なんでもdocomoやauでは、メールアドレスのlocal-part(@の前の文字列)に対して、
・先頭が"."(ドット)
・最後が"."
・".."のようにドットが連続する部分を持つ
といったメールアドレスを作成できるそうなのですが、これらはRFC2821に違反しているメールアドレスであるため、そういったアドレスに対するメールの送受信がエラーになるケースがあるそうなのです。
RFC2821(ftp://ftp.rfc-editor.org/in-notes/rfc2821.txt)を調べると、[4.1.2 Command Argument Syntax]には以下のような記述があります。
Local-part = Dot-string / Quoted-string
; MAY be case-sensitive
Dot-string = Atom *("." Atom)
Atom = 1*atext
Quoted-string = DQUOTE *qcontent DQUOTE
atestは英数字と一部記号でドットは含みません。
なので、local-partは"."が連続せず、且つ先頭と最後に使用されてはならないわけです。(他にダブルクォートで囲んだ文字列もありますがここでは省略します。)
docomoやauのアドレスでは、確かにこのルールに則っていませんので、RFC2821違反と言えるでしょう。
ただし、こういったアドレスに対するメールの送受信がエラーになるからと言って、必ずしもdocomoやauだけが悪いというわけでは無いようなのです。
同RFCの[2.3.10 Mailbox and Address]にはこうあります。
Consequently, and due to a long history of problems when intermediate hosts have attempted to optimize transport by modifying them, the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address.
local-partは、domainに指定されているホストでのみ、解釈と割り当てを行わなければならない(MUST)と記述があります。
つまり、docomo宛のlocal-partはdocomoでのみ、au宛のlocal-partはauでのみ、解釈すべきで、他のメールサーバーが解釈すべきでないわけです。
この章はメールボックスとアドレスに関する用語の説明ですので、このルールはRFC2821全体に関わります。
たしかに、docomoやauで運用されているような特殊なアドレスは、RFC2821違反であると言えるでしょうが、その事でdocomoやauを責めるのであれば、それらのアドレスのlocal-partを勝手に解釈してエラーとしてしまっている各メールサーバーも責められるべきだと思うのですよ。
**
上記はあくまで個人的な意見レベルのものなので、厳密な解釈は他の専門家の意見を参照したほうが良いかもしれません。
私自身は10年ほど昔に商用のSMTP/POP3ライブラリの実装をしたあとはこの分野から外れていましたので。
この意見の反論として、「local-partがフォーマットに沿っていないとそもそもアドレスがエラーになるんだからやっぱりdocomoやauが悪い」という意見もあるかもしれません。
これに関しては、RFCで定義されている書式をどう実装していくのが「正しい」かにもよるのですが、私自身は、
Mailbox = Local-part "@" Domain
と定義されている以上、まず"@"を見つけたあと、前部がlocal-part、後部がdomainと見なせるはずですので、local-partの解釈は必要ないはずという考えです。
[2.3.10 Mailbox and Address]を厳密に解釈すれば、送信時の処理はこれ以外の実装にはなりません。もちろんdomainが自分と同じであれば、その後local-partを解釈すべきです。
このネタは、色々な方がdocomo、auの仕様に対して突っ込みを入れていますが、一様にアドレスのRFC2821違反については言及があっても、サーバー側の問題には触れていないようなので起こしてみました。
なんか、一方的にdocomo、auが悪いという意見ばっかりだったのが気になったモノで。
タグ:RFC2821


