rfc9738xml2.original.xml		rfc9738.xml
	<?xml version="1.0"?>		<?xml version='1.0' encoding='UTF-8'?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
	<!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/referenc
	e.RFC.2119.xml'>
	<!ENTITY rfc3501 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/referenc
	e.RFC.3501.xml'>
	<!ENTITY rfc3502 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/referenc
	e.RFC.3502.xml'>
	<!ENTITY rfc5182 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/referenc
	e.RFC.5182.xml'>
	<!ENTITY rfc5256 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/referenc
	e.RFC.5256.xml'>
	<!ENTITY rfc7162 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/referenc
	e.RFC.7162.xml'>
	<!ENTITY rfc8174 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/referenc
	e.RFC.8174.xml'>
	<!ENTITY rfc9051 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/referenc
	e.RFC.9051.xml'>
	<!ENTITY rfc9394 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/referenc
	e.RFC.9394.xml'>
			<!DOCTYPE rfc [
			<!ENTITY nbsp "&#160;">
			<!ENTITY zwsp "&#8203;">
			<!ENTITY nbhy "&#8209;">
			<!ENTITY wj "&#8288;">
	]>		]>
	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
	<rfc category="exp" ipr="pre5378Trust200902" docName="draft-ietf-extra-imap-mess
	agelimit-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"?>
	<front>
	<title abbrev="IMAP MESSAGELIMIT">
	IMAP MESSAGELIMIT Extension
	</title>
	<author initials="A." surname="Melnikov" fullname="Alexey Melniko
	v">
	<organization abbrev="Isode">
	Isode Limited
	</organization>
	<address>
	<email>alexey.melnikov@isode.com</email>
	<uri>https://www.isode.com</uri>
	</address>
	</author>
			<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="exp" ipr="pre5378Trust
			200902" docName="draft-ietf-extra-imap-messagelimit-10" number="9738" consensus=
			"true" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="t
			rue" symRefs="true" sortRefs="true" version="3">
			<front>
			<title abbrev="IMAP MESSAGELIMIT">IMAP MESSAGELIMIT Extension</title>
			<seriesInfo name="RFC" value="9738"/>
			<author initials="A." surname="Melnikov" fullname="Alexey Melnikov">
			<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" >		<author initials="A. P." surname="Achuthan" fullname="Arun Prakash Achuthan" >
	<organization abbrev="Yahoo!">		<organization abbrev="Yahoo!">Yahoo!</organization>
	Yahoo!
	</organization>
	<address>		<address>
	<email>arunprakash@myyahoo.com</email>		<email>arunprakash@myyahoo.com</email>
	</address>		</address>
	</author>		</author>
	<author initials="V." surname="Nagulakonda" fullname="Vikram Nagulakonda">		<author initials="V." surname="Nagulakonda" fullname="Vikram Nagulakonda">
	<organization abbrev="Yahoo!">		<organization abbrev="Yahoo!">Yahoo!</organization>
	Yahoo!
	</organization>
	<address>		<address>
	<email>nvikram_imap@yahoo.com</email>		<email>nvikram_imap@yahoo.com</email>
	</address>		</address>
	</author>		</author>
	<author initials="L." surname="Alves" fullname="Luis Alves">		<author initials="L." surname="Alves" fullname="Luis Alves">
	<address>		<address>
	<email>luis.alves@lafaspot.com</email>		<email>luis.alves@lafaspot.com</email>
	</address>		</address>
	</author>		</author>
			<date year="2025" month="February"/>
			<area>ART</area>
			<workgroup>extra</workgroup>
	<date year="2024"/>		<abstract>
	<abstract>		<t>
	<t>
	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.
	This helps servers to control resource usage when performing various IMA
	P operations.
	This helps clients to know the message limit enforced by corresponding I
	MAP server
	and avoid issuing commands that would exceed such limit.
	</t>
			The MESSAGELIMIT extension of the Internet Message Access Protocol
			(RFCs 3501 and 9051) allows servers to announce a limit on the number
			of messages that can be processed in a single FETCH, SEARCH, STORE,
			COPY, or MOVE command (or their UID variants), or in a single APPEND
			or UID EXPUNGE command. This helps servers to control resource usage
			when performing various IMAP operations. This helps clients to know
			the message limit enforced by the corresponding IMAP server and avoid
			issuing commands that would exceed such limit.
			</t>
	</abstract>		</abstract>
	</front>		</front>
	<middle>		<middle>
			<section numbered="true" toc="default">
	<section title="Introduction and Overview">		<name>Introduction and Overview</name>
			<t>This document defines an extension to the Internet Message Access Proto
	<t>This document defines an extension to the Internet Message Access Proto		col <xref target="RFC9051" format="default"/>
	col <xref target="RFC3501"/>
	for announcing a server limit on the number of		for announcing a server limit on the number of
	messages that can be processed in a single FETCH/SEARCH/STORE/COPY/MOVE (o		messages that can be processed in a single FETCH, SEARCH, STORE, COPY, or
	r their UID variants), APPEND or UID EXPUNGE command.		MOVE command (or their UID variants), or a single APPEND or UID EXPUNGE command.
	This extension is compatible with both IMAP4rev1 <xref target="RFC3501"/>		This extension is compatible with both IMAP4rev1 <xref target="RFC3501" fo
	and IMAP4rev2 <xref target="RFC9051"/>.</t>		rmat="default"/> and IMAP4rev2 <xref target="RFC9051" format="default"/>.</t>
			</section>
	</section>		<section numbered="true" toc="default">
			<name>Document Conventions</name>
	<section title="Document Conventions">		<t>In protocol examples, this document uses a prefix of "C: " to denote
	<t>In protocol examples, this document uses a prefix of "		lines sent by the client to the server, and "S: " for lines sent by the
	C: " to denote lines sent by the client to the server, and		server to the client. Lines prefixed with "// " are comments explaining
	"S: " for lines sent by the server to the client. Lines p		the previous protocol line. These prefixes and comments are not part of
	refixed with "// " are comments explaining the previous protocol line.		the protocol. Lines without any of these prefixes are continuations of
	These prefixes and comments are not part of the protocol.		the previous line, and no line break is present in the protocol unless
	Lines without any of these prefixes are continuations of the previous line,		specifically mentioned.</t>
	and no line break is present in the protocol unless speci		<t>
	fically mentioned.</t>		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
			"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
	<t>		",
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	"OPTIONAL" in this document are to be interpreted as described in BC		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	P		be
	14 <xref target="RFC2119"/> <xref target="RFC8174"/>		interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
	when, and only when, they appear in all capitals, as shown here.		target="RFC8174"/> when, and only when, they appear in all capitals, as
	</t>		shown here.
			</t>
	<t>Other capitalised words are IMAP key words <xref target="RFC3501"		<t>Other capitalized words are IMAP key words <xref target="RFC3501" forma
	/><xref target="RFC9051"/>		t="default"/><xref target="RFC9051" format="default"/>
	or key words from this document.</t>		or key words from this document.</t>
			</section>
			<section anchor="imap-messagelimit" numbered="true" toc="default">
			<name>The MESSAGELIMIT Extension</name>
			<t>An IMAP server advertises support for the MESSAGELIMIT extension
			by including "MESSAGELIMIT=&lt;limit&gt;" capability in the CAPABILITY r
			esponse or response code,
			where "&lt;limit&gt;" is a positive integer that conveys the maximum num
			ber of messages
			that can be processed in a single SEARCH, FETCH, STORE, COPY, MOVE comma
			nd (or their UID variants), or in a single APPEND or UID EXPUNGE command.</t>
	</section>		<t>An IMAP server that only enforces the message limit on COPY and APPEND
			commands (and their UID variants) would include
	<section title="The MESSAGELIMIT extension" anchor="imap-messagelimit">		the "SAVELIMIT=&lt;limit&gt;" capability (instead of the "MESSAGELIMIT=&
			lt;limit&gt;") in
	<t>An IMAP server advertises support for the MESSAGELIMIT extension		the CAPABILITY response or response code.</t>
	by including "MESSAGELIMIT=&lt;limit>" capability in the CAPABILITY resp		<t>The limit advertised in the MESSAGELIMIT or SAVELIMIT capability <bcp14
	onse/response code,		>SHOULD NOT</bcp14> be lower than 1000 messages.</t>
	where "&lt;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, AP
	PEND or UID EXPUNGE command.</t>
	<t>An IMAP server that only enforces message limit on [UID] COPY/APPEND
	commands would include
	the "SAVELIMIT=&lt;limit>" capability (instead of the "MESSAGELIMIT=&lt;
	limit>") in
	the CAPABILITY response/response code.</t>
	<t>The limit advertised in the MESSAGELIMIT or SAVELIMIT capability SHOU
	LD NOT be lower than 1000 messages.</t>
	<!--///
	The server MUST NOT impose lower limit on a supporting client than o n any other client.		The server MUST NOT impose lower limit on a supporting client than o n any other client.
	Put diffently, if code in a client worked in the past, then adding s upport for this extension		Put diffently, if code in a client worked in the past, then adding s upport for this extension
	MUST NOT break it due to lower server limit.		MUST NOT break it due to lower server limit.
	Is the above only meaningful if ENABLE is used?		Is the above only meaningful if ENABLE is used?
	-->		-->
	<section title="Returning limits on the number of messages processed in a sin		<section anchor="messagelimit-commands" numbered="true" toc="default">
	gle SEARCH/FETCH/STORE/COPY/MOVE/APPEND/EXPUNGE command" anchor="messagelimit-co		<name>Returning Limits on the Number of Messages Processed in a Single Comm
	mmands">		and</name>
			<t>
	<t>
	<!--Reason: don't want to break COPY atomicity guarantee from IMAP4rev1/IM AP4rev2.-->		<!--Reason: don't want to break COPY atomicity guarantee from IMAP4rev1/IM AP4rev2.-->
	If a server implementation doesn't allow more than &lt;N&gt; messages to b e operated on		If a server implementation doesn't allow more than &lt;N&gt; messages to b e operated on
	by a single COPY/UID COPY command, it MUST fail the command by returning a tagged NO response		by a single COPY or UID COPY command, it <bcp14>MUST</bcp14> fail the comm and by returning a tagged NO response
	with the MESSAGELIMIT response code defined below. No messages are copied in this case.		with the MESSAGELIMIT response code defined below. No messages are copied in this case.
	If a server implementation doesn't allow more than &lt;N&gt; messages to b e operated on		If a server implementation doesn't allow more than &lt;N&gt; messages to b e operated on
	by a single SEARCH/FETCH/STORE/MOVE (or their UID variants), APPEND or UID		by a single SEARCH, FETCH, STORE, or MOVE command (or their UID variants),
	EXPUNGE command, it MUST return the MESSAGELIMIT response code defined below:		or an APPEND or UID EXPUNGE command, it <bcp14>MUST</bcp14> return the MESSAGEL
			IMIT response code defined below:
	<list style='hanging'>
	<t hangText='MESSAGELIMIT'>
	<iref item='MESSAGELIMIT (response code)'/>
	<list>
	<t>
	The server doesn't allow more than &lt;N&gt; messages to be operated o
	n
	by a single SEARCH/FETCH/STORE/COPY/MOVE command (or their UID variant
	s).
	The lowest processed UID is &lt;LastUID&gt;.
	The client needs to repeat the operation for remaining messages, if re
	quired.
	</t>
	<t>
	The server doesn't allow more than &lt;N&gt; \Deleted messages to be o
	perated on
	by a single UID EXPUNGE command.
	The lowest processed UID is &lt;LastUID&gt;.
	The client needs to repeat the operation for remaining messages, if re
	quired.
	</t>
	<t>
	Note that when the MESSAGELIMIT response code is returned,
	the server is REQUIRED to process messages from highest to lowest UIDs
	.
	</t>
	<t>
	Note that when the MESSAGELIMIT response code is similar to the LIMIT
	(<xref target="RFC9051"/>) response code,
	but it provides more details on the exact type of the limit and how to
	resume the command
	once the limit is exceeded.
	</t>
	<t>In the following example the &lt;N&gt; value is 1000 and the lowest
	processed UID &lt;LastUID&gt; is 23221.</t>
	<t>		</t>
	<figure><artwork><![CDATA[		<dl newline="true" spacing="normal">
			<dt>MESSAGELIMIT</dt>
			<dd>
			<t>The server doesn't allow more than &lt;N&gt; messages to be
			operated on by a single SEARCH, FETCH, STORE, COPY, or MOVE command
			(or
			their UID variants). The lowest processed UID is &lt;LastUID&gt;.
			The client needs to repeat the operation for remaining messages,
			if required.</t>
			<t>The server doesn't allow more than &lt;N&gt; \Deleted messages
			to be operated on by a single UID EXPUNGE command. The lowest
			processed UID is &lt;LastUID&gt;. The client needs to repeat the
			operation for remaining messages, if required.</t>
			<t>Note that when the MESSAGELIMIT response code is returned, the
			server is <bcp14>REQUIRED</bcp14> to process messages from highest
			to lowest UID.</t>
			<t>Note that the MESSAGELIMIT response code is similar to the
			LIMIT response 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 is exceeded.</t> <t>In
			the following example, the &lt;N&gt; value is 1000, and the lowest
			processed UID &lt;LastUID&gt; is 23221.</t>
			<!--[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)		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]]></artwork>
	]]></artwork></figure>		<t>In the following example the client searches for UNDELETED UIDs
	</t>		between 22000:25000. The total number of searched messages (note,
			NOT the number of matched messages) exceeds the server's published
	<t>In the following example the client searches for UNDELETED UIDs bet		1000-message limit.</t>
	ween 22000:25000.
	The total number of searched messages (note, NOT the number of matched
	messages) exceeds the server's published 1000 messages limit.</t>
	<t>		<artwork name="" type="" align="left" alt=""><![CDATA[
	<figure><artwork><![CDATA[
	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
	]]></artwork></figure>		partial results]]></artwork>
	</t>
	<t>The following example demonstrates copy of messages with UIDs betwe		<t>The following example demonstrates the copy of messages with UIDs
	en 18000:21000.		between 18000:21000. The total message count exceeds the server's
	The total message count exceeds the server's published 1000 messages l		published 1000-message limit. As COPY or UID COPY needs to be atomi
	imit.		c
	As COPY/UID COPY needs to atomic (as per <xref target="RFC3501"/>/<xre		(as per <xref target="RFC3501" format="default"/>/<xref
	f target="RFC9051"/>),		target="RFC9051" format="default"/>), no messages are copied.</t>
	no messages are copied.</t>
	<t>		<artwork name="" type="" align="left" alt=""><![CDATA[
	<figure><artwork><![CDATA[
	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 su		S: 05 NO [MESSAGELIMIT 1000 20001] Too many messages to copy,
	bset		try a smaller subset]]></artwork>
	]]></artwork></figure>
	</t>
	<t>The following example shows MOVE of messages with UIDs between 1800		<t>The following example shows the move of messages with UIDs betwee
	0:21000.		n
	The total message count exceeds the server's published 1000 messages l		18000:21000. The total message count exceeds the server's
	imit.		published 1000-message limit. (Unlike COPY or UID COPY, MOVE or UID
	(Unlike COPY/UID COPY, MOVE/UID MOVE don't need to be atomic.)		MOVE don't need to be atomic.) The client that wants to move all
	The client that wants to move all messages in the range and observes a		messages in the range and observes a MESSAGELIMIT response code
	MESSAGELIMIT response code,		can repeat the UID MOVE command with the same parameter.
	can repeat the UID MOVE command with the same parameter. (For the MOVE		<!--[rfced] This document mentions the "message set parameter" twice.
	command, the message set parameter need to be updated before repeating the comm		Will this be clear to the reader? We do not see mention of this term
	and.)		in RFC 9051 or other RFCs.
	The client needs to keep doing this until the MESSAGELIMIT response is
	not returned (or until a tagged NO/BAD is returned).
	</t>
	<t>		Current:
	<figure><artwork><![CDATA[		(For the MOVE command, the message set parameter needs 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 tagged
			NO or BAD is returned).</t>
			<artwork name="" type="" align="left" alt=""><![CDATA[
	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 mo		S: * OK [COPYUID 1397597919 20001:21000 22363:23362] Some
	ved		messages were not moved
	S: * 12336 EXPUNGE		S: * 12336 EXPUNGE
	S: * 12335 EXPUNGE		S: * 12335 EXPUNGE
	...		...
	S: * 11337 EXPUNGE		S: * 11337 EXPUNGE
	S: 06 OK [MESSAGELIMIT 1000 20001] MOVE completed for the last 1000 messages		S: 06 OK [MESSAGELIMIT 1000 20001] MOVE completed for the last
	]]></artwork></figure>		1000 messages]]></artwork>
	</t>
	<t>The following example shows update of flags for messages with UIDs		<t>The following example shows the update of flags for messages with
	between 18000:20000. The total number of existing messages in the UID range exce		UIDs between 18000:20000. The total number of existing messages in
	eds the server's published 1000 messages limit.		the UID range exceeds the server's published 1000-message limit.
	The client that wants to change flags for all messages in the range an		The client that wants to change flags for all messages in the
	d observes a MESSAGELIMIT response code,		range and observes a MESSAGELIMIT response code can repeat the
	can repeat the UID STORE command with the updated UID range that doesn		UID STORE command with the updated UID range that doesn't include
	't include the UID returned in the MESSAGELIMIT response code. (For the STORE co		the UID returned in the MESSAGELIMIT response code. (For the STORE
	mmand, the message set parameter also need to be updated before repeating the co		command, the message set parameter also needs to be updated before
	mmand.)		repeating the command.) The client needs to keep doing this until
	The client needs to keep doing this until the MESSAGELIMIT response is		the MESSAGELIMIT response is not returned (or until a tagged
	not returned (or until a tagged NO/BAD is returned).		NO or BAD is returned).</t>
	</t>
	<t>		<artwork name="" type="" align="left" alt=""><![CDATA[
	<figure><artwork><![CDATA[
	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
	]]></artwork></figure>		1000 messages]]></artwork>
	</t>
	<t>The following example shows removal of messages (using UID EXPUNGE)		<t>The following example shows the removal of messages (using UID
	that have \Deleted flag set with UIDs between 11000:13000.		EXPUNGE) that have the \Deleted flag set with UIDs between
	The total message count of messages with \Deleted flag set exceeds the		11000:13000. The total message count of messages with the \Deleted
	server's published 1000 messages limit.		flag set exceeds the server's published 1000-message limit. The
	The client that wants to remove all messages marked as \Deleted in the		client that wants to remove all messages marked as \Deleted in the
	range and observes a MESSAGELIMIT response code,		range and observes a MESSAGELIMIT response code can repeat the
	can repeat the UID EXPUNGE command with the same parameter.		UID EXPUNGE command with the same parameter. The client needs to
	The client needs to keep doing this until the MESSAGELIMIT response is		keep doing this until the MESSAGELIMIT response is not returned
	not returned (or until a tagged NO/BAD is returned).		(or until a tagged NO or BAD is returned).</t>
	</t>
	<t>		<artwork name="" type="" align="left" alt=""><![CDATA[
	<figure><artwork><![CDATA[
	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 mes		S: 08 OK [MESSAGELIMIT 1000 11627] UID EXPUNGE completed for
	sages		the last 1000 messages]]></artwork>
	]]></artwork></figure>
	</t>
	<t>The following example shows removal of messages (using EXPUNGE) tha		<t>The following example shows removal of messages (using EXPUNGE)
	t have \Deleted flag set.		that have the \Deleted flag set. Unlike UID EXPUNGE, the server
	Unlike UID EXPUNGE, the server MUST NOT impose any message limit when		<bcp14>MUST NOT</bcp14> impose any message limit when processing
	processing EXPUNGE.		EXPUNGE.</t>
	</t>
	<t>		<artwork name="" type="" align="left" alt=""><![CDATA[
	<figure><artwork><![CDATA[
	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]]></artwork>
	]]></artwork></figure>
	</t>
	<t>
	Similarly, the server MUST NOT impose any message limit when processin
	g a "CLOSE" or a "STATUS UNSEEN" command.
	</t>
	<t>The following example shows use of MESSAGELIMIT response code toget		<t>Similarly, the server <bcp14>MUST NOT</bcp14> impose any
	her with the PARTIAL <xref target="RFC9394"/> extension.		message limit when processing a "CLOSE" or a "STATUS UNSEEN"
	The total message count (as specified by the PARTIAL range) exceeds th		command.</t>
	e server's published 1000 messages limit,		<t>The following example shows use of the MESSAGELIMIT response code
	so the server refuses to do any work in this case.</t>		together with the PARTIAL <xref target="RFC9394"
			format="default"/> extension. The total message count (as
			specified by the PARTIAL range) exceeds the server's published
			1000-message limit, so the server refuses to do any work in this
			case.</t>
	<t>		<artwork name="" type="" align="left" alt=""><![CDATA[
	<figure><artwork><![CDATA[		C: 10 UID FETCH 22000:25000 (UID FLAGS MODSEQ)
	C: 10 UID FETCH 22000:25000 (UID FLAGS MODSEQ) (PARTIAL -1:-1500)		(PARTIAL -1:-1500)
	S: 10 NO [MESSAGELIMIT 1000] FETCH exceeds the maximum 1000 message limit		S: 10 NO [MESSAGELIMIT 1000] FETCH exceeds the maximum 1000-
	]]></artwork></figure>		message limit]]></artwork>
	</t>
	<t>Without the PARTIAL parameter the above UID FETCH can look		<t>Without the PARTIAL parameter, the above UID FETCH can look like
	like this:</t>		this:</t>
	<t>		<artwork name="" type="" align="left" alt=""><![CDATA[
	<figure><artwork><![CDATA[
	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 limi		S: 10 OK [MESSAGELIMIT 1000 23007] FETCH exceeds the maximum
	t		1000-message limit]]></artwork>
	]]></artwork></figure>		</dd>
	</t>		</dl>
	</list>
	</t>
	</list>
	</t>
	<t>Note that when the server needs to return both EXPUNGEISSUED (<xref tar
	get="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 followin
	g example demonstrates
	that:
	</t>
	<t>		<t>Note that when the server needs to return both EXPUNGEISSUED
	<figure><artwork><![CDATA[		<xref target="RFC9051" format="default"/> and MESSAGELIMIT
			response codes, the former <bcp14>MUST</bcp14> be returned in the
			tagged OK response, while the latter <bcp14>MUST</bcp14> be
			returned in an untagged NO response. The following example
			demonstrates that:
			</t>
			<artwork name="" type="" align="left" alt=""><![CDATA[
	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]]></artwork>
	]]></artwork></figure>		<t>When the IMAP MULTIAPPEND extension <xref target="RFC3502" format="de
	</t>		fault"/> is also supported by the server,
			the message limit also applies to the APPEND command. As MULTIAPPEND APPEN
	<t>When IMAP MULTIAPPEND <xref target="RFC3502"/> extension is also suppor		D needs to atomic (as per <xref target="RFC3502" format="default"/>),
	ted by the server,
	the message limit also applies to the APPEND command. As MULTIAPPEND APPEN
	D needs to atomic (as per <xref target="RFC3502"/>),
	no messages are appended when the server MESSAGELIMIT is exceeded.</t>		no messages are appended when the server MESSAGELIMIT is exceeded.</t>
			</section>
	</section>		<section anchor="search-criteria" numbered="true" toc="default">
			<name>UIDAFTER and UIDBEFORE SEARCH Criteria</name>
	<section title="UIDAFTER and UIDBEFORE SEARCH criteria" anchor="search-crite		<t>The MESSAGELIMIT extension also defines two extra SEARCH keys,
	ria">		UIDAFTER and UIDBEFORE, which make it easier to convert a single UID
			to a range of UIDs.</t>
	<t>		<dl spacing="normal" newline="false">
	The MESSAGELIMIT extension also defines 2 extra SEARCH keys: UIDAFTER an		<dt>"UIDAFTER &lt;uid&gt;"</dt> <dd>Messages that have a UID greater
	d UIDBEFORE,		than the specified UID. This is semantically the same as "UID
	which make it easier to convert a single UID to a range of UIDs.		&lt;uid&gt;+1:*".</dd>
	</t>		<dt>"UIDBEFORE &lt;uid&gt;"</dt> <dd>Messages that have a UID less
			than the specified UID. This is semantically the same as "UID
	<t>		1:&lt;uid&gt;-1" (or if &lt;uid&gt; has the value 1, then the empty
	"UIDAFTER &lt;uid&gt;" - Messages that have a UID greater than the speci		set).</dd>
	fied UID.		</dl>
	This is semantically the same as "UID &lt;uid&gt;+1:*".		<t>
	</t>		These two SEARCH keys are particularly useful when the SEARCHRES extensi
			on <xref target="RFC5182" format="default"/>
	<t>
	"UIDBEFORE &lt;uid&gt;" - Messages that have a UID less than the specifi
	ed UID.
	This is semantically the same as "UID 1:&lt;uid&gt;-1" (or if &lt;uid&gt
	; has the value 1, then the empty set).
	</t>
	<t>
	These 2 SEARCH keys are particularly useful when the SEARCHRES <xref tar
	get="RFC5182"/> extension
	is also supported, but they can be used without it. For example, this al lows a SEARCH that		is also supported, but they can be used without it. For example, this al lows a SEARCH that
	sets the "$" marker to be converted to a range of messages in a subseque nt SEARCH, and both SEARCH requests		sets the "$" marker to be converted to a range of messages in a subseque nt SEARCH, and both SEARCH requests
	can be pipelined.		can be pipelined.
	</t>		</t>
			<artwork name="" type="" align="left" alt=""><![CDATA[
	<t>
	<figure><artwork><![CDATA[
	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]]></artwork>
	]]></artwork></figure>		</section>
	</t>		<section numbered="true" toc="default">
			<name>Interaction with SORT and THREAD Extensions</name>
	</section>		<t>
			Servers that advertise MESSAGELIMIT N will be unable to execute a THREAD c
	<section title="Interaction with SORT and THREAD extensions">		ommand <xref target="RFC5256" format="default"/> in a mailbox with more than N m
			essages.
	<t>		</t>
	Servers that advertise MESSAGELIMIT N will be unable to execute a THREAD <		<t>
	xref target="RFC5256"/> command in a mailbox with more than N messages.		Servers that advertise MESSAGELIMIT N might be unable to execute a SORT co
	</t>		mmand <xref target="RFC5256" format="default"/> in a mailbox with more than N me
			ssages,
	<t>		unless they maintain indices for different SORT orders they support. In ab
	Servers that advertise MESSAGELIMIT N might be unable to execute a SORT <x		sence of such indices, server implementors will need to decide whether
	ref target="RFC5256"/> command in a mailbox with more than N messages,
	unless they maintain indices for different SORT orders they support. In ab
	sence of such indeces server implementors will need to decide whether
	their server advertises SORT or MESSAGELIMIT capability.		their server advertises SORT or MESSAGELIMIT capability.
	</t>		</t>
			</section>
	</section>		<section numbered="true" toc="default">
			<name>Interaction with SEARCHRES Extension and IMAP4rev2</name>
	<section title="Interaction with SEARCHRES extension and IMAP4rev2">		<t>
			Servers that support both MESSAGELIMIT and SEARCHRES extensions <xref targ
	<t>		et="RFC5182" format="default"/> <bcp14>MUST</bcp14> truncate SEARCH SAVE result
	Servers that support both MESSAGELIMIT and SEARCHRES <xref target="RFC5182		stored
	"/> extensions MUST truncate SEARCH SAVE result stored
	in the $ variable when the SEARCH command succeeds, but the MESSAGELIMIT r esponse code is returned. For example, if the following		in the $ variable when the SEARCH command succeeds, but the MESSAGELIMIT r esponse code is returned. For example, if the following
	SEARCH would have returned 1200 results in absence of MESSAGELIMIT, and th e MESSAGELIMIT is 1000, only 1000 matching results		SEARCH would have returned 1200 results in absence of MESSAGELIMIT, and th e MESSAGELIMIT is 1000, only 1000 matching results
	will be saved in the $ variable:		will be saved in the $ variable:
	</t>		</t>
			<artwork name="" type="" align="left" alt=""><![CDATA[
	<t>		C: D0004 UID SEARCH RETURN (SAVE) SINCE 1-Jan-2004 NOT FROM "Smith"
	<figure><artwork><![CDATA[		UID 22000:25000 UNDELETED
	C: D0004 UID SEARCH RETURN (SAVE) SINCE 1-Jan-2004 NOT FROM "Smith" UID 22000:		S: D0004 OK [MESSAGELIMIT 1000 1179] SEARCH completed with 1000
	25000 UNDELETED		partial results saved]]></artwork>
	S: D0004 OK [MESSAGELIMIT 1000 1179] SEARCH completed with 1000 partial result		</section>
	s saved
	]]></artwork></figure>
	</t>
	</section>
	</section>		</section>
			<section numbered="true" toc="default">
	<section title="Interoperability Considerations">		<name>Interoperability Considerations</name>
			<section numbered="true" toc="default">
	<section title="Effects of MESSAGELIMIT/SAVELIMIT extensions on non compli		<name>Effects of MESSAGELIMIT and SAVELIMIT Extensions on Noncompliant C
	ant clients">		lients</name>
			<t>A server that advertises the MESSAGELIMIT=N capability would have
	<t>		the following effect on clients that don't support this capability:</t>
	A server that advertises the MESSAGELIMIT=N capability would have the foll		<ul spacing="normal">
	owing effect on clients		<li>
	that don't support this capability:		<t>Operations are not affected on a mailbox that has N messages or f
			ewer.</t>
	<list>		</li>
			<li>
	<t>Operations on a mailbox that has &lt;= N messages are not affected.		<t>In a mailbox with more than N messages:</t>
	</t>		<ul spacing="normal">
			<li>
	<t>In a mailbox with more than N messages:		<t>An attempt to COPY or UID COPY more than N messages will alwa
			ys fail.</t>
	<list>		</li>
			<li>
	<t>An attempt to COPY/UID COPY more than N messages will always fa		<t>EXPUNGE and CLOSE will always operate on the full mailbox, so
	il.</t>		they are not affected.</t>
	<t>EXPUNGE and CLOSE will always operate on the full mailbox, so t		</li>
	hey are not affected.</t>		<li>
	<t>Other commands like FETCH, SEARCH and MOVE will be effectively		<t>Other commands like FETCH, SEARCH, and MOVE will be effective
	restricted to the last N messages		ly restricted to the last N messages
	of the mailbox. In particular unextended SEARCHes intended for cou		of the mailbox. In particular, unextended SEARCHes (intended for c
	nting of messages with or without		ounting of messages with or without
	a particular set of flags would return incorrect counts.</t>		a particular set of flags) would return incorrect counts.</t>
			</li>
	</list>		</ul>
	</t>		</li>
			</ul>
	</list>
	</t>
	</section>		</section>
			<section numbered="true" toc="default">
	<section title="Maintaining Compatibility">		<name>Maintaining Compatibility</name>
	<t>		<t>
	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 mailboxes.		abandon existing clients with respect to operation on large mailboxes.
	Suppose, for example, that a user is accessing a large and active		Suppose, for example, that a user is accessing a large and active
	mailing list via IMAP - the mailing list gets on the order of 1500		mailing list via IMAP, and the mailing list gets on the order of 1500
	posts per week. When the user returns from a week-long vacation and		posts per week. When the user returns from a week-long vacation and
	catches up on the mailing list, the user’s client will be fetching		catches up on the mailing list, the user's client will be fetching
	information about 1500 messages. If the server has a MESSAGELIMIT of		information about 1500 messages. If the server has a MESSAGELIMIT of
	1000, the client will only be able to download 1000 of most recent mes sages;		1000, the client will only be able to download 1000 of the most recent messages;
	the client will not understand why, will not be		the client will not understand why, will not be
	prepared to recover from the situation, and will act as if it is		prepared to recover from the situation, and will act as if it is
	interacting with a broken server.		interacting with a broken server.
	</t>		</t>
	<t>		<t>
	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 at		possible approach is to advertise a MESSAGELIMIT but not enforce it at
	all for a while. Clients that understand this extension will comply,		all for a while. Clients that understand this extension will comply,
	reducing load on the server, but clients that do not understand the		reducing load on the server, but clients that do not understand the
	limit will continue to work in all situations.		limit will continue to work in all situations.
	</t>		</t>
	<t>		<t>
	Another approach, perhaps phased in later, is to advertise one limit		Another approach, which perhaps could be phased in later, is to advert ise one limit
	but to treat it as a soft limit and to begin enforcement at a higher,		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		unadvertised hard limit. In the above example, perhaps the server
	might advertise 1000 but actually enforce a limit of 10,000. Again,		might advertise 1000 but actually enforce a limit of 10,000. Again,
	clients that understand MESSAGELIMIT will comply with the limit of		clients that understand MESSAGELIMIT will comply with the limit of
	1000, but other clients will still interoperate up to the higher		1000, but other clients will still interoperate up to the higher
	threshold.		threshold.
	</t>		</t>
	<t>		<t>
	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 may		implementation and deployment of this extension becomes common, it may
	at some point be acceptable to strictly enforce the advertised limit		at some point be acceptable to strictly enforce the advertised limit
	and to accept that the remaining clients will, indeed, no longer work		and to accept that the remaining clients will, indeed, no longer work
	properly with mailboxes above that limit.		properly with mailboxes above that limit.
	</t>		</t>
	</section>		</section>
	</section>		</section>
			<section numbered="true" toc="default">
			<name>Formal Syntax</name>
			<t>The following syntax specification uses the Augmented Backus-Naur Form
			(ABNF) notation as specified in <xref target="RFC5234" format="default"/>.</t>
	<section title="Formal syntax">		<t>Non-terminals referenced but not defined below are as defined by <xref
	<t>The following syntax specification uses the Augmented		target="RFC3501" format="default">IMAP4</xref>.</t>
	Backus-Naur Form (ABNF) notation as specified in <xref target="ABNF"/>.</t>		<t>Except as noted otherwise, all alphabetic characters are case-insensiti
	<t>Non-terminals referenced but not defined below are as		ve.
	defined by <xref target="RFC3501">IMAP4</xref>.</t>		The use of uppercase or lowercase characters to define token strings is fo
	<t>Except as noted otherwise, all alphabetic characters a		r editorial clarity only.
	re case-insensitive.		Implementations <bcp14>MUST</bcp14> accept these strings in a case-insensi
	The use of upper or lower case characters to define token strings is for e		tive fashion.</t>
	ditorial clarity only.		<sourcecode type="abnf"><![CDATA[
	Implementations MUST accept these strings in a case-insensitive fashion.</
	t>
	<figure><artwork><![CDATA[
	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.]]></sourcecode>
			</section>
	]]></artwork></figure>		<section numbered="true" toc="default">
			<name>Security Considerations</name>
	</section>
	<section title="Security Considerations">
	<t>		<t>
	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 <xref target="RF		does not change the underlying security considerations of IMAP4rev1 <xref
	C3501"/>		target="RFC3501" format="default"/>
	and IMAP4rev2 <xref target="RFC9051"/>.		or IMAP4rev2 <xref target="RFC9051" format="default"/>.
	</t>		</t>
	<t>		<t>
	This document defines an optimization that can both reduce the amount of w ork		This document defines an optimization that can both reduce the amount of w ork
	performed by the server, as well at the amount of data returned to the cli ent.		performed by the server, as well at the amount of data returned to the cli ent.
	Use of this extension is likely to cause the server and the client to use less memory		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 fro m		than when the extension is not used, which can in turn help to protect fro m
	Denial-of-Service attacks. However, as this is going		denial-of-service attacks. However, as this is going
	to be new code in both the client and the server, rigorous testing of such code		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.		is required in order to avoid introducing new implementation bugs.
	</t>		</t>
	<!--///Also misleading message counts? Or an attempt to calculate how much		<!--///Also misleading message counts? Or an attempt to calculate how much
	will be freed if \Deleted messages are EXPUNGEd from the mailbox?-->		will be freed if \Deleted messages are EXPUNGEd from the mailbox?-->
	</section>		</section>
			<section numbered="true" toc="default">
			<name>IANA Considerations</name>
			<section numbered="true" toc="default">
			<name>Additions to the IMAP Capabilities Registry</name>
	<section title="IANA Considerations">		<t>IMAP4 capabilities are registered by publishing a Standards Track
			or IESG-approved Informational or Experimental RFC. The "IMAP Capabilit
	<section title="Changes/additions to the IMAP4 capabilities registry">		ies" registry is
			currently located at:
	<t>		<eref target="https://www.iana.org/assignments/imap-capabilities/" brack
	IMAP4 capabilities are registered by publishing a		ets="angle"/>.</t>
	standards track or		<t>IANA has added "MESSAGELIMIT=" and
	IESG approved Informational or Experimental RFC.		"SAVELIMIT=" capabilities to this registry, with this
	The registry is currently located at:		document as the reference.</t>
	</t>
	<figure><artwork><![CDATA[
	https://www.iana.org/assignments/imap-capabilities/
	]]></artwork></figure>
	<t>
	IANA is requested to add registrations of "MESSAGELIMIT=" and "SAVELIMIT
	=" capabilities to
	this registry, both pointing to this document.
	</t>
	</section>		</section>
	</section>		</section>
			</middle>
			<back>
			<displayreference target="RFC5234" to="ABNF"/>
			<references>
			<name>References</name>
			<references>
	<section title="Acknowledgments">		<name>Normative References</name>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
			119.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
			174.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
			501.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
			502.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
			182.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
			256.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
			234.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
			051.xml"/>
			</references>
			<references>
			<name>Informative References</name>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
			394.xml"/>
			</references>
			</references>
			<section numbered="false" toc="default">
			<name>Acknowledgments</name>
	<t>This document was motivated by the Yahoo! team and their questions		<t>This document was motivated by the Yahoo! team and their questions
	about best client practices for dealing with large mailboxes.</t>		about best client practices for dealing with large mailboxes.</t>
			<t>The authors of this document would like to thank the following people w
			ho
			provided useful comments, contributed text, or participated in
			discussions of this document: <contact fullname="Timo Sirainen"/>,
			<contact fullname="Barry Leiba"/>, <contact fullname="Ken Murchison"/>,
			and <contact fullname="Arnt Gulbrandsen"/>.
			</t>
			</section>
	<t>		</back>
	Editor of this document would like to thank the following
	people
	who provided useful comments, contributed text or partici
	pated in discussions of
	this document: Timo Sirainen, Barry Leiba, Ken Murchison and Arnt Gulbrand
	sen.
	</t>
	</section>
	</middle>		<!-- [rfced] Please review each artwork element and let us know if any should
	<back>		be marked as sourcecode (or another element) instead.
	<references title="Normative References">
	&rfc2119;
	&rfc8174;
	&rfc3501;
	&rfc3502;
	&rfc5182;
	&rfc5256;
	<reference anchor="ABNF">
	<front>
	<title>Augmented BNF for Syntax Specifica
	tions: ABNF</title>
	<author initials="D" surname="Crocker" fu
	llname="Dave Crocker" role="editor">
	<organization />
	</author>
	<author initials="P" surname="Overell" fu
	llname="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;		FYI, we updated artwork to sourcecode type="abnf" in Section 5. Please confirm
			that this is accurate.
	</references>		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.
			-->
	<references title="Informative References">		<!-- [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.
	&rfc9394;		Note that our script did not flag any words in particular, but this should
			still be reviewed as a best practice.
			-->
	</references>		<!--[rfced] FYI, we have removed the index from this document,
			as an index with a single entry does not seem useful.
			-->
	</back>
	</rfc>		</rfc>
End of changes. 84 change blocks.
	531 lines changed or deleted		421 lines changed or added
This html diff was produced by rfcdiff 1.48.