要約

  • IETFは2026年9月11日22時UTCから、ietf.org、iab.org、irtf.org、rfc-editor.orgのメールサービスを新基盤へ移す。配送は最大60分遅れ、Mailman3のWeb画面は停止する予定だが、アーカイブとIMAPは利用可能とされる。
  • 新設計では、受理、保管、確認、解放、アドレス書換え、DKIM署名、DANE認証、送信キュー、アーカイブが別々の責任になる。ある処理の成功を終端配送の証拠にしてはならない。

8月28日のIETF発表は、単なる保守時間の告知ではない。機能ごとのコンテナ、専用Kubernetesクラスタ、milterによる接続、Rspamdへの変更、アドレス書換え機能、DANE証明書管理、そしてコンテナの外に置く複数の送信VMまで示している。

この構成では「メールサービスは稼働中」という一語が意味を失う。過去のアーカイブを読めても新規投稿は保管中かもしれない。Mailman3の管理画面が落ちてもIMAPは応答できる。クラスタ内の全Podが正常でも、送信VMのキューは増え得る。可用性には必ず観測対象を付けなければならない。

2024年の停止記事とは異なる出来事

BTWには、2024年8月のIETFメール停止を扱った記事がある。Amazon SESへの主要送信経路の移行、SPF準備、短時間の停止、回収できないメールの可能性を扱った記録であり、そのまま公開されるべきだ。

2025年2月の告知は、その段階では基礎的な処理はほぼ変わらず、現代的なクラウド機能の利用は後の作業だと説明していた。2026年の移行はその後段に当たる。postconfirmを全面的に作り直し、フィルタ、書換え、証明書、スケジューリング、送信経路の責任を分ける。

したがって今回の問いは停止時間ではない。メッセージを誰が持ち、誰が変え、誰の証拠で次へ進むかである。

入口の成功と投稿の解放を分ける

公開リポジトリのpostconfirmは、宛先が確認を要求するかを判断し、既知の送信者状態を調べる。未知の送信者なら原文を保存し、確認メールを出す。正しい応答を受けると状態をacceptへ変え、保存したメールを再投入する。

状態にはunknown、confirm、accept、reject、discard、expiredがある。rejectはSMTPクライアントに拒否を伝える。discardは成功を返しながら配送しない場合がある。確認経路では保存してから入口処理を終了する。この差は利用者に見える結果と内部保管を分離する。

監査には少なくとも三つの記録が必要だ。入口が何を返したか、どのバイト列をどの理由で保管したか、いつ再投入または削除したかである。承認DBの更新だけでは保存物の解放を証明しない。2xxだけではリスト掲載を証明しない。

READMEの既定値は本番設定ではない。実際のTTL、purge周期、DB構成、デプロイcommitは発表されていない。移行後に稼働設定とログから確認すべき項目である。

確認応答が証明する範囲も狭い。IETFはこれをNote Wellへの同意と結び付ける。対象メールボックスをこの手順に必要な程度に操作できることは示せるが、法的身元、所属組織の代理権、投稿内容の真実性までは示さない。

Fromを書き換えても作者は移らない

メーリングリストは自分の設備から再配送する。元ドメインのSPFがIETFのIPを許可していないことがあり、リストによる変更で元のDKIM署名が壊れることもある。厳格なDMARCの下では、正当な投稿でも拒否される。

新しい書換えmilterはSPFとDMARCを確認する。IETFの送信IPが元のSPFに含まれなければ、envelope FromをIETF管理のdmarc.*ドメイン上の可逆アドレスへ置き換える。DMARCがquarantineまたはrejectなら、読者が見るheader Fromも同様に変える。その上でIETF側の適切なドメインでDKIM署名する。

RFC 9989は、この回避策が現在のリスト運用で定着していることを認める。書換えは整合する送信主体を作るが、元の作者を置き換えない。RFC 6376のDKIMも、署名ドメインが指定部分に責任を持つ証拠であって、人の本人性、確認応答、未署名項目、最終配送の証明ではない。

受信時の作者アドレス、送信時のenvelope/header、適用したポリシー、マッピングの世代と鮮度、DKIM domain/selectorを同時に残す必要がある。書換え後のFromだけが残れば、アーカイブは「IETFが再送した」と「IETFが書いた」を区別できなくなる。

DANEのロールオーバーは時間を含む

発表は証明書を「現行＋次の組」で管理すると述べる。RFC 7672では、新証明書を使う前に新旧を覆うTLSAを公開し、古いDNSキャッシュが失効する時間を置く。必須DANEでTLSAと証明書が一致しなければ、未認証経路へ落とさず配送を遅延させる。

証明書作成ジョブの成功だけでは足りない。TLSA公開、DNSSEC、TTL、各endpointが提示する証明書、外部からのhandshake、キュー年齢を一緒に見る。9月11日の結果はまだ存在せず、全外部送信者がDANEを強制するという証拠もない。

独立したプロセスには共通のメッセージ台帳が要る

機能別スケールは有効だが、段階的更新中にreplicaの設定がずれる。DBが一方からだけ遅いこともある。Podの再生成は処理能力を戻すが、直前の判断根拠まで復元するとは限らない。

送信VMはさらに別の障害領域である。IPごとに評判や制限が異なり、フィルタ完了後も相手側でdeferされる。RFC 5321のSMTPはhopごとに責任を移すstore-and-forwardであり、作者から読者までの原子commitではない。

オープンリレーの可能性を除くという目標はRFC 2505の原則に合う。しかし、fresh/expired/missing/forgedな書換えmappingで負のテストをしなければ、目標は結果にならない。

アーカイブとIMAPは重要な証人だが、配送台帳ではない。確認待ちメールはまだ掲載されず、掲載済みでも一部購読者への配送は失敗し得る。入口応答、保存hash、確認、解放またはpurge、書換え、署名、list展開、archive entry、送信queue、相手SMTP、bounceを一つのcorrelationで結ぶ必要がある。変換でバイトが変わるため、hashには必ず段階名を付ける。

Running-Code Primacyが求めるのは、計画ではなく実行証拠である。データ主権の実務は、保管コピー、承認DB、ログ、鍵、DNS、Pod、VM、アーカイブに実際の管理権が分散することを示す。最小初期仕様と局所的な将来判断は境界を守る。SMTP、DKIM、DMARC、DANEは共通意味を与えるが、各運用者は自分の実装とinterfaceの結果だけに責任を持つ。

モジュール化が責任を薄めるのではなく、責任を測れる単位にすることが、この移行の成功条件である。