mailto: URL

mailto: URL

[4] mailto: は、電子メイル宛先を表す URI scheme です。 現在の定義では宛先だけでなく作成されるメイルの雛形の Subject: 欄などの内容 (欄本体) を指定することもできます。

[5] 特定の場所を表さないという意味で、 http: などのほかの URI scheme とは趣が異なります。 あくまで宛先を示すものであって、電子メイル・アドレスそのものの URI 的表現では (基本的には) ありませんし、 電子メイルの作成という動作を表すものでもありません。

目次

  1. 仕様書
  2. 意味
    1. 隠しメッセージ欄、制御命令欄としての用法
  3. 構文
    1. ABNF 構文
    2. 百分率符号化と予約文字
      1. +
    3. path
      1. addr-spec
        1. IDNA
      2. path と宛先
    4. query
      1. 符号化
      2. 改行
      3. to
      4. 無視するべき頭欄
      5. 複数の指定
      6. body
    5. 空の mailto: URL
    6. 素片識別子
    7. mailto: URL の長さ
  4. 処理モデル
    1. メッセージ作成
    2. フォーム提出
      1. 仕様書
    3. 正準化
  5. 歴史
    1. RFC 1630
      1. Mailto
      2. BNF for specific URL schemes (抜粋)
    2. RFC 1738
    3. RFC 2368
    4. RFC 6068
    5. HTML4
    6. HTML5
  6. 実装
    1. WWW ブラウザの実装
      1. MUA の実装
      2. 実装一般・その他の実装
  7. 安全性
    1. 意図しないメールの送信
    2. メール・アドレスの漏洩
    3. mailto: URL の受渡し時の安全化
    4. mailto: ブラクラ
    1. 単純な例
    2. 頭欄を指定した例
    3. 本文を指定した例
    4. 符号化の例
    5. HTML フォームの例
  8. 関連
  9. メモ

仕様書#

意味#

[842] mailto: URL は、メール・アドレスにより指定されるメール箱という 「インターネット資源」を表します。 query が記述されている時には、 そのメール・アドレスquery によって指定された方法でアクセスできる資源を表します。 >>70 3.

[843] http: URL など他の多くの URL scheme とは違って、 mailto: URL を「解決 (resolve) 」 してもすぐにへのアクセスが発生するわけではありません。 指定されたメール・アドレス頭欄既定値となったメッセージが作られ、 それを利用者が編集し、または編集せずに送信したり、送信しないことにしたりできます。 mailto: URL電子メールによって自動的インターネット資源にアクセスすることを意図したものではありません>>70 3.

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

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

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

[67] また、 2ch では掲示板一覧における当該スレの表示順序の制御のための「sage」 という指定が電子メイル・アドレス欄で可能になっています。そのため、「sage」やその対義語の 「age」がしばしば mailto: URLmailto: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  = "!" / "$" / "'" / "(" / ")" / "*"
                   / "+" / "," / ";" / ":" / "@"
[94] 仕様書本文中に別途百分率符号化についての規定 (>>86) があるため、 厳密ではありません。

百分率符号化と予約文字#

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

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

[108] path 部分で &, =予約する必要はないのでは... 簡略化のためでしょうか...

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

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

+#

[858] HTMLフォーム提出では、実装によっては SPACE+符号化します。しかし mailto: URL の仕様上は + は特別な意味を持たず、文字そのものとしての + を表します。従って SPACE%20 として符号化するべきであり+%2B として符号化して構いません>>70 5.

[71] au の携帯のブラウザ (の一部?) は、 local-part の「+」 を間隔とみなします。一方、Softbank の携帯のブラウザ (の一部?) は、 「%2B」を「+」の意味だと理解できません (percent-decode しません)。

path#

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

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

[82] といっても、 FWS が使えたとしても百分率符号化しなければ URI 共通の構文に反しますがね。
[81] RFC 1123mailbox の定義が改訂されているのですが、 そっちの定義を使った方が良いのではないでしょうか。 と思っていたら、 RFC 6068mailbox ではなくなりました。

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

addr-spec#

[83] RFC 6068addr-spec を次のように定義しています RFC 6068 2.

[91] 存在しない仕様に従わないといけないことを MUST にしても現時点で検証できない要件なわけで、どうなんですかね。。。
[92] >>89 のような条件付きの SHOULD も、適合するかどうかを一意に決められないわけで、 如何なものでしょう。

[93] この要件のほとんどは構文的に冗長な形式を認めないということに限られますが、 >>88 により local-partquoted-string のときに空白が認められず、これについては表現できないメール・アドレスが生じることになりますが、 良いのでしょうか。そんなアドレスはほとんどないから良いということなのでしょうかね。

[888] >>93 でも >>887 のような例が RFC 6068 にはあって quoted-string 内で SPACE が使われているので、これは仕様書本文が間違ってるのではないでしょうかね。。。

IDNA#

[36] 制定時期の関係から IDNA による非ASCII文字を含むドメイン名をどう扱うかは RFC 2368 の頃までは明記されておらず、 IDNA RFC の規定によりIDN未対応ドメイン名スロットであることから Punycode 符号化したものでなければならないと解釈されていました。 RFC 6068 でそれに加えて直接表記したものを百分率符号化してもよいことになっています。

path と宛先#

[109] path 部分に指定する宛先が RFC 2368 のときは RFC 822mailbox でしたが、 RFC 6068 では addr-spec とより限定的になっています。

[110] 電子メールでは mailbox よりも更に広い address を記述できます。つまり group があるのですが、 mailboxaddr-spec では使うことが出来ません。 group を使う時は query の中で ?to=foo:abc@bar.example; とするのでしょう。

[111] address-list (address = mailbox / group) にすると parse がやや面倒に なることはあるのですが、どのみち query の中で使えてしまうのですから、 あまり意味がありません。そもそも、 RFC 822 (RFC 5322) MUAgroup を扱えなければなりません。 (URI parser は単に分解して % 復号したものを そのまま MUA に渡せばいいだけです。 RFC 822 的な parse はする必要が無いはずです。)

[19] >>6 1997年くらい (NN3, WinIE 3 の時代。) には、 IE だと mailto:foo@bar.example,bar@foo.example のような URI だと IE では foo@bar.example だけが宛先になってしまうというのがちょっと問題になっていました。 これは MSIM が対応していなかったせいらしいです。

[20] もっとも、 >>19 のような複数指定や ? を使った複雑指定は、元々は Netscape の独自拡張で、もうちょっと前の時代には邪悪なものと考えられていました。 (結局 RFC になって誰も文句を言わなくなりましたが。)

query#

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

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

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

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

符号化#

[97] addr-spec 同様に (>>86 のことか?) 百分率符号化が必要です。 >>70 2.

[823] hfvalue では encoded-word を使って構いませんし、 UTF-8百分率符号化しても構いません。 >>70 2.

[824] 現実には UTF-8 以外、例えば EUC-JP百分率符号化されていることや、 百分率符号化せずに非ASCII文字が含まれていることもあります。

[825] 822 メッセージでは非ASCII文字encoded-word しか使えないわけですから、 mailto: URL の処理のためには 822 用の構文解析器とは別に非ASCII文字encoded-word の混合を扱える構文解析器が必要ということになります。

[826] mailto: URL からメッセージを作成する際には、 UTF-8 以外を使っても構いません>>70 2.

[49] 名古屋点訳ネットワーク 点字データ検索, http://www.n-braille.net/database/search/

Shift-JISとUTF-8はパソコン内部で使用している【文字コード】と呼ばれるものです。 お使いのパソコンがwindowsであれば、Shift-JISである可能性が高いのですが、文字が正常に表示されない場合は、下のUTF-8をクリックしてみてください。

改行#

[853] bodyhvalue では、改行%0D%0A で表さなければなりません。 >>70 5.

[854] メッセージの作成時には body の最後に改行を補っても構いません>>70 5.

[855] それ以外の hfvalue では改行を使うべきではありません>>70 5.

to#

[832] addr-spec 部分に宛先メール・アドレスを指定することができ、 メッセージ作成時には To: 頭欄で使われるのですが、 hfname として to を使い、 To: 頭欄を指定することも認められています。

[833] 従って addr-spec でだけ指定、 query でだけ指定、どちらでも指定の3通りがあり得ます。このうち両方指定する形式については、 実装によって扱いが違うことを利用に使用するべきではない >>70 2. とされています。

[845] メッセージ作成時には、To:, Cc:, Bcc: には必ずしも to, cc, bcc で指定されたものをそのまま使う必要はありません。メール・アドレスの重複は削除して構いませんmailto: URL には重複したメール・アドレスが含まれるべきではありません>>70 3.

無視するべき頭欄#

[848] メッセージ作成時には、危険と考えられる頭欄が含まれていれば、 作成を行うべきではありません。 あるいは、一部の頭欄だけからメッセージを作成しても構いません>>70 4.

[849] 前半が SHOULD ということは原則として前半の動作でなければならないのですが、 本当にそれでよいのでしょうか。どちらかといえば後半の方が現実的な動作なきがしますが・・・。

[850] subject, keywords, body あたりの限られた頭欄だけが一般に安全でかつ有用と考えられています。 mailto: URL の出所が明らかな場合であったり、 特定の頭欄が特定の既知の値だけに限定されている場合であったりすれば、 それ以外の頭欄も安全であるとみなして構いません>>70 4.

[851] メッセージの作成時には subjectbody を使った RFC 5322 に適合する電子メール・メッセージを正しく作れなければなりません>>70 4.

[846] メッセージ作成時には、Originator field (From, Date など)、 経路制御関連の頭欄 (Apparently-To, Recent-* など)、 trace field, MIME頭欄 (MIME-Version, Content-*) は無視しなければなりません>>70 3.

[899] RFC 2368 では Bcc も無視することになっていましたが、 RFC 6068 でリストから削除されています。 RFC 6068 の方がより実情に即しています。

[847] メッセージ作成時には、 MUA が知らない頭欄や通常の値とは違うものに気をつけるべきです。 実際には安全であっても MUA が知らない頭欄があったりもするでしょうから、 利用者に対して表示するようにしても構いません>>70 3.

[852] mailto: URL著者としては、 subjectbody 以外が意図通りに解釈されることは必ずしも期待できません。 >>70 4.

複数の指定#

[834] メッセージを作成するときに To: 頭欄を2つ生成してはなりません>>70 2.

[835] RFC 5322 の要件がなぜか RFC 6068 でも重ねて要件となっています。

[836] To: 以外の頭欄について、メッセージ中に1回だけ使えるものを mailto: URL で複数回使ってはなりません>>70 2.

[837] 相互運用性の問題を避けるため (利用者エージェントによって挙動が異なるため)、 同じ hfname を複数回使うべきではありません>>70 2.

[839] 最後だけ使うもの、複数の頭欄を作るもの、連結して1つにするものなどいろいろあるようです。 >>70 2.
[838] なぜか To: については禁止されていません。 mailto:1@example?to=2@example>>833 で原則禁止されていますが、 mailto:?to=1@example&to=2@example はなぜか >>836 で禁止されていません (>>837 で原則禁止されていますが)。

body#

[100] 特別な hfname body を使うと、 作成するメッセージ本文を指定できます。 body の値は、メッセージの最初の text/plain 本体部分の内容を表します。 >>70 2.

[101] body という頭欄の名前はこの目的に予約されている >>70 8.2. ため、 822 メッセージ頭部Body: 頭欄が出現することは、 仕様上はありません。

[102] 最初の text/plain 本体部分ということで、最初でさえあればよく、 多部分メッセージでなかったり、前に別の本体部分があったりしてもよいのでしょうね。

[103] この指定は自動処理用の短いテキスト・メッセージ (たとえばありがちなメーリング・リストの 「subscribe」命令) を生成することが主な目的であって、一般の MIME 本体を生成することは考えていません。 >>70 2.

[104] 現実には、自動処理用に限らず、人間宛メッセージの雛形だったり、 placeholder 的な文言を挿し込むために使われたりします。

[105] 百分率符号化することにより、 UTF-8 の任意の文字列を指定できます (>>97)。 MIME では Quoted-PrintableBase64内容転送符号化することができますが、 mailto: URL では認められておらず、 Content-Transfer-Encoding のような符号化の指定があっても無視しなければなりません >>70 2.>>823 のように encoded-word を使うことは認められていません >>70 2.

[106] 現実には、非ASCII文字百分率符号化せずに用いられていたり、 シフトJISなど UTF-8 以外で百分率符号化されていたりします。

[827] mailto: URL からメッセージを作成する際には、 UTF-8 以外を使っても構いません>>70 2.

空の mailto: URL#

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

mailto:
... だけの URL も構文上正しいことになります。意図的なのかどうかはわかりませんが、 RFC 6068 でもこれは変更されていません。

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

素片識別子#

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

[841] この規定は layering violation だと思いますが・・・。
[844] mailto: URL の「解決」は >>843 ですから、素片識別子を解釈するとしたら意味がよくわかりませんね。

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

[906] これは分解属性における処理での話なので、 メッセージの作成のために MUA に渡すときはきっと素片識別子まで含んだ URL 全体を使うでしょうから、むしろ MUA 側に解釈が委ねられると思います。

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 で使えない文字パーセント符号化が一部行われるくらいです。 IEOpera復号しがちで、FirefoxChrome符号化しがちです。 ただ http: URL とは違って URL で使えない ASCII 文字について IEパーセント符号化しがちで Chrome は元のまま放置しがちです。

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

歴史#

RFC 1630#

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

Mailto#

This allows a URL to specify an RFC822 addr-spec mail address. Note that use of % , for example as used in forming a gatewayed mail address, requires conversion to %25 in a URL.

[7] これは URL で RFC 822 addr-spec メイル・アドレスを指定可能にします。 例えば関門を挟んだメイル・アドレスで使われる % は、 URL 中では %25 に変換する必要があることに注意して下さい。

BNF for specific URL schemes (抜粋)#

  • [8] mailtoaddress m a i l t o : xalphas @ hostname
  • [9] xalpha alpha | digit | safe | extra | escape
  • [10] xalphas xalpha [ xalphas ]
  • [11] safe $ | - | _ | @ | . | & | + | -
  • [12] extra ! | * | " | ' | ( | ) | ,
  • [13] hostname ialpha [ . hostname ]
  • [14] ialpha alpha [ xalphas ]

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 です。

[861] 厳密には RFC 2396 より先に出版されているので RFC 1738 に従っています。

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

  1. mailtoURL = "mailto:" [ to ] [ headers ]
  2. to = #mailbox
  3. headers = "?" header *( "&" header )
  4. header = hname "=" hvalue
  5. hname = *urlc
  6. hvalue = *urlc
[76] RFC 6068RFC 2368 よりずっと明確化されていることがわかりますね。
[859] いずれの定義も、仕様書本文中に別途百分率符号化についての規定があるため、 厳密ではありません。

[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 6068RFC 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 ではよくある) 問題は基本的に解決していません。

[901] 現実世界で非ASCII文字の取り扱いについて互換性の問題が絶望的なレベルで存在しているにも関わらず、 「UTF-8 を使う方式は比較的相互運用性が低い」 >>70 8.1. という程度の言及しかしてませんしw

HTML4#

...

HTML5#

[69] Web Forms 2.0 ( 版) http://www.whatwg.org/specs/web-forms/current-work/#for-mailto

[870] WA1 との統合

実装#

WWW ブラウザの実装#

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

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

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

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

a 要素のような完全に URI だけの場合の実装は少しずつ良くなってきていますが、 form 要素の action として使われた場合に上手く動くかどうかは、 MozillaWinIE + 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 (名無しさん)

MUA の実装#

[27] M$OE では、 path/to/msimn.exe /mailurl:mailto:foo@bar.example とすると、その宛先へのメッセージ作成画面になります。 mailto:1 のような不正なアドレスを指定すると、 新規メッセージ作成画面になるようです。

実装一般・その他の実装#

[28] mailto:foo@bar.example?subject=foo&cc=bar@foo.example を、 Subjectfoo&cc=bar@foo.example だと思ってしまう実装が歴史的にかなりあったようです。 (今でもかなりあるかもしれません。) 1999年の時点で Windoze の実装の半数がそうだとの報告 (詳細未発表) もあります。

[53] Mailto URIs - Compose Form Data (2007-02-10 01:24:35 +09:00 版) http://shadow2531.com/opera/testcases/mailto/rfc2368-1.html (名無しさん 2007-02-14 11:13:24 +00:00)

安全性#

意図しないメールの送信#

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

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

メール・アドレスの漏洩#

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

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

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

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

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

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

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

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

例えば、 sprintf ("mua --new-message %s", mailto_uri) のように得た文字列シェルに渡して外部プログラムを起動していると、 仮に mailto_urimailto:?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

[876] In-Reply-To で返信先を指定しています。 メーリング・リストのアーカイブのページで使うと便利そうです。

[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 を正当化(?)してます。

[2] >>1 のようにお茶目なところもありますが、この資料は指定されても無視する頭欄が挙がっていて参考になります。

[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

[874] 改行%0D%0A となっています。

符号化の例#

[879] >>70 6.1.

mailto:gorby%25kremvax@example.com

[881] 文字としての「%」そのものを表すために %25 と表記しています。

[880] >>70 6.1.

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

[882] 文字としての「?」そのものを表すために %3F と表記しています。

[883] >>70 6.1.

mailto:Mike%26family@example.org

[884] 文字としての「&」そのものを表すために %26 と表記しています。

[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-8encoded-word、 3つ目は ISO-8859-1encoded-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>

関連#

[64] Sieve Notification Mechanism: mailto ( 版) http://www.ietf.org/rfc/rfc5436.txt

RFC 5436 では、 Sieve における通知の宛先として mailto: URL を使う場合の記述方法と、通知の送信方法が定義されています。

メモ#

[37] RFC 822 の仕様によれば、1つのメッセージに同じ名前の頭欄が複数存在し得ます。 mailto: URI scheme の仕様上も特に禁止されていないようです。 つまり、 query の部分で引数名が同じものが複数存在し得ます。 なお、同名の頭欄が複数存在する場合の意味は頭欄に依存します。 RFC 822 では曖昧な部分がありますが、 RFC 2822 には詳しく書かれています。

構文上は body も複数指定できてしまいます。 多分これは想定外でしょう。著者はそのような URI を使用しないように、 実装はそのような URI でおかしなことが起こらないように注意するべきです。

[59] TRANS - あなたのサイトの「お問い合わせ」、本当にクリックされていますか? (2007-06-30 22:54:38 +09:00 版) http://d.hatena.ne.jp/aratako0/20070630/p1 (名無しさん 2007-07-01 13:50:53 +00:00)

[61] A blog? with Σαιτω - 件名の文字化け (2007-10-10 09:12:16 +09:00 版) http://d.hatena.ne.jp/saiton/20071008/1191828919 (名無しさん)

[62] Mozilla-gumi Forum [One Topic All View / Re[2]: 件名の文字化け / Page: 0] (Mozilla-gumi 著, 2007-10-10 21:05:58 +09:00 版) http://forum.mozilla.gr.jp/?mode=al2&namber=12811&no=0&KLOG=84 (名無しさん)

[63] Mozilla-gumi Forum [One Topic All View / Re[4]: mailto の日本語subject / Page: 0] (Mozilla-gumi 著, 2007-10-10 21:06:57 +09:00 版) http://forum.mozilla.gr.jp/?mode=al2&namber=10520&no=0&KLOG=70

[68] mailto:について ( 版) http://www.wap2.jp/wap/mailto.html

WILLCOM以外では、メール題名・本文に半角英数字以外を含む場合はURLエスケープしなければなりません。

※メール本文に改行を含めたい時は、改行位置に¥n(%0A)を記述します。

KDDI・DoCoMoでは、mailto:が記載されているHTMLファイルの文字コードでURLエスケープします。 通常は、Shift_JISとなります。

SoftBank3GC端末では、UTF-8でURLエスケープしなければなりません。 Shift_JISでURLエスケープした場合、メーラーが起動した時、題名・本文に2バイト文字があると文字化けします。 mailto:リンクが記載されているHTMLファイルがUTF-8以外で書かれていても、UTF-8でURLエスケープする必要があります。

※SoftBank技術情報[XHTML編]P.19には、『本文は、ISO-2022-JPをエスケープせよ』という旨の記述がありますが、同P.68のサンプルはUTF-8でエスケープされています。

[907] WWW-Talk Apr-Jun 1993: Mail addresses as URLs ( ( 版)) http://1997.webhistory.org/www.lists/www-talk.1993q2/0276.html

[908] mailto リンクの落とし穴(Android編) - Qiita [キータ] ( ( 版)) http://qiita.com/rch850/items/72e83222efcecaf4f626

[909] ncsa-mosaic/CHANGES at master · alandipert/ncsa-mosaic ( ( 版)) https://github.com/alandipert/ncsa-mosaic/blob/master/CHANGES#L7

[912] mailto:スキームの注意点(iOS) - Qiita ( ( 版)) http://qiita.com/noppefoxwolf/items/12a3ee7c88dacaddf617

[25] 最近は Webブラウザーにも OS にも MUA が含まれておらず、 mailto: リンククリックしても無反応、 ということもよくあります。

[44] XHTMLBasic変換仕様 | Durianマニュアル ( 版) http://durian.symmetric.jp/dev/doc/technical/xhtmlbasic_conversion.html

mailtoリンク

mailtoリンクでsubjectやbodyを指定する場合、XMLのキャラクタエンコーディングと同じエンコーディングを使用してURLエンコードする必要があります。

[45] Fix form submission's encoding algorithms ( (annevk著, )) https://github.com/whatwg/html/commit/ec42efb1d7c3a2e34db21b8076a8a3f4bd6dfb81

[47] 家電会議の使い方 - はてなブックマークヘルプ () https://b.hatena.ne.jp/help/entry/kadenkaigi

<li>詳しいお問い合わせ内容を、<a href="mailto:cs+kadenkaigi@hatena.ne.jp?subject=家電会議に関するお問い合わせ">家電会議サポート窓口</a>(メールアプリが起動します)までメールでお問い合わせください。</li>

[48] Web Annotation Data Model () https://w3c.github.io/web-annotation/model/wd2/#h-agents

email Relationship The email address associated with the agent, using the mailto: IRI scheme [rfc6086].

Each agent may have 1 or more email addresses.

email_sha1 Property The text representation of the result of applying the sha1 algorithm to the email IRI of the agent, including the 'mailto:' prefix and no whitespace. This allows the mail address to be used as an identifier without publishing the address publicly.

Each agent may have 1 or more values in the email_sha1 property.

[56] mailto hostnames · Issue #331 · whatwg/url () https://github.com/whatwg/url/issues/331

[60] RFC 8292 - Voluntary Application Server Identification (VAPID) for Web Push () https://tools.ietf.org/html/rfc8292#section-2.1

[51] Welcome to Netscape Navigator 3.0, , https://web.archive.org/web/20020630200918/http://wp.netscape.com/eng/mozilla/3.0/relnotes/windows-3.0.html#JavaScriptBugs