要約

  • RFC 10022は、要求したメッセージ数に近い降順のUID範囲をIMAPクライアントへ返す。UIDONLYでも後続処理を先に分割できるが、範囲は固定ページでも保存済み検索結果でもない。
  • 範囲の両端に実在メッセージがなくてもよく、バッチは要求より小さくなり、削除後にはさらに縮む。メッセージ数はバイト数、遅延、サーバー負荷の等しさも保証しない。
  • Daniel EggertはIETF合意文書の編集者である。この仕様は最小限の分割方法を共有し、実装、スケジューリング、整合性判断、運用結果の責任をそれぞれの主体に残す。

大規模メールボックスを百バッチずつ処理する。最初は1:100、次は101:200。二つのコマンドの間に削除が起きれば、計算上の境界は同じとは限らない。RFC 10022は、1:100、100:200、200:300のように境界を一つ重ね、返された範囲を比較する方法を示す。

重複は無駄ではない。別時点の計算を結び付ける検査点である。

2026年7月にIETF Standards Trackで公開されたRFC 10022、IMAP UIDBATCHES Extensionは、Apple Inc.のDaniel Eggertが編集した。選択中のメールボックスを、おおむね指定件数のUID範囲に分ける仕組みである。UIDONLYによりメッセージシーケンス番号を使えない場合でも、クライアントはFETCH、SEARCH、STOREの対象を事前に分けられる。

ただし、分割はページング契約ではない。時間を止めず、作業量を一つの単位にそろえもしない。

バッチ番号は永続的なページIDではない

バッチ1は最も高いUID側にあり、次のバッチはその下へ続く。新着メッセージはより高いUIDを得るため、すでに返した範囲の内部には入らない。一方、EXPUNGEによって範囲内のメッセージは減る。

この性質は「増えないが減る」という片方向の安定性にすぎない。バッチ番号自体が同じメンバーを永続的に指すわけではない。別コマンドで部分的なバッチ範囲を計算すれば、その間の状態変化が境界に影響し得る。

そこで重複比較が役立つ。繰り返したバッチのUID範囲が合わなければ、クライアントは不整合の可能性を知る。ただし仕様は修復方法まで決めない。再取得するか、重複を広げるか、警告付きで進むか、厳格なエクスポートを止めるかはローカル判断である。

比較に成功しても完全なスナップショットが証明されたわけではない。重複は一つの観測窓を与えるだけだ。製品が重複分を早々に捨てれば、整合性を調べる根拠も同時に失う。

UIDの端点は存在証明にならない

サーバーが返す範囲の開始UIDと終了UIDは、実在するメッセージに対応しなくてよい。削除で番号に穴が残るため、広い数値区間がおおむね要求件数の実在メッセージを覆うことがある。

最終バッチをUID 1で終えることもできる。最古の実在UIDが302でも、1は「ここが最後の範囲である」と明確にする境界であり、UID 1のメッセージを主張しない。

したがって端点の差から件数を計算できない。区間内の番号を列挙して存在メッセージ扱いすることもできない。UIDBATCHES応答は後続処理の範囲指定であり、メンバー一覧はFETCHやSEARCHの実応答に属する。

この区別はSEARCHRESにも現れる。UIDBATCHESはSEARCHでもUID SEARCHでもなく、結果を$へ保存してはならない。PARTIALが提供するページ化SEARCH/FETCHとも役割が違う。似たクライアント実装を共有できても、証拠の意味は同じにならない。

同じ件数でも仕事は等しくない

クライアントは最低500件を要求する。サーバーは要求数を超えるメッセージを一範囲に含めてはならず、通常は要求値、可能なら90%以上を目指す。ただし実装が大きく簡単または効率的になる場合や計算中にメールボックスが変化した場合、少なく返せる。最後のバッチは余りになる。

これは件数の制約である。500通の短い通知と500通の大容量添付は同じ転送量ではない。ヘッダー取得と本文取得、索引済み検索と全件走査、読み取りとフラグ更新では処理も異なる。

RFCは仕事量やメモリー、応答データを減らし得る最適化として説明するが、一定の遅延やバイト数は約束しない。batch_size=2000を「一定コスト」と表示するのは、入力値を測定結果に変える誤りである。

クライアントは実メッセージ数、応答バイト、サーバー時間、クライアント時間、命令種別、失敗と再試行を記録すべきだ。ユーザー体験を守るなら、調整対象は実測した完了時間や進捗でなければならない。

再計算には理由が必要である

バッチ計算はサーバー資源を使う。RFC 10022は、別メールボックスを選択した場合、バッチサイズの半分を超える削除があった場合、または半バッチを超える新着があった場合に再実行を適切とする。それ以外ではクライアントは再送してはならない。

サーバー側もクライアントの善意だけに頼らず制限を実施することが推奨される。過剰な再計算は資源枯渇を起こし得るからだ。

記録すべきなのは「更新した」という事実ではない。前回からのEXPUNGE、VANISHED、EXISTSの変化、元のバッチサイズ、閾値、実行を許した条件である。これがなければ正当な再計算と不具合ループを区別できない。

選択メールボックスとUIDVALIDITYも不可欠だ。UIDはその組み合わせの中で意味を持つ。別メールボックスや新しいUIDVALIDITYへキャッシュ範囲を持ち込めば、古いページではなく、識別根拠を失った参照になる。

空の成功と資源上限

空メールボックスへの有効なUIDBATCHESは、範囲なしの応答とOKを返す。存在しないバッチ番号を要求した場合も同じ形になる。応答だけでは空メールボックスと範囲外を区別できない。

コマンドタグ、要求したインデックス、選択時のEXISTSを結び付ける必要がある。「0バッチ」という一つの表示に縮めれば、次の処置を決める原因が消える。

範囲付き要求は100,000メッセージを超えてはならない。サーバーは少なくともその範囲を扱える必要があるが、超過にはTOOMANYを返せる。巨大メールボックスですべての範囲を求めた場合も拒否できる。MESSAGELIMITがあれば、クライアントは一命令の上限を超えないバッチにすべきだ。

最低500件という制約は、UIDONLYの意図も守る。極小バッチで細かな位置情報を復元する使い方を防ぐためである。TOOFEW、TOOMANY、LIMITを一般エラーとして即時再試行するのは、保護機構を無視する行為になる。

Daniel Eggertの記録を実装証明にしない

2026年9月1日の取得時点で、IETF DatatrackerのDaniel EggertプロフィールはRFC 10022とRFC 9979を掲載していた。2022年のSwift.org記事は、EggertをiOSとmacOSのMailに取り組むAppleチームの一員とし、公開GitHub本人ページにリンクしている。

これは時点付きの職歴であって、特定製品のRFC 10022実装を証明しない。Eggertが本番サーバーの挙動を決めることも、IETF合意を所有することも示さない。編集、実装、運用は別々の責任である。

RFCの価値は、共有すべき最小限を定めた点にある。サーバーは計算方法を、クライアントは計画と不整合処理を、運用者はサービス判定を持つ。Heng LuのMinimum Initial SpecificationとRunning-Code Primacyを当てはめれば、共通範囲は調整の出発点であり、実行結果が最終の現実層になる。

調査に耐えるバッチ受領書

サーバー、アカウント境界、選択メールボックス、UIDVALIDITY、能力を記録する。タグ、要求件数、バッチ範囲、応答コード、返却UID範囲を続ける。EXISTS、EXPUNGE、VANISHEDと再計算理由、重複境界の比較を結ぶ。

さらに後続命令、実在UID、欠落、バイト、処理時間、再試行、ローカルチェックポイント、利用者に見えた結果まで追う。本文や認証情報を公開する必要はない。限定識別子、件数、ハッシュ、時刻、結果コードで判断経路は残せる。

この受領書があれば、UID範囲は効率的な分割のまま、安定ページのふりをしなくて済む。

出典