IMAP MESSAGELIMIT Extension

This document defines an extension to the Internet Message Access Protocol for announcing a server limit on the number of messages that can be processed in a single FETCH/SEARCH/STORE/COPY/MOVE command. This extension is compatible with both IMAP4rev1 and IMAP4rev2 .

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. 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 when, and only when, they appear in all capitals, as shown here. Other capitalised words are IMAP key words or key words from this document.

An IMAP server advertises support for the MESSAGELIMIT extension by including "MESSAGELIMIT=<limit>" capability in the CAPABILITY response/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.

If a server implementation doesn't allow more than <N> messages to be operated on by a single COPY/UID COPY command, it MUST fail the command by returning a tagged NO response with the MESSAGELIMIT response code defined below. If a server implementation doesn't allow more than <N> messages to be operated on by a single SEARCH/FETCH/STORE/MOVE command (or their UID variants), it MUST return the MESSAGELIMIT response code defined below: The server doesn't allow more than <N> messages to be operated on by a single SEARCH/FETCH/STORE/COPY/MOVE command (or their UID variants). The lowest processed UID is <LastUID>. The client needs to repeat the operation for remaining messages, if required. Note that when the MESSAGELIMIT response code is returned, the server is required to process messages from highest to lowest UIDs. In the following example the <N> value is 1000 and the lowest processed UID <LastUID> is 23221.

In the following example the client searches for UNDELETED UIDs between 22000:25000. The total number of matching messages exceeds the server's published 1000 messages limit.

The following example demonstrates copy of messages with UIDs between 18000:21000. The total message count exceeds the server's published 1000 messages limit.

The following example shows MOVE of messages with UIDs between 18000:21000. The total message count exceeds the server's published 1000 messages limit. The client that wants to move all messages in the range and observes a MESSAGELIMIT response code, can repeat the command by updating the UID set parameter specified in the command. The client needs to keep doing this until MESSAGELIMIT response is not returned (or until a tagged NO/BAD is returned).

The following example shows update of flags for messages with UIDs between 18000:20000. The total message count exceeds the server's published 1000 messages limit. The client that wants to change flags for all messages in the range and observes a MESSAGELIMIT response code, can repeat the command by updating the UID set parameter specified in the command. The client needs to keep doing this until MESSAGELIMIT response is not returned (or until a tagged NO/BAD is returned).

The following example shows use of MESSAGELIMIT response code together with the PARTIAL extension. The total message count exceeds the server's published 1000 messages limit.

Note that when the server needs to return both EXPUNGEISSUED () 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:

The MESSAGELIMIT extension also defines 2 extra SEARCH keys: UIDAFTER and UIDBEFORE, which make it easier to convert a single UID to a range of UIDs. "UIDAFTER <uid>" - Messages that have a UID greater than the specified UID. This is semantically the same as "UID <uid>:*". "UIDBEFORE <uid>" - Messages that have a UID less than the specified UID. This is semantically the same as "UID 1:<uid>". These 2 SEARCH keys are particularly useful when the SEARCHRES extension is also supported, but they can be used without it.

Servers that advertise MESSAGELIMIT N will be unable to execute a THREAD command in a mailbox with more than N messages. Servers that advertise MESSAGELIMIT N might be unable to execute a SORT command in a mailbox with more than N messages, unless they maintain indices for different SORT orders they support. In absence of such indeces server implementors will need to decide whether their server advertises SORT or MESSAGELIMIT capability.

Servers that support both MESSAGELIMIT and SEARCHRES extensions 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:

The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in . Non-terminals referenced but not defined below are as defined by IMAP4. 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.

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 and IMAP4rev2 . 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. 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 of new implementation bugs.

IMAP4 capabilities are registered by publishing a standards track or IESG approved Informational or Experimental RFC. The registry is currently located at:

IANA is requested to add definition of the MESSAGELIMIT extension to point to this document.

This document was motivated by Yahoo! team and their questions about best client practices for dealing with large mailboxes. Editor of this document would like to thank the following people who provided useful comments or participated in discussions of this document: Timo Sirainen, Barry Leiba and Ken Murchison.