要約

  • 初期IMAPのリテラルは、コマンド内部に置かれたオクテット数付き文字列だった。クライアントは{n}の後で+継続応答を待ち、そこからnオクテットと残りの構文を送った。
  • RFC 2088のLITERAL+は{n+}で待機を除いた。一方、拒否したいサーバーは既に許可されたデータを読み捨てるか、接続を閉じるかという負担を得た。
  • RFC 7888のLITERAL-は同じ表記の無待機送信を4096オクテット以下に限定した。APPENDLIMITは別にメールボックス単位の方針を示し、RFC 9051は制限付き形式をIMAP4rev2へ組み込んだ。

CRLFの後に続く一つの命令

リテラルはCRやLFを含められる。したがって改行文字を探して終端を決めることはできない。波括弧内の数だけを読み、その直後から同じIMAPコマンドの構文解析を再開する。そこには空白、次の引数、次のリテラル、または本当のコマンド終端が来る。

RFC 2060では、クライアントからサーバーへ送るリテラルは継続要求を待たなければならなかった。A001 LOGIN {11}は一行を終えてもLOGINを終えていない。サーバーが接頭部の誤りを見つければ、+ではなくBADを返し、余分なデータが流れ込む前に命令を閉じられた。RFC 3501も同じ規律を残した。

継続は最終承認ではない。後続引数の誤り、ACL、クォータなどは別に失敗し得る。{0}でも待つという規定は、この停止が転送時間ではなく決定権を表すことをよく示す。

TCPの受信窓とも違う。TCPはストリームの容量を扱い、LOGINやAPPENDを知らない。IMAPの+は、アプリケーションが一つの構文継続を受け入れる合図だった。

1997年の先送り

RFC 2088はLITERAL+ capabilityを定義した。サーバーが広告した場合、クライアントは{n+}を書き、返答を待たずnオクテットを続けられる。広告がなければ従来の{n}を使う。

速度は上がってもフレームは崩れない。受信側は行末の加号を認識し、数えた分だけをリテラルとして読み、その後の命令を解析する。リテラルが別メッセージになったのではなく、同じ命令の途中にあった往復だけが消えた。

capabilityは互換性以上の意味を持つ。サーバーが「各境界で尋ねなくてもよい」と事前委任し、クライアントがその委任を使う。高遅延回線や複数リテラルでは効果が大きい。しかし委任には、拒否を判断する時点が遅くなるという裏面があった。

読み捨てるか、切断するか

2016年のRFC 7888は、大きすぎる非同期リテラルを受けたサーバーの選択を記した。LITERAL+ではサイズ上限なしに送信が始まり得る。サーバーは指定数を読み捨てて命令を拒否するか、BYEを返して接続を閉じる。

読み捨てればストリーム境界は保てるが、帯域、CPU、メモリを失う。切断すれば現在の負荷を止められるが、再接続と再試行を招く。BADやNOを先に送っても、capabilityによって送信可能になったバイト列は取り消せない。

APPENDではメッセージ本体と添付がリテラルになるため、問題が目立つ。送信側が一往復を節約する一方、受信側は制限超過を知った後の処理を引き受ける。最適化は費用を消すのではなく、その帰属を変えた。

LITERAL-の小さな委任

RFC 7888はLITERAL+に加えてLITERAL-を定義した。LITERAL-のもとでは、継続なしのリテラルは4096オクテット以下に限られる。大きければ同期形式へ戻す。

ワイヤ上はどちらも{n+}である。各リテラルにマイナスは付かない。サーバーが広告したcapabilityが加号の範囲を決めるため、LITERAL+とLITERAL-を同時に広告してはならない。

4096はメールサイズでもクォータでもない。小さなAPPENDも失敗し、大きなAPPENDも許可応答の後なら成功し得る。この値が限定するのは「その場の許可なしに送り始められる量」だけである。

また、多数の小さなリテラルや反復接続は依然として資源を使う。RFC自身も、LITERAL-によるDoSリスク改善を部分的と位置付ける。

メールボックスの物差し

同じ2016年のRFC 7889はAPPENDLIMITを定めた。全メールボックス共通の上限を数値付きcapabilityで示すことも、STATUSやLIST-STATUSで個別値を取得させることもできる。

既知の上限を超えるAPPENDなら、クライアントは送信そのものを避けられる。ただし上限以下でもACLやクォータで失敗する。値が不明な場合、RFCはAPPENDで非同期リテラルを避けるよう勧める。

二つの物差しは統合されなかった。4096は共通構文の委任範囲、APPENDLIMITはローカルなメールボックス方針である。共通部分を最小にし、将来変わる決定を運用側に残す設計だった。

基本仕様に残った待機

RFC 9051は2021年、LITERAL-相当をIMAP4rev2に取り込んだ。非同期形式は通常4096以下であり、それを超える文字列は同期する。待機は古い仕組みとして削除されず、大きな資源投入の前に残された。

IANAのIMAP Capabilities登録簿はLITERAL+、LITERAL-、APPENDLIMITを掲載する。これは標準名の証拠であり、現在の採用率ではない。

この歴史の主役は加号ではなく、次のバイト列を誰が確定できるかである。個別許可、事前委任、限定委任、メールボックス方針という別々の判断を混ぜなかったから、速度と拒否権を同時に扱えた。

出典と限界

これらは現在の実装率、性能、攻撃頻度を測っていない。継続は最終承認ではなく、4096はクォータではなく、APPENDLIMITは上限以下の成功を保証しない。