<?xmlversion="1.0"?>version='1.0' encoding='UTF-8'?> <!DOCTYPE rfcSYSTEM "rfc2629.dtd"[ <!ENTITYrfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>nbsp " "> <!ENTITYrfc3501 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3501.xml'>zwsp "​"> <!ENTITYrfc3502 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3502.xml'>nbhy "‑"> <!ENTITYrfc5182 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5182.xml'> <!ENTITY rfc5256 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5256.xml'> <!ENTITY rfc7162 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7162.xml'> <!ENTITY rfc8174 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml'> <!ENTITY rfc9051 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.9051.xml'> <!ENTITY rfc9394 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.9394.xml'>wj "⁠"> ]><?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?><rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="exp" ipr="pre5378Trust200902"docName="draft-ietf-extra-imap-messagelimit-10"> <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <?rfc toc="yes" ?> <?rfc symrefs="yes" ?> <?rfc sortrefs="yes"?> <?rfc iprnotified="no" ?> <?rfc strict="yes" ?> <?rfc comments="yes" ?> <?rfc inline="yes" ?> <?rfc compact="yes"?> <?rfc subcompact="no"?>docName="draft-ietf-extra-imap-messagelimit-10" number="9738" consensus="true" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3"> <front> <title abbrev="IMAPMESSAGELIMIT"> IMAPMESSAGELIMIT">IMAP MESSAGELIMITExtension </title>Extension</title> <seriesInfo name="RFC" value="9738"/> <author initials="A." surname="Melnikov" fullname="Alexey Melnikov"> <organizationabbrev="Isode"> Isode Limited </organization>abbrev="Isode">Isode Limited</organization> <address> <email>alexey.melnikov@isode.com</email> <uri>https://www.isode.com</uri> </address> </author> <author initials="A. P." surname="Achuthan" fullname="Arun Prakash Achuthan"> <organizationabbrev="Yahoo!"> Yahoo! </organization>abbrev="Yahoo!">Yahoo!</organization> <address> <email>arunprakash@myyahoo.com</email> </address> </author> <author initials="V." surname="Nagulakonda" fullname="Vikram Nagulakonda"> <organizationabbrev="Yahoo!"> Yahoo! </organization>abbrev="Yahoo!">Yahoo!</organization> <address> <email>nvikram_imap@yahoo.com</email> </address> </author> <author initials="L." surname="Alves" fullname="Luis Alves"> <address> <email>luis.alves@lafaspot.com</email> </address> </author> <dateyear="2024"/>year="2025" month="February"/> <area>ART</area> <workgroup>extra</workgroup> <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> <!--[rfced] The acknowledgments mentions the editor of this document; however, none of the authors has been listed as the editor (meaning "Ed." would appear after their name). Should one person (or more) be listed as the editor(s) of this document? (If not, this sentence will be changed to "The authors of this document".) Original: Editor of this document would like to thank the following ... --> <keyword>example</keyword> <abstract> <t> <!--[rfced] Abstract: Does the updated text convey the intended meaning? The idea is to not rely on "/" for meaning and to clarify how the first set of commands (FETCH, SEARCH, STORE, COPY, MOVE) relates to the second set (APPEND, UID EXPUNGE). Original: 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 (or their UID variants), APPEND or UID EXPUNGE command. Current: 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, or MOVE command (or their UID variants), or in a single APPEND or UID EXPUNGE command. [And similarly in the Introduction] --> 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, 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. </t> </abstract> </front> <middle> <sectiontitle="Introductionnumbered="true" toc="default"> <!-- [rfced] May the first sentences of the Abstract and Introduction be updated to simply point to RFC 9051 rather than RFC 3501, as RFC 9501 is the current version of IMAP? Because there is already an explicit statement in Section 1 that the extension is compatible with "both IMAP4rev1 [RFC3501] andOverview">IMAP4rev2 [RFC9051]", please consider whether in other instances throughout the document the reference to RFC 3501 may be updated to RFC 9051. Abstract Original: The MESSAGELIMIT extension of the Internet Message Access Protocol (RFC 3501/RFC 9051) allows ... Perhaps: The MESSAGELIMIT extension of the Internet Message Access Protocol (RFC 9051) allows ... Introduction Original: This document defines an extension to the Internet Message Access Protocol [RFC3501] for announcing ... Perhaps: This document defines an extension to the Internet Message Access Protocol [RFC9051] for announcing ... --> <name>Introduction and Overview</name> <t>This document defines an extension to the Internet Message Access Protocol <xreftarget="RFC3501"/>target="RFC3501" format="default"/> for announcing a server limit on the number of messages that can be processed in a singleFETCH/SEARCH/STORE/COPY/MOVEFETCH, 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 <xreftarget="RFC3501"/>target="RFC3501" format="default"/> and IMAP4rev2 <xreftarget="RFC9051"/>.</t>target="RFC9051" format="default"/>.</t> </section> <sectiontitle="Document Conventions">numbered="true" toc="default"> <name>Document Conventions</name> <t>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.</t> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here. </t> <t>Othercapitalisedcapitalized words are IMAP key words <xreftarget="RFC3501"/><xref target="RFC9051"/>target="RFC3501" format="default"/><xref target="RFC9051" format="default"/> or key words from this document.</t> </section> <sectiontitle="Theanchor="imap-messagelimit" numbered="true" toc="default"> <name>The MESSAGELIMITextension" anchor="imap-messagelimit">Extension</name> <t>An IMAP server advertises support for the MESSAGELIMIT extension by including"MESSAGELIMIT=<limit>""MESSAGELIMIT=<limit>" capability in the CAPABILITYresponse/responseresponse or response code, where"<limit>""<limit>" is a positive integer that conveys the maximum number of messages that can be processed in a single[UID] SEARCH/FETCH/STORE/COPY/MOVE,SEARCH, FETCH, STORE, COPY, MOVE command (or their UID variants), or in a single APPEND or UID EXPUNGE command.</t> <t>An IMAP server that only enforces the message limit on[UID] COPY/APPENDCOPY and APPEND commands (and their UID variants) would include the"SAVELIMIT=<limit>""SAVELIMIT=<limit>" capability (instead of the"MESSAGELIMIT=<limit>")"MESSAGELIMIT=<limit>") in the CAPABILITYresponse/responseresponse or response code.</t> <t>The limit advertised in the MESSAGELIMIT or SAVELIMIT capabilitySHOULD NOT<bcp14>SHOULD NOT</bcp14> be lower than 1000 messages.</t> <!--/// The server MUST NOT impose lower limit on a supporting client than on any other client. Put diffently, if code in a client worked in the past, then adding support for this extension MUST NOT break it due to lower server limit. Is the above only meaningful if ENABLE is used? --> <sectiontitle="Returninganchor="messagelimit-commands" numbered="true" toc="default"> <!--[rfced] Section 3.1: May this text be updated as follows? Should "EXPUNGE" be "UID EXPUNGE" here? Original: 3.1. Returning limits on the number of messages processed in a single SEARCH/FETCH/STORE/COPY/MOVE/APPEND/EXPUNGEcommand" anchor="messagelimit-commands">command Perhaps Option A: 3.1. Returning Limits on the Number of Messages Processed in a Single Command (SEARCH, FETCH, STORE, COPY, MOVE, APPEND, EXPUNGE) or Option B (to simplify): 3.1. Returning Limits on the Number of Messages Processed in a Single Command --> <name>Returning Limits on the Number of Messages Processed in a Single SEARCH/FETCH/STORE/COPY/MOVE/APPEND/EXPUNGE Command</name> <t> <!--Reason: don't want to break COPY atomicity guarantee from IMAP4rev1/IMAP4rev2.--> If a server implementation doesn't allow more than <N> messages to be operated on by a singleCOPY/UIDCOPY or UID COPY command, itMUST<bcp14>MUST</bcp14> fail the command by returning a tagged NO response with the MESSAGELIMIT response code defined below. No messages are copied in this case. If a server implementation doesn't allow more than <N> messages to be operated on by a singleSEARCH/FETCH/STORE/MOVESEARCH, FETCH, STORE, or MOVE command (or their UID variants), or an APPEND or UID EXPUNGE command, itMUST<bcp14>MUST</bcp14> return the MESSAGELIMIT response code defined below:<list style='hanging'> <t hangText='MESSAGELIMIT'> <iref item='MESSAGELIMIT (response code)'/> <list> <t> The</t> <dl newline="true" spacing="normal"> <dt>MESSAGELIMIT</dt> <dd> <t>The server doesn't allow more than <N> messages to be operated on by a singleSEARCH/FETCH/STORE/COPY/MOVESEARCH, 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, ifrequired. </t> <t> Therequired.</t> <t>The server 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, ifrequired. </t> <t> Noterequired.</t> <t>Note that when the MESSAGELIMIT response code is returned, the server isREQUIRED<bcp14>REQUIRED</bcp14> to process messages from highest to lowestUIDs. </t> <t> NoteUID.</t> <t>Note thatwhenthe MESSAGELIMIT response code is similar to the LIMIT(<xref target="RFC9051"/>)responsecode,code <xref target="RFC9051" format="default"/>, but it provides more details on the exact type of the limit and how to resume the command once the limit isexceeded. </t>exceeded.</t> <t>In the followingexampleexample, the <N> value is10001000, and the lowest processed UID <LastUID> is 23221.</t><t> <figure><artwork><![CDATA[<!--[rfced] FYI, line breaks have been added in order to fit the line-width restrictions of the text output. Please let us know if changes are needed. --> <artwork name="" type="" align="left" alt=""><![CDATA[ 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 partialresults ]]></artwork></figure> </t>results]]></artwork> <t>In the following example the client searches for UNDELETED UIDs between 22000:25000. The total number of searched messages (note, NOT the number of matched messages) exceeds the server's published1000 messages1000-message limit.</t><t> <figure><artwork><![CDATA[<artwork name="" type="" align="left" alt=""><![CDATA[ C: 04 UID SEARCH UID 22000:25000 UNDELETED S: * SEARCH 25000 24998 (... UIDs ...) 23221 S: 04 OK [MESSAGELIMIT 1000 23221] SEARCH completed with 1000 partialresults ]]></artwork></figure> </t>results]]></artwork> <t>The following example demonstrates the copy of messages with UIDs between 18000:21000. The total message count exceeds the server's published1000 messages1000-message limit. AsCOPY/UIDCOPY or UID COPY needs to be atomic (as per <xreftarget="RFC3501"/>/<xref target="RFC9051"/>),target="RFC3501" format="default"/>/<xref target="RFC9051" format="default"/>), no messages are copied.</t><t> <figure><artwork><![CDATA[<artwork name="" type="" align="left" alt=""><![CDATA[ C: 05 UID COPY 18000:21000 "Trash" S: 05 NO [MESSAGELIMIT 1000 20001] Too many messages to copy, try a smallersubset ]]></artwork></figure> </t>subset]]></artwork> <t>The following example showsMOVEthe move of messages with UIDs between 18000:21000. The total message count exceeds the server's published1000 messages1000-message limit. (UnlikeCOPY/UIDCOPY or UID COPY,MOVE/UIDMOVE or UID MOVE don't need to be atomic.) The client that wants to move all messages in the range and observes a MESSAGELIMIT responsecode,code can repeat the UID MOVE command with the same parameter. <!--[rfced] This document mentions the "message set parameter" twice. Will this be clear to the reader? We do not see mention of this term in RFC 9051 or other RFCs. Current: (For the MOVE command, the message set parameterneedneeds to be ... [...] (For the STORE command, the message set parameter also needs to be ... --> (For the MOVE command, the message set parameter needs to be updated before repeating the command.) The client needs to keep doing this until the MESSAGELIMIT response is not returned (or until a taggedNO/BADNO or BAD isreturned). </t> <t> <figure><artwork><![CDATA[returned).</t> <artwork name="" type="" align="left" alt=""><![CDATA[ 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 1000messages ]]></artwork></figure> </t>messages]]></artwork> <t>The following example shows the update of flags for messages with UIDs between 18000:20000. The total number of existing messages in the UID range exceeds the server's published1000 messages1000-message limit. The client that wants to change flags for all messages in the range and observes a MESSAGELIMIT responsecode,code can repeat the UID STORE command with the updated UID range that doesn't include the UID returned in the MESSAGELIMIT response code. (For the STORE command, the message set parameter alsoneedneeds to be updated before repeating the command.) The client needs to keep doing this until the MESSAGELIMIT response is not returned (or until a taggedNO/BADNO or BAD isreturned). </t> <t> <figure><artwork><![CDATA[returned).</t> <artwork name="" type="" align="left" alt=""><![CDATA[ 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 1000messages ]]></artwork></figure> </t>messages]]></artwork> <t>The following example shows the removal of messages (using UID EXPUNGE) that have the \Deleted flag set with UIDs between 11000:13000. The total message count of messages with the \Deleted flag set exceeds the server's published1000 messages1000-message limit. The client that wants to remove all messages marked as \Deleted in the range and observes a MESSAGELIMIT responsecode,code can repeat the UID EXPUNGE command with the same parameter. The client needs to keep doing this until the MESSAGELIMIT response is not returned (or until a taggedNO/BADNO or BAD isreturned). </t> <t> <figure><artwork><![CDATA[returned).</t> <artwork name="" type="" align="left" alt=""><![CDATA[ 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 1000messages ]]></artwork></figure> </t>messages]]></artwork> <t>The following example shows removal of messages (using EXPUNGE) that have the \Deleted flag set. Unlike UID EXPUNGE, the serverMUST NOT<bcp14>MUST NOT</bcp14> impose any message limit when processingEXPUNGE. </t> <t> <figure><artwork><![CDATA[EXPUNGE.</t> <artwork name="" type="" align="left" alt=""><![CDATA[ C: 09 EXPUNGE S: * 4306 EXPUNGE S: * 4305 EXPUNGE ... S: * 3307 EXPUNGE S: * 112 EXPUNGE S: 09 OK EXPUNGEcompleted ]]></artwork></figure> </t> <t> Similarly,completed]]></artwork> <t>Similarly, the serverMUST NOT<bcp14>MUST NOT</bcp14> impose any message limit when processing a "CLOSE" or a "STATUS UNSEEN"command. </t>command.</t> <t>The following example shows use of the MESSAGELIMIT response code together with the PARTIAL <xreftarget="RFC9394"/>target="RFC9394" format="default"/> extension. The total message count (as specified by the PARTIAL range) exceeds the server's published1000 messages1000-message limit, so the server refuses to do any work in this case.</t><t> <figure><artwork><![CDATA[<artwork name="" type="" align="left" alt=""><![CDATA[ C: 10 UID FETCH 22000:25000 (UID FLAGS MODSEQ) (PARTIAL -1:-1500) S: 10 NO [MESSAGELIMIT 1000] FETCH exceeds the maximum10001000- messagelimit ]]></artwork></figure> </t>limit]]></artwork> <t>Without the PARTIALparameterparameter, the above UID FETCH can look like this:</t><t> <figure><artwork><![CDATA[<artwork name="" type="" align="left" alt=""><![CDATA[ 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 maximum1000 message limit ]]></artwork></figure> </t> </list> </t> </list> </t>1000-message limit]]></artwork> </dd> </dl> <t>Note that when the server needs to return both EXPUNGEISSUED(<xref target="RFC9051"/>)<xref target="RFC9051" format="default"/> and MESSAGELIMIT response codes, the formerMUST<bcp14>MUST</bcp14> be returned in the tagged OK response, while the latterMUST<bcp14>MUST</bcp14> be returned in an untagged NO response. The following example demonstrates that: </t><t> <figure><artwork><![CDATA[<artwork name="" type="" align="left" alt=""><![CDATA[ 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 alsoexpunged ]]></artwork></figure> </t>expunged]]></artwork> <t>When the IMAP MULTIAPPEND<xref target="RFC3502"/>extension <xref target="RFC3502" format="default"/> is also supported by the server, the message limit also applies to the APPEND command. As MULTIAPPEND APPEND needs to atomic (as per <xreftarget="RFC3502"/>),target="RFC3502" format="default"/>), no messages are appended when the server MESSAGELIMIT is exceeded.</t> </section> <sectiontitle="UIDAFTERanchor="search-criteria" numbered="true" toc="default"> <name>UIDAFTER and UIDBEFORE SEARCHcriteria" anchor="search-criteria"> <t> TheCriteria</name> <t>The MESSAGELIMIT extension also defines2two extra SEARCHkeys:keys, UIDAFTER and UIDBEFORE, which make it easier to convert a single UID to a range ofUIDs. </t> <t> "UIDAFTER <uid>" - MessagesUIDs.</t> <dl spacing="normal" newline="false"> <dt>"UIDAFTER <uid>"</dt> <dd>Messages that have a UID greater than the specified UID. This is semantically the same as "UID<uid>+1:*". </t> <t> "UIDBEFORE <uid>" - Messages<uid>+1:*".</dd> <dt>"UIDBEFORE <uid>"</dt> <dd>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 emptyset). </t>set).</dd> </dl> <t> These2two SEARCH keys are particularly useful when the SEARCHRES<xref target="RFC5182"/>extension <xref target="RFC5182" format="default"/> is also supported, but they can be used without 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 SEARCH requests can be pipelined. </t><t> <figure><artwork><![CDATA[<artwork name="" type="" align="left" alt=""><![CDATA[ C: 12 UID SEARCH UIDAFTER 25000 UNDELETED S: * SEARCH 27800 27798 (... 250 UIDs ...) 25001 S: 12 OK SEARCHcompleted ]]></artwork></figure> </t>completed]]></artwork> </section> <sectiontitle="Interactionnumbered="true" toc="default"> <name>Interaction with SORT and THREADextensions">Extensions</name> <t> Servers that advertise MESSAGELIMIT N will be unable to execute a THREAD<xref target="RFC5256"/>command <xref target="RFC5256" format="default"/> in a mailbox with more than N messages. </t> <t> Servers that advertise MESSAGELIMIT N might be unable to execute a SORT<xref target="RFC5256"/>command <xref target="RFC5256" format="default"/> in a mailbox with more than N messages, unless they maintain indices for different SORT orders they support. In absence of suchindecesindices, server implementors will need to decide whether their server advertises SORT or MESSAGELIMIT capability. </t> </section> <sectiontitle="Interactionnumbered="true" toc="default"> <name>Interaction with SEARCHRESextensionExtension andIMAP4rev2">IMAP4rev2</name> <t> Servers that support both MESSAGELIMIT and SEARCHRES<xref target="RFC5182"/>extensionsMUST<xref target="RFC5182" format="default"/> <bcp14>MUST</bcp14> truncate SEARCH SAVE result stored in the $ variable when the SEARCH command succeeds, but the MESSAGELIMIT response code is returned. For example, if the following SEARCH would have returned 1200 results in absence of MESSAGELIMIT, and the MESSAGELIMIT is 1000, only 1000 matching results will be saved in the $ variable: </t><t> <figure><artwork><![CDATA[<artwork name="" type="" align="left" alt=""><![CDATA[ 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 resultssaved ]]></artwork></figure> </t>saved]]></artwork> </section> </section> <sectiontitle="Interoperability Considerations">numbered="true" toc="default"> <name>Interoperability Considerations</name> <sectiontitle="Effectsnumbered="true" toc="default"> <name>Effects ofMESSAGELIMIT/SAVELIMIT extensionsMESSAGELIMIT and SAVELIMIT Extensions onnon compliant clients"> <t> ANoncompliant Clients</name> <t>A server that advertises the MESSAGELIMIT=N capability would have the following effect on clients that don't support thiscapability: <list>capability:</t> <!--[rfced] The first item uses notation; the second uses words. May this be updated as follows for consistency? Original: Operations on a mailbox that has <= N messages are not affected. In a mailbox with more than N messages: Suggested: * Operations are not affected on a mailbox that has N messages or fewer. * In a mailbox with more than N messages: Or (if you prefer notation): * Operations on a mailbox that has <= N messages are not affected. * In a mailbox with > N messages: --> <ul spacing="normal"> <li> <t>Operations on a mailbox that has <= N messages are not affected.</t> </li> <li> <t>In a mailbox with more than Nmessages: <list>messages:</t> <ul spacing="normal"> <li> <t>An attempt toCOPY/UIDCOPY or UID COPY more than N messages will always fail.</t> </li> <li> <t>EXPUNGE and CLOSE will always operate on the full mailbox, so they are not affected.</t> </li> <li> <t>Other commands like FETCH,SEARCHSEARCH, and MOVE will be effectively restricted to the last N messages of the mailbox. Inparticularparticular, unextended SEARCHesintended(intended for counting of messages with or without a particular set offlagsflags) would return incorrect counts.</t></list> </t> </list> </t></li> </ul> </li> </ul> </section> <sectiontitle="Maintaining Compatibility">numbered="true" toc="default"> <name>Maintaining Compatibility</name> <t> It is important to understand that the above effects essentially abandon existing clients with respect to operation on large mailboxes. Suppose, for example, that a user is accessing a large and active mailing list viaIMAP -IMAP, and the mailing list gets on the order of 1500 posts per week. When the user returns from a week-long vacation and catches up on the mailing list, theuser’suser's client will be fetching information about 1500 messages. If the server has a MESSAGELIMIT of 1000, the client will only be able to download 1000 of the most recent messages; the client will not understand why, will not be prepared to recover from the situation, and will act as if it is interacting with a broken server. </t> <t> In order to give clients time to implement this extension, servers should not be strict about applying the MESSAGELIMIT at first. One possible approach is to advertise a MESSAGELIMIT but not enforce it at all for a while. Clients that understand this extension will comply, reducing load on the server, but clients that do not understand the limit will continue to work in all situations. </t> <t> Another approach, which perhaps could be phased in later, is to advertise one limit but to treat it as a soft limit and to begin enforcement at a higher, unadvertised hard limit. In the above example, perhaps the server might advertise 1000 but actually enforce a limit of 10,000. Again, clients that understand MESSAGELIMIT will comply with the limit of 1000, but other clients will still interoperate up to the higher threshold. </t> <t> Attempts to go beyond the advertised limit can be logged so that client understanding of MESSAGELIMIT can be tracked. If implementation and deployment of this extension becomes common, it may at some point be acceptable to strictly enforce the advertised limit and to accept that the remaining clients will, indeed, no longer work properly with mailboxes above that limit. </t> </section> </section> <sectiontitle="Formal syntax">numbered="true" toc="default"> <name>Formal Syntax</name> <t>The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in <xreftarget="ABNF"/>.</t>target="RFC5234" format="default"/>.</t> <t>Non-terminals referenced but not defined below are as defined by <xreftarget="RFC3501">IMAP4</xref>.</t>target="RFC3501" format="default">IMAP4</xref>.</t> <t>Except as noted otherwise, all alphabetic characters are case-insensitive. The use ofupperuppercase orlower caselowercase characters to define token strings is for editorial clarity only. ImplementationsMUST<bcp14>MUST</bcp14> accept these strings in a case-insensitive fashion.</t><figure><artwork><![CDATA[<sourcecode type="abnf"><![CDATA[ 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 isomitted,omitted when notknown. ]]></artwork></figure>known.]]></sourcecode> </section> <sectiontitle="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t> This document defines an additional IMAP4 capability. As such, it does not change the underlying security considerations of IMAP4rev1 <xreftarget="RFC3501"/> andtarget="RFC3501" format="default"/> or IMAP4rev2 <xreftarget="RFC9051"/>.target="RFC9051" format="default"/>. </t> <t> 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, which can in turn help to protect fromDenial-of-Servicedenial-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 introducingofnew implementation bugs. </t> <!--///Also misleading message counts? Or an attempt to calculate how much will be freed if \Deleted messages are EXPUNGEd from the mailbox?--> </section> <sectiontitle="IANA Considerations">numbered="true" toc="default"> <name>IANA Considerations</name> <sectiontitle="Changes/additionsnumbered="true" toc="default"> <name>Additions to theIMAP4 capabilities registry"> <t> IMAP4IMAP Capabilities Registry</name> <t>IMAP4 capabilities are registered by publishing astandards trackStandards Track orIESG approvedIESG-approved Informational or Experimental RFC. The "IMAP Capabilities" registry is currently located at:</t> <figure><artwork><![CDATA[ https://www.iana.org/assignments/imap-capabilities/ ]]></artwork></figure> <t> IANA is requested to add registrations of<eref target="https://www.iana.org/assignments/imap-capabilities/" brackets="angle"/>.</t> <t>IANA has added "MESSAGELIMIT=" and "SAVELIMIT=" capabilities to this registry,both pointing towith thisdocument. </t>document as the reference.</t> </section> </section> </middle> <back> <displayreference target="RFC5234" to="ABNF"/> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3501.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3502.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5182.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5256.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9051.xml"/> </references> <references> <name>Informative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9394.xml"/> </references> </references> <sectiontitle="Acknowledgments">numbered="false" toc="default"> <name>Acknowledgments</name> <t>This document was motivated by the Yahoo! team and their questions about best client practices for dealing with large mailboxes.</t><t> Editor<t>The editor of this document would like to thank the following people who provided useful comments, contributedtexttext, or participated in discussions of this document:Timo Sirainen, Barry Leiba, Ken Murchison and Arnt Gulbrandsen.<contact fullname="Timo Sirainen"/>, <contact fullname="Barry Leiba"/>, <contact fullname="Ken Murchison"/>, and <contact fullname="Arnt Gulbrandsen"/>. </t> </section></middle> <back> <references title="Normative References"> &rfc2119; &rfc8174; &rfc3501; &rfc3502; &rfc5182; &rfc5256; <reference anchor="ABNF"> <front> <title>Augmented BNF for Syntax Specifications: ABNF</title> <author initials="D" surname="Crocker" fullname="Dave Crocker" role="editor"> <organization /> </author> <author initials="P" surname="Overell" fullname="Paul Overell" role="editor"> <organization /> </author> <date year="2008" month="January"/> </front> <seriesInfo name="RFC" value="5234" /> <format type="TXT" target="https://www.rfc-editor.org/info/rfc5234" /> </reference> &rfc9051; </references> <references title="Informative References"> &rfc9394; </references></back> <!-- [rfced] Please review each artwork element and let us know if any should be marked as sourcecode (or another element) instead. FYI, we updated artwork to sourcecode type="abnf" in Section 5. Please confirm that this is accurate. The current list of preferred values for "type" is available at <https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>. If the current list does not contain an applicable type, feel free to suggest additions for consideration. Note that it is also acceptable to leave the "type" attribute not set. --> <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> <!--[rfced] FYI, we have removed the index from this document, as an index with a single entry does not seem useful. --> </rfc>