要約

  • 1982年8月の改訂版はSMTPを信頼できるストリーム上の対話として定義し、両端が同じ伝送サービスを使わない場合もリレーを可能にした。
  • MAILは戻り経路、RCPTは一つ以上の宛先経路を示す。RFC 822は本文形式を別に定めており、SMTPが受理されてもメールボックスへの格納や閲読までは証明しない。

メールは、本文がどのネットワークを通ったかを知ることなく境界を越えられる。1982年8月にJonathan B. Postelが公表したSMTP仕様は、そのための仕組みを記述した。RFC 821は特定の伝送サブシステムに依存せず、信頼できて順序の保たれたデータストリームを要求する。その上で、SMTPプロセスがチャネルを通じてコマンドと応答を交わす手順を定めた。

中継は設計の中心にある。送信ホストと宛先ホストが同じ伝送サービスを共有すれば、送信側は受信側SMTPへ直接接続できる。共有しなければ、一つ以上の中間SMTPサーバーが異なる伝送サービス環境をつなぐ。Postelは環境の範囲を限定していない。一つのネットワーク全体の場合も、複数ネットワークの場合も、その一部の場合もある。「ネットワーク」と「伝送環境」は同じ箱ではない。

取引は引き渡しを段階ごとに見せる。送信側が双方向チャネルを開き、受信側が応答する。MAILは戻り経路を示して取引を始め、未達通知などの返送に使う。RCPTは宛先への前向き経路を指定し、複数回実行できる。その後のDATAが本文を運ぶ。応答コードによって、各命令が受理されたか失敗したかを確認できる。SMTPエンベロープは配送指示であり、本文内の表示と同じものではない。

同じ月に出たRFC 822と並べると分担が明確になる。RFC 822はARPA Internetのテキストメッセージ形式を定め、RFC 821は転送の対話を定めた。本文のFrom:ヘッダーはメッセージ表現の一部だが、MAIL FROMはSMTP取引の要素である。両者を同一視すると、本文に書かれたアドレスを実際の配送経路や受理判断の証拠と誤認する。仕様はその保証をしていない。

RFC 821はSMTPの起点ではなく改訂版だった。冒頭にはRFC 788、780、772を置き換えるとあり、1981年11月のRFC 788もすでにSMTPを記述していた。RFC 801の移行計画はSMTPサービスに触れるものの、導入数や利用者への配達実績を示していない。改訂文書の発行日は、すべてのホストが実装した日を意味しない。

また、この仕組みはTCPだけを前提にしていない。RFC 821の付録はNCP、TCP、NITSなどを扱い、TCP付録でSMTPにソケット番号25を割り当てる。番号は実装を具体化するが、ポートが開いているだけでメールサービスが稼働している証明にはならない。受信プロセス、命令の受理、経路、DATAの完了、チャネル後のローカル処理が必要だ。

歴史的意義は、異なる環境へ持ち運べるサービス境界を定めたことにある。SMTPはメール転送の共通対話を定義し、リレーによる環境間接続を可能にした。本文形式とローカルなメールボックス動作は別の論点に残る。Heng LuのNote 64を分析の視点として借りれば、共通仕様は相互運用に要る部分に絞り、伝送方式と導入を運用するシステムに委ねる例と読める。これは後世の解釈であり、Postelの意図を示す史料ではない。

Sources