/var/lib/azumakuniyuki

Sisimaiとか技術的なことはこっちに書いてみようかという試み

トップ > SMTP > SMTP D4C — SRE寄りのメール配信考察

SMTP D4C — SRE寄りのメール配信考察

SMTP

メール配信の継続的信頼性を維持する為に必要な要素をまとめたSMTP D4Cという概念があります。 日本語では「いとも容易く得られる(わけではない)えげつない信頼性」となります。 SMTP D4Cを構成するのはつ次の五要素です。

  1. Domain Authentication (ドメイン認証の徹底)
  2. Double Opt-in (確実なダブルオプトイン)
  3. Delivery (継続的な配信)
  4. Don't Change (配信の安定後は変更しない)
  5. Check & Change (定期的な確認と状況に合わせた変更)

そもそもの背景

京都開催なSREのイベント

Road to SRE NEXT@京都でメール系のLTがあると知り、 近所*1でもあるので、自分はSREではありませんが参加してみることにしました。

直前に「懇親会で飛び入りLTもOK」という案内を聞き、背中を押してもらったこともあり、 自分が喋れるネタでSREに関係しそうなことをスライドにしておくかって事で 「そもそもSREってなんやろ？」から始まり「メール配信における信頼性とは何か？」と考えました。

Dばっかりやん

各要素の単語を列挙していくとドメイン認証とかダブルオプトインとかDから始まるものばかり*2で、 「ん？なんかDが多い？Cが一個あればD4C？」で「SMTP D4C！なんか収まりが良い気がするしググっても何もない、ヨシ！*3」ってことで 数日前に思いついた概念です。

SMTP D4C

ただ、SMTP D4Cを構成する各要素は以前からあるものなので、別に全く新しい概念でも何でもありません。 なんかいい感じ*4にラベルが付いたと言う程度のものです。

speakerdeck.com

偶然にもSMTPはSから始まっているのでSREのSで押し通そうと決意しました。harukiさんがメール技術の話をしはるので 大丈夫、それにメールによる通知や確認・宣伝もサイトを構成する機能の重要な一部やし行ける、大丈夫って確信を持ちました。

「せっかく作ったしスライドも公開しておくか」で出しているのですが、SREについて考えるよい機会でもあったし、スライドでは端折った部分も追加して改定した内容で文章を残しておこうってことで、 この記事を書いていることになります。

なにより、去年の秋から始まった二月動乱*5で新規のお客さんも含む各所から相談をもらって何度も説明している話なので、 適当なラベルのついた概念として纏めておけば自分のアタマにも知見として残りやすいんと違うの？って思惑もあります。

SREとは？

懇親会の飛び入りLTとは言え、SREのイベントなのでSREに絡めた内容であるべきと、 まず「数年前からちょいちょ目にするSREってなんやろな？」でググって最初に出てきた記事を読んでフワッとではありますが理解しました、概念は理解できたと思ってます、たぶん。

品質という単語が目に留まったので「むかし聞いたことあるQCみたいなやつ？」と思いましたが、QCに言及している雰囲気ではありませんでした。 ただ、分野や業種は違えど目指すところは同じであると思いますし、QCのパレート図やヒストグラムを用いる部分はSREにおける可観測性と言えるかなって気がします、たぶん。

メール配信における信頼性

Reliabilityの意味からしてメール配信における信頼性とは何か？と考えた時に普段の業務や二月動乱で求められる基準について思い返しました。

だいたい僕が相談を受けるのは大規模な送信ボリュームであることが多いのですが、送信側と受信側、あるいは少量配信と大量配信、 トランザクション系とマーケティング系など二面性を意識して考えると指標(SLI)や目標(SLO)が異なります、たぶん。

僕はSREではありませんが、メール関係においては経験から得た妥当な指標と達成すべき数値を持っているので、 単にそれを表現する言葉を知らなかっただけで部分的にはSREに相当することをやっていた側面があると言っても過言ではないような気がします。

即時性

初回の登録確認や決済などトランザクション系メールは即時性が求められます。

そもそもインターネットですし電子メールが数秒で来ることを期待するものではありませんが、 現代においてはほぼ瞬時にメールが来ます。受信側も直ぐに来ることを期待しているでしょう。

例えば指標をサイト側での操作完了からユーザー側MXへの送信完了とし、目標は一分以内とします。 さらに一定の期間における即時性が達成できなかった割合を1%以下など継続的な指標と目標を定めるのも良いです。

即時性を指標とするならば、絶対に遅延しないようなメールサーバーが必要になります。 しかし絶対なんてものは無限の予算があっても無理よりの無理なのは自明ですので指標が目標に到達できる水準を維持できるよう、 トランザクション系を捌くメールサーバーを多段構成にするのが妥当でしょう。

可観測性の確保や可視化手段の統一が煩雑なるかも知れませんが、多段構成の最終段階に商用の配信サービスを配置するのも良いですし、 ログの確認や追跡*6が容易であれば一段目から外部の配信サービスでも良いでしょう。

それでも五分、十分待ってもメールが来ないケースはあります。サイトに対するユーザーからの信頼という観点では「10分以内*7 にメールが来ない場合は〜」みたいに考えられる到着までの最大時間を書いておくと、少し遅れてても待つ側の不安を軽減できるかも知れません。

Gmailなどスマートフォンへ通知が飛ぶ場合はメール到達の即時性が強調される

一方で、大量配信するマーケティング系メールは即時性を求められることはほぼ無いと思います。配信開始から数時間以内にキューを捌き切れば良いといったものでしょう。 もちろん速く送って早く終わるに越したことはありませんが、必要以上に速度を求める過程で相手側MTAの負荷となり流量制限や速度超過のエラーを誘発したりして、 継続的な安定配信に影を落とす危険性を考慮すれば、超高速配信を追求するのは危ないかも知れません。

ユーザー(受信者)から見てもマーケティング系メールは自分の操作に関係なく来る、送られてくる日時も読めないものですので、即時性が重要なのはトランザクション系だけであると言えます。

到達性

こちらは送信頻度が高く規模が大きなマーケティング系メールを対象にした指標です。

サイトに登録されている配信可能なメールアドレス全体において、少なくともハードバウンスしない割合を指標とする、といったところでしょうか。 メールアドレスが宛先不明であるとか長期間にわたってMailbox fullであるとか、端的に言えばバウンス率を1%以下で維持する目標です。

現代ではガラケーと呼ばれている携帯電話へのメール配信においては、バウンス率はかなり低い水準を維持しないと直ぐにSMTP接続が拒否されていたので、 経験的に1%以下ならマァ大丈夫*8と考えています。

運営や企画部門など送信側から見ると、サイトに100万ユーザーが登録しているけど、いざ全員にメールを配信してみたら実は50万件しか送れませんでした、 みたいな結果はマーケティング政策においては地獄のような数字でしょう。

大量配信をしているドメインや経由しているメールサーバーの信頼性・評価(レピュテーション)が損なわれると、 即時性が求められるトランザクション系の配信にも悪影響*9が及ぶと考えられます。

これらの指標における目標を達成し、維持するに当たりSMTP D4Cの各要素を継続的に実行し続けることが合理的です。

SMTP D4Cの各要素

ここから本題のSMTP D4Cの話、冒頭で述べた「いとも容易く得られる(わけではない)えげつない信頼性」です。 全てを完璧に実施しても遅延や理不尽なブロック*10 とかDNSBLに載ったとか録でもない事象が発生する可能性はありますが、何もしないと信頼性とは無縁のメール環境となります。

1. Domain Authentication

Gmailの二月動乱で世間での認知度が高まったドメイン認証です。2006年にRFC4408になったSPFを筆頭に、DKIMとDMARCの実装が求められます。 メール送信に使うドメインを取得/設定したら、いの一番に設定すべきです。

加えて送信元となるメールサーバーの逆引き設定と送信時のTLS使用も必要です。更に何処かから来たメールを外部に転送しているならARCも要るでしょう。

そもそもFrom:ヘッダーのドメインを騙ってくるメールが多くて多くて多すぎるので、大量送信者はSPFかDKIMのドメインに一致するかを見るDMARCのアライメントも必須です。 例えばFrom: neko@example.jpなメールの場合は次のいずれかが一致すればDMARCアライメントもPASSします。

  • Return-Path: <postmaster@example.jp>のようにFrom:ヘッダーのドメインと一致している
    • Return-Path:のメールアドレスはSMTPのエンベロープFrom*11で指定されるもの
    • バウンスメールの場合はReturn-Path: <>となっているのでSMTPのEHLOかHELOで指定されるドメインで評価される
    • 当然ながらアライメントの前にSPF単体でPASSしていることが前提
  • DKIM-Signature: ... d=example.jp; ...のようにDKIM署名のドメインとFrom:ヘッダーのドメインが一致している
    • 当然ながらアライメントの前にDKIM単体でPASSしていることが前提

From:ヘッダーのドメインがSPFまたはDKIMの認証で使われたドメインと一致してれば 「From:ヘッダーのドメインは、そのドメインの所有者/管理者しか設定できないはずのDNSで確認の為のレコードが引けて照合できるから、確実ではないけど騙ってないのと違うかな？」 と判断できます。

まだまだ穴がある

「確実ではない」と書いた理由はSPF (やDMARC) を突破する攻撃手法、BreakSPFで述べられているBreakSPFによるSPFの認証が回避可能であるから、です。 よって、SPF単体およびDMARCのSPFアライメントではドメイン認証として不十分・機能しないケースがあるので、いずれ大量送信者でなくともDKIMが必須になると予想されます。

なお、以下のようなFrom:ヘッダーにすればSPFもDKIMも、そして双方のDMARCアライメントもPASSした状態で騙ることが可能です。

Return-Path: <spammer@bulk.example.com>
DKIM-Signature: ...; d=bulk.example.com; ...
From: "prime-failed-info@amazon.co.jp" <spammer@bulk.example.com>
Subject: Amazonプライムの支払いができませんでした

From:ヘッダーの表示名に騙りたいメールアドレスを入れる方法です。 メール技術に詳しい人が良い対策を考えてくれてはると思いますし、bulk.example.comをスパマーのドメインとして認識したり、本文の内容やURLでスパムと判断されていると思いますが、 僕の知る限りでは今の時点でこれを回避する決定的な方法は無さそう*12です。

著名なサービスや企業であればBIMIによる商標登録したアイコンを表示させて*13視認による判断材料を増やすぐらいでしょうか。

2. Double Opt-in

ダブルオプトインについてはメルマガ考察(短文)で書いたので簡潔に言うと 「この先ずっと送るであろうメールアドレスへの最初の一通目であり確実に開いてもらえると期待できるからアカウント開設の仮登録確認メールは確実に送るべし」です。

それと、最初のマーケティング系メールをGmail(とかメールサービス)が評価する時に「なるほど、この前のメールと同じドメインやしユーザーが探して開いてたからスパムではないかな」 と判断してくれる可能性が高くなると推測されるからです。確証はありませんが、僕がGmailに転生したらそういう振る舞いをします。

メールアドレスの高い到達性を維持する第一歩です。

3. Delivery

これは日常の配信、継続的に行うものです。大量配信者でなくとも前述のドメイン認証はしっかり設定した上で、 RFC 5323に準拠したメールを配信するなど気をつけるべき点はたくさんあります。

要点は「コンテンツ・量・頻度ともに適切*14な形で定期的に継続的に送る」です。

Gmailの出している送信者のガイドラインはGmail専用ではなく汎用的な内容になっています。 他のメールサービスも同じような内容・基準でガイドラインを出してくる・遵守を要請してくると予想されますので、いま一度ガイドライン の内容を見返して足りない部分を実装するのは有益であると考えます。

配信そのものに特化して注意点を列挙するなら以下の通りです。

  • ガイドラインおよびRFCを遵守した健全*15な配信
  • トランザクション系とマーケティング系で配信経路を分ける
    • 特にトランザクション系は遅延しないように多段構成による経路の信頼性と着信までの即時性を重視
    • マーケティング系の配信経路で発生したブロックの巻き添えを食らわないように分離しておく
  • 送りすぎない(量的にも速度的にも)
    • 明確に同時接続数が多すぎると言ってくるサービスがある
    • 同様に1セッションで送れる量*16がメールサービスによって異なる
    • 自前のメールサーバーなら宛先MXによる配信速度などの調整が必要
  • 送信速度やキューの滞留状態など観測できるようにしておく
  • ログの設定確認
    • 数百万通/日ぐらいの量でメールを送っているとログが端折られる
    • 全て記録を残すようにしておく

レピュテーション

今から新しいサイトを立ち上げて、オープンから一週間後にメールマガジンを送る計画を立てたとしても、 すべてキレイに配信するのは難しいかもしれません。

理由はドメインのレピュテーションおよびIPアドレスのレピュテーションの存在です。端的に言うと、 過去にメールの配信実績が無いドメインやIPアドレスからのメールは最大限に警戒されて、SMTPの段階で遅延 させられる・拒否される・受け取ってもらえても迷惑メール扱いを受ける可能性が高いからです。

レピュテーション不足から暖機運転をするたとえ話

YAPC::Hiroshima 2024で少し喋ったので 料亭ミケ村にネギを卸すたとえ話でもしましょう。

  • 女将「うちは京料理の料亭ミケ村、最近はネギ料理が人気やしネギの仕入れを増やさなアカンかなぁ」
  • 夏目「こんにちは、最近ご近所で開業しましたキジトラ青果店の夏目と申します。本日はネギを買っていただきたく参りました」
  • 女将「ネギ？ちょうどほしいと思ってたんやけど何本ぐらいあるんです？」
  • 夏目「2000本あります！」
  • 女将「そうやなぁ、今日はとりあえず100本だけもらおうかな」
  • 女将 (なんや知らんお店やし、ネギの品質も分からんとこあるし、いきなり2000本もよう買わんしなぁ)
  • 女将 (もしちゃんとしたネギで美味しかったら次も100本かもうちょい買おうかな)

ネギが美味しい

キジトラ青果店からネギが品質も良くお客さんの評価も良好であれば、次に来た時も同量かもう少し多く買うと判断できます。 メールで言うと良いコンテンツでユーザーもわりとメールを開いているしスパム報告もない状態です。

ネギが不味い

料亭ミケ村の調理場で板前さんがネギの味見をします。不味かったらお客さんには出しません。 店で使えない品質のネギであったなら次にキジトラ青果店が来ても「うちのお客さんには合わへんネギやったわ、ごめんやで」と断ります。 メールで言うとコンテンツが低品質、あるいは明らかにスパム、ユーザーは誰もメールを開かないどころか開かずにスパム報告をする状態です。

レピュテーション(再)

前述のように品質が良く美味いネギを毎日毎日こつこつミケ村さんへ卸すことで、キジトラ青果店のネギは大丈夫と判断されます。 メールの配信においても同様で、暖機運転*17 と呼ばれる地道な努力*18 が要求されます。

そして、継続的に適量*19なメールを送ってないと獲得したドメインとIPアドレスの良いレピュテーションはリセットされると予想されます。 とは言え、土日はメールを送らない、お盆休みの夏休みも年末年始のお正月休みもメールを送らない程度では大丈夫であると推測します。 なんなら一ヶ月ぐらい送らなくてもレピュテーションは変化しない気がします。

しかし一年間まったく何も送らないとレピュテーションは何もない状態(Neutral)に戻るのではないかと考えられます。 このあたりはメールサービスまたは公開レピュテーション毎にリセットの有無や期間が違うと思いますので一概には言えませんが、 サービスの機能としてメールを届けるの��あれば、長期間メールを全く送らないのも良くないのではないかと考えられます。

そして環境の変化に気付かない可能性もあります。長期間メールを送っていないと知らん間にIPアドレスが巻き添えでDNSBLに登録されてた、 メールサービスのガイドラインが強化されててList-Unsubscribeとか実装しないと送ること自体マズいかも？など、 いざ今からメール配信って時に送れない・対応が後手に回るような事態が無いとも限らないからです。

ダブルオプトイン(再)

料亭ミケ村に対してダブルオプトインを実施するならキジトラ青果店はいきなりネギを売りに行かず以下のようにするのが妥当です。

  • 「七月七日、キジトラ青果店オープン！朝四時から営業してます！」ってチラシを入れる
  • 女将さんが買いに来たら「うちのネギ美味いんで付けておきますね」でおまけしておく
  • 料亭ミケ村の調理場でも評判が良かったので翌日キジトラ青果店で100本ぐらい買ってもらえる
  • 「来週から朝ミケ村さんのお店にネギを届けますわ」となる

新しいサイトを開いていずれはメールマガジンも送るのであれば、ダブルオプトインの第一段階で送る仮登録確認メールを使ってレピュテーションを上げていくのも 良いでしょう。集中するとほぼ確実に遅延すると予想されるので「仮登録を受け付けました、一ヶ月以内に本登録ご招待メールを送ります」とでも書いておけば、 サイト側で送信量は制御できるのでメールアドレスと本人の登録意思を確認できるのに加え、送信実績も得られるので一石二鳥と言えます。

4. Don't Change

スライドでは「Don't Change the Domain」と書いたのですが、よーく考えると変えないほうが良いのはドメインだけではないですね。 ここの要点は「安定して配信できるようになったら何も変えるな」です。

  • From:ヘッダーのドメインは変更しない
    • 変更した場合の弊害はメルマガ考察(短文)に書いた料亭ミケ村の話
    • ローカルパートも無闇に変えないほうが良い
  • 送信元IPアドレスも無闇に変えない
  • メールのヘッダー構成や本文の構造も無闇に変えない
  • これらを変える必要が生じたら数ヶ月間の暖機運転をする計画を立てる

送信元IPアドレスを変える場合は暖機運転からやりなおしとなるのは広く知られていると思いますが、 GmailのガイドラインのIncrease sending volume slowly節では メールのヘッダー構造や本文の形式*20を変えた場合も同様であると書かれています。

Increase sending volume slowly
* If you change the format of your bulk emails, gradually increase the sending volume of messages with the new format.
* After making any significant changes to your sending infrastructure or email header structure, increase the modified segment of traffic separately.

5. Check & Change

なんかもうちょっとD4Cの最後にふさわしいCから始まるビシャッとカッコいい単語は無いかと思いましたが、Checkて単語は便利で汎用性があるので。 4のDon't Changeと相反する内容ですが、常の監視・観測で信頼性を維持するために変えていくとなります。

  • 巨大メールサービスにおけるスパム報告率の観測と変更
  • バウンスの発生を観測して送信できない宛先を除外する変更
    • <宣伝> 自前のメールサーバーならうちのSisimaiが活躍できる </宣伝>
    • スパム報告率と同様に高い水準で放置するとSMTP接続が切られるって実害が出る
  • 登録メールアドレスの定期的な確認
    • 「登録してるメールアドレスってこれであってる？変更とかない？」ってログイン画面で出す
    • TwitterやGitHubで見たことある
    • 変っていれば変更を促す
      • 学校の卒業や転職・異動で変る人は変る
  • ユーザーの活動状態の観測と変更
    • サンセットポリシーの策定と適用
    • サイトによって適用する基準の根拠となる変数は多種多様
    • 長期にわたりログインしないユーザーは基準として汎用的かも
      • 「使ってないよね？月末までにログインが無ければアカウント消すで」の確認メール
    • メールを開かない人宛のメールマガジンの配信は止める
      • 開封率とかクリック率で判断できるなら全く読まない人は割り出せる
  • 配信ログの観測と速度や接続数の調整
    • メールサービスの方針変更でブロックされたりする
    • ユーザーの急激な増加に伴う送信メール量の増大
      • 送信量を減らすとかMTAを増やすとか送信速度を調整するとか妥当な変更が必要

あとは定期的にDKIMの鍵を交換したりSPFレコードに列挙したIPアドレスの棚卸しってのも必要な観測と変更ですね。

以上のようにSMTP D4Cとラベルを付けたので信頼性の継続的な維持に必要な要素は何であったか覚えやすくなったような気がします、たぶん。 他にもあると思いますがD4Cで収まりが良いので仮に後で何かを見つけてもDのどれか、またはCに突っ込みます。

なお、僕の書いてるメール系の記事では推量表現が多いのですが、対象がメールサービスで内部仕様 *21は公開されず、 日々の配信で得られる個々の事情から「こうなんちゃうの？」と帰納的推論しかできないためです。 メール担当者はみんなそうやと思います。

それに何よりそもそも、SMTP D4Cをビシャっと継続的に実施した結果えげつない信頼性を得たとしても、 不可抗力な外的要因で信頼性が崩れたり維持が困難*22 になることもあると思います。それでも「実施しない・対策しない」という選択肢は無いでしょう。

改めてメール(多種多様な宛先を相手にするSMTP)はわりと難しいんと違うかなぁって気がします。

SLA

SREの話に絡めて書いているとは言え、SLIとSLOまで出してるのにSLAを出していないんですよね、この記事で。

メール配信については多種多様なメールサービスを連続的に、または断続的に相手にするので不確実な要素が多いと思います。 加えて配信後にメールが開かれたかどうか？も完全に追跡できないのでやはり不確定要素が多く、また数日前に始めてSREについて調べて考えて未だ僕の理解が浅いこともあってか、 SLAとして宣言するには難しそうな気がします、たぶん。

Road to SRE NEXT@京都

単語だけで存在は知っていたSREについて考える切っ掛けとなったRoad to SRE NEXT@京都は SREとして活躍する先達の話が聞けて良かったですし、懇親会でご馳走になったビールとピザも美味しかったですし、運営の方や参加者の方といろいろお話ができてとても良いイベントでした。

会場スポンサーのマネーフォワードさん、運営スタッフの皆さん、参加者の皆さんありがとうございました。

まさか七月に二回もブログを書くとは思ってなかったので前回と同じセリフですが、暑中お見舞い申し上げます。

*1:マネーフォワードさんの京都開発拠点

*2:Domain Auth., Double Opt-in, Delivery, Don't Change the Domain

*3:指差し動作は省略

*4:自分ではそう思ってる

*5:去年の秋から始まるGmailの送信者ガイドラインにまつわる一連の騒動を個人的にそう呼んでる

*6:メールが来ないんですけど？って問い合わせが来たら少なくともログを確認する必要がある

*7:99.9%以上は1分以内に送れるとしてもSLAで1分と書くには不確定要素が多いと思う

*8:Amazon SESとかが求めるバウンス率はもう少し緩かったと記憶しています

*9:同じドメイン名という理由で拒否されるとか流量制限を食らうとか

*10:実際のところ八割ぐらいは送信側の不備や見落としに起因するけど初動の段階では理不尽なブロックという印象を持つ傾向にある

*11:SMTP> MAIL FROM: postmaster@example.jp

*12:どこかで議論されてるとかあれば教えてください

*13:当然ながらメールクライアントがBIMIに対応している必要がある

*14:まぁその適切ってのが曖昧でフワッとしているから苦労する

*15:適切とか健全とかフワッとしている・難しい

*16:前に調べた時は米国Yahoo!が20通程度/1SMTPセッションやった

*17:量にもよるけど経験的に毎日2倍にしていくのはかなり性急な暖機運転かも？と思ってる

*18:これの全く逆を行くのがスパマーで金曜日の夕方にVPSを借りて月曜日の営業開始時間ギリギリまでVPSをフル回転させスパムを送るという手段があった

*19:料理のレシピでも出てくる適量・ある程度の経験値が無いと分量の見当がつかない

*20:おそらくtext/plainからtext/htmlへの変更など大きなものと予想される

*21:具体的な数値を付けて公開するとスパム送信者に大きなヒントを与えるし

*22:二月動乱に関係して見ると今まで送信者が雑すぎた・Gmailが緩すぎた/黙認してたって見方もある