隠しメッセージ欄、制御命令欄としての用法

[65] 2ch など一部の Web 上の掲示板システムでは、メッセージ (レスなどと呼ばれます。) に題名や本文などと並んで電子メイル・アドレスを記述することができます。 電子メイル・アドレスは HTML として出力される際に mailto: URL として a 要素の href 属性に指定されます。

[66] 2ch のような匿名掲示板では実際にこの欄に電子メイル・アドレスが入力されることはほとんどありません。 href 属性の値は onmouseover 時に Webブラウザの状態棒などに表示されることから、隠しメッセージ的な存在としてしばしば濫用されています。

[67] また、 2ch では掲示板一覧における当該スレの表示順序の制御のための「sage」 という指定が電子メイル・アドレス欄で可能になっています。そのため、「sage」やその対義語の 「age」がしばしば mailto: URL 「mailto:sage」、「mailto:age」 として出現します。

ABNF 構文

[74] RFC 6068 には次の ABNF 生成規則が示されています。 RFC 6068 2.

      mailtoURI    = "mailto:" [ to ] [ hfields ]
      to           = addr-spec *("," addr-spec )
      hfields      = "?" hfield *( "&" hfield )
      hfield       = hfname "=" hfvalue
      hfname       = *qchar
      hfvalue      = *qchar
      addr-spec    = local-part "@" domain
      local-part   = dot-atom-text / quoted-string
      domain       = dot-atom-text / "[" *dtext-no-obs "]"
      dtext-no-obs = %d33-90 / ; Printable US-ASCII
                     %d94-126  ; characters not including
                               ; "[", "]", or "\"
      qchar        = unreserved / pct-encoded / some-delims
      some-delims  = "!" / "$" / "'" / "(" / ")" / "*"
                   / "+" / "," / ";" / ":" / "@"

百分率符号化と予約文字

[86] 次の文字は百分率符号化しなければなりません >>70 2.。

• URI で使えない文字
• %
• ほとんどの gen-delims: /, ?, #, [, ]
• 一部の sub-delimis: &, ;, =

[107] mailto: URL では ?, &, = が予約文字であり、 区切子以外として用いるときは百分率符号化しなければなりません >>70 2., 5.。

[108] メッセージを作成する時は復号しなければなりません。 利用者に対してメッセージを提示する前に復号するべきです。 >>70 5.

[50] RFC 3696 (情報提供 RFC) では、 URI で使えない文字の他、 #、%、 ~、:、 / を百分率符号化しなければならず、 + は百分率符号化した方が安全で、 $、!、 _、@ は百分率符号化する必要はないという見解を示しています。 path 部分で = を百分率符号化していない例もでてきます。

path

[77] mailto: URL の path 部分 (生成規則 to) は宛先メール・アドレスを表します。

[78] この部分の構文は addr-spec となっています。 RFC 2368 のときは RFC 822 の mailbox でしたが、より限定的になっています。 また、 RFC 2368 は RFC 822のABNF の # を使っていて、 複数の mailbox の間の , の前後に FWS を入れることが認められていましたが、 RFC 6068 は認めていません。

[857] / は百分率符号化しなければならないとされている (>>86) ので、 authority と解釈されてしまうことはありません。

query

[95] query 部分は URL ではありがちな「名前=値&名前=値&...」 の形式で、メッセージを作成する時の頭欄の名前と本体を表します。

[96] hfname, hfvalue がそれぞれ RFC 5322 メッセージ頭部の欄名と欄値を示しています。 >>70 2.

[98] hfname は大文字・小文字不区別です。 hfvalue は一般に大文字・小文字を区別します。 >>70 2.

[99] 値についての制約、例えば hfname が IANA に登録されていないといけないとか、 hfvalue が当該 hfname に対して妥当な値でなければならなないとか、 そういった制約はないようです。というかそういう観点の言及が全然ありません。

空の mailto: URL

[79] path も query も省略可能なので、

mailto:

[80] この URL は MUA を起動するために使われることがあります。

素片識別子

[840] RFC 6068 は、素片識別子は取出しした資源の表現に依存する故、 URL scheme として素片識別子は規定しない、としつつも、 mailto: URL は取出しには使われないことから、素片識別子は使うべきではなく、 解決の際には無視するべきであるとされています。 >>70 2.

[905] 実際には、 # は body の中身に使われることがあったりします。 IE 以外のWebブラウザーは素片識別子ではなく、 path や query の一部であると解釈します。

mailto: URL の長さ

[34] URI や mailto: URI や RFC 822 電子メイル・アドレスの長さに仕様上の制限はありません。 しかし、 URI を使用するプロトコルや実装などで長さの制限が課されている場合もあります。

[30] mailto: URI では body を使って電子メイルの本文を指定することができます。ですから、 本文が長くなると当然 URI も長くなってしまいます。しかし、 RFC に書いてあったかどうかは忘れましたが、 RFC の著者によれば mailto: URI はどんな電子メイルでも作成できるようなものなのではなく、 ごくごく短いメッセージの作成にしか使わないものです。

[31] mailto: URI を WWW ブラウザから電子メイルのプログラムに受け渡すというのはありそうな使い方です。 ブラウザとメイラーの情報伝達方法は様々ですが、 OS その他の制限により、一定以上の URL を引き渡せないことがよくあります。 例えばコマンドライン・オプションとしてシェルを経由して別のプログラムに渡すなら、 シェルの課している長さ制限の対象となります。

メッセージ作成

[867] RFC 6068 は、 mailto: URL の「解決 (resolve) 」 は通常 MUA によってメッセージを作成して、利用者が送信や編集を選択できるようにすることだとしています。 (>>843 参照。)

[892] 利用者が意図せず電子メールを送ってしまうと様々な不利益を被ることが予想されます。 従って、 MUA はメールを送信しようとしていること、 そしてその内容の頭欄も含めた全体を復号した状態で利用者に提示するべきです。 >>70 7.

フォーム提出

[868] HTML では、 form 要素の action 属性により、フォームの提出先として mailto: URL を指定することができます。

正準化

[903] Webブラウザーは mailto: URL に対してほとんど正準化しません。 (mailto: URL に限らず行われる) URL で使えない文字のパーセント符号化が一部行われるくらいです。 IE と Opera は復号しがちで、Firefox と Chrome は符号化しがちです。 ただ http: URL とは違って URL で使えない ASCII 文字について IE はパーセント符号化しがちで Chrome は元のまま放置しがちです。

[904] Chrome は query に # が含まれているとパーセント符号化しますが、 他のWebブラウザーはしません。 Chrome であっても path に含まれているときにはしません。

RFC 1630

[23] mailto: は RFC としては、 URI の最初の RFC である RFC 1630 で初めて規定されました。

RFC 1738

[863] IETF Standard Track としては最初の URL の仕様である RFC 1738 には次の様に書かれています。

mailto:<rfc822-addr-spec>

where <rfc822-addr-spec> is (the encoding of an) addr-spec, as

specified in RFC 822 [6]. Within mailto URLs, there are no reserved

characters.

[864] RFC 1738 から BNF を抜粋すると次の通り。

1. ; MAILTO (see also RFC822)
2. mailtourl = "mailto:" encoded822addr
3. encoded822addr = 1*xchar ; further defined in RFC822
4. xchar = unreserved | reserved | escape
5. reserved = ";" | "/" | "?" | ":" | "@" | "&" | "="
6. escape = "%" hex hex
7. safe = "$" | "-" | "_" | "." | "+"
8. extra = "!" | "*" | "'" | "(" | ")" | ","

[865] 次の RFC 1738 と非互換なのは明らかです。

[866] ところで、これなら "mailto:" を取り去って % を復号すれば そのままメイル・アドレスになりそうな気がします。そのまま RFC 822 メッセージに突っ込んで使えるという意味ではその通りですが、 一般的な意味では間違いです。

RFC 822 addr-spec では構成要素間に注釈が挿入出来ますから、 「mailto:foo(comment)@bar.example」というのもありですが、 (comment) はメイル・アドレスの一部ではありません。 (なお、このアドレスは RFC 2368 的には不正のようです。括弧は %28 %29 にしないといけません。 (注釈の挿入自体は、 2368 でも認められています。というか本文に明記されています。))

RFC 2368

[860] RFC 2396 世代になって単独の RFC となったのが第3次仕様 RFC 2368 http://tools.ietf.org/html/rfc2368 です。

[6] RFC 2368 では mailto: URL の ABNF 構文は次の様に説明されていました。

1. mailtoURL = "mailto:" [ to ] [ headers ]
2. to = #mailbox
3. headers = "?" header *( "&" header )
4. header = hname "=" hvalue
5. hname = *urlc
6. hvalue = *urlc

[75] Another HTML‐Lint の覚書 http://openlab.ring.gr.jp/k16/htmllint/notice.html#rfc2368 に幾つか突っ込みがあります。

この構文はRFC1738から引用したように書かれていますが、RFC1738には urlc という構文要素は出てきません。RFC822にも出てきません(当然)。RFC2396の uric のことでしょうか。そもそもRFC1738にこのような構文は書かれていません。話の流れから言うと、uric から ? = & を取り除いたもののようです。

構文では hname と hvalue が共に空になり得るので、= だけのheader部が許されることになりますが、本当にそれでいいのでしょうか。

[862] RFC 2368 の第2章には

Note that all URL reserved characters in "to" must be encoded:

in particular,parentheses, commas, and the percent sign ("%"),

which commonly occur in the "mailbox" syntax.

と書いてあります。では URL reserved characters とは何でしょうか。 URI / URL の BNF にある「reserved」だとしたら、 "@" とかも使ってはいけなく なりますが、例をみればそうでないことが分かります。 とりあえず、 "(" / ")" / "," は「to」の文字から除外する必要があることだけは 確かです。また、次の段落には 「As with "to", all URL reserved characters must be encoded. 」 とあるので、 hname や hvalue からも除外されることが分かります。

[24]

8-bit characters in mailto URLs are forbidden.

と2章の終わりに書いてあります。そのまま解釈すると URI ではそもそも8ビット文字は使えません。きっと、 % 符号化で符号化されたオクテットが8ビットのでは駄目、って言いたかったのでしょう。

[26] >>24 ietf-imaa で著者の PaulHoffman が、前者の意味で、 URI の仕様書にも書いてあるけど繰り返して注意を促したのだと述べています mid:p05210301ba74ba668b2d@[63.202.92.157]。

RFC 6068

[73] RFC 6068 は RFC 3986 (URI), RFC 3987 (IRI) に対応した、 RFC としては第4世代の mailto: URL の仕様書です。

[42] Re: I-D ACTION:draft-duerst-mailto-bis-00.txt mid:200504081455.19877.blilly@erols.com

この記事では、 mailto: 仕様書の (ありすぎる) 問題点に Bruce Lilly が突っ込んでいます。 大変素晴らしいまとめです。

(この記事自体は Martin Duerst の (多文字化以外まったくやる気がない) Internet Draft に対するものですが、 RFC 2368 に対してほとんどまったくそのまま同じことが言えます。)

[900] >>42 は最終的に >>73 となりましたが、結局 RFC 2368 からの変更点はほとんど UTF-8 を使えることにしたくらいで、あとは百分率符号化に関する要件が若干明確になった程度です。 処理モデルが不明瞭であるとか、何が要件で何がそうでないのかが不明であるとか、 現実世界の混沌とした状況をほとんど無視しているとかといった (IETF ではよくある) 問題は基本的に解決していません。

HTML4

HTML5

[69] Web Forms 2.0 (2009-01-05 20:07:15 +09:00 版) http://www.whatwg.org/specs/web-forms/current-work/#for-mailto

WWW ブラウザの実装

[16] 歴史的には、 1630/1738 的な、なんとなくメイル・アドレス1個。な実装がされてきました。今でもそういう実装は結構あるでしょう。

[17] 2368 のように複数指定したり頭欄を指定したりできるのは Netscape の拡張が最初だそうです (裏は取ってませんが, そう認識されていたことがあるのは事実っぽい)。

[18] 2368 の仕様が確定・実装される以前には、 (mailto: URI の主な応用場面である) HTML の a 要素に、独自拡張として subject 属性や title 属性が設けられ、作成するメイルの Subject 欄の値を指定するのに使われていました。 (Lynx のように今でもこれを残す実装もあります。)

[29] mailto URI がどれだけ正確に確実に扱えるかは、 WWW ブラウザと MUA, それに場合によっては OS など環境に強く依存します。 統合製品群の中のブラウザと MUA のような特定の組み合わせではまともだけど他の MUA と組み合わせるとうまくいかないとかがざらにあります。

a 要素のような完全に URI だけの場合の実装は少しずつ良くなってきていますが、 form 要素の action として使われた場合に上手く動くかどうかは、 Mozilla や WinIE + OE のような場合でも未知数です。 (そもそもフォーム + mailto をちゃんと規定した規格がまったくないのが痛い。)

[32] Lynx などは実装しているけど NCSA Mosaic が実装していなくて、 早く実装してくれよーと思われていた時代もあったそうです。

[52] IEBlog : International Mailto URIs in IE7 (2007-02-13 09:15:19 +09:00 版) http://blogs.msdn.com/ie/archive/2007/02/12/International-Mailto-URIs-in-IE7.aspx (名無しさん 2007-02-13 00:19:11 +00:00)

[54] 2006年6月の戯言 (kuruman.org > 過去の戯言) (2006-06-29 23:59:59 +09:00 版) http://kuruman.org/old_diary/200606#D19-01 (名無しさん)

[57] EMail Msg <9307122305.AA40433@stat1.cc.ukans.edu> (2007-07-01 04:58:23 +09:00 版) http://ksi.cpsc.ucalgary.ca/archives/WWW-TALK/www-talk-1993q3.messages/117.html (名無しさん)

[58] EMail Msg <9307122305.AA40433@stat1.cc.ukans.edu> (2007-07-01 04:58:23 +09:00 版) http://ksi.cpsc.ucalgary.ca/archives/WWW-TALK/www-talk-1993q3.messages/117.html (名無しさん)

意図しないメールの送信

[895] mailto: URL が利用者の意図しないメールの送信に使われることを防ぐため、 利用者エージェントは利用者にメッセージ全体を提示して利用者の意思に基づき送信させることが要求されています (>>892 参照)。

[897] MUA によっては指定された Bcc: を表示せず、 利用者が意図しないメール・アドレスに知らないうちにメールを送ってしまう問題がありました。

メール・アドレスの漏洩

[893] 公開された Webページで mailto: URL を使うと、 そのページにアクセスしたあらゆる人達に対してメール・アドレスを公開することとなります。 これはたとえそのメール・アドレスが bcc に指定されていたとしてもです。 >>70 7.

[894] bcc として指定することによって to や cc の人達からはメール・アドレスを隠すことができるかもしれませんが、 MUA によっては bcc に同時に指定した他の人にも見えてしまうことがありますし、 その他の方法で漏洩する可能性もありますから、注意する必要があります。 >>70 7. 当然、利用者が手動で Bcc から To や Cc に変更する可能性もあります。

[39] spam などのためにメイル・アドレスを収集するロボットは HTML 文書などに含まれる mailto: URI も収集の対象とします。

これへの対策として、 &#64; など HTML の文字参照を使うのが2003年頃を中心に流行しましたが、 その後のロボット側の進歩でこのような対策は無意味となってしまいました。

[40] 他に古くから spam 対策で行われている方法に、 メイル・アドレス中に不正な文字列を混入し、 本来の利用者にはその文字列を削除するように自然言語で要求するもの (.nospam など) や記号を at や dot のように置き換えるものが古くから (単なるメイル・アドレスの記述においても、 mailto: URI の記述においても) 行われてきました。 spam の被害が益々深刻になっている現在では、 メイリング・リストの保管庫に記録する際にメイル・アドレス (のようなもの) の一部又は全部をそもそも消去してしまうという方法まで普通に行われるようになっています。

[72] IANA は登録簿でメール・アドレスの @ のかわりに & を使っていて、 mailto: URL でもそのまま & になっています。

mailto: URL の受渡し時の安全化

[41] WWWブラウザから MUA へなど、 mailto: URI は他の種類の URI に比べてプログラム間で受渡しされることがよくあります。 その受渡しの方法によっては危険が生じることがあり得ますから、 プログラムの実装者は注意が必要です。

例えば、 sprintf ("mua --new-message %s", mailto_uri) のように得た文字列をシェルに渡して外部プログラムを起動していると、 仮に mailto_uri が mailto:?subject=;another だと another という勝手なプログラムを起動できてしまうかもしれません。

mailto: ブラクラ

[46] 利用者エージェントの正当な機能が、 スクリプトによる自動処理などのために利用者を妨害することがあります。 mailto: URI へのリンクの活性化やフォームの提出の際の新しいメイルの作成画面や確認画面も、 ブラクラや迷惑広告に使われる可能性があります。

Web Forms 2.0 は、(連続する) フォーム提出で毎回メイル作成画面を出さないなどの対策が必要ではないかと指摘しています。

[898] 古い Webブラウザーでは img 要素の src 属性に mailto: URL を指定するとページの表示の際にメールの作成画面が開くことがあります。

単純な例

[33] >>70 6.1.

mailto:chris@example.com

頭欄を指定した例

[871] >>70 6.1.

mailto:infobot@example.com?subject=current-issue

[875] >>70 6.1.

mailto:list@example.org?In-Reply-To=%3C3469A91.D10AF4C@example.com%3E

[878] >>70 6.1.

mailto:joe@example.com?cc=bob@example.com&body=hello

[3] 誤った例 >>70 6.1.

mailto:joe@example.com?cc=bob@example.com?body=hello

[1] 古い Netscape の資料 (http://developer.netscape.com/docs/manuals/htmlguid/tags17.htm#1428618) は不正な例 >>3 のような URI を正当化(?)してます。

• [828] mailto:addr1@an.example,addr2@an.example
• [829] mailto:?to=addr1@an.example,addr2@an.example
• [830] mailto:addr1@an.example?to=addr2@an.example

[831] この3例は等価ですが、 >>830 は利用者エージェントによって解釈が異なるので使用するべきではありません。 >>70 2.

本文を指定した例

[872] >>70 6.1.

mailto:infobot@example.com?body=send%20current-issue

[877] >>70 6.1.

mailto:majordomo@example.com?body=subscribe%20bamboo-l

[873] >>70 6.1.

mailto:infobot@example.com?body=send%20current-issue%0D%0Asend%20index

符号化の例

[879] >>70 6.1.

mailto:gorby%25kremvax@example.com

[880] >>70 6.1.

mailto:unlikely%3Faddress@example.com?blat=foop

[883] >>70 6.1.

mailto:Mike%26family@example.org

[885] >>70 6.2.

mailto:%22not%40me%22@example.org

"not@me"@example.org を表します。

[886] >>70 6.2.

mailto:%22oh%5C%5Cno%22@example.org

"oh\\no"@example.org を表します。

[887] >>70 6.2.

mailto:%22%5C%5C%5C%22it's%5C%20ugly%5C%5C%5C%22%22@example.org

"\\\"it's\ ugly\\\""@example.org を表します。

[889] >>70 6.3.

mailto:user@example.org?subject=caf%C3%A9
mailto:user@example.org?subject=%3D%3Futf-8%3FQ%3Fcaf%3DC3%3DA9%3F%3D
mailto:user@example.org?subject=%3D%3Fiso-8859-1%3FQ%3Fcaf%3DE9%3F%3D

Subject に非ASCII文字を含めています。いずれも同じ文字列を表していますが、 1つ目は UTF-8 で直接記述、2つ目は UTF-8 の encoded-word、 3つ目は ISO-8859-1 の encoded-word となっています。

[890] >>70 6.3.

mailto:user@example.org?subject=caf%C3%A9&body=caf%C3%A9

Subject と本文に非ASCII文字を含めています。この URL から作成されるメッセージの例を2つ示します。このどちらでも、 あるいはこれ以外でも同等な表現はいろいろあり得ます。

From: sender@example.net
To: user@example.org
Subject: =?utf-8?Q?caf=C3=A9?=
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable

caf=C3=A9

From: sender@example.net
To: user@example.org
Subject: =?iso-8859-1?Q?caf=E9?=
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

caf=E9

[891] >>70 6.3.

mailto:user@%E7%B4%8D%E8%B1%86.example.org?subject=Test&body=NATTO

こちらはドメイン名に生の UTF-8 が使われています。この URL からメッセージを作成した例を次に示します。

From: sender@example.net
To: user@xn--99zt52a.example.org
Subject: Test
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

NATTO

RFC 5322 はドメイン名に ASCII 文字しか認めていないので、 作成されたメッセージでは Punycode になっています。

HTML フォームの例

[35] Web Forms 1.0 で電子メイルで提出させる例 HTML 4.0 17.3

 <FORM action="mailto:Kligor.T@gee.whiz.com" method="post">
 ...form contents...
 </FORM>

[38] HTML のフォームで電子メイルで提出させる例 (Subject を指定):

<form action="mailto:foo@example.com?Subject=Form%20Submittion" method="post">
(略)
</form>