IMAP MESSAGELIMIT Extension

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 [UID] SEARCH/FETCH/STORE/COPY/MOVE/APPEND or UID EXPUNGE command. An IMAP server that only enforces message limit on [UID] COPY/APPEND commands would include the "SAVELIMIT=<limit>" capability (instead of the "MESSAGELIMIT=<limit>") in the CAPABILITY response/response code. The limit advertised in the MESSAGELIMIT or SAVELIMIT capability SHOULD NOT be lower than 1000 messages.

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/EXPUNGE 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. 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. Note that when the MESSAGELIMIT response code is returned, the server is REQUIRED to process messages from highest to lowest UIDs. Note that when the MESSAGELIMIT response code is similar to the LIMIT () response code, but it provides more details on the exact type of the limit and how to resume the command once the limit is exceeded. 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 searched messages (note, NOT the number of matched 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. As COPY/UID COPY needs to atomic (as per /), no messages are copied.

The following example shows MOVE of messages with UIDs between 18000:21000. The total message count exceeds the server's published 1000 messages limit. (Unlike COPY/UID COPY, MOVE/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 need 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/BAD is returned).

The following example shows 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 messages 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 need 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/BAD is returned).

The following example shows removal of messages (using UID EXPUNGE) that have \Deleted flag set with UIDs between 11000:13000. The total message count of messages with \Deleted flag set exceeds the server's published 1000 messages 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/BAD is returned).

The following example shows removal of messages (using EXPUNGE) that have \Deleted flag set. Unlike UID EXPUNGE, the server MUST NOT impose any message limit when processing EXPUNGE.

Similarly, the server MUST NOT impose any message limit when processing a CLOSE or a STATUS UNSEEN command. The following example shows use of MESSAGELIMIT response code together with the PARTIAL extension. The total message count (as specified by the PARTIAL range) exceeds the server's published 1000 messages limit, so the server refuses to do any work in this case.

Without the PARTIAL parameter the above UID FETCH can look like this:

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:

When IMAP MULTIAPPEND extension is also supported by the server, the message limit also applies to the APPEND command.

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>+1:*". "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). These 2 SEARCH keys are particularly useful when the SEARCHRES extension 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.

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:

A server that advertises the MESSAGELIMIT=N capability would have the following effect on clients that don't support this capability: Operations on a mailbox that has <= N messages are not affected. In a mailbox with more than N messages: An attempt to COPY/UID COPY more than N messages will always fail. EXPUNGE and CLOSE will always operate on the full mailbox, so they are not affected. 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.