要約

  • DELEの肯定応答は、現在のmaildrop内の番号に削除印を付けた証拠にすぎない。実体は残り、TRANSACTION中ならRSETで印を外せた。
  • クライアントがTRANSACTIONからQUITした場合だけUPDATEへ進む。異常切断や自動ログアウトは削除の同意にならない。
  • RFC 1939は、UPDATEが一部の印だけを除去して終わり得ると明記した。境界はあっても全件原子性はなかった。

肯定応答が約束した範囲

RFC 1081以来、POP3はAUTHORIZATION、TRANSACTION、UPDATEを分けた。認証後、サーバーはmaildropを開き、必要な排他ロックを得て、その時点の項目に番号を振る。

DELE 4はそのビューの4番を印付けする。以後その番号への参照はエラーになるが、格納物はまだ消えない。RSETはすべての印を外す。従って最初の+OKは「このセッションで破壊意図を受理した」という狭い事実で、不可逆な結果の受領証ではない。

ロックは番号の意味を守る。次回接続まで番号を恒久名にするものではなく、保存期間や別の配送経路を支配もしない。RFC 1225とRFC 1460も、印、取消し、UPDATE、ロック解放、応答、切断という順序を保った。

切断には削除権限がなかった

RFC 1725は、クライアント発のQUIT以外で終了したセッションはUPDATEに入らず、メールを除去してはならないと明記した。無通信による自動ログアウトも、応答せず、削除せずに閉じる。

これは、ネットワーク受信とローカル保存の間を守る規則だった。最後のオクテットが届いても、端末がディスクへ安全に書き終えたとは限らない。障害によるTCP終了を削除の同意とみなせば、保存確認を失わせた同じ障害が回収可能な原本まで奪う。

AUTHORIZATION中のQUITは終了だけを意味する。maildropと印が存在するTRANSACTION中のQUITだけがUPDATEを開く。権限は命令文字列ではなく状態との組合せにあった。

UPDATEは境界であって原子性ではない

RFC 1939では、資源不足などにより、印の付いたメールの一部または全部が残り得る。-ERR some deleted messages not removedはその現実を表す。印のないメールは決して除去してはならないが、印の集合が全件同じ結果になる保証もない。成功・失敗にかかわらずロックは解放され、接続は閉じる。

最終応答が失われれば、クライアントには完全成功、部分成功、未実行を区別できない。再接続後に古い番号へ同じDELEを繰り返すのは危険である。新しい4番は別のメールかもしれない。UIDLは残存物の照合を助けても、欠落の原因までは証明しない。

RFC 2449のEXPIRE 0は、UPDATEに入った時点でRETR済みメールを暗黙のDELEとして扱えるようにした。方針が印の集合を広げても、除去の境界はUPDATEのままだった。

IANAのサービス名・ポート番号登録簿はpop3を110番に記録するが、現代の利用率や実装の適合性は示さない。

POP3の設計は、証拠を小さく保った。印を付けた、UPDATEを要求した、結果を受け取った、次の状態を照合した——四つは別々の事実である。

出典