rfc9738v1.txt   rfc9738.txt 
skipping to change at line 15 skipping to change at line 15
ISSN: 2070-1721 V. Nagulakonda ISSN: 2070-1721 V. Nagulakonda
Yahoo! Yahoo!
L. Alves L. Alves
February 2025 February 2025
IMAP MESSAGELIMIT Extension IMAP MESSAGELIMIT Extension
Abstract Abstract
The MESSAGELIMIT extension of the Internet Message Access Protocol The MESSAGELIMIT extension of the Internet Message Access Protocol
(RFC 3501/RFC 9051) allows servers to announce a limit on the number (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, 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 COPY, or MOVE command (or their UID variants), or in a single APPEND
or UID EXPUNGE command. This helps servers to control resource usage or UID EXPUNGE command. This helps servers to control resource usage
when performing various IMAP operations. This helps clients to know when performing various IMAP operations. This helps clients to know
the message limit enforced by the corresponding IMAP server and avoid the message limit enforced by the corresponding IMAP server and avoid
issuing commands that would exceed such limit. issuing commands that would exceed such limit.
Status of This Memo Status of This Memo
This document is not an Internet Standards Track specification; it is This document is not an Internet Standards Track specification; it is
skipping to change at line 74 skipping to change at line 74
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction and Overview 1. Introduction and Overview
2. Document Conventions 2. Document Conventions
3. The MESSAGELIMIT Extension 3. The MESSAGELIMIT Extension
3.1. Returning Limits on the Number of Messages Processed in a 3.1. Returning Limits on the Number of Messages Processed in a
Single SEARCH/FETCH/STORE/COPY/MOVE/APPEND/EXPUNGE Command Single Command
3.2. UIDAFTER and UIDBEFORE SEARCH Criteria 3.2. UIDAFTER and UIDBEFORE SEARCH Criteria
3.3. Interaction with SORT and THREAD Extensions 3.3. Interaction with SORT and THREAD Extensions
3.4. Interaction with SEARCHRES Extension and IMAP4rev2 3.4. Interaction with SEARCHRES Extension and IMAP4rev2
4. Interoperability Considerations 4. Interoperability Considerations
4.1. Effects of MESSAGELIMIT and SAVELIMIT Extensions on 4.1. Effects of MESSAGELIMIT and SAVELIMIT Extensions on
Noncompliant Clients Noncompliant Clients
4.2. Maintaining Compatibility 4.2. Maintaining Compatibility
5. Formal Syntax 5. Formal Syntax
6. Security Considerations 6. Security Considerations
7. IANA Considerations 7. IANA Considerations
7.1. Additions to the IMAP Capabilities Registry 7.1. Additions to the IMAP Capabilities Registry
8. References 8. References
8.1. Normative References 8.1. Normative References
8.2. Informative References 8.2. Informative References
Acknowledgments Acknowledgments
Authors' Addresses Authors' Addresses
1. Introduction and Overview 1. Introduction and Overview
This document defines an extension to the Internet Message Access This document defines an extension to the Internet Message Access
Protocol [RFC3501] for announcing a server limit on the number of Protocol [RFC9051] for announcing a server limit on the number of
messages that can be processed in a single FETCH, SEARCH, STORE, messages that can be processed in a single FETCH, SEARCH, STORE,
COPY, or MOVE command (or their UID variants), or a single APPEND or COPY, or MOVE command (or their UID variants), or a single APPEND or
UID EXPUNGE command. This extension is compatible with both UID EXPUNGE command. This extension is compatible with both
IMAP4rev1 [RFC3501] and IMAP4rev2 [RFC9051]. IMAP4rev1 [RFC3501] and IMAP4rev2 [RFC9051].
2. Document Conventions 2. Document Conventions
In protocol examples, this document uses a prefix of "C: " to denote 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 lines sent by the client to the server, and "S: " for lines sent by
the server to the client. Lines prefixed with "// " are comments the server to the client. Lines prefixed with "// " are comments
skipping to change at line 138 skipping to change at line 138
An IMAP server that only enforces the message limit on COPY and An IMAP server that only enforces the message limit on COPY and
APPEND commands (and their UID variants) would include the APPEND commands (and their UID variants) would include the
"SAVELIMIT=<limit>" capability (instead of the "SAVELIMIT=<limit>" capability (instead of the
"MESSAGELIMIT=<limit>") in the CAPABILITY response or response code. "MESSAGELIMIT=<limit>") in the CAPABILITY response or response code.
The limit advertised in the MESSAGELIMIT or SAVELIMIT capability The limit advertised in the MESSAGELIMIT or SAVELIMIT capability
SHOULD NOT be lower than 1000 messages. SHOULD NOT be lower than 1000 messages.
3.1. Returning Limits on the Number of Messages Processed in a Single 3.1. Returning Limits on the Number of Messages Processed in a Single
SEARCH/FETCH/STORE/COPY/MOVE/APPEND/EXPUNGE Command Command
If a server implementation doesn't allow more than <N> messages to be If a server implementation doesn't allow more than <N> messages to be
operated on by a single COPY or UID COPY command, it MUST fail the operated on by a single COPY or UID COPY command, it MUST fail the
command by returning a tagged NO response with the MESSAGELIMIT command by returning a tagged NO response with the MESSAGELIMIT
response code defined below. No messages are copied in this case. response code defined below. No messages are copied in this case.
If a server implementation doesn't allow more than <N> messages to be If a server implementation doesn't allow more than <N> messages to be
operated on by a single SEARCH, FETCH, STORE, or MOVE command (or operated on by a single SEARCH, FETCH, STORE, or MOVE command (or
their UID variants), or an APPEND or UID EXPUNGE command, it MUST their UID variants), or an APPEND or UID EXPUNGE command, it MUST
return the MESSAGELIMIT response code defined below: return the MESSAGELIMIT response code defined below:
skipping to change at line 370 skipping to change at line 370
partial results saved partial results saved
4. Interoperability Considerations 4. Interoperability Considerations
4.1. Effects of MESSAGELIMIT and SAVELIMIT Extensions on Noncompliant 4.1. Effects of MESSAGELIMIT and SAVELIMIT Extensions on Noncompliant
Clients Clients
A server that advertises the MESSAGELIMIT=N capability would have the A server that advertises the MESSAGELIMIT=N capability would have the
following effect on clients that don't support this capability: following effect on clients that don't support this capability:
* Operations on a mailbox that has <= N messages are not affected. * Operations are not affected on a mailbox that has N messages or
fewer.
* In a mailbox with more than N messages: * In a mailbox with more than N messages:
- An attempt to COPY or UID COPY more than N messages will always - An attempt to COPY or UID COPY more than N messages will always
fail. fail.
- EXPUNGE and CLOSE will always operate on the full mailbox, so - EXPUNGE and CLOSE will always operate on the full mailbox, so
they are not affected. they are not affected.
- Other commands like FETCH, SEARCH, and MOVE will be effectively - Other commands like FETCH, SEARCH, and MOVE will be effectively
skipping to change at line 526 skipping to change at line 527
[RFC9394] Melnikov, A., Achuthan, A. P., Nagulakonda, V., and L. [RFC9394] Melnikov, A., Achuthan, A. P., Nagulakonda, V., and L.
Alves, "IMAP PARTIAL Extension for Paged SEARCH and Alves, "IMAP PARTIAL Extension for Paged SEARCH and
FETCH", RFC 9394, DOI 10.17487/RFC9394, June 2023, FETCH", RFC 9394, DOI 10.17487/RFC9394, June 2023,
<https://www.rfc-editor.org/info/rfc9394>. <https://www.rfc-editor.org/info/rfc9394>.
Acknowledgments Acknowledgments
This document was motivated by the Yahoo! team and their questions This document was motivated by the Yahoo! team and their questions
about best client practices for dealing with large mailboxes. about best client practices for dealing with large mailboxes.
The editor of this document would like to thank the following people The authors of this document would like to thank the following people
who provided useful comments, contributed text, or participated in who provided useful comments, contributed text, or participated in
discussions of this document: Timo Sirainen, Barry Leiba, Ken discussions of this document: Timo Sirainen, Barry Leiba, Ken
Murchison, and Arnt Gulbrandsen. Murchison, and Arnt Gulbrandsen.
Authors' Addresses Authors' Addresses
Alexey Melnikov Alexey Melnikov
Isode Limited Isode Limited
Email: alexey.melnikov@isode.com Email: alexey.melnikov@isode.com
URI: https://www.isode.com URI: https://www.isode.com
 End of changes. 6 change blocks. 
6 lines changed or deleted 7 lines changed or added

This html diff was produced by rfcdiff 1.48.