ドコモとAUだけではなく、ドコモとAUに悩まされているメール管理者にも今一度思い出して欲しいのが、以下の言葉。

Jon Postel - Wikiquote
In general, an implementation must be conservative in its sending behavior, and liberal in its receiving behavior.
[一般的に、送り手としては控えめに振る舞い、受け手としてはおおらかに振る舞うよう実装する必要がある]

ドコモとAUの実装が「送り手としてひかえめ」でないことは明らかだし、そのことは私も

404 Blog Not Found:ドコモもauはとりあえず"da..me."@を受け取れるようにしとくべし
ドコモならびにAUにおかれては、RFC2822準拠をユーザーに促すと同時に、上のような対策をとってみたらいかがだろうか。

と、それもentryの一番最後に書いてある。

ドコモもauもいいかげんにメールアドレス設定の仕様を直せ。の続きと補足
少なくともこの手法は本書いたり業界紙に記事を書いたりするそこそこの有名人が詳しい周辺説明をほとんど沿えずに肯定的に解釈されかねない形で公開するようなことじゃない。

とあるが、私はドコモとAUの現在の実装、いや瑕疵を肯定的に解釈など少しもしていない。

それでも前回記事を書いたのは、Postel則の前半分だけでは、今回の問題は解決しないと感じたからだ。「受け手はおおらかに」であるならば、RFC2822違反のmailも「ダメ」の一言で済ませるのではなく、「本当は行けないのだけれども、今回は特別に受け付ける」というのが望まれる姿である。

MTAの実装が大変なのは、この「受け手」と「送り手」を双方かねなければならない点にある。ユーザーからのmailを一端受け取るには、そこでは「受け手」であるので、RFC2822違反のmailもとりあえず受け取るべきで、Hotmailなどの実装はおおらかさが不足しているということになる。しかしそれを今度はドコモやAUに配達する際には、そのメールアドレスをas-isで出すのは今度は「送り手としての控えめさ」が足りないことになる。

だから、MTAのレベルで、RFC2822違反のmailをRFC2822準拠のものに変更する方法がないかを考えた結果が、前回のentryである。そもそも"da.me.."@example.comをなぜRFC2822がわざわざ残したかと言えば、このPostel即が念頭にあったからだと言っていい。そこには「@の左側はローカルな世界だから、一端そこに届いたらそこはMail Agentにまかす」が確かにある。quotedはカプセル化の手段なのだ。

「送り手としての控えめさ」と「受け手としての多らかさ」の双方を満足させる実装として、このカプセル化というのはTCP/IPの実装では実によく見られる。IPv6をIPv4ネットワークでやりとりするための6to4しかり、テキストしかやりとり出来ないことになっていたmailの世界で、バイナリーデータをやりとりするために使われるBase64しかり。RFC2822のquotedに関する規定も、また例外ではない。

私の前回のMailを「小難しい正規表現とperlやJavascriptのコードを見せびらかしたかっただけちゃうんかと」としか読めない人は、RFCの行間を見事に読み落としている。RFCは法律でも公的規格でもない。"Request for Comment"、「ご意見お待ちしております」を略記したものなのだ。法律であれば、行間を読まなくてもそれは法律が悪いということになるが、控えめなRFCを「ただの企画書」以上のものにするためには、行間を読む必要がどうしても出てくるのだ。

もちろん、このPostel則を一番読まなければならないのが、ドコモとAUであることは言うまでもない。これはRFC2822に限ったことではない。絵文字の扱い一つとっても、Unicodeのコードポイントがないおかげで苦労している人々がたくさんいる。Postel則は、社会的影響力が大きければ大きいほど、守る価値が高くなる法則でもある。両社におかれては、大企業に相応しい行動をとっていただきたいものである。

Dan the Conservative Blogger in Writing, Liberal Blogger in Reading -- Hopefully