要約

  • RFC 9873 は、RFC 5733 の基本メールを残したまま ASCII または SMTPUTF8 の追加アドレスを一つ扱い、追加側を主経路として指定できる。
  • セッションでの拡張合意は処理能力の証拠であり、メールボックスの存在、最終配送、返信者の本人性、RDAP 公開を証明しない。

境界はセッション開始時に現れる。RFC 5730 の greeting と login で、双方は利用する拡張を提示する。RFC 9873 を合意した場合、追加アドレスを受理、検証、保存、返却し、メールの送受信では SMTPUTF8 を支える。合意しなければ、拡張された contact データを提供も返却もしてはならない。

これは弱い証拠ではない。EPP 相互運用性については明確だ。ただし、証拠の射程が短い。DNS の配送経路、メールボックス作成、転送設定、SMTP 受理後の最終配送、閲覧、返信は別の系で起きる。

RFC 5733 の基本メールは残り、拡張はもう一つの ASCII または SMTPUTF8 アドレスを加える。任意の primary 属性は処理上の優先を示すだけで、基本値を消さない。空要素は更新時の解除、照会時の不在を表し、空のまま主指定することはできない。この状態機械にも配送試験は含まれない。

二つの経路は非対称にもなり得る。一方宛てのメールが他方へ転送され、返信が別のアドレスや文字体系から戻る場合がある。文字列が違うことだけで別人とは言えず、同じ連絡先レコードにあることだけで同一人物とも言えない。

国際化は保存試験を重要にする。RFC 6530 は国際化メールの枠組みを、RFC 6531 は SMTP 拡張を定める。RFC 9873 はローカル部の文字範囲を制御し、ドメインを IDNA2008 に合わせ、結合文字列を含む往復保存を試すよう勧める。RFC 5895 は UI 側のマッピングに関係し、IANA IDNA 表 はコードポイントの登録状態を示す。見た目の近さは同一性ではない。

開示には一つのルールが通る。基本メールの disclose 設定は追加メールにも適用しなければならない。一方、EPP 保存値を公開面にどう投影するかは別の判断だ。追加アドレスは RDAP で扱われ得るが、STD 95 は保存値の無条件な逐語公開を命じない。ICANN の 2026 年コミュニケーションフォーム勧告 は仮名化アドレスやフォームの政策文脈であり、RFC 9873 の採用実績ではない。

Heng Lu の現実レイヤー論で並べると、合意能力、設定値、正規化、保存、開示、SMTP 試行、輸送結果、受信者行動、公開投影は別々の事実になる。最小初期仕様は狭い共通契約を支持し、実行コードの優先は各境界に再現可能な記録を求める。

RFC 9873 は到達性を保証する規格ではない。第二経路を誤魔化さずに記述する規格である。主指定を検証済み表示へ、SMTP 受理を通知完了へ変換した瞬間に、その慎重さが失われる。

出典