[6]はやいはなしが、メイル・アドレスの @ の左側です。
[7] RFC 822/2822 では、 句点 (".") は、 local-part の最初と最後に、そのままでは書けません。 ですから、「foobar.@foo.example」は誤りです。 iモードの 携帯電話のメイル・アドレスには、このようなのが使われている ようですが、誤りです。 RFC 822/2822 に厳密に従う UA では 取り扱えません。
こういうときは正しくは、 quoted-string を使います。 ですから、正しくは「"foobar."@foo.example」になります。 これなら、 RFC 822/2822 に従う UA は正しく扱えます。 (し、あつかわなければなりません。)
ちなみに、 "." が混じっていなくても、 "" で括っても構いません。 「"foo"@hoge.test」は「foo@hoge.test」と同じ意味です。
ここで注意したいのは、 RFC 822/2822 の表現では引用符が 要るというだけであって、意味論的には引用符はアドレスの一部 ではありません。先ほどの例でいえば、 foo.example というところの 「foobar.」 という宛先、という意味であって、 「"foobar."」 という宛先ではありません。 RFC 822/2822 以外の世界においては、 foobar.@foo.example という表現が正しいかもしれません。 (ただし、 Internet の世界でそういうところはほとんどありません。)
RFC 822/2822 の local-part 中で "." は特別な 意味を持った文字として扱われています。 (ですから、ふつーにそのまま かけなくて、 quote する必要があるのです。)
歴史的にはどうやら、 "." は経路情報みたいなものの区切りに使われていた ようです。 RFC 822 の @bar.example,@foo.example: というような route とか、 foo%bar.example@foo.example みたいにする %-hack とか、そういうのの親戚みたいなものですか?
今でこそ、 @ の左側は local-part で、右側は世界的な domain という意識がありますが、昔は @ にはそれほど強い意味は無かった ってことでしょう。 (だって、 foo at bar at hoge みたいに 書いてたんでしょ、そもそも。)
おっと、脱線しすぎなんでこのくらいにして。
にしても、 "foo.bar".foo@foo.example と "foo.bar.foo"@foo.example と foo.bar.foo@foo.example って結局のところ、等価なんですかね? 厳密には同一視しては いけないんだろうけど、過去から現代にわたってずっと、 区別しないといけないことってあったんだろうか? と疑問に思ってます。 (ちなみに RFC 2822 では最初の例は旧式構文。)
もはや "." にかつてのように特別な意味は無いんだけど、 歴史的理由によって扱いがちょっとやばいという、普通に戻れない 普通の文字、ってことでしょか(謎)。
<foo>
という値を From:とか To:とかに入れたメッセージが sendmail のような一部 MTA を通ると、その MTA のドメイン名が補われて <foo@foo.example>
のようになることがあります。普通は問題ないのですが spam などがドメイン名なしで送られてきた時に、中継 MTA がこのような動作をすると勘違いの元で危険です。注意が必要です。quoted-string
があるとうまく送れないかもしれない (未確認。) ですが、いまどきそんなの使ってるところなんてないでしょう。 (あったら spam の温床じゃないかな。)[10] hxxk.jp - メールアドレスに使用できる文字列および、メールアドレスの判定の正規表現関連のまとめ (望月真琴 著, 版) http://hxxk.jp/2007/11/20/2309#replies-730
[11] NTTドコモ、メールアドレスのルールを変更 ~ ピリオド連続などが使用不可に:RBB TODAY (ブロードバンド情報サイト) 2009/04/03 ( 版) http://www.rbbtoday.com/news/20090403/59059.html
4月1日以降、メールアドレスを新規取得または変更する場合、新ルールが適用される。新ルールでは「○○..○○@docomo.ne.jp」(連続するピリオド)、「○○.@docomo.ne.jp」(@マーク直前のピリオド)といった命名方法が使用不可となる。すでに取得済みのアドレスについては、新ルールは適用されない。
[13] HTML5 で定義されている電子メール・アドレスの構文 (妥当な電子メール・アドレス)
では local-part での「.
」の無制限の使用が意図的に認められています。
[15] +
が利用者名と任意の文字列の区切子として使われることがあります。
この慣習は部分アドレスなどと呼ばれています。
[8] 局所部分で使っても安全な文字の種類について、 ietf-822 で話題になった時のまとめ (mid:2147483647.1030011437@dsl108-043.brandx.net, 2002年8月) をもとにまとめてみました:
[A-Za-z0-9]
postmaster
: RFC822 を除き) ありませんが、
多くのシステムでは同一視が行われます。 [_.=+/-]
_
は、最初の文字として使えないシステムがあります。
姓名の区切りによく使われます。
.
は、最初や最後の文字として使うときは quote
しないといけません。歴史的に特別な意味を持っていましたが、
今では勘違いされる虞も無いでしょう。
CMU Cyrus サーバーはメイル箱階層区切子として使います。
-
は qmail が部分番地区切子に使います。
システムが特別扱いしていないとしても、意味的に階層区切子と使われることが非常に多いです (特に ML とかで : RFC2142)。
一般の単語区切子に使われることも多いです。
=
も階層区切子に使われることがあります。
+
も iPlanet Messaging Server,
SIMS, PMDF, CMU Cyrus で階層区切子に使われます。
/
は X.400 関門などで特別な意味を持ちます : RFC2846。 [$&*?!~^()[]{}"'`\|#/<>]
, コロン, 間隔, 制御文字, 0x80 以上 [;/?:@&=+$,]
:
メイル・アドレスが URI参照の一部に使われることはよくありますが、予約文字
(RFC2396) は特別な意味に解釈され得ますし、
そうでなくても URI符号化形とそうでない形の区別が意味を持ってしまいますから、
迂闊に使うと手抜き実装で痛い目に合います。 (mailto:
scheme などの場合の他に、 Webメイルが http:
scheme などで使われることもあります。) [{}|\^[]`<>#%"]
, 間隔, 制御文字, 0x80〜 [
と ]
は RFC 2732
で予約文字に移動しましたが、安全でないことには変わりありません。 [()<>[]@,;"\]
, コロン, 間隔, 制御文字 [!%@.]
&
&
は特別な意味を持ちますから、
いい加減な IMAP の実装で(以下略)。encoded-word
=?〜encoded-word
を解読しようとするかもしれませんので(以下略)。 [*()\]
, NULL ['"\]
[$@\"'`[]{}/], ->
[()[]\+*?{}.]
[28]
+
が入っているとエラーにする壊れた実装があります。
[45] メールアドレスを収集利用するシステムが大文字と小文字の区別を保存せず勝手に変換している事例があります: 新生銀行
[47]
セキュリティーを理由に一部を隠して表示されることがあります。
[9]
[mew-dist 27636] Re: "が入ったメールアドレス (Kazu Yamamoto 著, 2007-04-19 06:54:18 +09:00
版) http://permalink.gmane.org/gmane.mail.mew.general.japanese/5990
DoCoMoでは、このようなアドレスも取れるのですが、携帯の網外からは送れない場合があって、(ものすごく後ろ向きではありますが)これをSPAM対策の裏技的に使っている人を時々見かけます。
はい。そういう都市伝説に惑わされて ".." を含むメールアドレスを 取り直す DoCoMo ユーザが多いと聞いています。
(名無しさん)
[12] RFC 5321 - Simple Mail Transfer Protocol ( 版) http://tools.ietf.org/html/rfc5321#section-4.5.3.1.1
[14] アンドロイドのメールアプリの中にはインテントでメールアドレスを受け取る時(?)に小文字に変換するものがあります。
[16] RFC 3801 - Voice Profile for Internet Mail - version 2 (VPIMv2) ( ( 版)) http://tools.ietf.org/html/rfc3801#section-4.1.1
[17] emailAddress
は大文字・小文字不区別としています。
[19] Official Google Blog: A first step toward more global email ( 版) https://googleblog.blogspot.jp/2014/08/a-first-step-toward-more-global-email.html
[22] RFC 7622 - Extensible Messaging and Presence Protocol (XMPP): Address Format ( 版) https://tools.ietf.org/html/rfc7622
[27] インターネットラジオステーション<音泉> () https://www.onsen.ag/support/faq
[30] この構文を定めてる「「RFC」と呼ばれるインターネットメールの世界標準規格」はいったいどこにあるのだろうか。 どこのインターネットのどの RFC かくらい書こうよ。。。
[31] フェイクニュースのようにみえるが毎日新聞社独自のインターネット(謎)の可能性が微レ存だからなw
[38]
tag:
URL
に似た構文がありますが、そちらはかなり厳しい制限が加わっています。
[42] Gmail アドレスでのピリオドの扱い - Gmail ヘルプ () https://support.google.com/mail/answer/7436150?hl=ja
[44] CLUB Panasonic、「+」を含むメールアドレスを不正な書式として無効化 | スラド IT () https://it.srad.jp/story/22/07/19/1535249/
[46] Disclosure of a vulnerability that allows the theft of visitors' email addresses using Medium's custom domain feature / Mediumの独自ドメインプランを使って訪問者のメールアドレスが窃取できる脆弱性の開示 · GitHub, https://gist.github.com/mala/c2ef4b49e7d71490de22bd8e9c3f962f
Also, the domain part and the first two characters of the email address are not masked, so the full email address may be inferred or the mask may not work. eg: me@example.com
[48] Xユーザーのナンジャモリスナーさん: 「@KFC_jp ケンタッキーのアプリにログインできなくなりました。+記号の入ったメールアドレスだと弾かれる仕様に変わったみたいです。メールアドレスを変更したいのですが、どうすればいいですか?」 / X, , https://x.com/inunoote/status/1817357042786693500