Javascript disabled? Like other modern websites, the IETF Datatracker relies on Javascript. Please enable Javascript for full functionality.

IMAP MESSAGELIMIT Extension
draft-ietf-extra-imap-messagelimit-01

Versions:

00
01
02
03
04
05
06
07
08
09
10
RFC 9738

The information below is for an old version of the document.

Document	Type	This is an older version of an Internet-Draft that was ultimately published as RFC 9738.
	Authors	Alexey Melnikov , ArunPrakash Achuthan , Vikram Nagulakonda , Luis Alves
	Last updated	2022-10-24
	RFC stream	Internet Engineering Task Force (IETF)
	Formats	txt html xml htmlized bibtex bibxml
	Reviews	ARTART Telechat review (of -10) by Barry Leiba Ready SECDIR IETF Last Call review (of -08) by Kathleen Moriarty Ready GENART IETF Last Call review (of -08) by Russ Housley Ready OPSDIR IETF Last Call review (of -08) by Joel Jaeggli Ready ARTART IETF Last Call review (of -08) by Barry Leiba Ready w/issues
	Additional resources	Mailing list discussion
Stream	WG state	WG Document
	Associated WG milestone	Dec 2023 Submit MESSAGELIMIT draft
	Document shepherd	(None)
IESG	IESG state	Became RFC 9738 (Experimental)
	Consensus boilerplate	Unknown
	Telechat date	(None)
	Responsible AD	(None)
	Send notices to	(None)

Email authors Email WG IPR References Referenced by Nits Nits v3 Search email archive

draft-ietf-extra-imap-messagelimit-01

Network Working Group A. Melnikov
Internet-Draft Isode
Intended status: Standards Track A. P. Achuthan
Expires: 27 April 2023 V. Nagulakonda
Yahoo!
L. Alves
24 October 2022

IMAP MESSAGELIMIT Extension
draft-ietf-extra-imap-messagelimit-01

Abstract

The MESSAGELIMIT extension of the Internet Message Access Protocol
(RFC 3501/RFC 9051) allows servers to announce a limit on the number
of messages that can be processed in a single
FETCH/SEARCH/STORE/COPY/MOVE command. This helps servers to control
resource usage when performing various IMAP operations.

Status of This Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on 27 April 2023.

Melnikov, et al. Expires 27 April 2023 [Page 1]
Internet-Draft IMAP MESSAGELIMIT October 2022

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
2. Document Conventions . . . . . . . . . . . . . . . . . . . . 3
3. The MESSAGELIMIT extension . . . . . . . . . . . . . . . . . 3
3.1. Use of ENABLE . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Returning limits on the number of messages processed in a
single SEARCH/FETCH/STORE/COPY/MOVE command . . . . . . . 4
3.3. Interaction with SORT and THREAD extensions . . . . . . . 6
4. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6.1. Changes/additions to the IMAP4 capabilities registry . . 7
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 8
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9

1. Introduction and Overview

This document defines an extension to the Internet Message Access
Protocol [RFC3501] for announcing a server limit on the number of
messages that can be processed in a single FETCH/SEARCH/STORE/COPY/
MOVE command. This extension is compatible with both IMAP4rev1
[RFC3501] and IMAP4rev2 [RFC9051].

Melnikov, et al. Expires 27 April 2023 [Page 2]
Internet-Draft IMAP MESSAGELIMIT October 2022

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.

Other capitalised words are IMAP keywords [RFC3501][RFC9051] or
keywords 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/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.

// Does this extension need use of ENABLE by clients to opt-in? In
// particular see below the open issue about COPY command atomicity.

3.1. Use of ENABLE

Servers supporting MESSAGELIMIT MUST implement and advertise support
for the ENABLE [RFC5161] IMAP extension. Issuance of the "ENABLE
MESSAGELIMIT" command tells the IMAP server that it understands the
MESSAGELIMIT response code and can cope with non atomic COPY/UID
COPY/MOVE/UID MOVE commands. (See Section 3.2.) This change remains
in effect until the connection is closed.

// Would this work? What is the incentive for clients to do this? A
client making use of MESSAGELIMIT extension MUST issue "ENABLE
MESSAGELIMIT" once it is authenticated.

Melnikov, et al. Expires 27 April 2023 [Page 3]
Internet-Draft IMAP MESSAGELIMIT October 2022

3.2. Returning limits on the number of messages processed in a single
SEARCH/FETCH/STORE/COPY/MOVE command

// Do we need a way to specify SEARCH criterion for "all UIDs after"
// or "all UIDs before" a specific UID? E.g. "UIDAFTER uniqueid" -
// Messages that have a UID greater than the specified UID.
// "UIDBEFORE uniqueid" - Messages that have a UID less than the
// specified UID.

If a server implementation doesn't allow more than <N> messages to be
operated on by a single SEARCH/FETCH/STORE/COPY/MOVE command, it MUST
return the MESSAGELIMIT response code defined below:

MESSAGELIMIT The server doesn't allow more than <N> messages to be operated
on by a single SEARCH/FETCH/STORE/COPY/MOVE command. The
lowest processed UID is <LastUID>. The client needs to repeat
the operation for remaining messages, if required.

In the following example the <N> value is 1000 and the lowest
processed UID <LastUID> is 23221.

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 the following example the client searches for UNDELETED UIDs
between 22000:25000. The total number of matching messages
exceeds the server's published 1000 messages limit.

C: 04 UID SEARCH UID 22000:25000 UNDELETED
S: * SEARCH 25000 24998 (... 997 UIDs ...) 23221
S: 04 OK [MESSAGELIMIT 1000 23221] SEARCH completed with 1000 partial results

The following example demonstrates copy of messages with UIDs
between 18000:21000. The total message count exceeds the
server's published 1000 messages limit.

C: 05 UID COPY 18000:21000 "Trash"
S: * NO [MESSAGELIMIT 1000 20001] Too many messages to copy
S: 05 OK [COPYUID 1397597919 20001:21000 21363:22362] COPY completed for the last 1000 messages

Melnikov, et al. Expires 27 April 2023 [Page 4]
Internet-Draft IMAP MESSAGELIMIT October 2022

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

The following example shows MOVE of messages with UIDs between
18000:21000. The total message count exceeds the server's
published 1000 messages limit. The client that wants to move
all messages in the range and observes a MESSAGELIMIT response
code, can repeat the command by updating the UID set parameter
specified in the command. The client needs to keep doing this
until MESSAGELIMIT response is not returned (or until a tagged
NO/BAD is returned).

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: * 11335 EXPUNGE
S: 06 OK [MESSAGELIMIT 1000 20001] MOVE completed for the last 1000 messages

The following example shows update of flags for messages with
UIDs between 18000:20000. The total message count exceeds the
server's published 1000 messages limit. The client that wants
to change flags for all messages in the range and observes a
MESSAGELIMIT response code, can repeat the command by updating
the UID set parameter specified in the command. The client
needs to keep doing this until MESSAGELIMIT response is not
returned (or until a tagged NO/BAD is returned).

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

The following example shows use of MESSAGELIMIT response code

Melnikov, et al. Expires 27 April 2023 [Page 5]
Internet-Draft IMAP MESSAGELIMIT October 2022

together with the PARTIAL [draft-ietf-extra-imap-partial]
extension. The total message count exceeds the server's
published 1000 messages limit.

C: 08 UID FETCH 22000:25000 (UID FLAGS MODSEQ) (PARTIAL -1:-1500)
S: 08 NO [MESSAGELIMIT 1000] FETCH exceeds the maximum 1000 message limit

Note that 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. The following example demonstrates that:

C: 031 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: 031 OK [EXPUNGEISSUED] Some messages were also expunged

3.3. Interaction with SORT and THREAD extensions

Servers that advertise MESSAGELIMIT N will be unable to execute a
THREAD [RFC5256] command in a mailbox with more than N messages.

Servers that advertise MESSAGELIMIT N might be unable to execute a
SORT [RFC5256] command in a mailbox with more than N messages, unless
they maintain indices for different SORT orders they support. In
absence of such indeces server implementors will need to decide
whether their server advertises SORT or MESSAGELIMIT capability.

4. 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. The use of upper or lower case characters to define
token strings is for editorial clarity only. Implementations MUST
accept these strings in a case-insensitive fashion.

Melnikov, et al. Expires 27 April 2023 [Page 6]
Internet-Draft IMAP MESSAGELIMIT October 2022

capability =/ "MESSAGELIMIT=" 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.

5. Security Considerations

This document defines an additional IMAP4 capability. As such, it
does not change the underlying security considerations of [RFC3501]
and IMAP4rev2 [RFC9051].

This document defines an optimization that can both reduce the amount
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
server and the client to use less memory than when the extension is
not used. 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 of new implementation bugs.

6. IANA Considerations

6.1. Changes/additions to the IMAP4 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/imap4-capabilities

IANA is requested to add definition of the MESSAGELIMIT extension to
point to this document.

7. Acknowledgments

This document was motivated by Yahoo! team and their questions about
best client practices for dealing with large mailboxes.

Editor of this document would like to thank the following people who
provided useful comments or participated in discussions of this
document: Timo Sirainen and Barry Leiba.

8. References

Melnikov, et al. Expires 27 April 2023 [Page 7]
Internet-Draft IMAP MESSAGELIMIT October 2022

8.1. Normative References

[ABNF] Crocker, D., Ed. and P. Overell, Ed., "Augmented BNF for
Syntax Specifications: ABNF", RFC 5234, 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>.

[RFC5161] Gulbrandsen, A., Ed. and A. Melnikov, Ed., "The IMAP
ENABLE Extension", RFC 5161, DOI 10.17487/RFC5161, March
2008, <https://www.rfc-editor.org/info/rfc5161>.

[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

[draft-ietf-extra-imap-partial]
Melnikov, A., Achuthan, A. P., Nagulakonda, V., and L.
Alves, "IMAP Paged SEARCH & FETCH Extension", Work in
Progress, Internet-Draft, draft-ietf-extra-imap-partial-
02, 12 August 2022, <https://www.ietf.org/archive/id/
draft-ietf-extra-imap-partial-02.txt>.

[RFC7162] Melnikov, A. and D. Cridland, "IMAP Extensions: Quick Flag
Changes Resynchronization (CONDSTORE) and Quick Mailbox
Resynchronization (QRESYNC)", RFC 7162,
DOI 10.17487/RFC7162, May 2014,
<https://www.rfc-editor.org/info/rfc7162>.

Melnikov, et al. Expires 27 April 2023 [Page 8]
Internet-Draft IMAP MESSAGELIMIT October 2022

Index

MESSAGELIMIT (response code)
Section 3.2, Paragraph 3.2.1

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

Melnikov, et al. Expires 27 April 2023 [Page 9]

IMAP MESSAGELIMIT Extension draft-ietf-extra-imap-messagelimit-01

IMAP MESSAGELIMIT Extension
draft-ietf-extra-imap-messagelimit-01