要約

  • IETFはメール機能をモジュール化したが、9月25日の報告にはアドレス状態、送信者の互換性、バウンス、迷惑メール判定に関する不具合が記録された。
  • IETFは500を超えるメーリングリストで大半の活動を行うと説明している。初回送信者の確認は、Note Wellへの同意確認も兼ねる。

サーバーを切り替えれば、メール移行は完了と発表できる。難しいのは、旧サービスの周囲に長年積み重なった利用者、メッセージ、例外が、新しいサービスでも通るかどうかだ。IETFの9月の移行は、その違いを具体的に示している。

IETFは9月11日、ietf.org、iab.org、irtf.org、rfc-editor.orgと各メーリングリストに提供するメール基盤の移行完了を発表した。新基盤は機能ごとにコンテナを分け、専用のKubernetesクラスターでスケジュールし、milterインターフェースで連携させる。送信メールは複数の仮想マシンを経由する別経路を取る。IETFによれば、この設計は機能ごとの水平拡張を可能にし、保守や更新を容易にする。旧ソフトウェアは複雑化し、運用と更新が難しくなっていた。

メールの各機能を分けるのには理由がある。迷惑メール検査、送信者確認、アドレス書き換え、証明書管理、リスト配信では負荷も制御ルールも異なる。モジュール化すれば、一部の変更がサービス全体に及ぶ範囲を抑えられる。一方で、機能間の境界がより重要になる。処理の並び替えによって、以前は有効だったルールに到達できなくなったり、違う段階で適用されたりする可能性がある。

メーリングリストは付随サービスではない。IETFは500を超えるリストを運営し、その大半で作業が行われていると説明する。多くのリストは購読と投稿を公開し、アーカイブも公開しているが、一部には制限がある。初回送信者へのチャレンジ確認は迷惑メール対策であると同時に、新しいアドレスの利用者がNote Wellを受け入れたことを確認する仕組みだ。つまりメールの経路は、誰が参加できるか、投稿が受理されるか、公開記録に残るかという手続きにも関わる。

9月11日の告知では、移行中もリストのアーカイブとIMAPアクセスを維持するとされた。これは対象サービスの継続計画を示すもので、切り替え後にあらゆるメッセージ形式が正常に処理された証明ではない。9月25日、IETF事務局長は移行後に問題が発生し、その大半は解決したと報告し、修正済みの8件と継続中の2件を挙げた。

修正のいくつかは、見落としやすい状態の違いに関するものだった。確認済みでも特定リストに未購読のアドレスが全体許可リストから漏れ、その投稿が保留された。大文字を含むアドレスは新規扱いとなり、再確認を求められた。珍しくても従来は受け付けていた送信形式が、互換処理ルールへ到達できず拒否または改変された。ほかにも、一括送信の識別情報、バウンス用アドレスのタグ、名前とメールアドレスの特殊な書式、ウェブ画面の所有者設定、リスト配信時のDMARC書き換えに問題があった。

これらは一種類の不具合ではない。アドレスの本人性、リスト購読、ヘッダー、送信者認証、モデレーション、通知の境界に分散していた。標準的なメッセージがメインキューに入ることだけを確認しても足りない。送信者確認済みでも未購読の人がいる。一般的でない形式でも正当な送信はある。ドメインのポリシーによって配信方法が変わることもある。それぞれ別の経路を通る。

もっとも示唆的なのはバウンス処理だった。事務局長によると、新システムは、到達不能になっても購読状態が残っているアドレスの滞留を表面化させた。旧基盤の構造的な制約により、そのバウンスはリストに届かず処理されていなかった。また、一部の新たなバウンス判定が誤っている可能性も報告された。調査中、IETFは自動処理を停止し、無効化されていたアドレスを再有効化した。

これは「新しい基盤が新たな障害を作った」という単純な説明では済まない。新基盤は、旧基盤が見えないままにしていた状態を明らかにし、同時に新しいバウンス処理自体も検証を要した。見通しのよいシステムは、静かに蓄積した運用上の負債を発見させる。しかし、見えるようになった後も、自動ルールが実際には到達可能な購読者を誤って無効化することはあり得る。安全な対応には、処理を止め、対象アドレスを戻し、根拠を確認してから再開できることが必要だ。

同じ報告は性能面の相互作用も記録した。バウンスを個別の宛先に結び付けるVERPは、処理時間を4〜5桁増加させたとして、調査中は無効化された。新しい迷惑メール判定も調整中だった。これらは全体的な処理能力不足を示すものではない。ただし、実効性能はコンテナのスケジューラーだけでなく、処理経路全体によって決まることを示している。

9月25日の報告は日付のある運用状況であり、それ以降の状態を示すものではない。標準化作業が止まった、特定の提案が失われた、移行全体が失敗したという証拠もない。資料から言えるのはより限定的なことだ。切り替え日の告知だけでは、長年のアドレス状態、送信習慣、バウンスのケースが正しく扱われた証明にはならない。

RFC 3935は、IETFの標準化を参加者の技術的判断と、仕様を実装・展開した現場経験の組み合わせと説明する。この考え方は、標準を運ぶシステムにも当てはまる。設計として筋の通ったアーキテクチャでも、人、アドレス、メッセージがアクセスと記録を失わずに通過して初めて、運用上の証明になる。

出典