要約

  • RFC 1425 は SMTP 拡張の共通の発見点として EHLO を導入した。成功応答が示す能力は一つのセッションに限られ、クライアントは次のセッションへ情報をキャッシュしてはならなかった。
  • 旧サーバーが EHLO を拒否しても接続を保ち、HELO へ戻れるはずだった。RFC 1651 は、実際には切断するサーバーと、その後の HELO を受け付けないサーバーを記録した。
  • 登録済み拡張、当該セッションでの広告、実行できるフォールバック、個別コマンドの受理、メール取引の完了、配達は別の証拠である。

電子メールを一斉更新せずに進化させるには、古い相手が新しい言葉を知らない場面を設計しなければならない。

SMTP は小さな会話で広がった。接続、サーバーの挨拶、HELO、封筒、本文という流れである。1990年代初めには新機能が必要になっていたが、機能ごとに独自の交渉を増やせば、共通言語は私的な方言に分かれてしまう。

RFC 1425 は未来の全機能を中央で決めなかった。拡張クライアントが EHLO で始め、サーバーが登録済みキーワードを複数行で示し、利用する機能の詳細は別の RFC に委ねる。共通化したのは発見の入口と名前の規律だった。

これは導入命令ではない。一回の通信の中で行われる能力申告である。

能力はホストではなくセッションに結び付いた

RFC 1425 は、拡張情報が必要なら SMTP セッションの開始ごとに EHLO を送るよう求めた。成功応答から得た情報をキャッシュしてはならない。

昨日の観測を今日の権限にしない規則である。同じホスト名でも、背後のプロセス、設定、経路、保守状態は変わり得る。変化がないと思えても、現在の伝送路の中で再び申告を受ける必要があった。

成功時のコードは 250。その時点でメール取引は走っておらず、双方の状態表とバッファーは初期状態にある。複数行応答に並ぶキーワードは大文字小文字を区別せず、公共のキーワードには登録された拡張仕様が対応した。当時のローカルな二者間拡張には X 接頭辞が使われた。

広告は処理済みの証明ではない。クライアントは個別拡張を選び、その RFC が定めるコマンドやパラメーターを送り、改めて応答を受ける。

RFC 1426 なら、EHLO 応答に 8BITMIME があることと、MAIL FROM で BODY=8BITMIME を要求することは別の段階である。その受理と DATA も別だ。本稿は八ビット本文の仕組みを扱わない。ここで重要なのは、能力を見た記録が能力を使えた記録ではないという順序である。

紙の矢印は接続状態を保証しなかった

拡張を知らない RFC 821 サーバーとの互換性も必要だった。RFC 1425 の想定では、旧サーバーは未知の EHLO にエラーを返し、接続を維持する。クライアントはリセットするか HELO に戻り、従来の SMTP を続ける。

拒否を違反にしない、よく抑制された設計だった。新機能を採用しない相手とも、共通する小さなルール集合で通信できる。

しかし、その矢印には条件が隠れていた。未知の語を受けてもサーバーが回線を閉じないこと。内部状態が壊れないこと。次の RSET や HELO が期待された状態で解釈されること。これらは文法ではなく、稼働する実装についての事実である。

RFC 1651 が運用現場を仕様へ戻した

1994年7月、RFC 1651 が RFC 1425 を置き換えた。基本構造は残ったが、「不適切に実装されたサーバー」という節が加わった。

既知のサーバーの中には、EHLO を受けると SMTP 伝送路を閉じるものがあった。応答前にも、応答後にも切断し得た。RFC 821 の状態規則に反するからといって、再送時に接続が戻るわけではない。

クライアントは応答コードだけでなく、回線の生死を監視する必要が生じた。切断されたら、拡張なしで処理できるかを判断する。可能なら新しい接続を開き、そこで HELO を使う。これは同じセッションの継続ではなく、別の状態と別の結果を持つ再試行である。

切断はしないものの、拒否した EHLO の後で HELO を受け付けないサーバーもあった。RSET を挟めば動く場合があったが、その RSET に 503 Bad sequence of commands を返す実装も多い。RFC 1651 は、この限定された回復手順ではその失敗コードを無視できるとした。

1995年11月の RFC 1869 もこの記述を残した。実装上の逸脱は、規格の外にある噂ではなく、改訂履歴の一部になった。

仕様が敗れたのではない。実装証拠を受け取り、最初のモデルと現実を分けて記録したことが改訂の強さだった。動くコードが文書を修正したのである。

一語の「成功」に複数の試行を埋めない

「ESMTP 非対応、SMTP へ正常にフォールバック」とだけ記録すれば、重要な境界が消える。

接続成立、220、EHLO 送信、応答、応答前切断、応答後切断、RSET、HELO、封筒受理、DATA 受理、中継責任、最終配達は、それぞれ別の出来事である。新しい接続で成功しても、最初の回線が連続していたことにはならない。広告されたキーワードも、その機能のコマンドが成功することを証明しない。

キャッシュ禁止の意味もここにある。能力はホスト台帳に永久保存する属性ではなく、ある接続の中で発せられた申告だった。接続が終われば、その文脈も終わる。

薄い共通層は互換性コストを移した

RFC 1425 は、選択肢の少ないプロトコルは普及し、多すぎるものは曖昧になると警告した。そこで共通部分を小さな発見面に留め、各機能の意味を別仕様へ分けた。

旧サーバーに一斉更新を要求しない代わりに、広い到達性を求めるクライアントが複数行応答、期限切れ能力、切断、再接続、例外的な状態遷移を引き受けた。コストは消えず、所有者が変わった。

登録は名前を共有させる。実装を起動させることはできない。サーバーは採用する機能を選び、クライアントは現在の広告から使える経路を選ぶ。古い規則へ戻れるのは、双方の状態機械がその経路を実行したときだけである。

仕様図は調査の出発点になる。観測された会話だけが、図の矢印を事実に変える。