要約

  • RFC 3974 は、IPv4だけの副MXがメールを受理しても、IPv6だけの主MXへ転送できない構成を示した。MX優先度は候補を並べるが、MX間の経路を作らない。
  • DNS応答、TCP接続、SMTP受理、キュー、内部中継、最終メールボックス到着は別々の受領証だった。

冗長化が外から正しく見えるほど、その次の断線は見落とされやすい。RFC 3974 の例では主MXがIPv6専用で、低優先度MXがIPv4専用だった。IPv4送信者は副MXへ到達できる。ところが副MXは主MXへ到達できない。

MXレコードは優先度とホスト名を与える。送信MTAは候補を並べ、アドレスを解決し、配送を試す。IESG注記は完全なアルゴリズムの権威が RFC 2821 にあると強調した。RFC 3974 はInformationalで新プロトコルを定義せず、後に RFC 5321 がRFC 2821を置き換えた。

優先順位は中継網ではない

送信者から選択MXへの経路と、受理MXから最終保管先への経路は別物だ。同じDNS回答に二つの名前が載っても、共通アドレス族やトンネルは生まれない。最も簡単な修復は主MXのデュアルスタック化だったが、UUCP、変換器、共有ストレージも選べた。要件は、受理した全メッセージを受信者のメール保管先へ運ぶことだった。

この仕組みは RFC 974、RFC 1123、RFC 1035 のDNS、RFC 3596 のAAAAに連なる。同じIN MX空間が両アドレス族を扱っても、優先度は受理後の到達性を表さない。

RFC 3974 はDNSの失敗も分けた。NODATAは有効な名前にMXがなく、暗黙MXへ進む。NXDOMAINはドメイン不在で恒久失敗となる。SERVFAILは一時失敗で再試行する。当時、壊れたDNSがAAAA問い合わせへSERVFAILを返し、メールがキューに残る例があった。RFC 4074 は後にこの誤動作を記録した。SERVFAILはAAAA不在の証明ではない。

アドレス取得後も段階は続く。同一MX優先度内でAとAAAAを並べ、TCP 25へ接続する。接続成功はSMTP開始にすぎない。一時応答、恒久エラー、成功受理は別の遷移を生む。成功受理も、そのMTAへの引き渡しであって主MXや最終保管への到着ではない。

RFC 7505 は後にNull MXを定義し、RFC 3463 と IANA表 は状態を整理した。RFC 6724 と RFC 8305 は後世の選択・接続文脈であり、2005年の普及率を測る資料ではない。

RFC Editor記録、errata、Datatracker が示すのは文書履歴で、障害件数ではない。

運用ではDNS応答、選択アドレス、TCP、SMTP返信、キューID、次の中継、最終格納を個別に追う。外部SMTP監視が緑でも、内部区間は赤になり得る。副MXの受理は物語の終わりではなく、受信ドメインの責任が始まった証拠である。

この区別は障害対応の順序も変える。副MXのポートが開き、テストメッセージに成功応答が返っても、そこで調査を終えてはいけない。副MXが生成したキュー記録と、次の中継が受け取った記録を対応させ、最後に受信者側ストレージの記録へ結び付ける必要がある。どこか一つの対応が欠ければ、観測できたのはその直前までの段階に限られる。

また、優先度の数字が小さい主MXは「最終保管先」を自動的に意味しない。RFC 3974 の例では運用設計がそこへ集約するため内部経路が問題になった。別のサイトが共有保管や他の搬送方式を使うなら、証明すべき経路も変わる。DNS表から内部アーキテクチャを推測せず、受信ドメインが実際に選んだ責任移転点を確認することが重要である。

情報源