要約

  • 初期SMTPの明示的ソースルートは中継順をforward-pathに入れ、各リレーが自分を消費してreverse-pathへ移す可変のエンベロープ状態だった。
  • routeと絶対mailbox、SMTPエンベロープと本文ヘッダーは別物である。reverse-pathは読者向けのFrom:でも、通過を証明する認証記録でもない。
  • MXと完全修飾ドメイン名は通常の経路選択を送信者の住所記述からDNS・送信MTA・ローカルポリシーへ移した。旧構文を読めることは、その経路に従う義務を意味しない。

左側から消えた名前はどこへ行ったのか

RFC 821の例を、そのままSMTPの会話に置く。送信側はまず MAIL FROM でreverse-pathを示し、受信者ごとに次のような命令を送る。

RCPT TO:<@ONE,@TWO:JOE@THREE>

コロンの右にある JOE@THREE は絶対mailboxである。左の @ONE,@TWO は、そこへ至るsource routeだ。mailboxは最終的な相手を指し、routeは途中の手順を指す。RFC 821が両者を混同してはならないと念を押したのは、文字列の一部を削る処理が最終宛先の変更に見えやすいからだ。

ONE が最初のroute要素として自分を認識すると、forward-pathから @ONE を取り除く。残るのは @TWO:JOE@THREE である。同時にONEは、自分をreverse-pathの先頭に追加する。つまり情報は消滅せず、将来の命令から、受け入れ済み区間の返送責任へ移る。

この更新を繰り返せば、前方の一覧は短くなり、後方の一覧は伸びる。ソースルートは静的なラベルではない。各MTAが状態遷移を実行する小さなプロトコルだった。

MAIL FROM は著者欄ではない

reverse-pathという語から「返信先」や「送信者」を想像すると、別の層が混ざる。SMTPのMAIL FROMは、転送後に配達不能が判明した場合の通知先を含むエンベロープ情報である。本文のFrom:、Sender:、Reply-To:とは目的も証拠の強さも異なる。

同じくRCPT TOのforward-pathは、本文に表示されるTo:やCc:の写しではない。Bccのように本文に現れない受信者もいれば、一つの本文を複数のエンベロープ受信者へ送ることもある。本文ヘッダーだけを保存しても、実際の中継命令は復元できない。

RFC 822もroute-addrをroute部分とaddr-specに分け、特別な必要がなければsource routingを避けるよう勧めた。歴史的に似た表記がメッセージ形式にも現れたことは確かだが、それを理由にエンベロープと本文を同一視してはならない。

したがってONEがreverse-pathへ自分を足しても、読者向けの差出人を書き換えたことにはならない。著者を認証したことにもならず、返答の宛先を決めたことにもならない。割り当てられたのは、SMTP配送失敗を戻すための機械的な経路状態である。

中継名は環境を越えるたびに同じとは限らない

RFC 821には見落としやすい条件がある。リレーがreverse-pathへ追加するのは、入ってきた環境で使われた名前の単純なコピーではない。次に送り出す環境で自分が知られている名前を使う。

ゲートウェイの両側で命名体系が違えば、一つの装置が複数の呼ばれ方を持つ。戻り道が役立つためには、これから受け取る側が理解できる名でなければならない。明示的経路は「全世界で同じ名前のリスト」ではなく、環境境界で再表現される連鎖だった。

現在のサーバがforward-pathの最初の要素でない場合も、自分の都合でそれを消せない。その要素は次のSMTPを選ぶ手掛かりになり得る。消費する権限は、リストの位置と受信側の自己認識が一致したときだけ生じる。

ただし、自己認識は暗号学的な証明ではない。経路に書かれた名は送信者認証を与えず、そのすべてを実際に通ったことを保証しない。reverse-pathが伸びたからといって、改ざん不能な監査証跡が完成するわけでもない。

MXが受け取ったのは「次のリレーを書く権利」だった

RFC 974のMXは、source routeをDNSに保存し直した仕組みではない。目的ドメインに対して、優先値を持つメール交換機を示す。送信MTAは目的ドメインを問い合わせ、規則に従って候補を試す。

この設計では利用者がuser@domainを示せばよい。どのMTAへ接続するかは、送信時のDNS、到達可能性、ローカル構成によって決まる。目的ドメインが交換機を変更しても、利用者のmailboxは変えずに済む。

RFC 974はMXを再帰的に追い、MXのMX、そのまたMXを順番に通る壮大な経路を作ることを戒めている。MX候補は直列のwaypointではない。これはsource routeとの違いを明確にする。旧方式では送り手が順序を書き、新方式ではMTAが目的のために次の一手を選ぶ。

経路知識を住所から外すと、失敗時の修正範囲も変わる。古い明示的経路は、住所を保存した名簿、キュー、転送設定のすべてに古いトポロジーを複製する。MXならドメイン側の記録や送信MTAの方針を更新できる。安定した名前と変わり得る経路を分離したのである。

生成を止めても、受信を同時には止められなかった

RFC 1123は、Sender-SMTPがRCPTで明示的な@...: routeを送るべきではないとした。普遍的な命名をsource routingより優先し、DNSとMXを主要な解決手段に据えた。

一方でReceiver-SMTPには、その構文を受け入れる義務を残した。ここでの受け入れは、まず正しく解析できることを指す。要求された中継サービスを無条件に提供することではない。source routeを実装しないサーバは、条件に従って右端の@の後にある最終ドメインへ直接送ることを試せる。

この非対称性には時間が組み込まれている。新しいクライアントが旧形式を増やすのを止め、すでに保存・転送・待機している旧形式は壊さない。構文の寿命と権限の寿命を同日に終わらせないことで、設置済みシステムを段階的に移行させた。

逆に、構文を読めるというだけで経路に従い続ければ、退役は起きない。互換性は過去の入力を解釈する能力であり、過去の入力に現在のポリシーを上書きさせる権利ではない。

パース成功とリレー許可の間には境界がある

source routeを受け付けるサーバを、そのままopen relayと呼ぶことはできない。サーバは構文を認識したうえで、認証、送信元、宛先、許可されたドメイン、接続経路などに基づいて中継を拒否できる。route部分を無視して最終ドメインだけを扱うこともできる。

RFC 2821はsource routeをdeprecatedとし、サーバには構文を受けられる準備を要求しながら、通常はrouteを無視するよう勧めた。クライアントは生成すべきでなく、サーバはrelayを拒否してよい。

routeを無視する通常処理では、そこに書かれた中継名をreverse-pathへコピーしてはならない。RFC 821の「前から後ろへ移す」動作は、旧経路を実際に使用する場合の処理であり、現代SMTPの全メールに起きる一般動作ではない。

もし例外的にrouteを使うなら、最初に示されたドメインへ送り、勝手に近道を推測してはならない。使うふりをして一部だけ並べ替えるより、明示的に無視または拒否する方が、決定を監査できる。

「メールの島」では、利用者の地図が資産だった

RFC 1711は1994年、明示的source routingを、利用者が通したいMTAをアドレスに組み込む仕組みとして説明した。指定MTAに届くと、そのMTAは自分を取り除き、残りを通常通り配送する。

当初の有用性は、接続の少ないmail islandにあった。遠い島へつながる既知のゲートウェイを利用者が知っていれば、その知識を住所へ入れることで届く可能性が生まれた。経路を書く行為は、ネットワークがまだ共有できていない到達性情報を補っていた。

しかし相互接続が進むと、利用者のトポロジー知識は古くなりやすい負債へ変わる。RFC 1711は、リレーによって処理が一貫しないことを理由の一つに挙げ、エンドユーザーがメール網の構造を知る必要はほぼ消えたと述べた。

これは2026年の実装調査ではない。1994年時点の分類と歴史判断である。また、ゲートウェイや特殊なデバッグ用途が一斉に消えたことも証明しない。確かに言えるのは、通常配送を正当化していた前提が「利用者しか経路を知らない」から「システム側が動的に選べる」へ移ったことだ。

percent hackやUUCPのbang pathは、古いルーティング知識をアドレスへ埋める別方式である。比較には使えるが、@relay1,@relay2:user@hostの構文やforward/reverse変換と同一ではない。似た時代背景を、一つのプロトコル動作に圧縮してはならない。

廃止済みの構文が残る理由

RFC 5321は、MXによって明示的source routeの通常需要がなくなり、完全修飾ドメイン名の要件によって最後の重要な一般的理由も失われたと整理する。クライアントは、デバッグや一時的で深刻なDNS障害のような異例の場合を除き、使うべきではない。

それでもサーバは古い構文を認識し続ける。routeを無視して最終宛先へ向かうことも、relayを拒否することもできる。obsoleteは「パーサから消す」という意味ではなく、「新しい正規動作の権限を与えない」という意味になった。

ただしrouteを削れば必ず救済できるわけではない。中間環境でしか意味のない名前に依存していた古いアドレスは、最終ドメインだけを残すと解決不能になり得る。仕様は無効な経路を新しく作るなと求めるが、受信側に過去の局所名前空間を推測する魔法までは与えない。

したがって運用上の問いは「source route対応か」の二択では足りない。構文を読んだか、原文を保存したか、routeを使ったか無視したか、relayを許可したか、最終ドメインは解決したか、失敗前に責任を受け入れたかを分ける必要がある。

正規化した住所から、受信時の命令は復元できない

最終的なログにJOE@THREEだけが残っていても、入力が最初からその形だったとは限らない。境界MTAがsource routeを取り除いたかもしれず、監視製品が解析後のmailboxしか保存しなかったかもしれない。メッセージ本文はそもそも同じ情報を持たない場合がある。

逆に、データベースの一欄に@ONE,@TWOがあっても、ONEとTWOを実際に通ったことは証明できない。文字列は命令の候補であり、受理・使用・転送の証拠には、SMTP応答、接続相手、時刻、次ホップ選択、キュー記録が必要である。

監査では受信した原文と、パース後のroute/mailbox、ポリシー判断、正規化後の値を別々に保存するべきだ。派生値だけを残すと、互換処理が成功したことは見えても、何を互換処理したのかが消える。

source routeそのものも署名済みの経路証明ではない。reverse-pathへ移された名前はエラー処理に使えるが、各ホップの正直さ、唯一性、実通過を保証しない。仕様が与えた処理意味と、証拠として推論できる範囲を分けなければならない。

出典が閉じる範囲

根拠はRFC 821、RFC 822、RFC 974、RFC 1123、RFC 1711、RFC 2821、RFC 5321に限定した。これらは構文、規範動作、設計の移行と当時の評価を示す。現在の流量、実装率、open relayの割合、攻撃件数、特定製品の挙動は示さない。

またSMTPのsource routeはIPv4のLSRR/SSRRとは別である。送信側が経路情報を持つという抽象的な共通点だけで、処理層、表現、権限、脅威、廃止史を共有すると推定してはならない。