RFC 9738

IMAP MESSAGELIMIT Extension

📅 published March 2025, from ietf

RFC 9738: IMAP MESSAGELIMIT Extension 💖

  • Authors: A. Melnikov (Isode), A. P. Achuthan, V. Nagulakonda (Yahoo!), L. Alves
  • Category: Experimental
  • ISSN: 2070-1721
  • Date: March 2025
  • Obsoletes / Updates: the title block has no Obsoletes or Updates entry

Okay bestie, this one is the MESSAGELIMIT extension for IMAP 🦋 It lets a server say "hey, I won't handle more than this many messages in one go," so clients stop sending commands that would go over the cap. It's giving resource management, and it's Experimental, so it's still in its testing era 🧪

Abstract

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.

Status of This Memo

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.

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.

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.

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.

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.

Table of Contents 🌸

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

1. Introduction and Overview ✨

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]. It's giving compatibility with both the old and new IMAP versions, which is so iconic 💅

2. Document Conventions 🎀

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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. So the caps lock words are the ones that actually count, bestie, the lowercase ones are just vibes 🙈

Other capitalized words are IMAP key words [RFC3501][RFC9051] or key words from this document.

3. The MESSAGELIMIT Extension 🧚

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.

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. So SAVELIMIT is the narrower cousin, only covering the saving stuff 💜

The limit advertised in the MESSAGELIMIT or SAVELIMIT capability SHOULD NOT be lower than 1000 messages. Ngl, that's a big number, so servers should not be tiny about it 🍓

Part 1 of 3 is done, bestie. Part 2 is next, and it's where the subsections really start getting spicy 🦋

3.1. Returning Limits on the Number of Messages Processed in a Single Command 💅

Okay bestie, so here's the big rule 🫶 If a server 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 (more on that below). No messages get copied in this case, because COPY has to be all-or-nothing 🙈 If a server 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, which works like this:

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.

The server also 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.

Heads up: when the MESSAGELIMIT response code is returned, the server is REQUIRED to process messages from highest to lowest UID. 🔥

Also, MESSAGELIMIT is kinda like the LIMIT response code [RFC9051], but it's way more detailed 🧚 It tells you the exact type of limit and how to pick things back up once you've hit it.

In the following example, the N value is 1000, and the lowest processed UID LastUID is 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 this one the client searches for UNDELETED UIDs between 22000:25000. The total number of searched messages (note, NOT the number of matched messages) goes over the server's published 1000-message limit 👀

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

Next up, copying messages with UIDs between 18000:21000. The total message count is over the server's published 1000-message limit. Since COPY or UID COPY needs to be atomic (as per [RFC3501]/[RFC9051]), nothing gets copied at all 💀

C: 05 UID COPY 18000:21000 "Trash"
S: 05 NO [MESSAGELIMIT 1000 20001] Too many messages to copy,
    try a smaller subset

Now moving messages with UIDs between 18000:21000. Again, the total is over the server's published 1000-message limit. Unlike COPY or UID COPY, MOVE or UID MOVE doesn't need to be atomic 🦋 So a client that wants to move everything in the range and sees a MESSAGELIMIT response code can just repeat the UID MOVE command with the same parameter. (For the MOVE command, the message set parameter needs to be updated before repeating it.) Keep doing this until MESSAGELIMIT stops coming back, or until you get a tagged NO or BAD.

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

Here's flag updates for messages with UIDs between 18000:20000. The total number of existing messages in that UID range is over the server's published 1000-message limit. A client that wants to change flags on everything in the range and sees a MESSAGELIMIT response code can repeat the UID STORE command with an updated UID range that leaves out the UID returned in the MESSAGELIMIT response code. (For the STORE command, the message set parameter also needs updating before repeating it.) Same deal: keep going until MESSAGELIMIT isn't returned anymore, or until a tagged NO or BAD shows up ✨

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

This one removes messages with the \Deleted flag set (using UID EXPUNGE) with UIDs between 11000:13000. The total count of \Deleted messages is over the server's published 1000-message limit. A client that wants to clear out everything marked \Deleted in the range and sees a MESSAGELIMIT response code can repeat the UID EXPUNGE command with the same parameter, and keep doing that until MESSAGELIMIT isn't returned (or a tagged NO or BAD appears) 🧹

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

Now the EXPUNGE example, which removes messages that have the \Deleted flag set. Unlike UID EXPUNGE, the server MUST NOT impose any message limit when processing EXPUNGE. It's giving no limits, periodt 💖

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 🌸

This example shows MESSAGELIMIT working together with the PARTIAL [RFC9394] extension. The total message count (as set by the PARTIAL range) is over the server's published 1000-message limit, so the server refuses to do any work at all here 🙅‍♀️

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, that same UID FETCH can look like this:

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

Okay, this part is kinda spicy 🌶️ 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. Here's proof:

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

If the server also supports the IMAP MULTIAPPEND extension [RFC3502], the message limit applies to the APPEND command too. Since MULTIAPPEND APPEND needs to be atomic (as per [RFC3502]), no messages get appended when the server's MESSAGELIMIT is exceeded 🎀

3.2. UIDAFTER and UIDBEFORE SEARCH Criteria 🌈

The MESSAGELIMIT extension also adds two extra SEARCH keys, UIDAFTER and UIDBEFORE, which make it way easier to turn a single UID into 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 two SEARCH keys are especially handy when the SEARCHRES extension [RFC5182] is also supported, but you can use them without it too. For example, this lets a SEARCH that sets the "$" marker get turned into a range of messages in a later SEARCH, and both SEARCH requests can be pipelined 🍓

C: 12 UID SEARCH UIDAFTER 25000 UNDELETED
S: * SEARCH 27800 27798 (... 250 UIDs ...) 25001
S: 12 OK SEARCH completed

3.3. Interaction with SORT and THREAD Extensions 🧁

Servers that advertise MESSAGELIMIT N will be unable to execute a THREAD command [RFC5256] in a mailbox with more than N messages. Big mailbox, no THREAD for you 😭

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 the different SORT orders they support. Without those indices, server implementors will need to decide whether their server advertises SORT or MESSAGELIMIT capability. It's a choice, bestie 🫣

3.4. Interaction with SEARCHRES Extension and IMAP4rev2 💜

Servers that support both MESSAGELIMIT and SEARCHRES extensions [RFC5182] MUST truncate the SEARCH SAVE result stored in the $ variable when the SEARCH command succeeds, but the MESSAGELIMIT response code is returned. For example, say the following SEARCH would have returned 1200 results without MESSAGELIMIT, and the MESSAGELIMIT is 1000. Then only 1000 matching results get saved in the $ variable:

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

4. Interoperability Considerations 🦋

4.1. Effects of MESSAGELIMIT and SAVELIMIT Extensions on Noncompliant Clients 🙈

A server that advertises the MESSAGELIMIT=N capability would have the following effect on clients that don't support this capability:

  • Operations are not affected on a mailbox that has N messages or fewer.
  • In a mailbox with more than N messages:
    • An attempt to COPY or 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 messages with or without a particular set of flags) would return incorrect counts. Yikes, that's a whole vibe shift 💀

4.2. Maintaining Compatibility ✨

okay bestie, this part is lowkey the most important bit 🥺 Switching to MESSAGELIMIT can absolutely break existing clients on big mailboxes, and that's a real problem. 💀

Picture this: a user is following a super active mailing list over IMAP, and it gets around 1500 posts a week. They come back from a week-long vacation, open their client, and it has to fetch info about about 1500 messages. If the server has a MESSAGELIMIT of 1000, the client only gets the 1000 most recent messages. It has no idea why, isn't ready to handle that, and acts like the server is totally broken. Not a vibe 😭

So the fix is to give clients time to catch up 🫶 Servers should not be strict about applying the MESSAGELIMIT at first. One option is to advertise a MESSAGELIMIT but not enforce it at all for a while. Clients that get this extension will play by the rules and take some load off the server, and clients that don't understand the limit keep working in every situation. ✨

Another option, which could maybe be phased in later, is to advertise one limit but treat it as a soft limit, and only start enforcing at a higher hard limit that isn't advertised. Going back to the example, the server could advertise 1000 but actually enforce a limit of 10,000. Clients that understand MESSAGELIMIT still stick to 1000, and everyone else keeps working up to the higher threshold. Iconic compromise 🎀

Attempts to go past the advertised limit can get logged, so you can track how many clients actually understand MESSAGELIMIT 📊 If this extension becomes common, it might eventually be okay to strictly enforce the advertised limit and accept that the leftover clients won't work properly with mailboxes above it. Rip to them, but that's the endgame 🌈

5. Formal Syntax 💅

The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [ABNF].

Non-terminals referenced but not defined below are as defined by IMAP4 [RFC3501].

Except as noted otherwise, all alphabetic characters are case-insensitive. Using uppercase or lowercase letters to define token strings is only for editorial clarity 🦋 Implementations MUST accept these strings in a case-insensitive fashion. No drama, just vibes ✨

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.

6. Security Considerations 🔐

This document defines an additional IMAP4 capability. As such, it does not change the underlying security considerations of IMAP4rev1 [RFC3501] or IMAP4rev2 [RFC9051]. Nothing about the base protocol's security story gets rewritten here 🙏

This document defines an optimization that can both reduce the amount of work performed by the server, as well as 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. 💀 Please, please test your code. New code means new bugs, and new bugs mean chaos. Do not skip the testing, bestie 🙅‍♀️

7. IANA Considerations 📋

7.1. Additions to the IMAP Capabilities Registry

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/>. 🗂️

IANA has added "MESSAGELIMIT=" and "SAVELIMIT=" capabilities to this registry, with this document as the reference. Officially on the list now, iconic 👑

8. References 📚

8.1. Normative References

[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>.

8.2. Informative References

[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>.

Acknowledgments 🫶

This document was motivated by the Yahoo! team and their questions about best client practices for dealing with large mailboxes. Real ones asking the real questions 🙌

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. Thank you, besties 💖

Authors' Addresses 💌

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
📦 where this page comes from