要約

  • 251 は古い受信者をこの取引で受理し、受信サーバーが先の転送を負う。551 は拒否であり、候補先を試すか失敗にするかはクライアントが決める。
  • 後年の仕様は、受理側に 250 の無言転送、拒否側に 550 の非開示を認めた。最終アドレスは運用情報であると同時に秘密にもなり得る。
  • 訂正された経路は本人確認でも全世界の改名でもない。将来のアドレス帳を書き換えるには、サーバーの真正性とデータ所有者の別の承認が要る。

同じ移転情報から逆の仕事が生まれる

クライアントが古い宛先を RCPT TO で示す。251 を返したサーバーは、その宛先を成功として受理し、メッセージを先へ渡す責任を持つ。551 を返したサーバーは受理しない。表示された新アドレスは次の行動の候補であり、すでに成立した配送ではない。

両方を「ユーザー移転」とだけ記録すると事故になる。251 後に新アドレスへ同じものを送れば重複し得る。551 後に転送済みと思えば消失する。三桁の先頭は、アドレスの説明ではなく責任の状態である。

最初の SMTP が用意した二本の道

RFC 821 は1982年、与えられた forward-path が誤っていても受信 SMTP が正しい場所を知る場合を定めた。ホスト、利用者部分、または双方が変わり得た。

251 User not local; will forward では、サーバーは今後使える訂正先を示し、現在のメッセージを届ける責任も引き受ける。551 User not local; please try では旧宛先を拒み、送信側が案内に従って再送するか、起点の利用者へ失敗を返す。

同じ文字列が現れても、前者は受理に添えられた情報、後者は拒否に添えられた情報である。SMTP は新しい名前を宣言するより先に、現在の荷物を誰が持つかを確定した。

一回の応答はアドレス帳を所有しない

クライアントは訂正先を保存しなくても取引を正しく処理できる。251 なら元の受信者は受理済み、551 なら未受理である。新しい取引、利用者への提示、恒久的な連絡先更新は、それぞれ別の処理だ。

RFC 5321 は、251 や 551 を返すサーバーが、クライアントによるアドレス更新や利用者への表示を期待してはならないとする。数秒の SMTP セッションが、何年も残る遠隔の名簿へ自動的な書き込み権を得るわけではない。

行き先を隠して転送する

RFC 2821 がまとめ直した時代には、silent forwarding が一般的だった。企業の安定した入口から内部メールボックスへ、古い個人アドレスから私的な新アドレスへ転送できる。しかし最終地点は内部構成を漏らし、送信者から直接到達できない場合もある。

そこで責任と開示が分離された。受理して転送するサーバーは 251 で訂正先を示しても、普通の 250 で黙っていてもよい。拒否するサーバーは 551 で候補を示しても、550 だけ返してもよい。RFC 5321 は、開示が望ましくないサイト向けに制限設定を用意するよう求める。

受理／拒否と、開示／非開示の組合せは四通りある。秘密を守るために、受理の事実まで曖昧にする必要はない。

移転済みでも公開先がない

RFC 3463 の X.1.6 は「宛先メールボックスは移転、転送先なし」という恒久失敗を表す。現在の IANA SMTP Enhanced Status Codes Registry にも同じ状態が残る。

本当に代替先がないことも、サーバーが知らないことも、方針上明かせないこともある。内部転送には使えても外部送信者からは使えないアドレスもある。したがって「移転した」は「公開してよい新経路がある」を含まない。

RFC 3464 は DSN が通常のメール同様に偽造可能だと注意し、自動転送先を秘密にしたい受信者も扱う。実装にはその機密性を守る方法が望まれる。配送が続くことと、送信者が全経路を知ることは別である。

機械が読める訂正は攻撃面にもなる

通常の SMTP 応答文は人向けで、クライアントは主に数字で動く。251 と 551 の訂正 path は例外であり、将来利用するなら機械が解析する。そのため中間者が一つの文字列を置換するだけで、長期の行き先を変えられる。

RFC 5321 は、アドレス帳など将来の挙動を自動更新する前に、サーバーの真正性を確かめるべきだと警告する。偽の訂正を保存すれば、現在の一通だけでなく以後の通信も攻撃者へ向かう。

ただし真正なサーバー応答も万能ではない。それは発言元を示すが、新メールボックスが同じ人物のものか、変更が永久か、その管理者が利用者の標準連絡先を決められるかまでは証明しない。認証は自動化の入口であって、命名権そのものではない。

Alias が変えるのは envelope の受信者

RFC 5598 は通常の MTA relay と alias を区別した。relay は envelope address を変えずに宛先へ近づける。受信者側の alias は、一つ以上の代替受信者へ再投入しつつ、元の内容と通常は reverse-path を保持する。

変更は RCPT TO 一つに見えても、意味は大きい。最初に指定された受信者が別の受信者を選んだのである。下流障害の通知は、その隠れた選択を知らない原著者へ戻る場合がある。

転送は運用責任を動かすが、表示上の To、Message-ID、著者の意図、人の正式な名前を自動的に書き換えない。251 と 551 は envelope の局所判断であり、インターネット全体の改名機構ではない。

限定された訂正だから長く使えた

この二つのコードは、受理する、転送する、開示する、記憶するという四つの判断を切り離した。後年のプライバシー対策は訂正機能を捨てず、公開範囲だけを狭めた。

SMTP はメッセージを移転先へ追随させながら、人そのものを改名したとは言わなかった。その抑制こそ、最終アドレスを黙らせても責任を正確に保てた理由である。