要約

  • RFC 821 は、端末表示、メールボックス保管、またはその双方を SMTP の配送意味論に組み込む三つの任意コマンドを定めた。
  • 成功の意味は同じではない。SEND は端末到達、SOML は端末かメールボックスのどちらか、SAML は端末も試すがメールボックスへの格納を成功条件とした。
  • MX 中継は、配送経路を知ることと利用者の画面を制御することを分離した。後代の SMTP は三命令を非推奨にし、限定的な互換規則だけを残した。

本文より先に、到着の形を選ぶ

1982 年の共有ホストを考えてみよう。受取人はログイン中で、端末メッセージを許可している。遠隔の送信側は SMTP セッションを開き、通常の MAIL の代わりに三つの開始命令から一つを選べた。

SEND は利用者の端末への配送を要求する。利用者が不在、または端末メッセージを拒んでいれば、その宛先には一時失敗を返し得る。SOML は Send Or MaiL の略で、利用者が活動中なら端末へ、それ以外ならメールボックスへ送る。SAML は Send And MaiL で、活動中なら端末にも表示し、必ずメールボックスにも入れる。

RFC 821 では、これらは表示上の希望ではなく、MAIL と同じく取引を開始する動詞だった。その後に RCPT と DATA が続く。送信側は宛先や本文を渡す前に、到着の性質を選んでいたのである。

ここで SMTP は、利用者がいま到達可能か、割り込みを許すか、画面への一瞬の表示と保存済みの複製のどちらを成功とするかまで解釈しようとした。

三つの成功は、三つの証拠だった

SEND は端末にデータが届いたときだけ成功する。別の動詞が選ばれていない限り、メールボックスは自動的な退避先ではない。SOML では端末とメールボックスが代替関係にあり、どちらかで完了する。SAML はメールボックスを必須とし、端末表示を追加する。成功条件はメールボックス配送であって、画面表示の証明ではない。

従って、成功した SEND に永続的な複製があるとは限らない。成功した SOML も、追加の記録なしではどちらの経路が成立したか分からない。成功した SAML はメールボックス側を示すが、利用者が表示を見たことまでは示さない。

この文法は、注意と保管が異なるサービスだと率直に認めていた。ただし、動詞を選ぶのは送信側であり、割り込みと保存の結果を負うのは受取人と受信ホストだった。

在席はアドレスではなく、局所セッションの状態

RFC 821 の端末配送には、利用者がそのホスト上で活動中であり、かつ端末メッセージを受け入れていることが必要だった。どちらもメールアドレスの恒久的属性ではない。特定の機械上の特定時点に属する事実である。

アドレスが同じでも、利用者はログアウトし、別端末へ移り、割り込み設定を変える。メール経路が有効でも、受信ホストが利用者の対話セッションを所有しているとは限らない。宛先確認から本文到着までの間に状態が変わることさえある。

送信側は SEND を要求できても、受取人が在席だと宣言する権限はない。EHLO に命令名が現れても、それはサーバーが語彙を実装した証拠にすぎず、この利用者の在席や同意を証明しない。

MX は経路権限と画面権限を切り離した

RFC 1123 は、送受信双方に三命令の実装を任意とした。その短い解説は、MX 中継との緊張を明記している。

Mail Exchange は、あるホストが宛先を代理してメールを受け取る仕組みである。そのホストは利用者へ近づける経路を知っていても、利用者の端末へ直接書き込めないことがある。SEND に続く宛先について、RFC 1123 はそのような受信側が 251 User Not Local を返し、配送が遅れる可能性を送信元へ知らせることを認めた。

ここでは二種類の到達可能性が分かれる。経路上の到達可能性は、メールを引き受けて転送できること。表示上の到達可能性は、利用者が活動中の画面を制御できること。MX は前者を持ちながら後者を持たない。

分散した蓄積交換網の中間点は、次の配送責任を負えても、人の注意を即時に獲得するとは約束できない。

EHLO が発見できたのは文法まで

RFC 1425 が SMTP 拡張モデルを導入した際、初期登録表は三命令を任意サービスとして載せ、命令名を EHLO キーワードにもした。

これでクライアントはサーバーが命令を理解するか推測せずに済んだ。しかし減った不確実性は実装能力だけである。受取人がログイン中か、端末メッセージを許可しているか、そのサーバーが最終ホストか、表示が完了するかは分からない。

能力表示を人のオンライン表示に読み替えれば、正しいプロトコル情報から誤った製品上の約束が生まれる。EHLO は文法を発見する仕組みであって、在席や同意の台帳ではない。

設計の中心を外れても、互換性は残った

2001 年の RFC 2821 は SEND、SAML、SOML を obsolete とした。実装例は稀であり、ワークステーション技術の変化や別プロトコルの登場によって、実装済みでも役割を失った可能性があるという。

それでも命令は無条件に消されなかった。クライアントはサービスとして提供すべきでない。サーバーは互換目的で実装できるが、RFC 821 の意味を守り、EHLO で命令名を公開しなければならない。

RFC 5321 も同じ整理を保つ。旧命令は取引開始語として認識可能だが、通常の SMTP は MAIL と、本文を成功受理したサーバーへの正式な責任移転を中心に据える。

この責任は記録できる。受理したサーバーは配送を続けるか、失敗を報告する。一方、特定の瞬間に人の目が画面へ向いたとは主張しない。非推奨化は、互換性を壊さず、転送層が担える主張へ権限を狭めた。

IANA の行は現在の利用率ではない

IANA の SMTP 登録表 には今も SEND、SOML、SAML があり、RFC 821 の意味、後年の非推奨化、Message Submission での MUST NOT が記録されている。

そこに名前があることは、互換語彙の保存を意味する。現在の実装数、受取人の設定、個別表示の成功を意味しない。登録は呼び名を調整するが、古い社会的前提を復活させない。

支持能力、在席、同意、表示、保存、責任はそれぞれ別の事実である。初期 SMTP は一つの取引選択に複数を載せた。後代の SMTP は人の注意を解決したのではなく、移ろう注意をメール転送の中心から外した。

画面に早く出ることは、強い配送ではない

小規模で密に結合したホスト群なら、端末への直接表示には合理性があった。SOML は自然なフォールバックを持ち、SAML は保存を確保した。設計者は本物の差を見て、別々の動詞を与えたのである。

規模の拡大は、その差をどの層が扱うべきかを変えた。中継、異なるワークステーション、独立した利用者アプリが増えると、メール転送はキューと保管責任を担えても、現在の画面や割り込みの意思までは担えない。

光る画面は早いが、消える。静かなメールボックスは遅れても、責任の残る複製を保てる。メールボックスより先に着いたメッセージは競争には勝っても、居場所を得たとは限らなかった。

出典