<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc='yes' ?>
<?rfc symrefs='yes' ?>
<?rfc sortrefs='no'?>
<?rfc linkmailto='no'?>
<?rfc compact='yes'?>
<?rfc comments='yes'?>
<?rfc inline='yes'?>
<?rfc-ext parse-xml-in-artwork='yes' ?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> "rfc2629-xhtml.ent">

<rfc ipr='pre5378Trust200902'
  docName='draft-ietf-extra-imap4rev2-30'
  obsoletes='3501' category='std'> xmlns:xi="http://www.w3.org/2001/XInclude" ipr="pre5378Trust200902" docName="draft-ietf-extra-imap4rev2-30" number="9051" obsoletes="3501" updates="" submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3">

  <!-- xml2rfc v2v3 conversion 3.5.0 -->

  <front>
    <title abbrev='IMAP4rev2'>Internet abbrev="IMAP4rev2">Internet Message Access Protocol (IMAP) - Version 4rev2</title>
    <seriesInfo name="RFC" value="9051"/>
    <author initials="A." surname="Melnikov" fullname="Alexey Melnikov" role="editor">
      <organization>Isode Ltd</organization>
      <address>
        <postal>
          <street>14 Castle Mews</street>
          <city>Hampton</city>
          <region>Middlesex</region>
          <city>Hampton, Middlesex</city>
          <code>TW12 2NP</code>
          <country>UK</country>
          <country>United Kingdom</country>
        </postal>
        <email>Alexey.Melnikov@isode.com</email>
      </address>
    </author>
    <author initials='B.' surname='Leiba' fullname='Barry Leiba' role='editor'> initials="B." surname="Leiba" fullname="Barry Leiba" role="editor">
      <organization>Futurewei Technologies</organization>
      <address>
        <phone>+1 646 827 0648</phone>
        <email>barryleiba@computer.org</email>
        <uri>http://internetmessagingtechnology.org/</uri>
      </address>
    </author>
    <date year="2021" month="August" />
    <area>Applications and RealTime</area>
    <keyword></keyword>

    <abstract>
      <t>
        The Internet Message Access Protocol, 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>

        IMAP4rev2 includes operations for creating, deleting, and renaming
        mailboxes,
        mailboxes; checking for new messages, permanently messages; removing messages, messages permanently;
        setting and clearing flags, RFC flags; parsing per RFCs 5322, RFC 2045 2045, and RFC 2231 parsing, searching, 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>
  <!--Removed:
        IMAP4rev2 supports a single server.  A mechanism for accessing
        configuration information to support multiple IMAP4rev2 servers is
        discussed in RFC 2244.
   -->
      </t>
      <t>
        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>
  <middle>
    <section title='How numbered="true" toc="default">
      <name>How to Read This Document'> Document</name>
      <section title='Organization numbered="true" toc="default">
        <name>Organization of This Document'> Document</name>
        <t>
   This document is written from the point of view of the implementor of
   an IMAP4rev2 client or server.  Beyond the protocol overview in
   section 2,
   <xref target="protocol_overview"/>, it is not optimized for someone trying to understand the
   operation of the protocol.

 The material in sections 3 through 5 Sections <xref target="state_and_flow" format="counter"/>, <xref target="data_formats" format="counter"/>, and <xref target="operational_considerations" format="counter"/>
provides the general context and definitions with which IMAP4rev2
   operates.
        </t>
        <t>
   Sections 6, 7, <xref target="client_commands" format="counter"/>, <xref target="server-responses" format="counter"/>, and 9 <xref target="IMAP-ABNF" format="counter"/> describe the IMAP commands, responses, and
   syntax, respectively.  The relationships among these are such that it
   is almost impossible to understand any of them separately.  In
   particular, do not attempt to deduce command syntax from the command
   section alone; instead instead, refer to the Formal Syntax "Formal Syntax" (<xref target='IMAP-ABNF'/>). target="IMAP-ABNF" format="default"/>).
        </t>
      </section>
      <section title='Conventions numbered="true" toc="default">
        <name>Conventions Used in This Document'> Document</name>
        <t>
   "Conventions" are basic principles or procedures.  Document
   conventions are noted in this section.
        </t>
        <t>
   In examples, "C:" and "S:" indicate lines sent by the client and
   server
   server, respectively. Note that each line includes the terminating CRLF.
        </t>

   <t>
          <iref item='MUST item="MUST (specification requirement term)'/> term)" subitem="" primary="false"/>
          <iref item='MUST item="MUST NOT (specification requirement term)'/> term)" subitem="" primary="false"/>
          <iref item='OPTIONAL item="OPTIONAL (specification requirement term)'/> term)" subitem="" primary="false"/>
          <iref item='REQUIRED item="REQUIRED (specification requirement term)'/> term)" subitem="" primary="false"/>
          <iref item='SHOULD item="SHOULD (specification requirement term)'/> term)" subitem="" primary="false"/>
          <iref item='SHOULD item="SHOULD NOT (specification requirement term)'/> term)" subitem="" primary="false"/>
          <iref item='RECOMMENDED item="RECOMMENDED (specification requirement term)'/> term)" subitem="" primary="false"/>
          <iref item='NOT item="NOT RECOMMENDED (specification requirement term)'/> term)" subitem="" primary="false"/>
          <iref item='MAY item="MAY (specification requirement term)'/> term)" subitem="" primary="false"/>
          <iref item='OPTIONAL item="OPTIONAL (specification requirement term)'/> term)" subitem="" primary="false"/>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
      "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
        </t>
        <t>
   The word "can" (not "may") is used to refer to a possible
   circumstance or situation, as opposed to an optional facility of the
   protocol.
        </t>
        <t>
   "User" is used to refer to a human user, whereas "client" refers to
   the software being run by the user.
        </t>
        <t>
   "Connection" refers to the entire sequence of client/server
   <!--"Internet connection"?-->
   interaction from the initial establishment of the network connection
   until its termination.
        </t>
        <t>
   "Session" refers to the sequence of client/server interaction from
   the time that a mailbox is selected (SELECT or EXAMINE command) until
   the time that selection ends (SELECT or EXAMINE of another mailbox,
   CLOSE command, UNSELECT command, or connection termination).
        </t>
        <t>
   The term "Implicit TLS" refers to the automatic negotiation of TLS
   whenever a TCP connection is made on a particular TCP port that is
   used exclusively by that server for TLS connections.  The term
   "Implicit TLS" is intended to contrast with the use of the STARTTLS command
   in IMAP that is used by the client and the server to explicitly
   negotiate TLS on an established cleartext TCP connection.
        </t>
        <t>
   Characters are 8-bit UTF-8 (of which 7-bit US-ASCII is a subset) subset), unless otherwise specified.  Other
   character sets are indicated using a "CHARSET", as described in
   <xref target='MIME-IMT'/> target="RFC2046" format="default"/> and defined in <xref target='CHARSET'/>. target="RFC2978" format="default"/>.  CHARSETs have important
   additional semantics in addition to defining a character set; refer to
   these documents for more detail.
        </t>
        <t>
   There are several protocol conventions in IMAP.  These refer to
   aspects of the specification which that are not strictly part of the IMAP
   protocol,
   protocol but reflect generally-accepted generally accepted practice.  Implementations
   need to be aware of these conventions, and avoid conflicts whether or
   not they implement the convention.  For example, "&amp;" may not be used
   as a hierarchy delimiter since it conflicts with the Mailbox
   International Naming Convention, and other uses of "&amp;" in mailbox
   names are impacted as well.
        </t>
      </section>
      <section title='Special numbered="true" toc="default">
        <name>Special Notes to Implementors'> Implementors</name>
        <t>
   Implementors of the IMAP protocol are strongly encouraged to read the
   IMAP implementation recommendations document <xref target='IMAP-IMPLEMENTATION'/> target="RFC2683" format="default"/> in
   conjunction with this document, to help understand the intricacies of
   this protocol and how best to build an interoperable product.
        </t>
        <t>
   IMAP4rev2 is designed to be upwards compatible from the IMAP4rev1 <xref target='RFC3501'/>, the target="RFC3501" format="default"/>, IMAP2 <xref target='IMAP2'/> target="RFC1176" format="default"/>, and
   unpublished IMAP2bis <xref target="IMAP2BIS"/> target="I-D.ietf-imap-imap2bis" format="default"/> protocols.  IMAP4rev2 is largely compatible with
   the IMAP4rev1 protocol described in RFC 3501 and
   the IMAP4 protocol described in RFC 1730; <xref target="RFC1730" format="default"/>; the exception being in
   certain facilities added in RFC 1730 <xref target="RFC1730" format="default"/> and RFC 3501 <xref target="RFC3501" format="default"/> that proved problematic and were
   subsequently removed or replaced by better alternatives.
   In the course of the evolution of IMAP4rev2,
   some aspects in the earlier protocols have become obsolete.

  Obsolete commands, responses, and data formats which that an IMAP4rev2
   implementation can encounter when used with an earlier implementation
   are described in Appendices <xref target='changesFromIMAP4rev1'/>, target="IMAP4rev1-compat" format="counter" derivedContent="A" /> and
   <xref target="IMAP4rev1-compat"/> target="changesFromIMAP4rev1" format="counter" derivedContent="E"/> and <xref target='IMAP-OBSOLETE'/>. target="RFC2062" format="default"/>. IMAP4rev2 supports 63bit 63-bit body part parts and message sizes.
   IMAP4rev2 compatibility with BINARY and LIST-EXTENDED IMAP extensions are described in
   Appendices <xref target="BINARY-compat"/> target="BINARY-compat" format="counter" sectionFormat="of" derivedContent="B"/> and <xref target="LIST-EXTENDED-compat"/> target="LIST-EXTENDED-compat" format="counter" sectionFormat="of" derivedContent="C"/>, respectively.

        </t>
        <t>
   Other compatibility issues with IMAP2bis, the most common variant of
   the earlier protocol, are discussed in <xref target='IMAP-COMPAT'/>. target="RFC2061" format="default"/>.  A full
   discussion of compatibility issues with rare (and presumed extinct)
   variants of <xref target='IMAP2'/> target="RFC1176" format="default"/> is in <xref target='IMAP-HISTORICAL'/>; target="RFC1732" format="default"/>; this document is
   primarily of historical interest.
        </t>
        <t>
  IMAP was originally developed for the older <xref target='RFC-822'/> target="RFC0822" format="default"/> standard, and
   as a consequence, the "RFC822.SIZE" fetch item in IMAP incorporates "RFC822" in
   its name.  "RFC822" should be interpreted as a reference to
   the updated <xref target='RFC-5322'/> target="RFC5322" format="default"/> standard.
        </t>
      <t>
        IMAP4rev2 does not specify a means of posting mail; this function is
        handled by a mail submission protocol such as the one specified in <xref target="RFC6409"/>.
      </t>
      </section>
    </section>
    <section title='Protocol Overview'> numbered="true" toc="default" anchor="protocol_overview">
      <name>Protocol Overview</name>
      <section title='Link Level'> numbered="true" toc="default">
        <name>Link Level</name>
        <t>
   The IMAP4rev2 protocol assumes a reliable data stream such as that
   provided by TCP.  When TCP is used, an IMAP4rev2 server listens on
   port 143 (cleartext port) or port 993 (Implicit TLS port).
        </t>
      </section>
      <section title='Commands numbered="true" toc="default">
        <name>Commands and Responses'> Responses</name>
        <t>
   An IMAP4rev2 connection consists of the establishment of a
   client/server network connection, an initial greeting from the
   server, and client/server interactions.  These client/server
   interactions consist of a client command, server data, and a server
   completion result response.
        </t>
        <t>
   All interactions transmitted by client and server are in the form of
   lines, that is, strings that end with a CRLF.  The protocol receiver
   of an IMAP4rev2 client or server is either reading either a line, line or is
   reading
   a sequence of octets with a known count followed by a line.
        </t>
        <section title='Client numbered="true" toc="default">
          <name>Client Protocol Sender and Server Protocol Receiver'> Receiver</name>
          <t>
   The client command begins an operation.  Each client command is
   prefixed with an identifier (typically a short alphanumeric string,
   e.g., A0001, A0002, etc.) called a "tag".  A different tag is
   generated by the client for each command.
   More formally: the client SHOULD <bcp14>SHOULD</bcp14> generate a unique tag for every command,
   but a server MUST <bcp14>MUST</bcp14> accept tag reuse.
          </t>
          <t>
   Clients MUST <bcp14>MUST</bcp14> follow the syntax outlined in this specification
   strictly.  It is a syntax error to send a command with missing or
   extraneous spaces or arguments.
          </t>
          <t>
   There are two cases in which a line from the client does not
   represent a complete command.  In one case, a command argument is
   quoted with an octet count (see the description of literal in <xref target='data-string'/>); target="data-string" format="default"/>);
   in the other case, the command arguments require
   server feedback (see the AUTHENTICATE command in <xref target='authenticate'/>). target="authenticate" format="default"/>).
   In either case, the server sends a command continuation request response if it is ready
   for the octets (if appropriate) and the remainder of the command.
   This response is prefixed with the token "+".

        <list>
        <t>
	  </t>
        <t indent="3">
        Note: If, instead, the server detected an error in the
        command, it sends a BAD completion response with a tag
        matching the command (as described below) to reject the
        command and prevent the client from sending any more of the
        command.
        </t>

        <t>
        <t indent="3">
        It is also possible for the server to send a completion
        response for some other command (if multiple commands are
        in progress), progress) or untagged data.  In either case, the
        command continuation request is still pending; the client
        takes the appropriate action for the response, response and reads
        another response from the server.  In all cases, the client
        MUST
        <bcp14>MUST</bcp14> send a complete command (including receiving all
        command continuation request responses and sending command
        continuations for the command) before initiating a new
        command.
        </t>
        </list>
   </t>
          <t>
   The protocol receiver of an IMAP4rev2 server reads a command line
   from the client, parses the command and its arguments, and transmits
   server data and a server command completion result response.
          </t>
        </section>
        <section title='Server numbered="true" toc="default">
          <name>Server Protocol Sender and Client Protocol Receiver'> Receiver</name>
          <t>
   Data transmitted by the server to the client and status responses
   that do not indicate command completion are prefixed with the token
   "*",
   "*" and are called untagged responses.
          </t>
          <t>
   Server data MAY <bcp14>MAY</bcp14> be sent as a result of a client command, command or MAY <bcp14>MAY</bcp14> be
   sent unilaterally by the server.  There is no syntactic difference
   between server data that resulted from a specific command and server
   data that were sent unilaterally.
          </t>
          <t>
   The server completion result response indicates the success or
   failure of the operation.  It is tagged with the same tag as the
   client command which that began the operation.  Thus, if more than one
   command is in progress, the tag in a server completion response
   identifies the command to which the response applies.  There are
   three possible server completion responses: OK (indicating success),
   NO (indicating failure), or BAD (indicating a protocol error such as
   unrecognized command or command syntax error).
          </t>
          <t>
   Servers SHOULD <bcp14>SHOULD</bcp14> strictly enforce the syntax outlined in this specification
   strictly. specification.
   Any client command with a protocol syntax error, including
   (but not limited to) missing or extraneous spaces or arguments,
   SHOULD
   <bcp14>SHOULD</bcp14> be rejected, rejected and the client given a BAD server completion
   response.
          </t>
          <t>
   The protocol receiver of an IMAP4rev2 client reads a response line
   from the server.  It then takes action on the response based upon the
   first token of the response, which can be a tag, a "*", or a "+".
          </t>
          <t>
   A client MUST <bcp14>MUST</bcp14> be prepared to accept any server response at all times.
   This includes server data that was not requested.  Server data SHOULD <bcp14>SHOULD</bcp14>
   be remembered (cached), so that the client can reference its remembered copy
   rather than sending a command to the server to request the data.  In
   the case of certain server data, the data MUST <bcp14>MUST</bcp14> be remembered,
   as specified elsewhere in this document.
          </t>
          <t>
   This topic is discussed in greater detail in the Server Responses
   section. "Server Responses" (see <xref target="server-responses"/>).
          </t>
        </section>
      </section>
      <section title='Message Attributes'> numbered="true" toc="default">
        <name>Message Attributes</name>
        <t>
   In addition to message text, each message has several attributes
   associated with it.  These attributes can be retrieved individually
   or in conjunction with other attributes or message texts.
        </t>
        <section title='Message Numbers'> numbered="true" toc="default">
          <name>Message Numbers</name>
          <t>
   Messages in IMAP4rev2 are accessed by one of two numbers; numbers: the unique
   identifier Unique
   Identifier (UID) or the message sequence number.
          </t>
          <section title='Unique anchor="uid-def" numbered="true" toc="default">
            <name>Unique Identifier (UID) Message Attribute' anchor='uid-def'> Attribute</name>
            <iref item='Unique item="Unique Identifier (UID) (message attribute)'/> attribute)" subitem="" primary="false"/>
            <t>
   A UID is an unsigned non-zero 32-bit value assigned to each message, which when used with the
   unique identifier validity value (see below) forms a 64-bit value
   that MUST NOT <bcp14>MUST NOT</bcp14> refer to any other message in the mailbox or any
   subsequent mailbox with the same name forever.  Unique identifiers
   are assigned in a strictly ascending fashion in the mailbox; as each
   message is added to the mailbox mailbox, it is assigned a higher UID than the those of all
   message(s) which were added previously. that are already in the mailbox.  Unlike message sequence
   numbers, unique identifiers are not necessarily contiguous.
            </t>
            <t>
   The unique identifier of a message MUST NOT <bcp14>MUST NOT</bcp14> change during the
   session,
   session and SHOULD NOT <bcp14>SHOULD NOT</bcp14> change between sessions.  Any change of
   unique identifiers between sessions MUST <bcp14>MUST</bcp14> be detectable using the
   UIDVALIDITY mechanism discussed below.  Persistent unique identifiers
   are required for a client to resynchronize its state from a previous
   session with the server (e.g., disconnected or offline access
   clients <xref target="IMAP-MODEL"/>); target="RFC1733" format="default"/>); this is discussed further in <xref target='IMAP-DISC'/>. target="RFC4549" format="default"/>.
            </t>
            <t>
   Associated with every mailbox are two 32-bit unsigned non-zero values which that aid in unique
   identifier handling: the next unique identifier value (UIDNEXT) and the unique
   identifier validity value (UIDVALIDITY).
            </t>
            <t>
   The next unique identifier value is the predicted value that will be
   assigned to a new message in the mailbox.  Unless the unique
   identifier validity also changes (see below), the next unique
   identifier value MUST <bcp14>MUST</bcp14> have the following two characteristics.  First,
   the next unique identifier value MUST NOT <bcp14>MUST NOT</bcp14> change unless new messages
   are added to the mailbox; and second, the next unique identifier
   value MUST <bcp14>MUST</bcp14> change whenever new messages are added to the mailbox,
   even if those new messages are subsequently expunged.

        <list><t>

            </t>
        <aside><t>
        Note: The next unique identifier value is intended to
        provide a means for a client to determine whether any
        messages have been delivered to the mailbox since the
        previous time it checked this value.  It is not intended to
        provide any guarantee that any message will have this
        unique identifier.  A client can only assume, at the time
        that it obtains the next unique identifier value, that
        messages arriving after that time will have a UID greater
        than or equal to that value.
        </t></list>
   </t> value.</t>
        </aside>
            <t>
   The unique identifier validity value is sent in a UIDVALIDITY
   response code in an OK untagged response at mailbox selection time.
   If unique identifiers from an earlier session fail to persist in this
   session, the unique identifier validity value MUST <bcp14>MUST</bcp14> be greater than
   the one used in the earlier session.

   A good UIDVALIDITY value to use
   is a 32-bit representation of the current date/time when the value
   is assigned: this ensures that the value is unique and always
   increases. Another possible alternative is a global counter
   that gets incremented every time a mailbox is created.

        <list>
        <t>

            </t>

        <t indent="3">
        Note: Ideally, unique identifiers SHOULD <bcp14>SHOULD</bcp14> persist at all
        times.  Although this specification recognizes that failure
        to persist can be unavoidable in certain server
        environments, it strongly encourages message store
        implementation techniques that avoid this problem.  For
        example:

        <list style='numbers'>
            <t>
        </t>

                <ol spacing="normal" type="1"><li>
            Unique identifiers MUST <bcp14>MUST</bcp14> be strictly ascending in the
            mailbox at all times.  If the physical message store is
            re-ordered
            reordered by a non-IMAP agent, this requires that the
            unique identifiers in the mailbox <bcp14>MUST</bcp14> be regenerated, since
            the former unique identifiers are no longer strictly
            ascending as a result of the re-ordering.
            </t>

            <t> reordering.
            </li>
                  <li>
            If the message store has no mechanism to store unique
            identifiers, it must regenerate unique identifiers at
            each session, and each session must have a unique
            UIDVALIDITY value.
            </t>

            <t> Note that this situation can be very disruptive to client message caching.
            </li>
                  <li>
            If the mailbox is deleted/renamed and a new mailbox with the
            same name is created at a later date, the server must
            either keep track of unique identifiers from the
            previous instance of the mailbox, mailbox or it must assign a
            new UIDVALIDITY value to the new instance of the
            mailbox.
            </t>

            <t>
            </li>
                  <li>
            The combination of mailbox name, UIDVALIDITY, and UID
            must refer to a single single, immutable (or expunged) message on that server
            forever.  In particular, the internal date, <xref target='RFC-5322'/>
            size, RFC822.SIZE, envelope, body structure, and message texts
            (all BODY[...] fetch data items) MUST <bcp14>MUST</bcp14> never change.  This does not
            include message numbers, nor does it include attributes
            that can be set by a STORE command (e.g., (such as FLAGS). When a message
            is expunged, its UID MUST NOT <bcp14>MUST NOT</bcp14> be reused under the same
            UIDVALIDITY value.
            </t>
        </list>

        </t></list>
   </t>
            </li>
                </ol>
          </section>
          <section title='Message numbered="true" toc="default">
            <name>Message Sequence Number Message Attribute'> Attribute</name>
            <iref item='Message item="Message Sequence Number (message attribute)'/> attribute)" subitem="" primary="false"/>
            <t>
   A Message Sequence Number message sequence number is a relative position from 1 to the number of messages in the mailbox.
   This position MUST <bcp14>MUST</bcp14> be ordered by ascending unique identifier. identifiers.  As
   each new message is added, it is assigned a message sequence number
   that is 1 higher than the number of messages in the mailbox before
   that new message was added.
            </t>
            <t>
   Message sequence numbers can be reassigned during the session.  For
   example, when a message is permanently removed (expunged) from the
   mailbox, the message sequence number for all subsequent messages is
   decremented.  The number of messages in the mailbox is also
   decremented.  Similarly, a new message can be assigned a message
   sequence number that was once held by some other message prior to an
   expunge.
            </t>
            <t>
   In addition to accessing messages by relative position in the
   mailbox, message sequence numbers can be used in mathematical
   calculations.  For example, if an untagged "11 EXISTS" is received,
   and previously an untagged "8 EXISTS" was received, three new
   messages have arrived with message sequence numbers of 9, 10, and 11.
   Another
   As another example, if message 287 in a 523 message 523-message mailbox has UID
   12345, there are exactly 286 messages which that have lesser UIDs and 236
   messages which that have greater UIDs.
            </t>
          </section>
        </section>
        <section title='Flags numbered="true" toc="default">
          <name>Flags Message Attribute'> Attribute</name>
          <iref item='Flags item="Flags (message attribute)'/> attribute)" subitem="" primary="false"/>
          <t>
   A message has associated with it a list of zero or more named tokens, known as "flags". "flags", associated with it.
  A flag is set by its addition to this list, list and is cleared by its
   removal.  There are two types of flags in IMAP4rev2: system flags, flags and keywords.
   A flag of either type can also be permanent or session-only.
          </t>
          <t>
     <iref item='System item="System Flag (type of flag)'/> flag)" subitem="" primary="false"/>
   A system flag is a flag name that is pre-defined predefined in this
   specification and begins with "\".
   Certain system flags (\Deleted and \Seen) have special semantics described
   elsewhere in this document.  The currently-defined currently defined system flags are:

        <list style='hanging'>
        <t hangText='\Seen'>
          </t>

          <dl newline="false" spacing="normal" indent="14">
            <dt>\Seen</dt>
            <dd>
             <iref item='\Seen item="\Seen (system flag)'/> flag)" subitem="" primary="false"/>
           Message has been read
        </t>

        <t hangText='\Answered'>
        </dd>
            <dt>\Answered</dt>
            <dd>
             <iref item='\Answered item="\Answered (system flag)'/> flag)" subitem="" primary="false"/>
           Message has been answered
        </t>

        <t hangText='\Flagged'>
        </dd>
            <dt>\Flagged</dt>
            <dd>
            <iref item='\Flagged item="\Flagged (system flag)'/> flag)" subitem="" primary="false"/>
           Message is "flagged" for urgent/special attention
        </t>

        <t hangText='\Deleted'>
        </dd>
            <dt>\Deleted</dt>
            <dd>
             <iref item='\Deleted item="\Deleted (system flag)'/> flag)" subitem="" primary="false"/>
           Message is "deleted" for removal by later EXPUNGE
        </t>

        <t hangText='\Draft'>
        </dd>
            <dt>\Draft</dt>
            <dd>
              <iref item='\Draft item="\Draft (system flag)'/> flag)" subitem="" primary="false"/>
           Message has not completed composition (marked as a draft).
        </t>

        <t hangText='\Recent'>
        </dd>
            <dt>\Recent</dt>
            <dd>
             <iref item='\Recent item="\Recent (system flag)'/> flag)" subitem="" primary="false"/>
           This flag was in use in IMAP4rev1 and is now deprecated.
        </t>
        </list>
   </t>
        </dd>
          </dl>
          <t>
     <iref item='Keyword item="Keyword (type of flag)'/> flag)" subitem="" primary="false"/>
   A keyword is defined by the server implementation.  Keywords do not
   begin with "\".  Servers MAY <bcp14>MAY</bcp14> permit the client to define new keywords
   in the mailbox (see the description of the PERMANENTFLAGS response
   code for more information). Some keywords that start with "$"
   are also defined in this specification.
          </t>
          <t>
     <iref item='Predefined keywords'/> item="Predefined keywords" subitem="" primary="false"/>
   This document defines several keywords that were not originally defined
   in RFC 3501, <xref target="RFC3501" format="default"/> but which were found to be useful by client implementations.
   These keywords SHOULD <bcp14>SHOULD</bcp14> be supported (i.e. allowed (allowed in SEARCH, SEARCH and allowed and preserved in APPEND, COPY, and MOVE commands)
   by server implementations:

        <list style='hanging'>

        <t hangText='$Forwarded'>

          </t>
          <dl newline="true" spacing="normal">
            <dt>$Forwarded</dt>
            <dd>
             <iref item='$Forwarded item="$Forwarded (predefined flag)'/> flag)" subitem="" primary="false"/>
          Message has been forwarded to another email address, address by being
          embedded within within, or attached to a new message.  An email client
          sets this keyword when it successfully forwards the message to
          another email address.  Typical usage of this keyword is to show a
          different (or additional) icon for a message that has been forwarded.
          Once set, the flag SHOULD NOT <bcp14>SHOULD NOT</bcp14> be cleared.

          <!--///Alexey: Add RFC 5550 reference for more reading?-->
          <!--RFC 5550 has stronger requirements for support than the SHOULD above:
          IMAP4rev2 servers MUST be able to store the $Forwarded keyword.
          They MUST preserve it on the COPY or MOVE operation.  The servers MUST
          support the SEARCH KEYWORD $Forwarded.
          -->

        </t>

        <t hangText='$MDNSent'>

        </dd>
            <dt>$MDNSent</dt>
            <dd>
              <iref item='$MDNSent item="$MDNSent (predefined flag)'/> flag)" subitem="" primary="false"/>
          Message Disposition Notification <xref target='RFC8098'/> target="RFC8098" format="default"/> was generated and sent for this message.
          See <xref target="RFC3503"/> target="RFC3503" format="default"/> for more details on how this keyword is used
          and for requirements on clients and servers.
        </t>

        <t hangText='$Junk'>
        </dd>
            <dt>$Junk</dt>
            <dd>
              <iref item='$Junk item="$Junk (predefined flag)'/> flag)" subitem="" primary="false"/>
          The user (or a delivery agent on behalf of the user) may choose to mark a message as definitely
          containing junk ($Junk; see also the related keyword $NotJunk). The $Junk keyword
          can be used to mark (and potentially move/delete messages later), group mark, group, or hide undesirable messages. messages (and such messages might be moved or deleted later).
          See <xref target="IMAP-KEYWORDS-REG"/> target="IMAP-KEYWORDS-REG" format="default"/> for more information.
        </t>

        <t hangText='$NotJunk'>
        </dd>
            <dt>$NotJunk</dt>
            <dd>
              <iref item='$NotJunk item="$NotJunk (predefined flag)'/> flag)" subitem="" primary="false"/>
          The user (or a delivery agent on behalf of the user) may choose to mark a message as definitely
          not containing junk ($NotJunk; see also the related keyword $Junk). The $NotJunk keyword
          can be used to mark, group group, or show messages that the user wants to see.
          See <xref target="IMAP-KEYWORDS-REG"/> target="IMAP-KEYWORDS-REG" format="default"/> for more information.
        </t>

        <t hangText='$Phishing'>
        <iref item='$Phishing
        </dd>
            <dt>$Phishing</dt>
            <dd>
              <t><iref item="$Phishing (predefined flag)'/> flag)" subitem="" primary="false"/>
          The $Phishing keyword can be used by a delivery agent to mark a message
          as highly likely to be a phishing email. An email that’s A message that's determined to
          be a phishing email by the delivery agent should also be considered a
          junk email and have the appropriate junk filtering applied, including
          setting the $Junk flag and placing the message in the \Junk special-use mailbox (see <xref target='list-resp'/>) target="list-resp" format="default"/>),
          if available.<vspace/> available.</t>
              <t>

          If both the $Phishing flag and the $Junk flag are set, the user agent
          should display an additional warning message to the user.
        <!--
          Phrasing
          Additionally, the user agent might display a warning,
          such as something of the form "this form, "This message
          may be trying to steal your personal information" is recommended.
          -->
          Additionally information,"
          when the user agent may display a warning when clicking clicks on any hyperlinks within the message.<vspace/> message.</t>
              <t>

          The requirement for both $Phishing and $Junk to be set before a user
          agent displays a warning is for better backwards compatibility with
          existing clients that understand the $Junk flag but not the $Phishing
          flag. This is so that when an unextended client removes the $Junk flag, an
          extended client will also show the correct state.
          See <xref target="IMAP-KEYWORDS-REG"/> target="IMAP-KEYWORDS-REG" format="default"/> for more information.
              </t>

        </list>
   </t>
            </dd>
          </dl>
          <t>$Junk and $NotJunk are mutually exclusive. If more than one of
      them
      these is set for a message, the client MUST <bcp14>MUST</bcp14> treat this it as if
      none of them is set are set, and SHOULD it <bcp14>SHOULD</bcp14> unset both of them on the IMAP
      server.
          </t>
          <t>Other registered keywords can be found in the "IMAP and JMAP Keywords" registry <xref target="IMAP-KEYWORDS-REG"/>. target="IMAP-KEYWORDS-REG" format="default"/>.
   New keywords SHOULD <bcp14>SHOULD</bcp14> be registered in this registry using the procedure specified in <xref target="RFC5788"/>.</t> target="RFC5788" format="default"/>.</t>
          <t>
     <iref item='Permanent item="Permanent Flag (class of flag)'/> flag)" subitem="" primary="false"/>
            <iref item='Session item="Session Flag (class of flag)'/> flag)" subitem="" primary="false"/>
   A flag can be permanent or session-only on a per-flag basis.
   Permanent flags are those which that the client can add or remove from the
   message flags permanently; that is, concurrent and subsequent
   sessions will see any change in permanent flags.  Changes to session
   flags are valid only in that session.

<!--
        <list><t>
        Note: The \Recent system flag is a special case of a
        session flag.  \Recent can not be used as an argument in a
        STORE or APPEND command, and thus can not be changed at
        all.
        </t></list>
  -->
          </t>
        </section>
        <section title='Internal numbered="true" toc="default">
          <name>Internal Date Message Attribute'> Attribute</name>
          <iref item='Internal item="Internal Date (message attribute)'/> attribute)" subitem="" primary="false"/>
          <t>
   An Internal Date message attribute is the internal date and time of the message on the server.  This
   is not the date and time in the <xref target='RFC-5322'/> header, target="RFC5322" format="default"/> header but rather a
   date and time which that reflects when the message was received.  In
   the case of messages delivered via <xref target='SMTP'/>, target="RFC5321" format="default"/>, this is the
   date and time of final delivery of the message as defined by
   <xref target='SMTP'/>. target="RFC5321" format="default"/>.  In the case of messages delivered created by the IMAP4rev2 COPY or MOVE command, this SHOULD <bcp14>SHOULD</bcp14> be the internal date and time same as the Internal Date attribute of the source
   message.  In the case of messages delivered created by the IMAP4rev2
   APPEND command, this SHOULD <bcp14>SHOULD</bcp14> be the date and time as specified in
   the APPEND command description.  All other cases are
   implementation defined.
          </t>
        </section>
        <section title='[RFC-5322] Size numbered="true" toc="default" anchor="RFC822.SIZE_message_attribute">
          <name>RFC822.SIZE Message Attribute'> Attribute</name>
          <iref item='[RFC-5322] Size item="RFC822.SIZE (message attribute)'/> attribute)" subitem="" primary="false"/>
          <t>
   An RFC 5322 size
   RFC822.SIZE is the number of octets in the message, as message when the message
  is expressed in <xref target='RFC-5322'/> target="RFC5322" format="default"/>
   format.
   </t>
      </section>

      <section title='Envelope Structure Message Attribute'>
      <iref item='Envelope Structure (message attribute)'/>

   <t>
   An Envelope Structure is a parsed representation of This size SHOULD match the result
  of a "FETCH BODY[]" command.  If the message is internally stored in
  some other format, the server calculates the size and often stores
  it for later use to avoid the need for recalculation.
          </t>
        </section>
        <section numbered="true" toc="default">
          <name>Envelope Structure Message Attribute</name>
          <iref item="Envelope Structure (message attribute)" subitem="" primary="false"/>
          <t>
   An envelope structure is a parsed representation of the <xref target='RFC-5322'/> target="RFC5322" format="default"/> header of the message.
   Note that the IMAP Envelope envelope structure is not the same as an
   <xref target='SMTP'/> target="RFC5321" format="default"/> envelope.
          </t>
        </section>
        <section title='Body numbered="true" toc="default">
          <name>Body Structure Message Attribute'> Attribute</name>
          <iref item='Body item="Body Structure (message attribute)'/> attribute)" subitem="" primary="false"/>
          <t>
   A Body Structure body structure is a parsed representation of the <xref target='MIME-IMB'/> target="RFC2045" format="default"/> body structure
   information of the message.
          </t>
        </section>
      </section>
      <section title='Message Texts'> numbered="true" toc="default">
        <name>Message Texts</name>
        <t>
   In addition to being able to fetch the full <xref target='RFC-5322'/> target="RFC5322" format="default"/> text of a
   message, IMAP4rev2 permits the fetching of portions of the full
   message text.  Specifically, it is possible to fetch the
   <xref target='RFC-5322'/> target="RFC5322" format="default"/> message header, the <xref target='RFC-5322'/> target="RFC5322" format="default"/> message body, a <xref target='MIME-IMB'/> target="RFC2045" format="default"/>
   body part, or a <xref target='MIME-IMB'/> target="RFC2045" format="default"/> header.
        </t>
      </section>
    </section>
    <section title='State numbered="true" toc="default" anchor="state_and_flow">
      <name>State and Flow Diagram'> Diagram</name>
      <t>
   Once the connection between client and server is established, an
   IMAP4rev2 connection is in one of four states.  The initial
   state is identified in the server greeting.  Most commands are
   only valid in certain states.  It is a protocol error for the
   client to attempt a command while the connection is in an
   inappropriate state, and the server will respond with a BAD or
   NO (depending upon server implementation) command completion
   result.
      </t>
      <section title='Not numbered="true" toc="default">
        <name>Not Authenticated State'> State</name>
        <t>
   In the not authenticated state, the client MUST <bcp14>MUST</bcp14> supply
   authentication credentials before most commands will be
   permitted.  This state is entered when a connection starts
   unless the connection has been pre-authenticated.
        </t>
      </section>
      <section title='Authenticated State'> numbered="true" toc="default">
        <name>Authenticated State</name>
        <t>
   In the authenticated state, the client is authenticated and MUST <bcp14>MUST</bcp14>
   select a mailbox to access before commands that affect messages
   will be permitted.  This state is entered when a
   pre-authenticated connection starts, when acceptable
   authentication credentials have been provided, after an error in
   selecting a mailbox, or after a successful CLOSE or UNSELECT command.
        </t>
      </section>
      <section title='Selected State'> numbered="true" toc="default">
        <name>Selected State</name>
        <t>
   In a selected state, a mailbox has been selected to access.
   This state is entered when a mailbox has been successfully
   selected.
        </t>
      </section>
      <section title='Logout State'> numbered="true" toc="default">
        <name>Logout State</name>
        <t>
   In the logout state, the connection is being terminated.  This
   state can be entered as a result of a client request (via the
   LOGOUT command) or by unilateral action on the part of either
   the client or the server.
        </t>
        <t>
   If the client requests the logout state, the server MUST <bcp14>MUST</bcp14> send an
   untagged BYE response and a tagged OK response to the LOGOUT
   command before the server closes the connection; and the client
   MUST
   <bcp14>MUST</bcp14> read the tagged OK response to the LOGOUT command before
   the client closes the connection.
        </t>
        <t>
   A server SHOULD NOT <bcp14>SHOULD NOT</bcp14> unilaterally close the connection without
   first sending an untagged BYE response that contains the reason for
   having done
   doing so.  A client SHOULD NOT <bcp14>SHOULD NOT</bcp14> unilaterally close the
   connection, and instead SHOULD
   connection; instead, it <bcp14>SHOULD</bcp14> issue a LOGOUT command.  If the
   server detects that the client has unilaterally closed the
   connection, the server MAY <bcp14>MAY</bcp14> omit the untagged BYE response and
   simply close its connection.
        </t>

<figure><artwork><![CDATA[
        <artwork name="" type="" align="left" alt=""><![CDATA[
                   +----------------------+
                   |connection established|
                   +----------------------+
                              ||
                              \/
            +--------------------------------------+
            |          server greeting             |
            +--------------------------------------+
                      || (1)       || (2)        || (3)
                      \/           ||            ||
            +-----------------+    ||            ||
            |Not Authenticated|    ||            ||
            +-----------------+    ||            ||
             || (7)   || (4)       ||            ||
             ||       \/           \/            ||
             ||     +----------------+           ||
             ||     | Authenticated  |<=++       ||
             ||     +----------------+  ||       ||
             ||       || (7)   || (5)   || (6)   ||
             ||       ||       \/       ||       ||
             ||       ||    +--------+  ||       ||
             ||       ||    |Selected|==++       ||
             ||       ||    +--------+           ||
             ||       ||       || (7)            ||
             \/       \/       \/                \/
            +--------------------------------------+
            |               Logout                 |
            +--------------------------------------+
                              ||
                              \/
                +-------------------------------+
                |both sides close the connection|
                +-------------------------------+

         (1)
]]></artwork>
	<t>
Legend for the above diagram:
	</t>
<ol spacing="compact" type="(%d)">
         <li> connection without pre-authentication (OK greeting)
         (2) greeting)</li>
         <li> pre-authenticated connection (PREAUTH greeting)
         (3) greeting)</li>
         <li> rejected connection (BYE greeting)
         (4) greeting)</li>
         <li> successful LOGIN or AUTHENTICATE command
         (5) command</li>
         <li> successful SELECT or EXAMINE command
         (6) command</li>
         <li> CLOSE or UNSELECT command, unsolicited CLOSED
             response code code, or failed SELECT or EXAMINE command
         (7) LOGOUT command</li>
         <li>LOGOUT command, server shutdown, or connection closed

]]></artwork></figure> </li>
       </ol>
      </section>
    </section>
    <section title='Data Formats'> numbered="true" toc="default" anchor="data_formats">
      <name>Data Formats</name>
      <t>
   IMAP4rev2 uses textual commands and responses.  Data in
   IMAP4rev2 can be in one of several forms: atom, number, string,
   parenthesized list, or NIL.  Note that a particular data item
   may take more than one form; for example, a data item defined as
   using "astring" syntax may be either an atom or a string.
      </t>
      <section title='Atom'> numbered="true" toc="default">
        <name>Atom</name>
        <t>
   An atom consists of one or more non-special characters.
        </t>
        <section title='Sequence set numbered="true" toc="default">
          <name>Sequence Set and UID set'> Set</name>
          <t>A set of messages can be referenced by a sequence set containing either
       message sequence numbers or unique identifiers. See <xref target='IMAP-ABNF'/> target="IMAP-ABNF" format="default"/> for details.
       Sequence sets
       A sequence set can contain ranges (e.g. of sequence numbers (such as "5:50"), an enumeration of specific
       message
       sequence numbers/unique identifiers,
       a special symbol "*", numbers, or a combination of the above.
       Note that a
       A sequence set never mixes message can use the special symbol "*" to represent the maximum sequence numbers and unique identifiers number in the same representation. mailbox.
       A sequence set never contains unique identifiers.
          </t>
          <t>
       A "UID set" is similar to the sequence set of set, but uses unique identifiers; however, the "*"
       value for a identifiers instead of message sequence number numbers, and is not permitted. permitted to contain the special symbol "*".
          </t>

       <!--Only useful for IMAP extension writers?
       <t>Sequence sets can be represented as &lt;atom&gt;s</t>
       -->
     </section>
      </section>
      <section title='Number'> numbered="true" toc="default">
        <name>Number</name>
        <t>
   A number consists of one or more digit characters, characters and
   represents a numeric value.
        </t>
      </section>
      <section title='String' anchor='data-string'> anchor="data-string" numbered="true" toc="default">
        <name>String</name>
        <t>
   A string is in one of three forms: synchronizing literal, non-synchronizing literal literal, or quoted
   string.  The synchronizing literal form is the general form of string. a string, without limitation on the characters the string may include.
   The non-synchronizing literal form is also the general form, but it has a length limitation. restriction.
   The quoted string form is an alternative that avoids the overhead of
   processing a literal at the cost of literal, but has limitations of on the characters
   which that may be used.
        </t>
        <t>When the distinction between synchronizing and non-synchronizing literals is not important,
   this document only uses the term "literal".</t>
        <t>
   A synchronizing literal is a sequence of zero or more octets (including CR and
   LF), prefix-quoted with an octet count in the form of an open
   brace ("{"), the number of octets, a close brace ("}"), and a CRLF.
   In the case of synchronizing literals transmitted from server to client, the
   CRLF is immediately followed by the octet data.  In the case of
   synchronizing literals transmitted from client to server, the client MUST <bcp14>MUST</bcp14> wait
   to receive a command continuation request (described later in
   this document) before sending the octet data (and the remainder
   of the command).
        </t>
        <t>
   The non-synchronizing literal is an alternative form of synchronizing
   literal, literal and it may appear in communication be used from client to server
   instead of the synchonizing form of literal. anywhere a synchronizing literal is permitted.
   The non-synchronizing literal form
   MUST NOT
   <bcp14>MUST NOT</bcp14> be sent from server to client.
   The non-synchronizing literal is distinguished from the synchronizing literal
   by having a plus ("+") between the octet count
   and the closing brace ("}").  The server does not generate a command
   continuation request in response to a non-synchronizing literal, and
   clients are not required to wait before sending the octets of a non-
   synchronizing
   non-synchronizing literal. Unless specified otherwise specified in an IMAP extension,
   non-synchronizing literals MUST NOT <bcp14>MUST NOT</bcp14> be larger than 4096 octets.
   Any literal larger than 4096 bytes MUST <bcp14>MUST</bcp14> be sent as a synchronizing literal.
   (Non-synchronizing literals defined in this document are the same as
   non-synchronizing literals defined by the LITERAL- extension from <xref target="RFC7888"/>. target="RFC7888" format="default"/>.
   See that document for details on how to handle invalid non-synchronizing literals
   longer than 4096 octets and for interaction with other IMAP extensions.)
        </t>
        <t>
   A quoted string is a sequence of zero or more Unicode characters,
   excluding CR and LF, encoded in UTF-8, with double quote (&lt;"&gt;) characters at each
   end.
        </t>
        <t>
   The empty string is represented as "" (a quoted string
   with zero characters between double quotes), as {0} followed
   by a CRLF (a synchronizing literal with an octet count of 0) 0), or
   as {0+} followed by a CRLF (a non-synchronizing literal with an octet count of 0).

     <list><t>

        </t>
        <t indent="3">
     Note: Even if the octet count is 0, a client transmitting a
     synchronizing literal MUST <bcp14>MUST</bcp14> wait to receive a command continuation request.
     </t></list>
        </t>
        <section title='8-bit numbered="true" toc="default">
          <name>8-Bit and Binary Strings'> Strings</name>
          <t>
   8-bit textual and binary mail is supported through the use of a
   <xref target='MIME-IMB'/> target="RFC2045" format="default"/> content transfer encoding.  IMAP4rev2 implementations MAY <bcp14>MAY</bcp14>
   transmit 8-bit or multi-octet characters in literals, literals but SHOULD <bcp14>SHOULD</bcp14> do
   so only when the <xref target='CHARSET'/> target="RFC2978" format="default"/> is identified.
          </t>
          <t>
   IMAP4rev2 is compatible with <xref target='I18N-HDRS'/>. target="RFC6532" format="default"/>. As a result,
   the identified charset for header-field values with 8-bit content is
   UTF-8 <xref target='UTF-8'/>. target="RFC3629" format="default"/>. IMAP4rev2 implementations MUST <bcp14>MUST</bcp14> accept
   and MAY <bcp14>MAY</bcp14> transmit <xref target='UTF-8'/> target="RFC3629" format="default"/> text in quoted-strings as
   long as the string does not contain NUL, CR, or LF. This differs from
   IMAP4rev1 implementations.
          </t>
          <t>
   Although a BINARY content transfer encoding is defined, unencoded binary strings
   are not permitted, unless returned in a &lt;literal8> &lt;literal8&gt; in response to
   BINARY.PEEK[&lt;section-binary>]&lt;&lt;partial>> a
   BINARY.PEEK[&lt;section-binary&gt;]&lt;&lt;partial&gt;&gt; or BINARY[&lt;section-binary>]&lt;&lt;partial>> BINARY[&lt;section-binary&gt;]&lt;&lt;partial&gt;&gt;
   FETCH data item.  A "binary string" is any string with NUL
   characters.  A string with an excessive amount of CTL characters MAY <bcp14>MAY</bcp14> also be considered to be
   binary.  Unless returned in response to BINARY.PEEK[...]/BINARY[...] FETCH,
   client and server implementations MUST <bcp14>MUST</bcp14> encode binary data into a textual
   form, such as BASE64, base64, before transmitting the data.
          </t>
        </section>
      </section>
      <section title='Parenthesized List'> numbered="true" toc="default">
        <name>Parenthesized List</name>
        <t>
   Data structures are represented as a "parenthesized list"; a sequence
   of data items, delimited by space, and bounded at each end by
   parentheses.  A parenthesized list can contain other parenthesized
   lists, using multiple levels of parentheses to indicate nesting.
        </t>
        <t>
   The empty list is represented as () -- a parenthesized list with no
   members.
        </t>
      </section>
      <section title='NIL'> numbered="true" toc="default">
        <name>NIL</name>
        <t>
   The special form "NIL" represents the non-existence of a particular
   data item that is represented as a string or parenthesized list, as
   distinct from the empty string "" or the empty parenthesized list ().

        <list><t>

        </t>
        <aside><t>
        Note: NIL is never used for any data item which that takes the
        form of an atom.  For example, a mailbox name of "NIL" is a
        mailbox named NIL as opposed to a non-existent mailbox
        name.  This is because mailbox uses "astring" syntax syntax, which
        is an atom or a string.  Conversely, an addr-name of NIL is
        a non-existent personal name, because addr-name uses
        "nstring" syntax syntax, which is NIL or a string, but never an
        atom.
        </t></list>
   </t>

<figure><artwork>
   Examples:

   The
        atom.</t>
        </aside>
       <t>
       Examples:</t>

<t>The following LIST response: response:</t>

<sourcecode name="" type="">
  * LIST () "/" NIL

   is
</sourcecode>

<t>is equivalent to: to:</t>

 <sourcecode name="" type="">
  * LIST () "/" "NIL"
</sourcecode>

<t>
  as LIST response ABNF is using "astring" for mailbox name.
</t>
<t>
  However, the following response response:
</t>

 <sourcecode name="" type="">
  * FETCH 1 (BODY[1] NIL)

   is
 </sourcecode>

<t>is not equivalent to: to:</t>

<sourcecode name="" type="">
  * FETCH 1 (BODY[1] "NIL")
</sourcecode>
<t>
   The former means indicates absence of the body part, while the latter
   means that it contains literal sequence of a string with the three characters "NIL".
</artwork></figure> "NIL".</t>

      </section>
    </section>
    <section title='Operational Considerations'> numbered="true" toc="default" anchor="operational_considerations">
      <name>Operational Considerations</name>
      <t>
   The following rules are listed here to ensure that all IMAP4rev2
   implementations interoperate properly.
      </t>
      <section title='Mailbox Naming' anchor='mailbox-naming'> anchor="mailbox-naming" numbered="true" toc="default">
        <name>Mailbox Naming</name>
        <t>
   In IMAP4rev2, Mailbox mailbox names are encoded in Net-Unicode <xref
   target="NET-UNICODE"/> target="RFC5198" format="default"/> (this differs from IMAP4rev1). Client
   implementations MAY <bcp14>MAY</bcp14> attempt to create Net-Unicode mailbox names, names and
   MUST
   <bcp14>MUST</bcp14> interpret any 8-bit mailbox names returned by LIST as
   <xref target="NET-UNICODE"/>. target="RFC5198" format="default"/>. Server implementations MUST <bcp14>MUST</bcp14> prohibit
   the creation of 8-bit mailbox names that do not comply with
   Net-Unicode. However, servers MAY <bcp14>MAY</bcp14> accept a de-normalized denormalized UTF-8
   mailbox name and convert it to Unicode normalization form "NFC" Normalization Form C (NFC)
   (as per Net-Unicode requirements) prior to mailbox creation.
   Servers that choose to accept such de-normalized denormalized UTF-8 mailbox
   names MUST <bcp14>MUST</bcp14> accept them in all IMAP commands that have a mailbox name parameter.
   In particular particular, SELECT &lt;name&gt; must open the same mailbox that
   was successfully created with CREATE &lt;name&gt;, even if &lt;name&gt;
   is a de-normalized denormalized UTF-8 mailbox name.
        </t>
        <t>
   The case-insensitive mailbox name INBOX is a special name reserved to
   mean "the primary mailbox for this user on this server".  (Note that
   this special name may might not exist on some servers for some users, for example example,
   if the user has no access to personal namespace.)  The
   interpretation of all other names is implementation-dependent. implementation dependent.
        </t>
        <t>
   In particular, this specification takes no position on case
   sensitivity in non-INBOX mailbox names.  Some server implementations
   are fully case-sensitive case sensitive in ASCII range; others preserve the case of a newly-created newly created
   name but otherwise are case-insensitive; case insensitive; and yet others coerce names
   to a particular case.  Client implementations must be able to interact with any
   of these.
        </t>
        <t>
   There are certain client considerations when creating a new mailbox
   name:

        <list style='numbers'>
         <t>

        </t>
        <ol spacing="normal" type="1"><li>
         Any character which that is one of the atom-specials (see the Formal Syntax "Formal Syntax"
         in <xref target='IMAP-ABNF'/>) target="IMAP-ABNF" format="default"/>) will require that the mailbox name be represented as a
         quoted string or literal.
         </t>

         <t>
         </li>
          <li>
         CTL and other non-graphic characters are difficult to represent
         in a user interface and are best avoided. Servers MAY <bcp14>MAY</bcp14> refuse to
         create mailbox names containing Unicode CTL characters.
         </t>

         <t>
         </li>
          <li>
         Although the list-wildcard characters ("%" and "*") are valid
         in a mailbox name, it is difficult to use such mailbox names
         with the LIST command due to the conflict with
         wildcard interpretation.
         </t>

         <t>
         </li>
          <li>
         Usually, a character (determined by the server implementation)
         is reserved to delimit levels of hierarchy.
         </t>

         <t>
         </li>
          <li>
         Two characters, "#" and "&amp;", have meanings by convention, convention and
         should be avoided except when used in that convention. See
         <xref target='namespace-convention'/> target="namespace-convention" format="default"/> and <xref target='mailbox-i18n'/> target="mailbox-i18n" format="default"/>, respectively.
         </t>

         </list>
   </t>
         </li>
        </ol>
        <section title='Mailbox numbered="true" toc="default">
          <name>Mailbox Hierarchy Naming'> Naming</name>
          <t>
   If it is desired to export hierarchical mailbox names, mailbox names
   MUST
   <bcp14>MUST</bcp14> be left-to-right hierarchical hierarchical, using a single ASCII character to
   separate levels of hierarchy.  The same hierarchy separator character
   is used for all levels of hierarchy within a single name.
          </t>
        </section>
        <section title='Namespaces'>

        <t>
        Personal Namespace: A numbered="true" toc="default">
          <name>Namespaces</name>
	    <dl spacing="normal" newline="true">
        <dt>Personal Namespace:</dt><dd>A namespace that the server considers within the
        personal scope of the authenticated user on a particular connection.
        Typically, only the authenticated user has access to mailboxes in
        their Personal Namespace. It is the part of the namespace that
        belongs to the user that and is allocated for mailboxes. If an INBOX
        exists for a user, it MUST <bcp14>MUST</bcp14> appear within the user's personal
        namespace. Personal
        Namespace.  In the typical case, there SHOULD <bcp14>SHOULD</bcp14> be only one Personal
        Namespace per user on a server.
        </t>

        <t>
          </dd>
          <dt>
        Other Users' Namespace: A Namespace:</dt><dd>A namespace that consists of mailboxes from
        the Personal Namespaces of other users.  To access mailboxes in the
        Other Users' Namespace, the currently authenticated user MUST <bcp14>MUST</bcp14> be
        explicitly granted access rights.  For example, it is common for a
        manager to grant to their administrative support staff access rights to their mailbox.
        In the typical case, there SHOULD <bcp14>SHOULD</bcp14> be only one Other Users' Namespace
        per user on a server.
        </t>

        <t>
          </dd>
          <dt>
        Shared Namespace: A Namespace:</dt><dd>A namespace that consists of mailboxes that are
        intended to be shared amongst users and do not exist within a user's
        Personal Namespace.
        </t> Namespace.</dd></dl>
          <t>
        The namespaces a server uses MAY <bcp14>MAY</bcp14> differ on a per-user basis.
          </t>
          <section title='Historic anchor="namespace-convention" numbered="true" toc="default">
            <name>Historic Mailbox Namespace Naming Convention' anchor='namespace-convention'> Convention</name>
            <t>
   By convention, the first hierarchical element of any mailbox name
   which
   that begins with "#" identifies the "namespace" of the remainder of
   the name.  This makes it possible to disambiguate between different
   types of mailbox stores, each of which have their own namespaces.

        <list><t>

            </t>
            <t indent="3">
        For example, implementations which that offer access to USENET
        newsgroups MAY <bcp14>MAY</bcp14> use the "#news" namespace to partition the
        USENET newsgroup namespace from that of other mailboxes.
        Thus, the comp.mail.misc newsgroup would have a mailbox
        name of "#news.comp.mail.misc", and the name
        "comp.mail.misc" can refer to a different object (e.g., a
        user's private mailbox).
        </t></list>
            </t>
            <t>
   Namespaces that include the "#" character are not IMAP URL <xref target="IMAP-URL"/> target="RFC5092" format="default"/> friendly
   requiring
   and require the "#" character to be represented as %23 when within URLs.
   As such, server implementors MAY <bcp14>MAY</bcp14> instead consider using namespace prefixes that do not contain
   the "#" character.
            </t>
          </section>
          <section title='Common namespace models'> numbered="true" toc="default">
            <name>Common Namespace Models</name>
            <t>
        The previous version of this protocol did not define a default server namespace.
        Two common namespace models have evolved:
            </t>
            <t>
        The "Personal Mailbox" model, in which the default namespace that is
        presented consists of only the user's personal mailboxes. To access
        shared mailboxes, the user must use an escape mechanism to reach
        another namespace.
            </t>
            <t>
        The "Complete Hierarchy" model, in which the default namespace that
        is presented includes the user's personal mailboxes along with any
        other mailboxes they have access to.
            </t>
          </section>
        </section>
      </section>
      <section title='Mailbox numbered="true" toc="default">
        <name>Mailbox Size and Message Status Updates'> Updates</name>
        <t>
   At any time, a server can send data that the client did not request.
   Sometimes, such behavior is required by this specification and/or extensions.
   For example, agents other than
   the server MAY may add messages to the mailbox (e.g., new message
   delivery), delivery);
   change the flags of the messages in the mailbox (e.g.,
   simultaneous access to the same mailbox by multiple agents), agents); or even
   remove messages from the mailbox.  A server MUST <bcp14>MUST</bcp14> send mailbox size
   updates automatically if a mailbox size change is observed during the
   processing of a command.  A server SHOULD <bcp14>SHOULD</bcp14> send message flag updates
   automatically, without requiring the client to request such updates
   explicitly.
        </t>
        <t>
   Special rules exist for server notification of a client about the
   removal of messages to prevent synchronization errors; see the
   description of the EXPUNGE response (<xref target='expunge-response'/>) target="expunge-response" format="default"/>) for more detail.  In particular,
   it is NOT permitted to send an EXISTS response that would reduce the
   number of messages in the mailbox; only the EXPUNGE response can do
   this.
        </t>
        <t>
   Regardless of what implementation decisions a client makes on
   remembering data from the server, a client implementation MUST <bcp14>MUST</bcp14> remember
   mailbox size updates.  It MUST NOT <bcp14>MUST NOT</bcp14> assume that any command after the
   initial mailbox selection will return the size of the mailbox.
        </t>
      </section>
      <section title='Response when no numbered="true" toc="default">
        <name>Response When No Command in Progress'> Progress</name>
        <t>
   Server implementations are permitted to send an untagged response
   (except for EXPUNGE) while there is no command in progress.  Server
   implementations that send such responses MUST <bcp14>MUST</bcp14> deal with flow control
   considerations.  Specifically, they MUST <bcp14>MUST</bcp14> either (1) verify that the
   size of the data does not exceed the underlying transport's available
   window size, size or (2) use non-blocking writes.
        </t>
      </section>
      <section title='Autologout Timer'> numbered="true" toc="default">
        <name>Autologout Timer</name>
        <t>
   If a server has an inactivity autologout timer that applies to
   sessions after authentication, the duration of that
   timer MUST <bcp14>MUST</bcp14> be at least 30 minutes.  The receipt of any command from
   the client during that interval resets the
   autologout timer.
        </t>
        <t>Note that this specification doesn't have any restrictions
   on an autologout timer used before successful client authentication.
   In particular, servers are allowed to use a shortened pre-authentication
   timer to protect themselves from Denial of Service Denial-of-Service attacks.</t>
      </section>
      <section title='Multiple anchor="pipelining" numbered="true" toc="default">
        <name>Multiple Commands in Progress (Command Pipelining)' anchor='pipelining'> Pipelining)</name>
        <t>
   The client MAY <bcp14>MAY</bcp14> send another command without waiting for the
   completion result response of a command, subject to ambiguity rules
   (see below) and flow control constraints on the underlying data
   stream.  Similarly, a server MAY <bcp14>MAY</bcp14> begin processing another command
   before processing the current command to completion, subject to
   ambiguity rules.  However, any command continuation request responses
   and command continuations MUST <bcp14>MUST</bcp14> be negotiated before any subsequent
   command is initiated.
        </t>
        <t>
   The exception is if an ambiguity would result because of a command
   that would affect the results of other commands.
   <!--///Alexey: I think the following MUST NOT is nonsense and should be removed.
   The client can always pipeline several commands, because the server is required
   to process them in order.-->
<!--
   Clients MUST NOT
   send multiple commands without waiting if an ambiguity would result.
-->
   If the server detects a possible ambiguity, it MUST <bcp14>MUST</bcp14> execute commands
   to completion in the order given by the client.
        </t>

   <!--///Alexey: This is not a great example: if the client wants to use
   result of one command to generate another command, it is obvious it can't
   generate and pipeline both commands at the same time. However, if the client
   wants to override flags unconditionally, it can clearly do that.
   This also contadicts one of the examples below:-->
   <t>
   The most obvious example of ambiguity is when a command would affect
   the results of another command, e.g., command.  One example is a FETCH of a message's that would cause \Seen flags
   to be set and a STORE of that same message's flags. SEARCH UNSEEN command.
        </t>
        <t>
   A non-obvious ambiguity occurs with commands that permit an untagged
   EXPUNGE response (commands other than FETCH, STORE, and SEARCH),
   since an untagged EXPUNGE response can invalidate sequence numbers in
   a subsequent command.  This is not a problem for FETCH, STORE, or
   SEARCH commands because servers are prohibited from sending EXPUNGE
   responses while any of those commands are in progress.  Therefore, if
   the client sends any command other than FETCH, STORE, or SEARCH, it
   MUST
   <bcp14>MUST</bcp14> wait for the completion result response before sending a command
   with message sequence numbers.

        <list><t>

        </t>
        <t indent="3">
        Note: EXPUNGE responses are permitted while UID FETCH,
        UID STORE, and UID SEARCH are in progress.  If the client
        sends a UID command, it MUST <bcp14>MUST</bcp14> wait for a completion result
        response before sending a command which that uses message
        sequence numbers (this may include UID SEARCH).  Any
        message sequence numbers in an argument to UID SEARCH
        are associated with messages prior to the effect of any
        untagged EXPUNGE responses returned by the UID SEARCH.
        </t></list>
        </t>
        <t>
   For example, the following non-waiting command sequences are invalid:

      <list>
      <t>FETCH

        </t>
        <ul empty="true" spacing="normal">
          <li>FETCH + NOOP + STORE</t>
      <t>STORE STORE</li>
          <li>STORE + COPY + FETCH</t>
      <t>COPY FETCH</li>
          <li>COPY + COPY</t>
      </list>
   </t> COPY</li>
        </ul>
        <t>
   The following are examples of valid non-waiting command sequences:

      <list>
      <t>FETCH
        </t>
        <ul empty="true" spacing="normal">
          <li>FETCH + STORE + SEARCH + NOOP</t>
      <t>STORE NOOP</li>
          <li>STORE + COPY + EXPUNGE</t> EXPUNGE</li>
        </ul>

          <t>UID SEARCH + UID SEARCH may be valid or invalid as a non-waiting
      command sequence, depending upon whether or not the second UID
      SEARCH contains message sequence numbers.
      </t>
      </list>
   </t> numbers.</t>

        <t>
   Use of a SEARCH result variable (see <xref target="search-save"/>) target="search-save" format="default"/>) creates
   direct dependency between two commands. See <xref target='search-save-pipelining'/> target="search-save-pipelining" format="default"/>
   for more considerations about pipelining such dependent commands.
        </t>
      </section>
    </section>
    <section title='Client Commands'> numbered="true" toc="default" anchor="client_commands">
      <name>Client Commands</name>
      <t>
   IMAP4rev2 commands are described in this section.  Commands are
   organized by the state in which the command is permitted.  Commands
   which
   that are permitted in multiple states are listed in the minimum
   permitted state (for example, commands valid in authenticated and
   selected state states are listed in the authenticated state commands).
      </t>
      <t>
   Command arguments, identified by "Arguments:" in the command
   descriptions below, are described by function, not by syntax.  The
   precise syntax of command arguments is described in the Formal Syntax "Formal Syntax"
   (<xref target='IMAP-ABNF'/>). target="IMAP-ABNF" format="default"/>).
      </t>
      <t>
   Some commands cause specific server responses to be returned; these
   are identified by "Responses:" in the command descriptions below.
   See the response descriptions in the Responses section "Responses" (<xref target='server-responses'/>) target="server-responses" format="default"/>) for
   information on these responses, responses and the Formal Syntax in "Formal Syntax" (<xref target='IMAP-ABNF'/>) target="IMAP-ABNF" format="default"/>) for the
   precise syntax of these responses.  It is possible for server data to
   be transmitted as a result of any command.  Thus, commands that do
   not specifically require server data specify "no specific responses
   for this command" instead of "none".
      </t>
      <t>
   The "Result:" in the command description refers to the possible
   tagged status responses to a command, command and any special interpretation
   of these status responses.
      </t>
      <t>
   The state of a connection is only changed by successful commands
   which
   that are documented as changing state.  A rejected command (BAD
   response) never changes the state of the connection or of the
   selected mailbox.  A failed command (NO response) generally does not
   change the state of the connection or of the selected mailbox; mailbox, with the
   exception being of the SELECT and EXAMINE commands.
      </t>
      <section title='Client numbered="true" toc="default">
        <name>Client Commands - Any State'> State</name>
        <t>
   The following commands are valid in any state: CAPABILITY, NOOP, and
   LOGOUT.
        </t>
        <section title='CAPABILITY Command' anchor="capability-command">
      <iref item='CAPABILITY (command)'/>

   <t>
   <list style='hanging' hangIndent='12'>
   <t hangText='Arguments:'>none</t>

   <t hangText='Responses:'>REQUIRED anchor="capability-command" numbered="true" toc="default">
          <name>CAPABILITY Command</name>

          <iref item="CAPABILITY (command)" subitem="" primary="false"/>
          <dl newline="false" spacing="normal" indent="14">
            <dt>Arguments:</dt>
            <dd>none</dd>
            <dt>Responses:</dt>
            <dd>
	    <dl spacing="compact">
	      <dt><bcp14>REQUIRED</bcp14> untagged response: CAPABILITY</t>

   <t hangText='Result:'>OK - capability completed<vspace/>
               BAD - arguments invalid</t>
   </list>
   </t> response:</dt><dd>CAPABILITY</dd>
	    </dl>
	    </dd>
            <dt>Result:</dt>
            <dd>
	       <dl spacing="compact">
              <dt>OK -</dt><dd>capability completed</dd>
              <dt>BAD -</dt><dd>arguments invalid</dd>
               </dl>
	    </dd>
          </dl>
          <t>
      The CAPABILITY command requests a listing of capabilities
      (e.g.
      (e.g., extensions and/or modifications of server behaviour) behavior) that the
      server supports.  The server MUST <bcp14>MUST</bcp14> send a single untagged
      CAPABILITY response with "IMAP4rev2" as one of the listed
      capabilities before the (tagged) OK response.
          </t>
          <t>
      A capability name which that begins with "AUTH=" indicates that the
      server supports that particular authentication mechanism as defined in the Simple Authentication and Security Layer (SASL) <xref target='SASL'/>. target="RFC4422" format="default"/>.
      All such names are, by definition, part of this specification.
    <!--///Alexey: If the following text is needed, it is probably should be done in SASL update?
      For example, the authorization capability for an experimental
      "blurdybloop" authenticator would be "AUTH=XBLURDYBLOOP" and not
      "XAUTH=BLURDYBLOOP" or "XAUTH=XBLURDYBLOOP".
      -->
          </t>
          <t>
      Other capability names refer to extensions, revisions, or
      amendments to this specification.  See the documentation of the
      CAPABILITY response in <xref target='capability-resp'/> target="capability-resp" format="default"/> for additional information.
      If IMAP4rev1 capability is not advertised, no capabilities, beyond the base IMAP4rev2 set
      defined in this specification, are enabled without explicit client action to invoke the capability.
      If both IMAP4rev1 and IMAP4rev2 capabilities are advertised, no capabilities,
      beyond the base IMAP4rev1 set specified in RFC 3501, <xref target="RFC3501" format="default"/>, are enabled without explicit
      client action to invoke the capability.
          </t>
          <t>
     Client and server implementations MUST <bcp14>MUST</bcp14> implement the STARTTLS <xref target='STARTTLS'/> (<xref target="STARTTLS" format="default"/>) and
     LOGINDISABLED capabilities on cleartext ports. Client and server implementations MUST <bcp14>MUST</bcp14>
     also implement AUTH=PLAIN (described in <xref target='PLAIN'/>) target="RFC4616" format="default"/>)
     capability on both cleartext and Implicit TLS ports.
     See the Security Considerations (<xref target='sec-cons'/>) target="sec-cons" format="default"/>) for important information.
          </t>
          <t>
      Unless specified otherwise, otherwise specified, all registered extensions to IMAP4rev1
      are also valid extensions to IMAP4rev2.
          </t>

  <!--
   <t>
      See the section entitled "Client Commands - Experimental/Expansion"
      for information about the form of site or
      implementation-specific capabilities.
   </t>
   -->

<figure><artwork>
   Example:

 <t>Example:</t>
<sourcecode type="">
  C: abcd CAPABILITY
  S: * CAPABILITY IMAP4rev2 STARTTLS AUTH=GSSAPI
   LOGINDISABLED
  S: abcd OK CAPABILITY completed
  C: efgh STARTTLS
  S: efgh OK STARTLS STARTTLS completed
  &lt;TLS negotiation, further commands are under [TLS] layer> TLS layer&gt;
  C: ijkl CAPABILITY
  S: * CAPABILITY IMAP4rev2 AUTH=GSSAPI AUTH=PLAIN
  S: ijkl OK CAPABILITY completed
</artwork></figure>
</sourcecode>
        </section>
        <section title='NOOP Command'>
      <iref item='NOOP (command)'/>

   <t>
   <list style='hanging' hangIndent='12'>
   <t hangText='Arguments:'>none</t>

   <t hangText='Responses:'>no numbered="true" toc="default">
          <name>NOOP Command</name>
         <iref item="NOOP (command)" subitem="" primary="false"/>
          <dl newline="false" spacing="normal" indent="14">
            <dt>Arguments:</dt>
            <dd>none</dd>
            <dt>Responses:</dt>
              <dd>no specific responses for this command (but see below)</t>

   <t hangText='Result:'>OK - noop completed<vspace/> below)</dd>
            <dt>Result:</dt>
            <dd>
	      <dl spacing="compact">
              <dt>OK -</dt><dd>noop completed</dd>
              <dt>
               BAD - command -</dt><dd>command unknown or arguments invalid</t>
   </list>
   </t> invalid</dd>
             </dl>
            </dd>
          </dl>
          <t>
      The NOOP command always succeeds.  It does nothing.
          </t>
          <t>
      Since any command can return a status update as untagged data, the
      NOOP command can be used as a periodic poll for new messages or
      message status updates during a period of inactivity (the IDLE
      command
      command; see <xref target="idle"/> target="idle" format="default"/>) should be used instead of NOOP if real-time updates
      to mailbox state are desirable).  The NOOP command can also be used
      to reset any inactivity autologout timer on the server.
          </t>

<figure><artwork>
   Example:
	  <t>Example:</t>
<sourcecode type="">
  C: a002 NOOP
  S: a002 OK NOOP completed
     . . .
  C: a047 NOOP
  S: * 22 EXPUNGE
  S: * 23 EXISTS
  S: * 14 FETCH (UID 1305 FLAGS (\Seen \Deleted))
  S: a047 OK NOOP completed
</artwork></figure>
</sourcecode>
        </section>
        <section title='LOGOUT Command'>
      <iref item='LOGOUT (command)'/>

   <t>
   <list style='hanging' hangIndent='12'>
   <t hangText='Arguments:'>none</t>

   <t hangText='Responses:'>REQUIRED numbered="true" toc="default">
          <name>LOGOUT Command</name>
        <iref item="LOGOUT (command)" subitem="" primary="false"/>
          <dl newline="false" spacing="normal" indent="14">
            <dt>Arguments:</dt>
            <dd>none</dd>
            <dt>Responses:</dt>
            <dd>
            <dl spacing="compact">
	      <dt><bcp14>REQUIRED</bcp14> untagged response: BYE</t>

   <t hangText='Result:'>OK - logout completed<vspace/> response:</dt><dd>BYE</dd>
	    </dl>
	    </dd>
            <dt>Result:</dt>
            <dd>
	      <dl spacing="compact">
              <dt>OK -</dt><dd>logout completed</dd>
              <dt>
               BAD - command -</dt><dd>command unknown or arguments invalid</t>
   </list>
   </t> invalid</dd>
               </dl>
            </dd>
          </dl>
          <t>
      The LOGOUT command informs the server that the client is done with
      the connection.  The server MUST <bcp14>MUST</bcp14> send a BYE untagged response
      before the (tagged) OK response, and then close the network
      connection.
          </t>

<figure><artwork>
   Example:
<t>Example:</t>
<sourcecode type="">
  C: A023 LOGOUT
  S: * BYE IMAP4rev2 Server logging out
  S: A023 OK LOGOUT completed
  (Server and client then close the connection)
</artwork></figure>
</sourcecode>
        </section>
      </section>
      <section title='Client numbered="true" toc="default">
        <name>Client Commands - Not Authenticated State'> State</name>
        <t>
   In the not authenticated state, the AUTHENTICATE or LOGIN command
   establishes authentication and enters the authenticated state.  The
   AUTHENTICATE command provides a general mechanism for a variety of
   authentication techniques, privacy protection, and integrity
   checking;
   checking, whereas the LOGIN command uses a traditional conventional user name and
   plaintext password pair and has no means of establishing privacy
   protection or integrity checking.
        </t>
        <t>
   The STARTTLS command is an alternative form of establishing session
   privacy protection and integrity checking, checking but does not by itself establish
   authentication or enter the authenticated state.
        </t>
        <t>
   Server implementations MAY <bcp14>MAY</bcp14> allow access to certain mailboxes without
   establishing authentication.
   This can be done by means of the
   ANONYMOUS <xref target='SASL'/> target="RFC4422" format="default"/> authenticator described in <xref target='ANONYMOUS'/>. target="RFC4505" format="default"/>.  An older
   convention is a LOGIN command using the userid "anonymous"; in this
   case, a password is required although the server may choose to accept
   any password.  The restrictions placed on anonymous users are
   implementation-dependent.
   implementation dependent.
        </t>
        <t>
   Once authenticated (including as anonymous), it is not possible to
   re-enter not authenticated state.
        </t>
        <t>
   In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
   the following commands are valid in the not authenticated state:
   STARTTLS, AUTHENTICATE AUTHENTICATE, and LOGIN.  See the Security Considerations
   (<xref target='sec-cons'/>) target="sec-cons" format="default"/>) for important information about these commands.
        </t>
        <section title='STARTTLS Command' anchor='STARTTLS'>
      <iref item='STARTTLS (command)'/>

   <t>
   <list style='hanging' hangIndent='12'>
   <t hangText='Arguments:'>none</t>

   <t hangText='Responses:'>no anchor="STARTTLS" numbered="true" toc="default">
          <name>STARTTLS Command</name>
         <iref item="STARTTLS (command)" subitem="" primary="false"/>
          <dl newline="false" spacing="normal" indent="14">
            <dt>Arguments:</dt>
            <dd>none</dd>
            <dt>Responses:</dt>
            <dd>no specific response for this command</t>

   <t hangText='Result:'>OK - starttls command</dd>
            <dt>Result:</dt>
            <dd>
	      <dl spacing="compact">
              <dt>OK -</dt><dd>starttls completed, begin TLS negotiation<vspace/>
               NO - TLS negotiation</dd>
              <dt>NO -</dt><dd>TLS negotiation can't be initiated, due to server configuration error<vspace/>
               BAD - STARTTLS error</dd>
              <dt>BAD -</dt><dd>STARTTLS received after a successful TLS negotiation or arguments invalid</t>
   </list>
   </t> invalid</dd>
          </dl>
	  </dd>
          </dl>
          <t>
     Note that the STARTTLS command is available only on cleartext ports.
     The server MUST <bcp14>MUST</bcp14> always respond with a tagged BAD response when the STARTTLS command is received on an Implicit TLS port.
          </t>
          <t>
      A <xref target="TLS-1.3">TLS</xref> target="RFC8446" format="default">TLS</xref> negotiation begins immediately after the CRLF at the end
      of the tagged OK response from the server.  Once a client issues a
      STARTTLS command, it MUST NOT <bcp14>MUST NOT</bcp14> issue further commands until a
      server response is seen and the TLS negotiation is complete.
      Some past server implementation implementations incorrectly implemented STARTTLS processing and
      are known to contain STARTTLS plaintext command injection vulnerability <xref target='CERT-555316'/>. target="CERT-555316" format="default"/>.
      In order to avoid this vulnerability, server implementations MUST <bcp14>MUST</bcp14> do one of the following
      If
      if any data is received in the same TCP buffer after the CRLF that starts the STARTTLS command:
        <list style='numbers'>
          <t>
          </t>
          <ol spacing="normal" type="1"><li>
          Extra data from the TCP buffer is interpreted as the beginning of the TLS handshake.
          (If the data is in cleartext, this will result in the TLS handshake failing.)
          </t>

          <t>
          </li>
            <li>
          Extra data from the TCP buffer is thrown away.
          </t>

        </list>
          </li>
          </ol>
          <t>
     Note that the first option is friendlier to clients that pipeline the beginning of
     the STARTTLS command with TLS handshake data.
          </t>
          <t>
      After successful TLS negotiation negotiation, the server remains in the non-authenticated state,
      even if client credentials are supplied during the TLS negotiation.  This does
      not preclude an authentication mechanism such as EXTERNAL (defined
      in <xref target='SASL'/>) target="RFC4422" format="default"/>) from using client identity determined by the TLS
      negotiation.
          </t>
          <t>
      Once TLS has been started, the client MUST <bcp14>MUST</bcp14> discard cached
      information about server capabilities and SHOULD re-issue <bcp14>SHOULD</bcp14> reissue the
      CAPABILITY command.  This is necessary to protect against man-in-
      the-middle active attacks which
      that alter the capabilities list prior to
      STARTTLS.  The server MAY <bcp14>MAY</bcp14> advertise different capabilities, and capabilities and,
      in particular SHOULD NOT particular, <bcp14>SHOULD NOT</bcp14> advertise the STARTTLS capability, after
      a successful STARTTLS command.
          </t>

<figure><artwork>
   Example:

  <t>Example:</t>
  <sourcecode type="">
   C: a001 CAPABILITY
   S: * CAPABILITY IMAP4rev2 STARTTLS LOGINDISABLED
   S: a001 OK CAPABILITY completed
   C: a002 STARTTLS
   S: a002 OK Begin TLS negotiation now
   &lt;TLS negotiation, further commands are under TLS layer> layer&gt;
   C: a003 CAPABILITY
   S: * CAPABILITY IMAP4rev2 AUTH=PLAIN
   S: a003 OK CAPABILITY completed
   C: a004 AUTHENTICATE PLAIN dGVzdAB0ZXN0AHRlc3Q=
   S: a004 OK Success (tls protection)
</artwork></figure>
</sourcecode>
        </section>
        <section title='AUTHENTICATE Command' anchor='authenticate'>
      <iref item='AUTHENTICATE (command)'/>

   <t>
   <list style='hanging' hangIndent='12'>
   <t hangText='Arguments:'>SASL anchor="authenticate" numbered="true" toc="default">
          <name>AUTHENTICATE Command</name>
          <iref item="AUTHENTICATE (command)" subitem="" primary="false"/>

       <dl newline="false" spacing="normal" indent="14">
            <dt>Arguments:</dt>
            <dd>
	    <t>SASL authentication mechanism name<vspace/>
                            OPTIONAL name</t>
            <t> <bcp14>OPTIONAL</bcp14> initial response</t>

   <t hangText='Responses:'>continuation
            </dd>
            <dt>Responses:</dt>
            <dd>continuation data can be requested</t>

   <t hangText='Result:'>OK - authenticate requested</dd>
            <dt>Result:</dt>
            <dd>
	      <dl spacing="compact">
              <dt>OK -</dt><dd>authenticate completed, now in authenticated state<vspace/>
               NO - authenticate state</dd>
              <dt>NO -</dt><dd>authenticate failure: unsupported authentication<vspace/> authentication mechanism, credentials rejected<vspace/> rejected</dd>
              <dt>
               BAD - command -</dt><dd>command unknown or arguments invalid,<vspace/> invalid,
                    authentication exchange cancelled</t>
   </list>
   </t> canceled</dd>
            </dl>
	   </dd>
           </dl>

          <t>
      The AUTHENTICATE command indicates a <xref target='SASL'/> target="RFC4422" format="default"/> authentication
      mechanism to the server.  If the server supports the requested
      authentication mechanism, it performs an authentication protocol
      exchange to authenticate and identify the client.  It MAY <bcp14>MAY</bcp14> also
      negotiate an OPTIONAL <bcp14>OPTIONAL</bcp14> security layer for subsequent protocol
      interactions.  If the requested authentication mechanism is not
      supported, the server SHOULD <bcp14>SHOULD</bcp14> reject the AUTHENTICATE command by
      sending a tagged NO response.
          </t>
          <t>

      The AUTHENTICATE command supports the optional "initial response"
      feature defined in Section 5.1 of <xref target='SASL'/>. target="RFC4422" sectionFormat="of" section="4"/>.  The client
      doesn't need to use it. If a SASL mechanism supports "initial response",
      but it is not specified by the client, the server handles this it as specified
      in Section 3 of <xref target='SASL'/>. target="RFC4422" sectionFormat="of" section="3"/>.
          </t>
          <t>
      The service name specified by this protocol's profile of <xref target='SASL'/> target="RFC4422" format="default"/> is
      "imap".
          </t>
          <t>
      The authentication protocol exchange consists of a series of
      server challenges and client responses that are specific to the
      authentication mechanism.  A server challenge consists of a
      command continuation request response with the "+" token followed
      by a BASE64 encoded base64-encoded (see Section 4 of <xref target="RFC4648"/>) target="RFC4648" sectionFormat="of" section="4"/>) string.
      The client response consists of a
      single line consisting of a BASE64 encoded base64-encoded string.  If the client
      wishes to cancel an authentication exchange, it issues a line
      consisting of a single "*".  If the server receives such a
      response, or if it receives an invalid BASE64 base64 string (e.g. (e.g.,
      characters outside the BASE64 alphabet, base64 alphabet or non-terminal "="), it
      MUST
      <bcp14>MUST</bcp14> reject the AUTHENTICATE command by sending a tagged BAD
      response.
          </t>
          <t>
      As with any other client response, the initial response MUST <bcp14>MUST</bcp14>
      be encoded as BASE64. base64.
      It also MUST <bcp14>MUST</bcp14> be transmitted outside of a quoted string or literal.
      To send a zero-length initial response, the client MUST <bcp14>MUST</bcp14> send
      a single pad character ("=").  This indicates that the response is present,
      but it is a zero-length string.
          </t>
          <t>
     When decoding the BASE64 base64 data in the initial response,
     decoding errors MUST <bcp14>MUST</bcp14> be treated as in any normal SASL client response,
     i.e.
     i.e., with a tagged BAD response.  In particular, the
     server should check for any characters not explicitly allowed by the
     BASE64
     base64 alphabet, as well as any sequence of BASE64 base64 characters that
     contains the pad character ('=') anywhere other than the end of the
     string (e.g., "=AAA" and "AAA=BBB" are not allowed).
          </t>
          <t>
     If the client uses an initial response with a SASL mechanism that
     does not support an initial response, the server MUST <bcp14>MUST</bcp14> reject the
     command with a tagged BAD response.
          </t>
          <t>
      If a security layer is negotiated through the <xref target='SASL'/> target="RFC4422" format="default"/>
      authentication exchange, it takes effect immediately following the
      CRLF that concludes the authentication exchange for the client, client
      and the CRLF of the tagged OK response for the server.
          </t>
          <t>
      While client and server implementations MUST <bcp14>MUST</bcp14> implement the
      AUTHENTICATE command itself, it is not required to implement any
      authentication mechanisms other than the PLAIN mechanism described
      in <xref target='PLAIN'/>. target="RFC4616" format="default"/>.  Also, an authentication mechanism is not required
      to support any security layers.

           <list><t>

          </t>
           <t indent="3">
           Note: a server implementation MUST <bcp14>MUST</bcp14> implement a
           configuration in which it does NOT permit any plaintext
           password mechanisms, unless either the STARTTLS command
           has been negotiated, TLS has been negotiated on an Implicit TLS port,
           or some other mechanism that
           protects the session from password snooping has been
           provided.  Server sites SHOULD NOT <bcp14>SHOULD NOT</bcp14> use any configuration
           which
           that permits a plaintext password mechanism without
           such a protection mechanism against password snooping.
           Client and server implementations SHOULD <bcp14>SHOULD</bcp14> implement
           additional <xref target='SASL'/> target="RFC4422" format="default"/> mechanisms that do not use plaintext
           passwords, such as the GSSAPI mechanism described in <xref target='RFC4752'/>, target="RFC4752" format="default"/>,
           the SCRAM-SHA-256/SCRAM-SHA-256-PLUS <xref target='SCRAM-SHA-256'/> mechanisms target="RFC7677" format="default"/> mechanisms,
           and/or the EXTERNAL <xref target='SASL'/> target="RFC4422" format="default"/> mechanism for mutual TLS authentication.
           (Note that the SASL framework allows for the creation of SASL mechanisms that support
           2FA (2-factor authentication), however
           2-factor authentication (2FA); however, none are fully ready to be recommended
           by this document.)
           </t></list>
           </t>
          <t>
      Servers and clients can support multiple authentication
      mechanisms.  The server SHOULD <bcp14>SHOULD</bcp14> list its supported authentication
      mechanisms in the response to the CAPABILITY command so that the
      client knows which authentication mechanisms to use.
          </t>
          <t>
      A server MAY <bcp14>MAY</bcp14> include a CAPABILITY response code in the tagged OK
      response of a successful AUTHENTICATE command in order to send
      capabilities automatically.  It is unnecessary for a client to
      send a separate CAPABILITY command if it recognizes these
      automatic capabilities.  This should only be done if a security
      layer was not negotiated by the AUTHENTICATE command, because the
      tagged OK response as part of an AUTHENTICATE command is not
      protected by encryption/integrity checking.  <xref target='SASL'/> target="RFC4422" format="default"/> requires the
      client to re-issue a CAPABILITY command in this case.
      The server MAY <bcp14>MAY</bcp14> advertise different capabilities after
      a successful AUTHENTICATE command.
          </t>
          <t>
      If an AUTHENTICATE command fails with a NO response, the client
      MAY
      <bcp14>MAY</bcp14> try another authentication mechanism by issuing another
      AUTHENTICATE command.  It MAY <bcp14>MAY</bcp14> also attempt to authenticate by
      using the LOGIN command (see <xref target='login'/> target="login" format="default"/> for more detail).  In
      other words, the client MAY <bcp14>MAY</bcp14> request authentication types in
      decreasing order of preference, with the LOGIN command as a last
      resort.
          </t>
          <t>
      The authorization identity passed from the client to the server
      during the authentication exchange is interpreted by the server as
      the user name whose privileges the client is requesting.
          </t>

<figure><artwork>
   Example:

<t>Example:</t>
<sourcecode type="">
  S: * OK [CAPABILITY IMAP4rev2 STARTTLS AUTH=GSSAPI]
   Capabilities
  C: A001 AUTHENTICATE GSSAPI
  S: +
  C: YIIB+wYJKoZIhvcSAQICAQBuggHqMIIB5qADAgEFoQMCAQ6iBw
     MFACAAAACjggEmYYIBIjCCAR6gAwIBBaESGxB1Lndhc2hpbmd0
     b24uZWR1oi0wK6ADAgEDoSQwIhsEaW1hcBsac2hpdmFtcy5jYW
     Mud2FzaGluZ3Rvbi5lZHWjgdMwgdCgAwIBAaEDAgEDooHDBIHA
     cS1GSa5b+fXnPZNmXB9SjL8Ollj2SKyb+3S0iXMljen/jNkpJX
     AleKTz6BQPzj8duz8EtoOuNfKgweViyn/9B9bccy1uuAE2HI0y
     C/PHXNNU9ZrBziJ8Lm0tTNc98kUpjXnHZhsMcz5Mx2GR6dGknb
     I0iaGcRerMUsWOuBmKKKRmVMMdR9T3EZdpqsBd7jZCNMWotjhi
     vd5zovQlFqQ2Wjc2+y46vKP/iXxWIuQJuDiisyXF0Y8+5GTpAL
     pHDc1/pIGmMIGjoAMCAQGigZsEgZg2on5mSuxoDHEA1w9bcW9n
     FdFxDKpdrQhVGVRDIzcCMCTzvUboqb5KjY1NJKJsfjRQiBYBdE
     NKfzK+g5DlV8nrw81uOcP8NOQCLR5XkoMHC0Dr/80ziQzbNqhx
     O6652Npft0LQwJvenwDI13YxpwOdMXzkWZN/XrEqOWp6GCgXTB
     vCyLWLlWnbaUkZdEYbKHBPjd8t/1x5Yg==
  S: + YGgGCSqGSIb3EgECAgIAb1kwV6ADAgEFoQMCAQ+iSzBJoAMC
     AQGiQgRAtHTEuOP2BXb9sBYFR4SJlDZxmg39IxmRBOhXRKdDA0
     uHTCOT9Bq3OsUTXUlk0CsFLoa8j+gvGDlgHuqzWHPSQg==
  C:
  S: + YDMGCSqGSIb3EgECAgIBAAD/////6jcyG4GE3KkTzBeBiVHe
     ceP2CWY0SR0fAQAgAAQEBAQ=
  C: YDMGCSqGSIb3EgECAgIBAAD/////3LQBHXTpFfZgrejpLlLImP
     wkhbfa2QteAQAgAG1yYwE=
  S: A001 OK GSSAPI authentication successful
</artwork></figure>

<figure><artwork>
</sourcecode>

	  <t>
 The following example demonstrates the use of an initial response

   Example: response.
	  </t>
<t>Example:</t>
<sourcecode type="">
  S: * OK [CAPABILITY IMAP4rev2 STARTTLS AUTH=GSSAPI
   LOGINDISABLED] Server ready
  C: A01 STARTTLS
  S: A01 OK STARTLS STARTTLS completed
  &lt;TLS negotiation, further commands are under [TLS] layer> TLS layer&gt;
  C: A02 CAPABILITY
  S: * CAPABILITY IMAP4rev2 AUTH=GSSAPI AUTH=PLAIN
  S: A02 OK CAPABILITY completed
  C: A03 AUTHENTICATE PLAIN dGVzdAB0ZXN0AHRlc3Q=
  S: A03 OK Success (tls protection)
</artwork></figure>

<!--Possible extra examples from RFC 4959:
</sourcecode>

	  <t>
   Note that even when a server supports this extension, because the initial response is optional, the following
   negotiation (which does not use the initial response) is still valid
   and MUST <bcp14>MUST</bcp14> be supported by the server:
	  </t>

<sourcecode type="">
  ... client connects to server and negotiates a TLS
      protection layer ...
  C: C01 CAPABILITY
  S: * CAPABILITY IMAP4rev1 SASL-IR IMAP4rev2 AUTH=PLAIN
  S: C01 OK Completed
  C: A01 AUTHENTICATE PLAIN
            (note that there is a space following the "+" in the
           following line)
  S: +
  C: dGVzdAB0ZXN0AHRlc3Q=
  S: A01 OK Success (tls protection)
</sourcecode>

    <t>
    Note that in the above example there is a space following the "+" from the server.
    </t>

	  <t>
   The following is an example authentication using the SASL EXTERNAL
   mechanism (defined in [RFC4422]) <xref target="RFC4422" format="default"/>)
   under a TLS protection layer (see
   [RFC4346]) and an empty initial response:
	  </t>

<sourcecode type="">
  ... client connects to server and negotiates a TLS
      protection layer ...
  C: C01 CAPABILITY
  S: * CAPABILITY IMAP4rev1 SASL-IR IMAP4rev2 AUTH=PLAIN AUTH=EXTERNAL
  S: C01 OK Completed
  C: A01 AUTHENTICATE EXTERNAL =
  S: A01 OK Success (tls protection)

   This is in contrast with the handling of such a situation when an
   initial response is omitted:

         ... client connects to server and negotiates a TLS protection
           layer ...
        C: C01 CAPABILITY
        S: * CAPABILITY IMAP4rev1 SASL-IR AUTH=PLAIN AUTH=EXTERNAL
        S: C01 OK Completed
        C: A01 AUTHENTICATE EXTERNAL
            (note that there is a space following the "+" in the
           following line)
        S: +
        C:
        S: A01 OK Success (tls protection)
-->
</sourcecode>

   <t>
        Note: The line breaks within server challenges and client
        responses are for editorial clarity and are not in real
        authenticators.
          </t>
        </section>
        <section title='LOGIN Command' anchor='login'>

   <t>
   <list style='hanging' hangIndent='12'>
   <t hangText='Arguments:'>user name<vspace/>
               password</t>

   <t hangText='Responses:'>no anchor="login" numbered="true" toc="default">
          <name>LOGIN Command</name>

          <dl newline="false" spacing="normal" indent="14">
            <dt>Arguments:</dt>
            <dd>
	      <t>user name</t>
              <t>password</t>
	     </dd>
            <dt>Responses:</dt>
            <dd>no specific responses for this command</t>

   <t hangText='Result:'>OK - login command</dd>
            <dt>Result:</dt>
            <dd>
	    <dl spacing="compact" indent="6">
	      <dt>OK -</dt><dd>login completed, now in authenticated state<vspace/>
               NO - login state</dd>
              <dt>NO -</dt><dd>login failure: user name or password rejected<vspace/>
               BAD - command rejected</dd>
              <dt>BAD -</dt><dd>command unknown or arguments invalid</t>
   </list>
   </t> invalid</dd>
          </dl>
	  </dd>
          </dl>
          <t>
      The LOGIN command identifies the client to the server and carries
      the plaintext password authenticating this user.
      The LOGIN command SHOULD NOT <bcp14>SHOULD NOT</bcp14> be used except as a last
      resort (after attempting and failing to authenticate using
      the AUTHENTICATE command one or more times),
      and it is recommended that client implementations
      have a means to disable any automatic use of the LOGIN
      command.
          </t>
          <t>
      A server MAY <bcp14>MAY</bcp14> include a CAPABILITY response code in the tagged OK
      response to a successful LOGIN command in order to send
      capabilities automatically.  It is unnecessary for a client to
      send a separate CAPABILITY command if it recognizes these
      automatic capabilities.
          </t>

<figure><artwork>
   Example:
<t>Example:</t>
<sourcecode type="">
  C: a001 LOGIN SMITH SESAME
  S: a001 OK LOGIN completed
</artwork></figure>
</sourcecode>
          <t>
        Note: Use of the LOGIN command over an insecure network
        (such as the Internet) is a security risk, because anyone
        monitoring network traffic can obtain plaintext passwords.
        For that reason reason, clients MUST NOT <bcp14>MUST NOT</bcp14> use LOGIN on unsecure networks.
          </t>
          <t>
        Unless either the client is accessing IMAP service on an Implicit TLS port <xref target='RFC8314'/>, target="RFC8314" format="default"/>,
        the STARTTLS command has been negotiated negotiated, or
        some other mechanism that protects the session from
        password snooping has been provided, a server
        implementation MUST <bcp14>MUST</bcp14> implement a configuration in which it
        advertises the LOGINDISABLED capability and does NOT permit
        the LOGIN command.  Server sites SHOULD NOT <bcp14>SHOULD NOT</bcp14> use any
        configuration which that permits the LOGIN command without such
        a protection mechanism against password snooping.  A client
        implementation MUST NOT <bcp14>MUST NOT</bcp14> send a LOGIN command if the
        LOGINDISABLED capability is advertised.
          </t>
        </section>
      </section>
      <section title='Client numbered="true" toc="default">
        <name>Client Commands - Authenticated State'> State</name>
        <t>
   In the authenticated state, commands that manipulate mailboxes as
   atomic entities are permitted.  Of these commands, the SELECT and
   EXAMINE commands will select a mailbox for access and enter the
   selected state.
        </t>
        <t>
   In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
   the following commands are valid in the authenticated state: ENABLE, SELECT,
   EXAMINE, NAMESPACE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST,
   STATUS, APPEND APPEND, and IDLE.
        </t>
        <section title='ENABLE Command' anchor="enable-command">
      <iref item='ENABLE (command)'/>

   <t>
   <list style='hanging' hangIndent='12'>
   <t hangText='Arguments:'>capability names</t>

   <t hangText='Responses:'>no anchor="enable-command" numbered="true" toc="default">
          <name>ENABLE Command</name>
         <iref item="ENABLE (command)" subitem="" primary="false"/>
          <dl newline="false" spacing="normal" indent="14">
            <dt>Arguments:</dt>
            <dd>capability names</dd>
            <dt>Responses:</dt>
            <dd>no specific responses for this command</t>

   <t hangText='Result:'>OK - Relevant command</dd>
            <dt>Result:</dt>
            <dd>
	       <dl spacing="compact">
              <dt>OK -</dt><dd>Relevant capabilities enabled<vspace/>
               BAD - No enabled</dd>
               <dt>BAD -</dt><dd>No arguments, or syntax error in an argument</t>
   </list>
   </t> argument</dd>
               </dl>
	       </dd></dl>
          <t>
   Several IMAP extensions allow the server to return unsolicited
   responses specific to these extensions in certain circumstances.
   However, servers cannot send those unsolicited responses
   (with the exception of response codes (see <xref target='server-status-responses'/>) target="server-status-responses" format="default"/>)
   included in tagged or untagged OK/NO/BAD responses, which can always be sent)
   until they know that the clients support such extensions and thus won't choke on will be able to correctly parse and process the extension response data.
          </t>
          <t>
   The ENABLE command provides an explicit indication from the client
   that it supports particular extensions. It is designed such that
   the client can send a simple constant string with the extensions it
   supports, and the server will enable the shared subset that both
   support.
          </t>
          <t>
   The ENABLE command takes a list of capability names, names and requests the
   server to enable the named extensions.  Once enabled using ENABLE,
   each extension remains active until the IMAP connection is closed.
   For each argument, the server does the following:

   <list style='symbols'>
     <t>

          </t>
          <ul spacing="normal">
            <li>
     If the argument is not an extension known to the server, the server
     MUST
     <bcp14>MUST</bcp14> ignore the argument.
     </t>

     <t>
     </li>
            <li>
     If the argument is an extension known to the server, and it is not
     specifically permitted to be enabled using ENABLE, the server MUST <bcp14>MUST</bcp14>
     ignore the argument.  (Note that knowing about an extension doesn't
     necessarily imply supporting that extension.)
     </t>

     <t>
     </li>
            <li>
     If the argument is an extension that is supported by the server and
     that needs to be enabled, the server MUST <bcp14>MUST</bcp14> enable the extension for
     the duration of the connection. Note that once an extension is enabled,
     there is no way to disable it.
     </t>
     </list>

   </t>
     </li>
          </ul>
          <t>
   If the ENABLE command is successful, the server MUST <bcp14>MUST</bcp14> send an untagged
   ENABLED response <xref target='enabled'/>, (<xref target="enabled" format="default"/>), which includes all enabled
   extensions as specified above. The ENABLED response is sent even if
   no extensions were enabled.
          </t>
          <t>
   Clients SHOULD <bcp14>SHOULD</bcp14> only include extensions that need to be enabled by the
   server.  For example, a client can enable IMAP4rev2 specific behaviour IMAP4rev2-specific behavior
   when both IMAP4rev1 and IMAP4rev2 are advertised in the CAPABILITY response.
   Future RFCs may add to this list.
          </t>
          <t>
   The ENABLE command is only valid in the authenticated state,
   before any mailbox is selected.  Clients MUST NOT <bcp14>MUST NOT</bcp14> issue
   ENABLE once they SELECT/EXAMINE a mailbox; however, server
   implementations don't have to check that no mailbox is selected or
   was previously selected during the duration of a connection.
          </t>
          <t>
   The ENABLE command can be issued multiple times in a session.  It is
   additive; i.e., that is, "ENABLE a b", followed by "ENABLE c" c", is the same as a
   single command "ENABLE a b c".  When multiple ENABLE commands are
   issued, each corresponding ENABLED response SHOULD <bcp14>SHOULD</bcp14> only contain
   extensions enabled by the corresponding ENABLE command, i.e. i.e.,
   for the above example, the ENABLED response to "ENABLE c" should not
   contain "a" or "b".
          </t>
          <t>
   There are no limitations on pipelining ENABLE.  For example, it is
   possible to send ENABLE and then immediately SELECT, or a LOGIN
   immediately followed by ENABLE.
          </t>
          <t>
   The server MUST NOT <bcp14>MUST NOT</bcp14> change the CAPABILITY list as a result of
   executing ENABLE; i.e., that is, a CAPABILITY command issued right after an
   ENABLE command MUST <bcp14>MUST</bcp14> list the same capabilities as a CAPABILITY
   command issued before the ENABLE command.  This is demonstrated in
   the following example. Note that below "X-GOOD-IDEA" is a fictitious
   extension capability that can be ENABLEd. ENABLED.
          </t>

<figure><artwork>

<sourcecode type="">
  C: t1 CAPABILITY
  S: * CAPABILITY IMAP4rev2 ID LITERAL+ X-GOOD-IDEA
  S: t1 OK foo
  C: t2 ENABLE CONDSTORE X-GOOD-IDEA
  S: * ENABLED X-GOOD-IDEA
  S: t2 OK foo
  C: t3 CAPABILITY
  S: * CAPABILITY IMAP4rev2 ID LITERAL+ X-GOOD-IDEA
  S: t3 OK foo again
</artwork></figure>
</sourcecode>
          <t>
   In the following example, the client enables CONDSTORE the Conditional Store (CONDSTORE) extension <xref target='RFC7162'/>: target="RFC7162" format="default"/>:
          </t>

<figure><artwork>
<sourcecode type="">
  C: a1 ENABLE CONDSTORE
  S: * ENABLED CONDSTORE
  S: a1 OK Conditional Store enabled
</artwork></figure>
</sourcecode>
          <section title='Note numbered="true" toc="default">
            <name>Note to Designers of Extensions That May Use the ENABLE Command'> Command</name>
            <t>
           Designers of IMAP extensions are discouraged from creating extensions
           that require ENABLE unless there is no good alternative design.
           Specifically, extensions that cause potentially incompatible behavior
           changes to deployed server responses (and thus benefit from ENABLE)
           have a higher complexity cost than extensions that do not.
            </t>
          </section>
        </section>
        <section title='SELECT Command'>
      <iref item='SELECT (command)'/>

   <t>
   <list style='hanging' hangIndent='12'>
   <t hangText='Arguments:'>mailbox name</t>

   <t hangText='Responses:'>REQUIRED numbered="true" toc="default">
          <name>SELECT Command</name>

         <iref item="SELECT (command)" subitem="" primary="false"/>
          <dl newline="false" spacing="normal" indent="14">
            <dt>Arguments:</dt>
            <dd>mailbox name</dd>
            <dt>Responses:</dt>
            <dd>
	    <dl spacing="compact">
              <dt><bcp14>REQUIRED</bcp14> untagged responses: FLAGS, responses:</dt><dd>FLAGS, EXISTS, LIST<vspace/>
               REQUIRED LIST</dd>

               <dt><bcp14>REQUIRED</bcp14> OK untagged responses: PERMANENTFLAGS,<vspace/> responses:</dt><dd>PERMANENTFLAGS,
               UIDNEXT, UIDVALIDITY</t>

   <t hangText='Result:'>OK - select UIDVALIDITY</dd>
	    </dl>
            </dd>
            <dt>Result:</dt>
            <dd>
	       <dl spacing="compact">
              <dt>OK -</dt><dd>select completed, now in selected state<vspace/>
               NO - select state</dd>
              <dt>NO -</dt><dd>select failure, now in authenticated state: no<vspace/> no such mailbox, can't access mailbox<vspace/>
               BAD - command mailbox</dd>
              <dt>BAD -</dt><dd>command unknown or arguments invalid</t>
   </list>
   </t> invalid</dd>
	       </dl>
            </dd>
          </dl>
          <t>
      The SELECT command selects a mailbox so that messages in the
      mailbox can be accessed.  Before returning an OK to the client,
      the server MUST <bcp14>MUST</bcp14> send the following untagged data to the client.
      (The order of individual responses is not important.)
      <!--///But some of these response are marked as REQUIRED above!-->
      Note that earlier versions of this protocol (e.g. protocol, such as the IMAP4rev1 version specified
      in RFC 2060) <xref target="RFC2060" format="default"/>,
      only required the FLAGS and EXISTS untagged responses and UIDVALIDITY response code; consequently, client code.
      Client implementations SHOULD that need to remain compatible with such older IMAP versions
      have to implement default behavior for missing data data, as discussed with the individual item.

         <list style='hanging'>
         <t hangText='FLAGS'>Defined items.

          </t>
          <dl newline="true" spacing="normal">
            <dt>FLAGS</dt>
            <dd>Defined flags in the mailbox.  See the description
                     of the FLAGS response in <xref target='flags-resp'/> target="flags-resp" format="default"/> for more detail.</t>

         <t hangText='&lt;n> EXISTS'>The detail.</dd>
            <dt>&lt;n&gt; EXISTS</dt>
            <dd>The number of messages in the mailbox.  See the
                     description of the EXISTS response in <xref target='exists'/> target="exists" format="default"/> for more detail.</t>

         <t hangText='LIST'>The detail.</dd>
            <dt>LIST</dt>
            <dd>The server MUST <bcp14>MUST</bcp14> return a LIST response
                     with the mailbox name. The list of mailbox attributes MUST <bcp14>MUST</bcp14> be accurate.
                     If the server allows de-normalized denormalized UTF-8 mailbox names
                     (see <xref target='mailbox-naming'/>) target="mailbox-naming" format="default"/>) and the supplied mailbox name
                     differs from the normalized version, the server MUST <bcp14>MUST</bcp14> return
                     LIST with the OLDNAME extended data item. See <xref target='oldname'/> target="oldname" format="default"/>
                     for more details.</t>

         <t hangText='OK details.</dd>
            <dt>OK [PERMANENTFLAGS (&lt;list of flags>)]'> flags&gt;)]</dt>
            <dd>
                     A list of message flags that the client can change
                     permanently.  If this is missing, the client should
                     assume that all flags can be changed permanently.</t>

         <t hangText='OK permanently.</dd>
            <dt>OK [UIDNEXT &lt;n>]'> &lt;n&gt;]</dt>
            <dd>
                     The next unique identifier value.  Refer to
                     <xref target='uid-def'/> target="uid-def" format="default"/> for more information.</t>

         <t hangText='OK information.</dd>
            <dt>OK [UIDVALIDITY &lt;n>]'> &lt;n&gt;]</dt>
            <dd>
                     The unique identifier validity value.  Refer to
                     <xref target='uid-def'/> target="uid-def" format="default"/> for more information.</t>
         </list>
   </t> information.</dd>
          </dl>
          <t>
      Only one mailbox can be selected at a time in a connection;
      simultaneous access to multiple mailboxes requires multiple
      connections.  The SELECT command automatically deselects any
      currently selected mailbox before attempting the new selection.
      Consequently, if a mailbox is selected and a SELECT command that
      fails is attempted, no mailbox is selected.
      When deselecting a selected mailbox, the server MUST <bcp14>MUST</bcp14> return
      an untagged OK response with the "[CLOSED]" response code when
      <!--RFC Editor: please make sure that the following reference correctly shows the section number:-->
      the currently selected mailbox is closed (see <xref target='closed'/>). target="closed" format="default"/>).
          </t>
          <t>
      If the client is permitted to modify the mailbox, the server
      SHOULD
      <bcp14>SHOULD</bcp14> prefix the text of the tagged OK response with the
      "[READ-WRITE]" response code.
          </t>
          <t>
      If the client is not permitted to modify the mailbox but is
      permitted read access, the mailbox is selected as read-only, and
      the server MUST <bcp14>MUST</bcp14> prefix the text of the tagged OK response to
      SELECT with the "[READ-ONLY]" response code.  Read-only access
      through SELECT differs from the EXAMINE command in that certain
      read-only mailboxes MAY <bcp14>MAY</bcp14> permit the change of permanent state on a
      per-user (as opposed to global) basis.  Netnews messages marked in
      a server-based .newsrc file are an example of such per-user
      permanent state that can be modified with read-only mailboxes.
          </t>

<figure><artwork>
   Example:
<t>Example:</t>
<sourcecode type="">
  C: A142 SELECT INBOX
  S: * 172 EXISTS
  S: * OK [UIDVALIDITY 3857529045] UIDs valid
  S: * OK [UIDNEXT 4392] Predicted next UID
  S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
  S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
  S: * LIST () "/" INBOX
  S: A142 OK [READ-WRITE] SELECT completed
</artwork></figure>

<figure><artwork>
   Example:
</sourcecode>
<t>Example:</t>
<sourcecode type="">
  C: A142 SELECT INBOX
  S: * 172 EXISTS
  S: * OK [UIDVALIDITY 3857529045] UIDs valid
  S: * OK [UIDNEXT 4392] Predicted next UID
  S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
  S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
  S: A142 OK [READ-WRITE] SELECT completed
  [...some time later...]
  C: A143 SELECT Drafts
  S: * OK [CLOSED] Previous mailbox is now closed
  S: * 5 EXISTS
  S: * OK [UIDVALIDITY 9877410381] UIDs valid
  S: * OK [UIDNEXT 102] Predicted next UID
  S: * LIST () "/" Drafts
  S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
  S: * OK [PERMANENTFLAGS (\Deleted \Seen \Answered
      \Flagged \Draft \*)] System flags and keywords allowed
  S: A143 OK [READ-WRITE] SELECT completed
</artwork></figure>
</sourcecode>
          <t>Note that IMAP4rev1 compliant IMAP4rev1-compliant servers can also send the untagged RECENT
   response which that was deprecated in IMAP4rev2. E.g. IMAP4rev2, e.g., "* 0 RECENT".
   Pure IMAP4rev2 clients are advised to ignore the untagged RECENT response.
          </t>
        </section>
        <section title='EXAMINE Command'>
      <iref item='EXAMINE (command)'/>

   <t>
   <list style='hanging' hangIndent='12'>
   <t hangText='Arguments:'>mailbox name</t>

   <t hangText='Responses:'>REQUIRED numbered="true" toc="default">
          <name>EXAMINE Command</name>
          <iref item="EXAMINE (command)" subitem="" primary="false"/>
          <dl newline="false" spacing="normal" indent="14">
            <dt>Arguments:</dt>
            <dd>mailbox name</dd>
            <dt>Responses:</dt>
            <dd>
	      <dl spacing="compact">
              <dt><bcp14>REQUIRED</bcp14> untagged responses: FLAGS, responses:</dt><dd>FLAGS, EXISTS, LIST<vspace/>
               REQUIRED LIST</dd>

              <dt><bcp14>REQUIRED</bcp14> OK untagged responses: PERMANENTFLAGS,<vspace/> responses:</dt><dd>PERMANENTFLAGS,
              UIDNEXT, UIDVALIDITY</t>

   <t hangText='Result:'>OK - examine UIDVALIDITY</dd>
	      </dl>
            </dd>
            <dt>Result:</dt>
            <dd>
	      <dl spacing="compact">
              <dt>OK -</dt><dd>examine completed, now in selected state<vspace/> state</dd>
              <dt> NO - examine -</dt><dd>examine failure, now in authenticated state: no<vspace/> no
                such mailbox, can't access mailbox
               BAD - command mailbox</dd>
		<dt>BAD -</dt><dd>command unknown or arguments invalid</t>
   </list>
   </t> invalid</dd>
	      </dl>
            </dd>
          </dl>
          <t>
      The EXAMINE command is identical to SELECT and returns the same
      output; however, the selected mailbox is identified as read-only.
      No changes to the permanent state of the mailbox, including
      per-user state, are permitted.
          </t>
          <t>
      The text of the tagged OK response to the EXAMINE command MUST <bcp14>MUST</bcp14>
      begin with the "[READ-ONLY]" response code.
          </t>

<figure><artwork>
   Example:
<t>Example:</t>
<sourcecode type="">
   C: A932 EXAMINE blurdybloop
   S: * 17 EXISTS
   S: * OK [UIDVALIDITY 3857529045] UIDs valid
   S: * OK [UIDNEXT 4392] Predicted next UID
   S: * LIST () "/" blurdybloop
   S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
   S: * OK [PERMANENTFLAGS ()] No permanent flags permitted
   S: A932 OK [READ-ONLY] EXAMINE completed
</artwork></figure>
</sourcecode>
        </section>
        <section title='CREATE Command'>
      <iref item='CREATE (command)'/>

   <t>
   <list style='hanging' hangIndent='12'>
   <t hangText='Arguments:'>mailbox name</t>

   <t hangText='Responses:'>OPTIONAL numbered="true" toc="default">
          <name>CREATE Command</name>
          <iref item="CREATE (command)" subitem="" primary="false"/>
          <dl newline="false" spacing="normal" indent="14">
            <dt>Arguments:</dt>
            <dd>mailbox name</dd>
            <dt>Responses:</dt>
            <dd>
            <dl spacing="compact">
	      <dt><bcp14>OPTIONAL</bcp14> untagged response: LIST</t>

   <t hangText='Result:'>OK - create completed<vspace/>
               NO - create response:</dt><dd>LIST</dd>
	    </dl>
	    </dd>
            <dt>Result:</dt>
            <dd>
	     <dl spacing="compact">
              <dt>OK -</dt><dd>create completed</dd>
              <dt>NO -</dt><dd>create failure: can't create mailbox with that name<vspace/>
               BAD - command name</dd>
              <dt>BAD -</dt><dd>command unknown or arguments invalid</t>
   </list>
   </t> invalid</dd>
	     </dl>
            </dd>
          </dl>
          <t>
      The CREATE command creates a mailbox with the given name.  An OK
      response is returned only if a new mailbox with that name has been
      created.  It is an error to attempt to create INBOX or a mailbox
      with a name that refers to an extant mailbox.  Any error in
      creation will return a tagged NO response. If a client attempts
      to create a UTF-8 mailbox name that is not a valid Net-Unicode
      name, the server MUST <bcp14>MUST</bcp14> reject the creation or convert the name to
      Net-Unicode prior to creating the mailbox.
      If the server decides to convert (normalize) the name,
      it SHOULD <bcp14>SHOULD</bcp14> return an untagged LIST with an OLDNAME extended data item,
      with the OLDNAME value being the supplied mailbox name and the
      name parameter being the normalized mailbox name.
      (See <xref target='oldname'/> target="oldname" format="default"/> for more details.)
          </t>
          <t>Mailboxes created in one IMAP session MAY <bcp14>MAY</bcp14> be announced to other
   IMAP sessions using an unsolicited LIST response.
   If the server automatically subscribes a mailbox when it is created,
   then the unsolicited LIST response for each affected
   subscribed mailbox name MUST <bcp14>MUST</bcp14> include the \Subscribed attribute.
          </t>
          <t>
      If the mailbox name is suffixed with the server's hierarchy
      separator character (as returned from the server by a LIST
      command), this is a declaration that the client intends to create
      mailbox names under this name in the hierarchy.  Server
      implementations that do not require this declaration MUST <bcp14>MUST</bcp14> ignore
      the declaration.  In any case, the name created is without the
      trailing hierarchy delimiter.
          </t>
          <t>
      If the server's hierarchy separator character appears elsewhere in
      the name, the server SHOULD <bcp14>SHOULD</bcp14> create any superior hierarchical names
      that are needed for the CREATE command to be successfully
      completed.  In other words, an attempt to create "foo/bar/zap" on
      a server in which "/" is the hierarchy separator character SHOULD <bcp14>SHOULD</bcp14>
      create foo/ and foo/bar/ if they do not already exist.
          </t>
          <t>
      If a new mailbox is created with the same name as a mailbox which that
      was deleted, its unique identifiers MUST <bcp14>MUST</bcp14> be greater than any
      unique identifiers used in the previous incarnation of the mailbox
      unless the new incarnation has a different unique identifier
      validity value.  See the description of the UID command in <xref target='uid-commands'/> target="uid-commands" format="default"/> for more
      detail.
          </t>

<figure><artwork>
   Example:

<t>Example:</t>
<sourcecode type="">
  C: A003 CREATE owatagusiam/
  S: A003 OK CREATE completed
  C: A004 CREATE owatagusiam/blurdybloop
  S: A004 OK CREATE completed
  C: A005 CREATE NonNormalized
  S: * LIST () "/" "Normalized" ("OLDNAME" ("NonNormalized"))
  S: A005 OK CREATE completed

   (in
</sourcecode>
<t>
    (In the last example example, imagine that "NonNormalized" is
    a non NFC non-NFC normalized Unicode mailbox name and that
    "Normalized" is its NFC normalized version.)
</artwork></figure>

   <t><list><t>
</t>
          <aside><t>
        Note: The interpretation of this example depends on whether
        "/" was returned as the hierarchy separator from LIST.  If
        "/" is the hierarchy separator, a new level of hierarchy
        named "owatagusiam" with a member called "blurdybloop" is
        created.  Otherwise, two mailboxes at the same hierarchy
        level are created.
   </t></list></t> created.</t>
          </aside>
        </section>
        <section title='DELETE Command'>
      <iref item='DELETE (command)'/>

   <t>
   <list style='hanging' hangIndent='12'>
   <t hangText='Arguments:'>mailbox name</t>

   <t hangText='Responses:'>OPTIONAL numbered="true" toc="default">
          <name>DELETE Command</name>
          <iref item="DELETE (command)" subitem="" primary="false"/>
          <dl newline="false" spacing="normal" indent="14">
            <dt>Arguments:</dt>
            <dd>mailbox name</dd>
            <dt>Responses:</dt>
            <dd>
            <dl spacing="compact">
	    <dt><bcp14>OPTIONAL</bcp14> untagged response: LIST</t>

   <t hangText='Result:'>OK - delete completed<vspace/>
               NO - delete response:</dt><dd>LIST</dd>
	    </dl>
	    </dd>
            <dt>Result:</dt>
            <dd>
	    <dl spacing="compact">
              <dt>OK -</dt><dd>delete completed</dd>
              <dt>NO -</dt><dd>delete failure: can't delete mailbox with that name<vspace/>
               BAD - command name</dd>
              <dt>BAD -</dt><dd>command unknown or arguments invalid</t>
   </list>
   </t> invalid</dd>
	    </dl>
            </dd>
          </dl>
          <t>
      The DELETE command permanently removes the mailbox with the given
      name.  A tagged OK response is returned only if the mailbox has
      been deleted.  It is an error to attempt to delete INBOX or a
      mailbox name that does not exist.
          </t>
          <t>
     The DELETE command MUST NOT <bcp14>MUST NOT</bcp14> remove inferior hierarchical names.
     For example, if a mailbox "foo" has an inferior "foo.bar"
     (assuming "." is the hierarchy delimiter character), removing
     "foo" MUST NOT <bcp14>MUST NOT</bcp14> remove "foo.bar".  It is an error to attempt to
     delete a name that has inferior hierarchical names and also has
     the \Noselect mailbox name attribute (see the description of the
     LIST response (<xref target='list-resp'/>) target="list-resp" format="default"/>) for more details).
          </t>
          <t>
      It is permitted to delete a name that has inferior hierarchical
      names and does not have the \Noselect mailbox name attribute.  If
      the server implementation does not permit deleting the name while
      inferior hierarchical names exists exist, then it SHOULD <bcp14>SHOULD</bcp14> disallow the
      DELETE command by returning a tagged NO response. The NO response
      SHOULD
      <bcp14>SHOULD</bcp14> include the HASCHILDREN response code.
      Alternatively
      Alternatively, the server MAY <bcp14>MAY</bcp14> allow the DELETE command,
      but it sets the \Noselect mailbox name attribute for that name.
          </t>
          <t>
      If the server returns an OK response, all messages in
      that mailbox are removed by the DELETE command.
          </t>
          <t>
      The value of the highest-used unique identifier of the deleted
      mailbox MUST <bcp14>MUST</bcp14> be preserved so that a new mailbox created with the
      same name will not reuse the identifiers of the former
      incarnation, unless the new incarnation has a different unique
      identifier validity value.  See the description of the UID command
      in <xref target='uid-commands'/> target="uid-commands" format="default"/> for more detail.
          </t>
          <t>
      If the server decides to convert (normalize) the mailbox name,
      it SHOULD <bcp14>SHOULD</bcp14> return an untagged LIST with the "\NonExistent" attribute and
      OLDNAME extended data item,
      with the OLDNAME value being the supplied mailbox name and the
      name parameter being the normalized mailbox name.
      (See <xref target='oldname'/> target="oldname" format="default"/> for more details.)
          </t>
          <t>Mailboxes deleted in one IMAP session MAY <bcp14>MAY</bcp14> be announced to other IMAP
	  sessions using an unsolicited LIST response, containing the "\NonExistent" attribute.</t>

<figure><artwork>
   Example:

<t>Example:</t>
<sourcecode type="">
  C: A682 LIST "" *
  S: * LIST () "/" blurdybloop
  S: * LIST (\Noselect) "/" foo
  S: * LIST () "/" foo/bar
  S: A682 OK LIST completed
  C: A683 DELETE blurdybloop
  S: A683 OK DELETE completed
  C: A684 DELETE foo
  S: A684 NO Name "foo" has inferior hierarchical names
  C: A685 DELETE foo/bar
  S: A685 OK DELETE Completed
  C: A686 LIST "" *
  S: * LIST (\Noselect) "/" foo
  S: A686 OK LIST completed
  C: A687 DELETE foo
  S: A687 OK DELETE Completed
</artwork></figure>

<figure><artwork>
   Example:
</sourcecode>

<t>Example:</t>
<sourcecode type="">
  C: A82 LIST "" *
  S: * LIST () "." blurdybloop
  S: * LIST () "." foo
  S: * LIST () "." foo.bar
  S: A82 OK LIST completed
  C: A83 DELETE blurdybloop
  S: A83 OK DELETE completed
  C: A84 DELETE foo
  S: A84 OK DELETE Completed
  C: A85 LIST "" *
  S: * LIST () "." foo.bar
  S: A85 OK LIST completed
  C: A86 LIST "" %
  S: * LIST (\Noselect) "." foo
  S: A86 OK LIST completed
</artwork></figure>
</sourcecode>
        </section>
        <section title='RENAME Command'>
      <iref item='RENAME (command)'/>

   <t>
   <list style='hanging' hangIndent='12'>
   <t hangText='Arguments:'>existing numbered="true" toc="default">
          <name>RENAME Command</name>
          <iref item="RENAME (command)" subitem="" primary="false"/>
          <dl newline="false" spacing="normal" indent="14">
            <dt>Arguments:</dt>
            <dd>
              <t>existing mailbox name<vspace/>
               new name</t>
              <t>new mailbox name</t>

   <t hangText='Responses:'>OPTIONAL
            </dd>
            <dt>Responses:</dt>
            <dd>
            <dl spacing="compact">
	      <dt> <bcp14>OPTIONAL</bcp14> untagged response: LIST</t>

   <t hangText='Result:'>OK - rename completed<vspace/>
               NO - rename response:</dt><dd>LIST</dd>
	    </dl>
	    </dd>
            <dt>Result:</dt>
            <dd>
	     <dl spacing="compact">
              <dt>OK -</dt><dd>rename completed</dd>
              <dt>NO -</dt><dd>rename failure: can't rename mailbox with that name,<vspace/> name,
                    can't rename to mailbox with that name<vspace/>
               BAD - command name</dd>
              <dt>BAD -</dt><dd>command unknown or arguments invalid</t>
   </list>
   </t> invalid</dd>
	     </dl>
            </dd>
          </dl>
          <t>
      The RENAME command changes the name of a mailbox.  A tagged OK
      response is returned only if the mailbox has been renamed.  It is
      an error to attempt to rename from a mailbox name that does not
      exist or to a mailbox name that already exists.  Any error in
      renaming will return a tagged NO response.
          </t>
          <t>
      If the name has inferior hierarchical names, then the inferior
      hierarchical names MUST <bcp14>MUST</bcp14> also be renamed.  For example, a rename of
      "foo" to "zap" will rename "foo/bar" (assuming "/" is the
      hierarchy delimiter character) to "zap/bar".
          </t>
          <t>
      If the server's hierarchy separator character appears in the new mailbox name,
      the server SHOULD <bcp14>SHOULD</bcp14> create any superior hierarchical names that are
      needed for the RENAME command to complete successfully.  In other
      words, an attempt to rename "foo/bar/zap" to baz/rag/zowie "baz/rag/zowie" on a
      server in which "/" is the hierarchy separator character in the corresponding namespace SHOULD <bcp14>SHOULD</bcp14>
      create baz/ "baz/" and baz/rag/ "baz/rag/" if they do not already exist.
          </t>
          <t>
      The value of the highest-used unique identifier of the old mailbox
      name MUST <bcp14>MUST</bcp14> be preserved so that a new mailbox created with the same
      name will not reuse the identifiers of the former incarnation,
      unless the new incarnation has a different unique identifier
      validity value.  See the description of the UID command in <xref target='uid-commands'/> target="uid-commands" format="default"/>
      for more detail.
          </t>
          <t>
      Renaming INBOX is permitted (i.e. it doesn't and does not result in a tagged BAD response), response,
      and it has special behavior.
      (Note that some servers disallow renaming INBOX by returning a tagged NO response, so clients
      need to be able to handle such RENAME failing). behavior: It moves all messages in INBOX to a new mailbox with
      the given name, leaving INBOX empty.  If the server implementation supports
      inferior hierarchical names of INBOX, these are unaffected by a
      rename of INBOX.
      (Note that some servers disallow renaming INBOX by returning a tagged NO response,
      so clients need to be able to handle the failure of such RENAME commands.)
          </t>
          <t>If the server allows creation of mailboxes with names that
      are not valid Net-Unicode names, the server normalizes
      both the existing mailbox name parameter and the new mailbox name parameter.
      If the normalized version of any of these 2 parameters differs
      from the corresponding supplied version, the server SHOULD <bcp14>SHOULD</bcp14> return
      an untagged LIST response with an OLDNAME extended data item,
      with the OLDNAME value being the supplied existing mailbox name and the
      name parameter being the normalized new mailbox name
      (see <xref target='oldname'/>). target="oldname" format="default"/>).
      This would allow the client to correlate the supplied name with the normalized name.
          </t>
          <t>Mailboxes renamed in one IMAP session MAY <bcp14>MAY</bcp14> be announced to other IMAP sessions
      using an unsolicited LIST response with an OLDNAME extended data item.
          </t>
          <t>
     In both of the above cases: cases, if the server automatically subscribes a mailbox
     when it is renamed, then the unsolicited LIST response for each affected
     subscribed mailbox name MUST <bcp14>MUST</bcp14> include the \Subscribed attribute.
     No unsolicited LIST responses need to be sent for children mailboxes, if any. child mailboxes.
     When INBOX is successfully renamed, it is assumed that a new INBOX is assumed to be created.
     No unsolicited LIST responses need to be sent for INBOX in this case.
          </t>

<figure><artwork>
   Examples:

<t>Examples:</t>
<sourcecode type="">
  C: A682 LIST "" *
  S: * LIST () "/" blurdybloop
  S: * LIST (\Noselect) "/" foo
  S: * LIST () "/" foo/bar
  S: A682 OK LIST completed
  C: A683 RENAME blurdybloop sarasoop
  S: A683 OK RENAME completed
  C: A684 RENAME foo zowie
  S: A684 OK RENAME Completed
  C: A685 LIST "" *
  S: * LIST () "/" sarasoop
  S: * LIST (\Noselect) "/" zowie
  S: * LIST () "/" zowie/bar
  S: A685 OK LIST completed

  C: Z432 LIST "" *
  S: * LIST () "." INBOX
  S: * LIST () "." INBOX.bar
  S: Z432 OK LIST completed
  C: Z433 RENAME INBOX old-mail
  S: Z433 OK RENAME completed
  C: Z434 LIST "" *
  S: * LIST () "." INBOX
  S: * LIST () "." INBOX.bar
  S: * LIST () "." old-mail
  S: Z434 OK LIST completed
</artwork></figure>
</sourcecode>
          <t>
      Note that renaming a mailbox doesn't update subscription information
      on the original name. To keep subscription information in sync,
      the following sequence of commands can be used:
          </t>

<figure><artwork>
<sourcecode type="">
  C: 1001 RENAME X Y
  C: 1002 SUBSCRIBE Y
  C: 1003 UNSUBSCRIBE X
</artwork></figure>
</sourcecode>
          <t>
      Note that the above sequence of commands doesn't account for updating
      the subscription for any children child mailboxes of mailbox X.
          </t>
        </section>
        <section title='SUBSCRIBE Command'>
      <iref item='SUBSCRIBE (command)'/>

   <t>
   <list style='hanging' hangIndent='12'>
   <t hangText='Arguments:'>mailbox</t>

   <t hangText='Responses:'>no numbered="true" toc="default">
          <name>SUBSCRIBE Command</name>
          <iref item="SUBSCRIBE (command)" subitem="" primary="false"/>
          <dl newline="false" spacing="normal" indent="14">
            <dt>Arguments:</dt>
            <dd>mailbox</dd>
            <dt>Responses:</dt>
            <dd>no specific responses for this command</t>

   <t hangText='Result:'>OK - subscribe completed<vspace/>
               NO - subscribe command</dd>
            <dt>Result:</dt>
            <dd>
	       <dl spacing="compact">
              <dt>OK -</dt><dd>subscribe completed</dd>
              <dt>NO -</dt><dd>subscribe failure: can't subscribe to that name<vspace/>
               BAD - command name</dd>
              <dt>BAD -</dt><dd>command unknown or arguments invalid</t>
   </list>
   </t> invalid</dd>
	       </dl>
            </dd>
          </dl>
          <t>
      The SUBSCRIBE command adds the specified mailbox name to the
      server's set of "active" or "subscribed" mailboxes as returned by
      the LIST (SUBSCRIBED) command.  This command returns a tagged OK response
      if the subscription is successful or if the mailbox is already subscribed.
          </t>
          <t>
      A server MAY <bcp14>MAY</bcp14> validate the mailbox argument to SUBSCRIBE to verify
      that it exists.  However, it SHOULD NOT <bcp14>SHOULD NOT</bcp14> unilaterally remove an
      existing mailbox name from the subscription list even if a mailbox
      by that name no longer exists.

           <list><t>

          </t>
           <aside><t>
           Note: This requirement is because a server site can
           choose to routinely remove a mailbox with a well-known
           name (e.g., "system-alerts") after its contents expire,
           with the intention of recreating it when new contents
           are appropriate.
           </t></list>
   </t>

<figure><artwork>
   Example: appropriate.</t>
           </aside>
<t>Example:</t>
<sourcecode type="">
  C: A002 SUBSCRIBE #news.comp.mail.mime
  S: A002 OK SUBSCRIBE completed
</artwork></figure>
</sourcecode>
        </section>
        <section title='UNSUBSCRIBE Command'>
      <iref item='UNSUBSCRIBE (command)'/>

   <t>
   <list style='hanging' hangIndent='12'>
   <t hangText='Arguments:'>mailbox name</t>

   <t hangText='Responses:'>no numbered="true" toc="default">
          <name>UNSUBSCRIBE Command</name>
          <iref item="UNSUBSCRIBE (command)" subitem="" primary="false"/>
          <dl newline="false" spacing="normal" indent="14">
            <dt>Arguments:</dt>
            <dd>mailbox name</dd>
            <dt>Responses:</dt>
            <dd>no specific responses for this command</t>

   <t hangText='Result:'>OK - unsubscribe completed<vspace/>
               NO - unsubscribe command</dd>
            <dt>Result:</dt>
            <dd>
	       <dl spacing="compact">
              <dt>OK -</dt><dd>unsubscribe completed</dd>
              <dt>NO -</dt><dd>unsubscribe failure: can't unsubscribe that name<vspace/>
               BAD - command name</dd>
              <dt>BAD -</dt><dd>command unknown or arguments invalid</t>
   </list>
   </t> invalid</dd>
	       </dl>
            </dd>
          </dl>
          <t>
      The UNSUBSCRIBE command removes the specified mailbox name from
      the server's set of "active" or "subscribed" mailboxes as returned
      by the LIST (SUBSCRIBED) command.  This command returns a tagged OK response
      if the unsubscription is successful or if the mailbox is not subscribed.
          </t>

<figure><artwork>
   Example:
 <t>Example:</t>
<sourcecode type="">
  C: A002 UNSUBSCRIBE #news.comp.mail.mime
  S: A002 OK UNSUBSCRIBE completed
</artwork></figure>
</sourcecode>
        </section>
        <section title='LIST Command' anchor='list-cmd'>
      <iref item='LIST (command)'/>

   <t>
   <list style='hanging' hangIndent='12'>
   <t hangText='Arguments (basic):'>reference name<vspace/> anchor="list-cmd" numbered="true" toc="default">
          <name>LIST Command</name>
          <iref item="LIST (command)" subitem="" primary="false"/>
          <dl newline="false" spacing="normal" indent="14">
            <dt>Arguments (basic):</dt>
            <dd>
	    <ul empty="true" bare="true" spacing="compact">
              <li>reference name</li>
              <li> mailbox name with possible wildcards</t>

   <t hangText='Arguments (extended):'>selection wildcards</li>
	    </ul>
            </dd>
            <dt>Arguments (extended):</dt>
            <dd>
	       <ul empty="true" bare="true" spacing="compact">
	      <li> selection options (OPTIONAL)<vspace/>
               reference name<vspace/>
               mailbox patterns<vspace/>
               return (<bcp14>OPTIONAL</bcp14>)</li>
              <li>reference name</li>
              <li>mailbox patterns</li>
              <li>return options (OPTIONAL)</t>

   <t hangText='Responses:'>untagged (<bcp14>OPTIONAL</bcp14>)</li>
	       </ul>
            </dd>
            <dt>Responses:</dt>
            <dd>untagged responses: LIST</t>

   <t hangText='Result:'>OK - list completed<vspace/>
               NO - list LIST</dd>
            <dt>Result:</dt>
            <dd>
	        <dl spacing="compact">
                <dt>OK -</dt><dd>list completed</dd>
		<dt>NO -</dt><dd>list failure: can't list that reference or mailbox name<vspace/>
               BAD - command name</dd>
		<dt>BAD -</dt><dd>command unknown or arguments invalid</t>
   </list>
   </t> invalid</dd>
	      </dl>
            </dd>
            </dl>
          <t>
      The LIST command returns a subset of mailbox names from the complete set
      of all mailbox names available to the client.  Zero or more untagged LIST
      responses are returned, containing the name attributes, hierarchy
      delimiter, name, and possible extension information; see the description of
      the LIST response (<xref target='list-resp'/>) target="list-resp" format="default"/>) for more detail.
          </t>
          <t>
      The LIST command SHOULD <bcp14>SHOULD</bcp14> return its data quickly, without undue
      delay.  For example, it should not go to excess trouble to
      calculate the \Marked or \Unmarked status or perform other
      processing; if each name requires 1 second of processing, then a
      list of 1200 names would take 20 minutes!
          </t>
          <t>
      The extended LIST command, originally introduced in
      <xref target="RFC5258"/>, target="RFC5258" format="default"/>,
      provides capabilities beyond that of the original IMAP LIST command.
      The extended syntax is being used if one or more of
      the following conditions is true:
      <?rfc compact="no" ?>
      <list style="numbers">
        <t>if the
          </t>
          <ol spacing="normal" type="1">
	    <li>the first word after the command name begins with a
        parenthesis ("LIST selection options");</t>

        <t>if the options");</li>
            <li>the second word after the command name begins with a
        parenthesis;</t>

        <t>if the
        parenthesis; and</li>
            <li>the LIST command has more than 2 parameters ("LIST return options")</t>
      </list>
      <?rfc compact="yes" ?>
   </t> options").</li>
          </ol>
          <t>
      An empty ("" string) reference name argument indicates that the
      mailbox name is interpreted as by SELECT.  The returned mailbox
      names MUST <bcp14>MUST</bcp14> match the supplied mailbox name pattern(s).  A non-empty
      reference name argument is the name of a mailbox or a level of
      mailbox hierarchy, and it indicates the context in which the mailbox
      name is interpreted.
      Clients SHOULD <bcp14>SHOULD</bcp14> use the empty reference argument.
          </t>
          <t>
      In the basic syntax only,
      an empty ("" string) mailbox name argument is a special request to
      return the hierarchy delimiter and the root name of the name given
      in the reference.  The value returned as the root MAY <bcp14>MAY</bcp14> be the empty
      string if the reference is non-rooted or is an empty string.  In
      all cases, a hierarchy delimiter (or NIL if there is no hierarchy)
      is returned.  This permits a client to get the hierarchy delimiter
      (or find out that the mailbox names are flat) even when no
      mailboxes by that name currently exist.
          </t>
          <t>
      In the extended syntax, any mailbox name arguments that are empty
      strings are ignored.  There is no special meaning for empty mailbox
      names when the extended syntax is used.
          </t>
          <t>
      The reference and mailbox name arguments are interpreted into a
      canonical form that represents an unambiguous left-to-right
      hierarchy.  The returned mailbox names will be in the interpreted
      form, <!--///Alexey: it looks like we have 2 definitions. Should
      we standardize on one?-->that which we call a "canonical LIST pattern"
      later in this document.
      To define the term "canonical LIST pattern" formally: it refers to pattern":
      the canonical pattern constructed internally by the server from
      the reference and mailbox name arguments.

           <list>
           <t>
          </t>
           <t indent="3">
           Note: The interpretation of the reference argument is
           implementation-defined.
           implementation defined.  It depends upon on whether the
           server implementation has a concept of the "current
           working directory" and leading "break out characters",
           which override the current working directory.
           </t>

           <t>
           <t indent="3">
           For example, on a server which that exports a UNIX or NT
           filesystem,
           file system, the reference argument contains the current
           working directory, and the mailbox name argument would
           contain
           contains the name as interpreted in the current working
           directory.
           </t>

           <t>
           <t indent="3">
           If a server implementation has no concept of break out
           characters, the canonical form is normally the reference
           name appended with the mailbox name.  Note that if the
           server implements the namespace convention (<xref target='namespace-convention'/>), target="namespace-convention" format="default"/>),
           "#" is a break out character and must be treated
           as such.
           </t>

           <t>
           <t indent="3">
           If the reference argument is not a level of mailbox
           hierarchy (that is, it is a \NoInferiors name), and/or
           the reference argument does not end with the hierarchy
           delimiter, it is implementation-dependent how this is
           interpreted.
           interpreted as implementation dependent.  For example, a reference of "foo/bar" and
           mailbox name of "rag/baz" could be interpreted as
           "foo/bar/rag/baz", "foo/barrag/baz", or "foo/rag/baz".
           A client SHOULD NOT <bcp14>SHOULD NOT</bcp14> use such a reference argument except
           at the explicit request of the user.  A hierarchical
           browser MUST NOT <bcp14>MUST NOT</bcp14> make any assumptions about server
           interpretation of the reference unless the reference is
           a level of mailbox hierarchy AND ends with the hierarchy
           delimiter.
           </t>
           </list>
   </t>
          <t>
      Any part of the reference argument that is included in the
      interpreted form SHOULD <bcp14>SHOULD</bcp14> prefix the interpreted form.  It SHOULD <bcp14>SHOULD</bcp14>
      also be in the same form as the reference name argument.  This
      rule permits the client to determine if the returned mailbox name
      is in the context of the reference argument, argument or if something about
      the mailbox argument overrode the reference argument.  Without
      this rule, the client would have to have knowledge of the server's
      naming semantics including what characters are "breakouts" that
      override a naming context.

<figure><artwork>
	  </t>

<t>
	   Here are some examples of how references
           and mailbox names might be interpreted on a UNIX-based
           server:

               Reference     Mailbox Name  Interpretation
               ------------  ------------  --------------
               ~smith/Mail/  foo.*         ~smith/Mail/foo.*
               archive/      %             archive/%
               #news.        comp.mail.*   #news.comp.mail.*
               ~smith/Mail/  /usr/doc/foo  /usr/doc/foo
               archive/      ~fred/Mail/*  ~fred/Mail/*
</t>

<table anchor="table_1">
  <name></name>
  <thead>
    <tr>
      <th>Reference</th>
      <th>Mailbox Name</th>
      <th>Interpretation</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>~smith/Mail/</td>
      <td>foo.* </td>
      <td>~smith/Mail/foo.*</td>
    </tr>
    <tr>
       <td>archive/</td>
       <td>%</td>
       <td>archive/%</td>
    </tr>
     <tr>
       <td>#news.</td>
       <td>comp.mail.*</td>
       <td>#news.comp.mail.*</td>
     </tr>
      <tr>
       <td>~smith/Mail/</td>
       <td>/usr/doc/foo</td>
       <td>/usr/doc/foo</td>
      </tr>
       <tr>
       <td>archive/</td>
       <td>~fred/Mail/*</td>
       <td>~fred/Mail/*</td>
       </tr>
  </tbody>
</table>
	  <t>
           The first three examples above demonstrate interpretations in
           the context of the reference argument.  Note that
           "~smith/Mail" SHOULD NOT <bcp14>SHOULD NOT</bcp14> be transformed into something
           like "/u2/users/smith/Mail", or it would be impossible
           for the client to determine that the interpretation was
           in the context of the reference.
</artwork></figure>
	  </t>
          <t>
      The character "*" is a wildcard, wildcard and matches zero or more
      characters at this position.  The character "%" is similar to "*",
      but it does not match a hierarchy delimiter.  If the "%" wildcard
      is the last character of a mailbox name argument, matching levels
      of hierarchy are also returned.  If these levels of hierarchy are
      not also selectable mailboxes, they are returned with the
      \Noselect mailbox name attribute (see the description of the LIST
      response (<xref target='list-resp'/>) target="list-resp" format="default"/>) for more details).
          </t>
          <t>Any syntactically valid pattern that is not accepted by a
      server for any reason MUST <bcp14>MUST</bcp14> be silently ignored. I.e. ignored, i.e., it results in
      no LIST responses responses, and the LIST command still returns a tagged OK response.
          </t>
          <t>
      Selection options tell the server to limit the mailbox names that
      are selected by the LIST operation.  If selection options are used,
      the mailboxes returned are those that match both the list of canonical LIST
      patterns and the selection options.  Unless a particular selection
      option provides special rules, the selection options are cumulative:
      a mailbox that matches the mailbox patterns is selected only if it
      also matches all of the selection options.
      (An example of a selection option with special rules is the RECURSIVEMATCH option.)
          </t>
          <t>
      Return options control what information is returned for each matched mailbox.
      Return options MUST NOT <bcp14>MUST NOT</bcp14> cause the server to report information about additional
      mailbox names other than those that match the canonical LIST patterns and selection options.
      If no return options are specified, the client is only expecting information
      about mailbox attributes.  The server MAY <bcp14>MAY</bcp14> return other information about the
      matched mailboxes, and clients MUST <bcp14>MUST</bcp14> be able to handle that situation.
          </t>
          <t>
      Initial selection options and return options are defined in the following subsections,
      and new ones will also be defined in extensions.
      Initial options defined in this document MUST <bcp14>MUST</bcp14> be supported.
      Each non-initial option will be enabled by a
      capability string (one capability may enable multiple options), and a client
      MUST NOT
      <bcp14>MUST NOT</bcp14> send an option for which the server has not advertised support.
      A server MUST <bcp14>MUST</bcp14> respond to options it does not recognize with a BAD response.
      The client SHOULD NOT <bcp14>SHOULD NOT</bcp14> specify any option more than once; however, if the
      client does this, the server MUST <bcp14>MUST</bcp14> act as if it received the option only once.
      The order in which options are specified by the client is not significant.
          </t>
          <t>
      In general, each selection option except RECURSIVEMATCH will have
      a corresponding return option with the same name.  The REMOTE selection option is an anomaly
      in this regard, regard and does not have a corresponding return option.
      That is because it expands, rather than restricts, the set of mailboxes
      that are returned.  Future extensions to this specification should keep
      this parallelism in mind and define a pair of corresponding
      selection and return options.
          </t>
          <t>
      Server implementations are permitted to "hide" otherwise
      accessible mailboxes from the wildcard characters, by preventing
      certain characters or names from matching a wildcard in certain
      situations.  For example, a UNIX-based server might restrict the
      interpretation of "*" so that an initial "/" character does not
      match.
          </t>
          <t>
      The special name INBOX is included in the output from LIST, if
      INBOX is supported by this server for this user and if the
      uppercase string "INBOX" matches the interpreted reference and
      mailbox name arguments with wildcards as described above.  The
      criteria for omitting INBOX is whether SELECT INBOX will return
      a failure; it is not relevant whether the user's real INBOX resides
      on this or some other server.
          </t>
          <section title='LIST anchor="list-select-options" numbered="true" toc="default">
            <name>LIST Selection Options' anchor='list-select-options'> Options</name>
            <t>The selection options defined in this specification are as follows:</t>
            <dl newline="true" spacing="normal">
              <dt>SUBSCRIBED</dt>
              <dd>
                <t>
      <list style="hanging">
        <t hangText="SUBSCRIBED -">
          causes
          Causes the LIST command to list subscribed
          names,
          names rather than the existing mailboxes.  This will often
          be a subset of the actual mailboxes.  It's also possible for
          this list to contain the names of mailboxes that don't exist.
          In any case, the list MUST <bcp14>MUST</bcp14> include exactly those mailbox names
          that match the canonical list pattern and are subscribed to.
    <!--Removed:
                </t>
                <t>
          This option is intended to supplement the LSUB command.
          Of particular note are the defines a mailbox attributes as returned by this
          option, compared with what attribute, "\Subscribed", that
          indicates that a mailbox name is returned by LSUB. With the
          latter, the attributes returned may not reflect the actual subscribed to. The "\Subscribed"
          attribute
          status on the mailbox name, <bcp14>MUST</bcp14> be supported and <bcp14>MUST</bcp14> be accurately computed
          when the \NoSelect attribute has a second special
          meaning (it indicates that this mailbox is not, itself,
          subscribed, but that it has descendant mailboxes that are).

          With the SUBSCRIBED selection option described here, the attributes are
          accurate and complete, and have no special meanings.
          "LSUB" and "LIST (SUBSCRIBED)" are, thus, not the same thing,
          and some servers must do significant extra work to respond to
          "LIST (SUBSCRIBED)".  Because of this, clients SHOULD continue
          to use "LSUB" unless they specifically want the additional
          information offered by "LIST (SUBSCRIBED)".
      -->
          <vspace blankLines="1"/>
          This option defines a mailbox attribute, "\Subscribed", that
          indicates that a mailbox name is subscribed to. The "\Subscribed"
          attribute MUST be supported and MUST be accurately computed
          when the SUBSCRIBED selection option SUBSCRIBED selection option is specified.
          <vspace blankLines="1"/>
                </t>
                <t>
          Note that the SUBSCRIBED selection option implies the SUBSCRIBED
          return option (see below).
                </t>

        <t hangText="REMOTE -">
          causes
              </dd>
              <dt>REMOTE</dt>
              <dd>
                <t>
          Causes the LIST command to show remote mailboxes as
          well as local ones, as described in <xref target="RFC2193"/>. target="RFC2193" format="default"/>.  This option
          is intended to replace the RLIST command and, in conjunction
          with the SUBSCRIBED selection option, the RLSUB command.
          Servers that don't support the concept of remote mailboxes just can ignore this option.
          <vspace blankLines="1"/>
                </t>
                <t>
          This option defines a mailbox attribute, "\Remote", that
          indicates that a mailbox is a remote mailbox.  The "\Remote"
          attribute MUST <bcp14>MUST</bcp14> be accurately computed when the REMOTE option is
          specified.
          <vspace blankLines="1"/>
                </t>
                <t>
          The REMOTE selection option has no interaction with other options.
          Its effect is to tell the server to apply the other options, if
          any, to remote mailboxes, in addition to local ones.
          In particular, it has no interaction with RECURSIVEMATCH (see below).
          A request for (REMOTE RECURSIVEMATCH) is invalid, because a
          request for (RECURSIVEMATCH) is also invalid.  A request for (REMOTE RECURSIVEMATCH SUBSCRIBED)
          is asking for all subscribed mailboxes, both local and remote.
                </t>

        <t hangText="RECURSIVEMATCH -">
          this option forces
              </dd>
              <dt>RECURSIVEMATCH</dt>
              <dd>
                <t>
          Forces the server to return
          information about parent mailboxes that don't match other
          selection options, options but have some submailboxes that do.
          Information about children is returned in the CHILDINFO
          extended data item, as described in <xref target="childinfo"/>.
          <vspace blankLines="1"/>
          Note 1: In target="childinfo" format="default"/>.
                </t>
		<dl spacing="normal" newline="false">

          <dt>Note 1:</dt><dd>In order for a parent mailbox to be returned, it still
          has to match the canonical LIST pattern.
          <vspace blankLines="1"/>
          Note 2: When pattern.</dd>

          <dt>Note 2:</dt><dd>When returning the CHILDINFO extended data item,
          it doesn't matter whether or not the submailbox matches
          the canonical LIST pattern. See also example Example 9 in
          <xref target="examples"/>.
          <vspace blankLines="1"/> target="examples" format="default"/>.</dd></dl>

                <t>
          The RECURSIVEMATCH option MUST NOT <bcp14>MUST NOT</bcp14> occur as the only selection
          option (or only with REMOTE),
          as it only makes sense when other selection options are
          also used. The server MUST <bcp14>MUST</bcp14> return a BAD tagged response in such case.
          <vspace blankLines="1"/>
                </t>
                <t>
          Note that even if the RECURSIVEMATCH option is specified, the client
          MUST
          <bcp14>MUST</bcp14> still be able to handle a case cases when a CHILDINFO extended
          data item is returned and there are no submailboxes
          that meet the selection criteria of the subsequent LIST command,
          as they can be deleted/renamed after the LIST response was sent, sent
          but before the client had a chance to access them.
                </t>
      </list>
      </t>
              </dd>
            </dl>
          </section>
          <section title='LIST anchor="list-return-options" numbered="true" toc="default">
            <name>LIST Return Options' anchor='list-return-options'> Options</name>
            <t>The return options defined in this specification are as follows:</t>
            <dl newline="true" spacing="normal">
              <dt>SUBSCRIBED</dt>
              <dd>
                <t>
	<list style="hanging">
	    <t hangText="SUBSCRIBED -">
	    causes
	    Causes the LIST command to return subscription
	    state for all matching mailbox names. The "\Subscribed"
	    attribute MUST <bcp14>MUST</bcp14> be supported and MUST <bcp14>MUST</bcp14> be accurately computed
	    when the SUBSCRIBED return option is specified.
	    Further,
	    Furthermore, all other mailbox attributes MUST <bcp14>MUST</bcp14> be accurately computed (this
	    differs from the behavior of the obsolete LSUB command from RFC 3501). <xref target="RFC3501" format="default"/>).
        Note that the above requirements don't override the requirement for the LIST
        command to return results quickly (see <xref target='list-cmd'/>),
        i.e. target="list-cmd" format="default"/>),
        i.e., server implementations need to compute results quickly and accurately.
        For example, server implementors might need to create quick access indices.
	    <vspace blankLines="1"/></t>

	    <t hangText="CHILDREN -">
	    requests
                </t>
              </dd>
              <dt>CHILDREN</dt>
              <dd>
	    Requests mailbox child information as originally
	    proposed in <xref target="RFC3348"/>. target="RFC3348" format="default"/>.
	    See <xref target="children"/>, target="children" format="default"/>, below, for details.
      <!--Alexey: it is a bit odd to explicitly have a MUST for this,
        despite explicitly saying earlier in the document that all options
        from this document MUST be supported.
	    This option MUST be supported by all servers.
      -->
	    </t>

	    <t hangText="STATUS -">
        requests
	    </dd>
              <dt>STATUS</dt>
              <dd>
                <t>
        Requests STATUS response for each matching mailbox.

          <list style="empty">
                </t>

                  <t>This option takes STATUS data items as parameters. For each selectable
            mailbox matching the list pattern and selection options, the server
            MUST
            <bcp14>MUST</bcp14> return an untagged LIST response followed by an untagged STATUS
            response containing the information requested in the STATUS return
            option, except for some cases described below.
	        </t>
                  <t>
            If an attempted STATUS for a listed mailbox fails because the mailbox
            can't be selected (e.g., if the "l" ACL Access Control List (ACL) right <xref target='RFC4314'/> target="RFC4314" format="default"/>
            is granted to the
            mailbox and the "r" right is not granted, or is due to a race condition
            between LIST and STATUS changing the mailbox to \NoSelect), the
            STATUS response MUST NOT <bcp14>MUST NOT</bcp14> be returned returned, and the LIST response MUST <bcp14>MUST</bcp14>
            include the \NoSelect attribute.  This means the server may have to
            buffer the LIST reply until it has successfully looked up the
            necessary STATUS information.
	        </t>
            <t>
            If the server runs into unexpected problems while trying to look up
            the STATUS information, it MAY <bcp14>MAY</bcp14> drop the corresponding STATUS reply.
            In such a situation, the LIST command would still return a tagged OK
            reply.
	        </t>

          </list>
	    </t>

	</list>
            <t>
            See the note in the discussion of the STATUS command in
            <xref target="status-command"/> for information about obtaining status
            on the currently selected mailbox.
	        </t>
              </dd>
            </dl>
          </section>
          <section anchor="general" title="General numbered="true" toc="default">
            <name>General Principles for Returning LIST Responses"> Responses</name>
            <t>This section outlines several principles that can be used by server
        implementations of this document to decide whether a LIST response should be
        returned, as well as how many responses and what kind of information
        they may contain.</t>

        <t>
        <list style="numbers">
          <t>At most
        <ol spacing="normal" type="1">
	  <li>At most, one LIST response should be returned for each mailbox
          name that matches the canonical LIST pattern.
          Server implementors must not assume that clients will be able to
          assemble mailbox attributes and other information returned in multiple
          LIST responses.
          </t>
          </li>
              <li>
                <t>There are only two reasons for including a matching mailbox name
          in the responses to the LIST command (note that the server is allowed
          to return unsolicited responses at any time, and such responses are not
          governed by this rule):

          <list style="letters">
            <t>The

                </t>
                <ol spacing="normal" type="A"><li>The mailbox name also satisfies the selection criteria.</t> criteria.</li>
                  <li>
                    <t>The mailbox name doesn't satisfy the selection criteria, but
            it has at least one descendant mailbox name that satisfies the
            selection criteria and that doesn't match the canonical LIST
            pattern.
       	    <vspace blankLines="1"/>
                    </t>
                    <t>
            For more information on this case, see the CHILDINFO extended data
            item described in <xref target="childinfo"/>. target="childinfo" format="default"/>.  Note that the CHILDINFO extended
            data item can only be returned when the RECURSIVEMATCH selection
            option is specified.</t>
          </list>
          </t>
                  </li>
                </ol>
              </li>
              <li>
                <t>Attributes returned in the same LIST response are treated additively.
          For example, the following response

          <list style="empty">
            <t>S:
                </t>
<sourcecode type="">
  S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"</t>
          </list> "Fruit/Peach"
</sourcecode>
          <t>
          means that the "Fruit/Peach" mailbox doesn't exist, but it is
          subscribed.</t>
        </list>
        </t>
              </li>
            </ol>
          </section>
          <section title="Additional LIST-related numbered="true" toc="default">
            <name>Additional LIST-Related Requirements on Clients"> Clients</name>
            <t>All clients MUST <bcp14>MUST</bcp14> treat a LIST attribute with
        a stronger meaning as implying any attribute that can be inferred
        from it. (See <xref target='list-resp'/> target="list-resp" format="default"/> for the list of currently defined attributes). attributes.)
        For example, the client must treat the presence of the
        \NoInferiors attribute as if the \HasNoChildren attribute was also
        sent by the server.
            </t>

        <texttable>
          <preamble>The
            <t>The following table summarizes inference rules.</preamble>

          <ttcol align='center'>returned attribute</ttcol>
          <ttcol align='center'>implied attribute</ttcol>

          <c>\NoInferiors</c>
          <c>\HasNoChildren</c>

          <c>\NonExistent</c>
          <c>\NoSelect</c>

          <!--<postamble></postamble>-->
        </texttable> rules.</t>
            <table align="center">
              <thead>
                <tr>
                  <th align="center">returned attribute</th>
                  <th align="center">implied attribute</th>
                </tr>
              </thead>
              <tbody>
                <tr>
                  <td align="center">\NoInferiors</td>
                  <td align="center">\HasNoChildren</td>
                </tr>
                <tr>
                  <td align="center">\NonExistent</td>
                  <td align="center">\NoSelect</td>
                </tr>
              </tbody>
            </table>
          </section>
          <section anchor="children" title="The numbered="true" toc="default">
            <name>The CHILDREN Return Option"> Option</name>
            <t>
      The CHILDREN return option is simply an indication that the client wants
      information about whether or not mailboxes contain children child mailboxes;
	    a server MAY <bcp14>MAY</bcp14> provide it even if the option is not specified.</t>

            <t>Many IMAP4 IMAP clients present to the user with a hierarchical view of
      the mailboxes that a user has access to.  Rather than initially
      presenting to the user the entire mailbox hierarchy, hierarchy to the user, it is often
      preferable to show to the user a collapsed outline list of the
      mailbox hierarchy (particularly if there is a large number of
      mailboxes).  The user can then expand the collapsed outline hierarchy
      as needed.  It is common to include within the collapsed hierarchy a
      visual clue (such as a ''+'') within the collapsed hierarchy to indicate that there are child
      mailboxes under a particular mailbox.   When the visual clue is
      clicked, the hierarchy list is expanded to show the child mailboxes.
      The CHILDREN return option provides a mechanism for a client to
      efficiently determine whether a particular mailbox has children, without
      issuing a LIST "" * or a LIST "" % for each mailbox name.
      The CHILDREN return option defines two new attributes that MUST <bcp14>MUST</bcp14> be
      returned within a LIST response: \HasChildren and \HasNoChildren.
      Although these attributes MAY <bcp14>MAY</bcp14> be returned in response to any LIST
      command, the CHILDREN return option is provided to indicate that the
      client particularly wants this information.  If the CHILDREN return
      option is present, the server MUST <bcp14>MUST</bcp14> return these attributes even if
      their computation is expensive.</t>

      <t>
      \HasChildren
      <list style="hanging" hangIndent="5">
        <t>The

       <dl newline="true" spacing="normal" indent="5">
       <dt>\HasChildren</dt>
       <dd>The presence of this attribute indicates that the
        mailbox has child mailboxes.
        A server SHOULD NOT <bcp14>SHOULD NOT</bcp14> set this attribute if there are child
        mailboxes and the user does not have permission to access any
        of them. In this case, \HasNoChildren SHOULD <bcp14>SHOULD</bcp14> be used.
        In many cases, however, a server may not be able to efficiently
        compute whether a user has access to any child mailbox.
        Note that even though the \HasChildren attribute for a mailbox
        must be correct at the time of processing of the mailbox, a client
        must be prepared to deal with a situation when a mailbox is marked
        with the \HasChildren attribute, but no child mailbox appears in the
        response to the LIST command. This might happen, for example, due to
        children
        child mailboxes being deleted or made inaccessible to the user
        (using access control) by another client before the server is able to
        list them.</t>
      </list>
      <vspace blankLines="1"/>

      \HasNoChildren
      <list style="hanging" hangIndent="5">
        <t>The them.</dd>

     <dt>\HasNoChildren</dt>
              <dd>The presence of this attribute indicates that the
        mailbox has NO child mailboxes that are accessible to the
        currently authenticated user.</t>
      </list>
      </t> user.</dd>
           </dl>

            <t>It is an error for the server to return both a
	    \HasChildren and a \HasNoChildren attribute in the same LIST response.</t>

            <t>Note: the \HasNoChildren attribute should not be confused with
      the
      the \NoInferiors attribute, which indicates
      that no child mailboxes exist now and none can be created in the future.</t>
          </section>
          <section anchor="childinfo" title="CHILDINFO numbered="true" toc="default">
            <name>CHILDINFO Extended Data Item"> Item</name>
            <t>The CHILDINFO extended data item MUST NOT <bcp14>MUST NOT</bcp14> be returned unless the client
        has specified the RECURSIVEMATCH selection option.</t>
            <t>The CHILDINFO extended data item in a LIST response describes the
        selection criteria that has caused it to be returned and indicates that
        the mailbox has at least one descendant mailbox that matches the selection
        criteria.</t>

<!--
        <t>The LSUB command indicates this condition by using the "\NoSelect"
        attribute, but the LIST (SUBSCRIBED) command MUST NOT do that, since
        "\NoSelect" retains its original meaning here.  Further, the CHILDINFO
        extended data item is more general, in that it can be used with any
        extended set of selection criteria.</t>
-->
        <t>Note: Some servers allow for mailboxes to exist without requiring
        their parent to exist. For example, a the mailbox "Customers/ABC" can exist
        while the mailbox "Customers" does not. As the CHILDINFO extended data
        item is not allowed if the RECURSIVEMATCH selection option is not specified,
        such servers SHOULD <bcp14>SHOULD</bcp14> use the "\NonExistent \HasChildren" attribute pair to signal
        to the client that there is a descendant mailbox that matches the selection
        criteria. See example Example 11 in <xref target="examples"/>.</t> target="examples" format="default"/>.</t>

            <t>The returned selection criteria allow allows the client to distinguish
        a solicited response from an unsolicited one, as well as to distinguish
        among solicited responses caused by multiple pipelined LIST commands
            that specify different criteria.</t>

            <t>Servers SHOULD <bcp14>SHOULD</bcp14> only return a non-matching mailbox name along with
        CHILDINFO if at least one matching child is not also being returned.
        That is, servers SHOULD <bcp14>SHOULD</bcp14> suppress redundant CHILDINFO responses.
            </t>
            <t>Examples 8 and 10 in <xref target="examples"/> target="examples" format="default"/> demonstrate the difference between
        the present CHILDINFO extended data item and the "\HasChildren" attribute.</t>

        <texttable>
          <preamble>The
            <t>The following table summarizes interaction between the "\NonExistent"
          attribute and CHILDINFO (the first column indicates whether the parent
            mailbox exists):</preamble>

          <ttcol align='center'>exists</ttcol>
          <ttcol align='center'>meets exists):</t>

            <table align="center">
              <thead>
                <tr>
                  <th align="center">Exists</th>
                  <th align="center">Meets the selection criteria</ttcol>
          <ttcol align='center'>has criteria</th>
                  <th align="center">Has a child that meets the selection criteria</ttcol>
          <ttcol align='center'>returned criteria</th>
                  <th align="center">Returned IMAP4rev2/LIST-EXTENDED attributes and CHILDINFO</ttcol>

          <c>no</c>
          <c>no</c>
          <c>no</c>
          <c>no LIST response returned</c>

          <c>yes</c>
          <c>no</c>
          <c>no</c>
          <c>no LIST response returned</c>

          <c>no</c>
          <c>yes</c>
          <c>no</c>
          <c>(\NonExistent &lt;attr&gt;)</c>

          <c>yes</c>
          <c>yes</c>
          <c>no</c>
          <c>(&lt;attr&gt;)</c>

          <c>no</c>
          <c>no</c>
          <c>yes</c>
          <c>(\NonExistent) CHILDINFO</th>
                </tr>
              </thead>
              <tbody>
                <tr>
                  <td align="center">no</td>
                  <td align="center">no</td>
                  <td align="center">no</td>
                  <td align="center">no LIST response returned</td>
                </tr>
                <tr>
                  <td align="center">yes</td>
                  <td align="center">no</td>
                  <td align="center">no</td>
                  <td align="center">no LIST response returned</td>
                </tr>
                <tr>
                  <td align="center">no</td>
                  <td align="center">yes</td>
                  <td align="center">no</td>
                  <td align="center">(\NonExistent &lt;attr&gt;)</td>
                </tr>
                <tr>
                  <td align="center">yes</td>
                  <td align="center">yes</td>
                  <td align="center">no</td>
                  <td align="center">(&lt;attr&gt;)</td>
                </tr>
                <tr>
                  <td align="center">no</td>
                  <td align="center">no</td>
                  <td align="center">yes</td>
                  <td align="center">(\NonExistent) + CHILDINFO</c>

          <c>yes</c>
          <c>no</c>
          <c>yes</c>
          <c>() CHILDINFO</td>
                </tr>
                <tr>
                  <td align="center">yes</td>
                  <td align="center">no</td>
                  <td align="center">yes</td>
                  <td align="center">() + CHILDINFO</c>

          <c>no</c>
          <c>yes</c>
          <c>yes</c>
          <c>(\NonExistent CHILDINFO</td>
                </tr>
                <tr>
                  <td align="center">no</td>
                  <td align="center">yes</td>
                  <td align="center">yes</td>
                  <td align="center">(\NonExistent &lt;attr&gt;) + CHILDINFO</c>

          <c>yes</c>
          <c>yes</c>
          <c>yes</c>
          <c>(&lt;attr&gt;) CHILDINFO</td>
                </tr>
                <tr>
                  <td align="center">yes</td>
                  <td align="center">yes</td>
                  <td align="center">yes</td>
                  <td align="center">(&lt;attr&gt;) + CHILDINFO</c>

          <postamble>where CHILDINFO</td>
                </tr>
              </tbody>
            </table>
            <t>where &lt;attr&gt; is one or more attributes that correspond to the
          selection criteria; for example, for the SUBSCRIBED option option, the &lt;attr&gt;
          is \Subscribed.</postamble>
        </texttable> \Subscribed.</t>
          </section>
          <section anchor="oldname" title="OLDNAME numbered="true" toc="default">
            <name>OLDNAME Extended Data Item"> Item</name>
            <t>The OLDNAME extended data item is included when
        a mailbox name is created (with the CREATE command), renamed (with the RENAME command) command),
        or deleted (with the DELETE command). (When a mailbox is deleted deleted, the "\NonExistent" attribute
        is also included.) IMAP extensions can specify other conditions when
            the OLDNAME extended data item should be included.</t>

            <t>If the server allows de-normalized denormalized mailbox names (see <xref target="mailbox-naming"/>) target="mailbox-naming" format="default"/>)
        in SELECT/EXAMINE, CREATE, RENAME RENAME, or DELETE, it SHOULD <bcp14>SHOULD</bcp14> return an unsolicited LIST response
        that includes the OLDNAME extended data item, whenever the supplied mailbox name differs from
        the resulting normalized mailbox name. From the client point of view view, this is indistinguishable
            from another user renaming or deleting the mailbox, as specified in the previous paragraph.</t>

	    <t>
<figure><artwork>
  A deleted mailbox can be announced like this: as follows:
	    </t>
<sourcecode type="">
  S: * LIST (\NonExistent) "." "INBOX.DeletedMailbox"
</sourcecode>

<t>
  Example of a renamed mailbox:
</t>
<sourcecode type="">
  S: * LIST () "/" "NewMailbox" ("OLDNAME" ("OldMailbox"))
</artwork></figure>
        </t>
</sourcecode>
          </section>

          <section anchor="examples" title='LIST numbered="true" toc="default">
            <name>LIST Command Examples'> Examples</name>
            <t>
This example shows some uses of the basic LIST command:
<figure><artwork>
	    </t>
	    <t>
Example:
	    </t>
<sourcecode type="">
  C: A101 LIST "" ""
  S: * LIST (\Noselect) "/" ""
  S: A101 OK LIST Completed
  C: A102 LIST #news.comp.mail.misc ""
  S: * LIST (\Noselect) "." #news.
  S: A102 OK LIST Completed
  C: A103 LIST /usr/staff/jones ""
  S: * LIST (\Noselect) "/" /
  S: A103 OK LIST Completed
  C: A202 LIST ~/Mail/ %
  S: * LIST (\Noselect) "/" ~/Mail/foo
  S: * LIST () "/" ~/Mail/meetings
  S: A202 OK LIST completed
</artwork></figure>
</t>
</sourcecode>
            <t>
Extended examples:
      <list style="format %d:" counter="Examples" hangIndent="0">
        <!-- ================================================== -->
            </t>

<ol group="Examples" spacing="normal" type="%d:">
        <li>
                <t>
        The first example shows the complete local hierarchy that will be
        used for the other examples.
        <figure><artwork>
                </t>
<sourcecode type="">
  C: A01 LIST "" "*"
  S: * LIST (\Marked \NoInferiors) "/" "inbox"
  S: * LIST () "/" "Fruit"
  S: * LIST () "/" "Fruit/Apple"
  S: * LIST () "/" "Fruit/Banana"
  S: * LIST () "/" "Tofu"
  S: * LIST () "/" "Vegetable"
  S: * LIST () "/" "Vegetable/Broccoli"
  S: * LIST () "/" "Vegetable/Corn"
  S: A01 OK done
        </artwork></figure>
        </t>

        <!-- ================================================== -->
</sourcecode>
              </li>
        <li>
                <t>
        In the next example, we will see the subscribed mailboxes.  This is
        similar to, but not equivalent with with, the now deprecated, deprecated &lt;LSUB "" "*"&gt;
        (see <xref target="RFC3501"/> target="RFC3501" format="default"/> for more details on the LSUB command). Note that the mailbox
        called "Fruit/Peach" is subscribed to, but it does not actually exist
        (perhaps it was deleted while still subscribed).  The "Fruit"
        mailbox is not subscribed to, but it has two subscribed children.
        The "Vegetable" mailbox is subscribed and has two children; one
        of them is subscribed as well.
        <figure><artwork>
                </t>
<sourcecode type="">
  C: A02 LIST (SUBSCRIBED) "" "*"
  S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
  S: * LIST (\Subscribed) "/" "Fruit/Banana"
  S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
  S: * LIST (\Subscribed) "/" "Vegetable"
  S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
  S: A02 OK done
        </artwork></figure>
        </t>

        <!-- ================================================== -->
</sourcecode>
              </li>
        <li>
                <t>
        The next example shows the use of the CHILDREN option.  The client,
        without having to list the second level of hierarchy, now knows which
        of the top-level mailboxes have submailboxes (children) and which do
        not.  Note that it's not necessary for the server to return the
        \HasNoChildren attribute for the inbox, because the \NoInferiors attribute
        already implies that, that and has a stronger meaning.
        <figure><artwork>
                </t>
<sourcecode type="">
  C: A03 LIST () "" "%" RETURN (CHILDREN)
  S: * LIST (\Marked \NoInferiors) "/" "inbox"
  S: * LIST (\HasChildren) "/" "Fruit"
  S: * LIST (\HasNoChildren) "/" "Tofu"
  S: * LIST (\HasChildren) "/" "Vegetable"
  S: A03 OK done
        </artwork></figure>
        </t>

        <!-- ================================================== -->
</sourcecode>
              </li>
        <li>
                <t>
        In this example, we see more mailboxes that reside on another server.
        This is similar to the command
        &lt;RLIST "" "%"&gt;.
        <figure><artwork>
                </t>
<sourcecode type="">
  C: A04 LIST (REMOTE) "" "%" RETURN (CHILDREN)
  S: * LIST (\Marked \NoInferiors) "/" "inbox"
  S: * LIST (\HasChildren) "/" "Fruit"
  S: * LIST (\HasNoChildren) "/" "Tofu"
  S: * LIST (\HasChildren) "/" "Vegetable"
  S: * LIST (\Remote \HasNoChildren) "/" "Bread"
  S: * LIST (\HasChildren \Remote) "/" "Meat"
  S: A04 OK done
        </artwork></figure>
        </t>

        <!-- ================================================== -->
</sourcecode>
              </li>
        <li>
                <t>
        The following example also requests the server to include mailboxes
        that reside on another server.  The server returns information about
        all mailboxes that are subscribed.  This is similar to the command
        &lt;RLSUB "" "*"&gt; (see <xref target="RFC2193"/> target="RFC2193" format="default"/> for more details
        on RLSUB).  We also see the use of two selection options.
        <figure><artwork>
                </t>
 <sourcecode type="">
  C: A05 LIST (REMOTE SUBSCRIBED) "" "*"
  S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
  S: * LIST (\Subscribed) "/" "Fruit/Banana"
  S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
  S: * LIST (\Subscribed) "/" "Vegetable"
  S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
  S: * LIST (\Remote \Subscribed) "/" "Bread"
  S: A05 OK done
        </artwork></figure>
        </t>

        <!-- ================================================== -->
 </sourcecode>
              </li>
        <li>
                <t>
        The following example requests the server to include mailboxes
        that reside on another server.  The server is asked to return
        subscription information for all returned mailboxes.
        This is different from the example above.
        <vspace blankLines="1"/>
                </t>
                <t>
        Note that the output of this command is not a superset of the output
        in the previous example, as it doesn't include a LIST response for the
        non-existent "Fruit/Peach".
        <figure><artwork>
                </t>
 <sourcecode type="">
  C: A06 LIST (REMOTE) "" "*" RETURN (SUBSCRIBED)
  S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
  S: * LIST () "/" "Fruit"
  S: * LIST () "/" "Fruit/Apple"
  S: * LIST (\Subscribed) "/" "Fruit/Banana"
  S: * LIST () "/" "Tofu"
  S: * LIST (\Subscribed) "/" "Vegetable"
  S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
  S: * LIST () "/" "Vegetable/Corn"
  S: * LIST (\Remote \Subscribed) "/" "Bread"
  S: * LIST (\Remote) "/" "Meat"
  S: A06 OK done
        </artwork></figure>
        </t>

        <!-- ================================================== -->
</sourcecode>
              </li>
        <li>
                <t>
        The following example demonstrates the difference between the
        \HasChildren attribute and the CHILDINFO extended data item.
        <vspace blankLines="1"/>
                </t>
                <t>
        Let's assume there is the following hierarchy:
        <figure><artwork>
                </t>
<sourcecode type="">
  C: C01 LIST "" "*"
  S: * LIST (\Marked \NoInferiors) "/" "inbox"
  S: * LIST () "/" "Foo"
  S: * LIST () "/" "Foo/Bar"
  S: * LIST () "/" "Foo/Baz"
  S: * LIST () "/" "Moo"
  S: C01 OK done
        </artwork></figure>
</sourcecode>
                <t>
        If the client asks RETURN (CHILDREN), it will get this:

        <figure><artwork>
                </t>
<sourcecode type="">
  C: CA3 LIST "" "%" RETURN (CHILDREN)
  S: * LIST (\Marked \NoInferiors) "/" "inbox"
  S: * LIST (\HasChildren) "/" "Foo"
  S: * LIST (\HasNoChildren) "/" "Moo"
  S: CA3 OK done
        </artwork></figure>

        A)
</sourcecode>
<ol spacing="normal" type="%C)">
  <li><t>
        Let's also assume that the mailbox "Foo/Baz" is the only
        subscribed mailbox. Then we get this result:

        <figure><artwork>

                </t>
<sourcecode type="">
  C: C02 LIST (SUBSCRIBED) "" "*"
  S: * LIST (\Subscribed) "/" "Foo/Baz"
  S: C02 OK done
        </artwork></figure>
</sourcecode>
                <t>
        Now, if the client issues &lt;LIST (SUBSCRIBED) "" "%"&gt;, the server will
        return no mailboxes (as the mailboxes "Moo", "Foo", and "Inbox" are NOT
        subscribed). However, if the client issues this:

        <figure><artwork>

                </t>
<sourcecode type="">
  C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
  S: * LIST () "/" "Foo" ("CHILDINFO" ("SUBSCRIBED"))
  S: C04 OK done
        </artwork></figure>

       (i.e.,
</sourcecode>
                <t>

       (that is, the mailbox "Foo" is not subscribed, but it has a child that is.)
        <vspace blankLines="1"/>
        A1) If is), then A1 or A2 occurs.
                </t>
        <ol spacing="normal" type="A%d)">
         <li><t>If the mailbox "Foo" had also been subscribed, the last
        command would return this:

        <figure><artwork> this:</t>

<sourcecode type="">
  C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
  S: * LIST (\Subscribed) "/" "Foo" ("CHILDINFO"
      ("SUBSCRIBED"))
  S: C04 OK done
        </artwork></figure>
</sourcecode>

       <t> or even this:

        <figure><artwork> this:</t>

<sourcecode type="">
  C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
  S: * LIST (\Subscribed \HasChildren) "/" "Foo"
      ("CHILDINFO" ("SUBSCRIBED"))
  S: C04 OK done
        </artwork></figure>

        A2)
	 </sourcecode></li>
	 <li>
       <t>
        If we assume instead that the mailbox "Foo" is not part of the
        original hierarchy and is not subscribed, the last command will
        give this result:

        <figure><artwork>
                </t>
<sourcecode type="">
  C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
  S: * LIST (\NonExistent) "/" "Foo" ("CHILDINFO"
      ("SUBSCRIBED"))
  S: C04 OK done
        </artwork></figure>

        B) Now,
</sourcecode></li></ol></li>

        <li><t>Now, let's assume that no mailbox is subscribed. In this case,
        the command &lt;LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"&gt; will return
        no responses, as there are no subscribed children (even though
        "Foo" has children).
        <vspace blankLines="1"/>
        C) And
                </t></li>

        <li><t>And finally, suppose that only the mailboxes "Foo" and "Moo" are
        subscribed.  In that case, we see this result:

        <figure><artwork>
                </t>
<sourcecode type="">
  C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" RETURN
      (CHILDREN)
  S: * LIST (\HasChildren \Subscribed) "/" "Foo"
  S: * LIST (\HasNoChildren \Subscribed) "/" "Moo"
  S: C04 OK done
        </artwork></figure>
</sourcecode>
                <t>

        (which means that the mailbox "Foo" has children, but none of them
        is subscribed).
        </t>

        <!-- ================================================== -->
                </t></li></ol>
              </li>
        <li>
                <t>
        The following example demonstrates that the CHILDINFO extended data item
        is returned whether or not children child mailboxes match the canonical LIST pattern.
        <vspace blankLines="1"/>
                </t>
                <t>
        Let's assume there is the following hierarchy:

        <figure><artwork>

                </t>
<sourcecode type="">
  C: D01 LIST "" "*"
  S: * LIST (\Marked \NoInferiors) "/" "inbox"
  S: * LIST () "/" "foo2"
  S: * LIST () "/" "foo2/bar1"
  S: * LIST () "/" "foo2/bar2"
  S: * LIST () "/" "baz2"
  S: * LIST () "/" "baz2/bar2"
  S: * LIST () "/" "baz2/bar22"
  S: * LIST () "/" "baz2/bar222"
  S: * LIST () "/" "eps2"
  S: * LIST () "/" "eps2/mamba"
  S: * LIST () "/" "qux2/bar2"
  S: D01 OK done
        </artwork></figure>
</sourcecode>
                <t>

        And that the following mailboxes are subscribed:

        <figure><artwork>

                </t>
<sourcecode type="">
  C: D02 LIST (SUBSCRIBED) "" "*"
  S: * LIST (\Subscribed) "/" "foo2/bar1"
  S: * LIST (\Subscribed) "/" "foo2/bar2"
  S: * LIST (\Subscribed) "/" "baz2/bar2"
  S: * LIST (\Subscribed) "/" "baz2/bar22"
  S: * LIST (\Subscribed) "/" "baz2/bar222"
  S: * LIST (\Subscribed) "/" "eps2"
  S: * LIST (\Subscribed) "/" "eps2/mamba"
  S: * LIST (\Subscribed) "/" "qux2/bar2"
  S: D02 OK done
        </artwork></figure>
</sourcecode>
                <t>

        The client issues the following command first:

        <figure><artwork>

                </t>
 <sourcecode type="">
  C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*2"
  S: * LIST () "/" "foo2" ("CHILDINFO" ("SUBSCRIBED"))
  S: * LIST (\Subscribed) "/" "foo2/bar2"
  S: * LIST (\Subscribed) "/" "baz2/bar2"
  S: * LIST (\Subscribed) "/" "baz2/bar22"
  S: * LIST (\Subscribed) "/" "baz2/bar222"
  S: * LIST (\Subscribed) "/" "eps2" ("CHILDINFO" ("SUBSCRIBED"))
  S: * LIST (\Subscribed) "/" "qux2/bar2"
  S: D03 OK done
        </artwork></figure>
 </sourcecode>
                <t>
        and the server may also include the following (but this would violate a SHOULD NOT restriction in Section 3.5, <xref target="childinfo"/>, because CHILDINFO is redundant)

        <figure><artwork> redundant):

                </t>
<sourcecode type="">
  S: * LIST () "/" "baz2" ("CHILDINFO" ("SUBSCRIBED"))
  S: * LIST (\NonExistent) "/" "qux2" ("CHILDINFO" ("SUBSCRIBED"))
        </artwork></figure>
</sourcecode>
                <t>

        The CHILDINFO extended data item is returned for mailboxes "foo2", "baz2",
        and "eps2", "eps2" because all of them have subscribed children,
        even though for the mailbox "foo2" "foo2", only one of the two subscribed
        children matches the pattern, pattern; for the mailbox "baz2" "baz2", all of the subscribed
        children match the pattern, pattern; and for the mailbox "eps2" "eps2", none of the
        subscribed children matches match the pattern.
        <vspace blankLines="1"/>
                </t>
                <t>
        Note that if the client issues

        <figure><artwork> the following:

                </t>
<sourcecode type="">
  C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*"
  S: * LIST () "/" "foo2" ("CHILDINFO" ("SUBSCRIBED"))
  S: * LIST (\Subscribed) "/" "foo2/bar1"
  S: * LIST (\Subscribed) "/" "foo2/bar2"
  S: * LIST () "/" "baz2" ("CHILDINFO" ("SUBSCRIBED"))
  S: * LIST (\Subscribed) "/" "baz2/bar2"
  S: * LIST (\Subscribed) "/" "baz2/bar22"
  S: * LIST (\Subscribed) "/" "baz2/bar222"
  S: * LIST (\Subscribed) "/" "eps2" ("CHILDINFO" ("SUBSCRIBED"))
  S: * LIST (\Subscribed) "/" "eps2/mamba"
  S: * LIST (\Subscribed) "/" "qux2/bar2"
  S: D03 OK done
        </artwork></figure>

        The
</sourcecode>
                <t>

        the LIST responses for mailboxes "foo2", "baz2", and "eps2" still have
        the CHILDINFO extended data item, even though this information
        is redundant and the client can determine it by itself.
                </t>

        <!-- ================================================== -->
              </li>
        <li>
                <t>
        The following example shows usage of an extended syntax for the mailbox pattern.
        It also demonstrates that the presence of the CHILDINFO extended data item
        doesn't necessarily imply \HasChildren.

        <figure><artwork>

                </t>
<sourcecode type="">
  C: a1 LIST "" ("foo")
  S: * LIST () "/" foo
  S: a1 OK done

  C: a2 LIST (SUBSCRIBED) "" "foo/*"
  S: * LIST (\Subscribed \NonExistent) "/" foo/bar
  S: a2 OK done

  C: a3 LIST (SUBSCRIBED RECURSIVEMATCH) "" foo RETURN (CHILDREN)
  S: * LIST (\HasNoChildren) "/" foo ("CHILDINFO" ("SUBSCRIBED"))
  S: a3 OK done
        </artwork></figure>
        </t>

        <!-- ================================================== -->
</sourcecode>
              </li>
        <li>
                <t>
        The following example shows how a server that supports missing
        mailbox hierarchy elements can signal to a client that didn't
        specify the RECURSIVEMATCH selection option that there is
        a child mailbox that matches the selection criteria.

        <figure><artwork>

                </t>
<sourcecode type="">
  C: a1 LIST (REMOTE) "" *
  S: * LIST () "/" music/rock
  S: * LIST (\Remote) "/" also/jazz
  S: a1 OK done

  C: a2 LIST () "" %
  S: * LIST (\NonExistent \HasChildren) "/" music
  S: a2 OK done

  C: a3 LIST (REMOTE) "" %
  S: * LIST (\NonExistent \HasChildren) "/" music
  S: * LIST (\NonExistent \HasChildren) "/" also
  S: a3 OK done

  C: a3.1 LIST "" (% music/rock)
  S: * LIST () "/" music/rock
  S: a3.1 OK done
        </artwork></figure>
</sourcecode>
                <t>

   Because "music/rock" is the only mailbox under "music", there's no
   need for the server to also return "music". However However, clients must
   handle both cases.
                </t>

        <!-- ================================================== -->
              </li>
        <li>
                <t>
        The following examples show use of the STATUS return option.

        <figure><artwork>

                </t>
<sourcecode type="">
  C: A01 LIST "" % RETURN (STATUS (MESSAGES UNSEEN))
  S: * LIST () "."  "INBOX"
  S: * STATUS "INBOX" (MESSAGES 17 UNSEEN 16)
  S: * LIST () "." "foo"
  S: * STATUS "foo" (MESSAGES 30 UNSEEN 29)
  S: * LIST (\NoSelect) "." "bar"
  S: A01 OK List completed.
        </artwork></figure>
</sourcecode>
                <t>

        The "bar" mailbox isn't selectable, so it has no STATUS reply.

        <figure><artwork>

                </t>
<sourcecode type="">
  C: A02 LIST (SUBSCRIBED RECURSIVEMATCH) "" % RETURN (STATUS
       (MESSAGES))
  S: * LIST (\Subscribed) "."  "INBOX"
  S: * STATUS "INBOX" (MESSAGES 17)
  S: * LIST () "." "foo" (CHILDINFO ("SUBSCRIBED"))
  S: A02 OK List completed.
        </artwork></figure>
</sourcecode>
                <t>

   The LIST reply for "foo" is returned because it has matching
   children, but no STATUS reply is returned because "foo" itself
   doesn't match the selection criteria.
                </t>

        <!-- ================================================== -->
      </list>
      </t>
              </li>
            </ol>
          </section>
        </section>
        <section title='NAMESPACE Command'>
      <iref item='NAMESPACE (command)'/>

   <t>
   <list style='hanging' hangIndent='12'>
   <t hangText='Arguments:'>none</t>

   <t hangText='Responses:'>REQUIRED numbered="true" toc="default">
          <name>NAMESPACE Command</name>
          <iref item="NAMESPACE (command)" subitem="" primary="false"/>
          <dl newline="false" spacing="normal" indent="14">
            <dt>Arguments:</dt>
            <dd>none</dd>
            <dt>Responses:</dt>
            <dd>
            <dl spacing="compact">
	      <dt><bcp14>REQUIRED</bcp14> untagged responses: NAMESPACE</t>

   <t hangText='Result:'>OK - command completed<vspace/>
               NO - Can't responses:</dt><dd>NAMESPACE</dd>
	    </dl>
	    </dd>
            <dt>Result:</dt>
            <dd>
	     <dl spacing="compact">
              <dt>OK -</dt><dd>command completed</dd>
              <dt>NO -</dt><dd>Can't complete the command<vspace/>
               BAD - arguments invalid</t>
   </list>
   </t> command</dd>
              <dt>BAD -</dt><dd>arguments invalid</dd>
	     </dl>
            </dd>
          </dl>
          <t>
     The NAMESPACE command causes a single untagged NAMESPACE response to be returned.
     The untagged NAMESPACE response contains the prefix
     and hierarchy delimiter to the server's Personal
     Namespace(s), Other Users' Namespace(s), and Shared
     Namespace(s) that the server wishes to expose. The
     response will contain a NIL for any namespace class
     that is not available. The namespace-response-extensions ABNF non terminal non-terminal
     is defined for extensibility and MAY <bcp14>MAY</bcp14> be included in the NAMESPACE response.

 <!--No longer the best practice (see BCP 178):
     namespace-response-extensions which are not on the IETF
     standards track, MUST be prefixed with an "X-".
 -->
               </t>
          <t>Example 1:</t>
          <t>In this example example, a server supports a single personal namespace. Personal Namespace.  No leading
   prefix is used on personal mailboxes mailboxes, and "/" is the hierarchy
   delimiter.</t>

<figure><artwork>
<sourcecode type="">
  C: A001 NAMESPACE
  S: * NAMESPACE (("" "/")) NIL NIL
  S: A001 OK NAMESPACE command completed
</artwork></figure>
</sourcecode>
          <t>Example 2:</t>
          <t>A user logged on anonymously to a server.  No personal mailboxes
      are associated with the anonymous user user, and the user does not have
      access to the Other Users' Namespace.  No prefix is required to
      access shared mailboxes mailboxes, and the hierarchy delimiter is "."</t>

<figure><artwork>
<sourcecode type="">
  C: A001 NAMESPACE
  S: * NAMESPACE NIL NIL (("" "."))
  S: A001 OK NAMESPACE command completed
</artwork></figure>
</sourcecode>
          <t>Example 3:</t>
          <t>A server that contains a Personal Namespace and a single Shared
      Namespace.</t>

<figure><artwork>
<sourcecode type="">
  C: A001 NAMESPACE
  S: * NAMESPACE (("" "/")) NIL (("Public Folders/" "/"))
  S: A001 OK NAMESPACE command completed
</artwork></figure>
</sourcecode>
          <t>Example 4:</t>
          <t>A server that contains a Personal Namespace, Other Users'
      Namespace
      Namespace, and multiple Shared Namespaces.  Note that the hierarchy
      delimiter used within each namespace can be different.</t>

<figure><artwork>
<sourcecode type="">
  C: A001 NAMESPACE
  S: * NAMESPACE (("" "/")) (("~" "/")) (("#shared/" "/")
      ("#public/" "/")("#ftp/" "/")("#news." "."))
  S: A001 OK NAMESPACE command completed
</artwork></figure>
</sourcecode>
          <t>
   The prefix string allows a client to do things such as automatically
   creating
   create personal mailboxes or LISTing LIST all available mailboxes within
   a namespace.
          </t>
          <t>Example 5:</t>
          <t>A server that supports only the Personal Namespace, with a
      leading prefix of INBOX to personal mailboxes and a hierarchy
	  delimiter of "."</t>

<figure><artwork><![CDATA[ ".".</t>

<sourcecode type="">
  C: A001 NAMESPACE
  S: * NAMESPACE (("INBOX." ".")) NIL  NIL
  S: A001 OK NAMESPACE command completed

               <
</sourcecode>

<t>
Automatically create a mailbox to store sent items.> items.
</t>

<sourcecode type="">
  C: A002 CREATE "INBOX.Sent Mail"
  S: A002 OK CREATE command completed
]]></artwork></figure>
</sourcecode>
          <t>
   Although typically a server will typically support only a single Personal
   Namespace, and a single Other User's Namespace, circumstances exist
   where there MAY <bcp14>MAY</bcp14> be multiples of these, and a client MUST <bcp14>MUST</bcp14> be prepared
   for them.   If a client is configured such that it is required to
   create a certain mailbox, there can be circumstances where it is
   unclear which Personal Namespaces it should create the mailbox in.
   In these situations situations, a client SHOULD <bcp14>SHOULD</bcp14> let the user select which
   namespaces to create the mailbox in in, or just use the first personal namespace. Personal Namespace.
          </t>
          <t>Example 6:</t>
          <t>In this example, a server supports two Personal Namespaces.  In
      addition to the regular Personal Namespace, the user has an
      additional personal namespace to allow Personal Namespace that allows access to mailboxes in an
      MH format mailstore.</t>
          <t>The client is configured to save a copy of all mail sent by the
        user into a mailbox with the \Sent attribute (see <xref target='list-resp'/>). target="list-resp" format="default"/>).
        Furthermore, after a message is deleted from a mailbox, the client is configured
        to move that message to a mailbox with the \Trash attribute.
        The server signals with the \NonExistent mailbox attribute <!--in LIST responses-->
        that the corresponding mailboxes don't exist yet, yet and that it is possible
        to create them. Once created, they could be used for the \Sent or
        \Trash purposes purposes, and the server will no longer include
        the \NonExistent mailbox attribute for them.
          </t>
          <t>Note that this example demonstrates how some extension parameters can
      be passed to further describe the #mh namespace. See the fictitious "X-PARAM"
	  extension parameter.</t>

<figure><artwork><![CDATA[

<sourcecode type="">
  C: A001 NAMESPACE
  S: * NAMESPACE (("" "/")("#mh/" "/" "X-PARAM"
      ("FLAG1" "FLAG2"))) NIL NIL
  S: A001 OK NAMESPACE command completed

  C: A002 LIST (SPECIAL-USE) "" "*"
  S: * LIST (\NonExistent \Archive) "/" Archives
  S: * LIST (\NonExistent \Drafts) "/" Drafts
  S: * LIST (\NonExistent \Junk) "/" Junk
  S: * LIST (\NonExistent \Sent) "/" "Sent Mail"
  S: * LIST (\NonExistent \Trash) "/" "Deleted Items"
  S: A002 OK LIST Completed

  C: A003 LIST (SPECIAL-USE) "#mh/" "*"
  S: * LIST (\NonExistent \Archive) "/" "#mh/Archives"
  S: * LIST (\NonExistent \Drafts) "/" "#mh/Drafts"
  S: * LIST (\NonExistent \Junk) "/" "#mh/Junk"
  S: * LIST (\NonExistent \Sent) "/" "#mh/Sent Mail"
  S: * LIST (\NonExistent \Trash) "/" "#mh/Deleted Items"
  S: A003 OK LIST Completed

               <
</sourcecode>

  <t>
    It is desired to keep only one copy of sent mail.
    It is unclear which Personal Namespace the client
    should use to create the 'Sent Mail' mailbox.
    The user is prompted to select a namespace namespace, and only
    one 'Sent Mail' mailbox is created. > created.</t>

<sourcecode type="">
  C: A004 CREATE "Sent Mail"
  S: A004 OK CREATE command completed

               <
</sourcecode>

<t> The client is designed so that it keeps two
    'Deleted Items' mailboxes, one for each namespace. > namespace.</t>

<sourcecode type="">
  C: A005 CREATE "Delete Items"
  S: A005 OK CREATE command completed

  C: A006 CREATE "#mh/Deleted Items"
  S: A006 OK CREATE command completed
]]></artwork></figure>
</sourcecode>

          <t>The next level of hierarchy following the Other Users' Namespace
   prefix SHOULD <bcp14>SHOULD</bcp14> consist of &lt;username&gt;, where &lt;username&gt; is
   a <!--canonical-->user user name as per the LOGIN or AUTHENTICATE command.
          </t>
          <t>
   A client can construct a LIST command by appending a "%" to the Other
   Users' Namespace prefix to discover the Personal Namespaces of other
   users that are available to the currently authenticated user.
          </t>
          <t>
   In response to such a LIST command, a server SHOULD NOT <bcp14>SHOULD NOT</bcp14> return user
   names that have not granted access to their personal mailboxes to the
   user in question.
          </t>
          <t>
   A server MAY <bcp14>MAY</bcp14> return a LIST response containing only the names of
   users that have explicitly granted access to the user in question.
          </t>
          <t>
   Alternatively, a server MAY <bcp14>MAY</bcp14> return NO to such a LIST command,
   requiring that a user name be included with the Other Users'
   Namespace prefix before listing any other user's mailboxes.
          </t>
          <t>Example 7:</t>
          <t>A server that supports providing a list of other user's
      mailboxes that are accessible to the currently logged on user.</t>

<figure><artwork><![CDATA[
<sourcecode type="">
  C: A001 NAMESPACE
  S: * NAMESPACE (("" "/")) (("Other Users/" "/")) NIL
  S: A001 OK NAMESPACE command completed

  C: A002 LIST "" "Other Users/%"
  S: * LIST () "/" "Other Users/Mike"
  S: * LIST () "/" "Other Users/Karen"
  S: * LIST () "/" "Other Users/Matthew"
  S: * LIST () "/" "Other Users/Tesa"
  S: A002 OK LIST command completed
]]></artwork></figure>
</sourcecode>
          <t>Example 8:</t>
          <t>A server that does not support providing a list of other user's
      mailboxes that are accessible to the currently logged on user.
      The mailboxes are listable if the client includes the name of the
      other user with the Other Users' Namespace prefix.</t>

<figure><artwork><![CDATA[

<sourcecode type="">
  C: A001 NAMESPACE
  S: * NAMESPACE (("" "/")) (("#Users/" "/")) NIL
  S: A001 OK NAMESPACE command completed

         <
</sourcecode>
  <t>
    In this example, the currently logged on user has access to
    the Personal Namespace of user Mike, but the server chose to
    suppress this information in the LIST response.  However,
    by appending the user name Mike (received through user input)
    to the Other Users' Namespace prefix, the client is able
    to get a listing of the personal mailboxes of user Mike. >
  </t>
 <sourcecode type="">
  C: A002 LIST "" "#Users/%"
  S: A002 NO The requested item could not be found.

  C: A003 LIST "" "#Users/Mike/%"
  S: * LIST () "/" "#Users/Mike/INBOX"
  S: * LIST () "/" "#Users/Mike/Foo"
  S: A003 OK LIST command completed.
]]></artwork></figure>
</sourcecode>
          <t>A prefix string might not contain a hierarchy delimiter, because
      in some cases cases, it is not needed as part of the prefix.
          </t>
          <t>Example 9:</t>
          <t>A server that allows access to the Other Users' Namespace by
      prefixing the others' mailboxes with a '~' followed by &lt;username&gt;,
      where &lt;username&gt; is a user name as per the LOGIN or
      AUTHENTICATE command.</t>

<figure><artwork><![CDATA[

<sourcecode type="">
  C: A001 NAMESPACE
  S: * NAMESPACE (("" "/")) (("~" "/")) NIL
  S: A001 OK NAMESPACE command completed

               < List
</sourcecode>

<t>List the mailboxes for user mark >
</t>
<sourcecode type="">
  C: A002 LIST "" "~mark/%"
  S: * LIST () "/" "~mark/INBOX"
  S: * LIST () "/" "~mark/foo"
  S: A002 OK LIST command completed
]]></artwork></figure>
</sourcecode>
</section>

        <section title='STATUS Command'>
      <iref item='STATUS (command)'/>

   <t>
   <list style='hanging' hangIndent='12'>
   <t hangText='Arguments:'>mailbox name<vspace/>
               status anchor="status-command" numbered="true" toc="default">
          <name>STATUS Command</name>
          <iref item="STATUS (command)" subitem="" primary="false"/>
          <dl newline="false" spacing="normal" indent="14">
            <dt>Arguments:</dt>
            <dd>
              <t>mailbox name</t>
              <t>status data item names</t>

   <t hangText='Responses:'>REQUIRED
            </dd>
            <dt>Responses:</dt>
            <dd>
            <dl spacing="compact">
	      <dt><bcp14>REQUIRED</bcp14> untagged responses: STATUS</t>

   <t hangText='Result:'>OK - status completed<vspace/>
               NO - status responses:</dt><dd>STATUS</dd>
	    </dl>
	    </dd>
            <dt>Result:</dt>
            <dd>
	       <dl spacing="compact">
              <dt>OK -</dt><dd>status completed</dd>
              <dt>NO -</dt><dd>status failure: no status for that name<vspace/>
               BAD - command name</dd>
              <dt>BAD -</dt><dd>command unknown or arguments invalid</t>
   </list>
   </t> invalid</dd>
	       </dl>
	    </dd>
          </dl>
          <t>
      The STATUS command requests the status of the indicated mailbox.
      It does not change the currently selected mailbox, nor does it
      affect the state of any messages in the queried mailbox.
          </t>
          <t>
      The STATUS command provides an alternative to opening a second
      IMAP4rev2 connection and doing an EXAMINE command on a mailbox to
      query that mailbox's status without deselecting the current
      mailbox in the first IMAP4rev2 connection.
          </t>
          <t>
      Unlike the LIST command, the STATUS command is not guaranteed to
      be fast in its response.  Under certain circumstances, it can be
      quite slow. In some implementations, the server is obliged to
      open the mailbox read-only as "read-only" internally to obtain certain status
      information.  Also unlike the LIST command, the STATUS command
      does not accept wildcards.

           <list>
           <t>
          </t>

           <t indent="3">
           Note: The STATUS command is intended to access the
           status of mailboxes other than the currently selected
           mailbox.  Because the STATUS command can cause the
           mailbox to be opened internally, and because this
           information is available by other means on the selected
           mailbox, the STATUS command SHOULD NOT <bcp14>SHOULD NOT</bcp14> be used on the
           currently selected mailbox.
           However, servers MUST <bcp14>MUST</bcp14> be able to execute the STATUS
           command on the selected mailbox.
           <!--////Alexey: Should this be moved to the LIST return options section?-->
           (This might also implicitly happen when the STATUS return option is used
           in a LIST command). command.)
           </t>

           <t>
           <!--Bron suggests to say "clients can't expect for this to work" instead-->
           <t indent="3">
           The STATUS command MUST NOT <bcp14>MUST NOT</bcp14> be used as a "check for new
           messages in the selected mailbox" operation (refer to Sections
           <xref target='server-responses'/> target="server-responses" format="counter"/> and
           <xref target='exists'/> target="exists" format="counter"/> for more information about
           the proper method for new message checking).
           </t>

           <t>
           <t indent="3">
           STATUS SIZE (see below) can take a significant amount of time,
           depending upon server implementation. Clients should use
           STATUS SIZE cautiously.
           </t>
           </list>
   </t>
          <t>
      The currently defined status data items that can be requested are:

      <list style='hanging'>
      <t hangText='MESSAGES'>
          </t>
          <dl newline="true" spacing="normal">
            <dt>MESSAGES</dt>
            <dd>
              <iref item='MESSAGES item="MESSAGES (status item)'/> item)" subitem="" primary="false"/>
         The number of messages in the mailbox.</t>

      <t hangText='UIDNEXT'> mailbox.</dd>
            <dt>UIDNEXT</dt>
            <dd>
              <iref item='UIDNEXT item="UIDNEXT (status item)'/> item)" subitem="" primary="false"/>
         The next unique identifier value of the mailbox.  Refer to
         <xref target='uid-def'/> target="uid-def" format="default"/> for more information.</t>

      <t hangText='UIDVALIDITY'> information.</dd>
            <dt>UIDVALIDITY</dt>
            <dd>
              <iref item='UIDVALIDITY item="UIDVALIDITY (status item)'/> item)" subitem="" primary="false"/>
         The unique identifier validity value of the mailbox.  Refer to
         <xref target='uid-def'/> target="uid-def" format="default"/> for more information.</t>

      <t hangText='UNSEEN'> information.</dd>
            <dt>UNSEEN</dt>
            <dd>
              <iref item='UNSEEN item="UNSEEN (status item)'/> item)" subitem="" primary="false"/>
         The number of messages which that do not have the \Seen flag set.</t>

      <t hangText='DELETED'> set.</dd>
            <dt>DELETED</dt>
            <dd>
              <iref item='DELETED item="DELETED (status item)'/> item)" subitem="" primary="false"/>
         The number of messages which that have the \Deleted flag set.</t>

      <t hangText='SIZE'> set.</dd>
            <dt>SIZE</dt>
            <dd>
              <iref item='SIZE item="SIZE (status item)'/> item)" subitem="" primary="false"/>
       The total size of the mailbox in octets.  This is not strictly
       required to be an exact value, but it MUST <bcp14>MUST</bcp14> be equal to or greater
       than the sum of the values of the RFC822.SIZE FETCH message data
       items (see <xref target='fetch-command'/>) target="fetch-command" format="default"/>) of all messages in the mailbox.
       <!--///Alexey: Do we want this text in the base spec?
       When the "QUOTA" capability <xref target='QUOTA'/> is also supported, this value SHOULD be equal
       to the storage usage value used to enforce the "STORAGE" resource
       limit for this mailbox.  This way, the client can directly infer
       the quota usage.
       -->
      </t>
      </list>

   </t>

<figure><artwork>

      </dd>
          </dl>
	  <t>
Example:
	  </t>
<sourcecode type="">
  C: A042 STATUS blurdybloop (UIDNEXT MESSAGES)
  S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
  S: A042 OK STATUS completed
</artwork></figure>
</sourcecode>
        </section>
        <section title='APPEND Command'>
      <iref item='APPEND (command)'/> numbered="true" toc="default">
          <name>APPEND Command</name>
          <iref item="APPEND (command)" subitem="" primary="false"/>
          <dl newline="false" spacing="normal" indent="14">
            <dt>Arguments:</dt>
            <dd>
              <t>mailbox name</t>
              <t>
   <list style='hanging' hangIndent='12'>
   <t hangText='Arguments:'>mailbox name<vspace/>
               OPTIONAL
               <bcp14>OPTIONAL</bcp14> flag parenthesized list<vspace/>
               OPTIONAL list</t>
              <t>
               <bcp14>OPTIONAL</bcp14> date/time string<vspace/> string</t>
              <t>
               message literal</t>

   <t hangText='Responses:'>OPTIONAL
            </dd>
            <dt>Responses:</dt>
            <dd>
             <dl spacing="compact">
	       <dt><bcp14>OPTIONAL</bcp14> untagged response: LIST</t>

   <t hangText='Result:'>OK - append completed<vspace/>
               NO - append response:</dt><dd>LIST</dd>
	     </dl>
	    </dd>
            <dt>Result:</dt>
            <dd>
	       <dl spacing="compact">
              <dt>OK -</dt><dd>append completed</dd>
              <dt>NO -</dt><dd>append error: can't append to that mailbox, error<vspace/> error
                    in flags or date/time or message text<vspace/>
               BAD - command text</dd>
		    <dt>BAD -</dt><dd>command unknown or arguments invalid</t>
   </list>
   </t> invalid</dd>
	       </dl>
            </dd>
          </dl>
          <t>
      The APPEND command appends the literal argument as a new message
      to the end of the specified destination mailbox.  This argument
      SHOULD
      <bcp14>SHOULD</bcp14> be in the format of an <xref target='RFC-5322'/> target="RFC5322" format="default"/> or <xref
      target='I18N-HDRS'/> target="RFC6532" format="default"/> message.  8-bit
      characters are permitted in the message.  A server implementation
      that is unable to preserve 8-bit data properly MUST <bcp14>MUST</bcp14> be able to
      reversibly convert 8-bit APPEND data to 7-bit 7 bits using a <xref target='MIME-IMB'/> target="RFC2045" format="default"/>
      content transfer encoding.

           <list><t>

          </t>
           <t indent="3">
           Note: There may be exceptions, e.g., such as draft messages, in
           which required <xref target='RFC-5322'/> target="RFC5322" format="default"/> header fields are omitted in
           the message literal argument to APPEND.  The full
           implications of doing so must be understood and
           carefully weighed.
           </t></list>
           </t>

          <t>
      If a flag parenthesized list is specified, the flags SHOULD <bcp14>SHOULD</bcp14> be set
      in the resulting message; otherwise, the flag list of the
      resulting message is set to empty "empty" by default.
          </t>
          <t>
      If a date-time is specified, the internal date SHOULD <bcp14>SHOULD</bcp14> be set in
      the resulting message; otherwise, the internal date of the
      resulting message is set to the current date and time by default.
          </t>
          <t>
      If the append is unsuccessful for any reason, the mailbox MUST <bcp14>MUST</bcp14> be
      restored to its state before the APPEND attempt (other than possibly
      keeping the changed mailbox's UIDNEXT value); no partial
      appending is permitted.
          </t>
          <t>
      If the destination mailbox does not exist, a server MUST <bcp14>MUST</bcp14> return an
      error,
      error and MUST NOT <bcp14>MUST NOT</bcp14> automatically create the mailbox.  Unless it
      is certain that the destination mailbox can not cannot be created, the
      server MUST <bcp14>MUST</bcp14> send the response code "[TRYCREATE]" as the prefix of
      the text of the tagged NO response.  This gives a hint to the
      client that it can attempt a CREATE command and retry the APPEND
      if the CREATE is successful.
          </t>
          <t>
     On successful completion of an APPEND, the server returns
     an APPENDUID response code (see <xref target='server-status-responses'/>), target="server-status-responses" format="default"/>),
     unless specified otherwise specified below.
          </t>
          <t>
     In the case of a mailbox that has permissions set so that the client
     can APPEND to the mailbox, but not SELECT or EXAMINE it, the
     server MUST NOT <bcp14>MUST NOT</bcp14> send an APPENDUID response code as it
     would disclose information about the mailbox.
          </t>
          <t>
     In the case of a mailbox that has UIDNOTSTICKY status
     (see <xref target='server-status-responses'/>), target="server-status-responses" format="default"/>),
     the server MAY <bcp14>MAY</bcp14> omit the APPENDUID response code as
     it is not meaningful.
          </t>

<!--
   <t>
     If the server does not return the APPENDUID response
     codes, the client can discover this information by selecting the
     destination mailbox.  The location of messages placed in the
     destination mailbox by APPEND can be determined by using
     FETCH and/or SEARCH commands (e.g., for Message-ID or some unique
     marker placed in the message in an APPEND).
   </t>
-->
   <t>
      If the mailbox is currently selected, the normal new message
      actions SHOULD <bcp14>SHOULD</bcp14> occur.  Specifically, the server SHOULD <bcp14>SHOULD</bcp14> notify the
      client immediately via an untagged EXISTS response.  If the server
      does not do so, the client MAY <bcp14>MAY</bcp14> issue a NOOP command after one or more APPEND commands.
          </t>
          <t>
      If the server decides to convert (normalize) the mailbox name,
      it SHOULD <bcp14>SHOULD</bcp14> return an untagged LIST with an OLDNAME extended data item,
      with the OLDNAME value being the supplied mailbox name and the
      name parameter being the normalized mailbox name.
      (See <xref target='oldname'/> target="oldname" format="default"/> for more details.)
          </t>

<figure><artwork><![CDATA[

	  <t>
Example:
	  </t>
<sourcecode type="">
  C: A003 APPEND saved-messages (\Seen) {326}
  S: + Ready for literal data
  C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
  C: From: Fred Foobar <foobar@Blurdybloop.example> &lt;foobar@Blurdybloop.example&gt;
  C: Subject: afternoon meeting
  C: To: mooch@owatagu.siam.edu.example
  C: Message-Id: <B27397-0100000@Blurdybloop.example> &lt;B27397-0100000@Blurdybloop.example&gt;
  C: MIME-Version: 1.0
  C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
  C:
  C: Hello Joe, do you think we can meet at 3:30 tomorrow?
  C:
  S: A003 OK APPEND completed
]]></artwork></figure>

<figure><artwork><![CDATA[
</sourcecode>
<t>
 Example:
</t>
<sourcecode type="">
  C: A003 APPEND saved-messages (\Seen) {297+}
  C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
  C: From: Fred Foobar <foobar@example.com> &lt;foobar@example.com&gt;
  C: Subject: afternoon meeting
  C: To: mooch@example.com
  C: Message-Id: <B27397-0100000@example.com> &lt;B27397-0100000@example.com&gt;
  C: MIME-Version: 1.0
  C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
  C:
  C: Hello Joe, do you think we can meet at 3:30 tomorrow?
  C:
  S: A003 OK [APPENDUID 38505 3955] APPEND completed
  C: A004 COPY 2:4 meeting
  S: A004 OK [COPYUID 38505 304,319:320 3956:3958] Done
  C: A005 UID COPY 305:310 meeting
  S: A005 OK No matching messages, so nothing copied
  C: A006 COPY 2 funny
  S: A006 OK Done
  C: A007 SELECT funny
  S: * 1 EXISTS
  S: * OK [UIDVALIDITY 3857529045] Validity session-only
  S: * OK [UIDNEXT 2] Predicted next UID
  S: * NO [UIDNOTSTICKY] Non-persistent UIDs
  S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
  S: * OK [PERMANENTFLAGS (\Deleted \Seen)] Limited
  S: * LIST () "." funny
  S: A007 OK [READ-WRITE] SELECT completed
]]></artwork></figure>
</sourcecode>
          <t>
   In this example, A003 and A004 demonstrate successful appending and
   copying to a mailbox that returns the UIDs assigned to the messages.
   A005 is an example in which no messages were copied; this is because
   in A003, we see that message 2 had UID 304, and message 3 had UID
   319; therefore, UIDs 305 through 310 do not exist (refer to <xref target='uid-def'/> target="uid-def" format="default"/>
   for further explanation).  A006 is an example of a
   message being copied that did not return a COPYUID; and, as expected,
   A007 shows that the mail store containing that mailbox does not
   support persistent UIDs.
          </t>

   <t>
     <list>
       <t>
        <aside><t>
        Note: The APPEND command is not used for message delivery,
        because it does not provide a mechanism to transfer <xref target='SMTP'/> target="RFC5321" format="default"/>
        envelope information.
       </t>
     </list>
   </t> information.</t>
        </aside>
        </section>
        <section title='IDLE Command' anchor="idle">
      <iref item='IDLE (command)'/>

   <t>
   <list style='hanging' hangIndent='12'>
   <t hangText='Arguments:'>none</t>

   <t hangText='Responses:'>continuation anchor="idle" numbered="true" toc="default">
          <name>IDLE Command</name>
          <iref item="IDLE (command)" subitem="" primary="false"/>
          <dl newline="false" spacing="normal" indent="14">
            <dt>Arguments:</dt>
            <dd>none</dd>
            <dt>Responses:</dt>
            <dd>continuation data will be requested; the client sends
               the continuation data "DONE" to end the command</t>

   <t hangText='Result:'>OK - IDLE command</dd>
            <dt>Result:</dt>
            <dd>
	      <dl spacing="compact">
              <dt>OK -</dt><dd>IDLE completed after client sent "DONE"<vspace/>
               NO - failure: "DONE"</dd>
              <dt>NO -</dt><dd>failure: the server will not allow the IDLE
                    command at this time<vspace/>
               BAD - command time</dd>
	      <dt>BAD -</dt><dd>command unknown or arguments invalid</t>
   </list>
   </t> invalid</dd>
	       </dl>
            </dd>
          </dl>
          <t>
     Without the IDLE command command, a client would need to poll the server for changes
     to the selected mailbox (new mail, deletions, and flag changes).
     It's often more desirable to have the server transmit updates to
     the client in real time.  This allows a user to see new mail immediately.
     The IDLE command allows a client to tell the server that it's ready to accept
     such real-time updates.
          </t>

<!--
   The IDLE command may be used with any IMAP4 server implementation
   that returns "IDLE" as one of the supported capabilities to the
   CAPABILITY command.  If the server does not advertise the IDLE
   capability, the client MUST NOT use the IDLE command and must poll
   for mailbox updates.  In particular, the client MUST continue to be
   able to accept unsolicited untagged responses to ANY command, as
   specified in the base IMAP specification.
-->
   <t>
     The IDLE command is sent from the client to the server when the
     client is ready to accept unsolicited update messages.  The
     server requests a response to the IDLE command using the continuation
     ("+") response.  The IDLE command remains active until the client
     responds to the continuation, and as long as an IDLE command is
     active, the server is now free to send untagged EXISTS, EXPUNGE, FETCH, and
     other responses at any time. If the server chooses to send unsolicited FETCH
     responses, they MUST <bcp14>MUST</bcp14> include a UID FETCH item.
          </t>
          <t>
     The IDLE command is terminated by the receipt of a "DONE"
     continuation from the client; such response satisfies the server's
     continuation request.  At that point, the server MAY <bcp14>MAY</bcp14> send any
     remaining queued untagged responses and then MUST <bcp14>MUST</bcp14> immediately send
     the tagged response to the IDLE command and prepare to process other
     commands. As for other commands, the processing of any new
     command may cause the sending of unsolicited untagged responses,
     subject to the ambiguity limitations.  The client MUST NOT <bcp14>MUST NOT</bcp14> send a
     command while the server is waiting for the DONE, since the server
     will not be able to distinguish a command from a continuation.
          </t>
          <t>
     The server MAY <bcp14>MAY</bcp14> consider a client inactive if it has an IDLE command
     running, and if such a server has an inactivity timeout timeout, it MAY <bcp14>MAY</bcp14> log
     the client off implicitly at the end of its timeout period.  Because
     of that, clients using IDLE are advised to terminate the IDLE and
     re-issue
     reissue it at least every 29 minutes to avoid being logged off.
     This still allows a client to receive immediate mailbox updates even
     though it need only "poll" at half hour intervals.
          </t>

   <!--///Alexey: Clarify which responses should be expected/MUST be implemented-->

<figure><artwork>
	  <t>
    Example:
	  </t>
<sourcecode type="">
  C: A001 SELECT INBOX
  S: * FLAGS (\Deleted \Seen \Flagged)
  S: * OK [PERMANENTFLAGS (\Deleted \Seen \Flagged)] Limited
  S: * 3 EXISTS
  S: * OK [UIDVALIDITY 1]
  S: * OK [UIDNEXT 1]
  S: * LIST () "/" INBOX
  S: A001 OK [READ-WRITE] SELECT completed
  C: A002 IDLE
  S: + idling
  ...time passes; new mail arrives...
  S: * 4 EXISTS
  C: DONE
  S: A002 OK IDLE terminated
  ...another client expunges message 2 now...
  C: A003 FETCH 4 ALL
  S: * 4 FETCH (...)
  S: A003 OK FETCH completed
  C: A004 IDLE
  S: * 2 EXPUNGE
  S: * 3 EXISTS
  S: + idling
  ...time passes; another client expunges message 3...
  S: * 3 EXPUNGE
  S: * 2 EXISTS
  ...time passes; new mail arrives...
  S: * 3 EXISTS
  C: DONE
  S: A004 OK IDLE terminated
  C: A005 FETCH 3 ALL
  S: * 3 FETCH (...)
  S: A005 OK FETCH completed
  C: A006 IDLE
</artwork></figure>
</sourcecode>
        </section>
      </section>
      <section title='Client numbered="true" toc="default">
        <name>Client Commands - Selected State'> State</name>
        <t>
   In the selected state, commands that manipulate messages in a mailbox
   are permitted.
        </t>
        <t>
   In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
   and the authenticated state commands (SELECT, EXAMINE, NAMESPACE, CREATE,
   DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, STATUS, and
   APPEND), the following commands are valid in the selected state:
   CLOSE, UNSELECT, EXPUNGE, SEARCH, FETCH, STORE, COPY, MOVE, and UID.
        </t>
        <section title='CLOSE Command'>
      <iref item='CLOSE (command)'/>

   <t>
   <list style='hanging' hangIndent='12'>
   <t hangText='Arguments:'>none</t>

   <t hangText='Responses:'>no numbered="true" toc="default">
          <name>CLOSE Command</name>
          <iref item="CLOSE (command)" subitem="" primary="false"/>
          <dl newline="false" spacing="normal" indent="14">
            <dt>Arguments:</dt>
            <dd>none</dd>
            <dt>Responses:</dt>
            <dd>no specific responses for this command</t>

   <t hangText='Result:'>OK - close command</dd>
            <dt>Result:</dt>
            <dd>
	      <dl spacing="compact">
              <dt>OK -</dt><dd>close completed, now in authenticated state<vspace/>
               BAD - command state</dd>
              <dt>BAD -</dt><dd>command unknown or arguments invalid</t>
   </list>
   </t> invalid</dd>
	      </dl>
            </dd>
          </dl>
          <t>
      The CLOSE command permanently removes all messages that have the
      \Deleted flag set from the currently selected mailbox, and it returns
      to the authenticated state from the selected state.  No untagged
      EXPUNGE responses are sent.
          </t>
          <t>
      No messages are removed, and no error is given, if the mailbox is
      selected by an EXAMINE command or is otherwise selected as read-only.
          </t>
          <t>
      Even if a mailbox is selected, a SELECT, EXAMINE, or LOGOUT
      command MAY <bcp14>MAY</bcp14> be issued without previously issuing a CLOSE command.
      The SELECT, EXAMINE, and LOGOUT commands implicitly close the
      currently selected mailbox without doing an expunge.  However,
      when many messages are deleted, a CLOSE-LOGOUT or CLOSE-SELECT
      sequence is considerably faster than an EXPUNGE-LOGOUT or
      EXPUNGE-SELECT because no untagged EXPUNGE responses (which the
      client would probably ignore) are sent.
          </t>

<figure><artwork>
	  <t>
Example:
	  </t>
<sourcecode type="">
  C: A341 CLOSE
  S: A341 OK CLOSE completed
</artwork></figure>
</sourcecode>
        </section>
        <section title='UNSELECT Command'>
        <iref item='UNSELECT (command)'/>

        <t>
          <list style='hanging' hangIndent='12'>
            <t hangText='Arguments:'>none</t>

            <t hangText='Responses:'>no numbered="true" toc="default">
          <name>UNSELECT Command</name>
          <iref item="UNSELECT (command)" subitem="" primary="false"/>
          <dl newline="false" spacing="normal" indent="14">
            <dt>Arguments:</dt>
            <dd>none</dd>
            <dt>Responses:</dt>
            <dd>no specific responses for this command</t>

            <t hangText='Result:'>
              OK - unselect command</dd>
            <dt>Result:</dt>
            <dd>
	     <dl spacing="compact">
              <dt>OK -</dt><dd>unselect completed, now in authenticated state<vspace/>
              BAD - no state</dd>
              <dt>BAD -</dt><dd>no mailbox selected, or argument supplied but
              none permitted
            </t>
          </list>
        </t> permitted</dd>
              </dl>
            </dd>
          </dl>
          <t>
          The UNSELECT command frees a session's resources associated with the
          selected mailbox and returns the server to the authenticated
          state.  This command performs the same actions as CLOSE, except
          that no messages are permanently removed from the currently
          selected mailbox.
          </t>

<figure><artwork>
  <t>
Example:
	  </t>
<sourcecode type="">
  C: A342 UNSELECT
  S: A342 OK Unselect completed
</artwork></figure>
</sourcecode>
        </section>
        <section title='EXPUNGE Command'>
      <iref item='EXPUNGE (command)'/>

   <t>
   <list style='hanging' hangIndent='12'>
   <t hangText='Arguments:'>none</t>

   <t hangText='Responses:'>untagged responses: EXPUNGE</t>

   <t hangText='Result:'>OK - expunge completed<vspace/>
               NO - expunge numbered="true" toc="default">
          <name>EXPUNGE Command</name>
          <iref item="EXPUNGE (command)" subitem="" primary="false"/>
          <dl newline="false" spacing="normal" indent="14">
            <dt>Arguments:</dt>
            <dd>none</dd>
            <dt>Responses:</dt>
            <dd>
            <dl spacing="compact">
	      <dt>untagged responses:</dt><dd>EXPUNGE</dd>
	    </dl>
	    </dd>
            <dt>Result:</dt>
            <dd>
	      <dl spacing="compact">
              <dt>OK -</dt><dd>expunge completed</dd>
              <dt>NO -</dt><dd>expunge failure: can't expunge (e.g., permission<vspace/>
                    denied)<vspace/>
               BAD - command permission
               denied)</dd>
               <dt>BAD -</dt><dd>command unknown or arguments invalid</t>
   </list>
   </t> invalid</dd>
	      </dl>
            </dd>
          </dl>
          <t>
      The EXPUNGE command permanently removes all messages that have the
      \Deleted flag set from the currently selected mailbox.  Before
      returning an OK to the client, an untagged EXPUNGE response is
      sent for each message that is removed.
          </t>

<figure><artwork>
 <t>
Example:
	  </t>
<sourcecode type="">
  C: A202 EXPUNGE
  S: * 3 EXPUNGE
  S: * 3 EXPUNGE
  S: * 5 EXPUNGE
  S: * 8 EXPUNGE
  S: A202 OK EXPUNGE completed
</artwork></figure>
</sourcecode>
          <t>
        Note: In this example, messages 3, 4, 7, and 11 had the
        \Deleted flag set.  See the description of the EXPUNGE
        response (<xref target='expunge-response'/>) target="expunge-response" format="default"/>) for further explanation.
          </t>
        </section>
        <section title='SEARCH Command'>
      <iref item='SEARCH (command)'/> numbered="true" toc="default">
          <name>SEARCH Command</name>
          <iref item="SEARCH (command)" subitem="" primary="false"/>
          <dl newline="false" spacing="normal" indent="14">
            <dt>Arguments:</dt>
            <dd>
              <t><bcp14>OPTIONAL</bcp14> result specifier</t>
              <t>
               <bcp14>OPTIONAL</bcp14> <xref target="RFC2978" format="default"/> specification</t>
              <t>
   <list style='hanging' hangIndent='12'>
   <t hangText='Arguments:'>OPTIONAL result specifier<vspace/>
               OPTIONAL <xref target='CHARSET'/> specification<vspace/>
               searching criteria (one or more)</t>

   <t hangText='Responses:'>OPTIONAL
            </dd>
            <dt>Responses:</dt>
            <dd>
            <dl spacing="compact">
	      <dt><bcp14>OPTIONAL</bcp14> untagged response: ESEARCH</t>

   <t hangText='Result:'>OK - search completed<vspace/>
               NO - search response:</dt><dd>ESEARCH</dd>
	    </dl>
	    </dd>
            <dt>Result:</dt>
            <dd>
	      <dl spacing="compact">
              <dt>OK -</dt><dd>search completed</dd>
              <dt>NO -</dt><dd>search error: can't search that <xref target='CHARSET'/> or<vspace/>
                    criteria<vspace/>
               BAD - command target="RFC2978" format="default"/> or criteria</dd>
              <dt>BAD -</dt><dd>command unknown or arguments invalid</t>
   </list>
   </t> invalid</dd>
	      </dl>
            </dd>
          </dl>
          <t>
      The SEARCH command searches the mailbox for messages that match
      the given searching criteria.
          </t>
          <t>
     The SEARCH command may contain result options. Result options control
     what kind of information is returned about messages matching the search criteria in an untagged ESEARCH response.
     If no result option is specified or empty list of options is specified as "()", ALL is assumed (see below).
     The order of individual options is arbitrary.  Individual options
     may contain parameters enclosed in parentheses.
     (However, if an option has a mandatory parameter, which can always be
     represented as a number or a sequence-set, the option parameter does
     not need the enclosing parentheses.  See the Formal Syntax "Formal Syntax" (<xref target='IMAP-ABNF'/>) target="IMAP-ABNF" format="default"/>)
     for more details). details.)  If an option has
     parameters, they consist of atoms and/or strings and/or lists in a
     specific order.  Any options not defined by extensions that the
     server supports MUST <bcp14>MUST</bcp14> be rejected with a BAD response.
          </t>
          <t>Note that IMAP4rev1 used SEARCH responses <xref target='RFC3501'/> target="RFC3501" format="default"/> instead of ESEARCH responses.
   <!--///Alexey: in theory IMAP4rev2-only client would never see SEARCH responses,
       but if they forget to ENABLE IMAP4rev2, they might still get them from dual IMAP4rev1/IMAP4rev2 servers.-->
      IMAP4rev2-only clients MUST
          Clients that support only IMAP4rev2 <bcp14>MUST</bcp14> ignore SEARCH responses.</t>
          <t>
     This document specifies the following result options:

     <list style='hanging'>
        <t hangText='MIN'>
        <iref item='MIN
          </t>
          <dl newline="true" spacing="normal">
            <dt>MIN</dt>
            <dd><t><iref item="MIN (search result option)'/>

          <list>
            <t> option)" subitem="" primary="false"/>
              Return the lowest message number/UID that satisfies the SEARCH
              criteria.
              </t>
              <t>
              If the SEARCH results in no matches, the server MUST NOT <bcp14>MUST NOT</bcp14>
              include the MIN result option in the ESEARCH response; however,
              it still MUST <bcp14>MUST</bcp14> send the ESEARCH response.
            </t>
          </list>
        </t>

        <t hangText='MAX'>
        <iref item='MAX
            </t></dd>
            <dt>MAX</dt>
            <dd>
              <t><iref item="MAX (search result option)'/>
          <list>
            <t> option)" subitem="" primary="false"/>
              Return the highest message number/UID that satisfies the SEARCH
              criteria.
            </t>
              criteria.</t>
               <t>
              If the SEARCH results in no matches, the server MUST NOT <bcp14>MUST NOT</bcp14>
              include the MAX result option in the ESEARCH response; however,
              it still MUST <bcp14>MUST</bcp14> send the ESEARCH response.
            </t>
          </list>
        </t>

        <t hangText='ALL'>
        <iref item='ALL response.</t>
            </dd>
            <dt>ALL</dt>
            <dd><t><iref item="ALL (search result option)'/>
          <list>
          <t> option)" subitem="" primary="false"/>
            Return all message numbers/UIDs that satisfy the SEARCH
            criteria using the sequence-set syntax. Note, Note that the client
            MUST NOT
            <bcp14>MUST NOT</bcp14> assume that messages/UIDs will be listed in any
            particular order.
		      </t> order.</t>
	   <t>
          If the SEARCH results in no matches, the server MUST NOT <bcp14>MUST NOT</bcp14>
          include the ALL result option in the ESEARCH response; however,
          it still MUST <bcp14>MUST</bcp14> send the ESEARCH response.
          </t>
          </list>
        </t>

        <t hangText='COUNT'> response.</t>
          </dd>

            <dt>COUNT</dt>
            <dd>
              <iref item='COUNT item="COUNT (search result option)'/> option)" subitem="" primary="false"/>
            Return the number of messages that satisfy the SEARCH criteria.
            This result option MUST <bcp14>MUST</bcp14> always be included in the ESEARCH
            response.
        </t>

        <t hangText='SAVE'>
        <iref item='SAVE
        </dd>
            <dt>SAVE</dt>
            <dd>
              <t><iref item="SAVE (search result option)'/>
          <list>
          <t> option)" subitem="" primary="false"/>
          This option tells the server to remember the result
          of the SEARCH or UID SEARCH command (as well as any command based on
          SEARCH, e.g., SORT and THREAD <xref target="RFC5256"/>>) target="RFC5256" format="default"/>) and store it in an internal
          variable that we will reference as the "search result variable".  The
          client can use the "$" marker to reference the content of this
          internal variable.  The "$" marker can be used instead of message
          sequence or UID sequence in order to indicate that the server should
          substitute it with the list of messages from the search result
          variable.  Thus, the client can use the result of the latest
          remembered SEARCH command as a parameter to another command.
          See <xref target="search-save"/> target="search-save" format="default"/> for details on how
          the value of the search result variable is determined,
          how it is affected by other commands executed, and how
          the SAVE return option interacts with other return options.
	    </t>
            <t>
          In absence of any other SEARCH result option, the SAVE result option
          also suppresses any ESEARCH response that would have been otherwise
          returned by the SEARCH command.
          </t>

          </list>
        </t>

     </list>
   </t> command.</t>
          </dd>
              </dl>
          <t>
   Note: future extensions to this document can allow servers to
   return multiple ESEARCH responses for a single extended SEARCH
   command.  However  However, all options specified above MUST <bcp14>MUST</bcp14> result in a single ESEARCH response if used by themselves or in combination.
   This guarantee simplifies processing in IMAP4rev2 clients.
   Future SEARCH extensions that relax this restriction will have to describe how results from
   multiple ESEARCH responses are to be combined.
          </t>
          <t>
      Searching criteria consist of one
      or more search keys.
          </t>
          <t>
      When multiple keys are specified, the result is the intersection
      (AND function) of all the messages that match those keys.  For
      example, the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers
      to all deleted messages from Smith with INTERNALDATE greater than
      February 1, 1994.  A search key can also be a parenthesized
      list of one or more search keys (e.g., for use with the OR and NOT
      keys).
          </t>
          <t>
      Server implementations MAY <bcp14>MAY</bcp14> exclude <xref target='MIME-IMB'/> target="RFC2045" format="default"/> body parts with
      terminal content media types other than TEXT and MESSAGE from
      consideration in SEARCH matching.
          </t>
          <t>
      The OPTIONAL <bcp14>OPTIONAL</bcp14> <xref target='CHARSET'/> target="RFC2978" format="default"/> specification consists of the word
      "CHARSET" followed by the name of a registered <xref target='CHARSET'/> character set from the registry <xref target='CHARSET-REG'/>. target="CHARSET-REG" format="default"/>.  It indicates the
      <xref target='CHARSET'/> target="RFC2978" format="default"/> of the strings that appear in the search criteria.
      <xref target='MIME-IMB'/> target="RFC2045" format="default"/> content transfer encodings, encodings and <xref target='MIME-HDRS'/> target="RFC2047" format="default"/> strings in
      <xref target='RFC-5322'/>/<xref target='MIME-IMB'/> headers, MUST target="RFC5322" format="default"/>/<xref target="RFC2045" format="default"/> headers <bcp14>MUST</bcp14> be decoded before comparing
      text.  Servers MUST <bcp14>MUST</bcp14> support US-ASCII and UTF-8 charsets; other <xref target='CHARSET'/>s MAY CHARSETs <bcp14>MAY</bcp14> be supported.
      Clients SHOULD <bcp14>SHOULD</bcp14> use UTF-8. Note that if "CHARSET" CHARSET is not provided provided, IMAP4rev2 servers MUST <bcp14>MUST</bcp14> assume UTF-8,
      so selecting CHARSET UTF-8 is redundant. It is permitted for improved compatibility with existing IMAP4rev1 clients.
          </t>
          <t>
      If the server does not support the specified <xref target='CHARSET'/>, target="RFC2978" format="default"/>, it MUST <bcp14>MUST</bcp14>
      return a tagged NO response (not a BAD).  This response SHOULD <bcp14>SHOULD</bcp14>
      contain the BADCHARSET response code, which MAY <bcp14>MAY</bcp14> list the
      <xref target='CHARSET'/>s CHARSETs
      supported by the server.
          </t>
          <t>
      In all search keys that use strings strings, and unless specified otherwise, otherwise specified,
      a message matches the key if
      the string is a substring of the associated text.  The matching SHOULD <bcp14>SHOULD</bcp14> be
      case-insensitive
      case insensitive for characters within the ASCII range. Consider using <xref target="IMAP-I18N"/> target="RFC5255" format="default"/>
      for language-sensitive language-sensitive, case-insensitive
      searching.  Note that the empty string is a substring; this
      is useful when doing performing a HEADER search in order to test for a header field
      presence in the message.
          </t>
          <t>
      The defined search keys are as follows.  Refer to the Formal
      Syntax section "Formal
      Syntax" (<xref target="IMAP-ABNF"/>) for the precise syntactic definitions of the
      arguments.

      <list style='hanging'>
      <t hangText='&lt;sequence set&gt;'>
      <!-- iref item='&lt;sequence set&gt; (search key)'/ -->
          </t>
          <dl newline="true" spacing="normal">
            <dt>&lt;sequence set&gt;</dt>
            <dd>
         Messages with message sequence numbers corresponding to the
         specified message sequence number set.</t>

      <t hangText='ALL'> set.</dd>
            <dt>ALL</dt>
            <dd>
              <iref item='ALL item="ALL (search key)'/> key)" subitem="" primary="false"/>
         All messages in the mailbox; the default initial key for
         ANDing.</t>

      <t hangText='ANSWERED'>
         ANDing.</dd>
            <dt>ANSWERED</dt>
            <dd>
              <iref item='ANSWERED item="ANSWERED (search key)'/> key)" subitem="" primary="false"/>
         Messages with the \Answered flag set.</t>

      <t hangText='BCC &lt;string>'> set.</dd>
            <dt>BCC &lt;string&gt;</dt>
            <dd>
              <iref item='BCC &lt;string> item="BCC &lt;string&gt; (search key)'/>
        <!--///Alexey: Does this mean the email address, the display name or either?
        M-Box is matching against RFC 5322 representation.--> key)" subitem="" primary="false"/>
         Messages that contain the specified string in the envelope
         structure's BCC field.</t>

      <t hangText='BEFORE &lt;date>'> Blind Carbon Copy (BCC) field.</dd>
            <dt>BEFORE &lt;date&gt;</dt>
            <dd>
              <iref item='BEFORE &lt;date> item="BEFORE &lt;date&gt; (search key)'/> key)" subitem="" primary="false"/>
         Messages whose internal date (disregarding time and timezone)
         is earlier than the specified date.</t>

      <t hangText='BODY &lt;string>'> date.</dd>
            <dt>BODY &lt;string&gt;</dt>
            <dd>
              <iref item='BODY &lt;string> item="BODY &lt;string&gt; (search key)'/> key)" subitem="" primary="false"/>
         Messages that contain the specified string in the body of the
         message. Unlike TEXT (see below), this doesn't match any header fields.
         Servers are allowed to implement flexible matching for this search key,
         for example example, by matching "swim" to both "swam" and "swum" in English language text
         or only doing performing full word matching (where "swim" will not match "swimming").
        </t>

      <t hangText='CC &lt;string>'>
        </dd>
            <dt>CC &lt;string&gt;</dt>
            <dd>
              <iref item='CC &lt;string> item="CC &lt;string&gt; (search key)'/> key)" subitem="" primary="false"/>
         Messages that contain the specified string in the envelope
         structure's CC field.</t>

      <t hangText='DELETED'> field.</dd>
            <dt>DELETED</dt>
            <dd>
              <iref item='DELETED item="DELETED (search key)'/> key)" subitem="" primary="false"/>
         Messages with the \Deleted flag set.</t>

      <t hangText='DRAFT'> set.</dd>
            <dt>DRAFT</dt>
            <dd>
              <iref item='DRAFT item="DRAFT (search key)'/> key)" subitem="" primary="false"/>
         Messages with the \Draft flag set.</t>

      <t hangText='FLAGGED'> set.</dd>
            <dt>FLAGGED</dt>
            <dd>
              <iref item='FLAGGED item="FLAGGED (search key)'/> key)" subitem="" primary="false"/>
         Messages with the \Flagged flag set.</t>

      <t hangText='FROM &lt;string>'> set.</dd>
            <dt>FROM &lt;string&gt;</dt>
            <dd>
              <iref item='FROM &lt;string> item="FROM &lt;string&gt; (search key)'/> key)" subitem="" primary="false"/>
         Messages that contain the specified string in the envelope
         structure's FROM field.</t>

      <t hangText='HEADER &lt;field-name> &lt;string>'>
      <iref item='HEADER &lt;field-name> &lt;string> field.</dd>
            <dt>HEADER &lt;field-name&gt; &lt;string&gt;</dt>
            <dd>
              <iref item="HEADER &lt;field-name&gt; &lt;string&gt; (search key)'/> key)" subitem="" primary="false"/>
         Messages that have a header field with the specified field-name (as
         defined in <xref target='RFC-5322'/>) target="RFC5322" format="default"/>) and that contains contain the specified string
         in the text of the header field (what comes after the colon).  If the
         string to search is zero-length, this matches all messages that
         have a header field with the specified field-name regardless of
         the contents. Servers should use a substring search for this SEARCH item,
         as clients can use it for automatic processing not initiated by end users.
         For example example, this can be used for when searching for Message-ID or Content-Type header field
         values that need to be exact, exact or for searches in header fields that the IMAP server
         might not know anything about.</t>

      <t hangText='KEYWORD &lt;flag>'> about.</dd>
            <dt>KEYWORD &lt;flag&gt;</dt>
            <dd>
              <iref item='KEYWORD &lt;flag> item="KEYWORD &lt;flag&gt; (search key)'/> key)" subitem="" primary="false"/>
         Messages with the specified keyword flag set.</t>

      <t hangText='LARGER &lt;n>'> set.</dd>
            <dt>LARGER &lt;n&gt;</dt>
            <dd>
              <iref item='LARGER &lt;n> item="LARGER &lt;n&gt; (search key)'/> key)" subitem="" primary="false"/>
         Messages with an <xref target='RFC-5322'/> size RFC822.SIZE larger than the specified
         number of octets.</t>

      <t hangText='NOT &lt;search-key>'> octets.</dd>
            <dt>NOT &lt;search-key&gt;</dt>
            <dd>
              <iref item='NOT &lt;search-key> item="NOT &lt;search-key&gt; (search key)'/> key)" subitem="" primary="false"/>
         Messages that do not match the specified search key.</t>

      <t hangText='ON &lt;date>'> key.</dd>
            <dt>ON &lt;date&gt;</dt>
            <dd>
              <iref item='ON &lt;date> item="ON &lt;date&gt; (search key)'/> key)" subitem="" primary="false"/>
         Messages whose internal date (disregarding time and timezone)
         is within the specified date.</t>

      <t hangText='OR &lt;search-key1> &lt;search-key2>'>
      <iref item='OR &lt;search-key1> &lt;search-key2> date.</dd>
            <dt>OR &lt;search-key1&gt; &lt;search-key2&gt;</dt>
            <dd>
              <iref item="OR &lt;search-key1&gt; &lt;search-key2&gt; (search key)'/> key)" subitem="" primary="false"/>
         Messages that match either search key.</t>

      <t hangText='SEEN'> key.</dd>
            <dt>SEEN</dt>
            <dd>
              <iref item='SEEN item="SEEN (search key)'/> key)" subitem="" primary="false"/>
         Messages that have the \Seen flag set.</t>

      <t hangText='SENTBEFORE &lt;date>'> set.</dd>
            <dt>SENTBEFORE &lt;date&gt;</dt>
            <dd>
              <iref item='SENTBEFORE &lt;date> item="SENTBEFORE &lt;date&gt; (search key)'/> key)" subitem="" primary="false"/>
         Messages whose <xref target='RFC-5322'/> target="RFC5322" format="default"/> Date: header field (disregarding time and
         timezone) is earlier than the specified date.</t>

      <t hangText='SENTON &lt;date>'> date.</dd>
            <dt>SENTON &lt;date&gt;</dt>
            <dd>
              <iref item='SENTON &lt;date> item="SENTON &lt;date&gt; (search key)'/> key)" subitem="" primary="false"/>
         Messages whose <xref target='RFC-5322'/> target="RFC5322" format="default"/> Date: header field (disregarding time and
         timezone) is within the specified date.</t>

      <t hangText='SENTSINCE &lt;date>'> date.</dd>
            <dt>SENTSINCE &lt;date&gt;</dt>
            <dd>
              <iref item='SENTSINCE &lt;date> item="SENTSINCE &lt;date&gt; (search key)'/> key)" subitem="" primary="false"/>
         Messages whose <xref target='RFC-5322'/> target="RFC5322" format="default"/> Date: header field (disregarding time and
         timezone) is within or later than the specified date.</t>

      <t hangText='SINCE &lt;date>'> date.</dd>
            <dt>SINCE &lt;date&gt;</dt>
            <dd>
              <iref item='SINCE &lt;date> item="SINCE &lt;date&gt; (search key)'/> key)" subitem="" primary="false"/>
         Messages whose internal date (disregarding time and timezone)
         is within or later than the specified date.</t>

      <t hangText='SMALLER &lt;n>'> date.</dd>
            <dt>SMALLER &lt;n&gt;</dt>
            <dd>
              <iref item='SMALLER &lt;n> item="SMALLER &lt;n&gt; (search key)'/> key)" subitem="" primary="false"/>
         Messages with an <xref target='RFC-5322'/> size RFC822.SIZE smaller than the specified
         number of octets.</t>

      <t hangText='SUBJECT &lt;string>'> octets.</dd>
            <dt>SUBJECT &lt;string&gt;</dt>
            <dd>
              <iref item='SUBJECT &lt;string> item="SUBJECT &lt;string&gt; (search key)'/> key)" subitem="" primary="false"/>
         Messages that contain the specified string in the envelope
         structure's SUBJECT field.</t>

      <t hangText='TEXT &lt;string>'> field.</dd>
            <dt>TEXT &lt;string&gt;</dt>
            <dd>
              <iref item='TEXT &lt;string> item="TEXT &lt;string&gt; (search key)'/> key)" subitem="" primary="false"/>
         Messages that contain the specified string in the header (including MIME header fields) or
         body of the message.
         Servers are allowed to implement flexible matching for this search key,
         for example example, matching "swim" to both "swam" and "swum" in English language text
         or only doing full word performing full-word matching (where "swim" will not match "swimming").
      </t>

      <t hangText='TO &lt;string>'>
      </dd>
            <dt>TO &lt;string&gt;</dt>
            <dd>
              <iref item='TO &lt;string> item="TO &lt;string&gt; (search key)'/> key)" subitem="" primary="false"/>
         Messages that contain the specified string in the envelope
         structure's TO field.</t>

      <t hangText='UID field.</dd>
            <dt>UID &lt;sequence set>'> set&gt;</dt>
            <dd>
              <iref item='UID item="UID &lt;sequence set> set&gt; (search key)'/> key)" subitem="" primary="false"/>
         Messages with unique identifiers corresponding to the specified
         unique identifier set.  Sequence set  Sequence-set ranges are permitted.</t>

      <t hangText='UNANSWERED'> permitted.</dd>
            <dt>UNANSWERED</dt>
            <dd>
              <iref item='UNANSWERED item="UNANSWERED (search key)'/> key)" subitem="" primary="false"/>
         Messages that do not have the \Answered flag set.</t>

      <t hangText='UNDELETED'> set.</dd>
            <dt>UNDELETED</dt>
            <dd>
              <iref item='UNDELETED item="UNDELETED (search key)'/> key)" subitem="" primary="false"/>
         Messages that do not have the \Deleted flag set.</t>

      <t hangText='UNDRAFT'> set.</dd>
            <dt>UNDRAFT</dt>
            <dd>
              <iref item='UNDRAFT item="UNDRAFT (search key)'/> key)" subitem="" primary="false"/>
         Messages that do not have the \Draft flag set.</t>

      <t hangText='UNFLAGGED'> set.</dd>
            <dt>UNFLAGGED</dt>
            <dd>
              <iref item='UNFLAGGED item="UNFLAGGED (search key)'/> key)" subitem="" primary="false"/>
         Messages that do not have the \Flagged flag set.</t>

      <t hangText='UNKEYWORD &lt;flag>'> set.</dd>
            <dt>UNKEYWORD &lt;flag&gt;</dt>
            <dd>
              <iref item='UNKEYWORD &lt;flag> item="UNKEYWORD &lt;flag&gt; (search key)'/> key)" subitem="" primary="false"/>
         Messages that do not have the specified keyword flag set.</t>

      <t hangText='UNSEEN'> set.</dd>
            <dt>UNSEEN</dt>
            <dd>
              <iref item='UNSEEN item="UNSEEN (search key)'/> key)" subitem="" primary="false"/>
         Messages that do not have the \Seen flag set.</t>
      </list>
   </t>

<figure><artwork> set.</dd>
          </dl>
 <t>
Example: </t>
<sourcecode type="">
  C: A282 SEARCH RETURN (MIN COUNT) FLAGGED
      SINCE 1-Feb-1994 NOT FROM "Smith"
  S: * ESEARCH (TAG "A282") MIN 2 COUNT 3
  S: A282 OK SEARCH completed
</sourcecode>
 <t>
Example: </t>
<sourcecode type="">
  C: A283 SEARCH RETURN () FLAGGED
      SINCE 1-Feb-1994 NOT FROM "Smith"
  S: * ESEARCH (TAG "A283") ALL 2,10:11
  S: A283 OK SEARCH completed

   Example:
</sourcecode>
   <t>
Example:</t>
<sourcecode type="">
  C: A284 SEARCH TEXT "string not in mailbox"
  S: * ESEARCH (TAG "A284")
  S: A284 OK SEARCH completed
  C: A285 SEARCH CHARSET UTF-8 TEXT {6} {12}
  S: + Ready for literal text
  C: XXXXXX отпуск
  S: * ESEARCH (TAG "A285") ALL 43
  S: A285 OK SEARCH completed
</artwork></figure>

   <t><!--RFC Editor: please amend the following note to match current state
          of XMLv3 and RFC Editor's policy. Happy to add an UTF-8 example above,
          if you think it is helpful.-->
        Note: Since this document is restricted to 7-bit ASCII
        text, it is not possible to show actual UTF-8 data.  The
        "XXXXXX" is a placeholder for what would be 6 octets of
        8-bit data in an actual transaction.
</sourcecode>
<t>
          </t>
          <t>
   The following example demonstrates finding the first unseen message
   in the mailbox:
          </t>

<figure><artwork>
 <t>
Example: </t>
<sourcecode type="">
  C: A284 SEARCH RETURN (MIN) UNSEEN
  S: * ESEARCH (TAG "A284") MIN 4
  S: A284 OK SEARCH completed
</artwork></figure>
</sourcecode>
          <t>
   The following example demonstrates that if the ESEARCH UID indicator
   is present, all data in the ESEARCH response is referring to UIDs;
   for example, the MIN result specifier will be followed by a UID.
          </t>

<figure><artwork>
  <t>
Example: </t>
<sourcecode type="">
  C: A285 UID SEARCH RETURN (MIN MAX) 1:5000
  S: * ESEARCH (TAG "A285") UID MIN 7 MAX 3800
  S: A285 OK SEARCH completed
</artwork></figure>
</sourcecode>
          <t>
   The following example demonstrates returning the number of deleted
   messages:
          </t>

<figure><artwork>
 <t>
Example: </t>
<sourcecode type="">
  C: A286 SEARCH RETURN (COUNT) DELETED
  S: * ESEARCH (TAG "A286") COUNT 15
  S: A286 OK SEARCH completed
</artwork></figure>
</sourcecode>
          <section title='SAVE result option anchor="search-save" numbered="true" toc="default">
            <name>SAVE Result Option and SEARCH result variable' anchor="search-save"> Result Variable</name>
            <t>
   Upon successful completion of a SELECT or an EXAMINE command (after
   the tagged OK response), the current search result variable is reset
   to the empty sequence.
            </t>
            <t>
   A successful SEARCH command with the SAVE result option sets the
   value of the search result variable to the list of messages found in
   the SEARCH command.  For example, if no messages were found, the
   search result variable will contain the empty sequence.
            </t>
            <t>
   Any of the following SEARCH commands MUST NOT <bcp14>MUST NOT</bcp14> change the search
   result variable:

     <list>
      <t>

            </t>
            <ul empty="true" spacing="normal">
              <li>
      a SEARCH command that caused the server to return the BAD tagged
      response,
      </t>

      <t>
      </li>
              <li>
      a SEARCH command with no SAVE result option that caused the
      server to return NO tagged response,
      </t>

      <t> and
      </li>
              <li>
      a successful SEARCH command with no SAVE result option.
      </t>
     </list>

   </t>
      </li>
            </ul>
            <t>
   A SEARCH command with the SAVE result option that caused the server
   to return the NO tagged response sets the value of the search result
   variable to the empty sequence.
            </t>
            <t>
   When a message listed in the search result variable is EXPUNGEd, it
   is automatically removed from the list.  Implementors are reminded
   that if the server stores the list as a list of message numbers, it
   MUST
   <bcp14>MUST</bcp14> automatically adjust them when notifying the client about
   expunged messages, as described in <xref target='expunge-response'/>. target="expunge-response" format="default"/>.
            </t>
            <t>
   If the server decides to send a new UIDVALIDITY value while the
   mailbox is opened, this it causes the resetting of the search variable to
   the empty sequence.
            </t>
            <t>
   Note that even if the "$" marker contains the empty sequence of messages,
   it must be treated by all commands accepting message sets as
   parameters as a valid, but non-matching non-matching, list of messages.  For
   example, the "FETCH $" command would return a tagged OK response and
   no FETCH responses.  See also the Example 5 in <xref target='search-save-examples'/>. target="search-save-examples" format="default"/>.
            </t>
            <t>
   The SAVE result option doesn't change whether the server would return
   items corresponding to MIN, MAX, ALL, or COUNT result options.
            </t>
            <t>
   When the SAVE result option is combined with the MIN or MAX
   result option, and both ALL and COUNT result options are
   absent, the corresponding MIN/MAX is returned (if the search result
   is not empty), but the "$" marker would contain a single message as
   returned in the MIN/MAX return item.
            </t>
            <t>
   If the SAVE result option is combined with both MIN and MAX result
   options, and both ALL and COUNT result options are absent,
   the "$" marker would contain zero, zero messages, one message, or two messages as returned in the
   MIN/MAX return items.
            </t>
            <t>
   If the SAVE result option is combined with the ALL and/or COUNT
   result option(s), the "$" marker would always contain all messages
   found by the SEARCH or UID SEARCH command.
            </t>

   <texttable>
     <preamble>
            <t>
     The following table summarizes the additional requirement on ESEARCH
     server implementations described in this section.
     </preamble>

          <ttcol align='center'>Combination
            </t>
            <table align="center">
              <thead>
                <tr>
                  <th align="center">Combination of Result option</ttcol>
          <ttcol align='center'>"$" marker value</ttcol>

          <c>SAVE MIN</c>
          <c>MIN</c>

          <c>SAVE MAX</c>
          <c>MAX</c>

          <c>SAVE Option</th>
                  <th align="center">"$" Marker Value</th>
                </tr>
              </thead>
              <tbody>
                <tr>
                  <td align="center">SAVE MIN</td>
                  <td align="center">MIN</td>
                </tr>
                <tr>
                  <td align="center">SAVE MAX</td>
                  <td align="center">MAX</td>
                </tr>
                <tr>
                  <td align="center">SAVE MIN MAX</c>
          <c>MIN MAX</td>
                  <td align="center">MIN &amp; MAX</c>

          <c>SAVE * [m]</c>
          <c>all MAX</td>
                </tr>
                <tr>
                  <td align="center">SAVE * [m]</td>
                  <td align="center">all found messages</c>

     <postamble> messages</td>
                </tr>
              </tbody>
            </table>
            <t>
     where  '*'  means "ALL" and/or "COUNT", and
     '[m]' means optional "MIN" and/or "MAX"
     </postamble>

   </texttable>
            </t>
            <t>
   Implementation note: server implementors should note that "$" can
   reference IMAP message sequences or UID sequences, depending on the
   context where it is used.  For example, the "$" marker can be set as
   a result of a SEARCH (SAVE) command and used as a parameter to a UID
   FETCH command (which accepts a UID sequence, not a message sequence),
   or the "$" marker can be set as a result of a UID SEARCH (SAVE)
   command and used as a parameter to a FETCH command (which accepts a
   message sequence, not a UID sequence). Server implementations need
   to automatically map the "$" marker value to message numbers or UIDs,
   depending on the context where the "$" marker is used.
            </t>
          </section>
          <section title='Multiple anchor="search-save-pipelining" numbered="true" toc="default">
            <name>Multiple Commands in Progress' anchor='search-save-pipelining'> Progress</name>
            <t>
   Use of a SEARCH RETURN (SAVE) command followed by a command using the
   "$" marker creates direct dependency between the two commands.  As
   directed by <xref target='pipelining'/>, target="pipelining" format="default"/>, a server MUST <bcp14>MUST</bcp14> execute the two
   commands in the order they were received.
            </t>
            <t>
   A client MAY <bcp14>MAY</bcp14> pipeline a SEARCH RETURN (SAVE) command with one or more command commands
   using the "$" marker, as long as this doesn't create an ambiguity,
   as described in <xref target='pipelining'/>. target="pipelining" format="default"/>. Examples 7-9 in
   <xref target='search-save-examples'/> target="search-save-examples" format="default"/> explain this in more details.
            </t>
          </section>
          <section title='Refusing numbered="true" toc="default">
            <name>Refusing to Save Search Results'> Results</name>
            <t>
   In some cases, the server MAY <bcp14>MAY</bcp14> refuse to save a SEARCH (SAVE) result,
   for example, if an internal limit on the number of saved results is
   reached.
   In this case, the server MUST <bcp14>MUST</bcp14> return a tagged NO response containing
   the NOTSAVED response code and set the search result variable to the
   empty sequence, as described in <xref target="search-save"/>. target="search-save" format="default"/>.
            </t>
          </section>
          <section title='Examples showing use anchor="search-save-examples" numbered="true" toc="default">
            <name>Examples Showing Use of the SAVE result option' anchor='search-save-examples'>

   <!--RFC Editor: I am happy if you decide to extract comments from examples and delete this sentence.
   Murray commented that most comments can be extracted.
   Don't bother if you think this is lots of work.--> Result Option</name>

   <t>Only in this section: explanatory comments in examples that start with // are not part of
   the protocol.
   </t>
     <ol spacing="normal" type="1"><li>
            <t>
   1)
     The following example demonstrates how the client can use the
      result of a SEARCH command to FETCH headers of interesting
      messages:
            </t>

<figure><artwork>
 <t>
Example 1:
	  </t>
<sourcecode type="">
  C: A282 SEARCH RETURN (SAVE) FLAGGED SINCE 1-Feb-1994
      NOT FROM "Smith"
  S: A282 OK SEARCH completed, result saved
  C: A283 FETCH $ (UID INTERNALDATE FLAGS BODY.PEEK[HEADER])
  S: * 2 FETCH (UID 14 ...
  S: * 84 FETCH (UID 100 ...
  S: * 882 FETCH (UID 1115 ...
  S: A283 OK completed
</artwork></figure>
</sourcecode>
            <t>
   The client can also pipeline the two commands:
            </t>

<figure><artwork>
  <t>
Example 2:
	  </t>
<sourcecode type="">
  C: A282 SEARCH RETURN (SAVE) FLAGGED SINCE 1-Feb-1994
      NOT FROM "Smith"
  C: A283 FETCH $ (UID INTERNALDATE FLAGS BODY.PEEK[HEADER])
  S: A282 OK SEARCH completed
  S: * 2 FETCH (UID 14 ...
  S: * 84 FETCH (UID 100 ...
  S: * 882 FETCH (UID 1115 ...
  S: A283 OK completed
</artwork></figure>

   <t>
   2)
</sourcecode></li>

            <li><t>
  The following example demonstrates that the result of one SEARCH
      command can be used as input to another SEARCH command:
            </t>

<figure><artwork>
 <t>
Example 3:
	  </t>
<sourcecode type="">
  C: A300 SEARCH RETURN (SAVE) SINCE 1-Jan-2004
      NOT FROM "Smith"
  S: A300 OK SEARCH completed
  C: A301 UID SEARCH UID $ SMALLER 4096
  S: * ESEARCH (TAG "A301") UID ALL 17,900,901
  S: A301 OK completed
</artwork></figure>
</sourcecode>
            <t>
Note that the second command in Example 3 can be replaced with:<vspace/> with:</t>

<sourcecode type="">
  C: A301 UID SEARCH $ SMALLER 4096<vspace/> 4096
</sourcecode>
<t>
   and the result of the command would be the same.
   </t>
            </t></li>
     <li> <t>
   3)
   The following example shows that the "$"
      marker can be combined with other message numbers using the OR
      SEARCH criterion.
            </t>

<figure><artwork>
 <t>
Example 4:
	  </t>
<sourcecode type="">
  C: P282 SEARCH RETURN (SAVE) SINCE 1-Feb-1994
      NOT FROM "Smith"
  S: P282 OK SEARCH completed
  C: P283 SEARCH CHARSET UTF-8 (OR $ 1,3000:3021) TEXT {8+}
  C: YYYYYYYY мать
  S: * ESEARCH (TAG "P283") ALL 882,1102,3003,3005:3006
  S: P283 OK completed
</artwork></figure>

   <t>
   Note: Since this document format is restricted to 7-bit ASCII text,
   it is not possible to show actual UTF-8 data.  The "YYYYYYYY" is a
   placeholder for what would be 8 octets of 8-bit data in an actual
   transaction.
   </t>

   <t>
   4)
</sourcecode>
   </li>
   <li><t>
   The following example demonstrates that a failed SEARCH sets the
      search result variable to the empty list. The server doesn't implement
      the KOI8-R charset.
            </t>

<figure><artwork>
 <t>
Example 5:
	  </t>
<sourcecode type="">
  C: B282 SEARCH RETURN (SAVE) SINCE 1-Feb-1994
      NOT FROM "Smith"
  S: B282 OK SEARCH completed
  C: B283 SEARCH RETURN (SAVE) CHARSET KOI8-R
      (OR $ 1,3000:3021) TEXT {4}
  C: XXXX
  S: B283 NO [BADCHARSET UTF-8] KOI8-R is not supported
 //After this command command, the saved result variable contains
 //no messages.  A client that wants to reissue the B283
 //SEARCH command with another CHARSET would have to reissue
 //the B282 command as well.  One possible workaround for
 //this is to include the desired CHARSET parameter
 //in the earliest SEARCH RETURN (SAVE) command in a
 //sequence of related SEARCH commands, to cause
 //the earliest SEARCH in the sequence to fail.
 //A better approach might be to always use CHARSET UTF-8
 //instead.
</artwork></figure>
</sourcecode>
            <t>
   Note: Since this document format is restricted to 7-bit ASCII text,
   it is not possible to show actual KOI8-R data.  The "XXXX" is a
   placeholder for what would be 4 octets of 8-bit data in an actual
   transaction.
   </t>

   <t>
   5)
            </t></li>
         <li><t>
  The following example demonstrates that it is not an error to use
      the "$" marker when it contains no messages.
            </t>

<figure><artwork>
 <t>
Example 6:
	  </t>
<sourcecode type="">
  C: E282 SEARCH RETURN (SAVE) SINCE 28-Oct-2006
      NOT FROM "Eric"
  C: E283 COPY $ "Other Messages"
 //The "$" contains no messages
  S: E282 OK SEARCH completed
  S: E283 OK COPY completed, nothing copied
</artwork></figure>

<figure><artwork>
</sourcecode>
 <t>
Example 7:
	  </t>
<sourcecode type="">
  C: F282 SEARCH RETURN (SAVE) KEYWORD $Junk
  C: F283 COPY $ "Junk"
  C: F284 STORE $ +FLAGS.Silent (\Deleted)
  S: F282 OK SEARCH completed
  S: F283 OK COPY completed
  S: F284 OK STORE completed
</artwork></figure>

<figure><artwork>
</sourcecode>
 <t>
Example 8:
	  </t>
<sourcecode type="">
  C: G282 SEARCH RETURN (SAVE) KEYWORD $Junk
  C: G283 SEARCH RETURN (ALL) SINCE 28-Oct-2006
      FROM "Eric"
 // The server can execute the two SEARCH commands
 // in any order, as they don't have any dependency.
 // For example, it may return:
  S: * ESEARCH (TAG "G283") ALL 3:15,27,29:103
  S: G283 OK SEARCH completed
  S: G282 OK SEARCH completed
</artwork></figure>
</sourcecode>
            <t>
   The following example demonstrates that the result of the second
   SEARCH RETURN (SAVE) always overrides the result of the first.
</t>

<figure><artwork>
 <t>
Example 9:
	  </t>
<sourcecode type="">
  C: H282 SEARCH RETURN (SAVE) KEYWORD $Junk
  C: H283 SEARCH RETURN (SAVE) SINCE 28-Oct-2006
      FROM "Eric"
  S: H282 OK SEARCH completed
  S: H283 OK SEARCH completed
 // At this point "$" would contain results of H283
</artwork></figure>
</sourcecode>
            <t>
   The following example demonstrates behavioral difference for
   different combinations of ESEARCH result options.
	    </t>

<figure><artwork>
	     <t>
Example 10:
	  </t>
<sourcecode type="">
  C: C282 SEARCH RETURN (ALL) SINCE 12-Feb-2006
      NOT FROM "Smith"
  S: * ESEARCH (TAG "C283") ALL 2,10:15,21
//$ value hasn't changed
  S: C282 OK SEARCH completed

  C: C283 SEARCH RETURN (ALL SAVE) SINCE 12-Feb-2006
      NOT FROM "Smith"
  S: * ESEARCH (TAG "C283") ALL 2,10:15,21
//$ value is 2,10:15,21
  S: C283 OK SEARCH completed

  C: C284 SEARCH RETURN (SAVE MIN) SINCE 12-Feb-2006
      NOT FROM "Smith"
  S: * ESEARCH (TAG "C284") MIN 2
//$ value is 2
  S: C284 OK SEARCH completed

  C: C285 SEARCH RETURN (MAX SAVE MIN) SINCE
      12-Feb-2006 NOT FROM "Smith"
  S: * ESEARCH (TAG "C285") MIN 2 MAX 21
//$ value is 2,21
  S: C285 OK SEARCH completed

  C: C286 SEARCH RETURN (MAX SAVE MIN COUNT)
      SINCE 12-Feb-2006 NOT FROM "Smith"
  S: * ESEARCH (TAG "C286") MIN 2 MAX 21 COUNT 8
//$ value is 2,10:15,21
  S: C286 OK SEARCH completed

  C: C286 SEARCH RETURN (ALL SAVE MIN) SINCE
      12-Feb-2006 NOT FROM "Smith"
  S: * ESEARCH (TAG "C286") MIN 2 ALL 2,10:15,21
//$ value is 2,10:15,21
  S: C286 OK SEARCH completed
</artwork></figure>
</sourcecode>
	 </li></ol>
          </section>
        </section>
        <section title='FETCH Command' anchor='fetch-command'>
      <iref item='FETCH (command)'/> anchor="fetch-command" numbered="true" toc="default">
          <name>FETCH Command</name>
          <iref item="FETCH (command)" subitem="" primary="false"/>
          <dl newline="false" spacing="normal" indent="14">
            <dt>Arguments:</dt>
            <dd>
              <t>sequence set</t>
              <t>
   <list style='hanging' hangIndent='12'>
   <t hangText='Arguments:'>sequence set<vspace/>
               message data item names or macro</t>

   <t hangText='Responses:'>untagged responses: FETCH</t>

   <t hangText='Result:'>OK - fetch completed<vspace/>
               NO - fetch
            </dd>
            <dt>Responses:</dt>
            <dd>
            <dl spacing="compact">
	      <dt>untagged responses:</dt><dd>FETCH</dd>
	    </dl>
	    </dd>
            <dt>Result:</dt>
            <dd>
	      <dl spacing="compact">
              <dt>OK -</dt><dd>fetch completed</dd>
              <dt>NO -</dt><dd>fetch error: can't fetch that data<vspace/>
               BAD - command data</dd>
              <dt>BAD -</dt><dd>command unknown or arguments invalid</t>
   </list>
   </t> invalid</dd>
	      </dl>
            </dd>
          </dl>
          <t>
      The FETCH command retrieves data associated with a message in the
      mailbox.  The data items to be fetched can be either a single atom
      or a parenthesized list.
          </t>
          <t>
      Most data items, identified in the formal syntax (<xref target='IMAP-ABNF'/>) target="IMAP-ABNF" format="default"/>) under the
      msg-att-static rule, are static and MUST NOT <bcp14>MUST NOT</bcp14> change for any
      particular message.  Other data items, identified in the formal
      syntax under the msg-att-dynamic rule, MAY change, <bcp14>MAY</bcp14> change either as a
      result of a STORE command or due to external events.

           <list>
           <t>

          </t>
          <ul empty="true" spacing="normal">
            <li>
           For example, if a client receives an ENVELOPE for a
           message when it already knows the envelope, it can
           safely ignore the newly transmitted envelope.
           </t>
           </list>
      </t>
           </li>
          </ul>
          <t>
      There are three macros which that specify commonly-used commonly used sets of data
      items,
      items and can be used instead of data items.  A macro must be
      used by itself, itself and not in conjunction with other macros or data
      items.

      <list style='hanging'>
      <t hangText='ALL'>

          </t>
          <dl newline="true" spacing="normal">
            <dt>ALL</dt>
            <dd>
              <iref item='ALL item="ALL (fetch item)'/> item)" subitem="" primary="false"/>
         Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)</t>

      <t hangText='FAST'> ENVELOPE)</dd>
            <dt>FAST</dt>
            <dd>
              <iref item='FAST item="FAST (fetch item)'/> item)" subitem="" primary="false"/>
         Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE)</t>

      <t hangText='FULL'> RFC822.SIZE)</dd>
            <dt>FULL</dt>
            <dd>
              <iref item='FULL item="FULL (fetch item)'/> item)" subitem="" primary="false"/>
         Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE
         BODY)</t>
      </list>
      </t>
         BODY)</dd>
          </dl>
          <t>Several data items reference "section" or "section-binary".
      See <xref target="fetch-section"/> target="fetch-section" format="default"/> for their detailed definition.</t>
          <t>
      The currently defined data items that can be fetched are:

      <list style='hanging'>

      <t hangText='BINARY[&lt;section-binary>]&lt;&lt;partial>>'>
      <iref item='BINARY[&lt;section-binary>]&lt;&lt;partial>>

          </t>
          <dl newline="true" spacing="normal">
            <dt>BINARY[&lt;section-binary&gt;]&lt;&lt;partial&gt;&gt;</dt>
            <dd>
              <t><iref item="BINARY[&lt;section-binary&gt;]&lt;&lt;partial&gt;&gt; (fetch item)'/>
        <list>
          <t> item)" subitem="" primary="false"/>
          Requests that the specified section be transmitted after
          performing Content-Transfer-Encoding-related decoding.
          </t> decoding of the section's Content-Transfer-Encoding.</t>
           <t>
          The &lt;partial&gt; argument, if present, requests that a subset of
          the data be returned.  The semantics of a partial FETCH BINARY
          command are the same as for a partial FETCH BODY command, with
          the exception that the &lt;partial&gt; arguments refer to the DECODED
          section data.
          </t>

          <t>
          <!--///Should this be allowed for message/global?-->
          Note that this data item can only be requested for leaf
          (i.e. non multipart/*, non message/rfc822 and non message/global) body parts.
          </t>

        </list>
      </t>

      <t hangText='BINARY.PEEK[&lt;section-binary>]&lt;&lt;partial>>'> parts: those that have media types other than multipart/*, message/rfc822, or message/global.</t>
          </dd>
            <dt>BINARY.PEEK[&lt;section-binary&gt;]&lt;&lt;partial&gt;&gt;</dt>
            <dd>
              <iref item='BINARY.PEEK[&lt;section-binary>]&lt;&lt;partial>> item="BINARY.PEEK[&lt;section-binary&gt;]&lt;&lt;partial&gt;&gt; (fetch item)'/> item)" subitem="" primary="false"/>
         An alternate form of BINARY[&lt;section-binary>] BINARY[&lt;section-binary&gt;] that does not implicitly
         set the \Seen flag.</t>

      <t hangText='BINARY.SIZE[&lt;section-binary>]'>
      <iref item='BINARY.SIZE[&lt;section-binary>] flag.</dd>
            <dt>BINARY.SIZE[&lt;section-binary&gt;]</dt>
            <dd>
              <t><iref item="BINARY.SIZE[&lt;section-binary&gt;] (fetch item)'/>
        <list>
          <t> item)" subitem="" primary="false"/>
          Requests the decoded size of the section (i.e., the size to
          expect in response to the corresponding FETCH BINARY request).
          </t>
                <t>
          Note: client authors are cautioned that this might be an
          expensive operation for some server implementations.
          Needlessly issuing this request could result in degraded
          performance due to servers having to calculate the value every
          time the request is issued.
          </t> issued.</t>
          <t>
          <!--///Should this be allowed for message/global?-->
          Note that this data item can only be requested for leaf
          (i.e. non multipart/*, non message/rfc822 and non message/global) body parts.
          </t>

        </list>
      </t>

      <t hangText='BODY'> parts: those that have media types other than multipart/*, message/rfc822, or message/global.</t>
          </dd>
            <dt>BODY</dt>
            <dd>
              <iref item='BODY item="BODY (fetch item)'/> item)" subitem="" primary="false"/>
         Non-extensible form of BODYSTRUCTURE.</t>

      <t hangText='BODY[&lt;section>]&lt;&lt;partial>>'>
      <iref item='BODY[&lt;section>]&lt;&lt;partial>> BODYSTRUCTURE.</dd>
            <dt>BODY[&lt;section&gt;]&lt;&lt;partial&gt;&gt;</dt>
            <dd>
              <t><iref item="BODY[&lt;section&gt;]&lt;&lt;partial&gt;&gt; (fetch item)'/>
      <list>
         <t> item)" subitem="" primary="false"/>
         The text of a particular body section. If BODY[] is specified
     (the section specification is omitted), the FETCH is requesting
     the <xref target="RFC5322" format="default"/> expression of the entire message.
         </t>
           <t>
         It is possible to fetch a substring of the designated text.
         This is done by appending an open angle bracket ("&lt;"), the
         octet position of the first desired octet, a period, the
         maximum number of octets desired, and a close angle bracket
         (">")
         ("&gt;") to the part specifier.  If the starting octet is beyond
         the end of the text, an empty string is returned.
         </t>
                  <t>
         Any partial fetch that attempts to read beyond the end of the
         text is truncated as appropriate.  A partial fetch that starts
         at octet 0 is returned as a partial fetch, even if this
         truncation happened.

            <list>
            <t>
                  </t>
            <t indent="3">
            Note: This means that BODY[]&lt;0.2048> BODY[]&lt;0.2048&gt; of a 1500-octet message
            will return BODY[]&lt;0> BODY[]&lt;0&gt; with a literal of size 1500, not
            BODY[].
            </t>

            <t>
            <t indent="3">
            Note: A substring fetch of a HEADER.FIELDS or
            HEADER.FIELDS.NOT part specifier is calculated after
            subsetting the header.
            </t>
            </list>

                  <t>
         The \Seen flag is implicitly set; if this causes the flags to
         change, they SHOULD <bcp14>SHOULD</bcp14> be included as part of the FETCH responses.</t>
      </list> responses.
		 </t>

      <t hangText='BODY.PEEK[&lt;section>]&lt;&lt;partial>>'>
               </dd>
            <dt>BODY.PEEK[&lt;section&gt;]&lt;&lt;partial&gt;&gt;</dt>
            <dd>
              <iref item='BODY.PEEK[&lt;section>]&lt;&lt;partial>> item="BODY.PEEK[&lt;section&gt;]&lt;&lt;partial&gt;&gt; (fetch item)'/> item)" subitem="" primary="false"/>
         An alternate form of BODY[&lt;section>] BODY[&lt;section&gt;] that does not implicitly
         set the \Seen flag.</t>

      <t hangText='BODYSTRUCTURE'> flag.</dd>
            <dt>BODYSTRUCTURE</dt>
            <dd>
              <iref item='BODYSTRUCTURE item="BODYSTRUCTURE (fetch item)'/> item)" subitem="" primary="false"/>
         The <xref target='MIME-IMB'/> target="RFC2045" format="default"/> body structure of the message.  This is computed
         by the server by parsing the <xref target='MIME-IMB'/> target="RFC2045" format="default"/> header fields in the
         <xref target='RFC-5322'/> target="RFC5322" format="default"/> header and <xref target='MIME-IMB'/> target="RFC2045" format="default"/> headers.
         See <xref target='fetch-response'/> target="fetch-response" format="default"/> for more details.</t>

      <t hangText='ENVELOPE'> details.</dd>
            <dt>ENVELOPE</dt>
            <dd>
              <iref item='ENVELOPE item="ENVELOPE (fetch item)'/> item)" subitem="" primary="false"/>
         The envelope structure of the message.  This is computed by the
         server by parsing the <xref target='RFC-5322'/> target="RFC5322" format="default"/> header into the component
         parts, defaulting various fields as necessary.
         See <xref target='fetch-response'/> target="fetch-response" format="default"/> for more details.</t>

      <t hangText='FLAGS'> details.</dd>
            <dt>FLAGS</dt>
            <dd>
              <iref item='FLAGS item="FLAGS (fetch item)'/> item)" subitem="" primary="false"/>
         The flags that are set for this message.</t>

      <t hangText='INTERNALDATE'> message.</dd>
            <dt>INTERNALDATE</dt>
            <dd>
              <iref item='INTERNALDATE (fetch item)'/> item="INTERNALDATE (
fetch item)" subitem="" primary="false"/>
         The internal date of the message.</t>

      <t hangText='RFC822.SIZE'> message.</dd>
            <dt>RFC822.SIZE</dt>
            <dd>
              <iref item='RFC822.SIZE item="RFC822.SIZE (fetch item)'/> item)" subitem="" primary="false"/>
         The <xref target='RFC-5322'/> size of the message.</t>

      <t hangText='UID'> message, as defined in <xref target="RFC822.SIZE_message_attribute" />.</dd>
            <dt>UID</dt>
            <dd>
              <iref item='UID item="UID (fetch item)'/> item)" subitem="" primary="false"/>
         The unique identifier for the message.</t>
      </list>
   </t>

<figure><artwork> message.</dd>
          </dl>
  <t>
Example:
	  </t>
<sourcecode type="">
  C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)])
  S: * 2 FETCH ....
  S: * 3 FETCH ....
  S: * 4 FETCH ....
  S: A654 OK FETCH completed
</artwork></figure>
</sourcecode>
          <section title='FETCH section specification' anchor='fetch-section'> anchor="fetch-section" numbered="true" toc="default">
            <name>FETCH Section Specification</name>
            <t>Several FETCH data items reference "section" or "section-binary".
         The section specification is a set of zero or more part specifiers
         delimited by periods.  A part specifier is either a part number
         or one of the following: HEADER, HEADER.FIELDS,
         HEADER.FIELDS.NOT, MIME, and TEXT. (Non numeric (Non-numeric part specifiers
         have to be the last specifier in a section specification.)
         An empty section specification refers to the entire message, including the
         header.
            </t>
            <t>
              Every message has at least one part number.  Non-<xref target='MIME-IMB'/>
         messages, and non-multipart <xref target='MIME-IMB'/>

Messages that do not use MIME, and MIME messages with that are not multipart and have no encapsulated message, message within them, only have a part 1.
            </t>
            <t>
         Multipart messages are assigned consecutive part numbers, as
         they occur in the message.  If a particular part is of type
         message or multipart, its parts MUST <bcp14>MUST</bcp14> be indicated by a period
         followed by the part number within that nested multipart part.
            </t>
            <t>
         A part of type MESSAGE/RFC822 or MESSAGE/GLOBAL also has nested part numbers,
         referring to parts of the MESSAGE part's body.
            </t>
            <t>
         <iref item='HEADER item="HEADER (part specifier)'/> specifier)" subitem="" primary="false"/>
              <iref item='HEADER.FIELDS item="HEADER.FIELDS (part specifier)'/> specifier)" subitem="" primary="false"/>
              <iref item='HEADER.FIELDS.NOT item="HEADER.FIELDS.NOT (part specifier)'/> specifier)" subitem="" primary="false"/>
              <iref item='TEXT item="TEXT (part specifier)'/> specifier)" subitem="" primary="false"/>
         The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, and TEXT part
         specifiers can be the sole part specifier or can be prefixed by
         one or more numeric part specifiers, provided that the numeric
         part specifier refers to a part of type MESSAGE/RFC822 or MESSAGE/GLOBAL.  The
         MIME part specifier MUST <bcp14>MUST</bcp14> be prefixed by one or more numeric
         part specifiers.
            </t>
            <t>
         The HEADER, HEADER.FIELDS, and HEADER.FIELDS.NOT part
         specifiers refer to the <xref target='RFC-5322'/> target="RFC5322" format="default"/> header of the message or of
         an encapsulated <xref target='MIME-IMT'/> target="RFC2046" format="default"/> MESSAGE/RFC822 or MESSAGE/GLOBAL message.
         HEADER.FIELDS and HEADER.FIELDS.NOT are followed by a list of
         field-name
         field-names (as defined in <xref target='RFC-5322'/>) names, target="RFC5322" format="default"/>) and return a
         subset of the header.  The subset returned by HEADER.FIELDS
         contains only those header fields with a field-name that
         matches one of the names in the list; similarly, the subset
         returned by HEADER.FIELDS.NOT contains only the header fields
         with a non-matching field-name.  The field-matching is
         ASCII range case-insensitive
         ASCII-range case insensitive but is otherwise exact.  Subsetting does not
         exclude the <xref target='RFC-5322'/> target="RFC5322" format="default"/> delimiting blank line between the header
         and the body; the blank line is included in all header fetches,
         except in the case of a message which that has no body and no blank
         line.
            </t>
            <t>
         <iref item='MIME item="MIME (part specifier)'/> specifier)" subitem="" primary="false"/>
         The MIME part specifier refers to the <xref target='MIME-IMB'/> target="RFC2045" format="default"/> header for
         this part.
            </t>
            <t>
         The TEXT part specifier refers to the text body of the message,
         omitting the <xref target='RFC-5322'/> target="RFC5322" format="default"/> header.

            <list><t>

            </t>
          <t>
            Here is an example of a complex message with some of its
            part specifiers:
            </t></list>

<figure><artwork>
	  </t>

<artwork type="" align="left" alt=""><![CDATA[
  HEADER     ([RFC-5322]     ([RFC5322] header of the message)
  TEXT       ([RFC-5322]       ([RFC5322] text body of the message) MULTIPART/MIXED
  1          TEXT/PLAIN
  2          APPLICATION/OCTET-STREAM
  3          MESSAGE/RFC822
  3.HEADER   ([RFC-5322]   ([RFC5322] header of the message)
  3.TEXT     ([RFC-5322]     ([RFC5322] text body of the message) MULTIPART/MIXED
  3.1        TEXT/PLAIN
  3.2        APPLICATION/OCTET-STREAM
  4          MULTIPART/MIXED
  4.1        IMAGE/GIF
  4.1.MIME   ([MIME-IMB] header for the IMAGE/GIF)
  4.2        MESSAGE/RFC822
  4.2.HEADER ([RFC-5322] ([RFC5322] header of the message)
  4.2.TEXT   ([RFC-5322]   ([RFC5322] text body of the message) MULTIPART/MIXED
  4.2.1      TEXT/PLAIN
  4.2.2      MULTIPART/ALTERNATIVE
  4.2.2.1    TEXT/PLAIN
  4.2.2.2    TEXT/RICHTEXT
</artwork></figure>
      </t>
]]></artwork>
          </section>
        </section>
        <section title='STORE Command'>
      <iref item='STORE (command)'/> numbered="true" toc="default">
          <name>STORE Command</name>
          <iref item="STORE (command)" subitem="" primary="false"/>
          <dl newline="false" spacing="normal" indent="14">
            <dt>Arguments:</dt>
            <dd>
              <t>sequence set</t>
              <t>
   <list style='hanging' hangIndent='12'>
   <t hangText='Arguments:'>sequence set<vspace/>
               message data item name<vspace/> name</t>
              <t>
               value for message data item</t>

   <t hangText='Responses:'>untagged responses: FETCH</t>

   <t hangText='Result:'>OK - store completed<vspace/>
               NO - store
            </dd>
            <dt>Responses:</dt>
            <dd>
            <dl spacing="compact">
	      <dt>untagged responses:</dt><dd>FETCH</dd>
	    </dl>
	    </dd>
            <dt>Result:</dt>
            <dd>
	      <dl spacing="compact">
              <dt>OK -</dt><dd>store completed</dd>
              <dt>NO -</dt><dd>store error: can't store that data<vspace/>
               BAD - command data</dd>
              <dt>BAD -</dt><dd>command unknown or arguments invalid</t>
   </list>
   </t> invalid</dd>
	      </dl>
            </dd>
          </dl>
          <t>
      The STORE command alters data associated with a message in the
      mailbox.  Normally, STORE will return the updated value of the
      data with an untagged FETCH response.  A suffix of ".SILENT" in
      the data item name prevents the untagged FETCH, and the server
      SHOULD
      <bcp14>SHOULD</bcp14> assume that the client has determined the updated value
      itself or does not care about the updated value.

           <list><t>

          </t>
          <t indent="3">
           Note: Regardless of whether or not the ".SILENT" suffix
           was used, the server SHOULD <bcp14>SHOULD</bcp14> send an untagged FETCH
           response if a change to a message's flags from an
           external source is observed.  The intent is that the
           status of the flags is determinate without a race
           condition.
           </t></list>
           </t>
          <t>
      The currently defined data items that can be stored are:

      <list style='hanging'>
      <t hangText='FLAGS

          </t>
          <dl newline="true" spacing="normal">
            <dt>FLAGS &lt;flag list>'> list&gt;</dt>
            <dd>
              <iref item='FLAGS item="FLAGS &lt;flag list> list&gt; (store command data item)'/> item)" subitem="" primary="false"/>
         Replace the flags for the message with the
         argument.  The new value of the flags is returned as if a FETCH
         of those flags was done.</t>

      <t hangText='FLAGS.SILENT done.</dd>
            <dt>FLAGS.SILENT &lt;flag list>'> list&gt;</dt>
            <dd>
              <iref item='FLAGS.SILENT item="FLAGS.SILENT &lt;flag list> list&gt; (store command data item)'/> item)" subitem="" primary="false"/>
         Equivalent to FLAGS, but without returning a new value.</t>

      <t hangText='+FLAGS value.</dd>
            <dt>+FLAGS &lt;flag list>'> list&gt;</dt>
            <dd>
              <iref item='+FLAGS item="+FLAGS &lt;flag list>'/> list&gt;" subitem="" primary="false"/>
         Add the argument to the flags for the message.  The new value
         of the flags is returned as if a FETCH of those flags was done.</t>

      <t hangText='+FLAGS.SILENT done.</dd>
            <dt>+FLAGS.SILENT &lt;flag list>'> list&gt;</dt>
            <dd>
              <iref item='+FLAGS.SILENT item="+FLAGS.SILENT &lt;flag list>'/> list>" subitem="" primary="false"/>
         Equivalent to +FLAGS, but without returning a new value.</t>

      <t hangText='-FLAGS value.</dd>
            <dt>-FLAGS &lt;flag list>'> list&gt;</dt>
            <dd>
              <iref item='-FLAGS item="-FLAGS &lt;flag list>'/> list&gt;" subitem="" primary="false"/>
         Remove the argument from the flags for the message.  The new
         value of the flags is returned as if a FETCH of those flags was
         done.</t>

      <t hangText='-FLAGS.SILENT
         done.</dd>
            <dt>-FLAGS.SILENT &lt;flag list>'> list&gt;</dt>
            <dd>
              <iref item='-FLAGS.SILENT item="-FLAGS.SILENT &lt;flag list>'/> list&gt;" subitem="" primary="false"/>
         Equivalent to -FLAGS, but without returning a new value.</t>
      </list>
   </t>

<figure><artwork> value.</dd>
          </dl>
  <t>
Example:
	  </t>
<sourcecode type="">
  C: A003 STORE 2:4 +FLAGS (\Deleted)
  S: * 2 FETCH (FLAGS (\Deleted \Seen))
  S: * 3 FETCH (FLAGS (\Deleted))
  S: * 4 FETCH (FLAGS (\Deleted \Flagged \Seen))
  S: A003 OK STORE completed
</artwork></figure>
</sourcecode>
        </section>
        <section title='COPY Command' anchor='copy-command'>
      <iref item='COPY (command)'/> anchor="copy-command" numbered="true" toc="default">
          <name>COPY Command</name>
          <iref item="COPY (command)" subitem="" primary="false"/>
          <dl newline="false" spacing="normal" indent="14">
            <dt>Arguments:</dt>
            <dd>
              <t>sequence set</t>
              <t>
   <list style='hanging' hangIndent='12'>
   <t hangText='Arguments:'>sequence set<vspace/>
               mailbox name</t>

   <t hangText='Responses:'>no
            </dd>
            <dt>Responses:</dt>
            <dd>no specific responses for this command</t>

   <t hangText='Result:'>OK - copy completed<vspace/>
               NO - copy command</dd>
            <dt>Result:</dt>
            <dd>
	      <dl spacing="compact">
              <dt>OK -</dt><dd>copy completed</dd>
              <dt>NO -</dt><dd>copy error: can't copy those messages or to that<vspace/>
                    name<vspace/>
               BAD - command that
                    name</dd>
		    <dt>BAD -</dt><dd>command unknown or arguments invalid</t>
   </list>
   </t> invalid</dd>
	      </dl>
            </dd>
          </dl>
          <t>
      The COPY command copies the specified message(s) to the end of the
      specified destination mailbox.  The flags and internal date of the
      message(s) SHOULD <bcp14>SHOULD</bcp14> be preserved in the copy.
          </t>
          <t>
      If the destination mailbox does not exist, a server MUST <bcp14>MUST</bcp14> return
      an error.  It MUST NOT <bcp14>MUST NOT</bcp14> automatically create the mailbox.  Unless
      it is certain that the destination mailbox can not be created, the
      server MUST <bcp14>MUST</bcp14> send the response code "[TRYCREATE]" as the prefix of
      the text of the tagged NO response.  This gives a hint to the
      client that it can attempt a CREATE command and retry the COPY if
      the CREATE is successful.
          </t>
          <t>
      If the COPY command is unsuccessful for any reason, server
      implementations MUST <bcp14>MUST</bcp14> restore the destination mailbox to its state
      before the COPY attempt (other than possibly incrementing UIDNEXT),
      i.e.
      i.e., partial copy MUST NOT <bcp14>MUST NOT</bcp14> be done.
          </t>
          <t>
     On successful completion of a COPY, the server returns a COPYUID response code
     (see <xref target='server-status-responses'/>). target="server-status-responses" format="default"/>). Two exception exceptions to this requirement
     are listed below.
          </t>
          <t>
     In the case of a mailbox that has permissions set so that the client
     can COPY to the mailbox, but not SELECT or EXAMINE it, the
     server MUST NOT <bcp14>MUST NOT</bcp14> send an a COPYUID response code as it
     would disclose information about the mailbox.
          </t>
          <t>
     In the case of a mailbox that has UIDNOTSTICKY status
     (see <xref target='server-status-responses'/>), target="server-status-responses" format="default"/>),
     the server MAY <bcp14>MAY</bcp14> omit the COPYUID response code as
     it is not meaningful.
          </t>

 <!--
 <t>
     If the server does not return the COPYUID response
     code, the client can discover this information by selecting the
     destination mailbox.  The location of messages placed in the
     destination mailbox by COPY can be determined by using
     FETCH and/or SEARCH commands (e.g., for Message-ID).
   </t>
   -->

<figure><artwork>
Example:
	  </t>
<sourcecode type="">
  C: A003 COPY 2:4 MEETING
  S: A003 OK [COPYUID 38505 304,319:320 3956:3958] COPY completed
</artwork></figure>
</sourcecode>
        </section>
        <section title='MOVE Command'>
      <iref item='MOVE (command)'/> numbered="true" toc="default">
          <name>MOVE Command</name>
          <iref item="MOVE (command)" subitem="" primary="false"/>
          <dl newline="false" spacing="normal" indent="14">
            <dt>Arguments:</dt>
            <dd>
              <t>sequence set</t>
              <t>
   <list style='hanging' hangIndent='12'>
   <t hangText='Arguments:'>sequence set<vspace/>
               mailbox name</t>

   <t hangText='Responses:'>no
            </dd>
            <dt>Responses:</dt>
            <dd>no specific responses for this command</t>

   <t hangText='Result:'>OK - move completed<vspace/>
               NO - move command</dd>
            <dt>Result:</dt>
            <dd>
	      <dl spacing="compact">
              <dt>OK -</dt><dd>move completed</dd>
              <dt>NO -</dt><dd>move error: can't move those messages or to that<vspace/>
                    name<vspace/>
               BAD - command that name</dd>
              <dt>BAD -</dt><dd>command unknown or arguments invalid</t>
   </list>
   </t> invalid</dd>
	      </dl>
            </dd>
          </dl>
          <t>
   The MOVE command moves the specified message(s) to the end of the
   specified destination mailbox.  The flags and internal date of the
   message(s) SHOULD <bcp14>SHOULD</bcp14> be preserved.
          </t>
          <t>
   This means that a new message is created in the target mailbox with a
   new UID, the original message is removed from the source mailbox, and
   it appears to the client as a single action.  This has the same
   effect for each message as this sequence:

   <list style='numbers'>

       <t>[UID] COPY</t>

       <t>[UID]
          </t>
          <ol spacing="normal" type="1"><li>[UID] COPY</li>
            <li>[UID] STORE +FLAGS.SILENT \DELETED</t>

       <t>UID EXPUNGE</t>
   </list>

   </t> \DELETED</li>
            <li>UID EXPUNGE</li>
          </ol>
          <t>
   Although the effect of the MOVE is the same as the preceding steps,
   the semantics are not identical: The the intermediate states produced by
   those steps do not occur, and the response codes are different.  In
   particular, though the COPY and EXPUNGE response codes will be
   returned, response codes for a STORE MUST NOT <bcp14>MUST NOT</bcp14> be generated generated, and the
   \Deleted flag MUST NOT <bcp14>MUST NOT</bcp14> be set for any message.
          </t>
          <t>
   Unlike the COPY command, MOVE of a set of messages might fail partway
   through the set.  Regardless of whether the command is successful in
   moving the entire set, each individual message MUST either <bcp14>MUST</bcp14> be either moved
   or unaffected.  The server MUST <bcp14>MUST</bcp14> leave each message in a state where
   it is in at least one of the source or target mailboxes (no message
   can be lost or orphaned).  The server SHOULD NOT <bcp14>SHOULD NOT</bcp14> leave any message in
   both mailboxes (it would be bad for a partial failure to result in a
   bunch of duplicate messages).  This is true even if the server
   returns a tagged NO response to the command.
          </t>
          <t>
   If the destination mailbox does not exist, a server MUST <bcp14>MUST</bcp14> return
   an error.  It MUST NOT <bcp14>MUST NOT</bcp14> automatically create the mailbox.  Unless
   it is certain that the destination mailbox can not cannot be created, the
   server MUST <bcp14>MUST</bcp14> send the response code "[TRYCREATE]" as the prefix of
   the text of the tagged NO response.  This gives a hint to the
   client that it can attempt a CREATE command and retry the MOVE if
   the CREATE is successful.
          </t>
          <t>
   Because of the similarity of MOVE to COPY, extensions that affect
   COPY affect MOVE in the same way.  Response codes listed in
   <xref target='server-status-responses'/>, target="server-status-responses" format="default"/>, as well as those defined by
   extensions, are sent as indicated for COPY.
          </t>
          <t>
   Servers send COPYUID in response to a MOVE or a UID MOVE (see <xref target='uid-commands'/>) target="uid-commands" format="default"/>) command.
   For additional information about COPYUID COPYUID, see <xref target='server-status-responses'/>. target="server-status-responses" format="default"/>.
   Note that there are several exceptions listed in <xref target='copy-command'/> target="copy-command" format="default"/>
   that allow servers not to return COPYUID.
          </t>
          <t>
   Servers are also REQUIRED <bcp14>REQUIRED</bcp14> to send the COPYUID
   response code in an untagged OK before sending EXPUNGE or similar
   responses.  (Sending COPYUID in the tagged OK, as described in the
   UIDPLUS specification, <xref target="copy-command"/>, means that clients first receive an EXPUNGE
   for a message and afterwards COPYUID for the same message.  It can be
   unnecessarily difficult to process that sequence usefully.)
          </t>

<figure><artwork>
  <t>
An example:
  </t>

<sourcecode type="">
  C: a UID MOVE 42:69 foo
  S: * OK [COPYUID 432432 42:69 1202:1229]
  S: * 22 EXPUNGE
  ...More EXPUNGE responses from the server...
  S: a OK Done
</artwork></figure>
</sourcecode>
          <t>
   Note that the server may send unrelated EXPUNGE responses as well, if
   any happen to have been expunged at the same time; this is normal
   IMAP operation.
          </t>

<!--
   <t>
   Implementors will need to read [RFC4315] to understand what UID
   EXPUNGE does, though full implementation of [RFC4315] is not
   necessary.
   </t>
  -->
   <t>
   Note that moving a message to the currently selected mailbox (that
   is, where the source and target mailboxes are the same) is allowed
   when copying the message to the currently selected mailbox is
   allowed.
          </t>
          <t>
   The server may send EXPUNGE responses before the tagged
   response, so the client cannot safely send more commands with message
   sequence number arguments while the server is processing MOVE.
          </t>
          <t>
   MOVE and UID MOVE can be pipelined with other commands, but care
   has to be taken.  Both commands modify sequence numbers and also
   allow unrelated EXPUNGE responses.  The renumbering of other messages
   in the source mailbox following any EXPUNGE response can be
   surprising and makes it unsafe to pipeline any command that relies on
   message sequence numbers after a MOVE or UID MOVE.  Similarly, MOVE
   cannot be pipelined with a command that might cause message
   renumbering.  See <xref target='pipelining'/>, target="pipelining" format="default"/> for more information about
   ambiguities as well as handling requirements for both clients and
   servers.
          </t>
        </section>
        <section title='UID Command' anchor='uid-commands'>
      <iref item='UID (command)'/>

   <t>
   <list style='hanging' hangIndent='12'>
   <t hangText='Arguments:'>command name<vspace/> anchor="uid-commands" numbered="true" toc="default">
          <name>UID Command</name>
          <iref item="UID (command)" subitem="" primary="false"/>
          <dl newline="false" spacing="normal" indent="14">
            <dt>Arguments:</dt>
            <dd>
              <t>command name</t>
              <t>
               command arguments</t>

   <t hangText='Responses:'>untagged responses: FETCH,
            </dd>
            <dt>Responses:</dt>
            <dd>
            <dl spacing="compact">
	      <dt>untagged responses:</dt><dd>FETCH, ESEARCH, EXPUNGE</t>

   <t hangText='Result:'>OK - UID command completed<vspace/>
               NO - UID command error<vspace/>
               BAD - command EXPUNGE</dd>
	    </dl>
	    </dd>
            <dt>Result:</dt>
            <dd>
	      <dl spacing="compact">
              <dt>OK -</dt><dd>UID command completed</dd>
              <dt>NO -</dt><dd>UID command error</dd>
              <dt>BAD -</dt><dd>command unknown or arguments invalid</t>
   </list>
   </t>

<!--///Alexey: Split into subsections by command?--> invalid</dd>
	      </dl>
            </dd>
          </dl>
   <t>
      The UID command has three forms.  In the first form, it takes as its
      arguments a COPY, MOVE, FETCH, or STORE command with arguments
      appropriate for the associated command.  However, the numbers in
      the sequence set sequence-set argument are unique identifiers instead of
      message sequence numbers.  Sequence set  Sequence-set ranges are permitted, but
      there is no guarantee that unique identifiers will be contiguous.
          </t>
          <t>
      A non-existent unique identifier is ignored without any error
      message generated.  Thus, it is possible for a UID FETCH command
      to return an OK without any data or a UID COPY, UID MOVE MOVE, or UID STORE to
      return an OK without performing any operations.
          </t>

<!--
2.1.  UID EXPUNGE Command

   Arguments:  sequence set

   Data:       untagged responses: EXPUNGE

   Result:     OK - expunge completed
               NO - expunge failure (e.g., permission denied)
               BAD - command unknown or arguments invalid
-->
<t>
      In the second form, the UID command takes an EXPUNGE command with
      an extra parameter the specified that specifies a sequence set of UIDs to operate on.
      The UID EXPUNGE command permanently removes all messages that both have both
      the \Deleted flag set and have a UID that is included in the
      specified sequence set from the currently selected mailbox.  If a
      message either does not have the \Deleted flag set or has a UID
      that is not included in the specified sequence set, it is not
      affected.

        <list>
   </t>

          <t>
            UID EXPUNGE is particularly useful for disconnected use clients.
            By using UID EXPUNGE instead of EXPUNGE when resynchronizing with
            the server, the client can ensure that it does not inadvertantly inadvertently
            remove any messages that have been marked as \Deleted by other
            clients between the time that the client was last connected and
            the time the client resynchronizes.
          </t>
        </list>
   </t>

<figure><artwork>
 <t>
Example:
	  </t>
<sourcecode type="">
  C: A003 UID EXPUNGE 3000:3002
  S: * 3 EXPUNGE
  S: * 3 EXPUNGE
  S: * 3 EXPUNGE
  S: A003 OK UID EXPUNGE completed
</artwork></figure>
</sourcecode>
          <t>
      In the third form, the UID command takes a SEARCH command with
      SEARCH command arguments.  The interpretation of the arguments is
      the same as with SEARCH; however, the numbers returned in a an ESEARCH
      response for a UID SEARCH command are unique identifiers instead
      of message sequence numbers. Also, the corresponding ESEARCH response MUST <bcp14>MUST</bcp14>
      include the UID indicator.
      For example, the command UID SEARCH
      1:100 UID 443:557 returns the unique identifiers corresponding to
      the intersection of two sequence sets, the message sequence number
      range 1:100 1:100, and the UID range 443:557.

           <list>
           <t>

          </t>
           <t indent="3">
           Note: in the above example, the UID range 443:557
           appears.  The same comment about a non-existent unique
           identifier being ignored without any error message also
           applies here.  Hence, even if neither UID 443 or 557
           exist, this range is valid and would include an existing
           UID 495.
           </t>

           <t>
            <t indent="3">
           Also note that a UID range of 559:* always includes the
           UID of the last message in the mailbox, even if 559 is
           higher than any assigned UID value.  This is because the
           contents of a range are independent of the order of the
           range endpoints.  Thus, any UID range with * as one of
           the endpoints indicates at least one message (the
           message with the highest numbered UID), unless the
           mailbox is empty.
           </t>
           </list>
   </t>
          <t>
      The number after the "*" in an untagged FETCH or EXPUNGE response is always a
      message sequence number, not a unique identifier, even for a UID
      command response.  However, server implementations MUST <bcp14>MUST</bcp14> implicitly
      include the UID message data item as part of any FETCH response
      caused by a UID command, regardless of whether a UID was specified
      as a message data item to the FETCH.
          </t>
          <t>
      Note: The rule about including the UID message data item as part
      of a FETCH response primarily applies to the UID FETCH and UID
      STORE commands, including a UID FETCH command that does not
      include UID as a message data item.  Although it is unlikely that
      the other UID commands will cause an untagged FETCH, this rule
      applies to these commands as well.
          </t>

<figure><artwork>
 <t>
Example:
	  </t>
<sourcecode type="">
  C: A999 UID FETCH 4827313:4828442 FLAGS
  S: * 23 FETCH (FLAGS (\Seen) UID 4827313)
  S: * 24 FETCH (FLAGS (\Seen) UID 4827943)
  S: * 25 FETCH (FLAGS (\Seen) UID 4828442)
  S: A999 OK UID FETCH completed
</artwork></figure>
</sourcecode>
        </section>
      </section>
      <section title='Client numbered="true" toc="default">
        <name>Client Commands - Experimental/Expansion'> Experimental/Expansion</name>
        <t>
      Each command which that is not part of this specification
      MUST
      <bcp14>MUST</bcp14> have at least one capability name (see <xref target="capability-command"/>) target="capability-command" format="default"/>) associated with it.
      (Multiple commands can be associated with the same capability name.)
        </t>
        <t>

      Server implementations MUST NOT <bcp14>MUST NOT</bcp14> send any added
      untagged responses (not specified in this specification)
      untagged responses, specification), unless the client requested it
      by issuing the associated experimental command (specified in an extension document) or
      the ENABLE command (<xref target="enable-command"/>). target="enable-command" format="default"/>).
        </t>
        <t>The following example demonstrates how a client can check for the presence of
      a fictitious XPIG-LATIN capability that adds the XPIG-LATIN command and
      the the XPIG-LATIN untagged response.
      (Note that for an extension extension, the command name and the capability name don't
      have to be the same.)</t>

<figure><artwork>
 <t>
Example:
	  </t>
<sourcecode type="">
  C: a441 CAPABILITY
  S: * CAPABILITY IMAP4rev2 XPIG-LATIN
  S: a441 OK CAPABILITY completed
  C: A442 XPIG-LATIN
  S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay
  S: A442 OK XPIG-LATIN ompleted-cay
</artwork></figure>
</sourcecode>
      </section>
    </section>
    <section title='Server Responses' anchor='server-responses'> anchor="server-responses" numbered="true" toc="default">
      <name>Server Responses</name>
      <t>
   Server responses are in three forms: status responses, server data,
   and command continuation request. requests.  The information contained in a
   server response, identified by "Contents:" in the response
   descriptions below, is described by function, not by syntax.  The
   precise syntax of server responses is described in the Formal Syntax "Formal Syntax"
   (<xref target='IMAP-ABNF'/>). target="IMAP-ABNF" format="default"/>).
      </t>
      <t>
   The client MUST <bcp14>MUST</bcp14> be prepared to accept any response at all times.
      </t>
      <t>
   Status responses can be tagged or untagged.  Tagged status responses
   indicate the completion result (OK, NO, or BAD status) of a client
   command,
   command and have a tag matching the command.
      </t>
      <t>
   Some status responses, and all server data, are untagged.  An
   untagged response is indicated by the token "*" instead of a tag.
   Untagged status responses indicate server greeting, greeting or server status
   that does not indicate the completion of a command (for example, an
   impending system shutdown alert).  For historical reasons, untagged
   server data responses are also called "unsolicited data", although
   strictly speaking, only unilateral server data is truly
   "unsolicited".
      </t>
      <t>
   Certain server data MUST <bcp14>MUST</bcp14> be remembered by the client when it is
   received; this is noted in the description of that data.  Such data
   conveys critical information which that affects the interpretation of all
   subsequent commands and responses (e.g., updates reflecting the
   creation or destruction of messages).
      </t>
      <t>
   Other server data SHOULD <bcp14>SHOULD</bcp14> be remembered for later reference; if the
   client does not need to remember the data, or if remembering the data has
   no obvious purpose (e.g., a SEARCH response when no SEARCH command is
   in progress), the data can be ignored.
      </t>
      <t>
   An example of unilateral untagged server data occurs when the IMAP
   connection is in the selected state.  In the selected state, the
   server checks the mailbox for new messages as part of command
   execution.  Normally, this is part of the execution of every command;
   hence, a NOOP command suffices to check for new messages.  If new
   messages are found, the server sends an untagged EXISTS
   response reflecting the new size of the mailbox.  Server
   implementations that offer multiple simultaneous access to the same
   mailbox SHOULD <bcp14>SHOULD</bcp14> also send appropriate unilateral untagged FETCH and
   EXPUNGE responses if another agent changes the state of any message
   flags or expunges any messages.
      </t>
      <t>
   Command continuation request responses use the token "+" instead of a
   tag.  These responses are sent by the server to indicate acceptance
   of an incomplete client command and readiness for the remainder of
   the command.
      </t>
      <section title='Server anchor="server-status-responses" numbered="true" toc="default">
        <name>Server Responses - Generic Status Responses' anchor='server-status-responses'> Responses</name>
        <t>
   Status responses are OK, NO, BAD, PREAUTH PREAUTH, and BYE.  OK, NO, and BAD
   can be tagged or untagged.  PREAUTH and BYE are always untagged.
        </t>
        <t>
   Status responses MAY <bcp14>MAY</bcp14> include an OPTIONAL <bcp14>OPTIONAL</bcp14> "response code".  A response
   code consists of data inside square brackets in the form of an atom,
   possibly followed by a space and arguments.  The response code
   contains additional information or status codes for client software
   beyond the OK/NO/BAD condition, condition and are defined when there is a
   specific action that a client can take based upon the additional
   information.
        </t>
        <t>
   The currently defined response codes are:

      <list style='hanging'>
      <t hangText='ALERT'>
      <iref item='ALERT

        </t>
        <dl newline="true" spacing="normal">
          <dt>ALERT</dt>
          <dd><iref item="ALERT (response code)'/>

          <list>
          <t> code)" subitem="" primary="false"/>
          The human-readable text contains a special alert that are is
          presented to the user in a fashion that calls the user's
          attention to the message.
          Content of ALERT response codes received on a connection without
          TLS or SASL security layer security-layer confidentiality SHOULD <bcp14>SHOULD</bcp14> be ignored
          by clients. If displayed, such alerts MUST <bcp14>MUST</bcp14> be clearly marked
          as potentially suspicious. (Note that some existing clients
          are known to hyperlink returned text text, which make them very
          dangerous.)
          Alerts received after successful establishment of a TLS/SASL
          confidentiality layer MUST <bcp14>MUST</bcp14> be presented to the user.
          <!--Warn about dangers of ALERT before STARTTLS, as they can be injected by an attacker
          They might contain URLs and trick users into clicking them, as some clients will HTML-ize ALERT text.-->
          </t>
          </list>
          </t>

      <t hangText='ALREADYEXISTS'>
      <iref item='ALREADYEXISTS

          </dd>

          <dt>ALREADYEXISTS</dt>
          <dd><t><iref item="ALREADYEXISTS (response code)'/>

         <list>
         <t> code)" subitem="" primary="false"/>
         The operation attempts to create something that already exists,
         such as when the a CREATE or RENAME directories attempt command attempts to create
         a mailbox and there is already one of that name.
         </t>

         <t>
<sourcecode type="">
  C: o356 RENAME this that<vspace/> that
  S: o356 NO [ALREADYEXISTS] Mailbox "that" already exists
         </t>
         </list>
         </t>

      <t hangText='APPENDUID'>
      <iref item='APPENDUID
</sourcecode>
              </dd>

          <dt>APPENDUID</dt>
          <dd><t><iref item="APPENDUID (response code)'/>

          <list>
            <t> code)" subitem="" primary="false"/>
              Followed by the UIDVALIDITY of the destination mailbox and the UID
              assigned to the appended message in the destination mailbox,
              it indicates that the message has been appended to the destination
              mailbox with that UID.
            </t>
             <t>
              If the server also supports the <xref target='MULTIAPPEND'/> target="RFC3502" format="default"/> extension, and if
              multiple messages were appended in the APPEND command, then the
              second value is a UID set containing the UIDs assigned to the
              appended messages, in the order they were transmitted in the
              APPEND command.  This UID set may not contain extraneous UIDs or
              the symbol "*".
            </t>

            <t>
              <list>
                <t>
              <t indent="3">
                  Note: the UID set form of the APPENDUID response code MUST NOT <bcp14>MUST NOT</bcp14>
                  be used if only a single message was appended.  In particular,
                  a server MUST NOT <bcp14>MUST NOT</bcp14> send a range such as 123:123.  This is
                  because a client that does not support <xref target='MULTIAPPEND'/> target="RFC3502" format="default"/> expects
                  only a single UID and not a UID set.
                </t>
              </list>
            </t>
              <t>
              UIDs are assigned in strictly ascending order in the mailbox
              (refer to <xref target='uid-def'/>); target="uid-def" format="default"/>); note that a range of 12:10 is exactly
              equivalent to 10:12 and refers to the sequence 10,11,12.
            </t> 10,11,12.</t>
            <t>
              This response code is returned in a tagged OK response to the
              APPEND command.
            </t>
          </list>
        </t>

      <t hangText='AUTHENTICATIONFAILED'>
      <iref item='AUTHENTICATIONFAILED command.</t>
            </dd>

          <dt>AUTHENTICATIONFAILED</dt>
          <dd><t><iref item="AUTHENTICATIONFAILED (response code)'/>

         <list>
           <t> code)" subitem="" primary="false"/>
             Authentication failed for some reason on which the server is
             unwilling to elaborate.  Typically, this includes "unknown
             user" and "bad password".
           </t>
             <t>
             This is the same as not sending any response code, except that
             when a client sees AUTHENTICATIONFAILED, it knows that the
             problem wasn't, e.g., UNAVAILABLE, so there's no point in
             trying the same login/password again later.
           </t>

           <t>
 <sourcecode type="">
  C: b LOGIN "fred" "foo"<vspace/> "foo"
  S: b NO [AUTHENTICATIONFAILED] Authentication failed
           </t>
         </list>
         </t>

      <t hangText='AUTHORIZATIONFAILED'>
      <iref item='AUTHORIZATIONFAILED
 </sourcecode>
          </dd>

          <dt>AUTHORIZATIONFAILED</dt>
          <dd> <t><iref item="AUTHORIZATIONFAILED (response code)'/>

         <list>
         <t> code)" subitem="" primary="false"/>
         Authentication succeeded in using the authentication identity,
         but the server cannot or will not allow the authentication
         identity to act as the requested authorization identity.  This
         is only applicable when the authentication and authorization
         identities are different.
         </t>
         <t>
<sourcecode type="">
  C: c1 AUTHENTICATE PLAIN<vspace/>
         [...]<vspace/> PLAIN
  [...]
  S: c1 NO [AUTHORIZATIONFAILED] No such authorization-ID<vspace/>
         </t>
         <t> authorization-ID
</sourcecode>

<sourcecode type="">
  C: c2 AUTHENTICATE PLAIN<vspace/>
         [...]<vspace/> PLAIN
  [...]
  S: c2 NO [AUTHORIZATIONFAILED] Authenticator is not an admin
         </t>
         </list>
         </t>

      <t hangText='BADCHARSET'>
      <iref item='BADCHARSET
</sourcecode>
</dd>
          <dt>BADCHARSET</dt>
          <dd><iref item="BADCHARSET (response code)'/>

         <list>
         <t> code)" subitem="" primary="false"/>
         Optionally followed by a parenthesized list of charsets.  A
         SEARCH failed because the given charset is not supported by
         this implementation.  If the optional list of charsets is
         given, this lists the charsets that are supported by this
         implementation.</t>
         </list>
         </t>

      <t hangText='CANNOT'>
      <iref item='CANNOT
         implementation.</dd>

          <dt>CANNOT</dt>
          <dd><t><iref item="CANNOT (response code)'/>

         <list>
         <t>
         The code)" subitem="" primary="false"/>
         This operation violates some invariant of the server and can
         never succeed.
         </t>

         <t>

<sourcecode type="">
  C: l create "///////"<vspace/> "///////"
  S: l NO [CANNOT] Adjacent slashes are not supported
         </t>
         </list>
         </t>

      <t hangText='CAPABILITY'>
      <iref item='CAPABILITY
</sourcecode>
              </dd>
          <dt>CAPABILITY</dt>
          <dd><iref item="CAPABILITY (response code)'/>

         <list>
         <t> code)" subitem="" primary="false"/>
         Followed by a list of capabilities.  This can appear in the
         initial OK or PREAUTH response to transmit an initial
         capabilities list.  It can also appear in tagged responses to LOGIN
         or AUTHENTICATE commands.  This makes it unnecessary for a client to
         send a separate CAPABILITY command if it recognizes this
         response code and there was no change to the TLS and/or authentication
         state since it was received.</t>
         </list>
         </t>

      <t hangText='CLIENTBUG'>
      <iref item='CLIENTBUG received.
          </dd>
          <dt>CLIENTBUG</dt>
          <dd><t><iref item="CLIENTBUG (response code)'/>

         <list>
         <t> code)" subitem="" primary="false"/>
         The server has detected a client bug.  This can accompany all any
         of OK, NO, and BAD, depending on what the client bug is.
         </t>

         <t>

 <sourcecode type="">
  C: k1 select "/archive/projects/experiment-iv"<vspace/>
         [...]<vspace/> "/archive/projects/experiment-iv"
  [...]
  S: k1 OK [READ-ONLY] Done<vspace/> Done
  C: k2 status "/archive/projects/experiment-iv" (messages)<vspace/>
         [...]<vspace/> (messages)
  [...]
  S: k2 OK [CLIENTBUG] Done
         </t>
         </list>
         </t>

      <t hangText='CLOSED' anchor='closed'>
      <iref item='CLOSED
 </sourcecode>
              </dd>

          <dt>CLOSED</dt>
          <dd anchor="closed">
           <t><iref item="CLOSED (response code)'/>

         <list>
         <t> code)" subitem="" primary="false"/>
           The CLOSED response code has no parameters.
	   A server return returns the CLOSED
           response code when the currently selected mailbox is closed
           implicitly using the SELECT/EXAMINE SELECT or EXAMINE command on another mailbox.  The
           CLOSED response code serves as a boundary between responses for the
           previously opened mailbox (which was closed) and the newly selected
           mailbox; all responses before the CLOSED response code relate to the
           mailbox that was closed, and all subsequent responses relate to the
           newly opened mailbox.
           </t>
           <t>
           There is no need to return the CLOSED response code on completion of
           the CLOSE or the UNSELECT command (or similar), whose
           purpose is to close the currently selected mailbox without opening a
           new one.
         </t>
         </list>
         </t>

      <t hangText='CONTACTADMIN'>
      <iref item='CONTACTADMIN one.</t>
         </dd>

          <dt>CONTACTADMIN</dt>
          <dd><t><iref item="CONTACTADMIN (response code)'/>

         <list>
         <t> code)" subitem="" primary="false"/>
         The user should contact the system administrator or support
         desk.
         </t>

         <t>
<sourcecode type="">
  C: e login "fred" "foo"<vspace/> "foo"
  S: e NO [CONTACTADMIN]
         </t>
         </list>
         </t>

      <t hangText='COPYUID'>
      <iref item='COPYUID
</sourcecode>
          </dd>

          <dt>COPYUID</dt>
          <dd><t><iref item="COPYUID (response code)'/>

          <list>
            <t> code)" subitem="" primary="false"/>
              Followed by the UIDVALIDITY of the destination mailbox, a UID set
              containing the UIDs of the message(s) in the source mailbox that
              were copied to the destination mailbox, followed by another UID set
              containing the UIDs
              assigned to the copied message(s) in the destination mailbox,
              indicates that the message(s) have has been copied to the destination
              mailbox with the stated UID(s).
            </t>
             <t>
              The source UID set is in the order the message(s) were was copied; the
              destination UID set corresponds to the source UID set and is in
              the same order.  Neither of the UID sets may contain extraneous
              UIDs or the symbol "*".
            </t>
              <t>

              UIDs are assigned in strictly ascending order in the mailbox
              (refer to <xref target='uid-def'/>); target="uid-def" format="default"/>); note that a range of 12:10 is exactly
              equivalent to 10:12 and refers to the sequence 10,11,12.
            </t> 10,11,12.</t>

             <t>
              This response code is returned in a tagged OK response to the COPY/UID COPY or UID COPY
              command or in the untagged OK response to the MOVE/UID MOVE command.
            </t>
          </list>
        </t>

      <t hangText='CORRUPTION'>
      <iref item='CORRUPTION or UID MOVE command.</t>
            </dd>

          <dt>CORRUPTION</dt>
          <dd> <t><iref item="CORRUPTION (response code)'/>

         <list>
         <t> code)" subitem="" primary="false"/>
         The server discovered that some relevant data (e.g., the
         mailbox) are corrupt.  This response code does not include any
         information about what's corrupt, but the server can write that
         to its logfiles.
         </t>

         <t>
<sourcecode type="">
  C: i select "/archive/projects/experiment-iv"<vspace/> "/archive/projects/experiment-iv"
  S: i NO [CORRUPTION] Cannot open mailbox
         </t>
         </list>
         </t>

      <t hangText='EXPIRED'>
      <iref item='EXPIRED
</sourcecode>
              </dd>

          <dt>EXPIRED</dt>
          <dd><t><iref item="EXPIRED (response code)'/>

         <list>
         <t> code)" subitem="" primary="false"/>
         Either authentication succeeded or the server no longer had the
         necessary data; either way, access is no longer permitted using
         that passphrase.  The client or user should get a new
         passphrase.
         </t>

         <t>
<sourcecode type="">
  C: d login "fred" "foo"<vspace/> "foo"
  S: d NO [EXPIRED] That password isn't valid any more
         </t>
         </list>
         </t>

      <t hangText='EXPUNGEISSUED'>
      <iref item='EXPUNGEISSUED
</sourcecode>
          </dd>

          <dt>EXPUNGEISSUED</dt>
          <dd><t><iref item="EXPUNGEISSUED (response code)'/>

         <list>
         <t> code)" subitem="" primary="false"/>
         Someone else has issued an EXPUNGE for the same mailbox.  The
         client may want to issue NOOP soon.  <xref target='IMAP-MULTIACCESS'/> target="RFC2180" format="default"/> discusses this
         subject in depth.
         </t>

         <t>

<sourcecode type="">
  C: h search from maria@example.com<vspace/> maria@example.com
  S: * ESEARCH (TAG "h") ALL 1:3,5,8,13,21,42<vspace/> 1:3,5,8,13,21,42
  S: h OK [EXPUNGEISSUED] Search completed
         </t>
         </list>
         </t>

      <t hangText='HASCHILDREN'>
      <iref item='HASCHILDREN
</sourcecode>
          </dd>

          <dt>HASCHILDREN</dt>
          <dd> <t><iref item="HASCHILDREN (response code)'/>

         <list>
         <t> code)" subitem="" primary="false"/>
         The mailbox delete operation failed because the mailbox
         has one or more children children, and the server doesn't allow
         deletion of mailboxes with children.
         </t>

         <t>
<sourcecode type="">
  C: m356 DELETE Notes<vspace/> Notes
  S: o356 NO [HASCHILDREN] Mailbox "Notes" has children
  that need to be deleted first
         </t>
         </list>
         </t>

      <t hangText='INUSE'>
      <iref item='INUSE
</sourcecode>
          </dd>

          <dt>INUSE</dt>
          <dd><t><iref item="INUSE (response code)'/>

         <list>
         <t> code)" subitem="" primary="false"/>
         An operation has not been carried out because it involves
         sawing off a branch someone else is sitting on.  Someone else
         may be holding an exclusive lock needed for this operation, or
         the operation may involve deleting a resource someone else is
         using, typically a mailbox.
         </t>
         <t>
         The operation may succeed if the client tries again later.
         </t>

         <t>
<sourcecode type="">
  C: g delete "/archive/projects/experiment-iv"<vspace/> "/archive/projects/experiment-iv"
  S: g NO [INUSE] Mailbox in use
         </t>
         </list>
         </t>

      <t hangText='LIMIT'>
      <iref item='LIMIT
</sourcecode>
          </dd>

          <dt>LIMIT</dt>
          <dd><t><iref item="LIMIT (response code)'/>

         <list>
         <t> code)" subitem="" primary="false"/>
         The operation ran up against an implementation limit of some
         kind, such as the number of flags on a single message or the
         number of flags used in a mailbox.
         </t>

         <t>
<sourcecode type="">
  C: m STORE 42 FLAGS f1 f2 f3 f4 f5 ... f250<vspace/> f250
  S: m NO [LIMIT] At most 32 flags in one mailbox supported
         </t>
         </list>
         </t>

      <t hangText='NONEXISTENT'>
      <iref item='NONEXISTENT
</sourcecode>
          </dd>

          <dt>NONEXISTENT</dt>
          <dd><t><iref item="NONEXISTENT (response code)'/>

         <list>
         <t> code)" subitem="" primary="false"/>
         The operation attempts to delete something that does not exist.
         Similar to ALREADYEXISTS.
         </t>

         <t>
<sourcecode type="">
  C: p RENAME this that<vspace/> that
  S: p NO [NONEXISTENT] No such mailbox
         </t>
         </list>
         </t>

      <t hangText='NOPERM'>
      <iref item='NOPERM
</sourcecode>
          </dd>

          <dt>NOPERM</dt>
          <dd><t><iref item="NOPERM (response code)'/>

         <list>
         <t> code)" subitem="" primary="false"/>
         The access control system (e.g., Access Control List (ACL), ACL; see
         <xref target='RFC4314'/>) target="RFC4314" format="default"/>) does not permit this user to carry out an operation,
         such as selecting or creating a mailbox.
         </t>

         <t>
<sourcecode type="">
  C: f select "/archive/projects/experiment-iv"<vspace/> "/archive/projects/experiment-iv"
  S: f NO [NOPERM] Access denied
         </t>
         </list>
         </t>

      <t hangText='OVERQUOTA'>
      <iref item='OVERQUOTA
</sourcecode>
          </dd>

          <dt>OVERQUOTA</dt>
          <dd><t><iref item="OVERQUOTA (response code)'/>

         <list>
         <t> code)" subitem="" primary="false"/>
         The user would be over quota after the operation.  (The user
         may or may not be over quota already.)
         </t>
	 <t>
         Note that if the server sends OVERQUOTA but doesn't support the
         IMAP QUOTA extension defined by <xref target='RFC2087'/>, target="RFC2087" format="default"/>, then there is a quota, but the client cannot find out what the quota is.
       </t>

         <t>

<sourcecode type="">
  C: n1 uid copy 1:* oldmail<vspace/> oldmail
  S: n1 NO [OVERQUOTA] Sorry<vspace/>
         </t>

         <t> Sorry
</sourcecode>

<sourcecode type="">
  C: n2 uid copy 1:* oldmail<vspace/> oldmail
  S: n2 OK [OVERQUOTA] You are now over your soft quota
         </t>
         </list>
         </t>

      <t hangText='PARSE'>
      <iref item='PARSE
</sourcecode>
              </dd>

          <dt>PARSE</dt>
          <dd><iref item="PARSE (response code)'/>

         <list>
         <t> code)" subitem="" primary="false"/>
         The human-readable text represents an error in parsing the
         <xref target='RFC-5322'/> target="RFC5322" format="default"/> header or <xref target='MIME-IMB'/> target="RFC2045" format="default"/> headers of a message in the
         mailbox.</t>
         </list>
         </t>

      <t hangText='PERMANENTFLAGS'>
      <iref item='PERMANENTFLAGS
          mailbox.</dd>

          <dt>PERMANENTFLAGS</dt>
          <dd><t><iref item="PERMANENTFLAGS (response code)'/>

         <list>
         <t> code)" subitem="" primary="false"/>
         Followed by a parenthesized list of flags, flags and indicates which of
         the known flags the client can change permanently.  Any flags
         that are in the FLAGS untagged response, but not in the
         PERMANENTFLAGS list, can not cannot be set permanently.
         The PERMANENTFLAGS list can also include the special flag \*,
         which indicates that it is possible to create new keywords by
         attempting to store those keywords in the mailbox.
         If the client attempts to STORE a flag that is not in the PERMANENTFLAGS
         list, the server will either ignore the change or store the
         state change for the remainder of the current session only.
         </t>
          <t>
         There is no need for a server that included the special flag \*
         to return a new PERMANENTFLAGS response code when a new keyword
         was successfully set on a message upon client request.
         However
         However, if the server has a limit on the number of different keywords
         that can be stored in a mailbox and that limit is reached,
         the server MUST <bcp14>MUST</bcp14> send a new PERMANENTFLAGS response code
         without the special flag \*.
         </t>
         </list>
         </t>

      <t hangText='PRIVACYREQUIRED'>
      <iref item='PRIVACYREQUIRED
         </t></dd>

          <dt>PRIVACYREQUIRED</dt>
          <dd><t><iref item="PRIVACYREQUIRED (response code)'/>

         <list>
         <t> code)" subitem="" primary="false"/>
         The operation is not permitted due to a lack of data confidentiality.
         If Transport Layer Security (TLS) TLS is not in use, the client could
         try STARTTLS (see <xref target='STARTTLS'/>) target="STARTTLS" format="default"/>) or alternatively
         reconnect on an Implicit TLS port, and then repeat
         the operation.
         </t>

         <t>
 <sourcecode type="">
  C: d login "fred" "foo"<vspace/> "foo"
  S: d NO [PRIVACYREQUIRED] Connection offers no privacy<vspace/>
         </t>

         <t> privacy
 </sourcecode>

<sourcecode type="">
  C: d select inbox<vspace/> inbox
  S: d NO [PRIVACYREQUIRED] Connection offers no privacy
         </t>
         </list>
         </t>

      <t hangText='READ-ONLY'>
      <iref item='READ-ONLY
 </sourcecode>
              </dd>

          <dt>READ-ONLY</dt>
          <dd><iref item="READ-ONLY (response code)'/>

         <list>
         <t> code)" subitem="" primary="false"/>
         The mailbox is selected as read-only, or its access while selected
         has changed from read-write to read-only.</t>
         </list>
         </t>

      <t hangText='READ-WRITE'>
      <iref item='READ-WRITE read-only.</dd>

          <dt>READ-WRITE</dt>
          <dd><iref item="READ-WRITE (response code)'/>

         <list>
         <t> code)" subitem="" primary="false"/>
         The mailbox is selected as read-write, or its access while
         selected has changed from read-only to read-write.</t>
         </list>
         </t>

      <t hangText='SERVERBUG'>
      <iref item='SERVERBUG read-write.</dd>

          <dt>SERVERBUG</dt>
          <dd><t><iref item="SERVERBUG (response code)'/>

         <list>
         <t> code)" subitem="" primary="false"/>
         The server encountered a bug in itself or violated one of its
         own invariants.
         </t>

         <t>
<sourcecode type="">
  C: j select "/archive/projects/experiment-iv"<vspace/> "/archive/projects/experiment-iv"
  S: j NO [SERVERBUG] This should not happen
         </t>
         </list>
         </t>

      <t hangText='TRYCREATE'>
      <iref item='TRYCREATE
</sourcecode>
          </dd>

          <dt>TRYCREATE</dt>
          <dd><iref item="TRYCREATE (response code)'/>

         <list>
         <t> code)" subitem="" primary="false"/>
         An APPEND, COPY COPY, or MOVE attempt is failing because the target mailbox
         does not exist (as opposed to some other reason).  This is a
         hint to the client that the operation can succeed if the
          mailbox is first created by the CREATE command.</t>
         </list>
         </t>

      <t hangText='UIDNEXT'>
      <iref item='UIDNEXT command.</dd>

          <dt>UIDNEXT</dt>
          <dd><iref item="UIDNEXT (response code)'/>

         <list>
         <t> code)" subitem="" primary="false"/>
         Followed by a decimal number, number and indicates the next unique
         identifier value.  Refer to <xref target='uid-def'/> target="uid-def" format="default"/> for more
         information.</t>
         </list>
         </t>

      <t hangText='UIDNOTSTICKY'>
      <iref item='UIDNOTSTICKY
          information.</dd>

          <dt>UIDNOTSTICKY</dt>
          <dd><t><iref item="UIDNOTSTICKY (response code)'/>

         <list>
            <t> code)" subitem="" primary="false"/>
            The selected mailbox is supported by a mail store that does not
            support persistent UIDs; that is, UIDVALIDITY will be different
            each time the mailbox is selected.  Consequently, APPEND or COPY
            to this mailbox will not return an APPENDUID or COPYUID response
            code.</t>

              <t>This response code is returned in an untagged NO response to the
            SELECT command.</t>

            <t>
            <list>
              <t>

              <t indent="3">
                Note: servers SHOULD NOT <bcp14>SHOULD NOT</bcp14> have any UIDNOTSTICKY mail stores.
                This facility exists to support legacy mail stores in which it
                is technically infeasible to support persistent UIDs.  This
                should be avoided when designing new mail stores.
              </t>
            </list>
            </t>
         </list>
      </t>

      <t hangText='UIDVALIDITY'>
      <iref item='UIDVALIDITY
          </dd>

          <dt>UIDVALIDITY</dt>
          <dd><iref item="UIDVALIDITY (response code)'/>

         <list>
         <t> code)" subitem="" primary="false"/>
         Followed by a decimal number, number and indicates the unique identifier
          validity value.  Refer to <xref target='uid-def'/> target="uid-def" format="default"/> for more information.</t>
         </list>
         </t>

      <t hangText='UNAVAILABLE'>
      <iref item='UNAVAILABLE information.</dd>

          <dt>UNAVAILABLE</dt>
          <dd><t><iref item="UNAVAILABLE (response code)'/>

         <list>
         <t> code)" subitem="" primary="false"/>
         Temporary failure because a subsystem is down.  For example, an
         IMAP server that uses a Lightweight Directory Access Protocol
         (LDAP) or Radius server for authentication might use this
         response code when the LDAP/Radius server is down.
         </t>

         <t>
<sourcecode type="">
  C: a LOGIN "fred" "foo"<vspace/> "foo"
  S: a NO [UNAVAILABLE] User's backend down for maintenance
         </t>
         </list>
         </t>

      <t hangText='UNKNOWN-CTE'>
      <iref item='UNKNOWN-CTE
</sourcecode>
          </dd>

          <dt>UNKNOWN-CTE</dt>
          <dd><iref item="UNKNOWN-CTE (response code)'/>

         <list>
         <t> code)" subitem="" primary="false"/>
         The server does not know how to decode the section's Content-Transfer-Encoding.
         </t>

<!--
         <t>
         </t>
  -->

         </list>
         </t>

      </list>
   </t>
         </dd>
         </dl>

        <t>
      <!--Removed this:
      Additional response codes defined by particular client or server
      implementations SHOULD be prefixed with an "X" until they are
      added to a revision of this protocol.-->
      Client implementations MUST <bcp14>MUST</bcp14> ignore response codes that they do not recognize.
        </t>
        <section title='OK Response'>
	<iref item='OK (response)'/>

   <t>
   <list style='hanging' hangIndent='12'>
   <t hangText='Contents:'>OPTIONAL response code<vspace/>
               human-readable text</t>
   </list>
   </t> numbered="true" toc="default">
          <name>OK Response</name>
          <iref item="OK (response)" subitem="" primary="false"/>
          <dl newline="false" spacing="compact" indent="12">
            <dt>Contents:</dt>
            <dd>
	       <ul spacing="compact" empty="true" bare="true">
              <li><bcp14>OPTIONAL</bcp14> response code</li>
              <li>human-readable text</li>
	       </ul>
            </dd>
          </dl>
          <t>
      The OK response indicates an information message from the server.
      When tagged, it indicates successful completion of the associated
      command.  The human-readable text MAY <bcp14>MAY</bcp14> be presented to the user as
      an information message.  The untagged form indicates an
      information-only message; the nature of the information MAY <bcp14>MAY</bcp14> be
      indicated by a response code.
          </t>
          <t>
      The untagged form is also used as one of three possible greetings
      at connection startup.  It indicates that the connection is not
      yet authenticated and that a LOGIN or an AUTHENTICATE command is needed.
          </t>

<figure><artwork>
   <t>
Example:
	  </t>
<sourcecode type="">
  S: * OK IMAP4rev2 server ready
  C: A001 LOGIN fred blurdybloop
  S: * OK [ALERT] System shutdown in 10 minutes
  S: A001 OK LOGIN Completed
</artwork></figure>
</sourcecode>
        </section>
        <section title='NO Response'>
	<iref item='NO (response)'/>

   <t>
   <list style='hanging' hangIndent='12'>
   <t hangText='Contents:'>OPTIONAL numbered="true" toc="default">
          <name>NO Response</name>
          <iref item="NO (response)" subitem="" primary="false"/>
          <dl newline="false" spacing="compact" indent="12">
            <dt>Contents:</dt>
            <dd>
	      <ul spacing="compact" empty="true" bare="true">
              <li><bcp14>OPTIONAL</bcp14> response code<vspace/> code</li>
              <li>
              human-readable text</t>
   </list>
   </t> text</li>
	      </ul>
            </dd>
          </dl>
          <t>
      The NO response indicates an operational error message from the
      server.  When tagged, it indicates unsuccessful completion of the
      associated command.  The untagged form indicates a warning; the
      command can still complete successfully.  The human-readable text
      describes the condition.
          </t>

<figure><artwork>
 <t>
Example:
	  </t>
<sourcecode type="">
  C: A222 COPY 1:2 owatagusiam
  S: * NO Disk is 98% full, please delete unnecessary data
  S: A222 OK COPY completed
  C: A223 COPY 3:200 blurdybloop
  S: * NO Disk is 98% full, please delete unnecessary data
  S: * NO Disk is 99% full, please delete unnecessary data
  S: A223 NO COPY failed: disk is full
</artwork></figure>
</sourcecode>
        </section>
        <section title='BAD Response'>
	<iref item='BAD (response)'/>

   <t>
   <list style='hanging' hangIndent='12'>
   <t hangText='Contents:'>OPTIONAL response code<vspace/>
               human-readable text</t>
   </list>
   </t> numbered="true" toc="default">
          <name>BAD Response</name>
          <iref item="BAD (response)" subitem="" primary="false"/>
          <dl newline="false" spacing="normal" indent="12">
            <dt>Contents:</dt>
            <dd>
	       <ul spacing="compact" empty="true" bare="true">
              <li><bcp14>OPTIONAL</bcp14> response code</li>
              <li>human-readable text</li>
	       </ul>
            </dd>
          </dl>
          <t>
      The BAD response indicates an error message from the server.  When
      tagged, it reports a protocol-level error in the client's command;
      the tag indicates the command that caused the error.  The untagged
      form indicates a protocol-level error for which the associated
      command can not be determined; it can also indicate an internal
      server failure.  The human-readable text describes the condition.
          </t>

<figure><artwork>
 <t>
Example:
	  </t>
<sourcecode type="">
  C: ...very long command line...
  S: * BAD Command line too long
  C: ...empty line...
  S: * BAD Empty command line
  C: A443 EXPUNGE
  S: * BAD Disk crash, attempting salvage to a new disk!
  S: * OK Salvage successful, no data lost
  S: A443 OK Expunge completed
</artwork></figure>
</sourcecode>
        </section>
        <section title='PREAUTH Response' anchor='preauth-resp'>
	<iref item='PREAUTH (response)'/>

   <t>
   <list style='hanging' hangIndent='12'>
   <t hangText='Contents:'>OPTIONAL response code<vspace/>
               human-readable text</t>
   </list>
   </t> anchor="preauth-resp" numbered="true" toc="default">
          <name>PREAUTH Response</name>
          <iref item="PREAUTH (response)" subitem="" primary="false"/>
          <dl newline="false" spacing="normal" indent="12">
            <dt>Contents:</dt>
            <dd>
	       <ul spacing="compact" empty="true" bare="true">
              <li><bcp14>OPTIONAL</bcp14> response code</li>
              <li>human-readable text</li>
	       </ul>
            </dd>
          </dl>
          <t>
      The PREAUTH response is always untagged, untagged and is one of three
      possible greetings at connection startup.  It indicates that the
      connection has already been authenticated by external means; thus thus,
      no LOGIN/AUTHENTICATE command is needed.
          </t>
          <t>
     <!--////Explain that injected (by an attacker) PREAUTH can force a naive client
     to send data in cleartext (because this bypasses STARTTLS).-->
     Because PREAUTH moves the connection directly to the authenticated state,
     it effectively prevents the client from using the STARTTLS command <xref target='STARTTLS'/>. (<xref target="STARTTLS" format="default"/>).
     For this reason reason, the PREAUTH response SHOULD <bcp14>SHOULD</bcp14> only be returned by servers
     on connections that are protected by TLS (such as on implicit an Implicit TLS port <xref target='RFC8314'/>) target="RFC8314" format="default"/>) or
     protected through other means such as IPSec.<!--Mention loopback or the like?--> IPsec.
     Clients that require mandatory TLS MUST <bcp14>MUST</bcp14> close the connection after receiving the PREAUTH response on a non protected non-protected port.
          </t>

        <figure><artwork>
 <t>
Example:
	  </t>
<sourcecode type="">
  S: * PREAUTH IMAP4rev2 server logged in as Smith
</artwork></figure>
</sourcecode>
        </section>
        <section title='BYE Response'>
	<iref item='BYE (response)'/>

   <t>
   <list style='hanging' hangIndent='12'>
   <t hangText='Contents:'>OPTIONAL response code<vspace/>
               human-readable text</t>
   </list>
   </t> numbered="true" toc="default">
          <name>BYE Response</name>
          <iref item="BYE (response)" subitem="" primary="false"/>
          <dl newline="false" spacing="normal" indent="12">
            <dt>Contents:</dt>
            <dd>
	       <ul spacing="compact" empty="true" bare="true">
              <li><bcp14>OPTIONAL</bcp14> response code</li>
              <li>human-readable text</li>
	       </ul>
            </dd>
          </dl>
          <t>
      The BYE response is always untagged, untagged and indicates that the server
      is about to close the connection.  The human-readable text MAY <bcp14>MAY</bcp14> be
      displayed to the user in a status report by the client.  The BYE
      response is sent under one of four conditions:

         <list style='numbers'>
            <t>

          </t>
          <ol spacing="normal" type="1"><li>
            as part of a normal logout sequence.  The server will close
            the connection after sending the tagged OK response to the
            LOGOUT command.
            </t>

            <t>
            </li>
            <li>
            as a panic shutdown announcement.  The server closes the
            connection immediately.
            </t>

            <t>
            </li>
            <li>
            as an announcement of an inactivity autologout.  The server
            closes the connection immediately.
            </t>

            <t>
            </li>
            <li>
            as one of three possible greetings at connection startup,
            indicating that the server is not willing to accept a
            connection from this client.  The server closes the
            connection immediately.
            </t>
         </list>
   </t>
            </li>
          </ol>
          <t>
      The difference between a BYE that occurs as part of a normal
      LOGOUT sequence (the first case) and a BYE that occurs because of
      a failure (the other three cases) is that the connection closes
      immediately in the failure case.  In all cases cases, the client SHOULD <bcp14>SHOULD</bcp14>
      continue to read response data from the server until the
      connection is closed; this will ensure that any pending untagged
      or completion responses are read and processed.
          </t>

<figure><artwork>
 <t>
Example:
	  </t>
<sourcecode type="">
  S: * BYE Autologout; idle for too long
</artwork></figure>
</sourcecode>
        </section>
      </section>
      <section title='Server anchor="server-status-capabilities" numbered="true" toc="default">
        <name>Server Responses - Server Status' anchor='server-status-capabilities'> Status</name>
        <t>
   These responses are always untagged.  This is how server
   status data are transmitted from the server to the client.
        </t>
        <section title='ENABLED Response' anchor='enabled'>

         <t>
         <list style='hanging' hangIndent='12'>
         <t hangText='Contents:'>capability listing</t>
         </list>
         </t> anchor="enabled" numbered="true" toc="default">
          <name>ENABLED Response</name>
          <dl newline="false" spacing="normal" indent="12">
            <dt>Contents:</dt>
            <dd>capability listing</dd>
          </dl>
          <t>
         The ENABLED response occurs as a result of an ENABLE command.  The
         capability listing contains a space-separated listing of capability
         names that the server supports and that were successfully enabled.
         The ENABLED response may contain no capabilities, which means that no
         extensions listed by the client were successfully enabled.
          </t>

<figure><artwork>
 <t>
Example:
	  </t>
<sourcecode type="">
  S: * ENABLED CONDSTORE QRESYNC
</artwork></figure>
</sourcecode>
        </section>
        <section title='CAPABILITY Response' anchor='capability-resp'>
      <iref item='CAPABILITY (response)'/>

   <t>
   <list style='hanging' hangIndent='12'>
   <t hangText='Contents:'>capability listing</t>
   </list>
   </t> anchor="capability-resp" numbered="true" toc="default">
          <name>CAPABILITY Response</name>
          <iref item="CAPABILITY (response)" subitem="" primary="false"/>
          <dl newline="false" spacing="normal" indent="12">
            <dt>Contents:</dt>
            <dd>capability listing</dd>
          </dl>
          <t>
      The CAPABILITY response occurs as a result of a CAPABILITY
      command.  The capability listing contains a space-separated
      listing of capability names that the server supports.  The
      capability listing MUST <bcp14>MUST</bcp14> include the atom "IMAP4rev2",
      but note that it doesn't have to be the first capability listed.
      The order of capability names has no significance.
          </t>
          <t>
      In addition, client
      Client and server implementations MUST <bcp14>MUST</bcp14> implement the capabilities
      "AUTH=PLAIN" (described in <xref target="RFC4616" format="default"/>),
      and <bcp14>MUST</bcp14> implement "STARTTLS" and "LOGINDISABLED" (only on the cleartext port), and "AUTH=PLAIN" (described in <xref target='PLAIN'/>)
      capabilities. port.
      See the Security Considerations (<xref target='sec-cons'/>) target="sec-cons" format="default"/>) for
      important information related to these capabilities.
          </t>
          <t>
      A capability name which that begins with "AUTH=" indicates that the
      server supports that particular authentication mechanism <xref target='SASL'/>. target="RFC4422" format="default"/>.
          </t>
          <t>
      The LOGINDISABLED capability indicates that the LOGIN command is
      disabled, and that the server will respond with a tagged NO
      response to any attempt to use the LOGIN command even if the user
      name and password are valid. valid (their validity will not be checked).
      An IMAP client MUST NOT <bcp14>MUST NOT</bcp14> issue the
      LOGIN command if the server advertises the LOGINDISABLED
      capability.
          </t>
          <t>
      Other capability names indicate that the server supports an
      extension, revision, or amendment to the IMAP4rev2 protocol.
      If IMAP4rev1 capability is not advertised, server responses
      MUST
      <bcp14>MUST</bcp14> conform to this document until the client
      issues a command that uses the associated an additional capability.
      If both IMAP4rev1 and IMAP4rev2 capabilities are advertised,
      server responses MUST <bcp14>MUST</bcp14> conform to RFC 3501 <xref target="RFC3501" format="default"/> until the client
      issues a command that uses the associated an additional capability.
      (For example, the client can issue ENABLE IMAP4rev2 to
      enable IMAP4rev2 specific behaviour). IMAP4rev2-specific behavior.)
          </t>
          <t>
      Capability names SHOULD <bcp14>SHOULD</bcp14> be registered with IANA using the RFC Required policy. policy <xref target="RFC8126" format="default"/>.
      A server SHOULD NOT <bcp14>SHOULD NOT</bcp14> offer unregistered capability names.
      <!--"In particular, implementation defined capabilities SHOULD be registered
          in Independent Stream or IETF Informational/Experimental RFC."-->
          </t>
          <t>
      Client implementations SHOULD NOT <bcp14>SHOULD NOT</bcp14> require any capability name
      other than "IMAP4rev2", and possibly "STARTTLS" and "LOGINDISABLED"
      (on a cleartext port).
      Client implementations MUST <bcp14>MUST</bcp14> ignore any unknown capability
      names.
          </t>
          <t>
      A server MAY <bcp14>MAY</bcp14> send capabilities automatically, by using the
      CAPABILITY response code in the initial PREAUTH or OK responses, responses
      and by sending an updated CAPABILITY response code in the tagged
      OK response as part of a successful authentication.  It is
      unnecessary for a client to send a separate CAPABILITY command if
      it recognizes these automatic capabilities and there was no change to
      the TLS and/or authentication state since they were received.
          </t>
          <t>
      The list of capabilities returned by a server MAY <bcp14>MAY</bcp14> change during the connection.
      In particular, it is quite common for the server to change the list
      of capabilities after successful TLS negotiation (STARTTLS command)
      and/or after successful authentication (AUTHENTICATE or LOGIN commands).
          </t>

<figure><artwork>
  <t>
Example:
	  </t>
<sourcecode type="">
  S: * CAPABILITY STARTTLS AUTH=GSSAPI IMAP4rev2 LOGINDISABLED
   XPIG-LATIN
</artwork></figure>
</sourcecode>
          <t>Note that in the above example example, XPIG-LATIN is a fictitious capability name.</t>
        </section>
      </section>
      <section title='Server numbered="true" toc="default">
        <name>Server Responses - Mailbox Status'> Status</name>
        <t>
     These responses are always untagged.  This is how mailbox
     status data are transmitted from the server to the client.  Many of
     these responses typically result from a command with the same name.
        </t>
        <section title='LIST Response' anchor='list-resp'>
      <iref item='LIST (response)'/>

   <t>
   <list style='hanging' hangIndent='12'>
   <t hangText='Contents:'>name attributes<vspace/>
               hierarchy delimiter<vspace/>
               name<vspace/>
               OPTIONAL anchor="list-resp" numbered="true" toc="default">
          <name>LIST Response</name>
          <iref item="LIST (response)" subitem="" primary="false"/>
          <dl newline="false" spacing="normal" indent="12">
            <dt>Contents:</dt>
            <dd>
	       <ul spacing="compact" empty="true" bare="true">
              <li>name attributes</li>
              <li>hierarchy delimiter</li>
              <li>name</li>
              <li><bcp14>OPTIONAL</bcp14> extension data</t>
   </list>
   </t> data</li>
	       </ul>
            </dd>
          </dl>
          <t>
      The LIST response occurs as a result of a LIST command.  It
      returns a single name that matches the LIST specification.  There
      can be multiple LIST responses for a single LIST command.
          </t>
          <t>
      The following base mailbox name attributes are defined:

      <list style='hanging'>
      <t hangText='\NonExistent'>
      <iref item='\NonExistent

          </t>
          <dl newline="true" spacing="normal">
            <dt>\NonExistent</dt>
            <dd>
              <t><iref item="\NonExistent (mailbox name attribute)'/> attribute)" subitem="" primary="false"/>
         The "\NonExistent" attribute indicates that a mailbox name does not
         refer to an existing mailbox.  Note that this attribute is not
         meaningful by itself, as mailbox names that match the canonical LIST
         pattern but don't exist must not be returned unless one of the two
         conditions listed below is also satisfied:

        <list style='numbers'>
        <t>The

              </t>
              <ol spacing="normal" type="1"><li>The mailbox name also satisfies the selection criteria (for
        example, it is subscribed and the "SUBSCRIBED" selection option
        has been specified).</t>

        <t>"RECURSIVEMATCH" specified).</li>
                <li>"RECURSIVEMATCH" has been specified, and the mailbox name has at
        least one descendant mailbox name that does not match the LIST
        pattern and does match the selection criteria.</t>
        </list> criteria.</li>
              </ol>
              <t>

         In practice, this means that the "\NonExistent" attribute is usually
         returned with one or more of "\Subscribed", "\Remote",
         "\HasChildren", or the CHILDINFO extended data item.<vspace blankLines="1"/> item.</t>
              <t>

         The "\NonExistent" attribute implies "\NoSelect".
         <!--This is implied for all basic attributes:
         The "\NonExistent"
         attribute MUST be supported and MUST be accurately computed.
         -->
              </t>

      <t hangText='\Noinferiors'>
            </dd>
            <dt>\Noinferiors</dt>
            <dd>
              <iref item='\Noinferiors item="\Noinferiors (mailbox name attribute)'/> attribute)" subitem="" primary="false"/>
         It is not possible for any child levels of hierarchy to exist
         under this name; no child levels exist now and none can be
         created in the future.</t>

      <t hangText='\Noselect'> future.</dd>
            <dt>\Noselect</dt>
            <dd>
              <iref item='\Noselect item="\Noselect (mailbox name attribute)'/> attribute)" subitem="" primary="false"/>
         It is not possible to use this name as a selectable mailbox.</t>

      <t hangText='\HasChildren'> mailbox.</dd>
            <dt>\HasChildren</dt>
            <dd>
              <iref item='\HasChildren item="\HasChildren (mailbox name attribute)'/> attribute)" subitem="" primary="false"/>
         The presence of this attribute indicates that the mailbox has child
         mailboxes.  A server SHOULD NOT <bcp14>SHOULD NOT</bcp14> set this attribute if there are
         child mailboxes and the user does not have permission to access
         any of them.  In this case, \HasNoChildren SHOULD <bcp14>SHOULD</bcp14> be used.  In
         many cases, however, a server may not be able to efficiently
         compute whether a user has access to any child mailbox. mailboxes.  Note
         that even though the \HasChildren attribute for a mailbox must
         be correct at the time of processing of the mailbox, a client
         must be prepared to deal with a situation when a mailbox is
         marked with the \HasChildren attribute, but no child mailbox
         appears in the response to the LIST command.  This might happen,
         for example, due to children child mailboxes being deleted or made
         inaccessible to the user (using access control) by another
         client before the server is able to list them.
        </t>

      <t hangText='\HasNoChildren'>
        </dd>
            <dt>\HasNoChildren</dt>
            <dd>
              <iref item='\HasNoChildren item="\HasNoChildren (mailbox name attribute)'/> attribute)" subitem="" primary="false"/>
         The presence of this attribute indicates that the mailbox has NO
         child mailboxes that are accessible to the currently
         authenticated user.
        </t>

      <t hangText='\Marked'>
        </dd>
            <dt>\Marked</dt>
            <dd>
              <iref item='\Marked item="\Marked (mailbox name attribute)'/> attribute)" subitem="" primary="false"/>
         The mailbox has been marked "interesting" by the server; the
         mailbox probably contains messages that have been added since
         the last time the mailbox was selected.</t>

      <t hangText='\Unmarked'> selected.</dd>
            <dt>\Unmarked</dt>
            <dd>
              <iref item='\Unmarked item="\Unmarked (mailbox name attribute)'/> attribute)" subitem="" primary="false"/>
         The mailbox does not contain any additional messages since the
         last time the mailbox was selected.</t>

      <t hangText='\Subscribed'> selected.</dd>
            <dt>\Subscribed</dt>
            <dd>
              <iref item='\Subscribed item="\Subscribed (mailbox name attribute)'/> attribute)" subitem="" primary="false"/>
         The mailbox name was subscribed to using the SUBSCRIBE command.</t>

      <t hangText='\Remote'> command.</dd>
            <dt>\Remote</dt>
            <dd>
              <iref item='\Remote item="\Remote (mailbox name attribute)'/> attribute)" subitem="" primary="false"/>
         The mailbox is a remote mailbox.</t>
      </list>

   </t> mailbox.</dd>
          </dl>
          <t>
     It is an error for the server to return both a \HasChildren and a
     \HasNoChildren attribute in the same LIST response. A client that
     encounters a LIST response with both \HasChildren and \HasNoChildren
     attributes present should act as if both are absent in the LIST response.

        <list>
        <t>

          </t>
         <t indent="3">
        Note: the \HasNoChildren attribute should not be confused with the
        \NoInferiors attribute, which indicates that no
        child mailboxes exist now and none can be created in the future.
        </t>
        </list>
   </t>

          <t>
      If it is not feasible for the server to determine whether or not
      the mailbox is "interesting", the server SHOULD NOT <bcp14>SHOULD NOT</bcp14> send either
      \Marked or \Unmarked.  The server MUST NOT <bcp14>MUST NOT</bcp14> send more than one of
      \Marked, \Unmarked, and \Noselect for a single mailbox, and MAY it <bcp14>MAY</bcp14>
      send none of these.
          </t>
          <t>
      In addition to the base mailbox name attributes defined above,
      an IMAP server MAY <bcp14>MAY</bcp14> also include any or all of
      the following attributes that denote "role" (or "special-use") of a mailbox.
      These attributes are included along with base
      attributes defined above.  A given mailbox may
      have none, one, or more than one of these attributes.  In some cases,
      a special use is advice to a client about what to put in that
      mailbox.  In other cases, it's advice to a client about what to
      expect to find there.

      <list style='hanging'>
      <t hangText='\All'>

          </t>
          <dl newline="true" spacing="normal">
            <dt>\All</dt>
            <dd>
              <iref item='\All item="\All (mailbox name attribute)'/> attribute)" subitem="" primary="false"/>
        This mailbox presents all messages in the user's message store.
        Implementations MAY <bcp14>MAY</bcp14> omit some messages, such as, perhaps, those
        in \Trash and \Junk.  When this special use is supported, it is
        almost certain to represent a virtual mailbox.
      </t>

      <t hangText='\Archive'>
      </dd>
            <dt>\Archive</dt>
            <dd>
              <iref item='\Archive item="\Archive (mailbox name attribute)'/> attribute)" subitem="" primary="false"/>
        This mailbox is used to archive messages.  The meaning of an
        "archival" mailbox is server-dependent; server dependent; typically, it will be
        used to get messages out of the inbox, or otherwise keep them
        out of the user's way, while still making them accessible.
      </t>

      <t hangText='\Drafts'>
      </dd>
            <dt>\Drafts</dt>
            <dd>
              <iref item='\Drafts item="\Drafts (mailbox name attribute)'/> attribute)" subitem="" primary="false"/>
        This mailbox is used to hold draft messages -- typically,
        messages that are being composed but have not yet been sent.  In
        some server implementations, this might be a virtual mailbox,
        containing messages from other mailboxes that are marked with
        the "\Draft" message flag.  Alternatively, this might just be
        advice that a client put drafts here.
      </t>

      <t hangText='\Flagged'>
      </dd>
            <dt>\Flagged</dt>
            <dd>
              <iref item='\Flagged item="\Flagged (mailbox name attribute)'/> attribute)" subitem="" primary="false"/>
        This mailbox presents all messages marked in some way as
        "important".  When this special use is supported, it is likely
        to represent a virtual mailbox collecting messages (from other
        mailboxes) that are marked with the "\Flagged" message flag.
      </t>

      <t hangText='\Junk'>
      </dd>
            <dt>\Junk</dt>
            <dd>
              <iref item='\Junk item="\Junk (mailbox name attribute)'/> attribute)" subitem="" primary="false"/>
        This mailbox is where messages deemed to be junk mail are held.
        Some server implementations might put messages here
        automatically.  Alternatively, this might just be advice to a
        client-side spam filter.
      </t>

      <t hangText='\Sent'>
      </dd>
            <dt>\Sent</dt>
            <dd>
              <iref item='\Sent item="\Sent (mailbox name attribute)'/> attribute)" subitem="" primary="false"/>
        This mailbox is used to hold copies of messages that have been
        sent.  Some server implementations might put messages here
        automatically.  Alternatively, this might just be advice that a
        client save sent messages here.
      </t>

      <t hangText='\Trash'>
      </dd>
            <dt>\Trash</dt>
            <dd>
              <iref item='\Trash item="\Trash (mailbox name attribute)'/> attribute)" subitem="" primary="false"/>
        This mailbox is used to hold messages that have been deleted or
        marked for deletion.  In some server implementations, this might
        be a virtual mailbox, containing messages from other mailboxes
        that are marked with the "\Deleted" message flag.
        Alternatively, this might just be advice that a client that
        chooses not to use the IMAP "\Deleted" model should use this as
        its trash location.  In server implementations that strictly
        expect the IMAP "\Deleted" model, this special use is likely not
        to be supported.
      </t>

      </list>
   </t>

<!--
   For the extended list command [RFC5258], this extension adds a new
   capability string, a new selection option, and a new return option,
   all called "SPECIAL-USE".  Supporting implementations MUST include
   the "SPECIAL-USE" capability string in response to an IMAP CAPABILITY
   command.  If the client specifies the "SPECIAL-USE" selection option,
   the LIST command MUST return only those mailboxes that have a
   special-use attribute set.  If the client specifies the "SPECIAL-USE"
   return option, the LIST command MUST return the new special-use
   attributes on those mailboxes that have them set.  The "SPECIAL-USE"
   return option is implied by the "SPECIAL-USE" selection option.  The
   extended LIST command MAY return SPECIAL-USE attributes even if the
   client does not specify the return option.
-->
      </dd>
          </dl>
   <t>
     All of special-use attributes are OPTIONAL, <bcp14>OPTIONAL</bcp14>, and any given server or
     message store may support any combination of the attributes, or none
     at all.  In most cases, there will likely be at most one mailbox with
     a given attribute for a given user, but in some server or message
     store implementations implementations, it might be possible for multiple mailboxes to
     have the same special-use attribute.
          </t>
          <t>
     Special-use attributes are likely to be user-specific. user specific.  User Adam
     might share his \Sent mailbox with user Barb, but that mailbox is
     unlikely to also serve as Barb's \Sent mailbox.
          </t>
          <t>
     Other mailbox name attributes can be found in the "IMAP Mailbox Name Attributes"
     registry <xref target="IMAP-MAILBOX-NAME-ATTRS-REG"/>. target="IMAP-MAILBOX-NAME-ATTRS-REG" format="default"/>.
          </t>
          <t>
      The hierarchy delimiter is a character used to delimit levels of
      hierarchy in a mailbox name.  A client can use it to create child
      mailboxes,
      mailboxes and to search higher or lower levels of naming
      hierarchy.  All children of a top-level hierarchy node MUST <bcp14>MUST</bcp14> use
      the same separator character.  A NIL hierarchy delimiter means
      that no hierarchy exists; the name is a "flat" name.
          </t>
          <t>
      The name represents an unambiguous left-to-right hierarchy, hierarchy and
      MUST
      <bcp14>MUST</bcp14> be valid for use as a reference in LIST command.
      Unless \Noselect or \NonExistent is indicated, the name MUST <bcp14>MUST</bcp14> also be valid as an
      argument for commands, such as SELECT, that accept mailbox names.
          </t>
          <t>
      The name might be followed by an OPTIONAL <bcp14>OPTIONAL</bcp14> series of extended fields,
      a parenthesized list of tagged data (also referred to as an "extended data item").
      The first element of an extended field is a string, which identifies the type of
      data.  <xref target="RFC5258"/> specified target="RFC5258" format="default"/> specifies requirements on string registration
      (which are called "tags" there; "tags"; such tags are not to be confused with IMAP command tags), tags);
      in particular particular, it said states that "Tags MUST <bcp14>MUST</bcp14> be registered with IANA". This document doesn't
      change that. See Section 9.5 of <xref target="RFC5258"/> target="RFC5258" sectionFormat="of" section="9.5"/> for the registration template.

      The server MAY <bcp14>MAY</bcp14> return data in the extended fields that was not directly solicited by the
      client in the corresponding LIST command.  For example, the client
      can enable extra extended fields by using another IMAP extension that
      make
      makes use of the extended LIST responses.  The client MUST <bcp14>MUST</bcp14> ignore all
      extended fields it doesn't recognize.
          </t>

<figure><artwork>
 <t>
Example:
	  </t>
<sourcecode type="">
  S: * LIST (\Noselect) "/" ~/Mail/foo
</artwork></figure>

<figure><artwork>
</sourcecode>
 <t>
Example:
	  </t>
<sourcecode type="">
  S: * LIST (\Marked) ":" Tables (tablecloth (("edge" "lacy")
      ("color" "red")) Sample "text")
  S: * LIST () ":" Tables:new (tablecloth ("edge" "lacy")
      Sample ("text" "more text"))
</artwork></figure>
</sourcecode>
        </section>
        <section title='NAMESPACE Response'>
      <iref item='NAMESPACE (response)'/>

   <t>
   <list style='hanging' hangIndent='12'>
   <t hangText='Contents:'> numbered="true" toc="default">
          <name>NAMESPACE Response</name>
          <iref item="NAMESPACE (response)" subitem="" primary="false"/>
          <dl newline="false" spacing="normal" indent="12">
            <dt>Contents:</dt>
            <dd>
     the prefix and hierarchy delimiter to the server's Personal
     Namespace(s), Other Users' Namespace(s), and Shared
     Namespace(s)
   </t>
   </list>
   </t>
   </dd>
          </dl>
          <t>
     The NAMESPACE response occurs as a result of a NAMESPACE command.
     It contains the prefix and hierarchy delimiter to the server's
     Personal Namespace(s), Other Users' Namespace(s), and Shared
     Namespace(s) that the server wishes to expose. The
     response will contain a NIL for any namespace class
     that is not available. The Namespace-Response-Extensions ABNF non terminal non-terminal
     is defined for extensibility and MAY <bcp14>MAY</bcp14> be included in the response.

     <!--No longer the best practice:
     Namespace-Response-Extensions which are not on the IETF
     standards track, MUST be prefixed with an "X-".
     -->
          </t>

<figure><artwork>
 <t>
Example:
	  </t>
<sourcecode type="">
  S: * NAMESPACE (("" "/")) (("~" "/")) NIL
</artwork></figure>
</sourcecode>
        </section>
        <section title='STATUS Response'>
      <iref item='STATUS (response)'/>

   <t>
   <list style='hanging' hangIndent='12'>
   <t hangText='Contents:'>name<vspace/>
               status numbered="true" toc="default">
          <name>STATUS Response</name>
          <iref item="STATUS (response)" subitem="" primary="false"/>
          <dl newline="false" spacing="normal" indent="12">
            <dt>Contents:</dt>
            <dd>
	       <ul spacing="compact" empty="true" bare="true">
              <li>name</li>
              <li>status parenthesized list</t>
   </list>
   </t> list</li>
	       </ul>
            </dd>
          </dl>
          <t>
      The STATUS response occurs as a result of an a STATUS command.  It
      returns the mailbox name that matches the STATUS specification and
      the requested mailbox status information.
          </t>

<figure><artwork>
 <t>
Example:
	  </t>
<sourcecode type="">
  S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
</artwork></figure>
</sourcecode>
        </section>
        <section title='ESEARCH Response'>
      <iref item='ESEARCH (response)'/>

   <t>
   <list style='hanging' hangIndent='12'>
   <t hangText='Contents:'>one numbered="true" toc="default">
          <name>ESEARCH Response</name>
          <iref item="ESEARCH (response)" subitem="" primary="false"/>
          <dl newline="false" spacing="normal" indent="12">
            <dt>Contents:</dt>
            <dd>one or more search-return-data pairs</t>
   </list>
   </t> pairs</dd>
          </dl>
          <t>
      The ESEARCH response occurs as a result of a SEARCH or UID SEARCH
      command.
          </t>
          <t>
     The ESEARCH response starts with an optional search correlator.  If
     it is missing, then the response was not caused by a particular IMAP
     command, whereas if it is present, it contains the tag of the command
     that caused the response to be returned.
          </t>
          <t>
     The search correlator is followed by an optional UID indicator.  If
     this indicator is present, all data in the ESEARCH response refers to
     UIDs, otherwise
     UIDs; otherwise, all returned data refers to message numbers.
          </t>
          <t>
     The rest of the ESEARCH response contains one or more search data
     pairs.  Each pair starts with a unique return item name, followed by a
     space and the corresponding data.  Search data pairs may be returned
     in any order.  Unless specified otherwise specified by an extension, any return
     item name SHOULD <bcp14>SHOULD</bcp14> appear only once in an ESEARCH response.
          </t>
          <t>
     This document specifies the following return item names:

     <list style='hanging'>
        <t hangText='MIN'>
        <iref item='MIN

          </t>
          <dl newline="true" spacing="normal">
            <dt>MIN</dt>
            <dd>
              <t><iref item="MIN (search return item name)'/>

          <list>
            <t> name)" subitem="" primary="false"/>
              Returns the lowest message number/UID that satisfies the SEARCH
              criteria.
            </t>
               <t>
              If the SEARCH results in no matches, the server MUST NOT <bcp14>MUST NOT</bcp14>
              include the MIN return item in the ESEARCH response; however,
              it still MUST <bcp14>MUST</bcp14> send the ESEARCH response.
            </t>
          </list>
        </t>

        <t hangText='MAX'>
        <iref item='MAX response.</t>
            </dd>

            <dt>MAX</dt>
            <dd>
              <t><iref item="MAX (search return item name)'/>
          <list>
            <t> name)" subitem="" primary="false"/>
              Returns the highest message number/UID that satisfies the SEARCH
              criteria.
            </t>
               <t>
              If the SEARCH results in no matches, the server MUST NOT <bcp14>MUST NOT</bcp14>
              include the MAX return item in the ESEARCH response; however,
              it still MUST <bcp14>MUST</bcp14> send the ESEARCH response.
            </t>
          </list>
        </t>

        <t hangText='ALL'>
        <iref item='ALL response.</t>
            </dd>

            <dt>ALL</dt>
            <dd>
              <t><iref item="ALL (search return item name)'/>
          <list>
            <t> name)" subitem="" primary="false"/>
            Returns all message numbers/UIDs that satisfy the SEARCH
            criteria using the sequence-set syntax. Note, Each set <bcp14>MUST</bcp14> be
            complete; in particular, a UID set is returned in an ESEARCH response only when
	    each number in the range corresponds to an existing (matching) message.
	    The client
            MUST NOT
            <bcp14>MUST NOT</bcp14> assume that messages/UIDs will be listed in any
            particular order.
		      </t>
               <t>
            If the SEARCH results in no matches, the server MUST NOT <bcp14>MUST NOT</bcp14>
            include the ALL return item in the ESEARCH response; however,
            it still MUST <bcp14>MUST</bcp14> send the ESEARCH response.
            </t>
          </list>
        </t>

        <t hangText='COUNT'> response.</t>
            </dd>

            <dt>COUNT</dt>
            <dd>
              <iref item='COUNT item="COUNT (search return item name)'/> name)" subitem="" primary="false"/>
            Returns the number of messages that satisfy the SEARCH criteria.
            This return item MUST <bcp14>MUST</bcp14> always be included in the ESEARCH
            response.
        </t>

     </list>
   </t>

<figure><artwork>
        </dd>
          </dl>
 <t>
Example:
	  </t>
<sourcecode type="">
  S: * ESEARCH UID COUNT 5 17 ALL 4:19,21,28 4:18,21,28
</sourcecode>
 <t>
Example:
	  </t>
<sourcecode type="">
  S: * ESEARCH (TAG "a567") UID COUNT 5 17 ALL 4:19,21,28 4:18,21,28
</sourcecode>
 <t>
Example:
	  </t>
<sourcecode type="">
  S: * ESEARCH COUNT 5 18 ALL 1:17,21
</artwork></figure>
</sourcecode>
        </section>
        <section title='FLAGS Response' anchor='flags-resp'>
      <iref item='FLAGS (response)'/>

   <t>
   <list style='hanging' hangIndent='12'>
   <t hangText='Contents:'>flag anchor="flags-resp" numbered="true" toc="default">
          <name>FLAGS Response</name>
          <iref item="FLAGS (response)" subitem="" primary="false"/>
          <dl newline="false" spacing="normal" indent="12">
            <dt>Contents:</dt>
            <dd>flag parenthesized list</t>
   </list>
   </t> list</dd>
          </dl>
          <t>
      The FLAGS response occurs as a result of a SELECT or EXAMINE
      command.  The flag parenthesized list identifies the flags (at a
      minimum, the system-defined flags) that are applicable for this
      mailbox.  Flags other than the system flags can also exist,
      depending on server implementation.
          </t>
          <t>
      The update from the FLAGS response MUST <bcp14>MUST</bcp14> be remembered by the client.
          </t>

<figure><artwork>
 <t>
Example:
	  </t>
<sourcecode type="">
  S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
</artwork></figure>
</sourcecode>
        </section>
      </section>
      <section title='Server numbered="true" toc="default">
        <name>Server Responses - Mailbox Size'> Size</name>
        <t>
   These responses are always untagged.  This is how changes in the size
   of the mailbox are transmitted from the server to the client.
   Immediately following the "*" token is a number that represents a
   message count.
        </t>
        <section title='EXISTS Response' anchor='exists'>

   <t>
   <list style='hanging' hangIndent='12'>
   <t hangText='Contents:'>none</t>
   </list>
   </t> anchor="exists" numbered="true" toc="default">
          <name>EXISTS Response</name>
          <dl newline="false" spacing="normal" indent="12">
            <dt>Contents:</dt>
            <dd>none</dd>
          </dl>
          <t>
      The EXISTS response reports the number of messages in the mailbox.
      This response occurs as a result of a SELECT or EXAMINE command, command
      and if the size of the mailbox changes (e.g., new messages).
          </t>
          <t>
      The update from the EXISTS response MUST <bcp14>MUST</bcp14> be remembered by the
      client.
          </t>

<figure><artwork>
 <t>
Example:
	  </t>
<sourcecode type="">
  S: * 23 EXISTS
</artwork></figure>
</sourcecode>
        </section>
      </section>
      <section title='Server numbered="true" toc="default">
        <name>Server Responses - Message Status'> Status</name>
        <t>
   These responses are always untagged.  This is how message data are
   transmitted from the server to the client, often as a result of a
   command with the same name.  Immediately following the "*" token is a
   number that represents a message sequence number.
        </t>
        <section title='EXPUNGE Response' anchor='expunge-response'>
      <iref item='EXPUNGE (response)'/>

   <t>
   <list style='hanging' hangIndent='12'>
   <t hangText='Contents:'>none</t>
   </list>
   </t> anchor="expunge-response" numbered="true" toc="default">
          <name>EXPUNGE Response</name>
          <iref item="EXPUNGE (response)" subitem="" primary="false"/>
          <dl newline="false" spacing="normal" indent="12">
            <dt>Contents:</dt>
            <dd>none</dd>
          </dl>
          <t>
      The EXPUNGE response reports that the specified message sequence
      number has been permanently removed from the mailbox.  The message
      sequence number for each successive message in the mailbox is
      immediately decremented by 1, and this decrement is reflected in
      message sequence numbers in subsequent responses (including other
      untagged EXPUNGE responses).
          </t>
          <t>
      The EXPUNGE response also decrements the number of messages in the
      mailbox; it is not necessary to send an EXISTS response with the
      new value.
          </t>
          <t>
      As a result of the immediate decrement rule, message sequence
      numbers that appear in a set of successive EXPUNGE responses
      depend upon whether the messages are removed starting from lower
      numbers to higher numbers, or from higher numbers to lower
      numbers.  For example, if the last 5 messages in a 9-message
      mailbox are expunged, a "lower to higher" server will send five
      untagged EXPUNGE responses for message sequence number 5, whereas
      a "higher to lower server" lower" server will send successive untagged EXPUNGE
      responses for message sequence numbers 9, 8, 7, 6, and 5.
          </t>
          <t>
      An EXPUNGE response MUST NOT <bcp14>MUST NOT</bcp14> be sent when no command is in
      progress, nor while responding to a FETCH, STORE, or SEARCH
      command.  This rule is necessary to prevent a loss of
      synchronization of message sequence numbers between client and
      server.  A command is not "in progress" until the complete command
      has been received; in particular, a command is not "in progress"
      during the negotiation of command continuation.

           <list><t>

          </t>
           <t indent="3">
           Note: UID FETCH, UID STORE, and UID SEARCH are different
           commands from FETCH, STORE, and SEARCH.  An EXPUNGE
           response MAY <bcp14>MAY</bcp14> be sent during a UID command.
           </t></list>
           </t>
          <t>
      The update from the EXPUNGE response MUST <bcp14>MUST</bcp14> be remembered by the
      client.
          </t>

<figure><artwork>
 <t>
Example:
	  </t>
<sourcecode type="">
  S: * 44 EXPUNGE
</artwork></figure>
</sourcecode>
        </section>
        <section title='FETCH Response' anchor='fetch-response'>
      <iref item='FETCH (response)'/>

   <t>
   <list style='hanging' hangIndent='12'>
   <t hangText='Contents:'>message data</t>
   </list>
   </t> anchor="fetch-response" numbered="true" toc="default">
          <name>FETCH Response</name>
          <iref item="FETCH (response)" subitem="" primary="false"/>
          <dl newline="false" spacing="normal" indent="12">
            <dt>Contents:</dt>
            <dd>message data</dd>
          </dl>
          <t>
      The FETCH response returns data about a message to the client.
      The data are pairs of data item names names, and their values are in
      parentheses.  This response occurs as the result of a FETCH or
      STORE command, as well as by a unilateral server decision (e.g.,
      flag updates).
          </t>
          <t>
      The current data items are:

      <list style='hanging'>

      <t hangText='BINARY[&lt;section-binary>]&lt;&lt;number>>'>
      <iref item='BINARY[&lt;section-binary>]&lt;&lt;number>>

          </t>
          <dl newline="true" spacing="normal">
            <dt>BINARY[&lt;section-binary&gt;]&lt;&lt;number&gt;&gt;</dt>
            <dd>
              <t><iref item="BINARY[&lt;section-binary&gt;]&lt;&lt;number&gt;&gt; (fetch result)'/>
      <list>
         <t> result)" subitem="" primary="false"/>
         An &lt;nstring> &lt;nstring&gt; or &lt;literal8> &lt;literal8&gt; expressing the content of the
         specified section after removing any Content-Transfer-Encoding-related encoding. encoding specified in the
	 corresponding Content-Transfer-Encoding header field.
	 If
         &lt;number> &lt;number&gt; is present present, it refers to the offset within the DECODED
         section data.
         </t> data.</t>

	 <t>
         If the domain of the decoded data is "8bit" and the data does
         not contain the NUL octet, the server SHOULD <bcp14>SHOULD</bcp14> return the data in
         a &lt;string> &lt;string&gt; instead of a &lt;literal8>; &lt;literal8&gt;; this allows the client to
         determine if the "8bit" data contains the NUL octet without
         having to explicitly scan the data stream for for NULs.
         </t>
         <t>
         <!--This text used to be in the "Implementation Considerations" section of BINARY extension:-->
         Messaging clients and servers have been notoriously lax in their
         adherence to the Internet CRLF convention for terminating lines of
         textual data (text/* media types) in Internet protocols.
         When sending data in a BINARY[...] FETCH data item,
         servers MUST <bcp14>MUST</bcp14> ensure that textual line-oriented
         sections are always transmitted using the IMAP4 IMAP CRLF line termination
         syntax, regardless of the underlying storage representation of the
         data on the server.
         </t> server.</t>

           <t>
         If the server does not know how to decode the section's Content-Transfer-Encoding,
         it MUST <bcp14>MUST</bcp14> fail the request and issue a "NO" response that contains
         the "UNKNOWN-CTE" response code.
         </t>

      </list>
      </t>

      <t hangText='BINARY.SIZE[&lt;section-binary>]'>
      <iref item='BINARY.SIZE[&lt;section-binary>] code.</t>
         </dd>

            <dt>BINARY.SIZE[&lt;section-binary&gt;]</dt>
            <dd>
              <t><iref item="BINARY.SIZE[&lt;section-binary&gt;] (fetch result)'/>
      <list>
         <t> result)" subitem="" primary="false"/>
         The size of the section after removing any Content-Transfer-Encoding-related
         encoding. encoding specified in the
	 corresponding Content-Transfer-Encoding header field.  The value returned MUST <bcp14>MUST</bcp14> match the size of the
         &lt;nstring>
         &lt;nstring&gt; or &lt;literal8> &lt;literal8&gt; that will be returned by the
         corresponding FETCH BINARY request.
         </t>
               <t>
         If the server does not know how to decode the section's Content-Transfer-Encoding,
         it MUST <bcp14>MUST</bcp14> fail the request and issue a "NO" response that contains
         the "UNKNOWN-CTE" response code.
         </t>

      </list>
      </t>

      <t hangText='BODY'> code.</t>
         </dd>

            <dt>BODY</dt>
            <dd>
              <iref item='BODY item="BODY (fetch result)'/> result)" subitem="" primary="false"/>
            A form of BODYSTRUCTURE without extension data.</t>

      <t hangText='BODY[&lt;section>]&lt;&lt;origin octet>>'>
      <iref item='BODY[&lt;section>]&lt;&lt;origin octet>> data.</dd>

            <dt>BODY[&lt;section&gt;]&lt;&lt;origin octet&gt;&gt;</dt>
            <dd>
              <t><iref item="BODY[&lt;section&gt;]&lt;&lt;origin octet&gt;&gt; (fetch result)'/>
      <list>
         <t> result)" subitem="" primary="false"/>

         A string expressing the body contents of the specified section.
         The string SHOULD <bcp14>SHOULD</bcp14> be interpreted by the client according to the
         content transfer encoding, body type, and subtype.
         </t>

                  <t>
         If the origin octet is specified, this string is a substring of
         the entire body contents, starting at that origin octet.  This
         means that BODY[]&lt;0> MAY BODY[]&lt;0&gt; <bcp14>MAY</bcp14> be truncated, but BODY[] is NEVER
         truncated.

            <list>
            <t>
                  </t>
             <t indent="3">
            Note: The origin octet facility MUST NOT <bcp14>MUST NOT</bcp14> be used by a server
            in a FETCH response unless the client specifically requested
            it by means of a FETCH of a BODY[&lt;section>]&lt;&lt;partial>> BODY[&lt;section&gt;]&lt;&lt;partial&gt;&gt; data
            item.
             </t>
            </list>
         </t>
	     <t>
         8-bit textual data is permitted if a <xref target='CHARSET'/> target="RFC2978" format="default"/> identifier is
         part of the body parameter parenthesized list for this section.
         Note that headers (part specifiers HEADER or MIME, or the
         header portion of a MESSAGE/RFC822 or MESSAGE/GLOBAL part), MAY part) <bcp14>MAY</bcp14> be in UTF-8.  Note also that the
         <xref target='RFC-5322'/> target="RFC5322" format="default"/> delimiting blank line between the header and the
         body is not affected by header line header-line subsetting; the blank line
         is always included as part of the header data, except in the case
         of a message which that has no body and no blank line.
         </t>

         <t>
         Non-textual data such as binary data MUST <bcp14>MUST</bcp14> be transfer encoded
         into a textual form, such as BASE64, base64, prior to being sent to the
         client.  To derive the original binary data, the client MUST <bcp14>MUST</bcp14>
         decode the transfer encoded string.
         </t>
      </list>
      </t>

      <t hangText='BODYSTRUCTURE'>
      <iref item='BODYSTRUCTURE transfer-encoded string.</t>
         </dd>

            <dt>BODYSTRUCTURE</dt>
            <dd>
              <t><iref item="BODYSTRUCTURE (fetch result)'/>
      <list>
         <t> result)" subitem="" primary="false"/>

         A parenthesized list that describes the <xref target='MIME-IMB'/> target="RFC2045" format="default"/> body
         structure of a message.  This is computed by the server by
         parsing the <xref target='MIME-IMB'/> target="RFC2045" format="default"/> header fields, defaulting various fields
         as necessary.
         </t>
               <t>
         For example, a simple text message of 48 lines and 2279 octets
         can have a body structure of: of:</t>

<artwork type="" align="left" alt=""><![CDATA[
   ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 2279 48)
         </t>
]]></artwork>

               <t>
         Multiple parts are indicated by parenthesis nesting.  Instead
         of a body type as the first element of the parenthesized list,
         there is a sequence of one or more nested body structures.  The
         second element of the parenthesized list is the multipart
         subtype (mixed, digest, parallel, alternative, etc.).
         </t>
                <t>
         For example, a two part two-part message consisting of a text and a
         BASE64-encoded
         base64-encoded text attachment can have a body structure of: of:</t>

<artwork type="" align="left" alt=""><![CDATA[
   (("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152
         23)("TEXT" 23)
    ("TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" "cc.diff")
         "&lt;960723163407.20117h@cac.washington.edu>"
    "<960723163407.20117h@cac.washington.edu>" "Compiler diff"
    "BASE64" 4554 73) "MIXED")
         </t>
]]></artwork>
                  <t>
         Extension data follows the multipart subtype.  Extension data
         is never returned with the BODY fetch, fetch but can be returned with
         a BODYSTRUCTURE fetch.  Extension data, if present, MUST <bcp14>MUST</bcp14> be in
         the defined order.  The extension data of a multipart body part
         are in the following order:

         <list style='hanging'>
         <t hangText='body
                  </t></dd>

                    <dt>body parameter parenthesized list'> list</dt>
                    <dd>
            A parenthesized list of attribute/value pairs [e.g., (e.g., ("foo"
            "bar" "baz" "rag") where "bar" is the value of "foo", and
            "rag" is the value of "baz"] "baz") as defined in <xref target='MIME-IMB'/>. target="RFC2045" format="default"/>.
            Servers SHOULD <bcp14>SHOULD</bcp14> decode parameter value parameter-value continuations and
            parameter value
            parameter-value character sets as described in <xref target='RFC2231'/>, target="RFC2231" format="default"/>,
            for example, if the message contains parameters "baz*0", "baz*1" "baz*1", and "baz*2",
            the server should RFC2231-decode them, concatenate decode them per <xref target="RFC2231" format="default"/>, concatenate, and return the resulting value
            as a parameter "baz".
            Similarly, if the message contains parameters "foo*0*" and "foo*1*", the server
            should RFC2231-decode them, decode them per <xref target="RFC2231" format="default"/>, convert to UTF-8, concatenate concatenate, and return
            the resulting value as a parameter "foo*".
            </t>

         <t hangText='body disposition'>
            </dd>
                    <dt>body disposition</dt>
                    <dd>
            A parenthesized list, consisting of a disposition type
            string, followed by a parenthesized list of disposition
            attribute/value pairs as defined in <xref target='DISPOSITION'/>. target="RFC2183" format="default"/>.
            Servers SHOULD <bcp14>SHOULD</bcp14> decode parameter value parameter-value continuations as described in <xref target='RFC2231'/>.
            </t>

         <t hangText='body language'> target="RFC2231" format="default"/>.
            </dd>
                    <dt>body language</dt>
                    <dd>
            A string or parenthesized list giving the body language
            value as defined in <xref target='LANGUAGE-TAGS'/>.</t>

         <t hangText='body location'> target="RFC3282" format="default"/>.</dd>
                    <dt>body location</dt>
                    <dd><t>
            A string giving the body content URI as defined in
            <xref target='LOCATION'/>.</t>
         </list>
         </t> target="RFC2557" format="default"/>.</t>

               <t>
         Any following extension data are not yet defined in this
         version of the protocol.  Such extension data can consist of
         zero or more NILs, strings, numbers, or potentially nested
         parenthesized lists of such data.  Client implementations that
         do a BODYSTRUCTURE fetch MUST <bcp14>MUST</bcp14> be prepared to accept such
         extension data.  Server implementations MUST NOT <bcp14>MUST NOT</bcp14> send such
         extension data until it has been defined by a revision of this
         protocol.
         </t>
         protocol.</t>

                  <t>
         The basic fields of a non-multipart body part are in the
         following order:

         <list style='hanging'>
         <t hangText='body type'>
                  </t></dd>

                    <dt>body type</dt>
                    <dd>
            A string giving the content media type media-type name as defined in
            <xref target='MIME-IMB'/>.</t>

         <t hangText='body subtype'> target="RFC2045" format="default"/>.</dd>
                    <dt>body subtype</dt>
                    <dd>
            A string giving the content subtype name as defined in
            <xref target='MIME-IMB'/>.</t>

         <t hangText='body target="RFC2045" format="default"/>.</dd>
                    <dt>body parameter parenthesized list'> list</dt>
                    <dd>
            A parenthesized list of attribute/value pairs [e.g., (e.g., ("foo"
            "bar" "baz" "rag") where "bar" is the value of "foo" "foo", and
            "rag" is the value of "baz"] "baz") as defined in <xref target='MIME-IMB'/>.</t>

         <t hangText='body id'> target="RFC2045" format="default"/>.</dd>
                    <dt>body id</dt>
                    <dd>
            A string giving the Content-ID header field value as defined in
            Section 7 of
            <xref target='MIME-IMB'/>.</t>

         <t hangText='body description'> target="RFC2045" sectionFormat="of" section="7"/>.</dd>
                    <dt>body description</dt>
                    <dd>
            A string giving the Content-Description header field value as defined in
            Section 8 of
            <xref target='MIME-IMB'/>.</t>

         <t hangText='body encoding'> target="RFC2045" sectionFormat="of" section="8"/>.</dd>
                    <dt>body encoding</dt>
                    <dd>
            A string giving the content transfer encoding as defined in
            Section 6 of
            <xref target='MIME-IMB'/>.</t>

         <t hangText='body size'> target="RFC2045" sectionFormat="of" section="6"/>.</dd>
                    <dt>body size</dt>
                    <dd><t>
            A number giving the size of the body in octets.  Note that
            this size is the size in its transfer encoding and not the
            resulting size after any decoding.</t>
         </list>
         </t>
           <t>
         A body type of type MESSAGE and subtype RFC822 contains,
         immediately after the basic fields, the envelope structure,
         body structure, and size in text lines of the encapsulated
         message.
         </t>
         message.</t>

	 <t>
         A body type of type TEXT contains, immediately after the basic
         fields, the size of the body in text lines.  Note that this
         size is the size in its content transfer encoding and not the
         resulting size after any decoding.
         </t> decoding.</t>
         <t>
         Extension data follows the basic fields and the type-specific
         fields listed above.  Extension data is never returned with the
         BODY fetch, fetch but can be returned with a BODYSTRUCTURE fetch.
         Extension data, if present, MUST <bcp14>MUST</bcp14> be in the defined order.
         </t>
                  <t>
         The extension data of a non-multipart body part are in the
         following order:

         <list style='hanging'>
         <t hangText='body MD5'>
                  </t></dd>

                    <dt>body MD5</dt>
                    <dd>
            A string giving the body MD5 value as defined in <xref target='MD5'/>.</t>

         <t hangText='body disposition'> target="RFC1864" format="default"/>.</dd>
                    <dt>body disposition</dt>
                    <dd>
            A parenthesized list with the same content and function as
            the body disposition for a multipart body part.</t>

         <t hangText='body language'> part.</dd>
                    <dt>body language</dt>
                    <dd>
            A string or parenthesized list giving the body language
            value as defined in <xref target='LANGUAGE-TAGS'/>.</t>

         <t hangText='body location'> target="RFC3282" format="default"/>.</dd>
                    <dt>body location</dt>
                    <dd><t>
            A string giving the body content URI as defined in
            <xref target='LOCATION'/>.</t>
         </list>
         </t> target="RFC2557" format="default"/>.</t>

	    <t>
         Any following extension data are not yet defined in this
         version of the protocol, protocol and would be as described above under
         multipart extension data.
         </t>
      </list>
      </t>

      <t hangText='ENVELOPE'>
      <iref item='ENVELOPE data.</t>
         </dd>

            <dt>ENVELOPE</dt>
            <dd>
              <t><iref item="ENVELOPE (fetch result)'/>
      <list>
         <t> result)" subitem="" primary="false"/>
         A parenthesized list that describes the envelope structure of a
         message.  This is computed by the server by parsing the
         <xref target='RFC-5322'/> target="RFC5322" format="default"/> header into the component parts, defaulting various
         fields as necessary.
         </t>
              <t>
         The fields of the envelope structure are in the following
         order: date, subject, from, sender, reply-to, to, cc, bcc,
         in-reply-to, and message-id.  The date, subject, in-reply-to,
         and message-id fields are strings.  The from, sender, reply-to,
         to, cc, and bcc fields are parenthesized lists of address
         structures.
         </t>
              <t>
         An address structure is a parenthesized list that describes an
         electronic mail address.  The fields of an address structure
         are in the following order: display name, <xref target='SMTP'/> target="RFC5321" format="default"/>
         at-domain-list (source route, route and obs-route ABNF production from <xref target='RFC-5322'/>), target="RFC5322" format="default"/>),
         mailbox name (local-part ABNF production from <xref target='RFC-5322'/>), target="RFC5322" format="default"/>), and host name. hostname.
         </t>
               <t>
                  <xref target='RFC-5322'/> target="RFC5322" format="default"/> group syntax is indicated by a special form of
         address structure in which the host name hostname field is NIL.  If the
         mailbox name field is also NIL, this is an end of group end-of-group marker
         (semi-colon
         (semicolon in RFC 822 syntax).  If the mailbox name field is
         non-NIL, this is a the start of a group marker, and the mailbox name
         field holds the group name phrase.
         </t>
                  <t>
         If the Date, Subject, In-Reply-To, and Message-ID header fields
         are absent in the <xref target='RFC-5322'/> target="RFC5322" format="default"/> header, the corresponding member
         of the envelope is NIL; if these header fields are present but
         empty
         empty, the corresponding member of the envelope is the empty
         string.

            <list>
            <t>
                  </t>
            <t indent="3">
            Note: some servers may return a NIL envelope member in the
            "present but empty" case.  Clients SHOULD <bcp14>SHOULD</bcp14> treat NIL and
            the empty string as identical.
            </t>

            <t>
            <t indent="3">
            Note: <xref target='RFC-5322'/> target="RFC5322" format="default"/> requires that all messages have a valid
            Date header field.  Therefore, for a well-formed message message, the date member in the envelope can
            not cannot
            be NIL or the empty string. However However, it can be NIL
            for a malformed or a draft message.
            </t>

            <t>
            <t indent="3">
            Note: <xref target='RFC-5322'/> target="RFC5322" format="default"/> requires that the In-Reply-To and
            Message-ID header fields, if present, have non-empty content.
            Therefore, for a well-formed message message, the in-reply-to and message-id members in the
            envelope can not cannot be the empty string. However However, they can still be
            the empty string for a malformed message.
            </t>
            </list>
         </t>
                 <t>
         If the From, To, Cc, and Bcc header fields are absent in the
         <xref target='RFC-5322'/> target="RFC5322" format="default"/> header, or are present but empty, the corresponding
         member of the envelope is NIL.
         </t>
                  <t>
         If the Sender or Reply-To header fields are absent in the <xref target='RFC-5322'/> target="RFC5322" format="default"/>
         header, or are present but empty, the server sets the
         corresponding member of the envelope to be the same value as
         the from member (the client is not expected to know how to do
         this).

            <list><t>   </t>

	          <t indent="3">
            Note: <xref target='RFC-5322'/> target="RFC5322" format="default"/> requires that all messages have a valid
            From header field.  Therefore, for a well-formed message message, the from, sender, and reply-to
            members in the envelope can not cannot be NIL. However However, they can be NIL
            for a malformed or a draft message.
            </t></list>
         </t>
      </list>
            </t>

      <t hangText='FLAGS'>
          </dd>

            <dt>FLAGS</dt>
            <dd>
              <iref item='FLAGS item="FLAGS (fetch result)'/> result)" subitem="" primary="false"/>
         A parenthesized list of flags that are set for this message.</t>

      <t hangText='INTERNALDATE'> message.</dd>
            <dt>INTERNALDATE</dt>
            <dd>
              <iref item='INTERNALDATE item="INTERNALDATE (fetch result)'/> result)" subitem="" primary="false"/>
         A string representing the internal date of the message.</t>

      <t hangText='RFC822.SIZE'> message.</dd>
            <dt>RFC822.SIZE</dt>
            <dd>
              <iref item='RFC822.SIZE item="RFC822.SIZE (fetch result)'/> result)" subitem="" primary="false"/>
         A number expressing the <xref target='RFC-5322'/> size of the message.</t>

      <t hangText='UID'> a message, as described in <xref target="RFC822.SIZE_message_attribute"/>.</dd>
            <dt>UID</dt>
            <dd>
              <iref item='UID item="UID (fetch result)'/> result)" subitem="" primary="false"/>
         A number expressing the unique identifier of the message.</t>
      </list>
   </t> message.</dd>
          </dl>
          <t>
     If the server chooses to send unsolicited FETCH responses, they MUST <bcp14>MUST</bcp14> include UID FETCH item.
     Note that this is a new requirement when compared to RFC 3501. <xref target="RFC3501" format="default"/>.
          </t>

<figure><artwork>
 <t>
Example:
	  </t>
<sourcecode type="">
  S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827 UID 447)
</artwork></figure>
</sourcecode>
        </section>
      </section>
      <section title='Server numbered="true" toc="default">
        <name>Server Responses - Command Continuation Request'> Request</name>
        <t>
   The command continuation request response is indicated by a "+" token
   instead of a tag.  This form of response indicates that the server is
   ready to accept the continuation of a command from the client.  The
   remainder of this response is a line of text.
        </t>
        <t>
   This response is used in the AUTHENTICATE command to transmit server
   data to the client, client and request additional client data.  This
   response is also used if an argument to any command is a synchronizing literal.
        </t>
        <t>
   The client is not permitted to send the octets of the synchronizing literal unless
   the server indicates that it is expected.  This permits the server to
   process commands and reject errors on a line-by-line basis.  The
   remainder of the command, including the CRLF that terminates a
   command, follows the octets of the literal.  If there are any
   additional command arguments, the literal octets are followed by a
   space and those arguments.
        </t>

<figure><artwork>
 <t>
Example:
	  </t>
<sourcecode type="">
  C: A001 LOGIN {11}
  S: + Ready for additional command text
  C: FRED FOOBAR {7}
  S: + Ready for additional command text
  C: fat man
  S: A001 OK LOGIN completed
  C: A044 BLURDYBLOOP {102856}
  S: A044 BAD No such command as "BLURDYBLOOP"
</artwork></figure>
</sourcecode>
      </section>
    </section>
    <section title='Sample numbered="true" toc="default" anchor="sample_IMAP4rev2">
      <name>Sample IMAP4rev2 connection'> Connection</name>

      <t>
   The following is a transcript of an IMAP4rev2 connection on a non TLS non-TLS port.
   A long line in this sample is broken for editorial clarity.
      </t>

<figure><artwork>
<sourcecode type="">
S:   * OK [CAPABILITY STARTTLS AUTH=SCRAM-SHA-256 LOGINDISABLED
      IMAP4rev2] IMAP4rev2 Service Ready
C:   a000 starttls
S:   a000 OK Proceed with TLS negotiation
 &lt;TLS negotiation> negotiation&gt;
C:   A001 AUTHENTICATE SCRAM-SHA-256
      biwsbj11c2VyLHI9ck9wck5HZndFYmVSV2diTkVrcU8=
S:   + cj1yT3ByTkdmd0ViZVJXZ2JORWtxTyVodllEcFdVYTJSYVRDQWZ1eEZJbGopaE5s
     RiRrMCxzPVcyMlphSjBTTlk3c29Fc1VFamI2Z1E9PSxpPTQwOTY= cj1yT3ByTkdmd0ViZVJXZ2JORWtxTyVodllEcFdVYTJSYVRDQWZ1eEZJbGopaE
     5sRiRrMCxzPVcyMlphSjBTTlk3c29Fc1VFamI2Z1E9PSxpPTQwOTY=
C:   Yz1iaXdzLHI9ck9wck5HZndFYmVSV2diTkVrcU8laHZZRHBXVWEyUmFUQ0FmdXhG
     SWxqKWhObEYkazAscD1kSHpiWmFwV0lrNGpVaE4rVXRlOXl0YWc5empmTUhnc3Ft
     bWl6N0FuZFZRPQ==
S:   + dj02cnJpVFJCaTIzV3BSUi93dHVwK21NaFVaVW4vZEI1bkxUSlJzamw5NUc0PQ== dj02cnJpVFJCaTIzV3BSUi93dHVwK21NaFVaVW4vZEI1bkxUSlJzamw5NUc0
     PQ==
C:
S:   A001 OK SCRAM-SHA-256 authentication successful
C:   babc ENABLE IMAP4rev2
S:   * ENABLED IMAP4rev2
S:   babc OK Some capabilities enabled
C:   a002 select inbox
S:   * 18 EXISTS
S:   * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S:   * OK [UIDVALIDITY 3857529045] UIDs valid
S:   * LIST () "/" INBOX ("OLDNAME" ("inbox"))
S:   a002 OK [READ-WRITE] SELECT completed
C:   a003 fetch 12 full
S:   * 12 FETCH (FLAGS (\Seen) INTERNALDATE
      "17-Jul-1996 02:44:25 -0700" RFC822.SIZE 4286 ENVELOPE ("Wed, (
      "Wed, 17 Jul 1996 02:23:25 -0700 (PDT)"
      "IMAP4rev2 WG mtg summary and minutes"
      (("Terry Gray" NIL "gray" "cac.washington.edu"))
      (("Terry Gray" NIL "gray" "cac.washington.edu"))
      (("Terry Gray" NIL "gray" "cac.washington.edu"))
      ((NIL NIL "imap" "cac.washington.edu"))
      ((NIL NIL "minutes" "CNRI.Reston.VA.US")
      ("John Klensin" NIL "KLENSIN" "MIT.EDU")) NIL NIL
      "&lt;B27397-0100000@cac.washington.edu>")
      "&lt;B27397-0100000@cac.washington.ed&gt;")
      BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT"
      3028 92))
S:    a003 OK FETCH completed
C:    a004 fetch 12 body[header]
S:    * 12 FETCH (BODY[HEADER] {342}
S:    Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)
S:    From: Terry Gray &lt;gray@cac.washington.edu> &lt;gray@cac.washington.edu&gt;
S:    Subject: IMAP4rev2 WG mtg summary and minutes
S:    To: imap@cac.washington.edu
S:    cc: minutes@CNRI.Reston.VA.US, John Klensin &lt;KLENSIN@MIT.EDU> &lt;KLENSIN@MIT.EDU&gt;
S:    Message-Id: &lt;B27397-0100000@cac.washington.edu> &lt;B27397-0100000@cac.washington.edu&gt;
S:    MIME-Version: 1.0
S:    Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
S:
S:    )
S:    a004 OK FETCH completed
C:    a005 store 12 +flags \deleted
S:    * 12 FETCH (FLAGS (\Seen \Deleted))
S:    a005 OK +FLAGS completed
C:    a006 logout
S:    * BYE IMAP4rev2 server terminating connection
S:    a006 OK LOGOUT completed
</artwork></figure>
</sourcecode>
    </section>
    <section title='Formal Syntax' anchor='IMAP-ABNF'> anchor="IMAP-ABNF" 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='ABNF'/>. target="RFC5234" format="default"/>.
      </t>
      <t>
   In the case of alternative or optional rules in which a later rule
   overlaps an earlier rule, the rule which that is listed earlier MUST <bcp14>MUST</bcp14> take
   priority.  For example, "\Seen" when parsed as a flag is the \Seen
   flag name and not a flag-extension, even though "\Seen" can be parsed
   as a flag-extension.  Some, but not all, instances of this rule are
   noted below.

        <list>
        <t>

      </t>
        <t indent="2" keepWithPrevious="true">
        Note: <xref target='ABNF'/> target="RFC5234" format="default"/> rules MUST <bcp14>MUST</bcp14> be followed strictly; in
        particular:
        </t>

        <t>
        (1) Except as noted otherwise,

        <ol spacing="normal" type="1">
        <li> Unless otherwise noted, all alphabetic characters
        are case-insensitive. case insensitive.  The use of upper uppercase or lower case lowercase
        characters to define token strings is for editorial clarity
        only.  Implementations MUST <bcp14>MUST</bcp14> accept these strings in a
        case-insensitive fashion.
        </t>

        <t>
        (2)
        </li>
        <li>
        In all cases, SP refers to exactly one space.  It is
        NOT permitted to substitute TAB, insert additional spaces,
        or otherwise treat SP as being equivalent to LWSP.
        </t>

        <t>
        (3) linear whitespace (LWSP).
        </li>
        <li>
        The ASCII NUL character, %x00, MUST NOT <bcp14>MUST NOT</bcp14> be used anywhere,
        with the exception of the OCTET production.
        </t>
        </list>
   </t>

<figure><artwork>
        </li>
	</ol>

<sourcecode type="abnf">
SP              = &lt;Defined in RFC 5234&gt;
CTL             = &lt;Defined in RFC 5234&gt;
CRLF            = &lt;Defined in RFC 5234&gt;
ALPHA           = &lt;Defined in RFC 5234&gt;
DIGIT           = &lt;Defined in RFC 5234&gt;
DQUOTE          = &lt;Defined in RFC 5234&gt;
OCTET           = &lt;Defined in RFC 5234&gt;

address         = "(" addr-name SP addr-adl SP addr-mailbox SP
                  addr-host ")"

addr-adl        = nstring
                    ; Holds route from [RFC-5322] [RFC5322] obs-route if
                    ; non-NIL

addr-host       = nstring
                    ; NIL indicates [RFC-5322] [RFC5322] group syntax.
                    ; Otherwise, holds [RFC-5322] [RFC5322] domain name

addr-mailbox    = nstring
                    ; NIL indicates end of [RFC-5322] [RFC5322] group; if
                    ; non-NIL and addr-host is NIL, holds
                    ; [RFC-5322] [RFC5322] group name.
                    ; Otherwise, holds [RFC-5322] [RFC5322] local-part
                    ; after removing [RFC-5322] [RFC5322] quoting

addr-name       = nstring
                    ; If non-NIL, holds phrase from [RFC-5322] [RFC5322]
                    ; mailbox after removing [RFC-5322] [RFC5322] quoting

append          = "APPEND" SP mailbox [SP flag-list] [SP date-time]
                  SP literal

append-uid      = uniqueid

astring         = 1*ASTRING-CHAR / string

ASTRING-CHAR   = ATOM-CHAR / resp-specials

atom            = 1*ATOM-CHAR

ATOM-CHAR       = &lt;any CHAR except atom-specials> atom-specials&gt;

atom-specials   = "(" / ")" / "{" / SP / CTL / list-wildcards /
                  quoted-specials / resp-specials

authenticate    = "AUTHENTICATE" SP auth-type [SP initial-resp]
                  *(CRLF base64)

auth-type       = atom
                    ; Defined Authentication mechanism name, as defined by [SASL]
                    ; [SASL], Section 7.1

base64          = *(4base64-char) [base64-terminal]

base64-char     = ALPHA / DIGIT / "+" / "/"
                    ; Case-sensitive Case sensitive

base64-terminal = (2base64-char "==") / (3base64-char "=")

body            = "(" (body-type-1part / body-type-mpart) ")"

body-extension  = nstring / number / number64 /
                   "(" body-extension *(SP body-extension) ")"
                    ; Future expansion.  Client implementations
                    ; MUST accept body-extension fields.  Server
                    ; implementations MUST NOT generate
                    ; body-extension fields except as defined by
                    ; future standard Standard or standards-track Standards Track
                    ; revisions of this specification.

body-ext-1part  = body-fld-md5 [SP body-fld-dsp [SP body-fld-lang
                  [SP body-fld-loc *(SP body-extension)]]]
                    ; MUST NOT be returned on non-extensible
                    ; "BODY" fetch

body-ext-mpart  = body-fld-param [SP body-fld-dsp [SP body-fld-lang
                  [SP body-fld-loc *(SP body-extension)]]]
                    ; MUST NOT be returned on non-extensible
                    ; "BODY" fetch

body-fields     = body-fld-param SP body-fld-id SP body-fld-desc SP
                  body-fld-enc SP body-fld-octets

body-fld-desc   = nstring

body-fld-dsp    = "(" string SP body-fld-param ")" / nil

body-fld-enc    = (DQUOTE ("7BIT" / "8BIT" / "BINARY" / "BASE64"/
                  "QUOTED-PRINTABLE") DQUOTE) / string
                  ; Content-Transfer-Encoding header field value.
                  ; Defaults to "7BIT" (as per RFC 2045)
                  ; if not present in the body part.

body-fld-id     = nstring

body-fld-lang   = nstring / "(" string *(SP string) ")"

body-fld-loc    = nstring

body-fld-lines  = number64

body-fld-md5    = nstring

body-fld-octets = number

body-fld-param  = "(" string SP string *(SP string SP string) ")" /
                  nil

body-type-1part = (body-type-basic / body-type-msg / body-type-text)
                  [SP body-ext-1part]

body-type-basic = media-basic SP body-fields
                    ; MESSAGE subtype MUST NOT be "RFC822" or
                    ; "GLOBAL"

body-type-mpart = 1*body SP media-subtype
                  [SP body-ext-mpart]
                    ; MULTIPART body part

body-type-msg   = media-message SP body-fields SP envelope
                  SP body SP body-fld-lines

body-type-text  = media-text SP body-fields SP body-fld-lines

capability      = ("AUTH=" auth-type) / atom
                    ; New capabilities SHOULD be
                    ; registered with IANA using the
                    ; RFC Required policy, i.e. i.e., in
                    ; a standards-track, Standards Track, an experimental Experimental,
                    ; or an informational Informational RFC.

capability-data = "CAPABILITY" *(SP capability) SP "IMAP4rev2"
                  *(SP capability)
                    ; Servers MUST implement the STARTTLS and LOGINDISABLED See Section 6.1.1 for information about
                    ; (on cleartext port), AUTH=PLAIN required security-related capabilities.
                    ; Servers which that offer RFC 1730 compatibility MUST
                    ; list "IMAP4" as the first capability.
                    ; Servers which that offer RFC 3501 compatibility MUST
                    ; list "IMAP4rev1" as one of the capabilities.

CHAR            = &lt;defined in [ABNF]&gt;

CHAR8           = %x01-ff
                    ; any OCTET except NUL, %x00

charset         = atom / quoted

childinfo-extended-item =  "CHILDINFO" SP "("
            list-select-base-opt-quoted
            *(SP list-select-base-opt-quoted) ")"
            ; Extended data item (mbox-list-extended-item)
            ; returned when the RECURSIVEMATCH
            ; selection option is specified.
            ; Note 1: the CHILDINFO extended data item tag can be
            ; returned with and or without surrounding quotes, as per
            ; mbox-list-extended-item-tag production.
            ; Note 2: The selection options are always returned
            ; quoted, unlike their specification in
            ; the extended LIST command.

child-mbox-flag =  "\HasChildren" / "\HasNoChildren"
            ; attributes for the CHILDREN return option, at most one
            ; one possible per LIST response

command         = tag SP (command-any / command-auth /
                  command-nonauth / command-select) CRLF
                    ; Modal based on state

command-any     = "CAPABILITY" / "LOGOUT" / "NOOP"
                    ; Valid in all states

command-auth    = append / create / delete / enable / examine /
                  list /
                  Namespace-Command namespace-command / rename /
                  select / status / subscribe / unsubscribe /
                  idle
                    ; Valid only in Authenticated or Selected state

command-nonauth = login / authenticate / "STARTTLS"
                    ; Valid only when in Not Authenticated state

command-select  = "CLOSE" / "UNSELECT" / "EXPUNGE" / copy /
                   move / fetch / store / search / uid
                    ; Valid only when in Selected state

continue-req    = "+" SP (resp-text / base64) CRLF

copy            = "COPY" SP sequence-set SP mailbox

create          = "CREATE" SP mailbox
                    ; Use of INBOX gives a NO error

date            = date-text / DQUOTE date-text DQUOTE

date-day        = 1*2DIGIT
                    ; Day of month

date-day-fixed  = (SP DIGIT) / 2DIGIT
                    ; Fixed-format version of date-day

date-month      = "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" /
                  "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec"

date-text       = date-day "-" date-month "-" date-year

date-year       = 4DIGIT

date-time       = DQUOTE date-day-fixed "-" date-month "-" date-year
                  SP time SP zone DQUOTE

delete          = "DELETE" SP mailbox
                    ; Use of INBOX gives a NO error

digit-nz        = %x31-39
                    ; 1-9

eitem-standard-tag =  atom
            ; a tag for LIST extended data item defined in a Standard
            ; Track or Experimental RFC.

eitem-vendor-tag =  vendor-token "-" atom
            ; a vendor-specific tag for LIST extended data item

enable          = "ENABLE" 1*(SP capability)

enable-data     = "ENABLED" *(SP capability)

envelope        = "(" env-date SP env-subject SP env-from SP
                  env-sender SP env-reply-to SP env-to SP env-cc SP
                  env-bcc SP env-in-reply-to SP env-message-id ")"

env-bcc         = "(" 1*address ")" / nil

env-cc          = "(" 1*address ")" / nil

env-date        = nstring

env-from        = "(" 1*address ")" / nil

env-in-reply-to = nstring

env-message-id  = nstring

env-reply-to    = "(" 1*address ")" / nil

env-sender      = "(" 1*address ")" / nil

env-subject     = nstring

env-to          = "(" 1*address ")" / nil

esearch-response  = "ESEARCH" [search-correlator] [SP "UID"]
                    *(SP search-return-data)
                  ; ESEARCH response replaces SEARCH response
                  ; from IMAP4rev1.

examine         = "EXAMINE" SP mailbox

fetch           = "FETCH" SP sequence-set SP ("ALL" (
                  "ALL" / "FULL" / "FAST" /
                  fetch-att / "(" fetch-att *(SP fetch-att) ")")

fetch-att       = "ENVELOPE" / "FLAGS" / "INTERNALDATE" /
                  "RFC822.SIZE" /
                  "BODY" ["STRUCTURE"] / "UID" /
                  "BODY" section [partial] /
                  "BODY.PEEK" section [partial] /
                  "BINARY" [".PEEK"] section-binary [partial] /
                  "BINARY.SIZE" section-binary

flag            = "\Answered" / "\Flagged" / "\Deleted" /
                  "\Seen" / "\Draft" / flag-keyword / flag-extension
                    ; Does not include "\Recent"

flag-extension  = "\" atom
                    ; Future expansion.  Client implementations
                    ; MUST accept flag-extension flags.  Server
                    ; implementations MUST NOT generate
                    ; flag-extension flags except as defined by
                    ; a future standard Standard or standards-track Standards Track
                    ; revisions of this specification.
                    ; "\Recent" was defined in RFC 3501
                    ; and is now deprecated.

flag-fetch      = flag / obsolete-flag-recent

flag-keyword    = "$MDNSent" / "$Forwarded" / "$Junk" /
                  "$NotJunk" / "$Phishing" / atom

flag-list       = "(" [flag *(SP flag)] ")"

flag-perm       = flag / "\*"

greeting        = "*" SP (resp-cond-auth / resp-cond-bye) CRLF

header-fld-name = astring

header-list     = "(" header-fld-name *(SP header-fld-name) ")"

idle            = "IDLE" CRLF "DONE"

initial-resp    =  (base64 / "=")
                   ; "initial response" defined in
                   ; Section 5.1 4 of [RFC4422] [SASL]

list            = "LIST" [SP list-select-opts] SP
                  mailbox SP mbox-or-pat
                  [SP list-return-opts]

list-mailbox    = 1*list-char / string

list-char       = ATOM-CHAR / list-wildcards / resp-specials

list-return-opt   =  return-option
                     ; Note that return-option is the ABNF
                     ; non terminal non-terminal used by RFC 5258

list-return-opts =  "RETURN" SP
            "(" [list-return-opt *(SP list-return-opt)] ")"
            ; list return options, e.g., CHILDREN

list-select-base-opt =  "SUBSCRIBED" / option-extension
            ; options that can be used by themselves

list-select-base-opt-quoted =  DQUOTE list-select-base-opt DQUOTE

list-select-independent-opt =  "REMOTE" / option-extension
            ; options that do not syntactically interact with
            ; other options

list-select-mod-opt =  "RECURSIVEMATCH" / option-extension
            ; options that require a list-select-base-opt
            ; to also be present

list-select-opt =  list-select-base-opt / list-select-independent-opt
                   / list-select-mod-opt
            ; An option registration template is described in
            ; Section 9.3 of this document.

list-select-opts =  "(" [
                   (*(list-select-opt SP) list-select-base-opt
                   *(SP list-select-opt))
                  / (list-select-independent-opt
                   *(SP list-select-independent-opt))
                     ] ")"
            ; Any number of options may be in any order.
            ; If a list-select-mod-opt appears, then a
            ; list-select-base-opt must also appear.
            ; This allows these:
            ; ()
            ; (REMOTE)
            ; (SUBSCRIBED)
            ; (SUBSCRIBED REMOTE)
            ; (SUBSCRIBED RECURSIVEMATCH)
            ; (SUBSCRIBED REMOTE RECURSIVEMATCH)
            ; But does NOT allow these:
            ; (RECURSIVEMATCH)
            ; (REMOTE RECURSIVEMATCH)

list-wildcards  = "%" / "*"

literal         = "{" number64 ["+"] "}" CRLF *CHAR8
                    ; &lt;number64&gt; represents the number of CHAR8s.
                    ; A non-synchronizing literal is distinguished from
                    ; from a synchronizing literal by the presence of the "+"
                    ; "+" before the closing "}".
                    ; Non synchronizing Non-synchronizing literals are not allowed when
                    ; sent from server to the client.

literal8        =  "~{" number64 "}" CRLF *OCTET
                    ; &lt;number64&gt; represents the number of OCTETs
                    ; in the response string.

login           = "LOGIN" SP userid SP password

mailbox         = "INBOX" / astring
                    ; INBOX is case-insensitive. case insensitive.  All case variants of
                    ; of INBOX (e.g., "iNbOx") MUST be interpreted as INBOX
                    ; INBOX, not as an astring.  An astring which that
                    ; consists of
                    ; the case-insensitive sequence
                    ; "I" "N" "B" "O" "X"
                    ; is considered
                    ; to be an INBOX and not an astring.
                    ; Refer to section Section 5.1 for further
                    ; semantic details of mailbox names.

mailbox-data    =  "FLAGS" SP flag-list / "LIST" SP mailbox-list /
                   esearch-response /
                   "STATUS" SP mailbox SP "(" [status-att-list] ")" /
                   number SP "EXISTS" / Namespace-Response namespace-response /
                   obsolete-search-response /
                   obsolete-recent-response
                    ; obsolete-search-response and
                    ; obsolete-recent-response can only be returned
                    ; by servers that support both IMAPrev1
                    ; and IMAPrev2.

mailbox-list    = "(" [mbx-list-flags] ")" SP
                   (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox
                   [SP mbox-list-extended]
            ; This is the list information pointed to by the ABNF
            ; item "mailbox-data", which is defined in [IMAP4] above

mbox-list-extended =  "(" [mbox-list-extended-item
                      *(SP mbox-list-extended-item)] ")"

mbox-list-extended-item = mbox-list-extended-item-tag SP
                           tagged-ext-val

mbox-list-extended-item-tag = astring
               ; The content MUST conform to either "eitem-vendor-tag"
               ; "eitem-vendor-tag" or "eitem-standard-tag"
               ; ABNF productions.

mbox-or-pat =  list-mailbox / patterns

mbx-list-flags  = *(mbx-list-oflag SP) mbx-list-sflag
                  *(SP mbx-list-oflag) /
                  mbx-list-oflag *(SP mbx-list-oflag)

mbx-list-oflag  = "\Noinferiors" / child-mbox-flag /
                  "\Subscribed" / "\Remote" / flag-extension
               ; Other flags; multiple from this list are
               ; possible per LIST response, but each flag
               ; can only appear once per LIST response

mbx-list-sflag  = "\NonExistent" / "\Noselect" / "\Marked" /
                  "\Unmarked"
               ; Selectability flags; only one per LIST response

media-basic     = ((DQUOTE ("APPLICATION" / "AUDIO" / "IMAGE" /
                  "FONT" / "MESSAGE" / "MODEL" / "VIDEO" ) DQUOTE)
                  / string)
                  SP media-subtype
                    ; FONT defined in RFC 8081. [RFC8081].
                    ; MODEL defined in RFC 2077. [RFC2077].
                    ; Other top level top-level media types
                    ; are defined in [MIME-IMT].

media-message   = DQUOTE "MESSAGE" DQUOTE SP
                  DQUOTE ("RFC822" / "GLOBAL") DQUOTE
                    ; Defined in [MIME-IMT]

media-subtype   = string
                    ; Defined in [MIME-IMT]

media-text      = DQUOTE "TEXT" DQUOTE SP media-subtype
                    ; Defined in [MIME-IMT]

message-data    = nz-number SP ("EXPUNGE" / ("FETCH" SP msg-att))

move            = "MOVE" SP sequence-set SP mailbox

msg-att         = "(" (msg-att-dynamic / msg-att-static)
                   *(SP (msg-att-dynamic / msg-att-static)) ")"

msg-att-dynamic = "FLAGS" SP "(" [flag-fetch *(SP flag-fetch)] ")"
                    ; MAY change for a message

msg-att-static  = "ENVELOPE" SP envelope /
                  "INTERNALDATE" SP date-time /
                  "RFC822.SIZE" SP number64 /
                  "BODY" ["STRUCTURE"] SP body /
                  "BODY" section ["&lt;" number ">"] "&gt;"] SP nstring /
                  "BINARY" section-binary SP (nstring / literal8) /
                  "BINARY.SIZE" section-binary SP number /
                  "UID" SP uniqueid
                    ; MUST NOT change for a message

name-component  = 1*UTF8-CHAR
                    ; MUST NOT contain ".", "/", "%", or "*"

namespace         = nil / "(" 1*namespace-descr ")"

namespace-command = "NAMESPACE"

namespace-descr   = "(" string SP
                       (DQUOTE QUOTED-CHAR DQUOTE / nil)
                        [namespace-response-extensions] ")"

namespace-response-extensions = *namespace-response-extension

namespace-response-extension = SP string SP
                  "(" string *(SP string) ")"

namespace-response = "NAMESPACE" SP namespace
                      SP namespace SP namespace
                 ; The first Namespace is the Personal Namespace(s).
                 ; The second Namespace is the Other Users'
                 ; Namespace(s).
                 ; The third Namespace is the Shared Namespace(s).

nil             = "NIL"

nstring         = string / nil

number          = 1*DIGIT
                    ; Unsigned 32-bit integer
                    ; (0 &lt;= n &lt; 4,294,967,296)

number64        = 1*DIGIT
                    ; Unsigned 63-bit integer
                    ; (0 &lt;= n &lt;= 9,223,372,036,854,775,807)

nz-number       = digit-nz *DIGIT
                    ; Non-zero unsigned 32-bit integer
                    ; (0 &lt; n &lt; 4,294,967,296)

nz-number64     = digit-nz *DIGIT
                    ; Unsigned 63-bit integer
                    ; (0 &lt; n &lt;= 9,223,372,036,854,775,807)

obsolete-flag-recent = "\Recent"

obsolete-recent-response = number SP "RECENT"

obsolete-search-response = "SEARCH" *(SP nz-number)

oldname-extended-item =  "OLDNAME" SP "(" mailbox ")"
                    ; Extended data item (mbox-list-extended-item)
                    ; returned in a LIST response when a mailbox is
                    ; renamed or deleted. Also returned when
                    ; the server canonicalized the provided mailbox
                    ; name.
                    ; Note 1: the OLDNAME tag can be returned
                    ; with or without surrounding quotes, as per
                    ; mbox-list-extended-item-tag production.

option-extension = (option-standard-tag / option-vendor-tag)
                   [SP option-value]

option-standard-tag =  atom
               ; an option defined in a Standards Track or
               ; Experimental RFC

option-val-comp =  astring /
                   option-val-comp *(SP option-val-comp) /
                   "(" option-val-comp ")"

option-value =  "(" option-val-comp ")"

option-vendor-tag =  vendor-token "-" atom
               ; a vendor-specific option, non-standard

partial-range    = number64 ["." nz-number64]
                    ; Copied from RFC 5092 (IMAP URL)
                    ; and updated to support 64bit 64-bit sizes.

partial         = "&lt;" number64 "." nz-number64 ">" "&gt;"
                    ; Partial FETCH request. 0-based offset of
                    ; the first octet, followed by the number of octets
                    ; octets in the fragment.

password        = astring

patterns        = "(" list-mailbox ")"
                  ; [RFC5258] supports multiple patterns,
                  ; but this document only requires one
                  ; to be supported.
                  ; If the server is also implementing
                  ; [RFC5258], the "patterns" syntax from that
                  ; that document must be followed.

quoted          = DQUOTE *QUOTED-CHAR DQUOTE

QUOTED-CHAR     = &lt;any TEXT-CHAR except quoted-specials> quoted-specials&gt; /
                  "\" quoted-specials / UTF8-2 / UTF8-3 / UTF8-4

quoted-specials = DQUOTE / "\"

rename          = "RENAME" SP mailbox SP mailbox
                    ; Use of INBOX as a destination gives a NO error

response        = *(continue-req / response-data) response-done

response-data   = "*" SP (resp-cond-state / resp-cond-bye /
                  mailbox-data / message-data / capability-data /
                  enable-data) CRLF

response-done   = response-tagged / response-fatal

response-fatal  = "*" SP resp-cond-bye CRLF
                    ; Server closes connection immediately

response-tagged = tag SP resp-cond-state CRLF

resp-code-apnd  = "APPENDUID" SP nz-number SP append-uid

resp-code-copy  = "COPYUID" SP nz-number SP uid-set SP uid-set

resp-cond-auth  = ("OK" / "PREAUTH") SP resp-text
                    ; Authentication condition

resp-cond-bye   = "BYE" SP resp-text

resp-cond-state = ("OK" / "NO" / "BAD") SP resp-text
                    ; Status condition

resp-specials   = "]"

resp-text       = ["[" resp-text-code "]" SP] [text]

resp-text-code  = "ALERT" /
                  "BADCHARSET" [SP "(" charset *(SP charset) ")" ] /
                  capability-data / "PARSE" /
                  "PERMANENTFLAGS" SP
                      "(" [flag-perm *(SP flag-perm)] ")" /
                  "READ-ONLY" / "READ-WRITE" / "TRYCREATE" /
                  "UIDNEXT" SP nz-number /
                  "UIDVALIDITY" SP nz-number /
                  resp-code-apnd / resp-code-copy / "UIDNOTSTICKY" /
                  "UNAVAILABLE" / "AUTHENTICATIONFAILED" /
                  "AUTHORIZATIONFAILED" / "EXPIRED" /
                  "PRIVACYREQUIRED" / "CONTACTADMIN" / "NOPERM" /
                  "INUSE" / "EXPUNGEISSUED" / "CORRUPTION" /
                  "SERVERBUG" / "CLIENTBUG" / "CANNOT" /
                  "LIMIT" / "OVERQUOTA" / "ALREADYEXISTS" /
                  "NONEXISTENT" / "NOTSAVED" / "HASCHILDREN" /
                  "CLOSED" /
                  "UNKNOWN-CTE" /
                  atom [SP 1*&lt;any TEXT-CHAR except "]">] "]"&gt;]

return-option   = "SUBSCRIBED" / "CHILDREN" / status-option /
                   option-extension

search          = "SEARCH" [search-return-opts]
                  SP search-program

search-correlator  = SP "(" "TAG" SP tag-string ")"

search-key      = "ALL" / "ANSWERED" / "BCC" SP astring /
                  "BEFORE" SP date / "BODY" SP astring /
                  "CC" SP astring / "DELETED" / "FLAGGED" /
                  "FROM" SP astring / "KEYWORD" SP flag-keyword /
                  "ON" SP date / "SEEN" /
                  "SINCE" SP date / "SUBJECT" SP astring /
                  "TEXT" SP astring / "TO" SP astring /
                  "UNANSWERED" / "UNDELETED" / "UNFLAGGED" /
                  "UNKEYWORD" SP flag-keyword / "UNSEEN" /
                    ; Above this line were in [IMAP2]
                  "DRAFT" / "HEADER" SP header-fld-name SP astring /
                  "LARGER" SP number64 / "NOT" SP search-key /
                  "OR" SP search-key SP search-key /
                  "SENTBEFORE" SP date / "SENTON" SP date /
                  "SENTSINCE" SP date / "SMALLER" SP number64 /
                  "UID" SP sequence-set / "UNDRAFT" / sequence-set /
                  "(" search-key *(SP search-key) ")"

search-modifier-name = tagged-ext-label

search-mod-params = tagged-ext-val
                  ; This non-terminal shows recommended syntax
                  ; for future extensions.

search-program     = ["CHARSET" SP charset SP]
                    search-key *(SP search-key)
                    ; CHARSET argument to SEARCH MUST be
                    ; registered with IANA.

search-ret-data-ext = search-modifier-name SP search-return-value
                    ; Note that not every SEARCH return option
                    ; is required to have the corresponding
                    ; ESEARCH return data.

search-return-data = "MIN" SP nz-number /
                    "MAX" SP nz-number /
                    "ALL" SP sequence-set /
                    "COUNT" SP number /
                    search-ret-data-ext
                    ; All return data items conform to
                    ; search-ret-data-ext syntax.
                    ; Note that "$" marker is not allowed
                    ; after the ALL return data item.

search-return-opts = SP "RETURN" SP "(" [search-return-opt
                    *(SP search-return-opt)] ")"

search-return-opt  = "MIN" / "MAX" / "ALL" / "COUNT" /
                     "SAVE" /
                     search-ret-opt-ext
                    ; conforms to generic search-ret-opt-ext
                    ; syntax

search-ret-opt-ext = search-modifier-name [SP search-mod-params]

search-return-value = tagged-ext-val
                    ; Data for the returned search option.
                    ; A single "nz-number"/"number"/"number64" value
                    ; can be returned as an atom (i.e., without
                    ; quoting).  A sequence-set can be returned
                    ; as an atom as well.

section         = "[" [section-spec] "]"

section-binary  = "[" [section-part] "]"

section-msgtext = "HEADER" /
                  "HEADER.FIELDS" [".NOT"] SP header-list /
                  "TEXT"
                    ; top-level or MESSAGE/RFC822 or
                    ; MESSAGE/GLOBAL part

section-part    = nz-number *("." nz-number)
                    ; body part reference.
                    ; Allows for accessing nested body parts.

section-spec    = section-msgtext / (section-part ["." section-text])

section-text    = section-msgtext / "MIME"
                    ; text other than actual body part (headers,
                    ; etc.)

select          = "SELECT" SP mailbox

seq-number      = nz-number / "*"
                    ; message sequence number (COPY, FETCH, STORE
                    ; commands) or unique identifier (UID COPY,
                    ; UID FETCH, UID STORE commands).
                    ; * represents the largest number in use.  In
                    ; the case of message sequence numbers, it is
                    ; the number of messages in a non-empty mailbox.
                    ; In the case of unique identifiers, it is the
                    ; unique identifier of the last message in the
                    ; mailbox or, if the mailbox is empty, the
                    ; mailbox's current UIDNEXT value.
                    ; The server should respond with a tagged BAD
                    ; response to a command that uses a message
                    ; sequence number greater than the number of
                    ; messages in the selected mailbox.  This
                    ; includes "*" if the selected mailbox is empty.

seq-range       = seq-number ":" seq-number
                    ; two seq-number values and all values between
                    ; these two regardless of order.
                    ; Example: 2:4 and 4:2 are equivalent and indicate
                    ; indicate values 2, 3, and 4.
                    ; Example: a unique identifier sequence range of
                    ; 3291:* includes the UID of the last message in
                    ; the mailbox, even if that value is less than
                    ; 3291.

sequence-set    = (seq-number / seq-range) ["," sequence-set]
                    ; set of seq-number values, regardless of order.
                    ; Servers MAY coalesce overlaps and/or execute the
                    ; the sequence in any order.
                    ; Example: a message sequence number set of
                    ; 2,4:7,9,12:* for a mailbox with 15 messages is
                    ; equivalent to 2,4,5,6,7,9,12,13,14,15
                    ; Example: a message sequence number set of *:4,5:7
                    ; *:4,5:7 for a mailbox with 10 messages is
                    ; equivalent to
                    ; 10,9,8,7,6,5,4,5,6,7 and MAY
                    ; be reordered and
                    ; overlap coalesced to be
                    ; 4,5,6,7,8,9,10.

sequence-set    =/ seq-last-command
                    ; Allow for "result of the last command"
                    ; indicator.

seq-last-command   = "$"

status          = "STATUS" SP mailbox SP
                  "(" status-att *(SP status-att) ")"

status-att      = "MESSAGES" / "UIDNEXT" / "UIDVALIDITY" /
                  "UNSEEN" / "DELETED" / "SIZE"

status-att-val  = ("MESSAGES" SP number) /
                  ("UIDNEXT" SP nz-number) /
                  ("UIDVALIDITY" SP nz-number) /
                  ("UNSEEN" SP number) /
                  ("DELETED" SP number) /
                  ("SIZE" SP number64)
                    ; Extensions to the STATUS responses
                    ; should extend this production.
                    ; Extensions should use the generic
                    ; syntax defined by tagged-ext.

status-att-list =  status-att-val *(SP status-att-val)

status-option = "STATUS" SP "(" status-att *(SP status-att) ")"
                    ; This ABNF production complies with
                    ; &lt;option-extension&gt; syntax.

store           = "STORE" SP sequence-set SP store-att-flags

store-att-flags = (["+" / "-"] "FLAGS" [".SILENT"]) SP
                  (flag-list / (flag *(SP flag)))

string          = quoted / literal

subscribe       = "SUBSCRIBE" SP mailbox

tag             = 1*&lt;any ASTRING-CHAR except "+"> "+"&gt;

tag-string      = astring
                  ; &lt;tag&gt; represented as &lt;astring&gt;

tagged-ext-label    = tagged-label-fchar *tagged-label-char
                      ; Is a valid RFC 3501 "atom".

tagged-label-fchar  = ALPHA / "-" / "_" / "."

tagged-label-char   = tagged-label-fchar / DIGIT / ":"

tagged-ext-comp     = astring /
                      tagged-ext-comp *(SP tagged-ext-comp) /
                      "(" tagged-ext-comp ")"
                      ; Extensions that follow this general
                      ; syntax should use nstring instead of
                      ; astring when appropriate in the context
                      ; of the extension.
                      ; Note that a message set or a "number"
                      ; can always be represented as an "atom".
                      ; An A URL should be represented as
                      ; a "quoted" string.

tagged-ext-simple   = sequence-set / number / number64

tagged-ext-val      = tagged-ext-simple /
                      "(" [tagged-ext-comp] ")"

text            = 1*(TEXT-CHAR / UTF8-2 / UTF8-3 / UTF8-4)
                    ; Non ASCII Non-ASCII text can only be returned
                    ; after ENABLE IMAP4rev2 command

TEXT-CHAR       = &lt;any CHAR except CR and LF> LF&gt;

time            = 2DIGIT ":" 2DIGIT ":" 2DIGIT
                    ; Hours minutes seconds

uid             = "UID" SP
                  (copy / move / fetch / search / store /
                   uid-expunge)
                    ; Unique identifiers used instead of message
                    ; sequence numbers

uid-expunge     = "EXPUNGE" SP sequence-set
                    ; Unique identifiers used instead of message
                    ; sequence numbers

uid-set         = (uniqueid / uid-range) *("," uid-set)

uid-range       = (uniqueid ":" uniqueid)
                    ; two uniqueid values and all values
                    ; between these two regards regardless of order.
                    ; Example: 2:4 and 4:2 are equivalent.

uniqueid        = nz-number
                    ; Strictly ascending

unsubscribe     = "UNSUBSCRIBE" SP mailbox

userid          = astring

UTF8-CHAR       = &lt;Defined in Section 4 of RFC 3629> 3629&gt;

UTF8-2          = &lt;Defined in Section 4 of RFC 3629> 3629&gt;

UTF8-3          = &lt;Defined in Section 4 of RFC 3629> 3629&gt;

UTF8-4          = &lt;Defined in Section 4 of RFC 3629> 3629&gt;

vendor-token    = "vendor." name-component
                    ; Definition copied from RFC 2244.
                    ; MUST be registered with IANA

zone            = ("+" / "-") 4DIGIT
                    ; Signed four-digit value of hhmm representing
                    ; hours and minutes east of Greenwich (that is,
                    ; the amount that the given time differs from
                    ; Universal Time).  Subtracting the timezone
                    ; from the given time will give the UT form.
                    ; The Universal Time zone is "+0000".
</artwork></figure>
</sourcecode>
    </section>
    <section title="Author's Note"> numbered="true" toc="default">
      <name>Author's Note</name>
      <t>
   This document is a revision or rewrite of earlier documents, documents and
   supercedes the protocol specification in those documents: RFC 3501, RFC 2060,
   RFC 1730, <xref target="RFC3501" format="default"/>, <xref target="RFC2060" format="default"/>,
   <xref target="RFC1730" format="default"/>, unpublished IMAP2bis.TXT document, RFC 1176, <xref target="RFC1176" format="default"/>, and RFC 1064. <xref target="RFC1064" format="default"/>.
      </t>
    </section>
    <section title='Security Considerations' anchor='sec-cons'> anchor="sec-cons" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
   IMAP4rev2 protocol transactions, including electronic mail data, are
   sent in the clear over the network network, exposing them to possible eavesdropping and
   manipulation unless protection is negotiated.
   This can be accomplished either by the use of the Implicit TLS port,
   the STARTTLS command, negotiated confidentiality protection in the AUTHENTICATE command,
   or some other protection mechanism.
      </t>
      <section title='TLS related numbered="true" toc="default">
        <name>TLS-Related Security Considerations'> Considerations</name>
        <t>This section applies to both use of both the STARTTLS command and the Implicit TLS port.</t>
        <t>
   IMAP client and server implementations MUST <bcp14>MUST</bcp14> comply with relevant
   TLS recommendations from <xref target='RFC8314'/>.
   <!--Add some specific section references?--> target="RFC8314" format="default"/>.
   If recommendations/requirements in this document conflict with recommendations
   from <xref target="RFC8314" format="default"/>, for example in regards to TLS ciphersuites,
   recommendations from this document take precedence.
        </t>

        <t>
   Clients and servers MUST <bcp14>MUST</bcp14> implement <xref target='TLS-1.2'>TLS target="RFC5246" format="default">TLS 1.2</xref> or newer.
   Use of TLS 1.3 <xref target='TLS-1.3'/> target="RFC8446" format="default"/> is RECOMMENDED. <bcp14>RECOMMENDED</bcp14>.
   TLS 1.2 may be used only in cases where the other party has not yet implemented TLS 1.3.
  <!--From RFC8314:
     All Mail Access Servers and Mail Submission Servers SHOULD
     implement the recommended TLS ciphersuites described in [RFC7525]
     or a future BCP or Standards Track revision of that document.
    -->
   Additionally, when using TLS 1.2, IMAP implementations MUST <bcp14>MUST</bcp14> implement the
   TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite.
   <!--While TLS_RSA_WITH_AES_128_CBC_SHA is mandatory-to-implement in the original TLS 1.2 RFC,
   it is not longer "recommended" in the IANA registry.
   TLS_RSA_WITH_AES_128_CBC_SHA256 is marginally better, but it is still
   not recommended in the IANA registry.-->
   This is important as it assures ensures that any two compliant implementations can be
   configured to interoperate.
   Other TLS cipher suites recommended in RFC 7525 <xref target='RFC7525'/> target="RFC7525" format="default"/>
   are RECOMMENDED: <bcp14>RECOMMENDED</bcp14>:
   TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, and
   TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384.

<!--Mozilla recommends the following TLS 1.2 ciphers for "Intermediate" compatibility:

     TLS_ECDHE_ECDSA_AES128_GCM_SHA256
     TLS_ECDHE_RSA_AES128_GCM_SHA256
     TLS_ECDHE_ECDSA_AES256_GCM_SHA384
     TLS_ECDHE_RSA_AES256_GCM_SHA384
     TLS_ECDHE_ECDSA_CHACHA20_POLY1305
     TLS_ECDHE_RSA_CHACHA20_POLY1305
     TLS_DHE_RSA_AES128_GCM_SHA256
     TLS_DHE_RSA_AES256_GCM_SHA384

  -->

   All other cipher suites are OPTIONAL. <bcp14>OPTIONAL</bcp14>.
   Note that this is a change from section 2.1 of <xref target='IMAP-TLS'/>. target="RFC2595" sectionFormat="of" section="2.1"/>.
        </t>
        <t>The list of mandatory-to-implement TLS 1.3 cipher suites is described in
   Section 9.1 of
   <xref target='TLS-1.3'/>.</t> target="RFC8446" sectionFormat="of" section="9.1"/>.</t>
        <t>
   During the TLS negotiation <xref target='TLS-1.3'/><xref target='TLS-1.2'/>, target="RFC8446" format="default"/> <xref target="RFC5246" format="default"/>,
   the client MUST <bcp14>MUST</bcp14> check its understanding
   of the server hostname against the server's identity as presented in
   the server Certificate message, in order to prevent on-path
   attackers attempting to masquerade as the server.
   This procedure is described in <xref target='RFC7817'/>. target="RFC7817" format="default"/>.
        </t>
        <t>
   Both the client and server MUST <bcp14>MUST</bcp14> check the result of the STARTTLS
   command and subsequent TLS (<xref target='TLS-1.3'/><xref target='TLS-1.2'/>) <xref target="RFC8446" format="default"/> <xref target="RFC5246" format="default"/>
   negotiation to see whether acceptable
   authentication and/or privacy was achieved.
        </t>
      </section>
      <section title='STARTTLS command versa use numbered="true" toc="default">
        <name>STARTTLS Command versus Use of Implicit TLS port'>

      <!--Arnt wrote: 1. Require of client authors that their clients be able to connect to 993-only servers.
          This does not impose a complicated new requirement since e.g. gmail has been 993-only since the late bronze age.
        --> Port</name>

      <t>For maximum backward compatibility compatibility, the client MUST <bcp14>MUST</bcp14> implement both TLS negotiation
      on implicit an Implicit TLS port and TLS negotiation using the STARTTLS command on a cleartext port.</t>

      <!--Arnt wrote: 2. Allow servers to be 993-only, and perhaps suggest that this is a good idea
      (IMO that doesn't matter, that kind of suggestion goes unread and ignored in RFCs).
        -->

      <t>
        The server MUST <bcp14>MUST</bcp14> implement TLS negotiation on implicit an Implicit TLS port.
        The server SHOULD <bcp14>SHOULD</bcp14> also implement IMAP on a cleartext port.
        If the server listens on a cleartext port, it MUST <bcp14>MUST</bcp14> allow the STARTTLS command on it.
        </t>
        <t>
      Some site/firewall maintainers insist on TLS site-wide and prefer not to rely
      on a configuration option in each higher-level protocol. For this reason, IMAP4rev2 clients
      SHOULD
      <bcp14>SHOULD</bcp14> try both ports 993 and 143 (and both IPv4 and IPv6) concurrently by default,
      unless overridden by either user configuration or DNS SRV records <xref target='RFC6186'/>. target="RFC6186" format="default"/>.
      A good algorithm for implementing such concurrent connect is described in <xref target='RFC8305'/>. target="RFC8305" format="default"/>.
        </t>
      </section>
      <section title='Client handling numbered="true" toc="default">
        <name>Client Handling of unsolicited responses not suitable Unsolicited Responses Not Suitable for the current connection state'>

       <!--Arnt wrote: 3. Add security considerations suggesting that clients discard most
       kinds of responses that they receive before successful login.
         --> Current Connection State</name>

      <t>
      Cleartext mail transmission (whether caused by firewall configuration errors that result
      in TLS stripping or weak security policies in email clients that choose not to negotiate
      TLS in the first place) can enable injection of responses that can confuse or
      even cause crashes in email clients. The following measures are recommended to
      minimize damage from them.

        <list>

          <t>
          See
      </t>

          <ul spacing="normal">
          <li>See <xref target='preauth-resp'/> target="preauth-resp" format="default"/> for special security considerations related to the PREAUTH response.
          </t>

          <t>
          Many response.</li>

          <li>Many server responses and response codes are only meaningful in authenticated or even selected state.
          However, nothing prevents a server (or an on-path attacker)
          from sending such invalid responses in cleartext before STARTTLS/AUTHENTICATE commands are issued.
          Before authentication authentication, clients SHOULD <bcp14>SHOULD</bcp14> ignore any responses other than CAPABILITY
          and server status responses (<xref target='server-status-responses'/>), target="server-status-responses" format="default"/>),
          as well as any response codes other than CAPABILITY.
          (In particular, some email clients are known to incorrectly process LIST responses
          received before authentication.)
       <!--///Alexey: this also need to mention mailbox state response codes before mailbox selection authentication, or authentication!--> FETCH responses when no mailbox is selected.)
          Clients SHOULD <bcp14>SHOULD</bcp14> ignore the ALERT response code until after TLS
          (whether using STARTTLS or TLS negotiation on implicit an Implicit TLS port)
          or a SASL security layer with confidentiality protection has been successfully negotiated.
          Unless explicitly allowed by an IMAP extension, when not in selected state state,
          clients MUST <bcp14>MUST</bcp14> ignore responses/response responses / response codes related to message and mailbox status
          such as FLAGS, EXIST, EXPUNGE EXPUNGE, and FETCH.
          </t>

        </list>
      </t>
        </li></ul>

      </section>
      <section title='COPYUID numbered="true" toc="default">
        <name>COPYUID and APPENDUID response codes'> Response Codes</name>
        <t>
        The COPYUID and APPENDUID response codes return information about the
        mailbox, which may be considered sensitive if the mailbox has
        permissions set that permit the client to COPY or APPEND to the
        mailbox, but not SELECT or EXAMINE it.
        </t>
        <t>
        Consequently, these response codes SHOULD NOT <bcp14>SHOULD NOT</bcp14> be issued if the client
        does not have access to SELECT or EXAMINE the mailbox.
        </t>
      </section>
      <section title="LIST command numbered="true" toc="default">
        <name>LIST Command and Other Users' namespace"> Namespace</name>
        <t>
        In response to a LIST command containing an argument of the Other
        Users' Namespace prefix, a server SHOULD NOT <bcp14>MUST NOT</bcp14> list users that have not
        granted list access to their personal mailboxes to the currently
        authenticated user. Providing such a list, list could compromise security
        by potentially disclosing confidential information of who is located
        on the server, server or providing a starting point of for a list of user
        accounts to attack.
        </t>
      </section>
      <section title='Use numbered="true" toc="default">
        <name>Use of MD5'> MD5</name>
        <t>
         The BODYSTRUCTURE FETCH Data data item can contain a the MD5 digest of the
         message body in the "body MD5" field (body-fld-md5 ABNF production).
         While MD5 is no longer considered a secure cryptographic hash <xref target='RFC6151'/>, target="RFC6151" format="default"/>,
         this field is used solely to expose the value of the Content-MD5 header field
         (if present in the original message), which is just a message
         integrity check and is not used for cryptographic purposes.
         Also note that other mechanisms that provide message integrity checks
         were defined since RFC 1864 <xref target="RFC1864" format="default"/> was published and are now more commonly
         used than Content-MD5.
	 Two such mechanisms are
         the DKIM-Signature <xref target='RFC6376'/> header field <xref target="RFC6376" format="default"/> and
        S/MIME signing <xref target='RFC8550'/><xref target='RFC8550'/>. target="RFC8550" format="default"/> <xref target="RFC8551"/>.
        </t>
      </section>
      <section title='Other numbered="true" toc="default">
        <name>Other Security Considerations'> Considerations</name>
        <t>
   A server error message for an AUTHENTICATE command which that fails due to
   invalid credentials SHOULD NOT <bcp14>SHOULD NOT</bcp14> detail why the credentials are
   invalid.
        </t>
        <t>
   Use of the LOGIN command sends passwords in the clear.  This can be
   avoided by using the AUTHENTICATE command with a <xref target='SASL'/> target="RFC4422" format="default"/> mechanism
   that does not use plaintext passwords, by first negotiating
   encryption via STARTTLS or some other protection mechanism.
        </t>
        <t>
   A server implementation MUST <bcp14>MUST</bcp14> implement a configuration that, at the
	time of authentication, requires:<vspace/>
   &nbsp;&nbsp;&nbsp;(1) The requires:</t>

   <ol spacing="compact" type="1">
     <li><t>The STARTTLS command has been negotiated or TLS negotiated on implicit an Implicit TLS port.<vspace/>
   OR<vspace/>
   &nbsp;&nbsp;&nbsp;(2) Some port</t>
<t>
     OR</t></li>

   <li><t>Some other mechanism that protects the session from password
   snooping has been provided.<vspace/>
   OR<vspace/>
   &nbsp;&nbsp;&nbsp;(3) The provided</t>
<t>
   OR
</t></li>
      <li><t>The following measures are in place:<vspace/>
   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(a) The place:</t>

   <ol spacing="compact" type="%c)">
     <li><t>The LOGINDISABLED capability is advertised, and <xref target='SASL'/> target="RFC4422" format="default"/> mechanisms
   (such as PLAIN) using plaintext passwords are NOT advertised in the
   CAPABILITY list.<vspace/>
      AND<vspace/>
   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(b) The list.</t>
<t>

     AND</t></li>

   <li><t>The LOGIN command returns an error even if the password is
         correct.<vspace/>
      AND<vspace/>
   &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(c) The
   correct</t>
<t>
   AND</t></li>

   <li><t>The AUTHENTICATE command returns an error with all <xref target='SASL'/> target="RFC4422" format="default"/>
         mechanisms that use plaintext passwords, even if the password
         is correct.
   </t> correct.</t>
       </li></ol></li></ol>

        <t>
   A server error message for a failing LOGIN command SHOULD NOT <bcp14>SHOULD NOT</bcp14> specify
   that the user name, as opposed to the password, is invalid.
        </t>
        <t>
   A server SHOULD <bcp14>SHOULD</bcp14> have mechanisms in place to limit or delay failed
   AUTHENTICATE/LOGIN attempts.
        </t>
        <t>
   A server SHOULD <bcp14>SHOULD</bcp14> report any authentication failure and analyze
   such authentication failure attempt attempts with regard to a password
   brute force
   brute-force attack as well as a password spraying attack.
<!--RFC Editor: can we add an informative reference for password spraying above?
One example is
https://www.ncsc.gov.uk/blog-post/spray-you-spray-me-defending-against-password-spraying-attacks
but it might not be the best one.
-->
   <!--Note that the following MUST is conditional on the previous SHOULD.--> attack <xref target="NCSC"/>.
   Accounts with passwords that match well known well-known passwords from spraying attacks
   MUST
   <bcp14>MUST</bcp14> be blocked blocked, and users associated with such accounts must be requested to change
   their passwords. Only a password with significant strength SHOULD <bcp14>SHOULD</bcp14> be accepted.
        </t>
        <t>
	  Additional security considerations are discussed in the section
   discussing sections that define the AUTHENTICATE (see <xref target='authenticate'/>) and LOGIN commands (see Sections <xref target='login'/>) commands. target="authenticate" format="counter"/> and <xref target="login" format="counter"/>, respectively).
        </t>
      </section>
    </section>
    <section title='IANA Considerations'> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>IANA is requested to update has updated the "Service Names and Transport Protocol Port Numbers" registry as follows:
     <list style='numbers'>
         <t>Registration
      </t>
      <ol spacing="normal" type="1"><li>Registration for TCP port 143 and the corresponding "imap" service name should be have been updated to point to this document and RFC 3501.</t>

         <t>Registration <xref target="RFC3501" format="default"/>.</li>
        <li>Registration for TCP port 993 and the corresponding "imaps" service name should be have been updated to point to this document, RFC 8314 <xref target="RFC8314" format="default"/>, and RFC 3501.</t>

         <t>Both UDP port <xref target="RFC3501" format="default"/>.</li>
        <li>UDP ports 143 and UDP port 993 should be have both been marked as "Reserved" in the registry.</t>

<!--What about the following:
     imap2			Interim Mail Access Protocol version 2
    ?
  -->

     </list>
     </t> registry.</li>
      </ol>
      <t>Additional IANA actions are specified in subsection of this section.</t> the subsections that follow.</t>
      <section title='Updates numbered="true" toc="default">
        <name>Updates to IMAP4 IMAP Capabilities registry'> Registry</name>
        <t>
   IMAP4 capabilities are registered by publishing a standards track Standards Track or
   IESG approved informational
   IESG-approved Informational or experimental Experimental RFC.  The registry is currently located
   at:

        https://www.iana.org/assignments/imap4-capabilities &lt;https://www.iana.org/assignments/imap4-capabilities&gt;
        </t>
        <t>
   As this specification revises the AUTH= prefix, STARTTLS STARTTLS, and LOGINDISABLED
   extensions, IANA is requested to update has updated registry entries for these 3 extensions
   to point to this document and RFC 3501. <xref target="RFC3501" format="default"/>.
        </t>
      </section>
      <section title='GSSAPI/SASL service name'> numbered="true" toc="default">
        <name>GSSAPI/SASL Service Name</name>
        <t>GSSAPI/Kerberos/SASL service names are registered by publishing a
       standards track
       Standards Track or IESG approved experimental IESG-approved Experimental RFC.  The registry
       is currently located at:

       https://www.iana.org/assignments/gssapi-service-names &lt;https://www.iana.org/assignments/gssapi-service-names&gt;
        </t>
        <t>
       IANA is requested to update has updated the "imap" service name previously
       registered in RFC 3501, <xref target="RFC3501" format="default"/> to point to both this document and RFC 3501. <xref target="RFC3501" format="default"/>.
        </t>
      </section>
      <section title='LIST numbered="true" toc="default">
        <name>LIST Selection Options, LIST Return Options, and LIST extended data items'> Extended Data Items</name>
        <t>
       <xref target="RFC5258"/> target="RFC5258" format="default"/> specifies IANA registration procedures for
       LIST Selection Options, selection options, LIST Return Options, return options, and LIST extended data items.
       This document doesn't change these registration procedures.
       In particular particular, LIST selection options (<xref target='list-select-options'/>) target="list-select-options" format="default"/>)
       and LIST return options (<xref target='list-return-options'/>) target="list-return-options" format="default"/>) are registered
       using the procedure specified in Section 9 of <xref target="RFC5258"/> target="RFC5258" sectionFormat="of" section="9"/>
       (and using the registration template from Section 9.3 of <xref target="RFC5258"/>). target="RFC5258" sectionFormat="of" section="9.3"/>).
       LIST Extended Data Items extended data items are registered using the registration template from Section
       9.6 of
       <xref target="RFC5258"/>). target="RFC5258" sectionFormat="of" section="9.6"/>).
        </t>
        <t>IANA is requested to add has added a reference to [RFCXXXX] RFC 9051 for the "OLDNAME"
       LIST-EXTENDED extended data item entry. This is in addition to
       the existing reference to <xref target="RFC5465"/>.</t> target="RFC5465" format="default"/>.</t>
      </section>
      <section title='IMAP numbered="true" toc="default">
        <name>IMAP Mailbox Name Attributes and IMAP Response Codes'> Codes</name>
        <t>
       IANA is requested to update has updated the "IMAP Mailbox Name Attributes" registry
       to point to this document in addition to RFC 3501. <xref target="RFC3501" format="default"/>.
        </t>
        <t>
       IANA is requested to update has updated the "IMAP Response Codes" registry
       to point to this document in addition to RFC 3501.
       </t>

     </section>

   </section>

     </middle>
     <back>
       <references title='Normative References'>

<!--///Explanatory text can't be accomodated by xml2rfc format. Hacks required.
         <t>
         The following documents contain definitions or specifications that
         are necessary to understand this document properly:
         </t>
-->
<?rfc include="reference.RFC.4752"?> <!-- Kerberos GSSAPI SASL mechanism. -->
<?rfc include="reference.RFC.5258"?> <!-- List Extended. This reference is only normative due to IANA registration procedure. -->
<?rfc include="reference.RFC.5788"?> <!-- IMAP/JMAP Keyword registry -->

<reference anchor="ABNF" target="https://www.rfc-editor.org/info/rfc5234">
<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author initials="D." surname="Crocker" fullname="D. Crocker" role="editor">
<organization/>
</author>
<author initials="P." surname="Overell" fullname="P. Overell">
<organization/>
</author>
<date year="2008" month="January"/>
</front>
<seriesInfo name="STD" value="68"/>
<seriesInfo name="RFC" value="5234"/>
<format type="ASCII" octets="26359"/>
</reference>

<reference anchor="CHARSET" target="https://www.rfc-editor.org/info/rfc2978">
<front>
<title>IANA Charset Registration Procedures</title>
<author initials="N." surname="Freed" fullname="N. Freed">
<organization/>
</author>
<author initials="J." surname="Postel" fullname="J. Postel">
<organization/>
</author>
<date year="2000" month="October"/>
</front>
<seriesInfo name="BCP" value="19"/>
<seriesInfo name="RFC" value="2978"/>
<format type="ASCII" octets="21615"/>
</reference>

<reference anchor="SCRAM-SHA-256" target="https://www.rfc-editor.org/info/rfc7677">
<front>
<title>
SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple Authentication and Security Layer (SASL) Mechanisms
</title>
<author initials="T." surname="Hansen" fullname="T. Hansen">
<organization/>
</author>
<date year="2015" month="November"/>
<abstract>
<t>
This document registers the Simple Authentication and Security Layer (SASL) mechanisms SCRAM-SHA-256 and SCRAM-SHA-256-PLUS, provides guidance for secure implementation of the original SCRAM-SHA-1-PLUS mechanism, and updates the SCRAM registration procedures of RFC 5802.
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7677"/>
<seriesInfo name="DOI" value="10.17487/RFC7677"/>
</reference>

<reference anchor="DISPOSITION" target="https://www.rfc-editor.org/info/rfc2183">
<front>
<title>
Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field
</title>
<author initials="R." surname="Troost" fullname="R. Troost">
<organization/>
</author>
<author initials="S." surname="Dorner" fullname="S. Dorner">
<organization/>
</author>
<author initials="K." surname="Moore" fullname="K. Moore" role="editor">
<organization/>
</author>
<date year="1997" month="August"/>
</front>
<seriesInfo name="RFC" value="2183"/>
<format type="ASCII" octets="23150"/>
</reference>

<reference anchor="PLAIN" target="https://www.rfc-editor.org/info/rfc4616">
<front>
<title>
The PLAIN Simple Authentication and Security Layer (SASL) Mechanism
</title>
<author initials="K." surname="Zeilenga" fullname="K. Zeilenga" role="editor">
<organization/>
</author>
<date year="2006" month="August"/>
</front>
<seriesInfo name="RFC" value="4616"/>
<format type="ASCII" octets="20270"/>
</reference>

<?rfc include="reference.RFC.2119"?> <!-- Key Words (BCP 14) -->
<?rfc include="reference.RFC.8174"?> <!-- 2119 update (BCP 14) -->

<reference anchor="LANGUAGE-TAGS" target="https://www.rfc-editor.org/info/rfc3282">
<front>
<title>Content Language Headers</title>
<author initials="H." surname="Alvestrand" fullname="H. Alvestrand">
<organization/>
</author>
<date year="2002" month="May"/>
</front>
<seriesInfo name="RFC" value="3282"/>
<format type="ASCII" octets="14022"/>
</reference>

 <!--[LANGUAGE-TAGS] BCP 47-->

<!--
<reference anchor="LANGUAGE-TAGS" target="https://www.rfc-editor.org/info/rfc5646">
<front>
<title>Tags for Identifying Languages</title>
<author initials="A." surname="Phillips" fullname="A. Phillips" role="editor">
<organization/>
</author>
<author initials="M." surname="Davis" fullname="M. Davis" role="editor">
<organization/>
</author>
<date year="2009" month="September"/>
</front>
<seriesInfo name="BCP" value="47"/>
<seriesInfo name="RFC" value="5646"/>
<format type="ASCII" octets="208592"/>
</reference>
-->

<reference anchor="LOCATION" target="https://www.rfc-editor.org/info/rfc2557">
<front>
<title>
MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)
</title>
<author initials="J." surname="Palme" fullname="J. Palme">
<organization/>
</author>
<author initials="A." surname="Hopmann" fullname="A. Hopmann">
<organization/>
</author>
<author initials="N." surname="Shelness" fullname="N. Shelness">
<organization/>
</author>
<date year="1999" month="March"/>
</front>
<seriesInfo name="RFC" value="2557"/>
<format type="ASCII" octets="61854"/>
</reference>

<reference anchor="MD5" target="https://www.rfc-editor.org/info/rfc1864">
<front>
<title>The Content-MD5 Header Field</title>
<author initials="J." surname="Myers" fullname="J. Myers">
<organization/>
</author>
<author initials="M." surname="Rose" fullname="M. Rose">
<organization/>
</author>
<date year="1995" month="October"/>
</front>
<seriesInfo name="RFC" value="1864"/>
<format type="ASCII" octets="7216"/>
</reference>

<reference anchor="MIME-HDRS" target="https://www.rfc-editor.org/info/rfc2047">
<front>
<title>
MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text
</title>
<author initials="K." surname="Moore" fullname="K. Moore">
<organization/>
</author>
<date year="1996" month="November"/>
</front>
<seriesInfo name="RFC" value="2047"/>
<format type="ASCII" octets="33262"/>
</reference>

<reference anchor="MIME-IMB" target="https://www.rfc-editor.org/info/rfc2045">
<front>
<title>
Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies
</title>
<author initials="N." surname="Freed" fullname="N. Freed">
<organization/>
</author>
<author initials="N." surname="Borenstein" fullname="N. Borenstein">
<organization/>
</author>
<date year="1996" month="November"/>
</front>
<seriesInfo name="RFC" value="2045"/>
<format type="ASCII" octets="72932"/>
</reference>

<reference anchor="MIME-IMT" target="https://www.rfc-editor.org/info/rfc2046">
<front>
<title>
Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types
</title>
<author initials="N." surname="Freed" fullname="N. Freed">
<organization/>
</author>
<author initials="N." surname="Borenstein" fullname="N. Borenstein">
<organization/>
</author>
<date year="1996" month="November"/>
</front>
<seriesInfo name="RFC" value="2046"/>
<format type="ASCII" octets="105854"/>
</reference>

<reference anchor="RFC2231" target="https://www.rfc-editor.org/info/rfc2231">
  <front>
    <title>
      MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations
    </title>
    <author initials="N." surname="Freed" fullname="N. Freed">
      <organization/>
    </author>
    <author initials="K." surname="Moore" fullname="K. Moore">
      <organization/>
    </author>
    <date year="1997" month="November"/>
    <abstract>
      <t>
        This memo defines extensions to the RFC 2045 media type and RFC 2183 disposition parameter value mechanisms. This memo also defines an extension to the encoded words defined in RFC 2047 to allow the specification of the language to be used for display as well as the character set. [STANDARDS-TRACK]
      </t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="2231"/>
  <seriesInfo name="DOI" value="10.17487/RFC2231"/>
</reference>

<reference anchor="RFC-5322" target="https://www.rfc-editor.org/info/rfc5322">
<front>
<title>Internet Message Format</title>
<author initials="P." surname="Resnick" fullname="P. Resnick" role="editor">
<organization/>
</author>
<date year="2008" month="October"/>
</front>
<seriesInfo name="RFC" value="5322"/>
<format type="ASCII" octets="122322"/>
</reference>

<reference anchor="SASL" target="https://www.rfc-editor.org/info/rfc4422">
<front>
<title>Simple Authentication and Security Layer (SASL)</title>
<author initials="A." surname="Melnikov" fullname="A. Melnikov" role="editor">
<organization/>
</author>
<author initials="K." surname="Zeilenga" fullname="K. Zeilenga" role="editor">
<organization/>
</author>
<date year="2006" month="June"/>
</front>
<seriesInfo name="RFC" value="4422"/>
<format type="ASCII" octets="73206"/>
</reference>

<reference anchor="TLS-1.2" target="https://www.rfc-editor.org/info/rfc5246">
<front>
<title>
The Transport Layer Security (TLS) Protocol Version 1.2
</title>
<author initials="T." surname="Dierks" fullname="T. Dierks">
<organization/>
</author>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization/>
</author>
<date year="2008" month="August"/>
</front>
<seriesInfo name="RFC" value="5246"/>
<format type="ASCII" octets="222395"/>
</reference>

<reference anchor="TLS-1.3" target="https://www.rfc-editor.org/info/rfc8446">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization/>
</author>
<date year="2018" month="August"/>
<abstract>
<t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>

<reference anchor="UTF-7" target="https://www.rfc-editor.org/info/rfc2152">
<front>
<title>UTF-7 A Mail-Safe Transformation Format of Unicode</title>
<author initials="D." surname="Goldsmith" fullname="D. Goldsmith">
<organization/>
</author>
<author initials="M." surname="Davis" fullname="M. Davis">
<organization/>
</author>
<date year="1997" month="May"/>
</front>
<seriesInfo name="RFC" value="2152"/>
<format type="ASCII" octets="28065"/>
</reference>

<reference  anchor='UTF-8' target='https://www.rfc-editor.org/info/rfc3629'>
<front>
<title>UTF-8, a transformation format of ISO 10646</title>
<author initials='F.' surname='Yergeau' fullname='F. Yergeau'><organization /></author>
<date year='2003' month='November' />
<abstract><t>ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems.  The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo.  UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values.  This memo obsoletes and replaces RFC 2279.</t></abstract>
</front>
<seriesInfo name='STD' value='63'/>
<seriesInfo name='RFC' value='3629'/>
<seriesInfo name='DOI' value='10.17487/RFC3629'/>
</reference>

<reference anchor="MULTIAPPEND" target="https://www.rfc-editor.org/info/rfc3502">
  <front>
    <title>
      Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension
    </title>
    <author initials="M." surname="Crispin" fullname="M. Crispin">
      <organization/>
    </author>
    <date year="2003" month="March"/>
  </front>
  <seriesInfo name="RFC" value="3502"/>
  <format type="ASCII" octets="13379"/>
</reference>

<reference anchor="NET-UNICODE" target="https://www.rfc-editor.org/info/rfc5198">
<front>
<title>Unicode Format for Network Interchange</title>
<author initials="J." surname="Klensin" fullname="J. Klensin">
<organization/>
</author>
<author initials="M." surname="Padlipsky" fullname="M. Padlipsky">
<organization/>
</author>
<date year="2008" month="March"/>
<abstract>
<t>
The Internet today is in need of a standardized form for the transmission of internationalized "text" information, paralleling the specifications for the use of ASCII that date from the early days of the ARPANET. This document specifies that format, using UTF-8 with normalization and specific line-ending sequences. [STANDARDS-TRACK]
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5198"/>
<seriesInfo name="DOI" value="10.17487/RFC5198"/>
</reference>

<reference anchor="I18N-HDRS" target="https://www.rfc-editor.org/info/rfc6532">
<front>
<title>Internationalized Email Headers</title>
<author initials="A." surname="Yang" fullname="A. Yang">
<organization/>
</author>
<author initials="S." surname="Steele" fullname="S. Steele">
<organization/>
</author>
<author initials="N." surname="Freed" fullname="N. Freed">
<organization/>
</author>
<date year="2012" month="February"/>
<abstract>
<t>
Internet mail was originally limited to 7-bit ASCII. MIME added support for the use of 8-bit character sets in body parts, and also defined an encoded-word construct so other character sets could be used in certain header field values. However, full internationalization of electronic mail requires additional enhancements to allow the use of Unicode, including characters outside the ASCII repertoire, in mail addresses as well as direct use of Unicode in header fields like "From:", "To:", and "Subject:", without requiring the use of complex encoded-word constructs. This document specifies an enhancement to the Internet Message Format and to MIME that allows use of Unicode in mail addresses and most header field content.
</t>
<t>
This specification updates Section 6.4 of RFC 2045 to eliminate the restriction prohibiting the use of non-identity content-transfer- encodings on subtypes of "message/". [STANDARDS-TRACK]
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6532"/>
<seriesInfo name="DOI" value="10.17487/RFC6532"/>
</reference>

<?rfc include="reference.RFC.3503"?> <!-- $MDNSent -->
<?rfc include="reference.RFC.4648"?> <!-- BASE64 -->
<?rfc include="reference.RFC.7525"?> <!-- Recommendations for Secure Use of TLS and DTLS -->
<?rfc include="reference.RFC.7817"?> <!-- Email TLS server identity verification procedure. -->
<?rfc include="reference.RFC.8098"?> <!-- MDN -->
<?rfc include="reference.RFC.8314"?> <!-- Updated TLS use in Email recommendations. -->

<!--///Explanatory text can't be accomodated by xml2rfc format. Hacks required.
         <t>The following documents describe quality-of-implementation issues
         that should be carefully considered when implementing this protocol:</t>
-->

<reference anchor="IMAP-IMPLEMENTATION" target="https://www.rfc-editor.org/info/rfc2683">
<front>
<title>IMAP4 Implementation Recommendations</title>
<author initials="B." surname="Leiba" fullname="B. Leiba">
<organization/>
</author>
<date year="1999" month="September"/>
</front>
<seriesInfo name="RFC" value="2683"/>
<format type="ASCII" octets="56300"/>
</reference>

<reference anchor="IMAP-MULTIACCESS" target="https://www.rfc-editor.org/info/rfc2180">
<front>
<title>IMAP4 Multi-Accessed Mailbox Practice</title>
<author initials="M." surname="Gahrns" fullname="M. Gahrns">
<organization/>
</author>
<date year="1997" month="July"/>
</front>
<seriesInfo name="RFC" value="2180"/>
<format type="ASCII" octets="24750"/>
</reference>

       </references>

       <references title='Informative References (related protocols)'>

<!--///
         <t>
         The following documents describe related protocols:
         </t>
-->

<reference anchor="CERT-555316" target="https://www.kb.cert.org/vuls/id/555316">
<front>
<title>
  Vulnerability Note VU#555316: STARTTLS plaintext command injection vulnerability
</title>
<author fullname="CERT">
<organization>Carnegie Mellon University Software Engineering Institute</organization>
</author>
<date year="2011" month="September"/>
</front>
</reference>

<?rfc include="reference.RFC.6151"?> <!-- Updated Security Considerations for MD5 -->

<?rfc include="reference.RFC.2193"?> <!-- Referrals -->
<?rfc include="reference.RFC.3348"?> <!-- Child mailboxes -->
<?rfc include="reference.RFC.5256"?> <!-- SORT and THREAD -->
<?rfc include="reference.RFC.5465"?> <!-- IMAP NOTIFY extension -->
<?rfc include="reference.RFC.6186"?> <!-- Use of SRV Records for Locating Email Submission/Access Services -->
<?rfc include="reference.RFC.7162"?> <!-- CONDSTORE/QRESYNC -->
<?rfc include="reference.RFC.7888"?> <!-- LITERAL+ and LITERAL- -->
<?rfc include="reference.RFC.8474"?> <!-- OBJECTID -->

<reference anchor="IMAP-DISC" target="https://www.rfc-editor.org/info/rfc4549">
<front>
<title>
Synchronization Operations for Disconnected IMAP4 Clients
</title>
<author initials="A." surname="Melnikov" fullname="A. Melnikov" role="editor">
<organization/>
</author>
<date year="2006" month="June"/>
</front>
<seriesInfo name="RFC" value="4549"/>
<format type="ASCII" octets="75417"/>
</reference>

<reference  anchor='IMAP-I18N' target='https://www.rfc-editor.org/info/rfc5255'>
<front>
<title>Internet Message Access Protocol Internationalization</title>
<author initials='C.' surname='Newman' fullname='C. Newman'><organization /></author>
<author initials='A.' surname='Gulbrandsen' fullname='A. Gulbrandsen'><organization /></author>
<author initials='A.' surname='Melnikov' fullname='A. Melnikov'><organization /></author>
<date year='2008' month='June' />
<abstract><t>Internet Message Access Protocol (IMAP) version 4rev1 has basic support for non-ASCII characters in mailbox names and search substrings.  It also supports non-ASCII message headers and content encoded as specified by Multipurpose Internet Mail Extensions (MIME).  This specification defines a collection of IMAP extensions that improve international support including language negotiation for  international error text, translations for namespace prefixes, and  comparator negotiation for search, sort, and thread.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5255'/>
<seriesInfo name='DOI' value='10.17487/RFC5255'/>
</reference>

<reference anchor="IMAP-MODEL" target="https://www.rfc-editor.org/info/rfc1733">
<front>
<title>Distributed Electronic Mail Models in IMAP4</title>
<author initials="M." surname="Crispin" fullname="M. Crispin">
<organization/>
</author>
<date year="1994" month="December"/>
</front>
<seriesInfo name="RFC" value="1733"/>
<format type="ASCII" octets="6205"/>
</reference>

<reference  anchor='IMAP-UTF-8' target='https://www.rfc-editor.org/info/rfc6855'>
<front>
<title>IMAP Support for UTF-8</title>
<author initials='P.' surname='Resnick' fullname='P. Resnick' role='editor'><organization /></author>
<author initials='C.' surname='Newman' fullname='C. Newman' role='editor'><organization /></author>
<author initials='S.' surname='Shen' fullname='S. Shen' role='editor'><organization /></author>
<date year='2013' month='March' />
<abstract><t>This specification extends the Internet Message Access Protocol (IMAP) to support UTF-8 encoded international characters in user names, mail addresses, and message headers. This specification replaces RFC 5738.</t></abstract>
</front>
<seriesInfo name='RFC' value='6855'/>
<seriesInfo name='DOI' value='10.17487/RFC6855'/>
</reference>

<reference anchor="ANONYMOUS" target="https://www.rfc-editor.org/info/rfc4505">
<front>
<title>
Anonymous Simple Authentication and Security Layer (SASL) Mechanism
</title>
<author initials="K." surname="Zeilenga" fullname="K. Zeilenga">
<organization/>
</author>
<date year="2006" month="June"/>
</front>
<seriesInfo name="RFC" value="4505"/>
<format type="ASCII" octets="16599"/>
</reference>

<!--
<reference anchor="ACAP" target="https://www.rfc-editor.org/info/rfc2244">
<front>
<title>ACAP &dash;- Application Configuration Access Protocol</title>
<author initials="C." surname="Newman" fullname="C. Newman">
<organization/>
</author>
<author initials="J." surname="G. Myers" fullname="J. G. Myers">
<organization/>
</author>
<date year="1997" month="November"/>
</front>
<seriesInfo name="RFC" value="2244"/>
<format type="ASCII" octets="154610"/>
</reference>
-->

<reference anchor="SMTP" target="https://www.rfc-editor.org/info/rfc5321">
<front>
<title>Simple Mail Transfer Protocol</title>
<author initials="J." surname="Klensin" fullname="J. Klensin">
<organization/>
</author>
<date year="2008" month="October"/>
</front>
<seriesInfo name="RFC" value="5321"/>
<format type="ASCII" octets="225929"/>
</reference>

<reference anchor="RFC3516" target="https://www.rfc-editor.org/info/rfc3516">
<front>
<title>IMAP4 Binary Content Extension</title>
<author initials="L." surname="Nerenberg" fullname="L. Nerenberg">
<organization/>
</author>
<date year="2003" month="April"/>
<abstract>
<t>
This memo defines the Binary extension to the Internet Message Access Protocol (IMAP4). It provides a mechanism for IMAP4 clients and servers to exchange message body data without using a MIME content-transfer- encoding. [STANDARDS-TRACK]
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3516"/>
<seriesInfo name="DOI" value="10.17487/RFC3516"/>
</reference>

<reference anchor="RFC4314" target="https://www.rfc-editor.org/info/rfc4314">
  <front>
    <title>IMAP4 Access Control List (ACL) Extension</title>
    <author initials="A." surname="Melnikov" fullname="A. Melnikov">
      <organization/>
    </author>
    <date year="2005" month="December"/>
  </front>
  <seriesInfo name="RFC" value="4314"/>
  <format type="ASCII" octets="56599"/>
</reference>

<reference anchor="RFC2087" target="https://www.rfc-editor.org/info/rfc2087">
  <front>
    <title>IMAP4 QUOTA extension</title>
    <author initials="J." surname="Myers" fullname="J. Myers">
      <organization/>
    </author>
    <date year="1997" month="January"/>
  </front>
  <seriesInfo name="RFC" value="2087"/>
  <format type="ASCII" octets="8542"/>
</reference>

<reference anchor="IMAP-URL" target="https://www.rfc-editor.org/info/rfc5092">
  <front>
    <title>IMAP URL Scheme</title>
    <author initials="A." surname="Melnikov" fullname="A. Melnikov" role="editor">
      <organization/>
    </author>
    <author initials="C." surname="Newman" fullname="C. Newman">
      <organization/>
    </author>
    <date year="2007" month="November"/>
    <abstract>
      <t>
        IMAP (RFC 3501) is a rich protocol for accessing remote message stores. It provides an ideal mechanism for accessing public mailing list archives as well as private and shared message stores. This document defines a URL scheme for referencing objects on an IMAP server.
      </t>
      <t>
        This document obsoletes RFC 2192. It also updates RFC 4467. [STANDARDS-TRACK]
      </t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="5092"/>
  <seriesInfo name="DOI" value="10.17487/RFC5092"/>
  <format type="ASCII" octets="65197"/>
</reference>

<?rfc include="reference.RFC.8305"?> <!-- Happy Eyeballs v2 -->

<?rfc include="reference.RFC.6376"?> <!-- DKIM -->

<?rfc include="reference.RFC.8550"?> <!-- S/MIME 4.0: Certificate Handling -->
<?rfc include="reference.RFC.8551"?> <!-- S/MIME 4.0: Message Specification -->

<reference anchor="IMAP-KEYWORDS-REG" target="https://www.iana.org/assignments/imap-jmap-keywords/imap-jmap-keywords.xhtml">
<front>
<title>
IMAP and JMAP Keywords
</title>

<author fullname="IANA">
<organization/>
</author>

<!--Used registry creation date-->
<date year="2009" month="December"/>
</front>
</reference>

<reference anchor="IMAP-MAILBOX-NAME-ATTRS-REG" target="https://www.iana.org/assignments/imap-mailbox-name-attributes/imap-mailbox-name-attributes.xhtml">
<front>
<title>
IMAP Mailbox Name Attributes
</title>

<author fullname="IANA">
<organization/>
</author>

<!--Used registry creation date: 2018-06-14-->
<date year="2018" month="June"/>
</front>
</reference>

<reference anchor="CHARSET-REG" target="https://www.iana.org/assignments/charset-reg/charset-reg.xhtml">
<front>
<title>
Character Set Registrations
</title>

<author fullname="IANA">
<organization/>
</author>

<!--Used last updated at the time of editing: 2015-05-11-->
<date year="2015" month="May"/>
</front>
</reference>

       </references>

       <references title='Informative References (historical aspects of IMAP and related protocols)'>

<!--///
         <t>The following documents are historical or describe historical aspects
         of to this protocol:</t>
-->

<?rfc include="reference.RFC.3501"?> <!-- IMAP4rev1 -->

<reference anchor="IMAP-COMPAT" target="https://www.rfc-editor.org/info/rfc2061">
<front>
<title>IMAP4 Compatibility with IMAP2bis</title>
<author initials="M." surname="Crispin" fullname="M. Crispin">
<organization/>
</author>
<date year="1996" month="December"/>
</front>
<seriesInfo name="RFC" value="2061"/>
<format type="ASCII" octets="5867"/>
</reference> document in addition to <xref target="RFC3501" format="default"/>.
        </t>
      </section>
    </section>
  </middle>
  <back>

<displayreference target="RFC2045" to="MIME-IMB"/>
<displayreference target="RFC8446" to="TLS-1.3"/>
<displayreference target="RFC4422" to="SASL"/>
<displayreference target="RFC5321" to="SMTP"/>
<displayreference target="RFC2978" to="CHARSET"/>
<displayreference target="RFC4616" to="PLAIN"/>
<displayreference target="RFC2557" to="LOCATION"/>
<displayreference target="RFC4549" to="IMAP-DISC"/>
<displayreference target="RFC2595" to="IMAP-TLS"/>
<displayreference target="RFC1733" to="IMAP-MODEL"/>
<displayreference target="RFC5198" to="NET-UNICODE"/>
<displayreference target="RFC2183" to="DISPOSITION"/>
<displayreference target="RFC3502" to="MULTIAPPEND"/>
<displayreference target="RFC2047" to="MIME-HDRS"/>
<displayreference target="RFC5246" to="TLS-1.2"/>
<displayreference target="RFC2180" to="IMAP-MULTIACCESS"/>
<displayreference target="RFC4505" to="ANONYMOUS"/>
<displayreference target="RFC6855" to="IMAP-UTF-8"/>
<displayreference target="RFC3282" to="LANGUAGE-TAGS"/>
<displayreference target="RFC2062" to="IMAP-OBSOLETE"/>
<displayreference target="RFC1176" to="IMAP2"/>
<displayreference target="RFC1732" to="IMAP-HISTORICAL"/>
<displayreference target="RFC3629" to="UTF-8"/>
<displayreference target="RFC5092" to="IMAP-URL"/>
<displayreference target="I-D.ietf-imap-imap2bis" to="IMAP2BIS"/>
<displayreference target="RFC5255" to="IMAP-I18N"/>
<displayreference target="RFC2152" to="UTF-7"/>
<displayreference target="RFC2683" to="IMAP-IMPLEMENTATION"/>
<displayreference target="RFC7677" to="SCRAM-SHA-256"/>
<displayreference target="RFC2061" to="IMAP-COMPAT"/>
<displayreference target="RFC2046" to="MIME-IMT"/>
<displayreference target="RFC5234" to="ABNF"/>
<displayreference target="RFC1864" to="MD5"/>
<displayreference target="RFC0822" to="RFC822"/>
<displayreference target="RFC6532" to="I18N-HDRS"/>
    <references>
      <name>References</name>
      <references>

        <name>Normative References</name>

	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4752.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5258.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5788.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2077.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2978.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7677.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2183.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4616.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3282.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2557.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1864.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2047.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2045.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2046.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2231.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5322.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4422.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2152.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3629.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3502.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5198.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6532.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3503.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7525.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7817.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8081.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8098.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8314.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2683.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2180.xml"/>
	 <referencegroup anchor="BCP178" target="https://www.rfc-editor.org/info/bcp178">
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6648.xml"/>

        </referencegroup>
      </references>

      <references>
        <name>Informative References</name>
	<references>
	  <name>Related Protocols</name>

	  <reference anchor="IMAP-HISTORICAL" target="https://www.rfc-editor.org/info/rfc1732"> anchor="NCSC" target="https://www.ncsc.gov.uk/blog-post/spray-you-spray-me-defending-against-password-spraying-attacks">
          <front>
<title>IMAP4 Compatibility with IMAP2 and IMAP2bis</title>
<author initials="M." surname="Crispin" fullname="M. Crispin">
<organization/>
            <title>Spray you, spray me: defending against password spraying attacks</title>
            <author>
              <organization>NCSC</organization>
            </author>
            <date year="1994" month="December"/> year="2018" month="May"/>
          </front>
<seriesInfo name="RFC" value="1732"/>
<format type="ASCII" octets="9276"/>
        </reference>

	<reference anchor="IMAP2BIS" target="https://www.ietf.org/archive/id/draft-ietf-imap-imap2bis-02.txt"> anchor="CERT-555316" target="https://www.kb.cert.org/vuls/id/555316">
          <front>
<title>INTERACTIVE MAIL ACCESS PROTOCOL - VERSION 2bis</title>
<author initials="M." surname="Crispin" fullname="M. Crispin">
<organization/>
            <title>STARTTLS plaintext command injection vulnerability</title>
            <author>
              <organization>Carnegie Mellon University</organization>
            </author>
            <date year="1993" month="October"/> year="2011" month="September"/>
          </front>
<seriesInfo name="Internet-Draft" value="draft-ietf-imap-imap2bis-02"/>
<format type="ASCII"/>
	  <refcontent>Software Engineering Institute</refcontent>
	  <refcontent>CERT Coordination Center</refcontent>
	  <refcontent>Vulnerability Note VU#555316</refcontent>
        </reference>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6151.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2193.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3348.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5256.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5465.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6186.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7162.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7888.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8474.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4549.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5255.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1733.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6855.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4505.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5321.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3516.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4314.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2087.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5092.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8305.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6376.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8550.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8551.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2177.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2342.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3691.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4315.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4466.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4731.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4959.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5161.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5182.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5530.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5819.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6154.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6409.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6851.xml"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8438.xml"/>

        <reference anchor="IMAP-OBSOLETE" target="https://www.rfc-editor.org/info/rfc2062"> anchor="IMAP-KEYWORDS-REG" target="https://www.iana.org/assignments/imap-jmap-keywords/">
          <front>
<title>Internet Message Access Protocol - Obsolete Syntax</title>
            <title>IMAP and JMAP Keywords</title>
            <author initials="M." surname="Crispin" fullname="M. Crispin"> fullname="IANA">
              <organization/>
            </author>
<date year="1996" month="December"/>
           <date/>
          </front>
<seriesInfo name="RFC" value="2062"/>
<format type="ASCII" octets="14222"/>
        </reference>

        <reference anchor="IMAP2" target="https://www.rfc-editor.org/info/rfc1176"> anchor="IMAP-MAILBOX-NAME-ATTRS-REG" target="https://www.iana.org/assignments/imap-mailbox-name-attributes/">
          <front>
<title>Interactive Mail Access Protocol: Version 2</title>
            <title>IMAP Mailbox Name Attributes</title>
            <author initials="M.R." surname="Crispin" fullname="M.R. Crispin"> fullname="IANA">
              <organization/>
            </author>
<date year="1990" month="August"/>
           <date/>
          </front>
<seriesInfo name="RFC" value="1176"/>
<format type="ASCII" octets="67330"/>
        </reference>

        <reference anchor="RFC-822" target="https://www.rfc-editor.org/info/rfc822"> anchor="CHARSET-REG" target="https://www.iana.org/assignments/charset-reg/">
          <front>
<title>
STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES
</title>
            <title>Character Set Registrations</title>
            <author initials="D." surname="Crocker" fullname="D. Crocker"> fullname="IANA">
              <organization/>
            </author>
<date year="1982" month="August"/>
           <date/>
          </front>
<seriesInfo name="STD" value="11"/>
<seriesInfo name="RFC" value="822"/>
<format type="ASCII" octets="106299"/>
        </reference>

<reference anchor="IMAP-TLS" target="https://www.rfc-editor.org/info/rfc2595">
<front>
<title>Using TLS with IMAP, POP3
      </references>

      <references>
        <name>Historical Aspects of IMAP and ACAP</title>
<author initials="C." surname="Newman" fullname="C. Newman">
<organization/>
</author>
<date year="1999" month="June"/>
</front>
<seriesInfo name="RFC" value="2595"/>
<format type="ASCII" octets="32440"/>
</reference> Related Protocols</name>

	      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1064.xml"/>
	      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1732.xml"/>
	      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1730.xml"/>
	      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2060.xml"/>
              <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2061.xml"/>
	      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3501.xml"/>

	      <!--ietf-imap-imap2bis-02; Expired-->
              <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-imap-imap2bis-02.xml"/>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2062.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1176.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0822.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2595.xml"/>

      </references>
    </references>
  </references>

    <section title='Backward compatibility anchor="IMAP4rev1-compat" numbered="true" toc="default">
      <name>Backward Compatibility with IMAP4rev1' anchor="IMAP4rev1-compat"> IMAP4rev1</name>
      <t>An implementation that wants to remain compatible with IMAP4rev1 can advertise both IMAP4rev1
         and IMAP4rev2 in its CAPABILITY response/response response / response code.
         (Such server implementation is likely to also want to advertise other IMAP4rev1 extensions that
         were folded into IMAP4rev2. See IMAP4rev2; see <xref target="changesFromIMAP4rev1"/>.)
         <!--///Alexey: Is the following statement actually true, considering
             that removed responses are not listed in the ABNF?--> target="changesFromIMAP4rev1" format="default"/>.)
         While some IMAP4rev1 responses were removed in IMAP4rev2,
         their presence will not break IMAP4rev2-only clients.</t>

         <t>If both IMAP4rev1 and IMAP4rev2 are advertised, an IMAP client
         that wants to use IMAP4rev2 MUST <bcp14>MUST</bcp14>
         issue an "ENABLE IMAP4rev2" command.</t>

         <t>When compared to IMAP4rev1, some request data items,
         corresponding response data items, and responses were removed in IMAP4rev2.
         See <xref target="changesFromIMAP4rev1" format="default"/> for more details.
         With the exception of obsolete SEARCH and RECENT responses,
         servers advertising both IMAP4rev1 and IMAP4rev2 would never return
         such removed response data items/responses unless explicitly requested
         by an IMAPrev1 client.
         </t>

         <t>Servers advertising both IMAP4rev1 and IMAP4rev2 MUST NOT <bcp14>MUST NOT</bcp14>
         generate UTF-8 quoted UTF-8-quoted strings unless the client has issued
         "ENABLE IMAP4rev2". Consider implementation of mechanisms
         described or referenced in <xref target="IMAP-UTF-8"/> target="RFC6855" format="default"/> to
         achieve this goal.</t>

         <!--///Alexey: talk about other breaking changes, like SEARCH NEW, ESEARCH response and LSUB removal here?-->

         <t>Servers advertising both IMAP4rev1 and IMAP4rev2, and
         clients intending to be compatible with IMAP4rev1 servers MUST servers, <bcp14>MUST</bcp14>
         be compatible with the international mailbox naming convention Mailbox International Naming Convention
         described in <xref target='mailbox-i18n'/>.</t> target="mailbox-i18n" format="default"/>.</t>

         <t>Also see <xref target="body-part-64bit"/> target="body-part-64bit" format="default"/> for special considerations
         for servers that support 63 bit 63-bit body part/message part / message sizes and want
         to advertise support for both IMAP4rev1 and IMAP4rev2.</t>

      <section title='Mailbox anchor="mailbox-i18n" numbered="true" toc="default">
        <name>Mailbox International Naming Convention for compatibility Compatibility with IMAP4rev1' anchor='mailbox-i18n'> IMAP4rev1</name>
        <t>Support for the Mailbox International Naming Convention described in this section
   is not required for IMAP4rev2-only clients and servers. It is only used for backward
   compatibility with IMAP4rev1 implementations.
        </t>
        <t>
   By convention, international mailbox names in IMAP4rev1 are specified
   using a modified version of the UTF-7 encoding described in <xref target='UTF-7'/>. target="RFC2152" format="default"/>.
   Modified UTF-7 may also be usable in servers that implement an
   earlier version of this protocol.
        </t>
        <t>
   In modified UTF-7, printable US-ASCII characters, except for "&amp;",
   represent themselves; that is, characters with octet values 0x20-0x25
   and 0x27-0x7e.  The character "&amp;" (0x26) is represented by the
   two-octet
   2-octet sequence "&amp;-".
        </t>
        <t>
   All other characters (octet values 0x00-0x1f and 0x7f-0xff) are
   represented in modified BASE64, base64, with a further modification from
   <xref target='UTF-7'/> target="RFC2152" format="default"/> that "," is used instead of "/".  Modified BASE64 MUST NOT base64 <bcp14>MUST NOT</bcp14> be
   used to represent any printing of a US-ASCII character which that can represent
   itself. Only characters inside the modified BASE64 base64 alphabet are
   permitted in modified BASE64 base64 text.
        </t>
        <t>
   "&amp;" is used to shift to modified BASE64 base64 and "-" to shift back to
   US-ASCII.  There is no implicit shift from BASE64 base64 to US-ASCII, and
   null shifts ("-&amp;" while in BASE64; base64; note that "&amp;-" while in US-ASCII
   means "&amp;") are not permitted.  However, all names start in US-ASCII, US-ASCII
   and MUST <bcp14>MUST</bcp14> end in US-ASCII; that is, a name that ends with a non-ASCII
   ISO-10646 character MUST <bcp14>MUST</bcp14> end with a "-"). "-".
        </t>
        <t>
   The purpose of these modifications is to correct the following
   problems with UTF-7:

      <list style='numbers'>
         <t>

        </t>
        <ol spacing="normal" type="1"><li>
         UTF-7 uses the "+" character for shifting; this conflicts with
         the common use of "+" in mailbox names, in particular USENET
         newsgroup names.
         </t>

         <t>
         </li>
          <li>
         UTF-7's encoding is BASE64 base64, which uses the "/" character; this
         conflicts with the use of "/" as a popular hierarchy delimiter.
         </t>

         <t>
         </li>
          <li>
         UTF-7 prohibits the unencoded usage of "\"; this conflicts with
         the use of "\" as a popular hierarchy delimiter.
         </t>

         <t>
         </li>
          <li>
         UTF-7 prohibits the unencoded usage of "~"; this conflicts with
         the use of "~" in some servers as a home directory indicator.
         </t>

         <t>
         </li>
          <li>
         UTF-7 permits multiple alternate forms to represent the same
         string; in particular, printable US-ASCII characters can be
         represented in encoded form.
         </t>

      </list>
   </t>
         </li>
        </ol>
        <t>
      Although modified UTF-7 is a convention, it establishes certain
      requirements on the server handling of any mailbox name with an
      embedded "&amp;" character.  In particular, server implementations
      MUST
      <bcp14>MUST</bcp14> preserve the exact form of the modified BASE64 base64 portion of a
      modified UTF-7 name and treat that text as case-sensitive, case sensitive, even if
      names are otherwise case-insensitive case insensitive or case-folded. case folded.
        </t>
        <t>
      Server implementations SHOULD <bcp14>SHOULD</bcp14> verify that any mailbox name with an
      embedded "&amp;" character, used as an argument to CREATE, is: in the
      correctly modified UTF-7 syntax, syntax; has no superfluous shifts, shifts; and
      has no encoding in modified BASE64 base64 of any printing US-ASCII
      character which that can represent itself.  However, client
      implementations MUST NOT <bcp14>MUST NOT</bcp14> depend upon the server doing this, this and
      SHOULD NOT
      <bcp14>SHOULD NOT</bcp14> attempt to create a mailbox name with an embedded "&amp;"
      character unless it complies with the modified UTF-7 syntax.
        </t>
        <t>
      Server implementations which that export a mail store that does not
      follow the modified UTF-7 convention MUST <bcp14>MUST</bcp14> convert to modified
      UTF-7 any mailbox name
      that contains either non-ASCII characters
      or the "&amp;" character.

           <list>
           <t> character to modified
      UTF-7.

        </t>
        <ul empty="true" spacing="normal">
          <li>
           For example, here is a mailbox name which that mixes English,
           Chinese, and Japanese text:
           ~peter/mail/&amp;U,BTFw-/&amp;ZeVnLIqe-
           </t>

           <t>
           </li>
          <li>
           For example, the string "&amp;Jjo!" is not a valid mailbox
           name because it does not contain a shift to US-ASCII
           before the "!".  The correct form is "&amp;Jjo-!".  The
           string "&amp;U,BTFw-&amp;ZeVnLIqe-" is not permitted because it
           contains a superfluous shift.  The correct form is
           "&amp;U,BTF2XlZyyKng-".
           </t>
           </list>
   </t>
           </li>
        </ul>
      </section>
    </section>
    <section title='Backward compatibility anchor="BINARY-compat" numbered="true" toc="default">
      <name>Backward Compatibility with BINARY extension' anchor="BINARY-compat"> Extension</name>
      <t>IMAP4rev2 incorporates a subset of functionality provided by
         the BINARY extension <xref target='RFC3516'/>, target="RFC3516" format="default"/>; in particular particular, it includes
         additional FETCH items (BINARY, BINARY.PEEK BINARY.PEEK, and BINARY.SIZE), BINARY.SIZE)
         but not extensions to the APPEND command.
	 IMAP4rev2 implementations
         that supports support full RFC 3516 <xref target="RFC3516" format="default"/>
	 functionality need to also advertise the BINARY
         capability in the CAPABILITY response/response response / response code.
      </t>
    </section>
    <section title='Backward compatibility anchor="LIST-EXTENDED-compat" numbered="true" toc="default">
      <name>Backward Compatibility with LIST-EXTENDED extension' anchor="LIST-EXTENDED-compat"> Extension</name>
      <t>
           IMAP4rev2 incorporates most of the functionality provided by
           the LIST-EXTENDED extension <xref target='RFC5258'/>. target="RFC5258" format="default"/>.
           In particular, the syntax for multiple mailbox patterns syntax is not supported
           in IMAP4rev2, unless LIST-EXTENDED capability is also advertised
           in the CAPABILITY response/response response / response code.
      </t>
    </section>
    <section title='63 bit body part anchor="body-part-64bit" numbered="true" toc="default">
      <name>63-Bit Body Part and message sizes' anchor="body-part-64bit"> Message Sizes</name>
      <t>
           IMAP4rev2 increases allowed body part and message sizes that servers
           can support from 32 to 63 bits.
           Server implementations don't have to support 63 bit long 63-bit-long body parts/message
           sizes, however
           sizes; however, client implementations have to expect them.
      </t>
      <t>
           As IMAP4rev1 didn't support 63 bit long 63-bit-long body part/message part / message sizes,
           there is an interoperability issue exposed by 63 bit capable
           servers<!--mailstores?--> 63-bit-capable
           servers/mailboxes that are accessible by both IMAP4rev1 and IMAP4rev2
           email clients. As IMAP4rev1 would be unable to retrieve the full content
           of messages bigger than 4Gb, 4 Gb, such servers either need to replace
           messages bigger that 4Gb 4 Gb with messages under 4Gb 4 Gb or hide them
           from IMAP4rev1 clients. This document doesn't prescribe any implementation
           strategy to address this issue.
      </t>

<!--Timo suggested that maybe hiding such messages is not the best strategy:
         <t>
           For example, imagine that a mailbox has 3 messages with UIDs 1, 17, 21.
           These messages have the following sizes (respectively): 32Kb, 5Gb, 60Mb.
           When such mailbox is accessed by an IMAP4rev2 client that issued "ENABLE IMAP4rev2",
           it will see all 3 messages. When such mailbox is accessed by an IMAP4rev1 client,
           it will only see messages with UIDs 1 and 21.
         </t>
   -->
       </section>
    <section title='Changes anchor="changesFromIMAP4rev1" numbered="true" toc="default">
      <name>Changes from RFC 3501 / IMAP4rev1' anchor="changesFromIMAP4rev1"> IMAP4rev1</name>
      <t>Below is the summary of changes since RFC 3501:
         <list style='numbers'>

            <!--////Chris Newman suggested to expand this to list every element added/changed, e.g. UIDSTICKY -->

           <t>Support
      </t>
      <ol spacing="normal" type="1">
           <li>Support for 64bit 64-bit message and body part sizes.</t>

            <t> sizes.</li>
           <li>
          Folded in IMAP NAMESPACE (RFC 2342), <xref target="RFC2342"/>, UNSELECT (RFC 3691), <xref target="RFC3691"/>,
	  UIDPLUS (RFC 4315), <xref target="RFC4315"/>,
            ESEARCH (RFC 4731), <xref target="RFC4731"/>, SEARCHRES (RFC 5182), <xref target="RFC5182"/>, ENABLE (RFC 5161), <xref target="RFC5161"/>, IDLE (RFC 2177), <xref target="RFC2177"/>,
            SASL-IR (RFC 4959), <xref target="RFC4959"/>, LIST-EXTENDED (RFC 5258), <xref target="RFC5258"/>, LIST-STATUS (RFC 5819), <xref target="RFC5819"/>, MOVE (RFC 6851) <xref target="RFC6851"/>,
            and LITERAL- (RFC 7888) extensions. extensions <xref target="RFC7888"/>.
            Also folded RFC 4466 (IMAP in IMAP ABNF extensions), RFC 5530 (response codes), extensions <xref target="RFC4466"/>, response codes <xref target="RFC5530"/>,
            the FETCH side of the BINARY extension (RFC 3516) <xref target="RFC3516"/>, and
            the list of new mailbox attributes from SPECIAL-USE (RFC 6154).</t>

            <t>Added <xref target="RFC6154"/>.</li>
        <li>Added STATUS SIZE (RFC 8438) <xref target="RFC8438"/> and STATUS DELETED.</t>

            <t>SEARCH DELETED.</li>
        <li>SEARCH command now requires to return the ESEARCH response (SEARCH response is now deprecated).</t>

            <t>Clarified deprecated).</li>
        <li>Clarified which SEARCH keys have to use substring match and which don't.</t>

            <t>Clarified don't.</li>
        <li>Clarified that the server should decode parameter value continuations as described in <xref target='RFC2231'/>. target="RFC2231" format="default"/>.
            This requirement was hidden in RFC 2231 itself.</t>

            <t>Clarified <xref target="RFC2231"/> itself.</li>
        <li>Clarified that the COPYUID response code is returned for both MOVE and UID MOVE.</t>

            <t>Tighen MOVE.</li>
        <li>Tightened requirements about COPY/MOVE commands not creating a target mailbox.
            Also require required them to return the TRYCREATE response code, if the target mailbox
            doesn't exist and can be created.</t>

            <t>Added created.</li>
        <li>Added the CLOSED response code from RFC 7162. <xref target="RFC7162"/>. SELECT/EXAMINE when a mailbox is
            already selected now requires a CLOSED response code to be returned.</t>

            <t>SELECT/EXAMINE returned.</li>
        <li>SELECT/EXAMINE are now required to return an untagged LIST response.</t>

            <t>UNSEEN response.</li>
        <li>UNSEEN response code on SELECT/EXAMINE is now deprecated.</t>

            <t>RECENT deprecated.</li>

        <li>RECENT response on SELECT/EXAMINE, \Recent flag, RECENT STATUS, and SEARCH NEW items are now deprecated.</t>

            <t>Clarified deprecated.</li>
        <li>Clarified that the server doesn't need to send a new PERMANENTFLAGS response code when a new
        keyword was successfully added and the server advertised \* earlier for the same mailbox.</t>

            <t>For mailbox.</li>

        <li>For future extensibility extensibility, extended ABNF for tagged-ext-simple to allow for bare number64.</t>

            <t>Added SHOULD number64.</li>
        <li>Added <bcp14>SHOULD</bcp14> level requirement on IMAP servers to support $MDNSent, $Forwarded, $Junk, $NonJunk $NonJunk, and $Phishing keywords.</t>

            <t>Mailbox keywords.</li>
        <li>Mailbox names and message headers now allow for UTF-8. Support for Modified modified UTF-7 in mailbox names
               is not required, unless compatibility with IMAP4rev1 is desired.</t>

            <t>Removed desired.</li>
        <li>Removed the CHECK command. Clients should use NOOP instead.</t>

            <t>RFC822, RFC822.HEADER instead.</li>
        <li>RFC822, RFC822.HEADER, and RFC822.TEXT FETCH data items were deprecated.
            Clients should use the corresponding BODY[] variants instead.</t>

            <t>LSUB instead.</li>
        <li>LSUB command was deprecated. Clients should use LIST (SUBSCRIBED) instead.</t>

            <t>IDLE instead.</li>
        <li>IDLE command can now return updates not related to the currently selected mailbox state.</t>

            <t>All state.</li>
        <li>All unsolicited FETCH updates are required to include UID.</t>

            <t>Clarified UID.</li>
        <li>Clarified that client implementations MUST <bcp14>MUST</bcp14> ignore response codes that they do not recognize. (Change (Changed from a SHOULD <bcp14>SHOULD</bcp14> to a MUST.)</t>

            <t>resp-text <bcp14>MUST</bcp14>.)</li>
        <li>resp-text ABNF non terminal non-terminal was updated to allow for empty text.</t>

            <t>After ENABLE text.</li>

        <li>After ENABLE, IMAP4rev2 human readable human-readable response text can include non ASCII non-ASCII encoded in UTF-8.</t>

            <t>Updated UTF-8.</li>
        <li>Updated to use modern TLS-related recommendations as per RFC 8314, RFC 7817, RFC 7525.</t>

            <t>Added <xref target="RFC7525"/>, <xref target="RFC7817"/>, and <xref target="RFC8314"/>.</li>
        <li>Added warnings about use of ALERT response codes and PREAUTH response.</t>

            <t>Replaced response.</li>
        <li>Replaced DIGEST-MD5 SASL mechanism with SCRAM-SHA-256. DIGEST-MD5 was deprecated.</t>

            <t>Clarified deprecated.</li>
        <li>Clarified that any command received from the client resets server autologout timer.</t>

            <t>Revised timer.</li>
        <li>Revised IANA registration procedure for IMAP extensions and removed "X" convention in accordance with BCP 178.</t>

            <t>Loosened <xref target="BCP178"/>.</li>
        <li>Loosened requirements on servers when closing connections to be more aligned with existing practices.</t>

         </list></t> practices.</li>
      </ol>
    </section>
    <section title='Other anchor="recommended-extensions" numbered="true" toc="default">
      <name>Other Recommended IMAP Extensions' anchor="recommended-extensions"> Extensions</name>
      <t>Support for the following extensions is recommended for all IMAP client clients and servers.
          While they significantly reduce bandwidth and/or number of round trips used by IMAP
          in certain situations, the EXTRA WG decided that requiring them as a part of IMAP4rev2
          would push the bar to implement too high for new implementations.
          Also note that the absence of any IMAP extension from this list doesn't make it somehow
          deficient or not recommended for use with IMAP4rev2.

            <list style='numbers'>

                <t>QRESYNC

      </t>
      <ol spacing="normal" type="1">

	<li>Quick Mailbox Resynchronization (QRESYNC) and CONDSTORE extensions <xref target='RFC7162'/>. target="RFC7162" format="default"/>. They make
	discovering changes to IMAP mailboxes more efficient, at the expense of storing a bit more state.</t>

                <t>OBJECTID state.</li>
        <li>OBJECTID extension <xref target='RFC8474'/> target="RFC8474" format="default"/> helps with preserving the IMAP client cache
                when messages are moved/copied or mailboxes are renamed.</t>

            </list>
          </t> renamed.</li>
      </ol>
    </section>
    <section title='Acknowledgement'> numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>Earlier draft versions of this document were edited by Mark Crispin. <contact fullname="Mark Crispin"/>.
         Sadly, he is no longer available to help with this work.
      Editors of this revisions revision are hoping that Mark would have approved.</t>

         <t>Chris Newman

      <t><contact fullname="Chris Newman"/> has contributed text on I18N and use of UTF-8 in messages and mailbox names.</t>

      <t>Thank you to Tony Hansen <contact fullname="Tony Hansen"/> for helping with the index generation.
         Thank you to Murray Kucherawy, Timo Sirainen, Bron Gondwana, Stephan Bosch, Robert Sparks,
         Arnt Gulbrandsen, Benjamin Kaduk, Daniel Migault, Roman Danyliw and Éric Vyncke <contact fullname="Murray Kucherawy"/>, <contact fullname="Timo Sirainen"/>, <contact fullname="Bron Gondwana"/>, <contact fullname="Stephan Bosch"/>, <contact fullname="Robert Sparks"/>,
         <contact fullname="Arnt Gulbrandsen"/>, <contact fullname="Benjamin Kaduk"/>, <contact fullname="Daniel Migaul"/>, <contact fullname="Roman Danyliw"/>, and <contact fullname="Éric Vyncke"/> for extensive feedback.</t>
      <t>
         This document incorporates text from RFC 4315
         <xref target="RFC2342" format="default"/> (by Mark Crispin), RFC 4466 <contact fullname="Mike Gahrns"/> and <contact fullname="Chris Newman"/>),
         <xref target="RFC3516" format="default"/> (by Cyrus Daboo),
         RFC 4731 <contact fullname="Lyndon Nerenberg"/>),
         <xref target="RFC4315" format="default"/> (by Dave Cridland), RFC 5161 <contact fullname="Mark Crispin"/>),
         <xref target="RFC4466" format="default"/> (by Arnt Gulbrandsen),
         RFC 5465 <contact fullname="Cyrus Daboo"/>),
         <xref target="RFC4731" format="default"/> (by Arnt Gulbrandsen and Curtis King), RFC 5530 <contact fullname="Dave Cridland"/>),
         <xref target="RFC4959" format="default"/> (by Arnt Gulbrandsen),
         RFC 5819 <contact fullname="Rob Siemborski"/> and <contact fullname="Arnt Gulbrandsen"/>),
         <xref target="RFC5161" format="default"/> (by Timo Sirainen), RFC 6154 <contact fullname="Arnt Gulbrandsen"/>),
         <xref target="RFC5465" format="default"/> (by Jamie Nicolson), RFC 8438 <contact fullname="Arnt Gulbrandsen"/> and <contact fullname="Curtis King"/>),
         <xref target="RFC5530" format="default"/> (by Stephan Bosch)
         <!--/////Update this list before publication--> <contact fullname="Arnt Gulbrandsen"/>),
         <xref target="RFC5819" format="default"/> (by <contact fullname="Timo Sirainen"/>),
         <xref target="RFC6154" format="default"/> (by <contact fullname="Jamie Nicolson"/>),
         <xref target="RFC6851" format="default"/> (by <contact fullname="Arnt Gulbrandsen"/> and <contact fullname="Ned Freed"/>),
         and <xref target="RFC8438" format="default"/> (by <contact fullname="Stephan Bosch"/>),
         so work done by authors/editors of these documents is appreciated. Note that editors
         of this document were redacted from the above list.</t>

      <t>The CHILDREN return option was originally proposed by Mike Gahrns <contact fullname="Mike Gahrns"/> and Raymond Cheng <contact fullname="Raymond Cheng"/> in <xref target="RFC3348"/>. target="RFC3348" format="default"/>.
         Most of the information in <xref target="children"/> target="children" format="default"/> is taken
      directly from their original specification <xref target="RFC3348"/>.</t> target="RFC3348" format="default"/>.</t>

      <t>Thank you to Damian Poddebniak, Fabian Ising, Hanno Böck and Sebastian Schinzel <contact fullname="Damian Poddebniak"/>, <contact fullname="Fabian Ising"/>, <contact fullname="Hanno Boeck"/>, and <contact fullname="Sebastian Schinzel"/> for pointing out that
         the ENABLE command should be a member of "command-auth" and not "command-any" ABNF production,
         as well as pointing out security issues associated with ALERT, PREAUTH PREAUTH, and other responses received
         before authentication.
      </t>

    </section>
  </back>
</rfc>