要約

  • RFC 772とRFC 780のMTPは、R（宛先先行）とT（本文先行）を持ち、受信側が利用可能な手順を決めた。MRSQは検出・選択・リセット、MRCPは宛先処理を担った。
  • Rは宛先表を保持してから一本文を渡し、Tは本文を保持してから宛先ごとに処理した。順序は、何をバッファするか、いつ失敗が確定するか、資源不足がどの範囲へ及ぶかを変えた。
  • RFC 788とRFC 821のSMTPはMAIL、複数RCPT、DATAという一つの外部順序に収束した。一つの本文を複数宛先で共有する目的は捨てず、受信実装の都合を通信路から内部へ移した。

「好みを聞く」は読み取り専用ではなかった

RFC 780でMRSQ ?は受信側のpreferred schemeを尋ねる。答えは215 Rまたは215 Tの形を取る。送信側は提案できるが、どの方式を実際に使えるかは受信側が制御する。

ここで注意すべきは、MRSQが必ず状態をリセットすることだ。問合せ、選択、引数なしの初期化のどれでも、現在の方式に保存された宛先または本文が破棄され得る。疑問符を単なる情報取得として途中に差し込むことはできない。

引数なしMRSQは、機能が実装されていれば200を返し、方式未選択へ戻る。対応する受信側はRかTの少なくとも一方と、好みの問合せを実装する。MRSQ Rに504を返して利用不能を示し、Tを選び直させることもできた。

選択権が受信側にあるのは、礼儀の問題ではない。宛先一覧を一括で中央mailerへ渡す方が自然なサイトと、各メールボックスへ逐次配達する方が自然なサイトでは、安全に確定できる応答の時点が異なる。

Rは宛先の記憶を先に作る

Recipients-firstでは、送信側がMRCP TO:<path>を繰り返す。受信側は一件ごとに受理または拒否し、成功したパスを表へ保持する。ある無効宛先は、すでに受理した別の宛先や後続宛先を自動的には無効にしない。

一覧の後、TOを持たないMAIL FROM:<sender-path>で本文を一度だけ渡す。本文後の肯定応答は、記憶された全宛先に対する成功を表す。失敗応答なら、その集合全体を失敗として扱う。いずれにせよ、処理後に宛先状態はフラッシュされる。

これは、完全な宛先集合と本文をまとめて別のmailerへ引き渡す実装に適していた。一本文を複数人へ使えるだけでなく、内部ハンドオフの単位もまとまる。

ただし、表には上限がある。452で宛先表が満杯になれば、現在の集合へ本文を送り、次の集合を集めて本文をもう一度送る。10名しか保持できない受信側へ50名を届ける例では、五回に分割され得る。一本文という効率は、受信側状態の容量までである。

Tは本文の記憶を先に作る

Text-firstでは、最初に宛先なしのMAILで本文を受信側へ保存する。その後の各MRCPは、保存済み本文を指定宛先へ適用し、個別MAILに相当する結果を返す。

本文は宛先ごとに再送されない。次のMAILが置き換えるか、MRSQがリセットするまで保持される。Tも複数宛先の転送量を節約するが、受信側が保持する対象は宛先表ではなく本文である。

逐次配達型の実装では、メールボックス容量やアクセス競合などの結果を宛先ごとに確定できる。Rのように、一つの最終本文応答へ集合全体の意味を載せる必要がない。

一方、本文を先に受けた時点では有効な宛先が存在する保証はない。本文保存前のMRCPは、実質的に空メッセージを送ろうとする状態となり、受信実装によって受理またはエラーになり得る。コマンドの意味は前段状態に依存する。

MRCPの250は方式なしには読めない

RのMRCP成功は、宛先が表に記憶されたことを主に示す。本文処理はまだ後にある。TのMRCP成功は、すでにある本文をその宛先へ処理した結果に近い。同じ命令名と2xxでも、証拠の位置が違う。

したがって古いトレースを読む時、数値応答だけを集計してはならない。選択中のR/T、最後のMRSQ、保存対象、MAILの種類を同時に再構成する必要がある。

リセットはさらに解釈を難しくする。MRSQは方式状態を消し、宛先を伴う通常MAILもその状態を初期化する。あるMRCPが直前まで有効だった本文または表に結び付いていると仮定すると、途中のリセット一行を見落としただけで誤配達の物語を作ってしまう。

交渉可能な順序は、二つのコードパスだけではない。二つのキャッシュ対象、複数の消去点、同形応答の異なる意味をすべて共有仕様にする。

受信側の都合は実在した

RFC 780は両方式を必要なものとして説明する。Rは、受信プロセス自身が直接書き込まず、中央mailerへまとめて渡すITSのような環境に便利だった。関連情報が一つのハンドオフに多いほど効率が良い。

Tは、宛先ごとに直接、増分的に配達する実装へ向く。ディスク割当やメールボックスの競合は人ごとに異なり、個別の成功・失敗を返せる。

送信側は相手の内部構造を知らない。宛先表の容量、本文保管の費用、ローカルmailerの境界を観測できない。そのため好みを提示しても、最終的な実行可能性は受信側が決める。

この権限配分は個々の接続では合理的だった。しかしインターネット全体では、全クライアントが二通りに備え、全ゲートウェイが状態を翻訳しなければならない。ローカル最適化を外部文法にすると、相互運用の状態空間が広がる。

SMTPは外部の並びを一つにした

1981年11月のRFC 788は、明瞭な三段階を定めた。MAIL FROMが送信者と新しいトランザクションを示し、繰り返し可能なRCPT TOが宛先を交渉し、DATAが本文を運ぶ。文書は対話を意図的なlock-stepと呼び、この順序だけで使うよう求める。

MRSQもMTPのMRCPも新しい命令集合にはない。受信側がTを要求する外部選択は消えた。複数宛先はRCPTの反復で表され、あるRCPTの拒否はトランザクション全体を拒否しない。

本文終端を受けた時、受信側は保存した宛先とデータを処理し、最終応答を返す。共有状態機械は一つになったが、各サーバーが内部でいつ検証し、いつキューへ渡すかまでは統一されていない。

SMTPが固定したのは、対向者が観測する順序である。受信実装が中央処理か逐次処理かという違いは、通信相手へ別文法を要求せずに内部へ残せる。

一本文の目的は消えなかった

MTPの二方式が目指した大きな効率は、同じ本文を同一ホストの各宛先へ何度も送らないことだった。SMTPはその目的を捨てていない。

RFC 788とRFC 821は、複数宛先に一つのデータコピーを使うよう勧める。固定順序ならMAIL一回、RCPT複数回、DATA一回となる。

RFC 1123も、同じホストの複数人にはRCPT, RCPT, ... RCPT, DATAを使い、RCPT, DATAを人数分繰り返さないよう強く促した。

失われたのは効率ではなく、効率を得るための二種類の外部編舞である。SMTPは宛先先行へ統一し、その中で一本文共有を通常動作にした。

PIPELININGは順序選択を復活させない

lock-stepは各命令の後に応答を待つ時間の問題でもある。後のPIPELININGは許された命令を応答前に送れるようにしたが、トランザクションの論理順序は維持する。

DATAをRCPTの前へ移すわけではなく、MRSQ Tを戻すわけでもない。待たずに並べることと、どの状態が先に存在するかは異なる。

この区別は既存のPIPELINING史との重複を避けるだけでなく、障害解析にも必要である。ネットワーク上でバイトが近接して見えても、受信側の状態遷移はMAIL、RCPT、DATAの因果順序に従う。

現行の外殻と内部の自由

RFC 5321でも、トランザクションはMAIL、一つ以上のRCPT、DATAを基本とする。能力拡張やパラメータは増えたが、本文先行を受信側が選ぶ枠組みは戻っていない。

それでも実装は一様ではない。RCPT時に詳細なローカル検証をするもの、DATA後にコンテンツ制約を適用するもの、すべてを別キューへ渡すものがあり得る。外部順序を固定したからこそ、内部差異を対向クライアントへ漏らさず変更できる。

標準化はローカル工学を奪ったのではない。ローカル工学が通信相手の手順を分岐させる権限を取り除いた。その結果、実装変更の影響範囲も狭くなった。

同じMRCPという別のプロトコル

ここでのMRCPはMTPのMail Recipient命令である。後年のMedia Resource Control Protocolは音声合成や認識などを制御する別物で、技術的系譜はない。

検索ではこの同形略語が大きなノイズになる。MRSQ、mail、RFC 772/780の文脈を伴わないMRCP結果は、この記事の既存 coverage や根拠として扱えない。

名前が同じでも、時代、ポート、状態機械、操作対象が異なる。プロトコル史では略語そのものより、どの仕様が何を登録・定義したかを確認する必要がある。

根拠の限界

根拠はRFC 772、780、788、821、1123、5321である。二方式の動作、受信側の選択、リセット、資源境界、SMTPの固定順序と複数宛先効率を確定できる。

これらはMRSQの実配備数や、廃止を決めた単一会議、全環境共通の性能改善を示さない。最も慎重な表現は、RFC 788がMRSQ/MRCPを定義せず、代わりに一つの必須順序を定義した、というものだ。

Rを原子的配達と呼ぶことも、Tを本文反復と呼ぶこともできない。両者は失敗とバッファの配置を変えるが、単純な優劣表ではない。