rfc9738.original   rfc9738.txt 
Network Working Group A. Melnikov Internet Engineering Task Force (IETF) A. Melnikov
Internet-Draft Isode Request for Comments: 9738 Isode
Intended status: Experimental A. P. Achuthan Category: Experimental A. P. Achuthan
Expires: 30 January 2025 V. Nagulakonda ISSN: 2070-1721 V. Nagulakonda
Yahoo! Yahoo!
L. Alves L. Alves
29 July 2024 February 2025
IMAP MESSAGELIMIT Extension IMAP MESSAGELIMIT Extension
draft-ietf-extra-imap-messagelimit-10
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 of messages that can be processed in a single FETCH, SEARCH, STORE,
FETCH/SEARCH/STORE/COPY/MOVE (or their UID variants), APPEND or UID COPY, or MOVE command (or their UID variants), or in a single APPEND
EXPUNGE command. This helps servers to control resource usage when or UID EXPUNGE command. This helps servers to control resource usage
performing various IMAP operations. This helps clients to know the when performing various IMAP operations. This helps clients to know
message limit enforced by corresponding IMAP server and avoid issuing the message limit enforced by the corresponding IMAP server and avoid
commands that would exceed such limit. issuing commands that would exceed such limit.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for examination, experimental implementation, and
evaluation.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document defines an Experimental Protocol for the Internet
and may be updated, replaced, or obsoleted by other documents at any community. This document is a product of the Internet Engineering
time. It is inappropriate to use Internet-Drafts as reference Task Force (IETF). It represents the consensus of the IETF
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on 30 January 2025. 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 Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Please review these documents carefully, as they describe your rights carefully, as they describe your rights and restrictions with respect
and restrictions with respect to this document. Code Components to this document. Code Components extracted from this document must
extracted from this document must include Revised BSD License text as include Revised BSD License text as described in Section 4.e of the
described in Section 4.e of the Trust Legal Provisions and are Trust Legal Provisions and are provided without warranty as described
provided without warranty as described in the Revised BSD License. in the Revised BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
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 . . . . . . . . . . . . . . . . . . 3 1. Introduction and Overview
2. Document Conventions . . . . . . . . . . . . . . . . . . . . 3 2. Document Conventions
3. The MESSAGELIMIT extension . . . . . . . . . . . . . . . . . 3 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 Single Command
command . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. UIDAFTER and UIDBEFORE SEARCH Criteria
3.2. UIDAFTER and UIDBEFORE SEARCH criteria . . . . . . . . . 7 3.3. Interaction with SORT and THREAD Extensions
3.3. Interaction with SORT and THREAD extensions . . . . . . . 8 3.4. Interaction with SEARCHRES Extension and IMAP4rev2
3.4. Interaction with SEARCHRES extension and IMAP4rev2 . . . 8 4. Interoperability Considerations
4. Interoperability Considerations . . . . . . . . . . . . . . . 8 4.1. Effects of MESSAGELIMIT and SAVELIMIT Extensions on
4.1. Effects of MESSAGELIMIT/SAVELIMIT extensions on non Noncompliant Clients
compliant clients . . . . . . . . . . . . . . . . . . . . 8 4.2. Maintaining Compatibility
4.2. Maintaining Compatibility . . . . . . . . . . . . . . . . 9 5. Formal Syntax
5. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7.1. Additions to the IMAP Capabilities Registry
7.1. Changes/additions to the IMAP4 capabilities registry . . 10 8. References
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.2. Informative References
9.1. Normative References . . . . . . . . . . . . . . . . . . 11 Acknowledgments
9.2. Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
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/COPY/ messages that can be processed in a single FETCH, SEARCH, STORE,
MOVE (or their UID variants), APPEND or UID EXPUNGE command. This COPY, or MOVE command (or their UID variants), or a single APPEND or
extension is compatible with both IMAP4rev1 [RFC3501] and IMAP4rev2 UID EXPUNGE command. This extension is compatible with both
[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
explaining the previous protocol line. These prefixes and comments explaining the previous protocol line. These prefixes and comments
are not part of the protocol. Lines without any of these prefixes are not part of the protocol. Lines without any of these prefixes
are continuations of the previous line, and no line break is present are continuations of the previous line, and no line break is present
in the protocol unless specifically mentioned. in the protocol unless specifically mentioned.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Other capitalised words are IMAP key words [RFC3501][RFC9051] or key Other capitalized words are IMAP key words [RFC3501][RFC9051] or key
words from this document. words from this document.
3. The MESSAGELIMIT extension 3. The MESSAGELIMIT Extension
An IMAP server advertises support for the MESSAGELIMIT extension by An IMAP server advertises support for the MESSAGELIMIT extension by
including "MESSAGELIMIT=<limit>" capability in the CAPABILITY including "MESSAGELIMIT=<limit>" capability in the CAPABILITY
response/response code, where "<limit>" is a positive integer that response or response code, where "<limit>" is a positive integer that
conveys the maximum number of messages that can be processed in a conveys the maximum number of messages that can be processed in a
single [UID] SEARCH/FETCH/STORE/COPY/MOVE, APPEND or UID EXPUNGE single SEARCH, FETCH, STORE, COPY, MOVE command (or their UID
command. variants), or in a single APPEND or UID EXPUNGE command.
An IMAP server that only enforces message limit on [UID] COPY/APPEND An IMAP server that only enforces the message limit on COPY and
commands would include the "SAVELIMIT=<limit>" capability (instead of APPEND commands (and their UID variants) would include the
the "MESSAGELIMIT=<limit>") in the CAPABILITY response/response code. "SAVELIMIT=<limit>" capability (instead of the
"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/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/MOVE (or their UID operated on by a single SEARCH, FETCH, STORE, or MOVE command (or
variants), APPEND or UID EXPUNGE command, it MUST return the their UID variants), or an APPEND or UID EXPUNGE command, it MUST
MESSAGELIMIT response code defined below: return the MESSAGELIMIT response code defined below:
MESSAGELIMIT The server doesn't allow more than <N> messages to be operated MESSAGELIMIT
on by a single SEARCH/FETCH/STORE/COPY/MOVE command (or their The server doesn't allow more than <N> messages to be operated on
UID variants). The lowest processed UID is <LastUID>. The by a single SEARCH, FETCH, STORE, COPY, or MOVE command (or their
client needs to repeat the operation for remaining messages, if UID variants). The lowest processed UID is <LastUID>. The client
required. needs to repeat the operation for remaining messages, if required.
The server doesn't allow more than <N> \Deleted messages to be The server doesn't allow more than <N> \Deleted messages to be
operated on by a single UID EXPUNGE command. The lowest operated on by a single UID EXPUNGE command. The lowest processed
processed UID is <LastUID>. The client needs to repeat the UID is <LastUID>. The client needs to repeat the operation for
operation for remaining messages, if required. remaining messages, if required.
Note that when the MESSAGELIMIT response code is returned, the Note that when the MESSAGELIMIT response code is returned, the
server is REQUIRED to process messages from highest to lowest server is REQUIRED to process messages from highest to lowest UID.
UIDs.
Note that when the MESSAGELIMIT response code is similar to the Note that the MESSAGELIMIT response code is similar to the LIMIT
LIMIT ([RFC9051]) response code, but it provides more details response code [RFC9051], but it provides more details on the exact
on the exact type of the limit and how to resume the command type of the limit and how to resume the command once the limit is
once the limit is exceeded. exceeded.
In the following example the <N> value is 1000 and the lowest In the following example, the <N> value is 1000, and the lowest
processed UID <LastUID> is 23221. processed UID <LastUID> is 23221.
C: 03 FETCH 10000:14589 (UID FLAGS) C: 03 FETCH 10000:14589 (UID FLAGS)
S: * 14589 FETCH (FLAGS (\Seen) UID 25000) S: * 14589 FETCH (FLAGS (\Seen) UID 25000)
S: * 14588 FETCH (FLAGS (\Answered) UID 24998) S: * 14588 FETCH (FLAGS (\Answered) UID 24998)
S: ... further 997 fetch responses S: ... further 997 fetch responses
S: * 13590 FETCH (FLAGS () UID 23221) S: * 13590 FETCH (FLAGS () UID 23221)
S: 03 OK [MESSAGELIMIT 1000 23221] FETCH completed with 1000 partial S: 03 OK [MESSAGELIMIT 1000 23221] FETCH completed with 1000
results partial results
In the following example the client searches for UNDELETED UIDs In the following example the client searches for UNDELETED UIDs
between 22000:25000. The total number of searched messages between 22000:25000. The total number of searched messages (note,
(note, NOT the number of matched messages) exceeds the server's NOT the number of matched messages) exceeds the server's published
published 1000 messages limit. 1000-message limit.
C: 04 UID SEARCH UID 22000:25000 UNDELETED C: 04 UID SEARCH UID 22000:25000 UNDELETED
S: * SEARCH 25000 24998 (... UIDs ...) 23221 S: * SEARCH 25000 24998 (... UIDs ...) 23221
S: 04 OK [MESSAGELIMIT 1000 23221] SEARCH completed with 1000 partial results S: 04 OK [MESSAGELIMIT 1000 23221] SEARCH completed with 1000
partial results
The following example demonstrates copy of messages with UIDs The following example demonstrates the copy of messages with UIDs
between 18000:21000. The total message count exceeds the between 18000:21000. The total message count exceeds the server's
server's published 1000 messages limit. As COPY/UID COPY needs published 1000-message limit. As COPY or UID COPY needs to be
to atomic (as per [RFC3501]/[RFC9051]), no messages are copied. atomic (as per [RFC3501]/[RFC9051]), no messages are copied.
C: 05 UID COPY 18000:21000 "Trash" C: 05 UID COPY 18000:21000 "Trash"
S: 05 NO [MESSAGELIMIT 1000 20001] Too many messages to copy, try a smaller subset S: 05 NO [MESSAGELIMIT 1000 20001] Too many messages to copy,
try a smaller subset
The following example shows MOVE of messages with UIDs between The following example shows the move of messages with UIDs between
18000:21000. The total message count exceeds the server's 18000:21000. The total message count exceeds the server's
published 1000 messages limit. (Unlike COPY/UID COPY, MOVE/UID published 1000-message limit. (Unlike COPY or UID COPY, MOVE or
MOVE don't need to be atomic.) The client that wants to 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 all messages in the range and observes a MESSAGELIMIT response
code, can repeat the UID MOVE command with the same parameter. code can repeat the UID MOVE command with the same parameter.
(For the MOVE command, the message set parameter need to be (For the MOVE command, the message set parameter needs to be
updated before repeating the command.) The client needs to updated before repeating the command.) The client needs to keep
keep doing this until the MESSAGELIMIT response is not returned doing this until the MESSAGELIMIT response is not returned (or
(or until a tagged NO/BAD is returned). until a tagged NO or BAD is returned).
C: 06 UID MOVE 18000:21000 "Archive/2021/2021-12" C: 06 UID MOVE 18000:21000 "Archive/2021/2021-12"
S: * OK [COPYUID 1397597919 20001:21000 22363:23362] Some messages were not moved S: * OK [COPYUID 1397597919 20001:21000 22363:23362] Some
S: * 12336 EXPUNGE messages were not moved
S: * 12335 EXPUNGE S: * 12336 EXPUNGE
... S: * 12335 EXPUNGE
S: * 11337 EXPUNGE ...
S: 06 OK [MESSAGELIMIT 1000 20001] MOVE completed for the last 1000 messages S: * 11337 EXPUNGE
S: 06 OK [MESSAGELIMIT 1000 20001] MOVE completed for the last
1000 messages
The following example shows update of flags for messages with The following example shows the update of flags for messages with
UIDs between 18000:20000. The total number of existing UIDs between 18000:20000. The total number of existing messages
messages in the UID range exceeds the server's published 1000 in the UID range exceeds the server's published 1000-message
messages limit. The client that wants to change flags for all limit. The client that wants to change flags for all messages in
messages in the range and observes a MESSAGELIMIT response the range and observes a MESSAGELIMIT response code can repeat the
code, can repeat the UID STORE command with the updated UID UID STORE command with the updated UID range that doesn't include
range that doesn't include the UID returned in the MESSAGELIMIT the UID returned in the MESSAGELIMIT response code. (For the
response code. (For the STORE command, the message set STORE command, the message set parameter also needs to be updated
parameter also need to be updated before repeating the before repeating the command.) The client needs to keep doing
command.) The client needs to keep doing this until the this until the MESSAGELIMIT response is not returned (or until a
MESSAGELIMIT response is not returned (or until a tagged NO/BAD tagged NO or BAD is returned).
is returned).
C: 07 UID STORE 18000:20000 +FLAGS (\Seen) C: 07 UID STORE 18000:20000 +FLAGS (\Seen)
S: * 11215 FETCH (FLAGS (\Seen \Deleted) UID 20000) S: * 11215 FETCH (FLAGS (\Seen \Deleted) UID 20000)
S: * 11214 FETCH (FLAGS (\Seen \Answered \Deleted) UID 19998) S: * 11214 FETCH (FLAGS (\Seen \Answered \Deleted) UID 19998)
... ...
S: * 10216 FETCH (FLAGS (\Seen) UID 19578) S: * 10216 FETCH (FLAGS (\Seen) UID 19578)
S: 07 OK [MESSAGELIMIT 1000 19578] STORE completed for the last 1000 messages S: 07 OK [MESSAGELIMIT 1000 19578] STORE completed for the last
1000 messages
The following example shows removal of messages (using UID The following example shows the removal of messages (using UID
EXPUNGE) that have \Deleted flag set with UIDs between EXPUNGE) that have the \Deleted flag set with UIDs between
11000:13000. The total message count of messages with \Deleted 11000:13000. The total message count of messages with the
flag set exceeds the server's published 1000 messages limit. \Deleted flag set exceeds the server's published 1000-message
The client that wants to remove all messages marked as \Deleted limit. The client that wants to remove all messages marked as
in the range and observes a MESSAGELIMIT response code, can \Deleted in the range and observes a MESSAGELIMIT response code
repeat the UID EXPUNGE command with the same parameter. The can repeat the UID EXPUNGE command with the same parameter. The
client needs to keep doing this until the MESSAGELIMIT response client needs to keep doing this until the MESSAGELIMIT response is
is not returned (or until a tagged NO/BAD is returned). not returned (or until a tagged NO or BAD is returned).
C: 08 UID EXPUNGE 11000:13000 C: 08 UID EXPUNGE 11000:13000
S: * 4306 EXPUNGE S: * 4306 EXPUNGE
S: * 4305 EXPUNGE S: * 4305 EXPUNGE
... ...
S: * 3307 EXPUNGE S: * 3307 EXPUNGE
S: 08 OK [MESSAGELIMIT 1000 11627] UID EXPUNGE completed for the last 1000 messages S: 08 OK [MESSAGELIMIT 1000 11627] UID EXPUNGE completed for
the last 1000 messages
The following example shows removal of messages (using EXPUNGE) The following example shows removal of messages (using EXPUNGE)
that have \Deleted flag set. Unlike UID EXPUNGE, the server that have the \Deleted flag set. Unlike UID EXPUNGE, the server
MUST NOT impose any message limit when processing EXPUNGE. MUST NOT impose any message limit when processing EXPUNGE.
C: 09 EXPUNGE C: 09 EXPUNGE
S: * 4306 EXPUNGE S: * 4306 EXPUNGE
S: * 4305 EXPUNGE S: * 4305 EXPUNGE
... ...
S: * 3307 EXPUNGE S: * 3307 EXPUNGE
S: * 112 EXPUNGE S: * 112 EXPUNGE
S: 09 OK EXPUNGE completed S: 09 OK EXPUNGE completed
Similarly, the server MUST NOT impose any message limit when Similarly, the server MUST NOT impose any message limit when
processing a "CLOSE" or a "STATUS UNSEEN" command. processing a "CLOSE" or a "STATUS UNSEEN" command.
The following example shows use of MESSAGELIMIT response code The following example shows use of the MESSAGELIMIT response code
together with the PARTIAL [RFC9394] extension. The total together with the PARTIAL [RFC9394] extension. The total message
message count (as specified by the PARTIAL range) exceeds the count (as specified by the PARTIAL range) exceeds the server's
server's published 1000 messages limit, so the server refuses published 1000-message limit, so the server refuses to do any work
to do any work in this case. in this case.
C: 10 UID FETCH 22000:25000 (UID FLAGS MODSEQ) (PARTIAL -1:-1500) C: 10 UID FETCH 22000:25000 (UID FLAGS MODSEQ)
S: 10 NO [MESSAGELIMIT 1000] FETCH exceeds the maximum 1000 message limit (PARTIAL -1:-1500)
S: 10 NO [MESSAGELIMIT 1000] FETCH exceeds the maximum 1000-
message limit
Without the PARTIAL parameter the above UID FETCH can look like Without the PARTIAL parameter, the above UID FETCH can look like
this: this:
C: 10 UID FETCH 22000:25000 (UID FLAGS MODSEQ) C: 10 UID FETCH 22000:25000 (UID FLAGS MODSEQ)
S: * 12367 FETCH (FLAGS (\Seen \Deleted) UID 23007) S: * 12367 FETCH (FLAGS (\Seen \Deleted) UID 23007)
S: * 12366 FETCH (FLAGS (\Seen \Answered \Deleted) UID 23114) S: * 12366 FETCH (FLAGS (\Seen \Answered \Deleted) UID 23114)
... ...
S: * 13366 FETCH (FLAGS (\Seen) UID 24598) S: * 13366 FETCH (FLAGS (\Seen) UID 24598)
S: 10 OK [MESSAGELIMIT 1000 23007] FETCH exceeds the maximum 1000 message limit S: 10 OK [MESSAGELIMIT 1000 23007] FETCH exceeds the maximum
1000-message limit
Note that when the server needs to return both EXPUNGEISSUED Note that when the server needs to return both EXPUNGEISSUED
([RFC9051]) and MESSAGELIMIT response codes, the former MUST be [RFC9051] and MESSAGELIMIT response codes, the former MUST be
returned in the tagged OK response, while the latter MUST be returned returned in the tagged OK response, while the latter MUST be returned
in an untagged NO response. The following example demonstrates that: in an untagged NO response. The following example demonstrates that:
C: 11 FETCH 10000:14589 (UID FLAGS) C: 11 FETCH 10000:14589 (UID FLAGS)
S: * 14589 FETCH (FLAGS (\Seen) UID 25000) S: * 14589 FETCH (FLAGS (\Seen) UID 25000)
S: * 14588 FETCH (FLAGS (\Answered) UID 24998) S: * 14588 FETCH (FLAGS (\Answered) UID 24998)
S: ... further 997 fetch responses S: ... further 997 fetch responses
S: * 13590 FETCH (FLAGS () UID 23221) S: * 13590 FETCH (FLAGS () UID 23221)
S: * NO [MESSAGELIMIT 1000 23221] FETCH completed with 1000 partial S: * NO [MESSAGELIMIT 1000 23221] FETCH completed with 1000 partial
results results
S: 11 OK [EXPUNGEISSUED] Some messages were also expunged S: 11 OK [EXPUNGEISSUED] Some messages were also expunged
When IMAP MULTIAPPEND [RFC3502] extension is also supported by the When the IMAP MULTIAPPEND extension [RFC3502] is also supported by
server, the message limit also applies to the APPEND command. As the server, the message limit also applies to the APPEND command. As
MULTIAPPEND APPEND needs to atomic (as per [RFC3502]), no messages MULTIAPPEND APPEND needs to atomic (as per [RFC3502]), no messages
are appended when the server MESSAGELIMIT is exceeded. are appended when the server MESSAGELIMIT is exceeded.
3.2. UIDAFTER and UIDBEFORE SEARCH criteria 3.2. UIDAFTER and UIDBEFORE SEARCH Criteria
The MESSAGELIMIT extension also defines 2 extra SEARCH keys: UIDAFTER The MESSAGELIMIT extension also defines two extra SEARCH keys,
and UIDBEFORE, which make it easier to convert a single UID to a UIDAFTER and UIDBEFORE, which make it easier to convert a single UID
range of UIDs. to a range of UIDs.
"UIDAFTER <uid>" - Messages that have a UID greater than the "UIDAFTER <uid>" Messages that have a UID greater than the specified
specified UID. This is semantically the same as "UID <uid>+1:*". UID. This is semantically the same as "UID <uid>+1:*".
"UIDBEFORE <uid>" - Messages that have a UID less than the specified "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> UID. This is semantically the same as "UID 1:<uid>-1" (or if
has the value 1, then the empty set). <uid> has the value 1, then the empty set).
These 2 SEARCH keys are particularly useful when the SEARCHRES These two SEARCH keys are particularly useful when the SEARCHRES
[RFC5182] extension is also supported, but they can be used without extension [RFC5182] is also supported, but they can be used without
it. For example, this allows a SEARCH that sets the "$" marker to be 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 converted to a range of messages in a subsequent SEARCH, and both
SEARCH requests can be pipelined. SEARCH requests can be pipelined.
C: 12 UID SEARCH UIDAFTER 25000 UNDELETED C: 12 UID SEARCH UIDAFTER 25000 UNDELETED
S: * SEARCH 27800 27798 (... 250 UIDs ...) 25001 S: * SEARCH 27800 27798 (... 250 UIDs ...) 25001
S: 12 OK SEARCH completed S: 12 OK SEARCH completed
3.3. Interaction with SORT and THREAD extensions 3.3. Interaction with SORT and THREAD Extensions
Servers that advertise MESSAGELIMIT N will be unable to execute a Servers that advertise MESSAGELIMIT N will be unable to execute a
THREAD [RFC5256] command in a mailbox with more than N messages. THREAD command [RFC5256] in a mailbox with more than N messages.
Servers that advertise MESSAGELIMIT N might be unable to execute a Servers that advertise MESSAGELIMIT N might be unable to execute a
SORT [RFC5256] command in a mailbox with more than N messages, unless SORT command [RFC5256] in a mailbox with more than N messages, unless
they maintain indices for different SORT orders they support. In they maintain indices for different SORT orders they support. In
absence of such indeces server implementors will need to decide absence of such indices, server implementors will need to decide
whether their server advertises SORT or MESSAGELIMIT capability. whether their server advertises SORT or MESSAGELIMIT capability.
3.4. Interaction with SEARCHRES extension and IMAP4rev2 3.4. Interaction with SEARCHRES Extension and IMAP4rev2
Servers that support both MESSAGELIMIT and SEARCHRES [RFC5182] Servers that support both MESSAGELIMIT and SEARCHRES extensions
extensions MUST truncate SEARCH SAVE result stored in the $ variable [RFC5182] MUST truncate SEARCH SAVE result stored in the $ variable
when the SEARCH command succeeds, but the MESSAGELIMIT response code when the SEARCH command succeeds, but the MESSAGELIMIT response code
is returned. For example, if the following SEARCH would have is returned. For example, if the following SEARCH would have
returned 1200 results in absence of MESSAGELIMIT, and the returned 1200 results in absence of MESSAGELIMIT, and the
MESSAGELIMIT is 1000, only 1000 matching results will be saved in the MESSAGELIMIT is 1000, only 1000 matching results will be saved in the
$ variable: $ variable:
C: D0004 UID SEARCH RETURN (SAVE) SINCE 1-Jan-2004 NOT FROM "Smith" UID 22000:25000 UNDELETED C: D0004 UID SEARCH RETURN (SAVE) SINCE 1-Jan-2004 NOT FROM "Smith"
S: D0004 OK [MESSAGELIMIT 1000 1179] SEARCH completed with 1000 partial results saved UID 22000:25000 UNDELETED
S: D0004 OK [MESSAGELIMIT 1000 1179] SEARCH completed with 1000
partial results saved
4. Interoperability Considerations 4. Interoperability Considerations
4.1. Effects of MESSAGELIMIT/SAVELIMIT extensions on non compliant 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/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
restricted to the last N messages of the mailbox. In restricted to the last N messages of the mailbox. In
particular unextended SEARCHes intended for counting of particular, unextended SEARCHes (intended for counting of
messages with or without a particular set of flags would return messages with or without a particular set of flags) would
incorrect counts. return incorrect counts.
4.2. Maintaining Compatibility 4.2. Maintaining Compatibility
It is important to understand that the above effects essentially It is important to understand that the above effects essentially
abandon existing clients with respect to operation on large abandon existing clients with respect to operation on large
mailboxes. Suppose, for example, that a user is accessing a large mailboxes. Suppose, for example, that a user is accessing a large
and active mailing list via IMAP - the mailing list gets on the order and active mailing list via IMAP, and the mailing list gets on the
of 1500 posts per week. When the user returns from a week-long order of 1500 posts per week. When the user returns from a week-long
vacation and catches up on the mailing list, the user’s client will vacation and catches up on the mailing list, the user's client will
be fetching information about 1500 messages. If the server has a be fetching information about 1500 messages. If the server has a
MESSAGELIMIT of 1000, the client will only be able to download 1000 MESSAGELIMIT of 1000, the client will only be able to download 1000
of most recent messages; the client will not understand why, will not of the most recent messages; the client will not understand why, will
be prepared to recover from the situation, and will act as if it is not be prepared to recover from the situation, and will act as if it
interacting with a broken server. is interacting with a broken server.
In order to give clients time to implement this extension, servers In order to give clients time to implement this extension, servers
should not be strict about applying the MESSAGELIMIT at first. One should not be strict about applying the MESSAGELIMIT at first. One
possible approach is to advertise a MESSAGELIMIT but not enforce it possible approach is to advertise a MESSAGELIMIT but not enforce it
at all for a while. Clients that understand this extension will at all for a while. Clients that understand this extension will
comply, reducing load on the server, but clients that do not comply, reducing load on the server, but clients that do not
understand the limit will continue to work in all situations. understand the limit will continue to work in all situations.
Another approach, perhaps phased in later, is to advertise one limit Another approach, which perhaps could be phased in later, is to
but to treat it as a soft limit and to begin enforcement at a higher, advertise one limit but to treat it as a soft limit and to begin
unadvertised hard limit. In the above example, perhaps the server enforcement at a higher, unadvertised hard limit. In the above
might advertise 1000 but actually enforce a limit of 10,000. Again, example, perhaps the server might advertise 1000 but actually enforce
clients that understand MESSAGELIMIT will comply with the limit of a limit of 10,000. Again, clients that understand MESSAGELIMIT will
1000, but other clients will still interoperate up to the higher comply with the limit of 1000, but other clients will still
threshold. interoperate up to the higher threshold.
Attempts to go beyond the advertised limit can be logged so that Attempts to go beyond the advertised limit can be logged so that
client understanding of MESSAGELIMIT can be tracked. If client understanding of MESSAGELIMIT can be tracked. If
implementation and deployment of this extension becomes common, it implementation and deployment of this extension becomes common, it
may at some point be acceptable to strictly enforce the advertised may at some point be acceptable to strictly enforce the advertised
limit and to accept that the remaining clients will, indeed, no limit and to accept that the remaining clients will, indeed, no
longer work properly with mailboxes above that limit. longer work properly with mailboxes above that limit.
5. Formal syntax 5. Formal Syntax
The following syntax specification uses the Augmented Backus-Naur The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) notation as specified in [ABNF]. Form (ABNF) notation as specified in [ABNF].
Non-terminals referenced but not defined below are as defined by Non-terminals referenced but not defined below are as defined by
IMAP4 [RFC3501]. IMAP4 [RFC3501].
Except as noted otherwise, all alphabetic characters are case- Except as noted otherwise, all alphabetic characters are case-
insensitive. The use of upper or lower case characters to define insensitive. The use of uppercase or lowercase characters to define
token strings is for editorial clarity only. Implementations MUST token strings is for editorial clarity only. Implementations MUST
accept these strings in a case-insensitive fashion. accept these strings in a case-insensitive fashion.
capability =/ "MESSAGELIMIT=" message-limit / capability =/ "MESSAGELIMIT=" message-limit /
"SAVELIMIT=" message-limit "SAVELIMIT=" message-limit
;; <capability> from [RFC3501] ;; <capability> from [RFC3501]
message-limit = nz-number message-limit = nz-number
resp-text-code =/ "MESSAGELIMIT" SP message-limit [SP uniqueid] resp-text-code =/ "MESSAGELIMIT" SP message-limit [SP uniqueid]
;; No more than nz-number messages can be processed ;; No more than nz-number messages can be processed
;; by any command at a time. The last (lowest) processed ;; by any command at a time. The last (lowest) processed
;; UID is uniqueid. ;; UID is uniqueid.
;; The last parameter is omitted, when not known. ;; The last parameter is omitted when not known.
6. Security Considerations 6. Security Considerations
This document defines an additional IMAP4 capability. As such, it This document defines an additional IMAP4 capability. As such, it
does not change the underlying security considerations of [RFC3501] does not change the underlying security considerations of IMAP4rev1
and IMAP4rev2 [RFC9051]. [RFC3501] or IMAP4rev2 [RFC9051].
This document defines an optimization that can both reduce the amount This document defines an optimization that can both reduce the amount
of work performed by the server, as well at the amount of data of work performed by the server, as well at the amount of data
returned to the client. Use of this extension is likely to cause the 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 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 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 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 and the server, rigorous testing of such code is required in order to
avoid introducing of new implementation bugs. avoid introducing new implementation bugs.
7. IANA Considerations 7. IANA Considerations
7.1. Changes/additions to the IMAP4 capabilities registry 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 registry is
currently located at:
https://www.iana.org/assignments/imap-capabilities/
IANA is requested to add registrations of "MESSAGELIMIT=" and
"SAVELIMIT=" capabilities to this registry, both pointing to this
document.
8. Acknowledgments
This document was motivated by the Yahoo! team and their questions IMAP4 capabilities are registered by publishing a Standards Track or
about best client practices for dealing with large mailboxes. IESG-approved Informational or Experimental RFC. The "IMAP
Capabilities" registry is currently located at:
<https://www.iana.org/assignments/imap-capabilities/>.
Editor of this document would like to thank the following people who IANA has added "MESSAGELIMIT=" and "SAVELIMIT=" capabilities to this
provided useful comments, contributed text or participated in registry, with this document as the reference.
discussions of this document: Timo Sirainen, Barry Leiba, Ken
Murchison and Arnt Gulbrandsen.
9. References 8. References
9.1. Normative References 8.1. Normative References
[ABNF] Crocker, D., Ed. and P. Overell, Ed., "Augmented BNF for [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Syntax Specifications: ABNF", RFC 5234, January 2008, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
<https://www.rfc-editor.org/info/rfc3501>. <https://www.rfc-editor.org/info/rfc3501>.
skipping to change at page 12, line 14 skipping to change at line 515
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message [RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message
Access Protocol (IMAP) - Version 4rev2", RFC 9051, Access Protocol (IMAP) - Version 4rev2", RFC 9051,
DOI 10.17487/RFC9051, August 2021, DOI 10.17487/RFC9051, August 2021,
<https://www.rfc-editor.org/info/rfc9051>. <https://www.rfc-editor.org/info/rfc9051>.
9.2. Informative References 8.2. Informative References
[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>.
Index Acknowledgments
M
M This document was motivated by the Yahoo! team and their questions
about best client practices for dealing with large mailboxes.
MESSAGELIMIT (response code) The authors of this document would like to thank the following people
Section 3.1, Paragraph 2.2.1 who provided useful comments, contributed text, or participated in
discussions of this document: Timo Sirainen, Barry Leiba, Ken
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
Arun Prakash Achuthan Arun Prakash Achuthan
Yahoo! Yahoo!
 End of changes. 82 change blocks. 
275 lines changed or deleted 274 lines changed or added

This html diff was produced by rfcdiff 1.48.