結局 "メールアドレスの規格" ってどこ？

メールアドレスの "規格" を探すと、おっそろしーことに未だ "RFC822を参照せよ" 、という文言を見かける。マジか。お前それいつの何の資料かわかって言ってんの？
(一応擁護すると、未だ "STD 11" はRFC822を参照している¹ - それはそれとして822を参照すること自体が不適切なのには変わりないんだが - ので、これについてはIETFもちょっと悪い気はする)

2系統の定義

メールアドレスの規格を調べる時混乱する要因の一つが、定義そのものが複数系統存在することだ。
こういうと「？」な感じなのだが、要するに「メールアドレスの規格」だけを定義するものはそもそも存在しない。
ムリもない話で、メールアドレスだけ存在しても周辺の伝送機構がなければなんにもならんのだ。住所とポストだけ整備しても郵便サービスがなければ手紙は届かんのである。

RFC822 系統

いわゆる「電子メールメッセージのデータ形式」の定義である。まだ3桁なあたりが時代を感じさせる。2018/01/16現在の最新はRFC5322で、標準となったのは822ながら、実はこの更に元ネタ (?) としてRFC733が存在する。
読めばわかるが、ARPANETのような懐かしい通り越して大多数の人間が「なにそれ」となりそうな単語が頻出する (気になったらとりあえず "カッコウはコンピュータに卵を産む" を読めばいいと思うよ。かくいう筆者もアレで知ったクチ) 。

これによるメールアドレスの定義はそれはもうドエラいガバガバっぷりを発揮しており、下手すると "もう /[@]/(= @ が含まれていればvalid) でいいじゃないか" とすら言われるほど²である。

Q. 何故こんなガバガバ定義なのか？

A. 「電子メールメッセージのデータ形式」の定義だから。
要するに、このRFCは「なんやかんやして受け取ったメッセージはこういうふうに解釈せえよ」と "受け取った者 (大抵は受信者のメーラー・ソフトウェア) に対して" 言っているのだ。

特に初期の定義は黎明期も黎明期のものである。いわゆる "メールアドレス" っぽい部分には人名が入り込んだりしていた。
よく見るこういうやつだ:

[e-mail] <hogefuga>

こういうのを受け付けるようにするとどうあがいたってそりゃガバる。
そもそも目的が「受け取ったものの解釈法」なので、根本的にこれを「メールアドレスの規格」として参照することそのものが論外である³。

RFC821 系統

SMTPという単語を聞いたことはあるだろうか。これはRFC772の提案物が821で標準化されたもので、2018/01/16現在の最新はRFC5321である。

SMTPは Simple Mail Transfar Protocol の略で、大雑把に言うとメールを送信する時の作法と送信系システムの規定である。
一般的には "SMTPサーバ" という形で聞く機会が (比較的) 多いはずだ。SMTPサーバはSMTPに従ってメールを送信する際それを受け付けてくれるサーバのことで、郵便でいうとそこらへんの郵便局に相当する。現実と異なり出しに行くのは通信一つで済むので、ポストに相当するものは存在しないと考えていい。

さて、先程 "受け取ったものの解釈法" の規定を "メールアドレスの規格" として扱うのは論外だと記述した。ではどこを使うべきか？ 無論 "メールアドレスを実際に使う側" の規定である。
既に大体察していると思うが、SMTPはまさにその "使う側" に他ならない。郵便局の人たちが読めないような書き方で郵便番号と住所と名前を書いても手紙が届かないように、SMTPサーバが解釈できないようなアドレスへメールを送れと言われても送りようがないのだ。必然的にRFC821系の最新を満たすのが望ましい。

……ただし、こうやっていろいろと掘っていくと最終的にかなりややこしい話になってくる。
(たとえば @ の前は quoted-string が利用可能である、とか……)
最終的には「RFCに意図的に違反した」バリデーションにならざるをえない、というのは珍しい話ではない。

結論

(少なくとも2018/01/16現在では) RFC5321を出来る限りそれっぽく満たすのがよい、ということになる。
……もちろんこれが死ぬほどややこしいのは言うまでもない。特にIPリテラルなどはほとんど無理ゲーに近い。
結局は input[type="email"] よろしく
/^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9-]+(?:\.[a-zA-Z0-9-]+)*$/
のような単純化した正規表現を使うとかそういう方向に倒すことが多くなるだろう。しかし、こういうものの裏にこういった資料群と葛藤があることは把握して然るべきである。
……あとは言うまでも無いが、まともに使えるライブラリがあるならそっちを使うべきだ。

参考

http://www.nslabs.jp/email-address-regular-expression.rhtml
http://srgia.com/docs/rfc5321j.html
http://srgia.com/docs/rfc1035j.html
https://www.w3.org/TR/html53/sec-forms.html#valid-e-mail-address

1. http://d.hatena.ne.jp/kazu-yamamoto/20080107/1199679405 によると、 IETF的には "標準" へわざわざ育て上げるメリットもないという認識があるらしくほったらかしらしい。まあわからんでもない、普通なら最新のRFCを優先する。 ↩

2. http://d.hatena.ne.jp/shidho/20090320/p1 記事自体は「お馬鹿な "使える正規表現まとめ" へのツッコミ集」である。あまりにお粗末な正規表現まとめが乱立していたため主語が大きくなり、主語が大きくなった結果クソリプが山ほど付いて大荒れになった。 ↩

3. http://jbpe.tripod.com/rfcj/rfc-822.j.sjis.txt ではこう訳されている: "この標準は、「電子メール」の枠組み内で、コンピューター利用者の間で送信されるテキストメッセージ用の構文を特定します。" つまりアドレスの定義はおまけ以下だ。822を参照すること自体が不適切なのには変わりない、というのはこういうこと。 ↩