[4] mailto:
は、電子メイルの宛先を表す URI scheme
です。 現在の定義では宛先だけでなく作成されるメイルの雛形の
Subject:
欄などの内容 (欄本体)
を指定することもできます。
[5] 特定の場所
を表さないという意味で、 http:
などのほかの URI scheme とは趣が異なります。
あくまで宛先を示すものであって、電子メイル・アドレスそのものの
URI 的表現では (基本的には) ありませんし、
電子メイルの作成という動作を表すものでもありません。
[842] mailto:
URL は、メール・アドレスにより指定されるメール箱という
「インターネット資源」を表します。 query が記述されている時には、
そのメール・アドレスと query によって指定された方法でアクセスできる資源を表します。
>>70 3.
[843] http:
URL など他の多くの URL scheme とは違って、
mailto:
URL を「解決」
してもすぐに鯖へのアクセスが発生するわけではありません。
指定されたメール・アドレスや頭欄が既定値となったメッセージが作られ、
それを利用者が編集し、または編集せずに送信したり、送信しないことにしたりできます。
mailto:
URL は電子メールによって自動的にインターネット資源にアクセスすることを意図したものではありません。
>>70 3.
[65] 2ch など一部の Web 上の掲示板システムでは、メッセージ (レスなどと呼ばれます。)
に題名や本文などと並んで電子メイル・アドレスを記述することができます。
電子メイル・アドレスは HTML として出力される際に mailto:
URL
として a
要素の href
属性に指定されます。
[66] 2ch のような匿名掲示板では実際にこの欄に電子メイル・アドレスが入力されることはほとんどありません。
href
属性の値は onmouseover
時に
Webブラウザの状態棒などに表示されることから、隠しメッセージ的な存在としてしばしば濫用されています。
[67] また、 2ch では掲示板一覧における当該スレの表示順序の制御のための「sage」
という指定が電子メイル・アドレス欄で可能になっています。そのため、「sage」やその対義語の
「age」がしばしば mailto:
URL
「mailto:sage
」、「mailto:age
」
として出現します。
[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.。
[107] mailto:
URL では ?
,
&
, =
が予約文字であり、
区切子以外として用いるときは百分率符号化しなければなりません >>70 2., 5.。
[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 しません)。
[77] mailto:
URL の path 部分
(生成規則 to
) は宛先メール・アドレスを表します。
[78] この部分の構文は addr-spec
となっています。
RFC 2368 のときは RFC 822 の mailbox
でしたが、より限定的になっています。
また、 RFC 2368 は RFC 822のABNF の #
を使っていて、
複数の mailbox
の間の ,
の前後に FWS
を入れることが認められていましたが、 RFC 6068 は認めていません。
mailbox
の定義が改訂されているのですが、
そっちの定義を使った方が良いのではないでしょうか。
と思っていたら、 RFC 6068 で mailbox
ではなくなりました。[857] /
は百分率符号化しなければならないとされている (>>86) ので、
authority と解釈されてしまうことはありません。
addr-spec
[83] RFC 6068 は addr-spec
を次のように定義しています
RFC 6068 2.。
comment
は除外します。obs-local-part
, NO-WS-CTL
は使ってはなりません。local-part
, domain
で空白と注釈を使ってはなりません。domain
では IDN
を表すために百分率符号化を使うことができます。 RFC 3986
の reg-name
についての規定を適用します。特に、
非ASCII文字は UTF-8 で符号化して百分率符号化しなければなりません。
UTF-8 でなければ百分率符号化を使ってはなりません。
IDN をメッセージ作成に使う時は RFC 5891 IDNA2008
に従って変形しなければなりません。
旧来の URI 解釈器との相互運用性を最大化したいなら、
百分率符号化ではなく IDNA 符号化を使うべきです。local-part
における非ASCIIオクテットの百分率符号化は、
local-part
の国際化のために予約します。
非ASCII文字は UTF-8 で符号化して百分率符号化しなければなりません。
それ以外に非ASCII文字を百分率符号化することは禁止します。
非ASCII文字を含む local-part
をメッセージ作成に使う時は
将来の仕様に従って変形しなければなりません。[93] この要件のほとんどは構文的に冗長な形式を認めないということに限られますが、
>>88 により local-part
が quoted-string
のときに空白が認められず、これについては表現できないメール・アドレスが生じることになりますが、
良いのでしょうか。そんなアドレスはほとんどないから良いということなのでしょうかね。
[888] >>93 でも >>887 のような例が RFC 6068 にはあって quoted-string
内で SPACE
が使われているので、これは仕様書本文が間違ってるのではないでしょうかね。。。
[36] 制定時期の関係から IDNA による非ASCII文字を含むドメイン名をどう扱うかは RFC 2368 の頃までは明記されておらず、 IDNA RFC の規定によりIDN未対応ドメイン名スロットであることから Punycode 符号化したものでなければならないと解釈されていました。 RFC 6068 でそれに加えて直接表記したものを百分率符号化してもよいことになっています。
[109] path 部分に指定する宛先が RFC 2368 のときは RFC 822 の mailbox
でしたが、
RFC 6068 では addr-spec
とより限定的になっています。
[110] 電子メールでは mailbox
よりも更に広い address
を記述できます。つまり group
があるのですが、 mailbox
や addr-spec
では使うことが出来ません。 group
を使う時は
query の中で ?to=foo:abc@bar.example;
とするのでしょう。
[111] address-list
(address = mailbox / group
)
にすると parse がやや面倒に
なることはあるのですが、どのみち query の中で使えてしまうのですから、
あまり意味がありません。そもそも、 RFC 822 (RFC 5322) MUA は group
を扱えなければなりません。 (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 が対応していなかったせいらしいです。
[95] query 部分は URL ではありがちな「名前=値&名前=値&...」 の形式で、メッセージを作成する時の頭欄の名前と本体を表します。
[96] hfname
, hfvalue
がそれぞれ RFC 5322
メッセージ頭部の欄名と欄値を示しています。 >>70 2.
[98] hfname
は大文字・小文字不区別です。
hfvalue
は一般に大文字・小文字を区別します。
>>70 2.
[99] 値についての制約、例えば hfname
が IANA に登録されていないといけないとか、
hfvalue
が当該 hfname
に対して妥当な値でなければならなないとか、
そういった制約はないようです。というかそういう観点の言及が全然ありません。
[97] addr-spec
同様に (>>86 のことか?) 百分率符号化が必要です。
>>70 2.
[823] hfvalue
では encoded-word を使って構いませんし、
UTF-8 を百分率符号化しても構いません。 >>70 2.
[825] 822 メッセージでは非ASCII文字は encoded-word
しか使えないわけですから、 mailto:
URL
の処理のためには 822 用の構文解析器とは別に非ASCII文字と
encoded-word の混合を扱える構文解析器が必要ということになります。
[49] 名古屋点訳ネットワーク 点字データ検索, http://www.n-braille.net/database/search/
Shift-JISとUTF-8はパソコン内部で使用している【文字コード】と呼ばれるものです。 お使いのパソコンがwindowsであれば、Shift-JISである可能性が高いのですが、文字が正常に表示されない場合は、下のUTF-8をクリックしてみてください。
[853] body
の hvalue
では、改行は
%0D%0A
で表さなければなりません。 >>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.
[850] subject
, keywords
, body
あたりの限られた頭欄だけが一般に安全でかつ有用と考えられています。
mailto:
URL の出所が明らかな場合であったり、
特定の頭欄が特定の既知の値だけに限定されている場合であったりすれば、
それ以外の頭欄も安全であるとみなして構いません。
>>70 4.
[851] メッセージの作成時には subject
と body
を使った RFC 5322 に適合する電子メール・メッセージを正しく作れなければなりません。
>>70 4.
[846] メッセージ作成時には、Originator field (From
, Date
など)、
経路制御関連の頭欄 (Apparently-To
,
Recent-*
など)、
trace field,
MIME頭欄 (MIME-Version
, Content-*
)
は無視しなければなりません。 >>70 3.
[847] メッセージ作成時には、 MUA が知らない頭欄や通常の値とは違うものに気をつけるべきです。 実際には安全であっても MUA が知らない頭欄があったりもするでしょうから、 利用者に対して表示するようにしても構いません。 >>70 3.
[852] mailto:
URL の著者としては、
subject
と body
以外が意図通りに解釈されることは必ずしも期待できません。
>>70 4.
[834] メッセージを作成するときに To:
頭欄を2つ生成してはなりません。
>>70 2.
[836] To:
以外の頭欄について、メッセージ中に1回だけ使えるものを
mailto:
URL で複数回使ってはなりません。 >>70 2.
[837] 相互運用性の問題を避けるため (利用者エージェントによって挙動が異なるため)、
同じ hfname
を複数回使うべきではありません。 >>70 2.
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:
頭欄が出現することは、
仕様上はありません。
[103] この指定は自動処理用の短いテキスト・メッセージ (たとえばありがちなメーリング・リストの 「subscribe」命令) を生成することが主な目的であって、一般の MIME 本体を生成することは考えていません。 >>70 2.
[105] 百分率符号化することにより、 UTF-8 の任意の文字列を指定できます (>>97)。
MIME では Quoted-Printable や Base64 で内容転送符号化することができますが、
mailto:
URL では認められておらず、
Content-Transfer-Encoding
のような符号化の指定があっても無視しなければなりません
>>70 2.。 >>823 のように encoded-word を使うことは認められていません >>70 2.。
[106] 現実には、非ASCII文字が百分率符号化せずに用いられていたり、 シフトJISなど UTF-8 以外で百分率符号化されていたりします。
mailto:
URLmailto:... だけの URL も構文上正しいことになります。意図的なのかどうかはわかりませんが、 RFC 6068 でもこれは変更されていません。
[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 の「解決」
は通常 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 に含まれているときにはしません。
[23] mailto:
は RFC としては、 URI の最初の RFC
である RFC 1630 で初めて規定されました。
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
に変換する必要があることに注意して下さい。
[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 を抜粋すると次の通り。
[865] 次の RFC 1738 と非互換なのは明らかです。
[866] ところで、これなら "mailto:" を取り去って % を復号すれば そのままメイル・アドレスになりそうな気がします。そのまま RFC 822 メッセージに突っ込んで使えるという意味ではその通りですが、 一般的な意味では間違いです。
RFC 822 addr-spec では構成要素間に注釈が挿入出来ますから、 「mailto:foo(comment)@bar.example」というのもありですが、 (comment) はメイル・アドレスの一部ではありません。 (なお、このアドレスは RFC 2368 的には不正のようです。括弧は %28 %29 にしないといけません。 (注釈の挿入自体は、 2368 でも認められています。というか本文に明記されています。))
[860] RFC 2396 世代になって単独の RFC となったのが第3次仕様 RFC 2368 http://tools.ietf.org/html/rfc2368 です。
[6] RFC 2368 では mailto:
URL の ABNF
構文は次の様に説明されていました。
[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 からも除外されることが分かります。
8-bit characters in mailto URLs are forbidden.
と2章の終わりに書いてあります。そのまま解釈すると URI ではそもそも8ビット文字は使えません。きっと、 % 符号化で符号化されたオクテットが8ビットのでは駄目、って言いたかったのでしょう。
[26] >>24 ietf-imaa で著者の PaulHoffman が、前者の意味で、 URI の仕様書にも書いてあるけど繰り返して注意を促したのだと述べています mid:p05210301ba74ba668b2d@[63.202.92.157]。
[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 ではよくある) 問題は基本的に解決していません。
[69] Web Forms 2.0 ( 版) http://www.whatwg.org/specs/web-forms/current-work/#for-mailto
[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
(名無しさん)
[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
を、 Subject
が foo&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
として指定することによって to
や cc
の人達からはメール・アドレスを隠すことができるかもしれませんが、 MUA
によっては bcc
に同時に指定した他の人にも見えてしまうことがありますし、
その他の方法で漏洩する可能性もありますから、注意する必要があります。 >>70 7.
当然、利用者が手動で Bcc から To や Cc に変更する可能性もあります。
[39] spam などのためにメイル・アドレスを収集するロボットは
HTML 文書などに含まれる mailto:
URI も収集の対象とします。
これへの対策として、 @ など 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 を指定するとページの表示の際にメールの作成画面が開くことがあります。
mailto:chris@example.com
mailto:infobot@example.com?subject=current-issue
mailto:list@example.org?In-Reply-To=%3C3469A91.D10AF4C@example.com%3E
mailto:joe@example.com?cc=bob@example.com&body=hello
mailto:joe@example.com?cc=bob@example.com?body=hello
[1] 古い Netscape の資料 (http://developer.netscape.com/docs/manuals/htmlguid/tags17.htm#1428618) は不正な例 >>3 のような URI を正当化(?)してます。
[831] この3例は等価ですが、 >>830 は利用者エージェントによって解釈が異なるので使用するべきではありません。 >>70 2.
mailto:infobot@example.com?body=send%20current-issue
mailto:majordomo@example.com?body=subscribe%20bamboo-l
mailto:infobot@example.com?body=send%20current-issue%0D%0Asend%20index
mailto:gorby%25kremvax@example.com
mailto:unlikely%3Faddress@example.com?blat=foop
mailto:Mike%26family@example.org
mailto:%22not%40me%22@example.org
"not@me"@example.org
を表します。
mailto:%22oh%5C%5Cno%22@example.org
"oh\\no"@example.org
を表します。
mailto:%22%5C%5C%5C%22it's%5C%20ugly%5C%5C%5C%22%22@example.org
"\\\"it's\ ugly\\\""@example.org
を表します。
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 となっています。
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
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 になっています。
[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
を使う場合の記述方法と、通知の送信方法が定義されています。
mailto:
URI でもそうすることがあるようです。 (Global じゃないし、あまり好ましい使い方ではありませんが。)[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:
リンクをクリックしても無反応、
ということもよくあります。
mailtoリンク
mailtoリンクでsubjectやbodyを指定する場合、XMLのキャラクタエンコーディングと同じエンコーディングを使用してURLエンコードする必要があります。
[45] Fix form submission's encoding algorithms ( (annevk著, )) https://github.com/whatwg/html/commit/ec42efb1d7c3a2e34db21b8076a8a3f4bd6dfb81
<li>詳しいお問い合わせ内容を、<a href="mailto:cs+kadenkaigi@hatena.ne.jp?subject=家電会議に関するお問い合わせ">家電会議サポート窓口</a>(メールアプリが起動します)までメールでお問い合わせください。</li>
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