Upgrade to Pro — share decks privately, control downloads, hide ads and more …

透過型SMTPプロキシによる送信メールの可観測性向上 / Improved observabi...

linyows
January 17, 2024

透過型SMTPプロキシによる送信メールの可観測性向上 / Improved observability of outgoing emails with transparent smtp proxy

さくらの夕べ in 福岡 Jun 17, 2024 で使用した資料です。

linyows

January 17, 2024
Tweet

More Decks by linyows

Other Decks in Programming

Transcript

  1. Tomohisa Oda — さくらインターネット研究所 Software Engineer @さくらの 夕 べ in

    福岡 Jun 1 7 , 2 0 2 4 透過型SMTPプロキシによる送信メールの 可観測性向上
  2. https://tomohisaoda.com • 福岡在住 🍜 • A ffi liation: さくらインターネッ ト、COGNANO

    • Community: Fukuoka.go主催 • Weight Trainingとテニスが趣味 Tomohisa Oda / @linyows
  3. メールにおけるセキュリティの問題 • メールの送信者は正しいか? • メールに盗聴や改ざんはされていな いか? • 自 分のフリをしてメールを送られて いないか?

    • 送信ドメイン認証(SPF、DKIM、 DMARC) • 経路暗号化(TLS、MTA-STS) • 転送対応(SRS、ARC) GmailやOutlook使っていれば何も考え(ry
  4. メールに対する信頼性の低下 メールInboxは未読で溢れていませんか? • メール配信が安価なマーケティングツールとなっていて、 大 量の広告メールが メールInboxを占有している • 利 用

    しているサービスがセキュリティインシデントにより 自 分のメールアド レスが流出しており、 大 量のスパムメールが着信する • そもそも、Instagram、X、Slack、LINEといったSNSやメッセージングプラ ットフォームで 生 活しているのでメールに問題があっても問題とは思わない
  5. メールホスティングの事情(送信のみ) • ドメイン単位にIPv 4 を割り振ることはできな いため、メール送信に使 用 するIPは集約したい • とはいえ、集約しすぎるとIPスロットリングの

    影響範囲が 大 きくなる • メール送信キューも集約しすぎると滞留時に影 響範囲が 大 きくなり運 用 が 大 変になる • つまり、メールキューは分散しIPは適切な分量 に集約するのが良い example.com example.jp example.org example.net example.us example.gov xxx.xxx.xxx.xxx yyy.yyy.yyy.yyy example.com example.jp example.org example.com example.jp example.org
  6. 分散MTAの可観測性が低い • MTAが出 力 するログを集約しパースすることによってメールシステム全体で 何が起きているか把握出来るようにはなる • しかしシステムで何が起きていたかを確認することはできても、リアルタイム に問題を検知して修復することは難しい •

    例えばIPスロットリングが発 生 していることを検知し、発 生 の引き 金 となっ たドメインの送信を 止 め、送信に使うIPを付け替えるといった運 用 の 自 動化 などを 行 える環境にしたい
  7. • 透過プロキシなのでメールキュー はコンテナ側で管理し、ルーティ ングだけを変える • SMTPプロトコルレベルでDBに 通信情報蓄積し何が発 生 している かリアルタイムで検知できるよう

    にする • 同 一 ホストのためコンテナのMTA とプロキシ間はTLSを使わない コンテナホストごとに透過プロキシを導 入 する xxx.xxx.xxx.xxx example.com example.jp example.org example.net example.us example.gov Proxy DB
  8. 透過型SMTP送信プロキシ: WARP https://github.com/linyows/warp • 一 般的なSMTPプロキシで送信 用 に使えるものはないためGoで 自 作

    • MTAプロセスからの25番宛先のパケットをiptablesでDNATし、本当の宛先を システムコールから取り出して使っている • 相 手 MXからのEHLOレスポンスに含まれるSTARTTLSを削除してMTAに返却 しプロキシは相 手 MXとTLS接続する • フックイベントを作っているのでプラグインから処理追加が可能 • カナリアリリースで本番導 入 検証済み
  9. 検証環境での事例:1, 2 SMTPセッション数10で100通を 大手 メールサービス宛に送る実験 1 . 同時最 大 接続数制限に引っかかった

    4 5 1 4 . 7 . 6 5 2 The mail server [xxx.xxx.xxx.xxx] has exceeded the maximum number of connections. 2 . レピュテーションの低さから受信拒否の判断をされた 5 5 0 - 5 . 7 . 1 [xxx.xxx.xxx.xxx] Our system has detected that this message is likely suspicious due to the very low reputation of the sending domain. To best protect our users from spam, the message has been blocked.
  10. 謝辞: 本研究は JSPS科研費20K 1 1 7 9 1 「軽量コンテナによる 大

    規模 高 集積メールホスティング基盤における送信機能の 高 機能化」の 助成を受けたものです。