Section 1. How to Read This Document

1.1.  Organization of This Document
   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, it is not optimized for someone trying to understand the
   operation of the protocol.  The material in Sections 3, 4, and 5
   provides the general context and definitions with which IMAP4rev2
   operates.
   Sections 6, 7, and 9 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, refer to "Formal Syntax" (Section 9).
1.2.  Conventions Used in This Document
   "Conventions" are basic principles or procedures.  Document
   conventions are noted in this section.
   In examples, "C:" and "S:" indicate lines sent by the client and
   server, respectively.  Note that each line includes the terminating
   CRLF.
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.
   The word "can" (not "may") is used to refer to a possible
   circumstance or situation, as opposed to an optional facility of the
   protocol.
   "User" is used to refer to a human user, whereas "client" refers to
   the software being run by the user.
   "Connection" refers to the entire sequence of client/server
   interaction from the initial establishment of the network connection
   until its termination.
   "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).
   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.
   Characters are 8-bit UTF-8 (of which 7-bit US-ASCII is a subset),
   unless otherwise specified.  Other character sets are indicated using
   a "CHARSET", as described in [MIME-IMT] and defined in [CHARSET].
   CHARSETs have important additional semantics in addition to defining
   a character set; refer to these documents for more detail.
   There are several protocol conventions in IMAP.  These refer to
   aspects of the specification that are not strictly part of the IMAP
   protocol but reflect generally accepted practice.  Implementations
   need to be aware of these conventions, and avoid conflicts whether or
   not they implement the convention.  For example, "&" may not be used
   as a hierarchy delimiter since it conflicts with the Mailbox
   International Naming Convention, and other uses of "&" in mailbox
   names are impacted as well.
1.3.  Special Notes to Implementors
   Implementors of the IMAP protocol are strongly encouraged to read the
   IMAP implementation recommendations document [IMAP-IMPLEMENTATION] in
   conjunction with this document, to help understand the intricacies of
   this protocol and how best to build an interoperable product.
   IMAP4rev2 is designed to be upwards compatible from the IMAP4rev1
   [RFC3501], IMAP2 [IMAP2], and unpublished IMAP2bis [IMAP2BIS]
   protocols.  IMAP4rev2 is largely compatible with the IMAP4rev1
   protocol described in RFC 3501 and the IMAP4 protocol described in
   [RFC1730]; the exception being in certain facilities added in
   [RFC1730] and [RFC3501] 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 that
   an IMAP4rev2 implementation can encounter when used with an earlier
   implementation are described in Appendices A and E and
   [IMAP-OBSOLETE].  IMAP4rev2 supports 63-bit body parts and message
   sizes.  IMAP4rev2 compatibility with BINARY and LIST-EXTENDED IMAP
   extensions are described in Appendices B and C, respectively.
   Other compatibility issues with IMAP2bis, the most common variant of
   the earlier protocol, are discussed in [IMAP-COMPAT].  A full
   discussion of compatibility issues with rare (and presumed extinct)
   variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is
   primarily of historical interest.
   IMAP was originally developed for the older [RFC822] 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 [RFC5322] standard.
   IMAP4rev2 does not specify a means of posting mail; this function is
   handled by a mail submission protocol such as the one specified in
   [RFC6409].