要約

  • IETFの9月25日の更新は、切替後に修正した8件を列挙した。確認済みの送信者がモデレーションに回る問題、バルクメールの破棄、DMARCによる配送失敗などだ。
  • バウンス処理では旧システムの滞留が表面化した。誤った可能性のあるバウンスを根拠に購読者の無効化が始まると、IETFは処理を止め、対象アドレスを再有効化して修正を待った。

先に出たのは完了の発表だった。IETFは9月11日、新しいメール基盤への移行が完了したと告知した。メールフィルターと書き換え機能のコンテナ分割、Kubernetesによる運用、新しいスパム対策ソフト、証明書処理の改善、バウンス処理の向上を紹介した。完了を伝えるよう見出しと導入部は同日更新されたが、技術説明の大半は8月28日の公開内容のままだった。

これは切替の記録であり、稼働実績の報告ではない。

稼働報告は9月25日に届いた。IETF事務局長のJay Daleyは、問題の大半は解決したとしつつ、修正済みの8件と継続中の2件を示した。新基盤の設計・実装は3年前に委託され、問題が繰り返された後、新たな請負先が完成を引き継いだという。旧作業の中核コンポーネントは書き直されず、そこでの問題も稼働前に検出されなかった。Daleyは「これは私たちのミスだった」と記した。

大規模な停止が一件起きたのではない。メーリングリストと実際の送信者の境界にあった、小さな規則がいくつも破綻した。投稿先リストに加入していなくても送信確認済みのアドレスが、全体の許可リストから漏れ、投稿がモデレーションに回った。Precedence: Bulk のメールは通知なく破棄され、主にIANAからのメールに影響した。BATVの処理も崩れた。確認済みの大文字を含むアドレスが新規扱いされ、再確認を求められた。特殊な送信者向けの規則は呼び出せなくなっていた。Outlookの一部のFrom名は二つに分割され、一方にIETFのドメインが誤って付加された。Postoriusのサイト所有者欄が空だったため、通知には仮の送信元アドレスが使われた。宛先数に関係する条件でDMARCの書き換えに失敗する場合もあった。

事務局長はこの8件を修正済みとした。これは名前の挙がった不具合数であり、失敗した全メールや影響を受けた参加者の数ではない。報告に母数はない。

より難しい問題はバウンス処理にあった。旧基盤には構造上の制約があり、バウンスはリストに届かず処理されていなかった。そのため該当アドレスは無効化されず、「到達不能だが購読中」と説明されるアドレスが滞留した。新しい処理がこの滞留をさばき始めると、リスト管理者に「過剰なバウンスにより購読者を無効化する」という通知が多数届いた。

この時点で、機械には待ち行列と判定があった。判定の信頼性はまだなかった。IETFは一部のバウンスが誤りである証拠があるとした。そこで処理を無効にし、その処理で無効化されたアドレスをすべて再有効化して修正を待った。一時的に、死んでいるかもしれないアドレスを残し、現役の参加者を誤って外す自動処理を避けた。具体的な保護判断であり、滞留が解消したという報告ではない。

同じ更新は別の性能上の驚きも記している。Mailmanの標準VERPモードでメール処理時間が4〜5桁も短くなることが判明し、調査中はVERPが無効化された。比較の基準時間、負荷、絶対的な遅延は示されていない。新しいRspamdも、迷惑メールが多く通過するため調整中だった。

発表の順番には意味がある。9月11日の移行記事は、バウンス処理の改善と迷惑メール機会の減少を期待される効果として示した。9月25日の記録は、期待と稼働証拠の差を明らかにした。新処理は古い滞留と疑わしい信号を表面化させ、迷惑メール判定にも調整が要った。機能を分けた新基盤でも、古いデータの負債は消えない。最初の自動判定が正確になるわけでもない。

共通のメーリングリストに依存する組織には、はっきりした教訓がある。移行完了は日付のある出来事だ。信頼できる投稿配送は、送信者の確認、モデレーション、リストへの展開、アドレス書き換え、認証、バウンス判定、受信まで何度も成立しなければならない。各境界の試験に合格しても、下流でメールが止まることはある。

公開報告から制御判断は読み取れるが、その費用は分からない。再有効化したアドレス数、誤りだったバウンスの割合、処理停止期間、VERPの基準時間、Rspamdの調整完了日は記されていない。これらの数字が分かれば復旧の評価は変わる。いま確実に言えるのは、IETFがバウンスの根拠を信頼できない間は購読者の無効化を止め、その修正を公表したことだ。

出典