local-part

local-part

[6]はやいはなしが、メイル・アドレスの @ の左側です。

特別な local-part

[24] 特別な local-part

句点が混じる local-part

[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 では最初の例は旧式構文。)

もはや "." にかつてのように特別な意味は無いんだけど、 歴史的理由によって扱いがちょっとやばいという、普通に戻れない 普通の文字、ってことでしょか(謎)。

[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 予約文字 [;/?:@&=+$,] : メイル・アドレスが URI参照の一部に使われることはよくありますが、予約文字 (RFC2396) は特別な意味に解釈され得ますし、 そうでなくても URI符号化形とそうでない形の区別が意味を持ってしまいますから、 迂闊に使うと手抜き実装で痛い目に合います。 (mailto: scheme などの場合の他に、 Webメイルhttp: scheme などで使われることもあります。)
URI 非安全文字 [{}|\^[]`<>#%"] , 間隔, 制御文字, 0x80〜
URI で使うときには必ず符号化しないといけませんが、手抜き実装で痛い目に(以下略)。 なお、 [ ] RFC 2732予約文字に移動しましたが、安全でないことには変わりありません。
822 特殊文字 [()<>[]@,;"\] , コロン, 間隔, 制御文字
局所部分で使うときは、必ず quote しないといけませんが、 quote に対応していないシステムも多いので困ります。 (RFC 821, 822, 2821, 2822)
0x80〜
電子メイルでは 0x7E 以下しか扱えません。 (RFC 821, 822, 2821, 2822)
NULL 0x00
C をはじめ多くのシステムでは 0x00 を扱えません。 RFC 2822 も禁止しています (RFC 822 は認めていました)。
経路指定 [!%@.]
伝統的に経路指定に使われてきました。 システムによっては今でもその意味で使われます。
IMAP 修正 UTF-7 &
IMAP 修正 UTF-7 で & は特別な意味を持ちますから、 いい加減な IMAP の実装で(以下略)。
encoded-word =?
いい加減な実装は所構わず encoded-word を解読しようとするかもしれませんので(以下略)。
LDAP 検索濾過特殊文字 [*()\] , NULL
iPlanet Messaging Server などは LDAP (RFC2254) を内部的にも使ってますが、 その時の特殊文字をちゃんと処理していないシステムもあったりします。
ECMAScript 特殊文字 ['"\]
JavaScript でメイルアドレスの構文をチェックしたりするのはよく行われますが、いい加減な(以下略)。
Perl 特殊文字 [$@\"'`[]{}/], ->
Perl で CGIスクリプトを実装して、その中でメイルアドレスを扱ったりよくしますが、いい加減(ry。 あるいは文字列として書くときにも特別に解釈され得る文字は無いほうがいいですし。
正規表現特殊文字 [()[]\+*?{}.]
メイルアドレスの一致検査に正規表現をよく使いますが、 特別に解釈され得る文字は無い方がいいです。

メモ

[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大文字・小文字不区別としています。

[18] ( 版) <https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf#page=24>

Communicating with the Domain’s administrator using an email address created by pre-pending ‘admin’,

‘administrator’, ‘webmaster’, ‘hostmaster’, or ‘postmaster’ in the local part, followed by the at-sign (“@”),

followed by the Domain Name, which may be formed by pruning zero or more components from the

requested FQDN;

[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>

[20] RFC 4282 - The Network Access Identifier ( 版) <https://tools.ietf.org/html/rfc4282#section-2.1>

The grammar for the username is based on [RFC0821]

[21] RFC 7542 - The Network Access Identifier ( 版) <https://tools.ietf.org/html/rfc7542#section-2.5>

Internationalization of the username portion of

the NAI is based on the "Internationalized Email Headers" [RFC6532]

extensions to the "local-part" portion of email addresses [RFC5322].

[22] RFC 7622 - Extensible Messaging and Presence Protocol (XMPP): Address Format ( 版) <https://tools.ietf.org/html/rfc7622>

[23] au、Eメールアドレスの設定文字数を最大30文字に拡張 (2006/06/01 11:57 ) <http://k-tai.watch.impress.co.jp/cda/article/news_toppage/29441.html>

これまでEZwebのEメールアドレスに設定できる文字数(@ezweb.ne.jpより前のユーザー名)は20文字までとなっていたが、6月6日以降は30文字まで設定可能となる。これに合わせて、「_」(アンダースコア/アンダーバー)の利用や、「.」(ピリオド/ドット)の連続使用、@直前での利用も可能となる。