PHPフレームワークと携帯メールアドレスの罠 (2007-06-03)

1. メールについての基礎知識
2. メールアドレスについての基礎知識
3. メールアドレスの文字制限
4. 携帯電話各社の、メールアドレス設定に関する制限(1)
5. 各社のlocal-partの制限とRFC(1)
6. dot-atomについて
7. 携帯各社の、メールアドレスに設定に関する制限(2)
8. 各社のlocal-partの制限とRFC(2)
9. "."をlocal-partの先頭または最後に配置、あるいは連続して使用したアドレス
10. 対処法

PHP in Fukuoka: 2007-06-03

はじめに

• このスライドは、http://hxxk.jp/2007-06-03にていつでも閲覧可能です。
  • 全ての項目を書き写したり、写真に残したりする必要はありません。
  • ただ、スライドはあくまで最低限のことしか書いていないので、ポイントは適宜メモ等をお願いします。
• 今回の内容は、2004～2005年頃にhxxk.jpで書いた内容をベースにしています。
  • 人によっては既に「読んだことがあるよ！」という方もいらっしゃるかも。
  • また、私は実務でこの問題に直面したわけではないので、理論上の話に過ぎない点があるかもしれません。
    • →では、本題に移ります！

メールについての基礎知識

• 詳しくは各自RFC 2822 - Internet Message Formatを読んでください。（和訳もあります）
• アドレスの規定は3.4. Address Specification部分

• address	mailbox	name-addr	[display-name] angle-addr
  		addr-spec	local-part "@" domain
  	group	display-name ":" [mailbox-list / CFWS] ";" [CFWS]	省略

メールアドレスについての基礎知識

• 詳しくは各自RFC 2822 - Internet Message Formatを読んでください。（和訳もあります）
• アドレスの規定は3.4.1. Addr-spec specification部分

• addr-spec	local-part "@" domain	local-part	dot-atom	[CFWS] dot-atom-text [CFWS]	[CFWS] 1*atext *("." 1*atext) [CFWS]
  			quoted-string	[CFWS] DQUOTE *([FWS] qcontent) [FWS] DQUOTE [CFWS]	省略
  			obs-local-part	word *("." word)	省略
  		domain	dot-atom	[CFWS] dot-atom-text [CFWS]	[CFWS] 1*atext *("." 1*atext) [CFWS]
  			domain-literal	[CFWS] "[" *([FWS] dcontent) [FWS] "]" [CFWS]	省略
  			obs-domain	atom *("." atom)	省略

• "@"より前はlocal-part
• "@"より後ろはdomain

メールアドレスの文字制限

• 文字数の制限については、RFC 2821 - Simple Mail Transfer Protocolに。
  • local-partはThe maximum total length of a user name or other local-part is 64 characters.
  • domainはThe maximum total length of a domain name or number is 255 characters.
• 文字の種類の制限については、RFC 2822 - Internet Message Formatに。
  • local-partはdot-atom / quoted-string / obs-local-partのいずれかで構成されます。
  • domainはdot-atom / domain-literal / obs-domainのいずれかで構成されます。
• 基本的にはdot-atomで構成されます。dot-atomについては後ほど詳しく。

携帯電話各社の、メールアドレス設定に関する制限(1)

	DoCoMo	SoftBank	au	イー・モバイル
参考ページ	メールアドレス変更 | お知らせ | NTTドコモ	メールアドレス設定｜SoftBank	KDDI au: 迷惑Eメール防止方法 > Eメールアドレス変更方法	emobile.jp
文字数	半角英数字等で3字以上30字まで	半角3字以上30字以内	Eメールネーム文字数が、30文字まで利用可能	メールをご利用の場合は各プロバイダとのご契約が必要とのことなので、各プロバイダの制限による
文字の種類	英数字のほか、使える記号は「_」（アンダーバー）「.」（ピリオド）「-」（ハイフン）です。 「スペース（空白）」は使用できません 英字を入力する場合、大文字小文字の区別はありません。すべて小文字で表示されます。 先頭文字は英文字にして下さい。	半角英数字及び特殊記号（_ - . のみ） スペースはご利用いただけません。 アカウント名の先頭に数字はご利用できません。（英字のみ。） 「.」をアカウント名の最後（@マークの直前）にご利用いただけません。 「.」の連続でのご利用はできません。 大文字と小文字の識別はされません。（例：ABCDE＝abcde）	半角英数字、小文字、「- (ハイフン)」、「. (ピリオド/ドット)」、「_ (アンダーバー)」が使用できます。

各社のlocal-partの制限とRFC(1)

• 文字数についてはRFCの規定よりも少なく、30文字以内。
  • メールアドレスを管理するデータベースのフィールドが30バイトにでもなっているのかも。
  • auは2006年6月以前は20文字以内という制限がありました。迷惑メール対策の一環ということで20文字から30文字に拡張されましたが、これは同年10月のナンバーポータビリティを睨んでいたんじゃないかと邪推。
• 文字の種類についてもRFCの規定よりも厳しく（後述）、ALPHA / DIGIT / . / _ / - のみ
• RFCというよりも、データベース運用や、アドレスチェックのためのコストによる独自の制限？

dot-atomについて(1)

• dot-atomについては、RFC 2822 - Internet Message Formatに。
  • dot-atom = [CFWS] dot-atom-text [CFWS]
  • dot-atom-text = 1*atext *("." 1*atext)
  • 要するに、「1文字以上のatextまたは"."が1文字以上のatextで囲まれている文字列(dot-atom-text)」の前後にコメントや空白文字や改行が配置される。
  • よって、"."がlocal-partの先頭や最後に出現したり、また2文字以上連続して出現したりはしない。

dot-atomについて(2)

• dot-atom-textは"."とatextで構成されます。

  • atext           =       ALPHA / DIGIT / ; Any character except controls,
                            "!" / "#" /     ;  SP, and specials.
                            "$" / "%" /     ;  Used for atoms
                            "&" / "'" /
                            "*" / "+" /
                            "-" / "/" /
                            "=" / "?" /
                            "^" / "_" /
                            "`" / "{" /
                            "|" / "}" /
                            "~"

• 前述の通り、携帯電話のlocal-partとしては各社ともALPHAとDIGITと"."と"_"と"-"しか使えない。
• でも"?"や"/"がlocal-partに入っているソフトバンクユーザが友人にいます。J-PHONE時代にそのlocal-partにしていたので、今でも使えるかは不明。

携帯各社の、メールアドレスに設定に関する制限(2)

	DoCoMo	SoftBank	au	イー・モバイル
参考ページ	メールアドレス変更 | お知らせ | NTTドコモ	メールアドレス設定｜SoftBank	KDDI au: 迷惑Eメール防止方法 > Eメールアドレス変更方法	emobile.jp
「ご注意」	「.」（ピリオド）をアドレス内で連続使用したり、アドレスの最後に設定すると、一部のプロバイダとメールを送受信できない場合があります。	アカウント名の先頭に数字はご利用できません。（英字のみ。） 「.」をアカウント名の最後（@マークの直前）にご利用いただけません。 「.」の連続でのご利用はできません。	「. (ピリオド/ドット)」をアドレス内で連続使用したり、@マーク直前に設定すると、一部のプロバイダーとメールを送受信できない場合があります。	メールをご利用の場合は各プロバイダとのご契約が必要とのことなので、各プロバイダの制限による

• ソフトバンクはlocal-partの先頭は英字のみなので、dot-atomの形式に沿っています。
• auも、以前はソフトバンク同様にdot-atomの形式に沿っていたのですが、前述の文字数20文字→30文字拡張の際に、DoCoMoに合わせた形に変更されました。やっぱりナンバーポータビリティが関係？
• DoCoMoはかなり以前からdot-atomの形式に沿っていませんでした。

各社のlocal-partの制限とRFC(2)

• あくまで状況証拠だけでの判断ですが……
  1. DoCoMoはRFCを意識しないまま自社メールサービスの仕様を決定した。
  2. auおよびJ-PHONE（当時）はRFCを意識して自社メールサービスの仕様を決定しつつ、DoCoMoとのメールのやりとりは行えるようにしていた。
  3. ナンバーポータビリティ制度の開始。
  4. 「キャリアをDoCoMoから変えたら、docomo.ne.jpの部分が変わるのは分かるけど、@より前も変わっちゃうのはなんでなんで！」とユーザに思われるのを避けたい。
  5. auはDoCoMoに合わせた仕様に妥協。
• 個人的には、どうせドメイン部分は変わっちゃうんだから、「前キャリアのlocal-partに固執する」という考えにはあまり賛同できません。

"."をlocal-partの先頭または最後に配置、あるいは連続して使用したアドレス(1)

• 携帯電話同士ならともかく、それ以外でのメールのやり取りは全く保証されません。
  • postfixはこのようなアドレスはデフォルトで弾くとのこと。
  • MicrosoftのExchange 2000 ServerとExchange Server 2003のSMTPサービスも、このようなアドレスを持ったメッセージの送受信を拒否していますと明言しています。
  • このようなアドレスが氾濫しているのは日本くらい（だと思われる）ので、海外製のフレームワークを用いると、アドレスのvalidationでひっかかることがあります。（前回の懇親会で金内さんから経験談をお聞きしました。）
  • "hoge.."@docomo.ne.jpのように、""で括って対処するサーバ・サービスもあるようですが。

"."をlocal-partの先頭または最後に配置、あるいは連続して使用したアドレス(2)

• そもそもが形式的にありえないメールアドレスです。
  • そのために、海外のspamのアドレス自動生成ルールから漏れ、結果的にspamが届かないアドレスになるという理論が考えられます。
  • よって、「"."を最後に付けたり連続して使ったりすると迷惑メールがこないんだよー」という理解が広まってしまっている可能性も高いです。身近な友人にも2人ほどそういう理解をしている人がいました。

対処法(1)

• まず、ここまでで説明した点をしっかりと理解しておきましょう。国内特有の問題と仕様の関係を知っているのと知らないのとでは対処コストが大きく違います。
• メールを配信するサービスなら
  • 配信部分にフレームワークを使っているなら、そこからこのドメスティックな問題が発生するかを確認
  • 必ずそのアドレスに配信しなければならないのか、あるいは問題があるアドレスを使用しているユーザには別のアドレスを提供してもらうか、運用の切り替えで対処する。

対処法(2)

• メールアドレスをユーザ登録に用いるサービスなら
  • 登録時のアドレスチェックを厳しくするか、緩くするか？
    • つい先日正規表現：メールアドレスかどうか調べる - phpspotが話題になりましたが、これだと取りこぼしが多くなります。
    • PHPでメールアドレスかどうか調べる方法に書かれているように、PEARのisValidInetAddressを使うのが良い？
    • 他にもre: PHPでメールアドレスかどうか調べる方法 (ハズレ日記)や
    • J0hn D0e の日誌 - PHPでメールアドレスを確認する「正しい方法」(Linux Journal誌の記事より)も参考になるので、後で併せて読むと良いでしょう。
  • もしくは、登録時に確認メールを送信する運用にする。validationに心血を注ぐより、実際のメールレスポンスを以って確認すれば以後のメール送信等も大丈夫でしょう（多分）。

懇親会への伏線

• 今回の内容は、実装経験のない私が理論だけを頼りに話しました。（いいのかな）
• この後の懇親会で、より現場に即した対処法をディスカッションしてはいかがでしょう！
• ただし、懇親会の席上で私に質問をされてもこれ以上突っ込んだことは話せませんので、その辺は実装経験豊富な方々に振った方が良いかも。
• 「次はこんなネタを話してくれ！」というリクエストなら大丈夫です。
• ご静聴ありがとうございました。懇親会では楽しくビーリング！