要約

  • RFC 1204 は、USER の構文が正しければ、投稿サーバーがユーザー名を認識していなくても 250 を返すよう勧めた。これはアカウント列挙を防ぐ応答であり、存在確認ではない。
  • 次の PASS 250 が、パスワードと先のユーザー名の対応を検証したという別の記録だった。DATA 354 は本文を読む準備、本文後の 250 はローカルキューへの受入れを示した。
  • NOOP 250 は現在のセッションで投稿サーバーに内部エラーがないという範囲にとどまる。コマンド、状態、応答したコンポーネントのないコードは、何が確認されたかを示せない。

正解を返さないことが、正しい動作だった

RFC 1204 の USER は、単純な名前入力に見える。クライアントがユーザー名を示し、サーバーが 250 で受け入れる。しかし仕様は、その名前をサーバーが認識していない場合でも、構文が正しければ同じコードを返すべきだと続ける。

理由はユーザーデータベースの情報を出し過ぎないためだった。クライアントに特定のユーザー名の存在を試させてはならない。外側の観測者にとって、登録済みと未登録は同じになる。区別を失ったのではなく、区別をこの段階の公開応答から意図的に外したのである。

したがって「受入れ」はアカウントへの判定ではない。プロトコル状態が次へ進めるという意味で、入力の対象が実在するという意味ではなかった。監視側が USER 250 を「有効なアカウント」と正規化すれば、仕様のプライバシー制御を逆向きに実装することになる。

RFC Editor の記録は1991年2月の実験的 RFC として保存する。現在の IETF Datatracker は、正式な出所が記録される前の Legacy stream 文書で、IETF の承認も現行標準化過程での正式な地位もないと明記する。ここから読めるのは歴史的な仕組みであり、普及率や現用性ではない。

PC と配送システムの間にエージェントが置かれた

文書が想定したワークステーションは、現在とは異なる制約を持つ。PC のオペレーティングシステムにはユーザー認証の仕組みがなく、メールの送信者詐称を抑えるには別のエージェントが必要だ、と RFC は説明する。メッセージ投稿サーバーが PC 利用者を認証し、その代理として Sendmail や MMDF などの配送システムにメッセージを提出する構成だった。

ここで権限は一か所に集まらない。PC クライアントは入力を出す。投稿サーバーはローカルな資格情報の照合とキューを持つ。配送システムはその後の配達を処理する。Netix MPP は TCP ポート 218 を使い、SMTP と FTP のコマンド／応答形式を借りた。

RFC 821 の SMTP は、コマンドの後に応答を待つ一問一答の対話、DATA、終端シーケンス、数値コードを定着させた。RFC 1204 はその語法を PC からの投稿境界に移したが、意味の主体はコマンドと状態のままだった。

二度目の 250 はパスワードの関係を述べた

USER 250 の後に許される PASS は、先に示したユーザー名に対応するパスワードを送る。ここで 250 なら、サーバーが両者の正しい対応を検証したという。対応しなければ 530、構文や順序、内部障害には別の応答がある。

最初の 250 は認識結果を隠す。二番目は資格情報の対応を判定する。同じコードが連続しても、情報価値は反対に近い。前者で詳しく答えないことが保護であり、後者で照合を実施することが認証だった。

ただし PASS 250 も、投稿サーバーが持つアカウント資料に関する局所判定である。キーボードの前の人物の法的身元、本文の著者、あらゆる宛先への権限、内容の真実性までは定義しない。

後年の RFC 4954 は SMTP AUTH を SASL 機構のネゴシエーションとして定義し、TLS 等がなければ平文パスワード機構を許可しない構成を必須にした。これは後のセキュリティ文脈であり、RFC 1204 に遡って機密性を与える資料ではない。認証、通信路の保護、メッセージ処理が別の判断であることを比較できるだけだ。

354 の時点では、完全なメッセージはまだない

パスワードの検証後、クライアントは DATA を送る。354 はサーバーがメッセージ本文を受け取る準備をしたという応答である。パーサーの状態が変わり、次のオクテットを本文として扱える。しかし完全な終端はまだ観測していない。

クライアントが本文と SMTP 由来のドット終端を送り終えると、サーバーは再び 250 を返せる。今度の意味は「メッセージ本文を配送用キューに入れた」。内部エラーでキューに入らなければ 451 だった。

キューは 354 より強い保管証拠だが、配送証拠ではない。RFC は投稿サーバーに、受け入れたメッセージをできるだけ早く配送システムへ提出するよう求める。一方、配送失敗は配送システムが処理し、投稿サーバーは介入しないと分けている。

従ってキューの 250 は、中継の受入れ、メールボックス保存、MUA 表示、人の読了を証明しない。ローカルコンポーネントが自分の仕事を終えても、次の権限主体の結果は未確定のままである。

NOOP の青信号はローカルだった

NOOP はメッセージを操作しない。250 は現在のセッションで投稿サーバーが内部エラーに遭遇していない、というだけの健全性信号だった。配送システムの検査ではない。

一つの RFC の中だけでも 250 は次を指す。

  • ユーザー名の構文を受け、認識結果は非公開のままにした；
  • ユーザー名とパスワードの対応を検証した；
  • 完全な本文をローカルキューが保管した；
  • 投稿サーバーの現在のセッションに既知の内部エラーがない。

これらを success=true 一つにまとめると、プライバシー、認証、保管、健全性の区別が消える。プロトコル、接続、コマンド、順序、遷移前後の状態、応答したコンポーネント、対象オブジェクトを一緒に残すことが、コードを証拠に変える。

「投稿」という役割は後に明文化された

RFC 6409 は後にポート 587 のメッセージ投稿を定め、MUA からメッセージを受ける Message Submission Agent と、中継／配送を担う Message Transfer Agent を区別した。二つのサービスに異なる方針とセキュリティ機構を適用できる理由も示した。

この類似から直接の系譜や MPP の普及を推定してはならない。後の RFC が提供するのは、役割を分けて名前を付ける価値の確認である。投稿エージェントの成功は正当なローカル事実だが、メール経路全体の完了ではない。

RFC 1204 が残したのは、曖昧さを雑音ではなく制御として扱う設計だった。最初の肯定応答はアカウントの有無を隠し、次の応答は資格情報を照合し、その後の応答は本文の入口とキュー保管を別にした。数字が変わらないからこそ、誰がどの状態について答えたかが重要になる。

出典