実録_マルチテナント環境でのGmailガイドライン対応

Transcript

1. 1 実録 マルチテナント環境での Gmailガイドライン対応 2024.03.15 Ya8 2024 - ヤパチー 令和六年最新版(仮)
2. 2 • セッション対象者 ◦ メールサーバを新規で構築したい⽅ ◦ 既存のメールサーバの運⽤を今後⾏う予定の⽅ ◦ メールサーバを運⽤している⽅ • ゴール ◦ Gmailガイドライン完全理解 ◦ 到達率の⾼いメールサーバの構築ノウハウ(の⼀部)を習得 ◦ マルチテナントでのメールサーバ運⽤完全理解
3. 3 アジェンダ 1. ⾃⼰紹介 2. メールサーバ⼊⾨ 3. Gmailガイドラインのアップデート内容の振り返り 4. サービス紹介 5. 実例紹介 6. マルチテナントでの実例紹介 7. まとめ
4. 4 1. ⾃⼰紹介
5. 技術部プラットフォームグループ 2021年 中途入社 5 自己紹介 渡部 龍一 Watanabe Ryuichi • ロール: SRE • 仙台から来ました • メールサーバ運用歴3年 • 好きなPOP3のコマンド: STAT • @ryuichi_1208
6. EC事業部 エンジニアリングリード 2021年 新卒入社 6 自己紹介 中山 慶祐 Nakayama Keisuke • ロール: Webアプリケーションエンジニア • 所沢から来ました • 職業プログラマ歴3年 • 好きなプログラミング言語: awk • @yammerjp
7. • gurasan ◦ 技術部 プラットフォームグループ ◦ インフラが得意 • yammer ◦ EC事業部 プロダクトチーム ◦ アプリケーションが得意 7 なんで2⼈で登壇するの？ 技術部 ホスティング 事業部 minne事業部 SUZURI事業部 EC事業部 ⼀緒に同じサービスのGmailガイドライン対応をしていた
8. 8 2. メールサーバ⼊⾨
9. 9 イントロダクション 届いた！ メール送信！
10. 10 イントロダクション 届いた！ メール送信！ 間で何が起きてるのかについて説明
11. 11 • MUA (Mail User Agent) ◦ ユーザーがメールを読んだり、作成したり、送信したりするためのインター フェースを 提供するソフトウェア ◦ 例: Microsoft Outlook, Mozilla Thunderbird, Apple Mail, Gmail • MTA (Mail Transport Agent) ◦ メールの転送と配送を担当するソフトウェア ◦ 例: Postfix, Sendmail • MDA (Mail Delivery Agent) ◦ 受信したメールをユーザーのメールボックスに配送するソフトウェア ◦ 例: Dovecot, Courier, Procmail 登場⼈物整理
12. 12 MUA MTA MDA MTA MDA SMTP SMTP MXレコード 問い合わせ DNSサーバ POP/IMAP 宛先: test@exmaple.com 送信元サーバ 送信先サーバ mail box
13. 13 • POP/IMAP ◦ MUAがメールサーバー上のメールにアクセスし、管理するためのプロトコル 登場⼈物整理(プロトコル)
14. 14 • SMTP(Simple Mail Transfer Protocol) ◦ メールを送信するための標準プロトコル ◦ 2つのFromがある ▪ ヘッダーFrom: WebUIやメールクライアントに表⽰ ▪ エンベロープFrom: メールサーバーがメールを送信するために使⽤するもの ◦ 2つある理由 ▪ 転送されたメールが誰から送られたものなのかを分かりやすくする ▪ BCCの機能を実現している 登場⼈物整理(プロトコル)
15. 15 登場⼈物整理(プロトコル) 封筒の外: エンベロープFrom 封筒の中の手紙: ヘッダーFrom
16. 16 MUA MTA MDA MTA MDA SMTP SMTP MXレコード 問い合わせ DNSサーバ POP/IMAP 宛先: test@exmaple.com 送信元サーバ 送信先サーバ mail box
17. 17 3. Gmailガイドラインのアップデート内容の振り返り
18. 18 イントロダクション 2023年10⽉ Gmailのメール送信者ガイドラインがアップデート https://support.google.com/a/answer/81126
19. 19 • フィッシングメールや迷惑メールを無くすためのガイドライン ◦ No Auth, No Entry ▪ 電子メール認証を使用していない場合は、配信しません ◦ 米国Yahoo!メールも同様のガイドラインを適用すると発表 ◦ この条件を満たさないと宛先にメールが届かなくなる ◦ 2024年2月までに一部を除いて対応する必要があった • 送信者の使い方で2段階のガイドライン要件 ◦ Gmailアカウントにメールを送信する送信者全員 ◦ 1日あたり5,000件を超えるメールを送信する送信者 ◦ Google Workspaceは対象外(元々は対象だったけど2023年12月に対象外に) 概要
20. 20 • 対応しないとどうなるか ◦ Gmail/米Yahoo宛のメールが届かなくなる ▪ 2024/02 ~ ごく一部のメールが拒否されるようになる ▪ 2024/04 ~ 段階的にメールの拒否が行われていく ▪ Google: 5.7.26エラー、Yahoo: 5XXエラーとなる ▪ 迷惑メール（スパム）に判定される可能性がある 要件の概要
21. 21 • RFC5322に準拠 • 有効な正引きおよび逆引きDNSレコードの設定 • SPFの設定 • DKIMの設定 • DMARCの設定 • ヘッダFromをGmailになりすまさない 要件の紹介(⼀部)
22. 22 • インターネットメッセージフォーマットに関する標準で、電⼦メールの形式 を定義 ◦ アドレスのlocal-partに使える⽂字数 ◦ メールの1⾏あたりの⽂字数制限 ◦ ヘッダー重複時の取扱い • 今回のガイドラインアップデート前からリジェクトされるケースはあった RFC5322の標準に準拠
23. 23 • 送信元のドメインまたはIPアドレスに有効な正引きおよび逆引きのDNSレ コードが必要 ◦ 正引き ▪ ホスト名に紐づくIPアドレスを関連付けるためのレコード ▪ 「dig google.com」とかで返ってくるレコード ◦ 逆引き ▪ PTRレコード（Pointer Record∕逆引き） ▪ Aレコードの逆で、IPアドレスに紐づくホスト名を定義するレコード ▪ 「dig -x 8.8.8.8」で返ってくるレコード 有効な正引きおよび逆引きDNSレコードの設定
24. 24 • メール送受信において送信者の⾝元の認証として利⽤ ◦ 送信元IPを逆引き ◦ 逆引き結果のドメインで正引きして⼀致するか • スパムに使うサーバは逆引きレコードが正しく設定されていないケースが あるのでそれらのフィルタリングにも役⽴つ 有効な正引きおよび逆引きDNSレコードの設定
25. 25 • 2006年にSPF（RFC 4408）で承認された • メールの送信元ドメインが詐称されていないことを確認する仕組み ◦ ドメイン所有者がDNSにSPFレコードを設定 ◦ 受信サーバーは、受け取ったメールの送信元のエンベロープFromの ドメインのDNSレコードを確認し、SPFレコードを参照 ◦ メールが正当なサーバーから送られてきたものであるか（SPFレコー ドにリストされているIPアドレスから来たものか）を確認 SPFの設定
26. 26 MTA MDA MTA MDA SMTP SMTP example.net SPFレコード 問い合わせ DNSサーバ 送信元サーバ 送信先サーバ 送信元: test@example.net 宛先: test@example.com
27. 27 • 2007年にDKIM（RFC 4871）で承認された • 送信メールに電⼦署名を付与して、なりすましメールでないことを証明 • 送信側は公開鍵と秘密鍵を作成し、公開鍵を DNS で公開 • 署名する⽅式として「作成者署名」と「第三者署名」 ◦ 作成者署名: ヘッダーFromと署名するドメインが⼀致 ◦ 第三者署名: ヘッダーFromとは別のドメインで署名 DKIMの設定
28. 28 MTA MDA MTA MDA SMTP SMTP DNSサーバ 送信元サーバ 送信先サーバ 送信元: test@example.net 宛先: test@example.com example.net DKIMレコード 問い合わせ
29. 29 • SPFレコードが設定されているかつDKIM署名の設定がされているメール サーバーを提供している場合 ◦ 任意のヘッダーFromでメールを送るとSPFもDKIMも正しく設定され ているためになりすましであったとしても受信側は正しいメールと認 識する SPFとDKIMだけだと
30. 30 • 2012年に発表された送信ドメイン認証技術 • SPF, DKIM の認証に fail (失敗) したメールを 受信者にどう扱ってほしいの か伝えることができる • GmailガイドラインではDMARCのPASSに加え以下の要件 ◦ SPFおよびDKIM認証を合格 ◦ 以下のどちらかを満たす必要がある ▪ SPFアライメント: エンベロープFromとヘッダーFromが⼀致すること ▪ DKIMアライメント: ヘッダーFromと署名したドメインが⼀致すること DMARC
31. 31 SPF/DKIM/DMARCの早⾒表 Gmailガイドラインを満たすには？ 
 SPF SPFアライメ ント DKIM DKIMアライメン ト DMARC Gmailガイドライ ン PASS FAIL PASS PASS PASS PASS PASS PASS PASS FAIL PASS PASS PASS PASS PASS PASS PASS PASS
32. 32 • Fromアドレスに「gmail.com」を使⽤して送信しないこと • 2024年２⽉以降はGmailドメインのDMARCはquarantineポリシーを設定 ヘッダーFromをGmailになりすまさない
33. 33 • メールの送信に TLS 接続を使⽤ • 迷惑メール率を0.3%未満に維持する • メッセージにワンクリックの登録解除機能の実装 • ARCヘッダーの追加 その他の要件
34. 34 4. サービス紹介
35. 35 • 国内最⼤級のECサイト作成サービス ◦ 無料で始められる ◦ 流通規模が⼤きくても使える • 2005年にサービス開始 ◦ 現在のショップ数は約4万店舗 ◦ 現在の流通総額は約2000億円 カラーミーショップ
36. 36 • B2B2C & Developer • ホスティングサービス • マルチテナントアーキテクチャ カラーミーショップの特徴
37. 37 特徴: B2B2C & Developer … 送られるメールの種類が多い • ショップオーナー ◦ ECサイト運営機能を提供 • 購⼊者 ◦ ショップオーナーのお客様 ◦ ショップ画⾯やカート画⾯を利⽤ • アプリ開発者 ◦ ECサイト運営のための機能を開発 ◦ Web API連携のアプリストアへ出店 ショップ オーナー 購入者 アプリ 開発者
38. 38 特徴: B2B2C & Developer … 送られるメールの種類が多い 本発表で扱うメールの種類は3つ • EC Webアプリからのメール ◦ 購⼊通知など ◦ ショップオーナー宛と購⼊者宛 • ショップごとのメールアカウント ◦ 購⼊者様との連絡など ◦ メールを送受信できる • ショップごとのマーケティングメール ◦ 販促⽤の、いわゆるメールマガジン ショップ オーナー 購入者 アプリ 開発者
39. 39 • コンテンツホスティング ◦ ショップページの内容や画像 ◦ ショップごとのブログシステム • 独⾃ドメインとDNS ◦ ショップごとにサブドメインを付与 ◦ 独⾃ドメインも利⽤できる • メール ◦ ショップごとにメールアカウントを付与 特徴: ホスティングサービス URL、両⽅アクセスできる https://yammer.shop-pro.jp https://yammer.example メール、両⽅つかえる shop@yammer.shop-pro.jp shop@yammer.example
40. 40 ショップごとに分かれておらず共有 • Webアプリケーション • データベース • メールサーバー 特徴: マルチテナントアーキテクチャ https://speakerdeck.com/kenchan/the-new-architecture-of-colorme-shop-in-the-post-covid-19-world?slide=9
41. 41 5. 実例紹介
42. 42 のまえにおさらい
43. 43 • RFC5322の標準に準拠 • 有効な正引きおよび逆引きDNSレコードの設定 • SPFの設定 • DKIMの設定 • DMARCの設定 • ヘッダFromをGmailになりすまさない 要件の紹介(⼀部) 再掲
44. 44 SMTP DNSサーバ 送信元サーバ 送信先サーバ SPF, DKIM, DMARCのおさらい
45. 45 SMTP 送信元サーバ 送信先サーバ SPF, DKIM, DMARCのおさらい 送信元IPアドレス ヘッダFrom 件名 本文 エンベロープFrom DNSサーバ 受信サーバから見ると がわかる
46. 46 SMTP 送信元サーバ 送信先サーバ SPF, DKIM, DMARCのおさらい 送信元IPアドレス ヘッダFrom 件名 本文 エンベロープFrom DNSサーバ TCP/IPなのでわかる　 なりすましかどうか不明 なりすましかどうか不明
47. 47 SMTP 送信元サーバ 送信先サーバ SPF, DKIM, DMARCのおさらい 送信元IPアドレス ヘッダFrom 件名 本文 エンベロープFrom DNSサーバ TCP/IPなのでわかる　 なりすましかどうか不明 なりすましかどうか不明 DNSレコードの内容を信頼 それをもとに送信者 /送信内容を 確認
48. 送信元サーバ 48 SMTP 送信元サーバ 送信先サーバ SPF … DNSにIPアドレスを公開 送信元IPアドレス ヘッダFrom 件名 本文 エンベロープFrom DNSサーバ passすると、エンベロープFromの ドメインがなりすましでないとわかる TCP/IPなのでわかる　 なりすましでないと判明 なりすましかどうか不明 v=spf1 ip4:192.168.2.0/24 送信元IPアドレスが含まれているか エンベロープFromのドメインの DNSサーバに問い合わせ
49. 送信元サーバ 49 SMTP 送信元サーバ 送信先サーバ SPF&SPFアライメント(DMARC) 送信元IPアドレス ヘッダFrom 件名 本文 エンベロープFrom DNSサーバ passすると、ヘッダFromのドメインが なりすましでないとわかる TCP/IPなのでわかる　 なりすましでないと判明 v=spf1 ip4:192.168.2.0/24 送信元IPアドレスが含まれているか エンベロープFromのドメインの DNSサーバに問い合わせ なりすましでないと判明
50. 送信元サーバ 50 SMTP 送信元サーバ 送信先サーバ DKIM … DNSに公開鍵を公開 送信元IPアドレス ヘッダFrom 件名 本文 DKIM署名 エンベロープFrom DNSサーバ passすると、署名元ドメインが なりすましでないとわかる なりすましかどうか不明 署名検証のため公開鍵を 署名元ドメインの DNSサーバに問い合わせ なりすましでないと判明 v=DMARC1; k=rsa; p=MIIBI…
51. 送信元サーバ 51 SMTP 送信元サーバ 送信先サーバ DKIM&DKIMアライメント(DMARC) 送信元IPアドレス ヘッダFrom 件名 本文 DKIM署名 エンベロープFrom DNSサーバ passすると、ヘッダFromのドメインが なりすましでないとわかる なりすましでないと判明 v=DMARC1; k=rsa; p=MIIBI… 署名検証のため公開鍵を 署名元ドメインの DNSサーバに問い合わせ なりすましでないと判明
52. 52 SPF, DKIM, DMARCすべてにpassする必要がある。つまり • SPF pass & DKIM pass & SPFアライメント(DMARC) pass もしくは • SPF pass & DKIM pass & DKIMアライメント(DMARC) pass Gmailガイドラインに準拠した上で5000通以上送るには
53. 53 5. 実例紹介
54. 54 特徴: B2B2C & Developer … 送られるメールの種類が多い 本発表で扱うメールの種類は3つ • EC Webアプリからのメール ◦ 購⼊通知など ◦ ショップオーナー宛と購⼊者宛 • ショップごとのメールアカウント ◦ 購⼊者様との連絡など ◦ メールを送受信できる • ショップごとのマーケティングメール ◦ 販促⽤の、いわゆるメールマガジン ショップ オーナー 購入者 アプリ 開発者 再掲 ※ちなみに全て、ショップごとのサブドメインや独⾃ドメインで送られることがあります
55. 55 • SPF … pass • DKIM … pass ◦ Postfix + OpenDKIM ◦ 共通のドメインで、第三者署名 • DMARC … SPF アライメントにpass ◦ ⾃社メールサーバーから送信 ◦ エンベロープFromも変更しやすい 実例: EC Webアプリからのメール ショップ オーナー 購入者 アプリ 開発者 ※OpenDKIM … DKIM署名を付与するOSS
56. 56 実例: ショップごとのメールアカウント ショップ オーナー 購入者 アプリ 開発者 • SPF … pass • DKIM … pass ◦ Postfix + OpenDKIM ◦ 共通のドメインで、第三者署名 • DMARC … SPF アライメントにpass ◦ ⾃社メールサーバーから送信 ◦ エンベロープFromも変更しやすい • ARC ◦ 転送設定できるので、OpenARCで設定 ※OpenARC… ARC(リレー時のDMARC等の検証のためのしくみ)署名を付与するOSS
57. 57 実例: ショップごとのマーケティングメール (マルチテナントの醍醐味) ショップ オーナー 購入者 アプリ 開発者 リレー サーバ 実装するのに⼿間がかかる！この後紹介します • SPF … pass • DKIM … pass ◦ Postfix + OpenDKIM ◦ 送信元ドメインで、作成者署名 • DMARC … DKIM アライメントにpass ◦ 外部リレーサーバを利⽤ ◦ エンベロープFromが実質的に変更不可
58. 58 6. マルチテナント特有の実例紹介
59. 59 SMTP DNSサーバ 送信元サーバ 送信先サーバ DKIMの流れ ①RSA鍵ペアを作る ②公開鍵を DNSで公開 ③署名付き メールを送る ④届いたメールの 署名を検証 v=DMARC1; k=rsa; p=MIIBI…
60. 60 SMTP DNSサーバ 送信元サーバ 送信先サーバ DKIMの流れ ①RSA鍵ペアを作る ②公開鍵を DNSで公開 ③署名付き メールを送る ④届いたメールの 署名を検証 v=DMARC1; k=rsa; p=MIIBI…
61. 61 ①RSA鍵ペアを作る ②公開鍵をDNSで公開 ③署名付きメールを送る ④受信メールに付与された署名を検証 DKIM署名の付与と検証のフロー
62. 62 ①RSA鍵ペアを作る ←1つつくる ②公開鍵をDNSで公開 ←1つ公開する ③署名付きメールを送る ←唯⼀の鍵で署名 ④受信メールに付与された署名を検証 DKIM署名の付与と検証のフロー (シングルテナント)
63. 63 ①RSA鍵ペアを作る ←テナントごとに作る ②公開鍵をDNSで公開 ←テナントごとに公開する ③署名付きメールを送る ←テナントごとの鍵で署名 ④受信メールに付与された署名を検証 DKIM署名の付与と検証のフロー (マルチテナント) ※ここでは、テナントごとに異なる鍵で署名することとします
64. 64 SMTP DNSサーバ 送信元サーバ 送信先サーバ DKIMの流れ(シングルテナント) ①RSA鍵ペアを作る ②公開鍵を DNSで公開 ③署名付き メールを送る ④届いたメールの 署名を検証 v=DMARC1; k=rsa; p=MIIBI…
65. 65 SMTP DNSサーバ 送信元サーバ 送信先サーバ DKIMの流れ(マルチテナント) ①RSA鍵ペアを作る ②公開鍵を DNSで公開 ③署名付き メールを送る ④届いたメールの 署名を検証 v=DMARC1; k=rsa; p=MIIBI… ①RSA鍵ペアを作る ①RSA鍵ペアを作る ①RSA鍵ペアを作る ①RSA鍵ペアを作る ①RSA鍵ペアを作る ①RSA鍵ペアを作る ②公開鍵を DNSで公開 ②公開鍵を DNSで公開 ②公開鍵を DNSで公開 ②公開鍵を DNSで公開 ③署名付き メールを送る ③署名付き メールを送る ③署名付き メールを送る ③署名付き メールを送る ③署名付き メールを送る v=DMARC1; k=rsa; p=MIIBI… v=DMARC1; k=rsa; p=MIIBI… v=DMARC1; k=rsa; p=MIIBI… v=DMARC1; k=rsa; p=MIIBI…
66. 66 Ruby標準のOpenSSLライブラリで、RSA鍵ペアを⽣成する 作成した鍵ペアは、MySQLに保存しておく ①RSA鍵ペアを作る require 'openssl' # initialize random seed OpenSSL::Random.seed(File.read("/dev/random", 16)) # 鍵対を生成 rsa = OpenSSL::PKey::RSA.generate(2048)
67. 67 Ruby標準のOpenSSLライブラリで、RSA鍵ペアを⽣成する 作成した鍵ペアは、MySQLに保存しておく ①RSA鍵ペアを作る CREATE TABLE dkim_signing_keys ( id INT AUTO_INCREMENT PRIMARY KEY, domain_name VARCHAR(255) NOT NULL, public_key VARCHAR(255) NOT NULL, private_key VARCHAR(512) NOT NULL, INDEX domain_name_index (domain_name) ); ※実際には複数のテーブルにわけている
68. 68 Route53 (もしくはPowerDNS) のWeb APIを実⾏する ②公開鍵をDNSで公開 client = Aws::Route53::Client.new( region: REGION, access_key_id: access_key_id, secret_access_key: secret_access_key ) client.change_resource_record_sets({ change_batch: { changes: [ { action: "CREATE", resource_record_set: { name: domain, type: "TXT", ttl: 600, resource_records: [ { value: "v=DMARC1; k=rsa; p=MIBI...." }], }, }, ], }, hosted_zone_id: HOSTED_ZONE_ID, })
69. 69 OpenDKIMでは、MySQLを鍵の保存先として利⽤できる 定められたスキーマ上のレコードから秘密鍵を取得し、 メールに署名できる ③MySQLに保存された鍵で署名 https://github.com/trusteddomainproject/OpenDKIM/blob/master/opendkim/README.SQL
70. 70 図にすると
71. 71 SMTP DNSサーバ 送信元サーバ (Postfix & OpenDKIM) ドメインごとのDKIM鍵で署名 ①RSA鍵ペアを作る ②公開鍵を DNSで公開 ③署名付き メールを送る ④届いたメールの 署名を検証 v=DMARC1; k=rsa; p=MIIBI… MySQL Webアプリ (Ruby) ①’RSA鍵ペアを保存 送信先サーバ リレーサーバ SMTP
72. 72 • ドメインの所有者確認をしなければならない • DNSの設定依頼をしなければならない • DNSが設定済みか確認しなければならない → CNAMEを使って解決 補⾜: 外部DNSサーバのドメインの対応 外部DNS サーバ カラーミー ショップ DNS selector._domainkey.extyammer.example selector._domainkey.yammer.shop-pro.jp CNAME
73. 73 SMTP DNSサーバ 送信元サーバ (Postfix & OpenDKIM) ドメインごとのDKIM鍵で署名 ①RSA鍵ペアを作る ②公開鍵を DNSで公開 ③署名付き メールを送る ④届いたメールの 署名を検証 MySQL Webアプリ (Ruby) ①’RSA鍵ペアを保存 送信先サーバ リレーサーバ SMTP v=DMARC1; k=rsa; p=MIIBI…
74. 74 SMTP DNSサーバ 送信元サーバ (Postfix & OpenDKIM) 外部DNSサーバを使う場合 ①RSA鍵ペアを作る ②公開鍵を DNSで公開 ③署名付き メールを送る ④届いたメールの 署名を検証 v=DMARC1; k=rsa; p=MIIBI… MySQL Webアプリ (Ruby) ①’RSA鍵ペアを保存 送信先サーバ リレーサーバ SMTP 外部DNSサーバ CNAME 準備: CNAMEの確認
75. 75 • RSAの2048bit鍵 … 有限時間で解読される可能性がある ◦ ローテーションの頻度: 半年/1年/…etc ◦ リリース時点で⾃動的なローテーション機能は不要だが、すぐに必要になる • DKIMにおける鍵のローテーション … RSAの鍵を交換するしくみ ◦ 1ドメインで複数鍵を同時に扱える「セレクタ」 ▪ 独⾃ドメインのCNAMEは2つ⽤意 ▪ 切り替え時には新旧双⽅の鍵を公開し、署名検証の失敗を防ぐ ◦ スキーマも、鍵とドメインの管理をわけ、中間テーブルで紐づけることとする ▪ OpenDKIMがSELECTする対象はビューでも良い 補⾜: 鍵のローテーション
76. 76 7. まとめ
77. 77 Gmailガイドラインは、⼤⼿受信者の意向 期限も定められており、さまざまなメール送信者が対応に追われただろう 内容⾃体はメールエコシステムの健全化に必要な前向きなものと解釈した 到達性の⾼いメールシステムの運⽤を続けていきたい 細かいところはこのあと直接話しましょう より安⼼してメールを送受信できるように