IMAP Paged SEARCH & FETCH Extension

This document defines an extension to the Internet Message Access Protocol for performing incremental searches and fetches. This extension is compatible with both IMAP4rev1 and IMAP4rev2 . The PARTIAL extension of the Internet Message Access Protocol (RFC 3501/RFC 9051) allows clients to limit the number of search results returned, as well as to perform incremental (paged) searches. This also helps servers to optimize resource usage when performing searches. This document extends PARTIAL SEARCH return option originally specified in RFC 5267. It also clarifies some interactions between RFC 5267 and RFC 4731/RFC 9051. This document also describes the MESSAGELIMIT extension for announcing a limit on the number of messages that can be processed in a single FETCH/SEARCH/STORE/COPY/MOVE command.

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 keywords or keywords from this document.

An IMAP server advertises support for the PARTIAL extension by including "PARTIAL" capability in the CAPABILITY response/response code. Clients that implement support for PARTIAL extension MUST also support the MESSAGELIMIT response code (see ).

The PARTIAL search return option causes the server to provide in an ESEARCH response a subset of the results denoted by the sequence range given as the mandatory argument. The first result (message with the lowest matching UID) is 1; thus, the first 500 results would be obtained by a return option of "PARTIAL 1:500", and the second 500 by "PARTIAL 501:1000". This intentionally mirrors message sequence numbers. It is also possible to direct the server to start SEARCH from the latest matching (with the highest UID) message. This can be done by prepeding "-" to the index. For example -1 is the last message, -2 is next to the last and so on. Using this syntax helps server implementations to optimize their SEARCHes. A single command MUST NOT contain more than one PARTIAL or ALL search return option -- that is, either one PARTIAL, one ALL, or neither PARTIAL nor ALL is allowed. For SEARCH results, the entire result list MUST be ordered in mailbox order, that is, in UID or message sequence number order. Where a PARTIAL search return option references results that do not exist, by using a range which starts or ends higher (or lower) than the current number of results, then the server returns the results that are in the set. This yields a PARTIAL return data item that has, as payload, the original range and a potentially missing set of results that may be shorter than the extent of the range. If the whole range references results that do not exist, a special value "NIL" is returned by the server instead of the sequence set. Clients need not request PARTIAL results in any particular order. Because mailboxes may change, clients might wish to use PARTIAL in combination with UPDATE (see if the server also advertises CONTEXT=SEARCH capability, especially if the intent is to walk a large set of results; however, these return options do not interact -- the UPDATE will provide notifications for all matching results.

This section only applies if the server advertises PARTIAL IMAP capability or CONTEXT=SEARCH , together with ESEARCH and/or IMAP4rev2". The SAVE result option doesn't change whether the server would return items corresponding to PARTIAL SEARCH result options. As specified in , it is an error to specify both PARTIAL and ALL result options in the same SEARCH command. When the SAVE result option is combined with the PARTIAL result option, and none of MIN/MAX/COUNT result options is present, the corresponding PARTIAL is returned, and the "$" marker would contain all messages returned by the PARTIAL result option. When the SAVE + PARTIAL result options are combined with the MIN or the MAX result option, and the COUNT result option is absent, the corresponding PARTIAL result and MIN/MAX is returned (if the search result is not empty), and the "$" marker would contain all messages returned by the PARTIAL result option + the corresponding MIN/MAX message. If the SAVE + PARTIAL result options are combined with both MIN and MAX result options, and the COUNT result options is absent, the PARTIAL, MIN and MAX are returned (if the search result is not empty), and the "$" marker would contain all messages returned by the PARTIAL result option plus MIN and MAX messages. If the SAVE + PARTIAL result options are combined with the COUNT result option, the PARTIAL and COUNT are returned, and the "$" marker would always contain all messages found by the SEARCH or UID SEARCH command. The following table summarizes the additional requirement on ESEARCH server implementations described in this section. Combination of Result option "$" marker value SAVE PARTIAL PARTIAL SAVE PARTIAL MIN PARTIAL & MIN SAVE PARTIAL MAX PARTIAL & MAX SAVE PARTIAL MIN MAX PARTIAL & MIN & MAX SAVE PARTIAL COUNT [m] all found messages where '[m]' means optional "MIN" and/or "MAX"

The PARTIAL extension also extends the UID FETCH command with a PARTIAL FETCH modifier. The PARTIAL FETCH modifier has the same syntax as the PARTIAL SEARCH result option. Presence of the PARTIAL FETCH modifier instructs the server to only return FETCH results for messages in the specified range. It is useful when the sequence-set (first) parameter to the UID FETCH command includes unknown number of messages.

This section is informative. The PARTIAL FETCH modifier can be combined with the CHANGEDSINCE FETCH modifier.

The above example causes the server to first select the last 30 messages and then only return flag changes for subset of these messages which have MODSEQ higher than 98305. Note that the order of PARTIAL and CHANGEDSINCE FETCH modifiers in the UID FETCH command is not important, i.e. the above example can also use "UID FETCH 25900:26600 (UID FLAGS) (CHANGEDSINCE 98305 PARTIAL -1:-30)" command and it would result in the same responses.

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.

Do we need a way to specify SEARCH criterion for "all UIDs after" or "all UIDs before" a specific UID? If a server implementation doesn't allow more than <N> messages to be operated on by a single SEARCH/FETCH/STORE/COPY/MOVE command, 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. The lowest processed UID is <LastUID>. The client needs to repeat the operation for remaining messages, if required. 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.

Open Issue: Note that the above example shows a UID COPY that partially fails. This is assumed to be better for clients that don't understand the MESSAGELIMIT response code. However this might cause naive clients to believe that the COPY fully completed and that all messages were copied. (An alternative would be to return MESSAGELIMIT in the tagged NO response, meaning that no messages could be copied. However this wouldn't work well with clients that don't support MESSAGELIMIT response code.) 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:

Servers that advertise MESSAGELIMIT N will be unable to execute THREAD command on mailboxes with more than N messages. Servers that advertise MESSAGELIMIT N might be unable to execute SORT command on mailboxes with more than N messages, unless they maintain indeces for different SORT orders they support.

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.

MINUS = "-" capability =/ "PARTIAL" ;; from [RFC3501] modifier-partial = "PARTIAL" SP partial-range partial-range-first = nz-number ":" nz-number ;; Request to search from oldest (lowest UIDs) to ;; more recent messages. ;; A range 500:400 is the same as 400:500. ;; This is similar to from [RFC3501], ;; but cannot contain "*". partial-range-last = MINUS nz-number ":" MINUS nz-number ;; Request to search from newest (highest UIDs) to ;; oldest messages. ;; A range -500:-400 is the same as -400:-500. partial-range = partial-range-first / partial-range-last search-return-opt =/ modifier-partial ;; All conform to , from [IMAP-ABNF]/[RFC9051] search-return-data =/ ret-data-partial ret-data-partial = "PARTIAL" SP "(" partial-range SP partial-results ")" ;; is the requested range. partial-results = sequence-set / "NIL" ;; from [RFC3501]. ;; NIL indicates no results correspond to the requested range. tagged-ext-simple =/ partial-range-last fetch-modifier =/ modifier-partial capability =/ "MESSAGELIMIT=" message-limit ;; 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. ]]>

TBD.

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 PARTIAL 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. This document uses lots of text from RFC 5267. Thus work of the RFC 5267 authors Dave Cridland and Curtis King is appreciated.