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.
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 variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is primarily of historical interest.