要約

  • TXT の id は再取得の合図であって、ポリシー本文でも署名でもない。全送信者の取得完了を証明せず、未期限の旧キャッシュを一斉に失効させない。各送信者が実際に適用するのは、HTTPS で認証し、取得時刻と max_age を持つ特定の本文である。
  • 再現可能な判断には、ポリシードメイン、DNS 応答、ポリシーホスト証明書、本文ハッシュ、キャッシュ履歴、MX 順序、STARTTLS、MX 証明書、キュー再試行、最終処分が要る。enforce は一つの SMTP 経路を制限するだけで、到達、エンドツーエンド秘密性、利用者本人性や取引権限を証明しない。

二つの送信者が違う判断をしても矛盾ではない

冒頭は障害報告ではなく境界試験である。Aは新しい ID を見て mta-sts.<domain> を認証し、新本文を取得した。予備 MX は許可リストに入った。Bは更新できなかったが、非失効の旧ポリシーを持つ。RFC 8461 は、ライブ DNS や HTTPS が失敗したからといって、その有効なキャッシュを捨てるよう求めない。むしろ適用を続ける。

旧本文に予備 MX がなければ、Bは候補を無効として一時保留する。逆に、TXT を見ても本文を初回取得できず、有効キャッシュもない送信者は、MTA-STS 未導入として配送を続ける。この違いは受信側の現行ページだけでは復元できない。

監査の問いは「今のファイルは何か」では足りない。「その試行時、送信者はどの認証済みバイト列を、どの期限まで適用する資格があったか」である。

id は内容ではなく更新通知である

_mta-sts.<policy-domain> の TXT はバージョンとインスタンス ID を持つ。IANA 登録は語彙を揃えるが、個別レコードや実装の正しさを保証しない。ID は本文のダイジェストではなく、mode、mx、max_age を結び付けない。

そのため順序が安全性を変える。本文だけ変えて ID を据え置けば、送信者は旧キャッシュを期限まで使う。ID を先に変えれば、新本文が全エッジへ届く前に旧本文を再取得し、新しい寿命を与える送信者が出る。現在の TXT だけを保存する監視は、適用事実ではなく公開意図を保存している。

HTTPS 取得で初めて一つの規則集合になる

本文はポリシーホスト mta-sts.<policy-domain> の固定パス /.well-known/mta-sts.txt に置かれる。送信者はポリシーホスト名を SNI に入れ、期間内で、その名前に一致し、自分が信頼するルートへ連鎖する証明書を検証する。

取得した本文には version、mode、max_age、そして none 以外では一つ以上の mx がある。証拠として必要なのは解析後の有効フラグだけではない。応答バイト、ハッシュ、Content-Type、取得時刻、証明書チェーン、ホスト名判定、信頼ストア世代、解析値と失効時刻を残す。

初回取得の弱点も明確だ。TXT が見えても HTTPS が失敗し、キャッシュがなければ、送信者は未導入として動く。MTA-STS は一度認証取得した後の更新妨害に強くなるが、署名されていない DNS の不在を認証済み事実には変えない。

max_age は送信者ごとの時計である

寿命は各送信者の成功取得時刻から始まる。世界共通の締切ではない。地域 DNS、HTTPS 到達性、プロセス再起動、キャッシュ複製、先行更新の差が、同じ本文に異なる失効時刻を作る。

この分散は耐妨害性の源であり、設定ミスを長生きさせる源でもある。更新失敗でキャッシュを捨てれば、ポリシーホストを遮断するだけで enforce を解除できる。長い誤設定を一度取得すれば、受信側が見える状態を直しても送信側では効き続ける。

撤去は mode: none を短い寿命で公開し、ID を変え、過去に配布した最長寿命が重なり終わるまで待ってから TXT と HTTPS を外す。先に削除することは失効操作ではなく、解除手段を消す行為になり得る。

MX と証明書の組だけが検証対象になる

送信 MTA は通常の優先順位で MX をたどる。候補名は適用中の mx パターンに一致しなければならない。ワイルドカードは左端一ラベルだけであり、apex や二階層を含まない。その後 STARTTLS を提示し、SMTP SNI の MX 名に一致する有効な PKIX 証明書を返す必要がある。

成功が示すのは、ある送信者が許可された次ホップへ認証 TLS で到達したことだけだ。メール作成者、受信利用者、本文の安全性、後続中継の秘密性は対象外である。

不適合 MX は一時的に到達不能な候補のように扱い、通常の順序を壊さない。予備 MX の漏れは主系が健全な間は隠れ、障害時に初めて表面化する。主系だけの確認は failover の証明ではない。

キュー遷移が影響を決める

enforce は不適合ホストへの送信を禁じるが、即時の永久エラーを許す言葉ではない。永久失敗にする前に、新しいポリシー ID がないか DNS を確認し、それ以外は SMTP の一時失敗と再試行を使う。

保留は修復時間を残し、永久エラーは取引を閉じる。したがってキュー ID、適用ハッシュと期限、候補順、失敗理由、次回時刻、最終 ID 確認、最終処分が必要になる。TLS ログだけでは配送結果を説明できない。

TLSRPT は集団観測である

RFC 8460 は、検出したポリシー、成功・失敗数、証明書や STARTTLS の故障を集約して伝える。Google と Microsoft の資料は、実際の製品に送信時検証と報告面があることを示す。

ただし報告は参加送信者と到達したレポートの範囲に限られる。日次集計は一通の受領証ではない。読了、保存、全中継での秘密性、業務処理を証明しない。

受信側公開、送信側執行、報告側観測を照合して初めて状況が見える。どれか一つを真実の唯一の所在にしてはならない。

DANE と REQUIRETLS を混ぜない

SMTP DANE は DNSSEC と TLSA による別の経路である。DANE 検証が失敗したとき、MTA-STS の PKIX 成功で上書きしてはならない。

REQUIRETLS はメッセージごとの発信者要求であり、対応中継を通じて運ばれる。MTA-STS は受信ドメインの方針を対応送信者が適用する仕組みで、個別メールの機密度を表さない。いずれも SMTP 区間の TLS から内容のエンドツーエンド暗号化を作り出さない。

「MTA-STS pass」を、送信者の秘密指定、受信完了、利用者本人、取引承認へ拡張してはならない。実装が制御した地点で証明を止める。

再実行できる判断記録

一件の記録は、ポリシードメイン、送信者、試行、時刻を主キーにする。TXT バイトと ID、TTL、DNSSEC 状態、HTTPS 本文と証明書、ポリシーハッシュと期限、MX RRset と順序、SMTP SNI、STARTTLS、証明書結果、DANE、キュー、再取得、最終 ID 確認、TLSRPT、処分を結ぶ。

本文だけ変更、ID の先行、HTTPS 遮断、キャッシュ有無と失効、主系停止、誤った二種類の証明書、none 撤去、DANE 失敗後の迂回を canary にする。公開は提案、認証取得は限定ルール、キャッシュはローカル寿命、SMTP とキューは実際の結果である。

出典