要約

  • RFC 5335 の実験モデルは、非 ASCII メールボックスに ASCII の代替アドレスを添えられた。経路が必要な機能を持たないと、格下げ処理は代替先を使えたが、両者が別のメールボックスや別人に届く可能性を RFC 自身が認めていた。
  • RFC 5504 の Downgraded-* は変換の痕跡を残しても、アドレス対の権限を認証しなかった。RFC 6530 は未認証の対応付け、実装間の相互運用問題、長期的な複雑さを実験結果として記録し、標準化版から経路途中の格下げを外した。

ログに書ける事実と、ログでは決められない事実

あるメールの最終形に Downgraded-To がある。元の国際化アドレスと、ASCII 化された現在の宛先が記録されている。運用者はそこから、途中で変換が起きたらしいと分かる。

分からないことも多い。誰が二つのアドレスを結び付けたのか。本人は承認したのか。承認は今も有効か。ASCII 側は同じ受信箱なのか。別の部署や共有箱へ転送されないか。フィールドを挿入したシステム自体は信頼できるか。

操作の provenance と操作の authority は別である。前者は「どのような変更を観測したか」を支える。後者は「その変更を誰が許可できたか」を支える。RFC 5335 と RFC 5504 の組み合わせは前者を増やしたが、後者を自動的には作らなかった。

この区別は Lu Heng のノートにある、帳簿と支配権を分ける考え方にも通じる。記録を保管する役割は重要である。しかし記録が存在するからといって、その管理者が記録対象の本人を置き換える権限まで得るわけではない。

二つのアドレスは同じ構文に入っても同じ主体にならない

RFC 5335 はメールヘッダーの値に UTF-8 を直接使えるようにしつつ、フィールド名は ASCII のままにした。国際化メールボックスには、任意の全 ASCII 代替アドレスを添えられた。対応していない経路に備えるための設計である。

だが、メールアドレスの local-part は表示名ではない。受信ドメインが解釈する識別子である。人名をローマ字に変換しても同じアカウントになるとは限らない。昔の別名は再割り当てされ得る。別ドメインの代替先は別事業者の管理下にあるかもしれない。

RFC 5335 のセキュリティ節は、この弱点を明記した。ASCII と非 ASCII の二つは、異なるメールボックス、さらには異なる人へ届き得る。どちらが選ばれるかは MTA の能力に左右され得る。同じ送信意図でも経路構成が変われば受取人まで変わる可能性があった。

したがって、ALT-ADDRESS は単なる文字列ではなく、検証を要する主張である。主張者、本人確認、適用範囲、作成時点、再確認期限、失効方法、現在の配送先を結び付けなければならない。これらを持たない対応表は、便利な候補であって本人同一性の証拠ではない。

経路の能力不足は別人を選ぶ委任状ではない

RFC 5504 の手順では、非 ASCII の envelope path と ALT-ADDRESS があれば、格下げ時に ASCII 側へ置き換えられた。代替アドレスのドメインが元と違う場合、現在の SMTP 接続をそのまま使えるとは限らない。新しいドメインを解決し、別の接続へ向かう必要があった。

ここで変更されるのは表記だけではない。配送責任を持つ組織、保存場所、フィルタリング、法域、アクセス主体まで変わり得る。

それでも発火条件は「次のサーバーが必要な機能を広告していない」という狭い観測である。サーバーは自分が扱えない形式を拒める。それだけで送信者の意図する人物を変更する権限は得ない。

正しい対応は、その観測から出せる範囲に結論を止めることだ。対応経路を探す。送信側の管理下にある提出システムへ戻す。明示的に失敗する。既に本人が検証した代替関係を送信側が持つなら、そこで限定的に適用する。途中の中継が自身の制約を根拠に identity policy を作ってはならない。

Downgraded-* にも独自の信頼境界があった

変換前の値を別フィールドに保存する発想は、何も残さないよりはるかに良い。障害解析や表示判断に材料を与えるからだ。しかし新しいフィールドは新しい攻撃面でもある。

悪意ある送信者が似たフィールドを最初から入れる可能性がある。受信者は、どの MTA がいつ追加したかを別の証拠で確かめる必要がある。格下げアルゴリズムによっては情報が失われ、元の形を完全に復元できない。ヘッダーの書換えは署名対象のバイト列も変え得る。

複数宛先ではさらに制約が増える。元の受信者アドレスを共有ヘッダーへ書けば、他の受信者に漏れる。RFC 5504 はその場合の Downgraded-Rcpt-To を禁止した。プライバシーを守る正しい制限だが、最終メッセージだけでは経路を再構成できない場合が生じる。

必要なのは証拠の階層である。メッセージ内フィールドは自己記述。制御された MTA ログは実行記録。アドレス対の登録は関連主張。本人の確認は権限証拠。SMTP の成功応答は受入れ証拠。人間の受領や行動はさらに後の結果である。

失敗を隠す互換性は継続性ではない

ASCII 側がメッセージを受理すれば、配達率は上がる。バウンスは減る。互換性機能は成果を出したように見える。

しかし元の本人に届かなければ、改善されたのは transport metric だけである。共有箱、古い別名、退職者の再割当アドレスへ届いた秘密は取り戻せない。アカウント回復や承認依頼では、誤った成功が明示的な失敗より危険になる。

運用画面は単一の緑色を避けるべきだ。元の宛先、能力不足を観測した hop、変換を許可した主体、実際の代替先、ドメイン変更、結び付きの検証状態、SMTP 受入れ、メールボックス配置を別々に示す必要がある。

実験の結論は橋を残すことではなかった

RFC 5335 は 2008 年の Experimental 仕様であり、2012 年に RFC 6532 が置き換えた。RFC 6530 は、初期設計が非 ASCII アドレスに全 ASCII の等価先を伴わせ、経路途中で格下げできるようにしたと振り返る。そして、その対応付けは認証できず、初期実装は相互運用問題を起こし、要件と長期的影響が複雑すぎたと結論付けた。

標準化版は経路途中の格下げを削除した。RFC 6532 は transport が保証する 8-bit-clean 環境で、UTF-8 ヘッダーを端から端まで扱う。SMTP では SMTPUTF8 が必要である。古い 7-bit 経路を別アドレスで通過できるとは約束しない。

これは実験が失敗したという単純な話ではない。実験が、文字変換に見えた機能の内部に、認証・権限・プライバシー・署名・経路・監査という複数の制度を発見した話である。

現代の別名、回復先、アカウント統合にも同じ原則が要る。関連付けは同一性ではない。同一性の主張は認可ではない。受入れは元の本人への到達ではない。変換前に結び付きを認証し、変換時に選択を記録し、証明できなければ見える形で止める。それが互換性を権限内に戻す。

情報源