Internet Engineering Task Force (IETF) A. Melnikov
Request for Comments: 9738 Isode
Category: Experimental A. P. Achuthan
ISSN: 2070-1721 V. Nagulakonda
Yahoo!
L. Alves
March 2025
The MESSAGELIMIT extension of the Internet Message Access Protocol (RFCs 3501 and 9051) allows servers to announce a limit on the number of messages that can be processed in a single FETCH, SEARCH, STORE, COPY, or MOVE command (or their UID variants), or in a single APPEND or UID EXPUNGE command. This helps servers to control resource usage when performing various IMAP operations. This helps clients to know the message limit enforced by the corresponding IMAP server and avoid issuing commands that would exceed such limit.
インターネットメッセージアクセスプロトコル（RFCS 3501および9051）のMESSAGELIMIT拡張機能により、サーバーは、単一のフェッチ、検索、保存、コピー、または移動コマンド（またはUIDバリエーション）、または単一の付録またはUID ead ead excungeコマンドで処理できるメッセージの数の制限を発表できます。これにより、さまざまなIMAP操作を実行するときにサーバーがリソースの使用を制御するのに役立ちます。これにより、クライアントは、対応するIMAPサーバーによって実施されたメッセージ制限を知ることができ、そのような制限を超えるコマンドの発行を避けることができます。
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントは、インターネット標準の追跡仕様ではありません。試験、実験的実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントでは、インターネットコミュニティ向けの実験プロトコルを定義しています。このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。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/rfc9738.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9738で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 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ドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。この資料の一部の著作権を管理する人は、IETFの信頼にIETF標準プロセス以外のそのような資料の変更を許可する権利を認めていない可能性があります。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、RFCとして公開したり、英語以外の言語に翻訳する場合を除き、IETF標準プロセスの外で作成されない場合があります。
1. Introduction and Overview
2. Document Conventions
3. The MESSAGELIMIT Extension
3.1. Returning Limits on the Number of Messages Processed in a
Single Command
3.2. UIDAFTER and UIDBEFORE SEARCH Criteria
3.3. Interaction with SORT and THREAD Extensions
3.4. Interaction with SEARCHRES Extension and IMAP4rev2
4. Interoperability Considerations
4.1. Effects of MESSAGELIMIT and SAVELIMIT Extensions on
Noncompliant Clients
4.2. Maintaining Compatibility
5. Formal Syntax
6. Security Considerations
7. IANA Considerations
7.1. Additions to the IMAP Capabilities Registry
8. References
8.1. Normative References
8.2. Informative References
Acknowledgments
Authors' Addresses
This document defines an extension to the Internet Message Access Protocol [RFC9051] for announcing a server limit on the number of messages that can be processed in a single FETCH, SEARCH, STORE, COPY, or MOVE command (or their UID variants), or a single APPEND or UID EXPUNGE command. This extension is compatible with both IMAP4rev1 [RFC3501] and IMAP4rev2 [RFC9051].
このドキュメントでは、単一のフェッチ、検索、ストア、コピー、または移動コマンド（またはUIDバリアント）で処理できるメッセージの数のサーバー制限（またはUIDバリアント）のサーバーの制限、または単一の追加またはUID ead expuntedコマンドを発表するために、インターネットメッセージアクセスプロトコル[RFC9051]の拡張機能を定義します。この拡張は、IMAP4REV1 [RFC3501]とIMAP4REV2 [RFC9051]の両方と互換性があります。
In protocol examples, this document uses a prefix of "C: " to denote lines sent by the client to the server, and "S: " for lines sent by the server to the client. Lines prefixed with "// " are comments explaining the previous protocol line. These prefixes and comments are not part of the protocol. Lines without any of these prefixes are continuations of the previous line, and no line break is present in the protocol unless specifically mentioned.
プロトコルの例では、このドキュメントでは「C：」のプレフィックスを使用して、クライアントからサーバーに送信された行、およびサーバーからクライアントに送信された行について「s：」を示します。「//」が付いた行は、以前のプロトコル行を説明するコメントです。これらのプレフィックスとコメントは、プロトコルの一部ではありません。これらのプレフィックスのない線は、前の行の継続であり、具体的に言及されていない限り、プロトコルにはラインブレークは存在しません。
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 key words [RFC3501][RFC9051] or key words from this document.
その他の大文字の単語は、IMAPキーワード[RFC3501] [RFC9051]またはこのドキュメントのキーワードです。
An IMAP server advertises support for the MESSAGELIMIT extension by including "MESSAGELIMIT=<limit>" capability in the CAPABILITY response or response code, where "<limit>" is a positive integer that conveys the maximum number of messages that can be processed in a single SEARCH, FETCH, STORE, COPY, MOVE command (or their UID variants), or in a single APPEND or UID EXPUNGE command.
IMAPサーバーは、「MessageLimit = <limit>」機能を含めることにより、MessageLimit拡張機能のサポートを宣伝します。ここで、「<limit>」は、単一の検索、保存、コピー、移動コマンド（またはuidバリエーション）、または単一のappendまたはuid ofconge commandで処理できるメッセージを伝える最大数のメッセージを伝える正の整数です。
An IMAP server that only enforces the message limit on COPY and APPEND commands (and their UID variants) would include the "SAVELIMIT=<limit>" capability (instead of the "MESSAGELIMIT=<limit>") in the CAPABILITY response or response code.
コピーと追加のコマンド（およびそのUIDバリアント）にメッセージ制限のみを実施するIMAPサーバーには、機能（savelimit = <limit>」機能（「messageLimit = <limed>」の代わりに）が機能または応答コードに含まれます。
The limit advertised in the MESSAGELIMIT or SAVELIMIT capability SHOULD NOT be lower than 1000 messages.
MessageLimitまたはSavelimit機能で宣伝されている制限は、1000のメッセージを超えてはなりません。
If a server implementation doesn't allow more than <N> messages to be operated on by a single COPY or UID COPY command, it MUST fail the command by returning a tagged NO response with the MESSAGELIMIT response code defined below. No messages are copied in this case. If a server implementation doesn't allow more than <N> messages to be operated on by a single SEARCH, FETCH, STORE, or MOVE command (or their UID variants), or an APPEND or UID EXPUNGE command, it MUST return the MESSAGELIMIT response code defined below:
サーバーの実装では、単一のコピーまたはUIDコピーコマンドで<n>メッセージを操作することを許可しない場合、以下に定義されたMessageLimit応答コードでタグ付けされた応答を返すことにより、コマンドに失敗する必要があります。この場合、メッセージはコピーされていません。サーバーの実装では、単一の検索、フェッチ、保存、または移動コマンド（またはuidバリアント）、またはappendまたはuid expungeコマンドによって<n>メッセージを操作することを許可しない場合は、以下に定義するmessageLimit応答コードを返す必要があります。
MESSAGELIMIT
Messagelimit
The server doesn't allow more than <N> messages to be operated on by a single SEARCH, FETCH, STORE, COPY, or MOVE command (or their UID variants). The lowest processed UID is <LastUID>. The client needs to repeat the operation for remaining messages, if required.
サーバーは、単一の検索、フェッチ、保存、コピー、または移動コマンド（またはそのUIDバリアント）によって<n>メッセージを操作することを許可しません。最低処理されたuidは<lastuid>です。必要に応じて、クライアントは残りのメッセージの操作を繰り返す必要があります。
The server doesn't allow more than <N> \Deleted messages to be operated on by a single UID EXPUNGE command. The lowest processed UID is <LastUID>. The client needs to repeat the operation for remaining messages, if required.
サーバーは、単一のuid expungeコマンドによって<n> \削除されたメッセージを操作することを許可しません。最低処理されたuidは<lastuid>です。必要に応じて、クライアントは残りのメッセージの操作を繰り返す必要があります。
Note that when the MESSAGELIMIT response code is returned, the server is REQUIRED to process messages from highest to lowest UID.
MessageLimit応答コードが返された場合、サーバーは最高のUIDから最低UIDまでメッセージを処理する必要があることに注意してください。
Note that the MESSAGELIMIT response code is similar to the LIMIT response code [RFC9051], but it provides more details on the exact type of the limit and how to resume the command once the limit is exceeded.
MessageLimit応答コードは制限応答コード[RFC9051]に似ているが、制限の正確なタイプと制限を超えた後のコマンドの再開方法の詳細を提供することに注意してください。
In the following example, the <N> value is 1000, and the lowest processed UID <LastUID> is 23221.
次の例では、<n>値は1000であり、最低処理されたuid <lastuid>は23221です。
C: 03 FETCH 10000:14589 (UID FLAGS)
S: * 14589 FETCH (FLAGS (\Seen) UID 25000)
S: * 14588 FETCH (FLAGS (\Answered) UID 24998)
S: ... further 997 fetch responses
S: * 13590 FETCH (FLAGS () UID 23221)
S: 03 OK [MESSAGELIMIT 1000 23221] FETCH completed with 1000
partial results
In the following example the client searches for UNDELETED UIDs between 22000:25000. The total number of searched messages (note, NOT the number of matched messages) exceeds the server's published 1000-message limit.
次の例では、クライアントは22000：25000の間に未定のUIDを検索します。検索されたメッセージの総数（注、一致したメッセージの数ではなく）は、公開されている1000メッセージの制限を超えています。
C: 04 UID SEARCH UID 22000:25000 UNDELETED
S: * SEARCH 25000 24998 (... UIDs ...) 23221
S: 04 OK [MESSAGELIMIT 1000 23221] SEARCH completed with 1000
partial results
The following example demonstrates the copy of messages with UIDs between 18000:21000. The total message count exceeds the server's published 1000-message limit. As COPY or UID COPY needs to be atomic (as per [RFC3501]/[RFC9051]), no messages are copied.
次の例は、18000：21000の間にUIDSを含むメッセージのコピーを示しています。合計メッセージ数は、サーバーの公開された1000メッセージの制限を超えています。コピーまたはUIDコピーはアトミックである必要があるため（[RFC3501]/[RFC9051]）、メッセージはコピーされません。
C: 05 UID COPY 18000:21000 "Trash"
S: 05 NO [MESSAGELIMIT 1000 20001] Too many messages to copy,
try a smaller subset
The following example shows the move of messages with UIDs between 18000:21000. The total message count exceeds the server's published 1000-message limit. (Unlike COPY or UID COPY, MOVE or UID MOVE don't need to be atomic.) The client that wants to move all messages in the range and observes a MESSAGELIMIT response code can repeat the UID MOVE command with the same parameter. (For the MOVE command, the message set parameter needs to be updated before repeating the command.) The client needs to keep doing this until the MESSAGELIMIT response is not returned (or until a tagged NO or BAD is returned).
次の例は、18000：21000の間のUIDを使用したメッセージの動きを示しています。合計メッセージ数は、サーバーの公開された1000メッセージの制限を超えています。（コピーまたはUIDコピー、移動、またはUID移動とは異なり、Atomicである必要はありません。）すべてのメッセージを範囲内のメッセージを移動し、MessageLimit応答コードを観察するクライアントは、同じパラメーターでUID Moveコマンドを繰り返すことができます。（MOVEコマンドの場合、コマンドを繰り返す前にメッセージセットパラメーターを更新する必要があります。）クライアントは、MessageLimit応答が返されるまで（またはタグ付けされたノーまたはバッドが返されるまで）これを続ける必要があります。
C: 06 UID MOVE 18000:21000 "Archive/2021/2021-12"
S: * OK [COPYUID 1397597919 20001:21000 22363:23362] Some
messages were not moved
S: * 12336 EXPUNGE
S: * 12335 EXPUNGE
...
S: * 11337 EXPUNGE
S: 06 OK [MESSAGELIMIT 1000 20001] MOVE completed for the last
1000 messages
The following example shows the update of flags for messages with UIDs between 18000:20000. The total number of existing messages in the UID range exceeds the server's published 1000-message limit. The client that wants to change flags for all messages in the range and observes a MESSAGELIMIT response code can repeat the UID STORE command with the updated UID range that doesn't include the UID returned in the MESSAGELIMIT response code. (For the STORE command, the message set parameter also needs to be updated before repeating the command.) The client needs to keep doing this until the MESSAGELIMIT response is not returned (or until a tagged NO or BAD is returned).
次の例は、18000：20000の間にUIDSを使用したメッセージのフラグの更新を示しています。UID範囲内の既存のメッセージの総数は、公開されている1000メッセージの制限を超えています。範囲内のすべてのメッセージのフラグを変更したいクライアントは、MessageLimit応答コードに返されたUIDが含まれていない更新されたUID範囲でUIDストアコマンドを繰り返すことができます。（Storeコマンドの場合、メッセージセットパラメーターもコマンドを繰り返す前に更新する必要があります。）クライアントは、MessageLimit応答が返されるまで（またはタグ付けされたノーまたは悪いものが返されるまで）これを続ける必要があります。
C: 07 UID STORE 18000:20000 +FLAGS (\Seen)
S: * 11215 FETCH (FLAGS (\Seen \Deleted) UID 20000)
S: * 11214 FETCH (FLAGS (\Seen \Answered \Deleted) UID 19998)
...
S: * 10216 FETCH (FLAGS (\Seen) UID 19578)
S: 07 OK [MESSAGELIMIT 1000 19578] STORE completed for the last
1000 messages
The following example shows the removal of messages (using UID EXPUNGE) that have the \Deleted flag set with UIDs between 11000:13000. The total message count of messages with the \Deleted flag set exceeds the server's published 1000-message limit. The client that wants to remove all messages marked as \Deleted in the range and observes a MESSAGELIMIT response code can repeat the UID EXPUNGE command with the same parameter. The client needs to keep doing this until the MESSAGELIMIT response is not returned (or until a tagged NO or BAD is returned).
次の例は、11000：13000の間のUIDを使用して\削除されたフラグが設定されたメッセージの削除（UID消去を使用）を示しています。\削除されたフラグセットを使用したメッセージの合計メッセージ数は、サーバーの公開された1000メッセージの制限を超えています。範囲内で削除された\としてマークされたすべてのメッセージを削除したいクライアントは、MessageLimit応答コードを同じパラメーターでUID消去コマンドを繰り返すことができます。クライアントは、MessageLimit応答が返されなくなるまで（またはタグ付けされたノーまたは悪いものが返されるまで）これを続ける必要があります。
C: 08 UID EXPUNGE 11000:13000
S: * 4306 EXPUNGE
S: * 4305 EXPUNGE
...
S: * 3307 EXPUNGE
S: 08 OK [MESSAGELIMIT 1000 11627] UID EXPUNGE completed for
the last 1000 messages
The following example shows removal of messages (using EXPUNGE) that have the \Deleted flag set. Unlike UID EXPUNGE, the server MUST NOT impose any message limit when processing EXPUNGE.
次の例は、\削除されたフラグセットを備えたメッセージの削除（expungeを使用）を示しています。uid expungeとは異なり、サーバーは、処理の抹消時にメッセージの制限を課さないでください。
C: 09 EXPUNGE
S: * 4306 EXPUNGE
S: * 4305 EXPUNGE
...
S: * 3307 EXPUNGE
S: * 112 EXPUNGE
S: 09 OK EXPUNGE completed
Similarly, the server MUST NOT impose any message limit when processing a "CLOSE" or a "STATUS UNSEEN" command.
同様に、サーバーは、「閉じる」または「ステータスが見えない」コマンドを処理するときにメッセージの制限を課さないでください。
The following example shows use of the MESSAGELIMIT response code together with the PARTIAL [RFC9394] extension. The total message count (as specified by the PARTIAL range) exceeds the server's published 1000-message limit, so the server refuses to do any work in this case.
次の例は、部分的な[RFC9394]拡張とともに、MessageLimit応答コードの使用を示しています。合計メッセージカウント（部分範囲で指定）は、サーバーの公開されている1000メッセージの制限を超えているため、サーバーはこの場合の作業を行うことを拒否します。
C: 10 UID FETCH 22000:25000 (UID FLAGS MODSEQ)
(PARTIAL -1:-1500)
S: 10 NO [MESSAGELIMIT 1000] FETCH exceeds the maximum 1000-
message limit
Without the PARTIAL parameter, the above UID FETCH can look like this:
部分パラメーターがなければ、上記のUIDフェッチは次のようになります。
C: 10 UID FETCH 22000:25000 (UID FLAGS MODSEQ)
S: * 12367 FETCH (FLAGS (\Seen \Deleted) UID 23007)
S: * 12366 FETCH (FLAGS (\Seen \Answered \Deleted) UID 23114)
...
S: * 13366 FETCH (FLAGS (\Seen) UID 24598)
S: 10 OK [MESSAGELIMIT 1000 23007] FETCH exceeds the maximum
1000-message limit
Note that when the server needs to return both EXPUNGEISSUED [RFC9051] and MESSAGELIMIT response codes, the former MUST be returned in the tagged OK response, while the latter MUST be returned in an untagged NO response. The following example demonstrates that:
サーバーが抹消[RFC9051]とMessageLimit応答コードの両方を返す必要がある場合、前者はタグ付きOK応答で返されなければならず、後者は未編成なしの応答で返さなければならないことに注意してください。次の例は、次のことを示しています。
C: 11 FETCH 10000:14589 (UID FLAGS)
S: * 14589 FETCH (FLAGS (\Seen) UID 25000)
S: * 14588 FETCH (FLAGS (\Answered) UID 24998)
S: ... further 997 fetch responses
S: * 13590 FETCH (FLAGS () UID 23221)
S: * NO [MESSAGELIMIT 1000 23221] FETCH completed with 1000 partial
results
S: 11 OK [EXPUNGEISSUED] Some messages were also expunged
When the IMAP MULTIAPPEND extension [RFC3502] is also supported by the server, the message limit also applies to the APPEND command. As MULTIAPPEND APPEND needs to atomic (as per [RFC3502]), no messages are appended when the server MESSAGELIMIT is exceeded.
IMAP MultiaPend Extension [RFC3502]もサーバーによってサポートされている場合、メッセージの制限はAppendコマンドにも適用されます。MultiaPend AppendはAtomic（[RFC3502]に従って）に必要であるため、サーバーMessageLimitを超えたときにメッセージは追加されません。
The MESSAGELIMIT extension also defines two extra SEARCH keys, UIDAFTER and UIDBEFORE, which make it easier to convert a single UID to a range of UIDs.
MessageLimit拡張機能は、2つの追加の検索キー、UIDAFTERとUIDBEFOREも定義するため、単一のUIDをさまざまなUIDに変換しやすくなります。
"UIDAFTER <uid>"
「uidafter <uid>」
Messages that have a UID greater than the specified UID. This is semantically the same as "UID <uid>+1:*".
指定されたUIDよりも大きいUIDを持つメッセージ。これは、「uid <uid> +1：*」と意味的に同じです。
"UIDBEFORE <uid>"
「uidbefore <uid>」
Messages that have a UID less than the specified UID. This is semantically the same as "UID 1:<uid>-1" (or if <uid> has the value 1, then the empty set).
指定されたuidよりも小さいuidを持つメッセージ。これは、「uid 1：<uid> -1」と意味的に同じです（または<uid>に値1、次に空のセットがある場合）。
These two SEARCH keys are particularly useful when the SEARCHRES extension [RFC5182] is also supported, but they can be used without it. For example, this allows a SEARCH that sets the "$" marker to be converted to a range of messages in a subsequent SEARCH, and both SEARCH requests can be pipelined.
これらの2つの検索キーは、SearchRes拡張子[RFC5182]もサポートされている場合に特に役立ちますが、それなしで使用できます。たとえば、これにより、「$」マーカーをその後の検索でさまざまなメッセージに変換する検索を可能にし、両方の検索要求をパイプラインできます。
C: 12 UID SEARCH UIDAFTER 25000 UNDELETED
S: * SEARCH 27800 27798 (... 250 UIDs ...) 25001
S: 12 OK SEARCH completed
Servers that advertise MESSAGELIMIT N will be unable to execute a THREAD command [RFC5256] in a mailbox with more than N messages.
Messagelimit nを宣伝するサーバーは、nメッセージ以上のメールボックスでスレッドコマンド[RFC5256]を実行できません。
Servers that advertise MESSAGELIMIT N might be unable to execute a SORT command [RFC5256] in a mailbox with more than N messages, unless they maintain indices for different SORT orders they support. In absence of such indices, server implementors will need to decide whether their server advertises SORT or MESSAGELIMIT capability.
Messagelimit nを宣伝するサーバーは、サポートするさまざまなソートオーダーのインデックスを維持しない限り、nメッセージ以上のメールボックスでソートコマンド[RFC5256]を実行できない場合があります。このようなインデックスがない場合、サーバーの実装者は、サーバーがソートまたはMessagelimit機能を宣伝するかどうかを決定する必要があります。
Servers that support both MESSAGELIMIT and SEARCHRES extensions [RFC5182] MUST truncate SEARCH SAVE result stored in the $ variable when the SEARCH command succeeds, but the MESSAGELIMIT response code is returned. For example, if the following SEARCH would have returned 1200 results in absence of MESSAGELIMIT, and the MESSAGELIMIT is 1000, only 1000 matching results will be saved in the $ variable:
MessageLimitとSearchRes拡張機能の両方をサポートするサーバー[RFC5182]は、検索コマンドが成功したときに$変数に保存されている検索保存結果を切り捨てる必要がありますが、MessageLimit応答コードは返されます。たとえば、MessageLimitがない場合に次の検索が1200の結果を返し、MessageLimitが1000の場合、$変数には1000の一致結果のみが保存されます。
C: D0004 UID SEARCH RETURN (SAVE) SINCE 1-Jan-2004 NOT FROM "Smith"
UID 22000:25000 UNDELETED
S: D0004 OK [MESSAGELIMIT 1000 1179] SEARCH completed with 1000
partial results saved
A server that advertises the MESSAGELIMIT=N capability would have the following effect on clients that don't support this capability:
messageLimit = n機能を宣伝するサーバーは、この機能をサポートしていないクライアントに次の効果をもたらします。
* Operations are not affected on a mailbox that has N messages or fewer.
* 操作は、nメッセージ以下のメールボックスで影響を受けません。
* In a mailbox with more than N messages:
* n以上のメッセージを持つメールボックスで：
- An attempt to COPY or UID COPY more than N messages will always fail.
- nメッセージ以上のコピーまたはuidコピーの試みは、常に失敗します。
- EXPUNGE and CLOSE will always operate on the full mailbox, so they are not affected.
- obunge and closeは常に完全なメールボックスで動作するため、影響を受けません。
- Other commands like FETCH, SEARCH, and MOVE will be effectively restricted to the last N messages of the mailbox. In particular, unextended SEARCHes (intended for counting of messages with or without a particular set of flags) would return incorrect counts.
- フェッチ、検索、および移動などの他のコマンドは、メールボックスの最後のnメッセージに効果的に制限されます。特に、拡張された検索（特定のフラグセットの有無にかかわらずメッセージのカウントを目的とした）は、間違ったカウントを返します。
It is important to understand that the above effects essentially abandon existing clients with respect to operation on large mailboxes. Suppose, for example, that a user is accessing a large and active mailing list via IMAP, and the mailing list gets on the order of 1500 posts per week. When the user returns from a week-long vacation and catches up on the mailing list, the user's client will be fetching information about 1500 messages. If the server has a MESSAGELIMIT of 1000, the client will only be able to download 1000 of the most recent messages; the client will not understand why, will not be prepared to recover from the situation, and will act as if it is interacting with a broken server.
上記の効果は、大きなメールボックスでの操作に関して既存のクライアントを本質的に放棄することを理解することが重要です。たとえば、ユーザーがIMAPを介して大規模でアクティブなメーリングリストにアクセスしており、メーリングリストが週に1500件の投稿を獲得しているとします。ユーザーが1週間にわたる休暇から戻ってメーリングリストに追いつくと、ユーザーのクライアントは1500のメッセージに関する情報を取得します。サーバーのMessageLimitが1000の場合、クライアントは最新のメッセージの1000のみをダウンロードできます。クライアントは、理由を理解せず、状況から回復する準備ができておらず、壊れたサーバーと対話しているかのように動作します。
In order to give clients time to implement this extension, servers should not be strict about applying the MESSAGELIMIT at first. One possible approach is to advertise a MESSAGELIMIT but not enforce it at all for a while. Clients that understand this extension will comply, reducing load on the server, but clients that do not understand the limit will continue to work in all situations.
クライアントにこの拡張機能を実装する時間を与えるために、サーバーは最初にMessagelimitを適用することを厳しくしてはなりません。考えられるアプローチの1つは、Messagelimitを宣伝することですが、しばらくの間それを実施しないことです。この拡張機能を理解しているクライアントは遵守し、サーバーの負荷が削減されますが、制限を理解していないクライアントは、あらゆる状況で引き続き機能します。
Another approach, which perhaps could be phased in later, is to advertise one limit but to treat it as a soft limit and to begin enforcement at a higher, unadvertised hard limit. In the above example, perhaps the server might advertise 1000 but actually enforce a limit of 10,000. Again, clients that understand MESSAGELIMIT will comply with the limit of 1000, but other clients will still interoperate up to the higher threshold.
おそらく後で段階的に段階的に段階的になる可能性がある別のアプローチは、1つの制限を宣伝するが、それをソフト制限として扱い、より高い、宣伝されていないハードリミットで執行を開始することです。上記の例では、おそらくサーバーは1000を宣伝するかもしれませんが、実際には10,000の制限を実施するかもしれません。繰り返しますが、MessageLimitを理解しているクライアントは1000の制限に準拠しますが、他のクライアントは引き続きより高いしきい値まで相互運用します。
Attempts to go beyond the advertised limit can be logged so that client understanding of MESSAGELIMIT can be tracked. If implementation and deployment of this extension becomes common, it may at some point be acceptable to strictly enforce the advertised limit and to accept that the remaining clients will, indeed, no longer work properly with mailboxes above that limit.
宣伝された制限を超えようとする試みを記録することができ、クライアントのMessageLimitの理解を追跡できます。この拡張機能の実装と展開が一般的になった場合、ある時点で宣伝された制限を厳密に施行し、残りのクライアントが実際にその制限を超えるメールボックスで適切に動作しなくなることを受け入れることが許容される場合があります。
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [ABNF].
次の構文仕様では、[ABNF]で指定されているように、拡張されたBackus-Naurフォーム（ABNF）表記を使用します。
Non-terminals referenced but not defined below are as defined by IMAP4 [RFC3501].
参照されているが以下では定義されていない非末端は、IMAP4 [RFC3501]によって定義されているとおりです。
Except as noted otherwise, all alphabetic characters are case-insensitive. The use of uppercase or lowercase characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion.
それ以外の場合は、言及されている場合を除き、すべてのアルファベット文字はケース非感受性です。トークン文字列を定義するために大文字または小文字の文字を使用することは、編集の明確さのみを目的としています。実装は、これらの文字列をケースに依存しない方法で受け入れる必要があります。
capability =/ "MESSAGELIMIT=" message-limit /
"SAVELIMIT=" message-limit
;; <capability> from [RFC3501]
message-limit = nz-number
resp-text-code =/ "MESSAGELIMIT" SP message-limit [SP uniqueid]
;; No more than nz-number messages can be processed
;; by any command at a time. The last (lowest) processed
;; UID is uniqueid.
;; The last parameter is omitted when not known.
This document defines an additional IMAP4 capability. As such, it does not change the underlying security considerations of IMAP4rev1 [RFC3501] or IMAP4rev2 [RFC9051].
このドキュメントは、追加のIMAP4機能を定義します。そのため、IMAP4REV1 [RFC3501]またはIMAP4REV2 [RFC9051]の基礎となるセキュリティ上の考慮事項は変更されません。
This document defines an optimization that can both reduce the amount of work performed by the server, as well at 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, which can in turn help to protect from denial-of-service attacks. 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 introducing new implementation bugs.
このドキュメントでは、クライアントに返されるデータの量で、サーバーが実行する作業量を減らすことができる最適化を定義します。この拡張機能の使用により、サーバーとクライアントは、拡張機能が使用されていない場合よりも少ないメモリを使用する可能性があります。これにより、サービス拒否攻撃から保護するのに役立ちます。ただし、これはクライアントとサーバーの両方で新しいコードになるため、新しい実装バグの導入を避けるために、そのようなコードの厳密なテストが必要です。
IMAP4 capabilities are registered by publishing a Standards Track or IESG-approved Informational or Experimental RFC. The "IMAP Capabilities" registry is currently located at: <https://www.iana.org/assignments/imap-capabilities/>.
IMAP4機能は、標準トラックまたはIESGが承認した情報または実験RFCを公開することにより登録されます。「IMAP機能」レジストリは現在、<https://www.iana.org/assignments/imap-capabilities/>にあります。
IANA has added "MESSAGELIMIT=" and "SAVELIMIT=" capabilities to this registry, with this document as the reference.
IANAは、このレジストリに「MessageLimit =」と「Savelimit =」機能を追加し、このドキュメントを参照として追加しました。
[ABNF] 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>.
[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>.
[RFC3502] Crispin, M., "Internet Message Access Protocol (IMAP) -
MULTIAPPEND Extension", RFC 3502, DOI 10.17487/RFC3502,
March 2003, <https://www.rfc-editor.org/info/rfc3502>.
[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>.
[RFC5256] Crispin, M. and K. Murchison, "Internet Message Access
Protocol - SORT and THREAD Extensions", RFC 5256,
DOI 10.17487/RFC5256, June 2008,
<https://www.rfc-editor.org/info/rfc5256>.
[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>.
[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>.
This document was motivated by the Yahoo! team and their questions about best client practices for dealing with large mailboxes.
この文書はYahoo!によって動機付けられました大きなメールボックスを扱うための最高のクライアントプラクティスに関するチームとその質問。
The authors of this document would like to thank the following people who provided useful comments, contributed text, or participated in discussions of this document: Timo Sirainen, Barry Leiba, Ken Murchison, and Arnt Gulbrandsen.
この文書の著者は、有用なコメントを提供したり、テキストを提供したり、この文書の議論に参加したりしてくれた次の人々に感謝したいと思います：Timo Sirainen、Barry Leiba、Ken Murchison、およびArnt Gulbrandsen。
Alexey Melnikov
Isode Limited
Email: alexey.melnikov@isode.com
URI: https://www.isode.com
Arun Prakash Achuthan
Yahoo!
Email: arunprakash@myyahoo.com
Vikram Nagulakonda
Yahoo!
Email: nvikram_imap@yahoo.com
Luis Alves
Email: luis.alves@lafaspot.com