記事本文
メールアドレスと RFC 絡みの話を自分用にまとめ
ドコモもauもいいかげんにメールアドレス設定の仕様を直せ。という記事がはてなブックマークの人気エントリー入りをしているようですね。 その記事が投稿されるにあたって、 DoCoMoの説明にある「RFCに準拠しています」はウソが再編集されて、昨日の Movable Type の Trackback Auto-Discovery は記事ごとにどうにかできないかで取り上げた Trackback Auto-Discovery の暴発につながっていたのです、実は。
せっかくの機会なので (?) 、メールアドレスと RFC 絡みの話をもう一度まとめてみたいと思います。 と言っても、過去の自分の記事や、他のサイトの記事のリンクを整理するだけですが。
メールアドレスに使用できる文字列絡みの記事
- RFC
- 2004-10-09: メールアドレスに使える文字
-
つまり，メールアドレスはatextで始まり，間にatext又は"."が来てatextで終るということらしい．
- 2004-10-10: hxxk.jp - メールアドレスに使える文字
-
atext で囲まれていない "." が存在する場合は dot-atom トークンにはなり得ないということだと考えられますので、「 "." の連続使用」と「 local-part の最初や最後に "." の使用」はできないと覚えておいた方がいいと思います。
- 2004-10-22: RFCを読まなかった携帯キャリアの罪
-
auやdocomoの携帯電話上ではメールアドレスの設定変更の画面において、 xxxx.@docomo.ne.jpのように設定しても通ってしまう。 結果、Exchangeやpostfixなどのメールサーバからこうしたメールアドレスに送信しようとするとエラーになる。 携帯キャリア(auやdocomoのこと)のエンジニアがメールアドレスのフォーマットにまつわるRFCを理解しきらずに メールアドレスの設定変更システムを作ったことが原因だ。
- 2004-10-23: hxxk.jp - RFC によるメールアドレスの local-part におけるピリオドの取り扱いについての考察
-
RFC 2822 における、 Some of the structured header field bodies also allow the period character (".", ASCII value 46) within runs of atext. An additional "dot-atom" token is defined for those purposes. という記述と、 If the string can be represented as a dot-atom (that is, it contains no characters other than atext characters or "." surrounded by atext characters) という記述が、 メールアドレスの@の直前にはピリオドは使ってはいけない ということの根拠になると思います。
- 2005-03-15: hxxk.jp - 携帯電話のメールアドレスにおけるピリオドの扱い
-
実際に禁則処理を行っているかは分かりませんが、 au はピリオドによって RFC に準拠しないアドレスに設定されることは無いようです。 vodafone は @ の直前への配置を禁じているだけで、連続使用は注意書きだけに留めています。 DoCoMo は注意書きだけで全く禁止していません。
- 2005-03-16: hxxk.jp - FOMA SH901iC の不具合の一部は DoCoMo 自身の過去のツケ
-
これは DoCoMo のプレスリリースですが、機能向上と表現するべき所じゃないでしょう。 辛辣に言ってしまえば、単に過去のミスのツケが廻ってきた分を粉飾しているだけなのですから。
- 2006-04-11: DoCoMoの説明にある「RFCに準拠しています」はウソ
-
もしかして今現在でも「ｉメニュー」のメールアドレス変更画面は、@の直前にピリオドを置くような設定をユーザーに許してしまっているのか？ もしそうだとすれば、もうそういう風に設定しちゃったユーザーはしょうがないとして、今後そういうアドレス設定が増えないように、設定画面を仕様変更すべきなんじゃないのか？ それすらしないどころか逆に今の仕様は正しいという誤った情報を流すってのはどうなのよ？
- 2006-04-30: ドコモの説明から「RFCに準拠しています」が削除
-
「RFCに準拠しています」の一行が消えている。
- 2006-06-01: スラッシュドット ジャパン | auのEメールアドレスが相互接続性を保障できないルールに変更?
-
kazu070曰く、"インプレス ケータイWatchの au、Eメールアドレスの設定文字数を最大30文字に拡張 によると、メールアドレスの20文字から30文字への文字数の拡張にあわせて、「「_」（アンダースコア/アンダーバー）の利用や、「.」（ピリオド/ドット）の連続使用、@直前での利用も可能となる。」という仕様が発表されている。 効果としては、迷惑メールを受信しにくくなるという後ろ向きなメリットが挙げられる。
- 2006-06-02: みんなで渡れば怖くない － au by KDDI メールアドレスにRFC違反を故意に許すの巻
-
いくらナンバーポータビリティ実施が近づいてるからって、DocomoのユーザーがKDDIに乗り換えたとしてもメールアドレスは@docomo.ne.jpのままなんてことは不可能なんだろうから、メールアドレスのローカルパート（＠の左側）仕様だけ合わせて改悪してもメリットよりデメリットのほうがよほど大きい。
- 2007-08: メール アドレスの @ より前にピリオドがあるなど RFC に準拠していない宛先に Outlook からメッセージを送信できない
-
RFC 2821、RFC 2822 では、@ の前の文字列をピリオドで区切ることを許可しています。 しかし、区切り文字であるピリオドや @ を連続して使用することを許可していないことにより、この現象が発生します。
これ、タイトルだけ読むと「 @ の前にピリオドが存在すると RFC に準拠していない」と誤認しそうですね。 後でフィードバックを送ろうかなあ。
- 2007-11-19: ドコモもauもいいかげんにメールアドレス設定の仕様を直せ。
-
回避策はもちろん無い。 これはOutlookの仕様であり、かつ、「電子メール」そのものの、もともとの仕様だからだ。 そんなおかしなメールアドレスを取得できてしまうサービス提供者＝ドコモとau＝に100%の責任がある。
- 2007-11-20: 404 Blog Not Found:ドコモもauはとりあえず"da..me."@を受け取れるようにしとくべし
-
実はRFC2822の規定では、
da.me..@docomo.ne.jpはNGだが、意外なことに"da.me.."@docomo.ne.jpはOKなのだ。 @の前の部分が""でくくられている場合、RFC2822はそれを特別扱いすることになっている
メールアドレスかどうかの判別を行う正規表現絡みの記事
- 2007-05-30: はてなブックマーク - 正規表現：メールアドレスかどうか調べる - phpspot
-
これから新規メアドを作成するような入力欄がこれでは全然ダメ。 しかし既存メアドの入力欄(一般的なメール欄)は、RFC違反のメアドが実在する以上、この程度で仕方ないと言える。
- 2007-05-31: PHPでメールアドレスかどうか調べる方法
-
ていうか「メールアドレス」「正規表現」でぐぐると最初に出てくるリソースに、思いっきり
メールアドレスに一致する正規表現は「ありません」
なんてあって、その下に条件付きの鬼のような正規表現が紹介されている。 メールアドレスの闇は深い。 ヘタに触れると火傷する。 - 2007-06-01: re: PHPでメールアドレスかどうか調べる方法 (ハズレ日記)
-
DNS引いてドメインの有効性チェックまでやるsymfonyはヤリ過ぎ。
- 2007-06-02: PHPでメールアドレスを確認する「正しい方法」(Linux Journal誌の記事より) - J0hn D0e の日誌
-
「メールアドレスに一致する正規表現は「ありません」」って書いてあるけど、よくよむと、「クオートすればなんでも入るから」って話ですよね。
- 2007-10-17: 秋元@サイボウズラボ・プログラマー・ブログ: phpspotの人は正規表現について語らないほうがいいのでは
-
これは、"example@so-net.ne.jp"とか"example+tracer@gmail.com"をメールアドレスではないと判定する。 この簡単さだと、メールアドレスじゃないものを通してしまう取りこぼしも多いはず。
- 2007-10-18: 秋元@サイボウズラボ・プログラマー・ブログ: phpspotの件の続報
-
なお、今も注釈つきで載り続けているコードはこれ。使っちゃだめよ。
一度このネタを使って勉強会で発表した
実は、これらのネタは以前 PHP in Fukuoka の第 2 回勉強会 (2007 年 6 月 3 日開催 ) にて PHP フレームワークと携帯メールアドレスの罠というタイトルで発表させていただいたものです。 今回メールアドレス絡みの話が盛り上がっていたので、その時にまとめていたリンクを再利用しておくか、という感じで書いたのが今回のまとめです。
ちなみに、私はメールサーバの運用やメールサービスの開発などには全く関わったことがないので、リンク記事の選定や内容の引用が適切かどうかの判断は、ご覧になる皆さんで行っていただきたいと思います。
