[8] 近年では電子メールアドレスと言えば、ほとんどの場合インターネットメールのメールアドレスのことをいいます。
[4] メールアドレス風の識別子構文は、インターネットメール以外にも転用されています。 (その構文や意味は、少しずつ違いがあります。)
[10] 技術的には、これらはインターネットメールのメールアドレスと異なるものです。 実運用上は同じ識別子なら同じ利用者等を識別するのが好ましいでしょう。
[11] URL の authority 部分 (userinfo + ホスト名) も、 元々は電子メールアドレス構文を意識したものと思われます。
[12] Webアプリケーションの中には、利用者を識別するため入力させる文字列としてメールアドレスを採用していることがあります。 別途識別子を割り当てているとしても、ログイン時にその識別子でなく電子メールアドレスを使えることもあります。
[29] RFC 720 - Address Specification Syntax for Network Mail, , https://tools.ietf.org/html/rfc720
local-part
が空の account を使いたいかもしれませんし (既定の連絡先として有用かも!)、 FQDN も IP番地もないところのアカウントなら空の domain-literal
にすればいいし、第一そんな変てこなアドレスでも問題が起こったという話は聞かないからほっといていいでしょ、てな具合みたいです。 (ietf-822 の 2002年10月の mid:3D991B36.1070700@alex.blilly.com から始まるスレッド参照。)[6] スラッシュドット ジャパン | auのEメールアドレスが相互接続性を保障できないルールに変更? http://slashdot.jp/mobile/06/06/01/0931224.shtml (名無しさん 2006-06-04 03:04:55 +00:00)
[23] IDNA によって DNS には IDN を格納できるように拡張されていますが、
DNS に格納されるあらゆるデータに対して IDNA が適用されるわけではありません。
特に、電子メール・アドレスはしばしば DNS に格納されますが、
電子メールの local-part
はドメイン名スロットではなく、
IDNA の適用対象外です。 >>14, >>16
local-part
はACE接頭辞ではじまるべきではありませんし、
ACE接頭辞ではじまっていても IDN ではなく、そのままの文字列として解釈されます。 >>14
[15] >>23 などと SHOULD で規定されていますが、電子メール・アドレスの仕様でもないし、 update しているわけでもない IDNA の仕様で SHOULD といったところで効力はあるんですかねw 「そのまま解釈される」という事実の言明はその通りですが、 SHOULD 要件には意味が無いような。
[17] RFC 6943 - Issues in Identifier Comparison for Security Purposes ( ( 版)) http://tools.ietf.org/html/rfc6943#section-3.4
[18] RFC 2142 - Mailbox Names for Common Services, Roles and Functions ( ( 版)) http://tools.ietf.org/html/rfc2142
[19] RFC 3801 - Voice Profile for Internet Mail - version 2 (VPIMv2) ( ( 版)) http://tools.ietf.org/html/rfc3801#section-4.1.2
[20] RFC 7542 - The Network Access Identifier ( 版) https://tools.ietf.org/html/rfc7542
[21] RFC 7565 - The 'acct' URI Scheme ( 版) https://tools.ietf.org/html/rfc7565
[22] draft-seantek-mail-regexen-00 - Regular Expressions for Internet Mail ( 版) https://tools.ietf.org/html/draft-seantek-mail-regexen-00
[26] ガラケーの会社と Gmail だと Gmail の方が安全そうなイメージがありますが、 日本郵便的には逆のようですね。。。