Slide 1

Slide 1 text

@azumakuniyuki Road to SRE NEXT@京都(懇親会とびいりLT枠) | 07/05(金) マネーフォワードさん SMTP eliability ngeneering R E

Slide 2

Slide 2 text

Road to SRE NEXT@京都(懇親会とびいりLT枠) | 07/05(金) マネーフォワードさん SMTP Reliability Engineering — @azumakuniyuki Road to SRE NEXT@京都(懇親会とびいりLT枠) | 07/05(金) マネーフォワードさん S(MTP) Reliability Engeenering — @azumakuniyuki 自己紹介 @azumakuniyuki Cubicroot Co. Ltd. 2 libsisimai.org nyaan.jp

Slide 3

Slide 3 text

ネコ紹介 3 道綱 「ニャーン」 Road to SRE NEXT@京都(懇親会とびいりLT枠) | 07/05(金) マネーフォワードさん SMTP Reliability Engineering — @azumakuniyuki

Slide 4

Slide 4 text

Road to SRE NEXT@京都(懇親会とびいりLT枠) | 07/05(金) マネーフォワードさん SMTP Reliability Engineering — @azumakuniyuki 4 - SLI = ハードバウンス率 - メールアドレスの到達性(99%以上) - 主にマーケティング系メール - SLI = 送信から着信までの時間 - 配信の即時性(1分以内?) - 主にトランザクション系メール メール配信における信頼性(例)

Slide 5

Slide 5 text

SMTPD4C Road to SRE NEXT@京都(懇親会とびいりLT枠) | 07/05(金) マネーフォワードさん SMTP Reliability Engineering — @azumakuniyuki いとも容易く得られる(わけではない)えげつない信頼性

Slide 6

Slide 6 text

Road to SRE NEXT@京都(懇親会とびいりLT枠) | 07/05(金) マネーフォワードさん SMTP Reliability Engineering — @azumakuniyuki 6 SMTPD4C いとも容易く得られる(わけではない)えげつない信頼性 Domain Authentication Double Opt-in Delivery Don’t Change the Domain Check 1. 2. 3. 4. 5.

Slide 7

Slide 7 text

Road to SRE NEXT@京都(懇親会とびいりLT枠) | 07/05(金) マネーフォワードさん SMTP Reliability Engineering — @azumakuniyuki 7 SMTPD4C いとも容易く得られる(わけではない)えげつない信頼性 Domain Authentication 1. * ドメイン認証をしっかりやる * SPF, DKIM, DMARC * 自社内で転送が発生するならARCも * お金と時間があるならBIMIも * From:ヘッダーのドメイン部分を認証(アライメント) * SPF(Envelope-Fromのドメインと一致するか?) * DKIM(d=の署名ドメインと一致するか?)

Slide 8

Slide 8 text

Road to SRE NEXT@京都(懇親会とびいりLT枠) | 07/05(金) マネーフォワードさん SMTP Reliability Engineering — @azumakuniyuki 8 SMTPD4C いとも容易く得られる(わけではない)えげつない信頼性 Double Opt-in 2. * ダブルオプトイン(必須・義務と考える) * サイトでユーザー自身がメアドを入力 * サイト側は確認のメールを必ず確実に送る * ユーザーはそのメールを * 受信トレイから探す * 無ければ迷惑メールフォルダから探す(救出) * 確実に開いてくる * 本文の確認URLを開いてくれる

Slide 9

Slide 9 text

Road to SRE NEXT@京都(懇親会とびいりLT枠) | 07/05(金) マネーフォワードさん SMTP Reliability Engineering — @azumakuniyuki 9 SMTPD4C いとも容易く得られる(わけではない)えげつない信頼性 Delivery 3. * 健全な配信と内容(Gmailのガイドラインは汎用的) * トラ系とマー系で配信経路を分ける * トランザクション系は多段冗長構成 * 送りすぎない(MTAの速度調整も必要) * 逆に何も送らないのもアドレスの到達性が心配 * 頻度やコンテンツの継続的改善

Slide 10

Slide 10 text

Road to SRE NEXT@京都(懇親会とびいりLT枠) | 07/05(金) マネーフォワードさん SMTP Reliability Engineering — @azumakuniyuki 10 SMTPD4C いとも容易く得られる(わけではない)えげつない信頼性 Don’t Change the Domain 4. * From:のドメインを安易に無闇に変えない * 送信元IPアドレスも同様 * 蓄積した信頼性 * レピュテーションの存在 * ローカルパートも無闇に変えない方が良い * ユーザー定義のフォルダ分けルールから外れる * ドメインを変えざるを得ない状況にならぬように

Slide 11

Slide 11 text

Road to SRE NEXT@京都(懇親会とびいりLT枠) | 07/05(金) マネーフォワードさん SMTP Reliability Engineering — @azumakuniyuki 11 SMTPD4C いとも容易く得られる(わけではない)えげつない信頼性 Check 5. * 定期的な検査や確認 * バウンスした宛先の除外やスパム報告率の注視 * ログイン画面での確認 * 「メアドやけど、これで合ってる?」確認 * サンセットポリシー(組織内での合意形成が難しい) * 活動なし/読まないユーザーには送らない * アカウントの一時停止(Suspend)

Slide 12

Slide 12 text