5Internet Engineering Task Force (IETF) A. Melnikov
6Request for Comments: 9738 Isode
7Category: Experimental A. P. Achuthan
8ISSN: 2070-1721 V. Nagulakonda
14 IMAP MESSAGELIMIT Extension
18 The MESSAGELIMIT extension of the Internet Message Access Protocol
19 (RFCs 3501 and 9051) allows servers to announce a limit on the number
20 of messages that can be processed in a single FETCH, SEARCH, STORE,
21 COPY, or MOVE command (or their UID variants), or in a single APPEND
22 or UID EXPUNGE command. This helps servers to control resource usage
23 when performing various IMAP operations. This helps clients to know
24 the message limit enforced by the corresponding IMAP server and avoid
25 issuing commands that would exceed such limit.
29 This document is not an Internet Standards Track specification; it is
30 published for examination, experimental implementation, and
33 This document defines an Experimental Protocol for the Internet
34 community. This document is a product of the Internet Engineering
35 Task Force (IETF). It represents the consensus of the IETF
36 community. It has received public review and has been approved for
37 publication by the Internet Engineering Steering Group (IESG). Not
38 all documents approved by the IESG are candidates for any level of
39 Internet Standard; see Section 2 of RFC 7841.
41 Information about the current status of this document, any errata,
42 and how to provide feedback on it may be obtained at
43 https://www.rfc-editor.org/info/rfc9738.
47 Copyright (c) 2025 IETF Trust and the persons identified as the
48 document authors. All rights reserved.
50 This document is subject to BCP 78 and the IETF Trust's Legal
51 Provisions Relating to IETF Documents
52 (https://trustee.ietf.org/license-info) in effect on the date of
53 publication of this document. Please review these documents
54 carefully, as they describe your rights and restrictions with respect
55 to this document. Code Components extracted from this document must
56 include Revised BSD License text as described in Section 4.e of the
57 Trust Legal Provisions and are provided without warranty as described
58 in the Revised BSD License.
60 This document may contain material from IETF Documents or IETF
61 Contributions published or made publicly available before November
62 10, 2008. The person(s) controlling the copyright in some of this
63 material may not have granted the IETF Trust the right to allow
64 modifications of such material outside the IETF Standards Process.
65 Without obtaining an adequate license from the person(s) controlling
66 the copyright in such materials, this document may not be modified
67 outside the IETF Standards Process, and derivative works of it may
68 not be created outside the IETF Standards Process, except to format
69 it for publication as an RFC or to translate it into languages other
74 1. Introduction and Overview
75 2. Document Conventions
76 3. The MESSAGELIMIT Extension
77 3.1. Returning Limits on the Number of Messages Processed in a
79 3.2. UIDAFTER and UIDBEFORE SEARCH Criteria
80 3.3. Interaction with SORT and THREAD Extensions
81 3.4. Interaction with SEARCHRES Extension and IMAP4rev2
82 4. Interoperability Considerations
83 4.1. Effects of MESSAGELIMIT and SAVELIMIT Extensions on
85 4.2. Maintaining Compatibility
87 6. Security Considerations
88 7. IANA Considerations
89 7.1. Additions to the IMAP Capabilities Registry
91 8.1. Normative References
92 8.2. Informative References
961. Introduction and Overview
98 This document defines an extension to the Internet Message Access
99 Protocol [RFC9051] for announcing a server limit on the number of
100 messages that can be processed in a single FETCH, SEARCH, STORE,
101 COPY, or MOVE command (or their UID variants), or a single APPEND or
102 UID EXPUNGE command. This extension is compatible with both
103 IMAP4rev1 [RFC3501] and IMAP4rev2 [RFC9051].
1052. Document Conventions
107 In protocol examples, this document uses a prefix of "C: " to denote
108 lines sent by the client to the server, and "S: " for lines sent by
109 the server to the client. Lines prefixed with "// " are comments
110 explaining the previous protocol line. These prefixes and comments
111 are not part of the protocol. Lines without any of these prefixes
112 are continuations of the previous line, and no line break is present
113 in the protocol unless specifically mentioned.
115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
117 "OPTIONAL" in this document are to be interpreted as described in
118 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
119 capitals, as shown here.
121 Other capitalized words are IMAP key words [RFC3501][RFC9051] or key
122 words from this document.
1243. The MESSAGELIMIT Extension
126 An IMAP server advertises support for the MESSAGELIMIT extension by
127 including "MESSAGELIMIT=<limit>" capability in the CAPABILITY
128 response or response code, where "<limit>" is a positive integer that
129 conveys the maximum number of messages that can be processed in a
130 single SEARCH, FETCH, STORE, COPY, MOVE command (or their UID
131 variants), or in a single APPEND or UID EXPUNGE command.
133 An IMAP server that only enforces the message limit on COPY and
134 APPEND commands (and their UID variants) would include the
135 "SAVELIMIT=<limit>" capability (instead of the
136 "MESSAGELIMIT=<limit>") in the CAPABILITY response or response code.
138 The limit advertised in the MESSAGELIMIT or SAVELIMIT capability
139 SHOULD NOT be lower than 1000 messages.
1413.1. Returning Limits on the Number of Messages Processed in a Single
144 If a server implementation doesn't allow more than <N> messages to be
145 operated on by a single COPY or UID COPY command, it MUST fail the
146 command by returning a tagged NO response with the MESSAGELIMIT
147 response code defined below. No messages are copied in this case.
148 If a server implementation doesn't allow more than <N> messages to be
149 operated on by a single SEARCH, FETCH, STORE, or MOVE command (or
150 their UID variants), or an APPEND or UID EXPUNGE command, it MUST
151 return the MESSAGELIMIT response code defined below:
154 The server doesn't allow more than <N> messages to be operated on
155 by a single SEARCH, FETCH, STORE, COPY, or MOVE command (or their
156 UID variants). The lowest processed UID is <LastUID>. The client
157 needs to repeat the operation for remaining messages, if required.
159 The server doesn't allow more than <N> \Deleted messages to be
160 operated on by a single UID EXPUNGE command. The lowest processed
161 UID is <LastUID>. The client needs to repeat the operation for
162 remaining messages, if required.
164 Note that when the MESSAGELIMIT response code is returned, the
165 server is REQUIRED to process messages from highest to lowest UID.
167 Note that the MESSAGELIMIT response code is similar to the LIMIT
168 response code [RFC9051], but it provides more details on the exact
169 type of the limit and how to resume the command once the limit is
172 In the following example, the <N> value is 1000, and the lowest
173 processed UID <LastUID> is 23221.
175 C: 03 FETCH 10000:14589 (UID FLAGS)
176 S: * 14589 FETCH (FLAGS (\Seen) UID 25000)
177 S: * 14588 FETCH (FLAGS (\Answered) UID 24998)
178 S: ... further 997 fetch responses
179 S: * 13590 FETCH (FLAGS () UID 23221)
180 S: 03 OK [MESSAGELIMIT 1000 23221] FETCH completed with 1000
183 In the following example the client searches for UNDELETED UIDs
184 between 22000:25000. The total number of searched messages (note,
185 NOT the number of matched messages) exceeds the server's published
188 C: 04 UID SEARCH UID 22000:25000 UNDELETED
189 S: * SEARCH 25000 24998 (... UIDs ...) 23221
190 S: 04 OK [MESSAGELIMIT 1000 23221] SEARCH completed with 1000
193 The following example demonstrates the copy of messages with UIDs
194 between 18000:21000. The total message count exceeds the server's
195 published 1000-message limit. As COPY or UID COPY needs to be
196 atomic (as per [RFC3501]/[RFC9051]), no messages are copied.
198 C: 05 UID COPY 18000:21000 "Trash"
199 S: 05 NO [MESSAGELIMIT 1000 20001] Too many messages to copy,
202 The following example shows the move of messages with UIDs between
203 18000:21000. The total message count exceeds the server's
204 published 1000-message limit. (Unlike COPY or UID COPY, MOVE or
205 UID MOVE don't need to be atomic.) The client that wants to move
206 all messages in the range and observes a MESSAGELIMIT response
207 code can repeat the UID MOVE command with the same parameter.
208 (For the MOVE command, the message set parameter needs to be
209 updated before repeating the command.) The client needs to keep
210 doing this until the MESSAGELIMIT response is not returned (or
211 until a tagged NO or BAD is returned).
213 C: 06 UID MOVE 18000:21000 "Archive/2021/2021-12"
214 S: * OK [COPYUID 1397597919 20001:21000 22363:23362] Some
215 messages were not moved
220 S: 06 OK [MESSAGELIMIT 1000 20001] MOVE completed for the last
223 The following example shows the update of flags for messages with
224 UIDs between 18000:20000. The total number of existing messages
225 in the UID range exceeds the server's published 1000-message
226 limit. The client that wants to change flags for all messages in
227 the range and observes a MESSAGELIMIT response code can repeat the
228 UID STORE command with the updated UID range that doesn't include
229 the UID returned in the MESSAGELIMIT response code. (For the
230 STORE command, the message set parameter also needs to be updated
231 before repeating the command.) The client needs to keep doing
232 this until the MESSAGELIMIT response is not returned (or until a
233 tagged NO or BAD is returned).
235 C: 07 UID STORE 18000:20000 +FLAGS (\Seen)
236 S: * 11215 FETCH (FLAGS (\Seen \Deleted) UID 20000)
237 S: * 11214 FETCH (FLAGS (\Seen \Answered \Deleted) UID 19998)
239 S: * 10216 FETCH (FLAGS (\Seen) UID 19578)
240 S: 07 OK [MESSAGELIMIT 1000 19578] STORE completed for the last
243 The following example shows the removal of messages (using UID
244 EXPUNGE) that have the \Deleted flag set with UIDs between
245 11000:13000. The total message count of messages with the
246 \Deleted flag set exceeds the server's published 1000-message
247 limit. The client that wants to remove all messages marked as
248 \Deleted in the range and observes a MESSAGELIMIT response code
249 can repeat the UID EXPUNGE command with the same parameter. The
250 client needs to keep doing this until the MESSAGELIMIT response is
251 not returned (or until a tagged NO or BAD is returned).
253 C: 08 UID EXPUNGE 11000:13000
258 S: 08 OK [MESSAGELIMIT 1000 11627] UID EXPUNGE completed for
259 the last 1000 messages
261 The following example shows removal of messages (using EXPUNGE)
262 that have the \Deleted flag set. Unlike UID EXPUNGE, the server
263 MUST NOT impose any message limit when processing EXPUNGE.
271 S: 09 OK EXPUNGE completed
273 Similarly, the server MUST NOT impose any message limit when
274 processing a "CLOSE" or a "STATUS UNSEEN" command.
276 The following example shows use of the MESSAGELIMIT response code
277 together with the PARTIAL [RFC9394] extension. The total message
278 count (as specified by the PARTIAL range) exceeds the server's
279 published 1000-message limit, so the server refuses to do any work
282 C: 10 UID FETCH 22000:25000 (UID FLAGS MODSEQ)
284 S: 10 NO [MESSAGELIMIT 1000] FETCH exceeds the maximum 1000-
287 Without the PARTIAL parameter, the above UID FETCH can look like
290 C: 10 UID FETCH 22000:25000 (UID FLAGS MODSEQ)
291 S: * 12367 FETCH (FLAGS (\Seen \Deleted) UID 23007)
292 S: * 12366 FETCH (FLAGS (\Seen \Answered \Deleted) UID 23114)
294 S: * 13366 FETCH (FLAGS (\Seen) UID 24598)
295 S: 10 OK [MESSAGELIMIT 1000 23007] FETCH exceeds the maximum
298 Note that when the server needs to return both EXPUNGEISSUED
299 [RFC9051] and MESSAGELIMIT response codes, the former MUST be
300 returned in the tagged OK response, while the latter MUST be returned
301 in an untagged NO response. The following example demonstrates that:
303 C: 11 FETCH 10000:14589 (UID FLAGS)
304 S: * 14589 FETCH (FLAGS (\Seen) UID 25000)
305 S: * 14588 FETCH (FLAGS (\Answered) UID 24998)
306 S: ... further 997 fetch responses
307 S: * 13590 FETCH (FLAGS () UID 23221)
308 S: * NO [MESSAGELIMIT 1000 23221] FETCH completed with 1000 partial
310 S: 11 OK [EXPUNGEISSUED] Some messages were also expunged
312 When the IMAP MULTIAPPEND extension [RFC3502] is also supported by
313 the server, the message limit also applies to the APPEND command. As
314 MULTIAPPEND APPEND needs to atomic (as per [RFC3502]), no messages
315 are appended when the server MESSAGELIMIT is exceeded.
3173.2. UIDAFTER and UIDBEFORE SEARCH Criteria
319 The MESSAGELIMIT extension also defines two extra SEARCH keys,
320 UIDAFTER and UIDBEFORE, which make it easier to convert a single UID
323 "UIDAFTER <uid>" Messages that have a UID greater than the specified
324 UID. This is semantically the same as "UID <uid>+1:*".
326 "UIDBEFORE <uid>" Messages that have a UID less than the specified
327 UID. This is semantically the same as "UID 1:<uid>-1" (or if
328 <uid> has the value 1, then the empty set).
330 These two SEARCH keys are particularly useful when the SEARCHRES
331 extension [RFC5182] is also supported, but they can be used without
332 it. For example, this allows a SEARCH that sets the "$" marker to be
333 converted to a range of messages in a subsequent SEARCH, and both
334 SEARCH requests can be pipelined.
336 C: 12 UID SEARCH UIDAFTER 25000 UNDELETED
337 S: * SEARCH 27800 27798 (... 250 UIDs ...) 25001
338 S: 12 OK SEARCH completed
3403.3. Interaction with SORT and THREAD Extensions
342 Servers that advertise MESSAGELIMIT N will be unable to execute a
343 THREAD command [RFC5256] in a mailbox with more than N messages.
345 Servers that advertise MESSAGELIMIT N might be unable to execute a
346 SORT command [RFC5256] in a mailbox with more than N messages, unless
347 they maintain indices for different SORT orders they support. In
348 absence of such indices, server implementors will need to decide
349 whether their server advertises SORT or MESSAGELIMIT capability.
3513.4. Interaction with SEARCHRES Extension and IMAP4rev2
353 Servers that support both MESSAGELIMIT and SEARCHRES extensions
354 [RFC5182] MUST truncate SEARCH SAVE result stored in the $ variable
355 when the SEARCH command succeeds, but the MESSAGELIMIT response code
356 is returned. For example, if the following SEARCH would have
357 returned 1200 results in absence of MESSAGELIMIT, and the
358 MESSAGELIMIT is 1000, only 1000 matching results will be saved in the
361 C: D0004 UID SEARCH RETURN (SAVE) SINCE 1-Jan-2004 NOT FROM "Smith"
362 UID 22000:25000 UNDELETED
363 S: D0004 OK [MESSAGELIMIT 1000 1179] SEARCH completed with 1000
364 partial results saved
3664. Interoperability Considerations
3684.1. Effects of MESSAGELIMIT and SAVELIMIT Extensions on Noncompliant
371 A server that advertises the MESSAGELIMIT=N capability would have the
372 following effect on clients that don't support this capability:
374 * Operations are not affected on a mailbox that has N messages or
377 * In a mailbox with more than N messages:
379 - An attempt to COPY or UID COPY more than N messages will always
382 - EXPUNGE and CLOSE will always operate on the full mailbox, so
383 they are not affected.
385 - Other commands like FETCH, SEARCH, and MOVE will be effectively
386 restricted to the last N messages of the mailbox. In
387 particular, unextended SEARCHes (intended for counting of
388 messages with or without a particular set of flags) would
389 return incorrect counts.
3914.2. Maintaining Compatibility
393 It is important to understand that the above effects essentially
394 abandon existing clients with respect to operation on large
395 mailboxes. Suppose, for example, that a user is accessing a large
396 and active mailing list via IMAP, and the mailing list gets on the
397 order of 1500 posts per week. When the user returns from a week-long
398 vacation and catches up on the mailing list, the user's client will
399 be fetching information about 1500 messages. If the server has a
400 MESSAGELIMIT of 1000, the client will only be able to download 1000
401 of the most recent messages; the client will not understand why, will
402 not be prepared to recover from the situation, and will act as if it
403 is interacting with a broken server.
405 In order to give clients time to implement this extension, servers
406 should not be strict about applying the MESSAGELIMIT at first. One
407 possible approach is to advertise a MESSAGELIMIT but not enforce it
408 at all for a while. Clients that understand this extension will
409 comply, reducing load on the server, but clients that do not
410 understand the limit will continue to work in all situations.
412 Another approach, which perhaps could be phased in later, is to
413 advertise one limit but to treat it as a soft limit and to begin
414 enforcement at a higher, unadvertised hard limit. In the above
415 example, perhaps the server might advertise 1000 but actually enforce
416 a limit of 10,000. Again, clients that understand MESSAGELIMIT will
417 comply with the limit of 1000, but other clients will still
418 interoperate up to the higher threshold.
420 Attempts to go beyond the advertised limit can be logged so that
421 client understanding of MESSAGELIMIT can be tracked. If
422 implementation and deployment of this extension becomes common, it
423 may at some point be acceptable to strictly enforce the advertised
424 limit and to accept that the remaining clients will, indeed, no
425 longer work properly with mailboxes above that limit.
429 The following syntax specification uses the Augmented Backus-Naur
430 Form (ABNF) notation as specified in [ABNF].
432 Non-terminals referenced but not defined below are as defined by
435 Except as noted otherwise, all alphabetic characters are case-
436 insensitive. The use of uppercase or lowercase characters to define
437 token strings is for editorial clarity only. Implementations MUST
438 accept these strings in a case-insensitive fashion.
440 capability =/ "MESSAGELIMIT=" message-limit /
441 "SAVELIMIT=" message-limit
442 ;; <capability> from [RFC3501]
444 message-limit = nz-number
446 resp-text-code =/ "MESSAGELIMIT" SP message-limit [SP uniqueid]
447 ;; No more than nz-number messages can be processed
448 ;; by any command at a time. The last (lowest) processed
450 ;; The last parameter is omitted when not known.
4526. Security Considerations
454 This document defines an additional IMAP4 capability. As such, it
455 does not change the underlying security considerations of IMAP4rev1
456 [RFC3501] or IMAP4rev2 [RFC9051].
458 This document defines an optimization that can both reduce the amount
459 of work performed by the server, as well at the amount of data
460 returned to the client. Use of this extension is likely to cause the
461 server and the client to use less memory than when the extension is
462 not used, which can in turn help to protect from denial-of-service
463 attacks. However, as this is going to be new code in both the client
464 and the server, rigorous testing of such code is required in order to
465 avoid introducing new implementation bugs.
4677. IANA Considerations
4697.1. Additions to the IMAP Capabilities Registry
471 IMAP4 capabilities are registered by publishing a Standards Track or
472 IESG-approved Informational or Experimental RFC. The "IMAP
473 Capabilities" registry is currently located at:
474 <https://www.iana.org/assignments/imap-capabilities/>.
476 IANA has added "MESSAGELIMIT=" and "SAVELIMIT=" capabilities to this
477 registry, with this document as the reference.
4818.1. Normative References
483 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
484 Specifications: ABNF", STD 68, RFC 5234,
485 DOI 10.17487/RFC5234, January 2008,
486 <https://www.rfc-editor.org/info/rfc5234>.
488 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
489 Requirement Levels", BCP 14, RFC 2119,
490 DOI 10.17487/RFC2119, March 1997,
491 <https://www.rfc-editor.org/info/rfc2119>.
493 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
494 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
495 <https://www.rfc-editor.org/info/rfc3501>.
497 [RFC3502] Crispin, M., "Internet Message Access Protocol (IMAP) -
498 MULTIAPPEND Extension", RFC 3502, DOI 10.17487/RFC3502,
499 March 2003, <https://www.rfc-editor.org/info/rfc3502>.
501 [RFC5182] Melnikov, A., "IMAP Extension for Referencing the Last
502 SEARCH Result", RFC 5182, DOI 10.17487/RFC5182, March
503 2008, <https://www.rfc-editor.org/info/rfc5182>.
505 [RFC5256] Crispin, M. and K. Murchison, "Internet Message Access
506 Protocol - SORT and THREAD Extensions", RFC 5256,
507 DOI 10.17487/RFC5256, June 2008,
508 <https://www.rfc-editor.org/info/rfc5256>.
510 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
511 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
512 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
514 [RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message
515 Access Protocol (IMAP) - Version 4rev2", RFC 9051,
516 DOI 10.17487/RFC9051, August 2021,
517 <https://www.rfc-editor.org/info/rfc9051>.
5198.2. Informative References
521 [RFC9394] Melnikov, A., Achuthan, A. P., Nagulakonda, V., and L.
522 Alves, "IMAP PARTIAL Extension for Paged SEARCH and
523 FETCH", RFC 9394, DOI 10.17487/RFC9394, June 2023,
524 <https://www.rfc-editor.org/info/rfc9394>.
528 This document was motivated by the Yahoo! team and their questions
529 about best client practices for dealing with large mailboxes.
531 The authors of this document would like to thank the following people
532 who provided useful comments, contributed text, or participated in
533 discussions of this document: Timo Sirainen, Barry Leiba, Ken
534 Murchison, and Arnt Gulbrandsen.
540 Email: alexey.melnikov@isode.com
541 URI: https://www.isode.com
544 Arun Prakash Achuthan
546 Email: arunprakash@myyahoo.com
551 Email: nvikram_imap@yahoo.com
555 Email: luis.alves@lafaspot.com