メールアドレス vs 俺たち

メールアドレス vs 俺たち

Our stand against the challenges posed by E-mail addresses

pixiv Inc.

USAMI Kenta

2024-01-12 Sapporo Community Plaza

PHPカンファレンス北海道2024 前夜祭

お前誰よ

• うさみけんた (@tadsan) / Zonu.EXE / にゃんだーすわん
• ピクシブ株式会社 pixiv事業本部 Webエンジニアリングチーム PHPer
• 2012年末から現職でPHPを書いているWebプログラマ
• Emacs PHP Modeを開発しています (2017年-)
• プログラミング言語にちょっとこだわりのある素人 (spcamp2010)
• 2011年頃にPython札幌というコミュニティをやっていました

今回のお題

出典: Wikipedia： ID (2023-07-09T09:38:16版)

出典: Wikipedia： デジタルアイデンティティ ( 2023-10-20T14:01:45版)

今回はIDとは何か(本質)の話には深入りしません

おことわり

発表者は現時点において現職のID設計判断や実装に関わっていません！

ID、Auth、アカウント基盤などAAA(Authentication,Authorization, Accounting)は高度な専門技術領域

発表のねらい

今回のゴール

• ただメールアドレスを扱うだけのよくある仕組みだとしても、考慮事項がいくつもあってシンプルな実装では済まない(こともある)こと
• これらの考慮事項には唯一の正解はなく、ビジネス要件やユーザーのニーズに応じて取捨選択する必要があるということを理解し、必要十分なものを設計・実装できること

ゴールではないこと

• メールアドレスに関係しないアカウント設計の考慮事項
• こう実装すれば間違いないという指針を提示すること
• デジタルアイデンティティを完全理解してIDエキスパートになること
• オブジェクト指向設計についてマスターすること
• 今回提示することをそのまま実装するとユニットテストしにくい構造になる場合があるので、適切に依存を分割・注入することは読者への課題とする

今回は専門職ではない我々が実装するためのお話をします

初心者の方も怖がらずにお聞きください

さて

難しいことは置いておいてユーザーからメールアドレスを収集したい(せざるを得ない)ことは現代でも多い

メールアドレスを何に使うか

• マーケティング (メールによる告知など)
• Webサービスのログイン機能のIDとして
• Laravelのようなフレームワークは基本機能として持っていて、スキャッフォールド(コードの自動生成)で最低限のものは簡単に作れる(生成されるので実装の必要すらない)

• ログイン通知 (心あたりのないログインでないかユーザ自身に知らせる)

メールアドレスを何に使うか

• アカウント登録させてマーケティングに活用…
• 利用規約に同意させた上なら問題はないが、やりすぎは嫌われるので要注意
• メールマガジンなど送りすぎてフィルタリングされてしまっては、本当に大事な連絡が届かなくなるのはよくない
• 個人的な意見では、私信のような体裁や「あなただけ特別に…」のような文言のキャンペーンメールは非常にストレスが大きい

個人的感情はおいといて

DBに入れるだけだしフレームワークとか要らん

ですよね？[要出典]

すごくシンプルなログインシステムを作っていきましょう

[要件1]変な形式の文字列が登録できないこと

aaa@example,com

example.com

ググったら最適解が出てくる良い時代…

良くなかった時代とは

どういうこと？

そもそもメールアドレスとは

tadsan@pixiv.com

"tadsan"@pixiv.com

<tadsan@pixiv.com>

USAMI Kenta <tadsan@pixiv.com>

どれも「メールアドレス」

出典: Wikipedia： メールアドレス (2023-11-07T03:00:31版)

メールアドレスとは

• 特に断りがなければ tadsan@pixiv.com のような文字列を指す
• RFC 5322ではaddr-specと呼ばれるもの
• USAMI Kenta <tadsan@pixiv.com> のような、名前や <> を含んだものもメールアドレス
• 先述のブログで「正規表現でマッチできない」と言われているのはこれを含めたメールアドレスのこと

出典: Wikipedia： メールアドレス (2023-11-07T03:00:31版)

一般的なメールアドレスを収集する用途でaddr-spec以外が必要になることはない

基本的にaddr-specだけを相手にすればいいとわかった

改めて

ローカルパートドメイン名

tadsan@pixiv.com

ローカルパートの制約

• dot-atom形式 (いわゆる普通のメールアドレス)
• ASCIIの英数文字 [a-zA-Z0-9]
• ASCIIの記号 ! # $ % & ' * + - / = ? ^ _ ` { | } ~
• . (ドット)は先頭と末尾以外に使用できるが、2個以上連続できない
• 大文字小文字は区別する… が… 現実には区別せずに扱うサービスも
• むしろ多数

RFC違反メールアドレス

• 2009年頃まで一部の携帯キャリアで発行できていたメールアドレス
• good..by..@example.com のようなアドレスが発行できた
• 仕様違反のメールアドレスでも動作するサービスが存在していたが…
• 2020年にiOS 14、2021年にSendGridで利用不可能に
• quoted-string形式 "good..by.."@example.com に変換すれば合法だが、残念なことに受信側のメールサービスが対応している必要がある

PHPではこれを使えば安全！

…ここまでに説明した範囲では

[要件2]存在しないドメインのメールアドレス登録を弾きたい

a@b.c

filter_var('a@b.c',FILTER_VALIDATE_EMAIL)

filter_var('a@b.c',FILTER_VALIDATE_EMAIL)// => "a@b.c"

定石：入力されたアドレスに送信してメール内のコードを入力させる

実メール送る前にどうしても確認したいのだとしましょう

DNSをチェックしよう

この方法で良いといえば良いだめといえばだめ

(非常に言葉を濁す)

メールはどうやって届くのか

• 白ヤギさんと黒ヤギさんが… という話から始めると15分では無理
• メールに関係するDNSレコードにはAとMXがある
• メール配送の仕組みとしてはAレコードがあればいいのだが、今日の多くはメールアドレスのドメイン部分に対応したMXレコードがある
• Aレコードしかないメールアドレスは個人や小規模なメールサーバの独自運用されている傾向にあるのでAレコードもサポートするかは各自判断

DNSではなくSMTPでチェックする別解もあるが…

(僕は運用経験がないので言葉を濁す)

ついでにメールアドレス

IPアドレス

a@0.0.0.0

filter_var('a@0.0.0.0',FILTER_VALIDATE_EMAIL)

filter_var('a@0.0.0.0',FILTER_VALIDATE_EMAIL)// => "a@0.0.0.0"

ドメインがIP

[要件3]メールアドレスの重複登録を弾きたい！

DBに登録

ユニークキー制約

大勝利

かと思いましたか？

ローカルパートの制約

• dot-atom形式 (いわゆる普通のメールアドレス)
• ASCIIの英数文字 [a-zA-Z0-9]
• ASCIIの記号 ! # $ % & ' * + - / = ? ^ _ ` { | } ~
• . (ドット)は先頭と末尾以外に使用できるが、2個以上連続できない
• 大文字小文字は区別する… が… 現実には区別せずに扱うサービスも
• むしろ多数

a@example.com

A@example.com

同一かもしれないし別人かもしれない

unicode_ciは大文字小文字を同一視する

utf8mb4_binで厳密チェックすればいいのか？

もっとひどい穴を簡単に作れるのでbinで比較はやめた方がいいと思う

Laravelは全部小文字のアドレスのみ許可(これが無難)

この問題を騙り尽すには15分枠はあまりに短い…

Gmailエイリアス沼

• 同じメールアカウントに対応するアドレスはたくさんある
• fafnir127@gmail.com, fafnir127+alias@gmail.com
• f.a.f.n.i.r.1.2.7@gmail.com, fafnir127@googlemail.com
• これらはGoogle Workspaceを使った独自ドメインのメールでも有効

ご静聴ありがとうございました