要約

  • 1994年8月、Experimentalとして公開されたRFC 1664は、X.400とRFC 822のアドレスを対応付ける表をゲートウェイへ配布するDNSのPXレコードを提案した。
  • PXはアドレス対応の情報である。SMTPの経路選択にはMXが使われ、RFCや少数の試験記録はメールの到達や広範な導入を証明しない。

小規模な試験から見えた課題

RFC 1664の著者の一部は、それ以前に .it のPTRレコードへ対応表を格納し、少数の試験アプリケーションで有用な結果を得たと報告している。ここから確認できるのは限定された実験までだ。インターネット全体に普及した、あるいは継続運用されたという証拠ではない。

X.400とRFC 822では、同じ宛先でもアドレスの構造と表記が異なる。ゲートウェイが一方を他方へ変換するには、どの部分が対応するのかを示す規則が要る。RFC 1327はその広い枠組みを定めていたが、各ゲートウェイにある表をどう配布し、整合させるかは別の運用課題だった。

RFC 1664はその配布先としてDNSを使い、新しい資源レコードPX（タイプコード26）を提案した。優先度と二つのアドレス形式を含む対応データを公開し、ゲートウェイが検索して変換に使う設計である。DNSは規則を渡し、実際の変換はゲートウェイが行う。

PXとMXを混同すると提案の意味が変わる。RFC 1664はSMTPのメール経路にMXを使うと説明し、PXはアドレス対応を補う情報だと位置付ける。PXは次のSMTPサーバーを指定せず、メール本文を運ばず、相手側が受け取ったことも示さない。変換の後にメールを配送する処理は別に残る。

新しいレコードを使うには、DNSの名前サーバーを対応させる必要があった。RFCはサーバー環境の多様さから導入に時間がかかると見込む。また、X.400の名前空間を段階的に分散する案にも触れるが、これは計画の説明であり、完了した展開の記録ではない。RFC 1664自身もExperimentalで、インターネット標準ではないと明記する。RFC 2163は1998年にMIXER向けの提案でこれを廃止した。後続仕様の存在は技術的な継承を示すが、PXの普及率は示さない。RFC 1649が求めたゲートウェイ間の世界規模の表の整合と調整も、要件であって達成の証明ではない。

出典