要約

  • DELEは、排他的にロックされたTRANSACTION状態で削除印を付けるだけである。RSETは正常終了より前なら印をすべて外せる。
  • TRANSACTIONからクライアントがQUITを送った場合だけUPDATEへ進む。異常切断では一通も消してはならないが、UPDATE中の障害は部分的な削除を残し得る。

切れた回線に同意を代弁させない

ダイヤルアップ端末が三通を受信し、サーバー上の原本を消すよう求めたとする。応答はすべて成功だった。しかし最後の一通をローカルディスクへ書く直前に回線が切れた。要求の受理と同時に削除していたなら、保存を妨げた障害が遠隔コピーまで失わせる。

POP3は結果を遅らせた。DELE後のメールは、そのセッションからは参照できなくなるが、maildropには残る。RSETで印を外せる。TRANSACTION中のQUITだけがUPDATEへの扉を開き、そこで初めて物理的な削除を試みる。

サーバーは送信を知っても、相手の永続保存を確認できない。そこで双方が観測できる「正常な別れ」を限定的な合図にした。TCPの沈黙やタイムアウトは、破壊の許可に読み替えられない。

受領と削除を離す発想はPOP3以前からあった

1984年のRFC 918は、読み取りだけのRETRと、削除を伴うRDELを分けた。データ受信後にクライアントがRCVDを返してから削除を試み、RSETは取引を中止してメールボックスを適切に閉じ、ロックを解いた。

1985年のPOP2を定めたRFC 937では、ACKDが受領を確認して削除印を付けた。実際の変更は、セッション終了または別メールボックス選択によって現在のボックスが解放されるまで待った。

命令名は変わっても、問題は同じだった。「送信済み」と「相手が安全なコピーを持つ」は、不安定なネットワークでは同一時刻ではない。その間を共通仕様にする必要があった。

三つの状態が猶予を構造にした

1988年のRFC 1081は、初のPOP3をAUTHORIZATION、TRANSACTION、UPDATEに分けた。認証後、サーバーはmaildropを開いて排他ロックを取る。TRANSACTIONで一覧、取得、削除印を扱い、QUITでUPDATEへ進み、削除、ロック解放、TCP切断を行う。

AUTHORIZATIONはアクセス主体を決め、TRANSACTIONは安定した取り消し可能な作業面を提供し、UPDATEは不可逆な効果を担う。認証前のQUITは終了するだけでUPDATEへ行かない。対象となる認証済み取引がないからだ。

番号も一時的な作業面に属する。DELEされた番号は同じセッションの後続命令から拒否される一方、基礎データはまだある。論理上の削除と物理的除去を、状態境界が分離した。

RSETは通常の撤回手段だった

RSETは必須の最小命令で、すべての削除印を外す。ローカル容量不足、解析失敗、保存方針の変更に気づいたクライアントは、別れの前なら判断を撤回できる。

RFC 1725は、必要な排他ロックがUPDATE以前の変更や除去を防ぐと明確にした。別クライアントに作業中の番号対応を動かされないためである。

ただし汎用データベース取引ではない。分散合意もUPDATE後のundoも、共通ジャーナルもない。狭い撤回可能区間だけを単純なサーバー向けに定義した。

異常終了はUPDATEに入れない

RFC 1725は改訂点として接続切断時の挙動を明記した。クライアント発行のQUIT以外で終わるセッションはUPDATEへ入らず、maildropから何も削除してはならない。自動ログアウトも応答せず接続を閉じるだけである。

1996年のSTD 53、RFC 1939も同じ義務を維持し、理由を示す。異常終了した場合、クライアントはメールを正しく受信または保存できていないかもしれない。

これは相手のディスク状態の証明ではない。切断前に保存済みかもしれず、正常終了でもバックアップを保証しない。それでも重複という修復可能な側を選び、唯一のコピーの喪失を避ける共同シグナルになる。

QUITはコミットの門であって原子性ではない

UPDATEでサーバーは印の付いたすべてを除去しようとする。しかしRFC 1939は、資源不足などで一部、全部、または一つも除去できない場合を認める。印のないメールだけは絶対に消せない。成否にかかわらずロックを解放し、接続を閉じる。

したがってQUITは権限境界という意味ではcommitに似るが、all-or-nothingではない。最後の応答まで失われれば、クライアントはどの集合が消えたかも確定できない。仕様は、多様な保存方式に存在しない保証を押し付けず、部分結果を正直に記述した。

DELEへの+OKが意味するのは「印を受理した」であり、「サーバーコピーが消えた」ではない。表示や監視が二つを混同すれば、安全機構が見えなくなる。

後発の保存方針もUPDATEを通った

サーバーにメールを残す利用が増えると、RFC 2449はEXPIRE能力を定義した。EXPIRE NEVERは方針上削除しないことを示し、EXPIRE 0は取得成功メールを暗黙に削除対象と見なせる。ただしそれもセッションがUPDATEへ入る時である。

新しい方針は印の付け方を変えても、取得を即時破壊にはせず、切断を別れとして扱わなかった。小さな状態機械の境界が拡張を統治した。

別れが守ったのは礼儀ではなく保管責任だった

クライアントは予定した受信列の終わりを決め、サーバーは保存領域での実行結果を知る。ネットワークは双方を妨げられるが、前者の決定を代行できない。不確実性のコストは再受信と照合へ寄せられ、静かな消失から遠ざけられた。

印を付け、必要なら戻し、明示的に門を越え、除去を試し、部分失敗を認める。削除は別れで現実になり始めるが、POP3はその現実が常に一度に変わるとは偽らなかった。

出典と限界

起源はRFC 918とRFC 937、最初のPOP3はRFC 1081、継続はRFC 1225とRFC 1460にある。RFC 1725が切断規則を明確化し、RFC 1939が現行動作と部分失敗を、RFC 2449がEXPIREを定める。現在の普及率、特定製品の保存方式、原子的またはexactly-onceな削除は示さない。