要約

  • RFC 821 では、送信側がメールボックスの前にリレー順を記し、各リレーが自分の名を往路から取り除いて復路へ移した。
  • RFC 1123 は通常の配送を普遍的なドメイン名と DNS MX に委ねた。受信側は旧構文を受け取れても、中間経路を捨てて最終ドメインを使えた。
  • 現行 SMTP では、構文の認識、リレー許可、経路の実行は別判断である。旧形式を読めることは、中継を許すことでも、その通り運ぶ約束でもない。

同じ宛先を受け取った三つのサーバー

クライアントが次の受信者を送る。

RCPT TO:<[リレー alpha、リレー beta]:[gamma ドメインの user メールボックス]>

gamma ドメインの user メールボックスが絶対的な宛先であり、コロンより前は希望するリレー列である。現代のサーバーは二つを正しく分解できる。それでも処理結果は一つに決まらない。

あるサーバーは列を除去し、gamma.example の配送先を調べる。別のサーバーはリレー自体を拒む。限定された障害調査を行うサーバーなら、明示的に経路を採用して alpha.example へ先に接続することもある。差を生むのは文法ではなく、現在の運用権限である。

古い入力を誤読しないことと、古い入力にネットワークを選ばせることは別だ。SMTP の変遷は、その二つを切り離した。

かつて経路は封筒の中で移動した

RFC 822 は、絶対アドレスの前に任意の route を置く route-addr を定義した。送信者が通過させたいホストや伝送サービスを並べる部分であり、メールボックス名そのものとは区別されていた。

RFC 821 はこの区別を SMTP 封筒で実行した。標準例ではリレー ONE と TWO が THREE ドメインの JOE メールボックスより前に並び、メールボックスが住所、ONE と TWO が行程だった。

指定されたリレーへ到着すると、そのサーバーは forward-path から自分の識別子を外し、reverse-path の先頭へ加え、今度は SMTP 送信者となって次のホストへ接続する。未消化の往路は短くなり、障害通知に使える復路は長くなる。配送の進行と、それまでの中継履歴を一つの変換で表そうとした仕組みだった。

ただし、サーバーはリレー作業を拒否できた。名前を列挙しただけで第三者サーバーを使う資格が生まれたわけではない。さらに RFC 821 は、この経路が MAIL FROM と RCPT TO の封筒情報であり、メッセージの To、From、CC に現れる必要はないとした。輸送経路と著者が書いた宛先表示は最初から別層だった。

長く使える名前が、短命な行程表に代わった

1989 年の RFC 1123 は、送信 SMTP に明示的なソースルート形式を生成しないよう求めた。理由は明快だった。インターネットメールはソースルーティングより普遍的な命名を選んだ。SMTP が接続性を担い、DNS が場所に依存しない世界的な名前を提供し、MX が従来リレー列を必要とした主要場面を扱う。

リレーそのものは残った。変わったのは選択者である。送信者は最終ドメインを示し、そのドメインが交換先を DNS に公開し、各サーバーが現時点の認可と到達性に基づいて次を選ぶ。構成変更は DNS 側で吸収でき、すべての送信者が古い中継リストを書き換える必要がない。

メールボックス名は継続的な参照になり、昨日のトポロジーは配送インフラの管理対象になった。これは表記の短縮ではなく、制御主体の変更である。

受理される構文、取り除かれる指示

RFC 1123 は旧形式を構文エラーにしなかった。受信 SMTP は明示ルート構文を受け入れなければならない。ただし旧来のリレー機能を実装しない場合、メールボックスの最終ドメインへ直接配送を試みるべきだとした。標準例ではリレー ALPHA と BETA を外し、JOE のメールボックスを GAMMA ドメインへ直接向ける。

RFC 2821 は境界をさらに明示した。受信側はソースルートを認識するが、通常はそれを剥がし、最初から存在しなかったようにメールボックスのドメインを使う。経路名を reverse-path へコピーしてもならない。昔の記号を見つけたというだけで、RFC 821 の復路生成まで復活させることはできない。

解析を捨てれば、古いクライアントを壊したり、区切りを local-part のデータと誤認したりする。解析結果を自動実行すれば、現在のポリシーが認めない中間サーバーを旧トークンに選ばせる。理解は相互運用性を守り、非服従は信頼境界を守る。

現行規格が残すのは例外の手順

RFC 5321 は現在も、カンマ区切りのドメイン列である A-d-l を規範文法に含める。注記は三つの性質を並べる。この形式は受け入れなければならず、生成すべきではなく、無視すべきである。

サーバーはリレー提供を断れるし、ルート付きアドレスを拒否できる。列を無視して最終ドメインへ送ってもよい。一方、明示的に経路を使うなら、最初に書かれたドメインへ必ず送り、勝手な近道を選んではならない。廃止方向の機能にも、実行するときの意味は残る。

移行上の落とし穴もある。最終ドメインに DNS で有効でない名を書き、中間リレーが理解してくれることを前提にした送信者がいた。準拠サーバーがルートを捨てると、その依存は失敗する。文字列が文法的に正しくても、成功を支えた古い解決モデルまでは保証されない。

深刻な一時障害の回避やデバッグは、なお例外的な理由になり得る。だが実行権限はサーバーの明示ポリシーから生じる。クライアントがホスト名を並べるだけで得られるものではない。

ヘッダー側に残った別の化石

RFC 5322 は、メッセージヘッダーの route を旧式アドレス文法へ移し、解釈時には無視すべきだとしている。アーカイブの古いメールを読めても、そこに残る句読点を生きた SMTP 命令へ変えないためである。

ヘッダーの route は、実際の封筒受信者も通過リレーも証明しない。実行経路を知るには、SMTP 取引、接続結果、Received トレースを別に見る必要がある。

情報源と限界

RFC 821、RFC 822、RFC 1123、RFC 2821、RFC 5321、RFC 5322 は、構文と規範の変化を裏付ける。現在どれほど使われているか、製品の既定値、拒否率、配送成功率は示さない。

歴史が残した境界は単純である。SMTP は過去の経路を理解する責任を保ちながら、その経路が将来の中継を決める既定の権限を取り去った。