RFC 3501
INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1
Pages: 108
Obsoletes: 2060
Obsoleted by: 9051
Updated by: 4466 4469 4551 5032 5182 5738 6186 6858 7817 8314 8437 8474 8996
Obsoletes: 2060
Obsoleted by: 9051
Updated by: 4466 4469 4551 5032 5182 5738 6186 6858 7817 8314 8437 8474 8996
Part 1 of 4 – Pages 1 to 17
Network Working Group M. Crispin Request for Comments: 3501 University of Washington Obsoletes: 2060 March 2003 Category: Standards Track INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved.Abstract
The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev1 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev1 also provides the capability for an offline client to resynchronize with the server. IMAP4rev1 includes operations for creating, deleting, and renaming mailboxes, checking for new messages, permanently removing messages, setting and clearing flags, RFC 2822 and RFC 2045 parsing, searching, and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev1 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev1 supports a single server. A mechanism for accessing configuration information to support multiple IMAP4rev1 servers is discussed in RFC 2244. IMAP4rev1 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as RFC 2821.
Table of Contents
IMAP4rev1 Protocol Specification ................................ 4 1. How to Read This Document ............................... 4 1.1. Organization of This Document ........................... 4 1.2. Conventions Used in This Document ....................... 4 1.3. Special Notes to Implementors ........................... 5 2. Protocol Overview ....................................... 6 2.1. Link Level .............................................. 6 2.2. Commands and Responses .................................. 6 2.2.1. Client Protocol Sender and Server Protocol Receiver ..... 6 2.2.2. Server Protocol Sender and Client Protocol Receiver ..... 7 2.3. Message Attributes ...................................... 8 2.3.1. Message Numbers ......................................... 8 2.3.1.1. Unique Identifier (UID) Message Attribute ....... 8 2.3.1.2. Message Sequence Number Message Attribute ....... 10 2.3.2. Flags Message Attribute ................................. 11 2.3.3. Internal Date Message Attribute ......................... 12 2.3.4. [RFC-2822] Size Message Attribute ....................... 12 2.3.5. Envelope Structure Message Attribute .................... 12 2.3.6. Body Structure Message Attribute ........................ 12 2.4. Message Texts ........................................... 13 3. State and Flow Diagram .................................. 13 3.1. Not Authenticated State ................................. 13 3.2. Authenticated State ..................................... 13 3.3. Selected State .......................................... 13 3.4. Logout State ............................................ 14 4. Data Formats ............................................ 16 4.1. Atom .................................................... 16 4.2. Number .................................................. 16 4.3. String .................................................. 16 4.3.1. 8-bit and Binary Strings ................................ 17 4.4. Parenthesized List ...................................... 17 4.5. NIL ..................................................... 17 5. Operational Considerations .............................. 18 5.1. Mailbox Naming .......................................... 18 5.1.1. Mailbox Hierarchy Naming ................................ 19 5.1.2. Mailbox Namespace Naming Convention ..................... 19 5.1.3. Mailbox International Naming Convention ................. 19 5.2. Mailbox Size and Message Status Updates ................. 21 5.3. Response when no Command in Progress .................... 21 5.4. Autologout Timer ........................................ 22 5.5. Multiple Commands in Progress ........................... 22 6. Client Commands ........................................ 23 6.1. Client Commands - Any State ............................ 24 6.1.1. CAPABILITY Command ..................................... 24 6.1.2. NOOP Command ........................................... 25 6.1.3. LOGOUT Command ......................................... 26
6.2. Client Commands - Not Authenticated State .............. 26 6.2.1. STARTTLS Command ....................................... 27 6.2.2. AUTHENTICATE Command ................................... 28 6.2.3. LOGIN Command .......................................... 30 6.3. Client Commands - Authenticated State .................. 31 6.3.1. SELECT Command ......................................... 32 6.3.2. EXAMINE Command ........................................ 34 6.3.3. CREATE Command ......................................... 34 6.3.4. DELETE Command ......................................... 35 6.3.5. RENAME Command ......................................... 37 6.3.6. SUBSCRIBE Command ...................................... 39 6.3.7. UNSUBSCRIBE Command .................................... 39 6.3.8. LIST Command ........................................... 40 6.3.9. LSUB Command ........................................... 43 6.3.10. STATUS Command ......................................... 44 6.3.11. APPEND Command ......................................... 46 6.4. Client Commands - Selected State ....................... 47 6.4.1. CHECK Command .......................................... 47 6.4.2. CLOSE Command .......................................... 48 6.4.3. EXPUNGE Command ........................................ 49 6.4.4. SEARCH Command ......................................... 49 6.4.5. FETCH Command .......................................... 54 6.4.6. STORE Command .......................................... 58 6.4.7. COPY Command ........................................... 59 6.4.8. UID Command ............................................ 60 6.5. Client Commands - Experimental/Expansion ............... 62 6.5.1. X<atom> Command ........................................ 62 7. Server Responses ....................................... 62 7.1. Server Responses - Status Responses .................... 63 7.1.1. OK Response ............................................ 65 7.1.2. NO Response ............................................ 66 7.1.3. BAD Response ........................................... 66 7.1.4. PREAUTH Response ....................................... 67 7.1.5. BYE Response ........................................... 67 7.2. Server Responses - Server and Mailbox Status ........... 68 7.2.1. CAPABILITY Response .................................... 68 7.2.2. LIST Response .......................................... 69 7.2.3. LSUB Response .......................................... 70 7.2.4 STATUS Response ........................................ 70 7.2.5. SEARCH Response ........................................ 71 7.2.6. FLAGS Response ......................................... 71 7.3. Server Responses - Mailbox Size ........................ 71 7.3.1. EXISTS Response ........................................ 71 7.3.2. RECENT Response ........................................ 72 7.4. Server Responses - Message Status ...................... 72 7.4.1. EXPUNGE Response ....................................... 72 7.4.2. FETCH Response ......................................... 73 7.5. Server Responses - Command Continuation Request ........ 79
8. Sample IMAP4rev1 connection ............................ 80 9. Formal Syntax .......................................... 81 10. Author's Note .......................................... 92 11. Security Considerations ................................ 92 11.1. STARTTLS Security Considerations ....................... 92 11.2. Other Security Considerations .......................... 93 12. IANA Considerations .................................... 94 Appendices ..................................................... 95 A. Normative References ................................... 95 B. Changes from RFC 2060 .................................. 97 C. Key Word Index ......................................... 103 Author's Address ............................................... 107 Full Copyright Statement ....................................... 108 IMAP4rev1 Protocol Specification1. 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 IMAP4rev1 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 through 5 provides the general context and definitions with which IMAP4rev1 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 the Formal Syntax section.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. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS]. 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, or connection termination). Characters are 7-bit US-ASCII 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 character set; refer to these documents for more detail. There are several protocol conventions in IMAP. These refer to aspects of the specification which 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. IMAP4rev1 is designed to be upwards compatible from the [IMAP2] and unpublished IMAP2bis protocols. IMAP4rev1 is largely compatible with the IMAP4 protocol described in RFC 1730; the exception being in certain facilities added in RFC 1730 that proved problematic and were subsequently removed. In the course of the evolution of IMAP4rev1, some aspects in the earlier protocols have become obsolete. Obsolete commands, responses, and data formats which an IMAP4rev1 implementation can encounter when used with an earlier implementation are described in [IMAP-OBSOLETE]. 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 [RFC-822] standard, and as a consequence several fetch items in IMAP incorporate "RFC822" in their name. With the exception of RFC822.SIZE, there are more modern replacements; for example, the modern version of RFC822.HEADER is BODY.PEEK[HEADER]. In all cases, "RFC822" should be interpreted as a reference to the updated [RFC-2822] standard.2. Protocol Overview
2.1. Link Level
The IMAP4rev1 protocol assumes a reliable data stream such as that provided by TCP. When TCP is used, an IMAP4rev1 server listens on port 143.2.2. Commands and Responses
An IMAP4rev1 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. 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 IMAP4rev1 client or server is either reading a line, or is reading a sequence of octets with a known count followed by a line.2.2.1. Client Protocol Sender and Server Protocol Receiver
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. Clients MUST follow the syntax outlined in this specification strictly. It is a syntax error to send a command with missing or extraneous spaces or arguments. 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 String under Data Formats); in the other case, the command arguments require server feedback (see the AUTHENTICATE command). 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 "+".
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.
It is also possible for the server to send a completion
response for some other command (if multiple commands are
in progress), or untagged data. In either case, the
command continuation request is still pending; the client
takes the appropriate action for the response, and reads
another response from the server. In all cases, the client
MUST send a complete command (including receiving all
command continuation request responses and command
continuations for the command) before initiating a new
command.
The protocol receiver of an IMAP4rev1 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.
2.2.2. Server Protocol Sender and Client Protocol Receiver
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.
Server data MAY be sent as a result of a client command, or MAY 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.
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 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).
Servers SHOULD enforce the syntax outlined in this specification
strictly. Any client command with a protocol syntax error, including
(but not limited to) missing or extraneous spaces or arguments,
SHOULD be rejected, and the client given a BAD server completion response. The protocol receiver of an IMAP4rev1 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 "+". A client MUST be prepared to accept any server response at all times. This includes server data that was not requested. Server data SHOULD be recorded, so that the client can reference its recorded copy rather than sending a command to the server to request the data. In the case of certain server data, the data MUST be recorded. This topic is discussed in greater detail in the Server Responses section.2.3. Message Attributes
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.2.3.1. Message Numbers
Messages in IMAP4rev1 are accessed by one of two numbers; the unique identifier or the message sequence number.2.3.1.1. Unique Identifier (UID) Message Attribute
A 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 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 it is assigned a higher UID than the message(s) which were added previously. Unlike message sequence numbers, unique identifiers are not necessarily contiguous. The unique identifier of a message MUST NOT change during the session, and SHOULD NOT change between sessions. Any change of unique identifiers between sessions MUST 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); this is discussed further in [IMAP-DISC].
Associated with every mailbox are two values which aid in unique
identifier handling: the next unique identifier value and the unique
identifier validity value.
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 have the following two characteristics. First,
the next unique identifier value MUST NOT change unless new messages
are added to the mailbox; and second, the next unique identifier
value MUST change whenever new messages are added to the mailbox,
even if those new messages are subsequently expunged.
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.
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 be greater than
the one used in the earlier session.
Note: Ideally, unique identifiers SHOULD 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:
1) Unique identifiers MUST be strictly ascending in the
mailbox at all times. If the physical message store is
re-ordered by a non-IMAP agent, this requires that the
unique identifiers in the mailbox be regenerated, since
the former unique identifiers are no longer strictly
ascending as a result of the re-ordering.
2) 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.
3) If the mailbox is deleted 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, or it must assign a
new UIDVALIDITY value to the new instance of the
mailbox. A good UIDVALIDITY value to use in this case
is a 32-bit representation of the creation date/time of
the mailbox. It is alright to use a constant such as
1, but only if it guaranteed that unique identifiers
will never be reused, even in the case of a mailbox
being deleted (or renamed) and a new mailbox by the
same name created at some future time.
4) The combination of mailbox name, UIDVALIDITY, and UID
must refer to a single immutable message on that server
forever. In particular, the internal date, [RFC-2822]
size, envelope, body structure, and message texts
(RFC822, RFC822.HEADER, RFC822.TEXT, and all BODY[...]
fetch data items) must never change. This does not
include message numbers, nor does it include attributes
that can be set by a STORE command (e.g., FLAGS).
2.3.1.2. Message Sequence Number Message Attribute
A relative position from 1 to the number of messages in the mailbox.
This position MUST be ordered by ascending unique identifier. 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.
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.
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 example, if message 287 in a 523 message mailbox has UID
12345, there are exactly 286 messages which have lesser UIDs and 236
messages which have greater UIDs.
2.3.2. Flags Message Attribute
A list of zero or more named tokens associated with the message. A flag is set by its addition to this list, and is cleared by its removal. There are two types of flags in IMAP4rev1. A flag of either type can be permanent or session-only. A system flag is a flag name that is pre-defined in this specification. All system flags begin with "\". Certain system flags (\Deleted and \Seen) have special semantics described elsewhere. The currently-defined system flags are: \Seen Message has been read \Answered Message has been answered \Flagged Message is "flagged" for urgent/special attention \Deleted Message is "deleted" for removal by later EXPUNGE \Draft Message has not completed composition (marked as a draft). \Recent Message is "recently" arrived in this mailbox. This session is the first session to have been notified about this message; if the session is read-write, subsequent sessions will not see \Recent set for this message. This flag can not be altered by the client. If it is not possible to determine whether or not this session is the first session to be notified about a message, then that message SHOULD be considered recent. If multiple connections have the same mailbox selected simultaneously, it is undefined which of these connections will see newly-arrived messages with \Recent set and which will see it without \Recent set. A keyword is defined by the server implementation. Keywords do not begin with "\". Servers MAY permit the client to define new keywords in the mailbox (see the description of the PERMANENTFLAGS response code for more information).
A flag can be permanent or session-only on a per-flag basis.
Permanent flags are those which 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.
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.
2.3.3. Internal Date Message Attribute
The internal date and time of the message on the server. This
is not the date and time in the [RFC-2822] header, but rather a
date and time which reflects when the message was received. In
the case of messages delivered via [SMTP], this SHOULD be the
date and time of final delivery of the message as defined by
[SMTP]. In the case of messages delivered by the IMAP4rev1 COPY
command, this SHOULD be the internal date and time of the source
message. In the case of messages delivered by the IMAP4rev1
APPEND command, this SHOULD be the date and time as specified in
the APPEND command description. All other cases are
implementation defined.
2.3.4. [RFC-2822] Size Message Attribute
The number of octets in the message, as expressed in [RFC-2822]
format.
2.3.5. Envelope Structure Message Attribute
A parsed representation of the [RFC-2822] header of the message.
Note that the IMAP Envelope structure is not the same as an
[SMTP] envelope.
2.3.6. Body Structure Message Attribute
A parsed representation of the [MIME-IMB] body structure
information of the message.
2.4. Message Texts
In addition to being able to fetch the full [RFC-2822] text of a message, IMAP4rev1 permits the fetching of portions of the full message text. Specifically, it is possible to fetch the [RFC-2822] message header, [RFC-2822] message body, a [MIME-IMB] body part, or a [MIME-IMB] header.3. State and Flow Diagram
Once the connection between client and server is established, an IMAP4rev1 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.3.1. Not Authenticated State
In the not authenticated state, the client MUST supply authentication credentials before most commands will be permitted. This state is entered when a connection starts unless the connection has been pre-authenticated.3.2. Authenticated State
In the authenticated state, the client is authenticated and MUST 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 command.3.3. Selected State
In a selected state, a mailbox has been selected to access. This state is entered when a mailbox has been successfully selected.
3.4. Logout State
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 server. If the client requests the logout state, the server MUST send an untagged BYE response and a tagged OK response to the LOGOUT command before the server closes the connection; and the client MUST read the tagged OK response to the LOGOUT command before the client closes the connection. A server MUST NOT unilaterally close the connection without sending an untagged BYE response that contains the reason for having done so. A client SHOULD NOT unilaterally close the connection, and instead SHOULD issue a LOGOUT command. If the server detects that the client has unilaterally closed the connection, the server MAY omit the untagged BYE response and simply close its connection.
+----------------------+
|connection established|
+----------------------+
||
\/
+--------------------------------------+
| server greeting |
+--------------------------------------+
|| (1) || (2) || (3)
\/ || ||
+-----------------+ || ||
|Not Authenticated| || ||
+-----------------+ || ||
|| (7) || (4) || ||
|| \/ \/ ||
|| +----------------+ ||
|| | Authenticated |<=++ ||
|| +----------------+ || ||
|| || (7) || (5) || (6) ||
|| || \/ || ||
|| || +--------+ || ||
|| || |Selected|==++ ||
|| || +--------+ ||
|| || || (7) ||
\/ \/ \/ \/
+--------------------------------------+
| Logout |
+--------------------------------------+
||
\/
+-------------------------------+
|both sides close the connection|
+-------------------------------+
(1) connection without pre-authentication (OK greeting)
(2) pre-authenticated connection (PREAUTH greeting)
(3) rejected connection (BYE greeting)
(4) successful LOGIN or AUTHENTICATE command
(5) successful SELECT or EXAMINE command
(6) CLOSE command, or failed SELECT or EXAMINE command
(7) LOGOUT command, server shutdown, or connection closed
4. Data Formats
IMAP4rev1 uses textual commands and responses. Data in IMAP4rev1 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.4.1. Atom
An atom consists of one or more non-special characters.4.2. Number
A number consists of one or more digit characters, and represents a numeric value.4.3. String
A string is in one of two forms: either literal or quoted string. The literal form is the general form of string. The quoted string form is an alternative that avoids the overhead of processing a literal at the cost of limitations of characters which may be used. A 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, close brace ("}"), and CRLF. In the case of literals transmitted from server to client, the CRLF is immediately followed by the octet data. In the case of literals transmitted from client to server, the client MUST wait to receive a command continuation request (described later in this document) before sending the octet data (and the remainder of the command). A quoted string is a sequence of zero or more 7-bit characters, excluding CR and LF, with double quote (<">) characters at each end. The empty string is represented as either "" (a quoted string with zero characters between double quotes) or as {0} followed by CRLF (a literal with an octet count of 0). Note: Even if the octet count is 0, a client transmitting a literal MUST wait to receive a command continuation request.
4.3.1. 8-bit and Binary Strings
8-bit textual and binary mail is supported through the use of a [MIME-IMB] content transfer encoding. IMAP4rev1 implementations MAY transmit 8-bit or multi-octet characters in literals, but SHOULD do so only when the [CHARSET] is identified. Although a BINARY body encoding is defined, unencoded binary strings are not permitted. A "binary string" is any string with NUL characters. Implementations MUST encode binary data into a textual form, such as BASE64, before transmitting the data. A string with an excessive amount of CTL characters MAY also be considered to be binary.4.4. Parenthesized List
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. The empty list is represented as () -- a parenthesized list with no members.4.5. NIL
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 (). Note: NIL is never used for any data item which 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 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 which is NIL or a string, but never an atom.