要約
- IETFは2026年9月11日にメールサービスを移行する予定で、最大60分の配送遅延とMailmanのウェブ画面停止を見込む。移行前の現時点では、これは計画と予想であって実績ではない。
- 新規送信者が確認に応答すると、postconfirmは保管したメールをメールシステムへ戻せる。この記録はローカルな条件の成立を示すだけで、リスト受理、正しい書換え、署名、DANE通信、購読者への到着を証明しない。
移行中に初めて投稿する人を考える。メールはpostconfirmに保管され、確認要求が送られる。返答が届くと送信者の状態が変わり、保管メールは再投入される。ここで保管キューが一件減った。
だが、その一件はMailmanの前で待っているかもしれない。書換え規則で止まったかもしれない。署名後に外向きリレーの一台へ偏っているかもしれない。キューから出た事実は、次のキューに入った事実ではない。
IETFの8月28日の告知は、IETF、IAB、IRTF、RFC Editorの各ドメインを対象に、9月11日22時UTCから移行するとしている。Mailman3のウェブ画面は停止し、アーカイブとIMAPは影響を受けない予定だ。最大一時間の遅延も運用上の見込みであり、切替え後の測定値ではない。
保管責任はサービスごとに移る
機能はKubernetes上のコンテナに分離され、milterで連携する。外向きメールだけは複数の仮想マシンから中継される。postconfirm、Rspamd、アドレス書換え、DKIM、DANE証明書、バウンス処理には、それぞれ別の証拠境界がある。
postconfirmの公開リポジトリによれば、未知の送信者のメールは確認中に保存される。確認が成立すると送信者をacceptにし、保存メールを再投入する。同じ説明はrejectとdiscardも区別する。後者はSMTPクライアントに成功を返しながら捨てる場合がある。したがって「SMTP成功」には、発行した機能、処理種別、対象メールの指紋が必要だ。
保管時刻、期限、確認状態、解放試行、再投入の受領を同じ指紋で照合する。件数だけでは、正常な移動、期限切れ、重複再投入、説明できない消失を区別できない。
書換え後の送信者は、新しい主張である
メーリングリストは元のドメインがSPFで認めていない基盤から再配信することがある。告知ではSPFとDMARCを調べ、必要な場合にEnvelope FromやHeader Fromを書き換え、適切なドメインでDKIM署名する。
SPFは送信ホストとドメインの公開方針を照合する。DKIMは選択された正規化対象をドメイン鍵で検証し、個人まで確認できない署名者も想定する。DMARCは識別子整合と受信方針を結ぶが、紛らわしいドメインや表示名の詐欺まで解決しない。
そこで、元の識別子、分岐理由、書換え後の識別子、署名ドメインとselector、対象フィールド、受信側の検証結果を残す。有効なIETF管理ドメインの署名は、署名後の形に対する責任を示す。元の人間の身元や権限を遡って証明するものではない。
次の証明書を置いただけではロールオーバーにならない
current + next 3 1 1方式は、更新中もDANEで使える証明書を維持するためのものだ。danebotにはcurrentとnextを分ける処理が見える。これは準備の証拠として重要だ。
一方、SMTP向けDANEの結果は、送信MTAがDNSSEC検証済みMX/TLSAを使い、次ホップのTLSを認証した時に生まれる。RFCは全SMTPを守るとは述べず、downgrade耐性をDNSSECに依存する。予定した鍵、外部resolverが見たTLSA、実際に提示した証明書、旧新両状態の接続成功を分けて観測しなければならない。
250は責任の始点であり、読了の証拠ではない
SMTPではDATA後の250 OKを返した受信側が、配送または中継の責任を引き受ける。強い約束だが最終結果ではない。配送状態通知のdeliveredはメーリングリスト展開器への配送を含み、読まれたことを示さない。relayedとexpandedも別の意味を持つ。
入口MTA、postconfirm、リスト管理、書換え、署名、外向きリレー、受信MTA、試験用メールボックスを別の証人として扱う。バウンスがないことも配送証明ではない。Podがhealthyでも次段の待ち時間は分からない。
Heng Luの現実レイヤーは、設定、局所状態、プロトコル受理、外部効果を混ぜない。動くコードの優先は、実際に状態を変えられる境界での観測を要求する。実務上のデータ支配を持つのは、キューを読み、識別子を書き換え、鍵を交換し、保管メールを戻せる側だ。
移行の成功は、すべての局所成功が同じメール指紋でつながった時に初めて示せる。チャレンジ成功は、その鎖の最初の受領証にすぎない。
出典
- https://www.ietf.org/blog/email-service-tranistion-2026-09/
- https://www.ietf.org/blog/email-service-transition-2025-02/
- https://github.com/ietf-tools/postconfirm
- https://github.com/ietf-tools/container-rewriter
- https://github.com/ietf-tools/danebot
- https://docs.rspamd.com/
- https://www.postfix.org/MILTER_README.html
- https://docs.mailman3.org/projects/mailman/en/latest/
- https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
- https://www.rfc-editor.org/rfc/rfc5321.html
- https://www.rfc-editor.org/rfc/rfc6376.html
- https://www.rfc-editor.org/rfc/rfc7208.html
- https://www.rfc-editor.org/rfc/rfc7489.html
- https://www.rfc-editor.org/rfc/rfc7672.html
- https://www.rfc-editor.org/rfc/rfc3464.html
- https://www.rfc-editor.org/rfc/rfc6698.html
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/on-data-sovereignty-technical-vs-practical-realities/
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
