<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="exp" ipr="pre5378Trust200902" docName="draft-ietf-extra-imap-messagelimit-10" number="9738" consensus="true" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" prepTime="2025-03-03T15:47:02" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-extra-imap-messagelimit-10" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9738" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="IMAP MESSAGELIMIT">IMAP MESSAGELIMIT Extension</title>
    <seriesInfo name="RFC" value="9738" stream="IETF"/>
    <author initials="A." surname="Melnikov" fullname="Alexey Melnikov">
      <organization abbrev="Isode" showOnFrontPage="true">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">
      <organization abbrev="Yahoo!" showOnFrontPage="true">Yahoo!</organization>
      <address>
        <email>arunprakash@myyahoo.com</email>
      </address>
    </author>
    <author initials="V." surname="Nagulakonda" fullname="Vikram Nagulakonda">
      <organization abbrev="Yahoo!" showOnFrontPage="true">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>
    <date month="03" year="2025"/>
    <area>ART</area>
    <workgroup>extra</workgroup>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">

        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>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for examination, experimental implementation, and
            evaluation.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document defines an Experimental Protocol for the Internet
            community.  This document is a product of the Internet Engineering
            Task Force (IETF).  It represents the consensus of the IETF community.
            It has received public review and has been approved for publication
            by the Internet Engineering Steering Group (IESG).  Not all documents
            approved by the IESG are candidates for any level of Internet
            Standard; see Section 2 of RFC 7841. 
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9738" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2025 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) 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.
        </t>
        <t indent="0" pn="section-boilerplate.2-3">
            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.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction-and-overview">Introduction and Overview</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-document-conventions">Document Conventions</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-messagelimit-extension">The MESSAGELIMIT Extension</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-returning-limits-on-the-num">Returning Limits on the Number of Messages Processed in a Single Command</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-uidafter-and-uidbefore-sear">UIDAFTER and UIDBEFORE SEARCH Criteria</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.3">
                <t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-interaction-with-sort-and-t">Interaction with SORT and THREAD Extensions</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.4">
                <t indent="0" pn="section-toc.1-1.3.2.4.1"><xref derivedContent="3.4" format="counter" sectionFormat="of" target="section-3.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-interaction-with-searchres-">Interaction with SEARCHRES Extension and IMAP4rev2</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-interoperability-considerat">Interoperability Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-effects-of-messagelimit-and">Effects of MESSAGELIMIT and SAVELIMIT Extensions on Noncompliant Clients</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-maintaining-compatibility">Maintaining Compatibility</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-formal-syntax">Formal Syntax</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-additions-to-the-imap-capab">Additions to the IMAP Capabilities Registry</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2">
              <li pn="section-toc.1-1.8.2.1">
                <t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.2">
                <t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction-and-overview">Introduction and Overview</name>
      <t indent="0" pn="section-1-1">This document defines an extension to the Internet Message Access Protocol <xref target="RFC9051" format="default" sectionFormat="of" derivedContent="RFC9051"/>
      for announcing a server 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 a single APPEND or UID EXPUNGE command.
      This extension is compatible with both IMAP4rev1 <xref target="RFC3501" format="default" sectionFormat="of" derivedContent="RFC3501"/> and IMAP4rev2 <xref target="RFC9051" format="default" sectionFormat="of" derivedContent="RFC9051"/>.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-document-conventions">Document Conventions</name>
      <t indent="0" pn="section-2-1">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 indent="0" pn="section-2-2">
    The key words "<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 "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
      </t>
      <t indent="0" pn="section-2-3">Other capitalized words are IMAP key words <xref target="RFC3501" format="default" sectionFormat="of" derivedContent="RFC3501"/><xref target="RFC9051" format="default" sectionFormat="of" derivedContent="RFC9051"/>
            or key words from this document.</t>
    </section>
    <section anchor="imap-messagelimit" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-the-messagelimit-extension">The MESSAGELIMIT Extension</name>
      <t indent="0" pn="section-3-1">An IMAP server advertises support for the MESSAGELIMIT extension
        by including "MESSAGELIMIT=&lt;limit&gt;" capability in the CAPABILITY response or response code,
        where "&lt;limit&gt;" is a positive integer that conveys the maximum number of messages
        that can be processed in a single SEARCH, FETCH, STORE, COPY, MOVE command (or their UID variants), or in a single APPEND or UID EXPUNGE command.</t>
      <t indent="0" pn="section-3-2">An IMAP server that only enforces the message limit on COPY and APPEND commands (and their UID variants) would include
        the "SAVELIMIT=&lt;limit&gt;" capability (instead of the "MESSAGELIMIT=&lt;limit&gt;") in
        the CAPABILITY response or response code.</t>
      <t indent="0" pn="section-3-3">The limit advertised in the MESSAGELIMIT or SAVELIMIT capability <bcp14>SHOULD NOT</bcp14> be lower than 1000 messages.</t>
      <section anchor="messagelimit-commands" numbered="true" toc="include" removeInRFC="false" pn="section-3.1">
        <name slugifiedName="name-returning-limits-on-the-num">Returning Limits on the Number of Messages Processed in a Single Command</name>
        <t indent="0" pn="section-3.1-1">
      If a server implementation doesn't allow more than &lt;N&gt; messages to be operated on
      by a single COPY or UID COPY command, it <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 &lt;N&gt; messages to be operated on
      by a single SEARCH, FETCH, STORE, or MOVE command (or their UID variants), or an APPEND or UID EXPUNGE command, it <bcp14>MUST</bcp14> return the MESSAGELIMIT response code defined below:

        </t>
        <dl newline="true" spacing="normal" indent="3" pn="section-3.1-2">
          <dt pn="section-3.1-2.1">MESSAGELIMIT</dt>
          <dd pn="section-3.1-2.2">
            <t indent="0" pn="section-3.1-2.2.1">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 indent="0" pn="section-3.1-2.2.2">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 indent="0" pn="section-3.1-2.2.3">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 indent="0" pn="section-3.1-2.2.4">Note that the MESSAGELIMIT response code is similar to the
            LIMIT response code <xref target="RFC9051" format="default" sectionFormat="of" derivedContent="RFC9051"/>,
            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 indent="0" pn="section-3.1-2.2.5">In
            the following example, the &lt;N&gt; value is 1000, and the lowest
            processed UID &lt;LastUID&gt; is 23221.</t>
            <artwork name="" type="" align="left" alt="" pn="section-3.1-2.2.6">
  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</artwork>
            <t indent="0" pn="section-3.1-2.2.7">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 published
            1000-message limit.</t>
            <artwork name="" type="" align="left" alt="" pn="section-3.1-2.2.8">
  C: 04 UID SEARCH UID 22000:25000 UNDELETED
  S: * SEARCH 25000 24998 (... UIDs ...) 23221
  S: 04 OK [MESSAGELIMIT 1000 23221] SEARCH completed with 1000 
      partial results</artwork>
            <t indent="0" pn="section-3.1-2.2.9">The following example demonstrates the copy of messages with UIDs
            between 18000:21000.  The total message count exceeds the server's
            published 1000-message limit.  As COPY or UID COPY needs to be atomic
            (as per <xref target="RFC3501" format="default" sectionFormat="of" derivedContent="RFC3501"/>/<xref target="RFC9051" format="default" sectionFormat="of" derivedContent="RFC9051"/>), no messages are copied.</t>
            <artwork name="" type="" align="left" alt="" pn="section-3.1-2.2.10">
  C: 05 UID COPY 18000:21000 "Trash"
  S: 05 NO [MESSAGELIMIT 1000 20001] Too many messages to copy, 
      try a smaller subset</artwork>
            <t indent="0" pn="section-3.1-2.2.11">The following example shows the move of messages with UIDs between
            18000:21000.  The total message count exceeds the server's
            published 1000-message limit.  (Unlike COPY or UID COPY, MOVE or UID
            MOVE don't need to be atomic.)  The client that wants to move all
            messages in the range and observes a MESSAGELIMIT response code
            can repeat the UID MOVE command with the same parameter. (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="" pn="section-3.1-2.2.12">
  C: 06 UID MOVE 18000:21000 "Archive/2021/2021-12"
  S: * OK [COPYUID 1397597919 20001:21000 22363:23362] Some 
      messages were not moved
  S: * 12336 EXPUNGE
  S: * 12335 EXPUNGE
  ...
  S: * 11337 EXPUNGE
  S: 06 OK [MESSAGELIMIT 1000 20001] MOVE completed for the last
      1000 messages</artwork>
            <t indent="0" pn="section-3.1-2.2.13">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 published 1000-message limit.
            The client that wants to change flags for all messages in the
            range and observes a MESSAGELIMIT response 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 also 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="" pn="section-3.1-2.2.14">
  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</artwork>
            <t indent="0" pn="section-3.1-2.2.15">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 published 1000-message limit.  The
            client that wants to remove all messages marked as \Deleted in the
            range and observes a MESSAGELIMIT response 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 tagged NO or BAD is returned).</t>
            <artwork name="" type="" align="left" alt="" pn="section-3.1-2.2.16">
  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 1000 messages</artwork>
            <t indent="0" pn="section-3.1-2.2.17">The following example shows removal of messages (using EXPUNGE)
            that have the \Deleted flag set.  Unlike UID EXPUNGE, the server
            <bcp14>MUST NOT</bcp14> impose any message limit when processing
            EXPUNGE.</t>
            <artwork name="" type="" align="left" alt="" pn="section-3.1-2.2.18">
  C: 09 EXPUNGE
  S: * 4306 EXPUNGE
  S: * 4305 EXPUNGE
  ...
  S: * 3307 EXPUNGE
  S: * 112 EXPUNGE
  S: 09 OK EXPUNGE completed</artwork>
            <t indent="0" pn="section-3.1-2.2.19">Similarly, the server <bcp14>MUST NOT</bcp14> impose any
            message limit when processing a "CLOSE" or a "STATUS UNSEEN"
            command.</t>
            <t indent="0" pn="section-3.1-2.2.20">The following example shows use of the MESSAGELIMIT response code
            together with the PARTIAL <xref target="RFC9394" format="default" sectionFormat="of" derivedContent="RFC9394"/> 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>
            <artwork name="" type="" align="left" alt="" pn="section-3.1-2.2.21">
  C: 10 UID FETCH 22000:25000 (UID FLAGS MODSEQ) 
      (PARTIAL -1:-1500)
  S: 10 NO [MESSAGELIMIT 1000] FETCH exceeds the maximum 1000-
      message limit</artwork>
            <t indent="0" pn="section-3.1-2.2.22">Without the PARTIAL parameter, the above UID FETCH can look like
            this:</t>
            <artwork name="" type="" align="left" alt="" pn="section-3.1-2.2.23">
  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 maximum 
      1000-message limit</artwork>
          </dd>
        </dl>
        <t indent="0" pn="section-3.1-3">Note that when the server needs to return both EXPUNGEISSUED
            <xref target="RFC9051" format="default" sectionFormat="of" derivedContent="RFC9051"/> 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="" pn="section-3.1-4">
  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 also expunged</artwork>
        <t indent="0" pn="section-3.1-5">When the IMAP MULTIAPPEND extension <xref target="RFC3502" format="default" sectionFormat="of" derivedContent="RFC3502"/> is also supported by the server,
      the message limit also applies to the APPEND command. As MULTIAPPEND APPEND needs to atomic (as per <xref target="RFC3502" format="default" sectionFormat="of" derivedContent="RFC3502"/>),
      no messages are appended when the server MESSAGELIMIT is exceeded.</t>
      </section>
      <section anchor="search-criteria" numbered="true" toc="include" removeInRFC="false" pn="section-3.2">
        <name slugifiedName="name-uidafter-and-uidbefore-sear">UIDAFTER and UIDBEFORE SEARCH Criteria</name>
        <t indent="0" pn="section-3.2-1">The MESSAGELIMIT extension also defines two extra SEARCH keys,
        UIDAFTER and UIDBEFORE, which make it easier to convert a single UID
        to a range of UIDs.</t>
        <dl spacing="normal" newline="false" indent="3" pn="section-3.2-2">
          <dt pn="section-3.2-2.1">"UIDAFTER &lt;uid&gt;"</dt>
          <dd pn="section-3.2-2.2">Messages that have a UID greater
          than the specified UID.  This is semantically the same as "UID
          &lt;uid&gt;+1:*".</dd>
          <dt pn="section-3.2-2.3">"UIDBEFORE &lt;uid&gt;"</dt>
          <dd pn="section-3.2-2.4">Messages that have a UID less
          than the specified 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).</dd>
        </dl>
        <t indent="0" pn="section-3.2-3">
        These two SEARCH keys are particularly useful when the SEARCHRES extension <xref target="RFC5182" format="default" sectionFormat="of" derivedContent="RFC5182"/> 
        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>
        <artwork name="" type="" align="left" alt="" pn="section-3.2-4">
  C: 12 UID SEARCH UIDAFTER 25000 UNDELETED
  S: * SEARCH 27800 27798 (... 250 UIDs ...) 25001
  S: 12 OK SEARCH completed</artwork>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-3.3">
        <name slugifiedName="name-interaction-with-sort-and-t">Interaction with SORT and THREAD Extensions</name>
        <t indent="0" pn="section-3.3-1">
      Servers that advertise MESSAGELIMIT N will be unable to execute a THREAD command <xref target="RFC5256" format="default" sectionFormat="of" derivedContent="RFC5256"/> in a mailbox with more than N messages.
        </t>
        <t indent="0" pn="section-3.3-2">
      Servers that advertise MESSAGELIMIT N might be unable to execute a SORT command <xref target="RFC5256" format="default" sectionFormat="of" derivedContent="RFC5256"/> in a mailbox with more than N messages,
      unless they maintain indices for different SORT orders they support. In absence of such indices, server implementors will need to decide whether
      their server advertises SORT or MESSAGELIMIT capability.
        </t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-3.4">
        <name slugifiedName="name-interaction-with-searchres-">Interaction with SEARCHRES Extension and IMAP4rev2</name>
        <t indent="0" pn="section-3.4-1">
      Servers that support both MESSAGELIMIT and SEARCHRES extensions <xref target="RFC5182" format="default" sectionFormat="of" derivedContent="RFC5182"/> <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>
        <artwork name="" type="" align="left" alt="" pn="section-3.4-2">
  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 results saved</artwork>
      </section>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-interoperability-considerat">Interoperability Considerations</name>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-effects-of-messagelimit-and">Effects of MESSAGELIMIT and SAVELIMIT Extensions on Noncompliant Clients</name>
        <t indent="0" pn="section-4.1-1">A server that advertises the MESSAGELIMIT=N capability would have
        the following effect on clients that don't support this capability:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.1-2">
          <li pn="section-4.1-2.1">
            <t indent="0" pn="section-4.1-2.1.1">Operations are not affected on a mailbox that has N messages or fewer.</t>
          </li>
          <li pn="section-4.1-2.2">
            <t indent="0" pn="section-4.1-2.2.1">In a mailbox with more than N messages:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.1-2.2.2">
              <li pn="section-4.1-2.2.2.1">
                <t indent="0" pn="section-4.1-2.2.2.1.1">An attempt to COPY or UID COPY more than N messages will always fail.</t>
              </li>
              <li pn="section-4.1-2.2.2.2">
                <t indent="0" pn="section-4.1-2.2.2.2.1">EXPUNGE and CLOSE will always operate on the full mailbox, so they are not affected.</t>
              </li>
              <li pn="section-4.1-2.2.2.3">
                <t indent="0" pn="section-4.1-2.2.2.3.1">Other commands like FETCH, SEARCH, and MOVE will be effectively restricted to the last N messages
              of the mailbox. In particular, unextended SEARCHes (intended for counting of messages with or without
              a particular set of flags) would return incorrect counts.</t>
              </li>
            </ul>
          </li>
        </ul>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-maintaining-compatibility">Maintaining Compatibility</name>
        <t indent="0" pn="section-4.2-1">
          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 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
          catches up on the mailing list, the user'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 indent="0" pn="section-4.2-2">
          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 indent="0" pn="section-4.2-3">
          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 indent="0" pn="section-4.2-4">
          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>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-formal-syntax">Formal Syntax</name>
      <t indent="0" pn="section-5-1">The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in <xref target="RFC5234" format="default" sectionFormat="of" derivedContent="ABNF"/>.</t>
      <t indent="0" pn="section-5-2">Non-terminals referenced but not defined below are as defined by <xref target="RFC3501" format="default" sectionFormat="of" derivedContent="RFC3501">IMAP4</xref>.</t>
      <t indent="0" pn="section-5-3">Except as noted otherwise, all alphabetic characters are case-insensitive.
      The use of uppercase or lowercase characters to define token strings is for editorial clarity only.
      Implementations <bcp14>MUST</bcp14> accept these strings in a case-insensitive fashion.</t>
      <sourcecode type="abnf" markers="false" pn="section-5-4">
capability          =/ "MESSAGELIMIT=" message-limit /
                       "SAVELIMIT=" message-limit
                       ;; &lt;capability&gt; 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.</sourcecode>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-6-1">
      This document defines an additional IMAP4 capability.  As such, it
      does not change the underlying security considerations of IMAP4rev1 <xref target="RFC3501" format="default" sectionFormat="of" derivedContent="RFC3501"/>
      or IMAP4rev2 <xref target="RFC9051" format="default" sectionFormat="of" derivedContent="RFC9051"/>.
      </t>
      <t indent="0" pn="section-6-2">
      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 from
      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
      is required in order to avoid introducing new implementation bugs.
      </t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-7.1">
        <name slugifiedName="name-additions-to-the-imap-capab">Additions to the IMAP Capabilities Registry</name>
        <t indent="0" pn="section-7.1-1">IMAP4 capabilities are registered by publishing a Standards Track
        or IESG-approved Informational or Experimental RFC.  The "IMAP Capabilities" registry is
        currently located at:
        <eref target="https://www.iana.org/assignments/imap-capabilities/" brackets="angle"/>.</t>
        <t indent="0" pn="section-7.1-2">IANA has added "MESSAGELIMIT=" and
        "SAVELIMIT=" capabilities to this registry, with this
        document as the reference.</t>
      </section>
    </section>
  </middle>
  <back>
    <displayreference target="RFC5234" to="ABNF"/>
    <references pn="section-8">
      <name slugifiedName="name-references">References</name>
      <references pn="section-8.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC5234" target="https://www.rfc-editor.org/info/rfc5234" quoteTitle="true" derivedAnchor="ABNF">
          <front>
            <title>Augmented BNF for Syntax Specifications: ABNF</title>
            <author fullname="D. Crocker" initials="D." role="editor" surname="Crocker"/>
            <author fullname="P. Overell" initials="P." surname="Overell"/>
            <date month="January" year="2008"/>
            <abstract>
              <t indent="0">Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="68"/>
          <seriesInfo name="RFC" value="5234"/>
          <seriesInfo name="DOI" value="10.17487/RFC5234"/>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC3501" target="https://www.rfc-editor.org/info/rfc3501" quoteTitle="true" derivedAnchor="RFC3501">
          <front>
            <title>INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1</title>
            <author fullname="M. Crispin" initials="M." surname="Crispin"/>
            <date month="March" year="2003"/>
            <abstract>
              <t indent="0">The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev1 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev1 also provides the capability for an offline client to resynchronize with the server. IMAP4rev1 includes operations for creating, deleting, and renaming mailboxes, checking for new messages, permanently removing messages, setting and clearing flags, RFC 2822 and RFC 2045 parsing, searching, and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev1 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev1 supports a single server. A mechanism for accessing configuration information to support multiple IMAP4rev1 servers is discussed in RFC 2244. IMAP4rev1 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as RFC 2821. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3501"/>
          <seriesInfo name="DOI" value="10.17487/RFC3501"/>
        </reference>
        <reference anchor="RFC3502" target="https://www.rfc-editor.org/info/rfc3502" quoteTitle="true" derivedAnchor="RFC3502">
          <front>
            <title>Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension</title>
            <author fullname="M. Crispin" initials="M." surname="Crispin"/>
            <date month="March" year="2003"/>
            <abstract>
              <t indent="0">This document describes the multiappending extension to the Internet Message Access Protocol (IMAP) (RFC 3501). This extension provides substantial performance improvements for IMAP clients which upload multiple messages at a time to a mailbox on the server. A server which supports this extension indicates this with a capability name of "MULTIAPPEND". [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3502"/>
          <seriesInfo name="DOI" value="10.17487/RFC3502"/>
        </reference>
        <reference anchor="RFC5182" target="https://www.rfc-editor.org/info/rfc5182" quoteTitle="true" derivedAnchor="RFC5182">
          <front>
            <title>IMAP Extension for Referencing the Last SEARCH Result</title>
            <author fullname="A. Melnikov" initials="A." surname="Melnikov"/>
            <date month="March" year="2008"/>
            <abstract>
              <t indent="0">Many IMAP clients use the result of a SEARCH command as the input to perform another operation, for example, fetching the found messages, deleting them, or copying them to another mailbox.</t>
              <t indent="0">This can be achieved using standard IMAP operations described in RFC 3501; however, this would be suboptimal. The server will send the list of found messages to the client; after that, the client will have to parse the list, reformat it, and send it back to the server. The client can't pipeline the SEARCH command with the subsequent command, and, as a result, the server might not be able to perform some optimizations.</t>
              <t indent="0">This document proposes an IMAP extension that allows a client to tell a server to use the result of a SEARCH (or Unique Identifier (UID) SEARCH) command as an input to any subsequent command. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5182"/>
          <seriesInfo name="DOI" value="10.17487/RFC5182"/>
        </reference>
        <reference anchor="RFC5256" target="https://www.rfc-editor.org/info/rfc5256" quoteTitle="true" derivedAnchor="RFC5256">
          <front>
            <title>Internet Message Access Protocol - SORT and THREAD Extensions</title>
            <author fullname="M. Crispin" initials="M." surname="Crispin"/>
            <author fullname="K. Murchison" initials="K." surname="Murchison"/>
            <date month="June" year="2008"/>
            <abstract>
              <t indent="0">This document describes the base-level server-based sorting and threading extensions to the IMAP protocol. These extensions provide substantial performance improvements for IMAP clients that offer sorted and threaded views. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5256"/>
          <seriesInfo name="DOI" value="10.17487/RFC5256"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC9051" target="https://www.rfc-editor.org/info/rfc9051" quoteTitle="true" derivedAnchor="RFC9051">
          <front>
            <title>Internet Message Access Protocol (IMAP) - Version 4rev2</title>
            <author fullname="A. Melnikov" initials="A." role="editor" surname="Melnikov"/>
            <author fullname="B. Leiba" initials="B." role="editor" surname="Leiba"/>
            <date month="August" year="2021"/>
            <abstract>
              <t indent="0">The Internet Message Access Protocol Version 4rev2 (IMAP4rev2) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev2 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev2 also provides the capability for an offline client to resynchronize with the server.</t>
              <t indent="0">IMAP4rev2 includes operations for creating, deleting, and renaming mailboxes; checking for new messages; removing messages permanently; setting and clearing flags; parsing per RFCs 5322, 2045, and 2231; searching; and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev2 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers.</t>
              <t indent="0">IMAP4rev2 does not specify a means of posting mail; this function is handled by a mail submission protocol such as the one specified in RFC 6409.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9051"/>
          <seriesInfo name="DOI" value="10.17487/RFC9051"/>
        </reference>
      </references>
      <references pn="section-8.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="RFC9394" target="https://www.rfc-editor.org/info/rfc9394" quoteTitle="true" derivedAnchor="RFC9394">
          <front>
            <title>IMAP PARTIAL Extension for Paged SEARCH and FETCH</title>
            <author fullname="A. Melnikov" initials="A." surname="Melnikov"/>
            <author fullname="A. P. Achuthan" initials="A. P." surname="Achuthan"/>
            <author fullname="V. Nagulakonda" initials="V." surname="Nagulakonda"/>
            <author fullname="L. Alves" initials="L." surname="Alves"/>
            <date month="June" year="2023"/>
            <abstract>
              <t indent="0">The PARTIAL extension of the Internet Message Access Protocol (see RFCs 3501 and 9051) allows clients to limit the number of SEARCH results returned, as well as to perform incremental (paged) searches. This also helps servers to optimize resource usage when performing searches.</t>
              <t indent="0">This document extends the PARTIAL SEARCH return option originally specified in RFC 5267. It also clarifies some interactions between RFC 5267 and RFCs 4731 and 9051.</t>
              <t indent="0">This document updates RFCs 4731 and 5267.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9394"/>
          <seriesInfo name="DOI" value="10.17487/RFC9394"/>
        </reference>
      </references>
    </references>
    <section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t indent="0" pn="section-appendix.a-1">This document was motivated by the Yahoo! team and their questions
      about best client practices for dealing with large mailboxes.</t>
      <t indent="0" pn="section-appendix.a-2">The authors of this document would like to thank the following people who
      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>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="A." surname="Melnikov" fullname="Alexey Melnikov">
        <organization abbrev="Isode" showOnFrontPage="true">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">
        <organization abbrev="Yahoo!" showOnFrontPage="true">Yahoo!</organization>
        <address>
          <email>arunprakash@myyahoo.com</email>
        </address>
      </author>
      <author initials="V." surname="Nagulakonda" fullname="Vikram Nagulakonda">
        <organization abbrev="Yahoo!" showOnFrontPage="true">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>
    </section>
  </back>
</rfc>
