Internet Engineering Task Force (IETF) D. Eggert, Ed.
Request for Comments: 10022 Apple Inc
Category: Standards Track July 2026
ISSN: 2070-1721
The UIDBATCHES extension of the Internet Message Access Protocol (IMAP) allows clients to retrieve Unique Identifier (UID) ranges that partition a mailbox's messages into equally sized batches. This enables clients to perform operations such as FETCH, SEARCH, and STORE on specific message batches, providing better control over resource usage and response sizes. The extension is particularly useful with the UIDONLY mode where sequence numbers are unavailable.
インターネット メッセージ アクセス プロトコル (IMAP) の UIDBATCHES 拡張機能を使用すると、クライアントはメールボックスのメッセージを同じサイズのバッチに分割する一意の識別子 (UID) 範囲を取得できます。これにより、クライアントは特定のメッセージ バッチに対して FETCH、SEARCH、STORE などの操作を実行できるようになり、リソースの使用量と応答サイズをより適切に制御できるようになります。この拡張機能は、シーケンス番号が使用できない UIDONLY モードで特に便利です。
This is an Internet Standards Track document.
これはインターネット標準化トラックの文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されました。インターネット標準の詳細については、RFC 7841 のセクション 2 を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc10022.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc10022 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。この文書から抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
2. Document Conventions
3. The UIDBATCHES Extension
3.1. UIDBATCHES Command
3.1.1. Example Usage
3.1.2. Response Format
3.1.3. Batch Sizes
3.1.4. UIDs
3.1.5. Batch Ranges
3.1.6. Empty Responses
3.1.7. Large Mailboxes
3.2. Interaction with MESSAGELIMIT Extension
3.3. Interaction with UIDONLY Extension
3.4. Interaction with SEARCHRES Extension
4. Formal Syntax
5. Operational Considerations
6. Security Considerations
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Appendix A. Comparison with Existing Commands and Extensions
A.1. Similarity to UID SEARCH Command
A.2. Similarity to PARTIAL Extension
Author's Address
This document defines an extension to the Internet Message Access Protocol (IMAP) [RFC9051] that enables clients to retrieve UID ranges that partition a mailbox's messages into evenly sized batches. This extension is compatible with both IMAP4rev1 [RFC3501] and IMAP4rev2 [RFC9051].
この文書は、クライアントがメールボックスのメッセージを均等なサイズのバッチに分割する UID 範囲を取得できるようにするインターネット メッセージ アクセス プロトコル (IMAP) [RFC9051] の拡張機能を定義します。この拡張機能は、IMAP4rev1 [RFC3501] と IMAP4rev2 [RFC9051] の両方と互換性があります。
The primary purpose of this extension is to allow clients to predetermine UID ranges that limit the number of messages each command operates on. This capability is especially beneficial when used with the UIDONLY mode [RFC9586], where sequence numbers are unavailable to the client, making it difficult to create message batches using conventional methods.
この拡張機能の主な目的は、クライアントが各コマンドが処理するメッセージの数を制限する UID 範囲を事前に決定できるようにすることです。この機能は、クライアントがシーケンス番号を利用できないため、従来の方法を使用してメッセージ バッチを作成することが困難になる UIDONLY モード [RFC9586] で使用する場合に特に有益です。
In protocol examples, "C:" indicates lines sent by a client that is connected to a server and "S:" indicates lines sent by the server to the client. These prefixes are not part of the protocol. Long lines in examples are wrapped using "The Single Backslash Strategy" described in [RFC8792].
プロトコルの例では、「C:」はサーバーに接続されているクライアントから送信される行を示し、「S:」はサーバーからクライアントに送信される行を示します。これらのプレフィックスはプロトコルの一部ではありません。例内の長い行は、[RFC8792] で説明されている「単一バックスラッシュ戦略」を使用して折り返されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
Other capitalized words are IMAP keywords [RFC9051] or keywords from this document.
他の大文字の単語は、IMAP キーワード [RFC9051] またはこの文書のキーワードです。
An IMAP server advertises support for the UIDBATCHES extension by including the UIDBATCHES capability in the CAPABILITY response / response code.
IMAP サーバーは、CAPABILITY 応答/応答コードに UIDBATCHES 機能を含めることによって、UIDBATCHES 拡張機能のサポートをアドバタイズします。
Arguments:
引数:
Message count per batch.
バッチごとのメッセージ数。
OPTIONAL batch range.
オプションのバッチ範囲。
Responses:
回答:
REQUIRED untagged response: UIDBATCHES
必須のタグなし応答: UIDBATCHES
Result:
結果：
OK uidbatches completed
OK uidbatch が完了しました
NO command exceeds limits
NO コマンドが制限を超えています
BAD command unknown or arguments invalid
不正なコマンドが不明、または引数が無効です
The UIDBATCHES command requests UID ranges that partition the messages in the currently selected mailbox into equally sized batches. The server returns these ranges in descending UID order, with batch 1 containing the highest UIDs (most recent messages), batch 2 containing the next highest set of UIDs, and so on.
UIDBATCHES コマンドは、現在選択されているメールボックス内のメッセージを同じサイズのバッチに分割する UID 範囲を要求します。サーバーはこれらの範囲を UID の降順で返します。バッチ 1 には最も高い UID (最新のメッセージ) が含まれ、バッチ 2 には次に高い UID セットが含まれます。
For a mailbox with M messages, requesting batches of size N returns UID ranges corresponding to the following sequence number ranges (where sequence numbers are ordered from 1 to M, with M being the most recent message):
M 個のメッセージを含むメールボックスの場合、サイズ N のバッチを要求すると、次のシーケンス番号範囲に対応する UID 範囲が返されます (シーケンス番号は 1 から M の順序で、M が最新のメッセージです)。
Batch 1: M:(M-N+1) // Most recent N messages
Batch 2: (M-N):(M-2*N+1) // Next N messages
Batch 3: (M-2*N):(M-3*N+1) // Next N messages
...and so on
The following example demonstrates how a client uses UIDBATCHES to partition a mailbox into manageable batches:
次の例は、クライアントが UIDBATCHES を使用してメールボックスを管理可能なバッチに分割する方法を示しています。
========== NOTE: '\' line wrapping per RFC 8792 ===========
C: A142 SELECT INBOX
S: * 6823 EXISTS
S: * 1 RECENT
S: * OK [UNSEEN 12] Message 12 is first unseen
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * OK [UIDNEXT 215296] Predicted next UID
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
S: A142 OK [READ-WRITE] SELECT completed
C: A143 UIDBATCHES 2000
S: * UIDBATCHES (TAG "A143") \
215295:99696,99695:20351,20350:7830,7829:1
S: A143 OK UIDBATCHES Completed
The server's response provides four UID ranges:
サーバーの応答では、次の 4 つの UID 範囲が提供されます。
1. 215295:99696
1. 215295:99696
2. 99695:20351
2. 99695:20351
3. 20350:7830
3. 20350:7830
4. 7829:1
4. 7829:1
Each range contains up to 2,000 messages, except the last range, which contains the remaining 823 messages.
各範囲には最大 2,000 個のメッセージが含まれます。ただし、最後の範囲には残りの 823 個のメッセージが含まれます。
As new messages cannot appear within these UID ranges, the number of messages in each range will not increase. However, it may decrease as messages are deleted.
これらの UID 範囲内には新しいメッセージが表示されないため、各範囲内のメッセージの数は増加しません。ただし、メッセージが削除されると減少する可能性があります。
It is only appropriate to resend UIDBATCHES if one of the following conditions is met:
UIDBATCHES を再送信するのは、次の条件のいずれかが満たされる場合にのみ適切です。
1. A different mailbox has been selected
1. 別のメールボックスが選択されています
2. More than N/2 messages have been expunged from the mailbox (where N is the batch size)
2. N/2 を超えるメッセージがメールボックスから削除されました (N はバッチ サイズです)
3. More than N/2 new messages have been received into the mailbox
3. N/2 を超える新しいメッセージがメールボックスに受信されました
To prevent server overload, the client MUST NOT resend UIDBATCHES otherwise.
サーバーの過負荷を防ぐために、クライアントはそれ以外の場合に UIDBATCHES を再送信してはなりません。
Computing message batches may be resource-intensive for servers.
メッセージ バッチの計算はサーバーのリソースを大量に消費する可能性があります。
The client can keep track of the number of EXPUNGE or VANISHED messages and re-run UIDBATCHES if many messages are deleted.
クライアントは、EXPUNGE または VANISHED メッセージの数を追跡し、多くのメッセージが削除された場合には UIDBATCHES を再実行できます。
As new messages arrive into the mailbox, the client should add these to a new message batch (starting at UID 215296 in the above example). Once N/2 or more new messages have been added to the mailbox, the client MAY ask for updated batches by re-running the UIDBATCHES command.
新しいメッセージがメールボックスに到着すると、クライアントはこれらを新しいメッセージ バッチ (上の例では UID 215296 から始まる) に追加する必要があります。N/2 個以上の新しいメッセージがメールボックスに追加されると、クライアントは UIDBATCHES コマンドを再実行して更新されたバッチを要求してもよい(MAY)。
The server SHOULD reject UIDBATCHES commands with a NO response with the LIMIT response code if the client exceeds this limit. Servers MAY choose to track client requests and mailbox state changes to enforce these restrictions and prevent resource abuse.
クライアントがこの制限を超えた場合、サーバーは UIDBATCHES コマンドを LIMIT 応答コード付きの NO 応答で拒否する必要があります (SHOULD)。サーバーは、これらの制限を強制し、リソースの乱用を防ぐために、クライアントのリクエストとメールボックスの状態の変化を追跡することを選択してもよい(MAY)。
The server MUST reply with a UIDBATCHES response, even if no ranges are returned (see Section 3.1.6). The UIDBATCHES response MUST include the tag of the command it relates to (similar to an ESEARCH response defined in [RFC4731]).
サーバーは、範囲が返されない場合でも、UIDBATCHES 応答で応答しなければなりません (セクション 3.1.6 を参照)。UIDBATCHES 応答には、関連するコマンドのタグが含まれなければなりません ([RFC4731] で定義されている ESEARCH 応答と同様)。
The UID ranges in the response MUST be ordered in descending sequence, from the highest to the lowest UIDs.
応答内の UID 範囲は、最高の UID から最低の UID まで降順に並べる必要があります。
To ensure efficient server operation and prevent abuse, this extension enforces constraints on batch sizes. The design balances server efficiency requirements with the primary use case of working effectively with the UIDONLY mode [RFC9586], without creating a mechanism that circumvents the sequence number restrictions of that mode.
サーバーの効率的な運用を確保し、悪用を防止するために、この拡張機能はバッチ サイズの制約を強制します。この設計では、モードのシーケンス番号制限を回避するメカニズムを作成せずに、UIDONLY モード [RFC9586] を効果的に使用する主な使用例とサーバー効率の要件のバランスをとります。
The following table provides a quick reference for batch size constraints:
次の表は、バッチ サイズの制約に関するクイック リファレンスを示しています。
+============+================+==================================+
| Constraint | Client Request | Server Response |
+============+================+==================================+
| Minimum | 500 messages | Aim for >= 90% of requested size |
+------------+----------------+----------------------------------+
| Maximum | No limit | Never exceed requested size |
+------------+----------------+----------------------------------+
| Exception | - | May be smaller during mailbox |
| | | changes |
+------------+----------------+----------------------------------+
Table 1: Batch Size Constraints
表 1: バッチ サイズの制約
Key principles:
重要な原則:
* Clients MUST request at least 500 messages per batch (see Sections 3.1.3.4 and 3.3)
* クライアントはバッチごとに少なくとも 500 のメッセージを要求しなければなりません (セクション 3.1.3.4 および 3.3 を参照)
* Servers MUST NOT return more messages than requested
* サーバーは要求された以上のメッセージを返してはなりません
* Servers SHOULD return batches close to the requested size (>= 90% when possible)
* サーバーは、要求されたサイズに近いバッチ (可能な場合は >= 90%) を返す必要があります。
* Exact batch sizes may vary due to implementation efficiency or mailbox changes
* 正確なバッチ サイズは、実装効率やメールボックスの変更により異なる場合があります。
The server MUST support batch sizes of 500 messages or larger. This minimum size prevents clients from misusing the extension to effectively reconstruct sequence numbers while still allowing reasonable batch operations.
サーバーは 500 メッセージ以上のバッチ サイズをサポートしなければなりません。この最小サイズにより、クライアントが拡張機能を悪用してシーケンス番号を効果的に再構築すると同時に、合理的なバッチ操作が可能になるのを防ぎます。
Note that clients MUST be prepared to handle batches smaller than requested, as detailed in Section 3.1.3.3.
セクション 3.1.3.3 で詳述されているように、クライアントは要求されたバッチよりも小さいバッチを処理できるように準備しなければならないことに注意してください。
The server MUST respond with NO and a response code TOOFEW if the client uses a batch size smaller than the minimum allowed by the server:
クライアントがサーバーで許可されている最小値より小さいバッチ サイズを使用する場合、サーバーは NO と応答コード TOOFEW で応答しなければなりません。
S: A302 NO [TOOFEW] Minimum batch size is 500
While servers SHOULD return batches that correspond exactly to the requested size, they have flexibility in specific circumstances to enable efficient implementations.
サーバーは、要求されたサイズに正確に対応するバッチを返す必要がありますが、特定の状況では効率的な実装を可能にする柔軟性を備えています。
The server MUST NOT return ranges that contain more than the number of messages per batch requested by the client. This is a strict upper bound that cannot be exceeded.
サーバーは、クライアントが要求したバッチごとのメッセージ数を超える範囲を返してはなりません (MUST NOT)。これは超えることのできない厳密な上限です。
If the requested batch size equals or exceeds the total number of messages in the mailbox, the server MUST return a single UID range spanning all messages.
要求されたバッチ サイズがメールボックス内のメッセージの総数以上の場合、サーバーはすべてのメッセージにわたる単一の UID 範囲を返さなければなりません (MUST)。
Servers MAY return fewer messages per range in two specific circumstances:
サーバーは、次の 2 つの特定の状況では、範囲ごとに返すメッセージの数が少なくてもよい (MAY)。
1. When doing so makes the implementation substantially simpler and/ or more efficient
1. そうすることで、実装が大幅に簡素化および/または効率化されます。
2. When there are changes in mailbox state during the execution of the UIDBATCHES command, particularly when messages are expunged
2. UIDBATCHES コマンドの実行中にメールボックスの状態に変化があったとき、特にメッセージが消去されたとき
However, servers SHOULD NOT return batches that are substantially smaller than requested and SHOULD aim to stay within 90% of the requested size. This guideline reflects the fact that clients typically choose batch sizes based on their intended use, such as displaying a specific number of messages to users.
ただし、サーバーは要求されたサイズよりも大幅に小さいバッチを返してはならず、要求されたサイズの 90% 以内に収まるようにする必要があります (SHOULD)。このガイドラインは、クライアントが通常、特定の数のメッセージをユーザーに表示するなど、使用目的に基づいてバッチ サイズを選択するという事実を反映しています。
Mailbox state changes during UIDBATCHES execution can result in servers returning substantially fewer messages in each batch, particularly when message expungement reduces the overall mailbox size. Clients can detect these situations through the EXPUNGE, VANISHED, or EXISTS responses they receive.
UIDBATCHES の実行中にメールボックスの状態が変化すると、特にメッセージの消去によってメールボックス全体のサイズが小さくなった場合、サーバーが各バッチで返すメッセージが大幅に少なくなる可能性があります。クライアントは、受信する EXPUNGE、VANISHED、または EXISTS 応答を通じてこれらの状況を検出できます。
Due to these flexibility provisions, servers may return batches of varying sizes. For instance, when returning 3 batches of a requested size of 1,000, one might contain 990 messages, another 977, and the third 1,000 messages. Clients MUST be prepared to handle such variations.
これらの柔軟性の規定により、サーバーはさまざまなサイズのバッチを返す場合があります。たとえば、要求されたサイズが 1,000 の 3 つのバッチを返す場合、1 つは 990 のメッセージ、もう 1 つは 977 のメッセージ、そして 3 番目のバッチは 1,000 のメッセージを含む可能性があります。クライアントは、そのような変化に対処する準備をしておく必要があります。
When the total number of messages is not evenly divisible by the requested batch size, the final batch will contain the remainder. Therefore, the last batch in the mailbox (containing the lowest UIDs) will typically have fewer messages than requested.
メッセージの総数が要求されたバッチ サイズで割り切れない場合、最終バッチには残りが含まれます。したがって、メールボックス内の最後のバッチ (最も低い UID を含む) には通常、要求されたメッセージよりも少ないメッセージが含まれます。
These restrictions provide servers with implementation flexibility while preventing clients from misusing the extension to effectively reconstruct sequence numbers. Appendix A.1 also outlines some reasoning for these limitations.
これらの制限により、サーバーは柔軟な実装が可能になると同時に、クライアントが拡張機能を誤って使用してシーケンス番号を効果的に再構成することを防ぎます。付録 A.1 では、これらの制限の理由についても概説します。
The flexibility regarding batch sizes is designed to enable efficient server implementations while maintaining predictable behavior for clients. This leeway is not intended as a general permission to return arbitrarily sized batches but rather to accommodate implementation constraints and dynamic mailbox changes.
バッチ サイズに関する柔軟性は、クライアントの予測可能な動作を維持しながら効率的なサーバー実装を可能にするように設計されています。この余裕は、任意のサイズのバッチを返すための一般的な許可を意図したものではなく、実装の制約と動的なメールボックスの変更に対応することを目的としています。
The server MAY return UID ranges with UIDs that do not exist on the server. As a result, the client MUST NOT make assumptions about the existence of messages. If the server returns the response:
サーバーは、サーバー上に存在しない UID を含む UID 範囲を返すことができます (MAY)。したがって、クライアントはメッセージの存在について仮定を行ってはなりません (MUST NOT)。サーバーが応答を返した場合:
========== NOTE: '\' line wrapping per RFC 8792 ===========
S: * UIDBATCHES (TAG "A302") \
163886:99703,99696:20358,20351:7841,7830:1
S: A302 OK UIDBATCHES Completed
there may not be any messages on the server with the UIDs such as 163886, 99703, 99696, etc.
163886、99703、99696 などの UID を持つメッセージがサーバー上に存在しない可能性があります。
The range 163886:99703 will span approximately the requested number of messages (may be less, see Section 3.1.3), but its start and end UIDs may not correspond to messages on the server.
範囲 163886:99703 は、要求されたメッセージ数とほぼ同じになります (これより少ない場合があります。セクション 3.1.3 を参照) が、その開始 UID と終了 UID がサーバー上のメッセージに対応していない可能性があります。
This gives the server implementation some flexibility as to which UID ranges to return. They might, e.g., return 163886:99697 and 99696:20358 instead of 163886:99703 and 99696:20358 -- assuming that there are no messages in the range 99702:99697.
これにより、サーバー実装はどの UID 範囲を返すかについてある程度の柔軟性が得られます。たとえば、99702:99697 の範囲にメッセージがないと仮定すると、163886:99703 と 99696:20358 の代わりに 163886:99697 と 99696:20358 が返される可能性があります。
If there are fewer messages in the mailbox than the requested batch size, the server would return a single batch that contains all messages in the mailbox.
メールボックス内のメッセージが要求されたバッチ サイズよりも少ない場合、サーバーはメールボックス内のすべてのメッセージを含む単一のバッチを返します。
When applying the flexibility described above to the last batch in the mailbox, ending that batch with UID 1 makes it unambiguous to the client that this range is in fact the last range. For example, if the message with the lowest UID is 302, the server can return 7829:1 instead of 7829:302.
メールボックス内の最後のバッチに上記の柔軟性を適用する場合、そのバッチを UID 1 で終了すると、クライアントにとってこの範囲が実際に最後の範囲であることが明確になります。たとえば、最小の UID を持つメッセージが 302 の場合、サーバーは 7829:302 の代わりに 7829:1 を返すことができます。
A client can optionally provide a batch range. The server limits its response to UID ranges corresponding to the specified batch indices. For example, if the client sends:
クライアントはオプションでバッチ範囲を提供できます。サーバーは、指定されたバッチ インデックスに対応する UID 範囲に応答を制限します。たとえば、クライアントが次を送信するとします。
C: A302 UIDBATCHES 2000 10:20
for a mailbox with 100,000 messages, the server would return the 10th to 20th batches. The 10th batch would correspond to message sequence numbers `82000:80001` and the 20th batch would correspond to message sequence numbers `62000:60001`.
100,000 件のメッセージを含むメールボックスの場合、サーバーは 10 番目から 20 番目のバッチを返します。10 番目のバッチはメッセージ シーケンス番号 '82000:80001' に対応し、20 番目のバッチはメッセージ シーケンス番号 '62000:60001' に対応します。
Batches start at the highest UIDs, i.e., batch 1 is the batch with the highest UIDs.
バッチは最も高い UID から始まります。つまり、バッチ 1 が最も高い UID を持つバッチです。
The UID ranges that the server returns would still split the mailbox's messages into batches of the requested size (2,000 in the example).
サーバーが返す UID 範囲は、メールボックスのメッセージを要求されたサイズ (この例では 2,000) のバッチに分割します。
If the client requests more batches than exist on the server, the server would return those that do exist. For example, if the client sends:
クライアントがサーバー上に存在するバッチよりも多くのバッチを要求した場合、サーバーは存在するバッチを返します。たとえば、クライアントが次を送信するとします。
C: A302 UIDBATCHES 2000 1:5
and the selected mailbox has 7,000 messages, the server would then return a UIDBATCHES response with only 4 UID ranges.
選択したメールボックスに 7,000 件のメッセージがある場合、サーバーは 4 つの UID 範囲のみを含む UIDBATCHES 応答を返します。
Batch ranges such as 1:4 in the above example MUST be ordered lowest to highest, i.e., be sent as 1:4 and not as 4:1. Servers MUST reject batch ranges that are in the wrong order with BAD and a response code CLIENTBUG:
上記の例の 1:4 などのバッチ範囲は、最小値から最大値の順に並べる必要があります。つまり、4:1 ではなく 1:4 として送信する必要があります。サーバーは、順序が間違っているバッチ範囲を BAD および応答コード CLIENTBUG で拒否しなければなりません。
C: A302 UIDBATCHES 2000 4:1
S: A302 BAD [CLIENTBUG] Invalid batch range
If the client requests a range of batches that do not exist on the server, the server MUST still return an empty response. See Section 3.1.6.
クライアントがサーバー上に存在しないバッチ範囲を要求した場合でも、サーバーは空の応答を返さなければなりません(MUST)。セクション 3.1.6 を参照してください。
The number of messages per batch returned by the server may be approximate, as detailed in Section 3.1.3. As a result, if the client needs to request consecutive batch ranges such as 1:100, 101:200, 201:300, and so on, the client may want to make these batch ranges overlap by, e.g., requesting 1:100, 100:200, and 200:300. While the UIDs returned may not correspond to existing messages (as described in Section 3.1.4) and mailbox state can change between requests, checking whether the returned UID ranges overlap can help clients detect potential inconsistencies, though how to handle such situations depends on the specific client implementation requirements.
セクション 3.1.3 で詳しく説明されているように、サーバーから返されるバッチあたりのメッセージ数は概算である可能性があります。その結果、クライアントが 1:100、101:200、201:300 などの連続するバッチ範囲をリクエストする必要がある場合、クライアントは、たとえば 1:100、100:200、および 200:300 をリクエストすることで、これらのバッチ範囲を重複させたい場合があります。返された UID は既存のメッセージに対応していない可能性があり (セクション 3.1.4 で説明)、メールボックスの状態はリクエスト間で変化する可能性がありますが、返された UID 範囲が重複しているかどうかをチェックすることは、クライアントが潜在的な不一致を検出するのに役立ちますが、そのような状況を処理する方法は特定のクライアント実装要件によって異なります。
Clients MUST NOT request batch ranges that span more than 100,000 messages, i.e., the number of batches multiplied by the batch size MUST NOT be larger than 100,000. This restriction applies only when a batch range is specified; when no batch range is provided, the client is requesting all batches but the server may limit its response as described in Section 3.1.7. The server MAY reject UIDBATCHES commands with a NO response with the TOOMANY response code if the client exceeds this limit.
クライアントは、100,000 メッセージを超えるバッチ範囲を要求してはなりません。つまり、バッチ数とバッチ サイズを掛けた値が 100,000 を超えてはなりません。この制限は、バッチ範囲が指定されている場合にのみ適用されます。バッチ範囲が指定されていない場合、クライアントはすべてのバッチを要求しますが、セクション 3.1.7 で説明されているようにサーバーはその応答を制限する場合があります。クライアントがこの制限を超えた場合、サーバーは、TOOMANY 応答コードを伴う NO 応答で UIDBATCHES コマンドを拒否してもよい(MAY)。
C: A302 UIDBATCHES 2000 1:100
S: A302 NO [TOOMANY] Too many messages
When the client issues any valid UIDBATCHES command and the mailbox is empty, the server MUST reply with a UIDBATCHES response, for example:
クライアントが有効な UIDBATCHES コマンドを発行し、メールボックスが空の場合、サーバーは次のような UIDBATCHES 応答で応答しなければなりません (MUST)。
S: * UIDBATCHES (TAG "A302")
S: A302 OK UIDBATCHES Completed
If the client requests a range of batches that do not exist, the server MUST reply with an empty UIDBATCHES response. If the mailbox has 7,000 messages, and the client sends:
クライアントが存在しないバッチ範囲を要求した場合、サーバーは空の UIDBATCHES 応答で応答しなければなりません (MUST)。メールボックスに 7,000 のメッセージがあり、クライアントが次を送信するとします。
C: A302 UIDBATCHES 2000 6:8
the server would respond with:
サーバーは次のように応答します。
S: * UIDBATCHES (TAG "A302")
S: A302 OK UIDBATCHES Completed
The server may not be able to return all UID ranges if the mailbox contains an extremely large number of messages.
メールボックスに非常に多くのメッセージが含まれている場合、サーバーはすべての UID 範囲を返せない場合があります。
The server MUST at least support returning UID ranges spanning 100,000 messages. See Section 3.1.5 for details on this limit.
サーバーは、少なくとも 100,000 メッセージにわたる UID 範囲を返すことをサポートしなければなりません。この制限の詳細については、セクション 3.1.5 を参照してください。
If the server cannot return all of the requested UID ranges, it MUST respond with a NO response with the TOOMANY response code. Notably, when the client requests all UID ranges and the mailbox has more than 100,000 messages, the server MAY reply with a NO response. For example:
サーバーが要求された UID 範囲のすべてを返すことができない場合は、TOOMANY 応答コードを含む NO 応答で応答しなければなりません (MUST)。特に、クライアントがすべての UID 範囲を要求し、メールボックスに 100,000 を超えるメッセージがある場合、サーバーは NO 応答を返してもよい(MAY)。例えば：
C: A302 UIDBATCHES 2000
S: A302 NO [TOOMANY] Too many messages in mailbox
The client should know what the message count in the mailbox is, and if the message count exceeds 100,000, it may choose to always request batch ranges as discussed in Section 3.1.5 instead of requesting all batches.
クライアントはメールボックス内のメッセージ数を知っている必要があり、メッセージ数が 100,000 を超える場合は、すべてのバッチを要求するのではなく、セクション 3.1.5 で説明したように常にバッチ範囲を要求することを選択できます。
When the server supports both the MESSAGELIMIT [RFC9738] and UIDBATCHES extension, the client SHOULD request batches no larger than the specified maximum number of messages that can be processed in a single command. The client MAY choose to use a smaller batch size.
サーバーが MESSAGELIMIT [RFC9738] と UIDBATCHES 拡張機能の両方をサポートする場合、クライアントは 1 つのコマンドで処理できる指定された最大メッセージ数を超えないバッチを要求する必要があります (SHOULD)。クライアントは、より小さいバッチ サイズの使用を選択してもよい(MAY)。
Additionally, since servers MAY limit the number of UIDs returned in response to UIDBATCHES, it is reasonable to assume that they would at most return N UIDs, where N is the limit the server announced as its MESSAGELIMIT.
さらに、サーバーは UIDBATCHES に応答して返される UID の数を制限してもよいため、最大でも N 個の UID を返すと想定するのが合理的です。ここで、N はサーバーが MESSAGELIMIT として発表した制限です。
The UIDBATCHES extension allows clients to create UID ranges for message batches even when the connection operates in UIDONLY mode, which otherwise doesn't allow for using message sequence numbers.
UIDBATCHES 拡張機能を使用すると、接続が UIDONLY モードで動作している場合でも、クライアントはメッセージ バッチの UID 範囲を作成できます。それ以外の場合は、メッセージ シーケンス番号を使用できません。
This interaction is particularly important because the UIDONLY extension disallows the use of sequence numbers. While the PARTIAL extension [RFC9394] provides paged SEARCH and FETCH operations, some clients need to predetermine UID ranges for batches upfront. UIDBATCHES enables such clients to use the same overall batching strategy, regardless of whether the server supports UIDONLY, PARTIAL, or neither, making client implementations simpler and more consistent.
UIDONLY 拡張機能ではシーケンス番号の使用が許可されていないため、この対話は特に重要です。PARTIAL 拡張 [RFC9394] はページングされた SEARCH および FETCH 操作を提供しますが、一部のクライアントはバッチの UID 範囲を事前に決定する必要があります。UIDBATCHES を使用すると、サーバーが UIDONLY、PARTIAL、またはどちらもサポートしていないかに関係なく、そのようなクライアントが同じ全体的なバッチ処理戦略を使用できるようになり、クライアントの実装がよりシンプルかつ一貫性のあるものになります。
When operating in UIDONLY mode, clients SHOULD use UIDBATCHES to determine appropriate UID ranges for batch operations rather than attempting to construct batches using sequence-number-based approaches that would violate UIDONLY restrictions.
UIDONLY モードで動作する場合、クライアントは、UIDONLY 制限に違反するシーケンス番号ベースのアプローチを使用してバッチを構築しようとするのではなく、UIDBATCHES を使用してバッチ操作に適切な UID 範囲を決定する必要があります (SHOULD)。
The batch size constraints defined in Section 3.1.3 serve dual purposes: ensuring server efficiency and preventing UIDBATCHES from becoming a mechanism to effectively reconstruct sequence numbers. Without these constraints, clients could request very small batch sizes to obtain fine-grained positional information about messages, which would circumvent the sequence number restrictions of UIDONLY mode. The extension is designed specifically to support the legitimate need of predetermining message batches upfront while maintaining the architectural intent of UIDONLY mode.
セクション 3.1.3 で定義されたバッチ サイズの制約は、サーバーの効率を確保することと、UIDBATCHES がシーケンス番号を効果的に再構築するメカニズムになるのを防ぐことという 2 つの目的に役立ちます。これらの制約がなければ、クライアントはメッセージに関する詳細な位置情報を取得するために非常に小さなバッチ サイズを要求する可能性があり、これにより UIDONLY モードのシーケンス番号制限が回避されます。この拡張機能は、UIDONLY モードのアーキテクチャ上の意図を維持しながら、事前にメッセージ バッチを事前に決定するという正当なニーズをサポートするように特別に設計されています。
UIDBATCHES is not a SEARCH nor UID SEARCH command. Servers that support SEARCHRES [RFC5182] MUST NOT store the result of UIDBATCHES in the $ variable.
UIDBATCHES は SEARCH コマンドでも UID SEARCH コマンドでもありません。SEARCHRES [RFC5182] をサポートするサーバーは、UIDBATCHES の結果を $ 変数に保存してはなりません (MUST NOT)。
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [RFC5234].
以下の構文仕様では、[RFC5234] で指定されている拡張バッカス・ナウア形式 (ABNF) 表記法を使用します。
Non-terminals referenced but not defined below are as defined by IMAP4 [RFC9051].
以下で参照されているが定義されていない非端末は、IMAP4 [RFC9051] で定義されているとおりです。
Except as noted otherwise, all alphabetic characters are case-insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion.
特に明記されていない限り、すべてのアルファベット文字は大文字と小文字が区別されません。トークン文字列の定義に大文字または小文字を使用するのは、編集をわかりやすくするためだけです。実装では、大文字と小文字を区別せずにこれらの文字列を受け入れなければなりません。
capability =/ "UIDBATCHES"
;; <capability> from [RFC9051]
command-select =/ message-batches
message-batches = "UIDBATCHES" SP nz-number
[SP nz-number ":" nz-number]
uidbatches-response = "UIDBATCHES" search-correlator
[SP uid-range *("," uid-range) ]
mailbox-data =/ uidbatches-response
resp-text-code =/ "TOOFEW" / "TOOMANY"
This document defines an optimization that can reduce both the amount of work performed by the server and the amount of data returned to the client. Use of this extension is likely to cause the server and the client to use less memory than when the extension is not used. However, as this is going to be new code in both the client and the server, rigorous testing of such code is required in order to avoid the introduction of new implementation bugs.
このドキュメントでは、サーバーによって実行される作業量とクライアントに返されるデータ量の両方を削減できる最適化を定義します。この拡張機能を使用すると、拡張機能を使用しない場合よりもサーバーとクライアントで使用されるメモリが少なくなる可能性があります。ただし、これはクライアントとサーバーの両方で新しいコードになるため、新しい実装バグの導入を避けるために、そのようなコードの厳密なテストが必要です。
This document defines an additional IMAP4 capability. As such, it does not change the underlying security considerations of IMAP4rev1 [RFC3501] and IMAP4rev2 [RFC9051]. The author and reviewers believe that no new security issues are introduced with this additional IMAP4 capability.
このドキュメントでは、追加の IMAP4 機能を定義します。したがって、IMAP4rev1 [RFC3501] および IMAP4rev2 [RFC9051] の根本的なセキュリティに関する考慮事項は変更されません。著者と査読者は、この追加の IMAP4 機能によって新たなセキュリティ問題が発生することはないと考えています。
One consideration during the design of this extension was the potential for clients to cause servers to perform excessive computational work by repeatedly requesting batch calculations. The restrictions on when clients may re-run UIDBATCHES (Section 3.1) and the batch size constraints (Section 3.1.3) are designed to mitigate this concern. Server implementations are strongly advised to implement enforcement of these rate-limiting restrictions rather than relying solely on client compliance. Servers SHOULD track UIDBATCHES requests per mailbox and reject requests that violate the conditions in Section 3.1, as failure to do so may allow malicious or buggy clients to cause resource exhaustion through repeated batch calculations. Servers may reject requests that exceed these limits with the LIMIT, TOOFEW, or TOOMANY response codes.
この拡張機能の設計時に考慮された点の 1 つは、クライアントがバッチ計算を繰り返し要求することで、サーバーに過剰な計算作業を実行させる可能性があるということでした。クライアントが UIDBATCHES を再実行できるタイミングに関する制限 (セクション 3.1) とバッチ サイズの制約 (セクション 3.1.3) は、この懸念を軽減するように設計されています。サーバー実装では、クライアントのコンプライアンスのみに依存するのではなく、これらのレート制限の強制を実装することを強くお勧めします。サーバーは、メールボックスごとに UIDBATCHES リクエストを追跡し、セクション 3.1 の条件に違反するリクエストを拒否する必要があります。そうしないと、悪意のあるクライアントやバグのあるクライアントがバッチ計算の繰り返しによってリソースを使い果たす可能性があるためです。サーバーは、これらの制限を超えるリクエストを LIMIT、TOOFEW、または TOOMANY 応答コードで拒否する場合があります。
As this extension involves new code in both clients and servers, rigorous testing of such code is required in order to avoid introducing new implementation bugs.
この拡張機能にはクライアントとサーバーの両方に新しいコードが含まれるため、新しい実装バグの導入を避けるために、そのようなコードの厳密なテストが必要です。
IANA has added the UIDBATCHES capability to the "Internet Message Access Protocol (IMAP) Capabilities Registry" (https://www.iana.org/assignments/imap4-capabilities), with a reference to this document.
IANA は、このドキュメントを参照して、「インターネット メッセージ アクセス プロトコル (IMAP) 機能レジストリ」(https://www.iana.org/assignments/imap4-capabilities) に UIDBATCHES 機能を追加しました。
IANA has added TOOMANY and TOOFEW to the "IMAP Response Codes" registry (https://www.iana.org/assignments/imap-response-codes), with a reference to this document.
IANA は、この文書を参照して、「IMAP 応答コード」レジストリ (https://www.iana.org/assignments/imap-response-codes) に TOOMANY と TOOFEW を追加しました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
<https://www.rfc-editor.org/info/rfc3501>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message
Access Protocol (IMAP) - Version 4rev2", RFC 9051,
DOI 10.17487/RFC9051, August 2021,
<https://www.rfc-editor.org/info/rfc9051>.
[RFC9738] Melnikov, A., Achuthan, A. P., Nagulakonda, V., and L.
Alves, "IMAP MESSAGELIMIT Extension", RFC 9738,
DOI 10.17487/RFC9738, March 2025,
<https://www.rfc-editor.org/info/rfc9738>.
[RFC4731] Melnikov, A. and D. Cridland, "IMAP4 Extension to SEARCH
Command for Controlling What Kind of Information Is
Returned", RFC 4731, DOI 10.17487/RFC4731, November 2006,
<https://www.rfc-editor.org/info/rfc4731>.
[RFC5182] Melnikov, A., "IMAP Extension for Referencing the Last
SEARCH Result", RFC 5182, DOI 10.17487/RFC5182, March
2008, <https://www.rfc-editor.org/info/rfc5182>.
[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
"Handling Long Lines in Content of Internet-Drafts and
RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
<https://www.rfc-editor.org/info/rfc8792>.
[RFC9394] Melnikov, A., Achuthan, A. P., Nagulakonda, V., and L.
Alves, "IMAP PARTIAL Extension for Paged SEARCH and
FETCH", RFC 9394, DOI 10.17487/RFC9394, June 2023,
<https://www.rfc-editor.org/info/rfc9394>.
[RFC9586] Melnikov, A., Achuthan, A. P., Nagulakonda, V., Singh, A.,
and L. Alves, "IMAP Extension for Using and Returning
Unique Identifiers (UIDs) Only", RFC 9586,
DOI 10.17487/RFC9586, May 2024,
<https://www.rfc-editor.org/info/rfc9586>.
UIDBATCHES is in effect nothing more than shorthand for a UID SEARCH command of the form
UIDBATCHES は、実質的には、次の形式の UID SEARCH コマンドの短縮表現にすぎません。
C: A145 UID SEARCH RETURN () <M>,<M-N>,<M-2*N>,<M-3*N>,...
where M is the number of messages in the mailbox and N is the requested batch count.
ここで、M はメールボックス内のメッセージの数、N は要求されたバッチ数です。
However, the special purpose UIDBATCHES command tries to address two problems:
ただし、特別な目的の UIDBATCHES コマンドは、次の 2 つの問題に対処しようとします。
1. For many servers, UID SEARCH commands specifying sequence numbers are costly, especially for mailboxes with many messages.
1. 多くのサーバーでは、特に多数のメッセージを含むメールボックスの場合、シーケンス番号を指定する UID SEARCH コマンドはコストがかかります。
2. The UIDONLY extension disallows the use of sequence numbers and thus makes it difficult for the client to split its commands into batches of a size that works well for the client and server.
2. UIDONLY 拡張機能ではシーケンス番号の使用が禁止されているため、クライアントがコマンドをクライアントとサーバーで適切に機能するサイズのバッチに分割することが困難になります。
By providing a special purpose command, servers can implement a different, optimized code path for determining message batches. And servers using the UIDONLY extension can provide a facility to let the client determine message batches without using sequence numbers in a UID SEARCH command.
特別な目的のコマンドを提供することにより、サーバーはメッセージ バッチを決定するための別の最適化されたコード パスを実装できます。また、UIDONLY 拡張機能を使用するサーバーは、UID SEARCH コマンドでシーケンス番号を使用せずにクライアントがメッセージ バッチを決定できる機能を提供できます。
Section 3.1.3 describes some implementation restrictions to ensure this.
セクション 3.1.3 では、これを確実にするための実装上の制限について説明します。
The PARTIAL extension in [RFC9394] provides a different way for the client to split its commands into batches by using paged SEARCH and FETCH.
[RFC9394] の PARTIAL 拡張機能は、ページングされた SEARCH および FETCH を使用して、クライアントがコマンドをバッチに分割する別の方法を提供します。
The intention of the UIDBATCHES command is to let the client predetermine message batches of a desired size.
UIDBATCHES コマンドの目的は、クライアントが希望するサイズのメッセージ バッチを事前に決定できるようにすることです。
This makes it easier for the client to share implementation between servers, regardless of their support of PARTIAL. And additionally, because the client can issue a corresponding UID SEARCH command to servers that do not implement UIDBATCHES, the client can use similar batching implementations for servers that support UIDBATCHES and those that do not.
これにより、クライアントが PARTIAL をサポートしているかどうかに関係なく、サーバー間で実装を共有することが容易になります。さらに、クライアントは UIDBATCHES を実装していないサーバーに対応する UID SEARCH コマンドを発行できるため、クライアントは UIDBATCHES をサポートするサーバーとサポートしないサーバーに対して同様のバッチ処理実装を使用できます。
Daniel Eggert (editor)
Apple Inc
One Apple Park Way
Cupertino, CA 95014
United States of America
Email: deggert@apple.com