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.
Crispin Standards Track [Page 1]
RFC 3501 IMAPv4 March 2003
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
Crispin Standards Track [Page 2]
RFC 3501 IMAPv4 March 2003
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
Crispin Standards Track [Page 3]
RFC 3501 IMAPv4 March 2003
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. References ............................................. 95
B. Changes from RFC 2060 .................................. 97
C. Key Word Index ......................................... 103
Author's Address ............................................... 107
Full Copyright Statement ....................................... 108
IMAP4rev1 Protocol Specification
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 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.
Crispin Standards Track [Page 4]
RFC 3501 IMAPv4 March 2003
"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)
Crispin Standards Track [Page 5]
RFC 3501 IMAPv4 March 2003
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
Crispin Standards Track [Page 6]
RFC 3501 IMAPv4 March 2003
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,
Crispin Standards Track [Page 7]
RFC 3501 IMAPv4 March 2003
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].
Crispin Standards Track [Page 8]
RFC 3501 IMAPv4 March 2003
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.
Crispin Standards Track [Page 9]
RFC 3501 IMAPv4 March 2003
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.
Crispin Standards Track [Page 10]
RFC 3501 IMAPv4 March 2003
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).
Crispin Standards Track [Page 11]
RFC 3501 IMAPv4 March 2003
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.
Crispin Standards Track [Page 12]
RFC 3501 IMAPv4 March 2003
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.
Crispin Standards Track [Page 13]
RFC 3501 IMAPv4 March 2003
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.
Crispin Standards Track [Page 14]
RFC 3501 IMAPv4 March 2003
+----------------------+
|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
Crispin Standards Track [Page 15]
RFC 3501 IMAPv4 March 2003
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 transmi
<P><FONT face="courier new,courier">Network Working Group&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; M. Crispin
Request for Comments: 3501&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; University of Washington
Obsoletes: 2060&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; March 2003
Category: Standards Track</FONT></P>
<P>
<FONT face="courier new,courier">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1</FONT></P>
<P><FONT face="courier new,courier">Status of this Memo</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; This document specifies an Internet standards track protocol for the
&nbsp;&nbsp; Internet community, and requests discussion and suggestions for
&nbsp;&nbsp; improvements.&nbsp; Please refer to the current edition of the "Internet
&nbsp;&nbsp; Official Protocol Standards" (STD 1) for the standardization state
&nbsp;&nbsp; and status of this protocol.&nbsp; Distribution of this memo is unlimited.</FONT></P>
<P><FONT face="courier new,courier">Copyright Notice</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; Copyright (C) The Internet Society (2003).&nbsp; All Rights Reserved.</FONT></P>
<P><FONT face="courier new,courier">Abstract</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1)
&nbsp;&nbsp; allows a client to access and manipulate electronic mail messages on
&nbsp;&nbsp; a server.&nbsp; IMAP4rev1 permits manipulation of mailboxes (remote
&nbsp;&nbsp; message folders) in a way that is functionally equivalent to local
&nbsp;&nbsp; folders.&nbsp; IMAP4rev1 also provides the capability for an offline
&nbsp;&nbsp; client to resynchronize with the server.</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; IMAP4rev1 includes operations for creating, deleting, and renaming
&nbsp;&nbsp; mailboxes, checking for new messages, permanently removing messages,
&nbsp;&nbsp; setting and clearing flags, RFC 2822 and RFC 2045 parsing, searching,
&nbsp;&nbsp; and selective fetching of message attributes, texts, and portions
&nbsp;&nbsp; thereof.&nbsp; Messages in IMAP4rev1 are accessed by the use of numbers.
&nbsp;&nbsp; These numbers are either message sequence numbers or unique
&nbsp;&nbsp; identifiers.</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; IMAP4rev1 supports a single server.&nbsp; A mechanism for accessing
&nbsp;&nbsp; configuration information to support multiple IMAP4rev1 servers is
&nbsp;&nbsp; discussed in RFC 2244.</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; IMAP4rev1 does not specify a means of posting mail; this function is
&nbsp;&nbsp; handled by a mail transfer protocol such as RFC 2821.</FONT></P>
<P><FONT face="courier new,courier"></FONT>&nbsp;</P>
<P><FONT face="courier new,courier"></FONT>&nbsp;</P>
<P><FONT face="courier new,courier"></FONT>&nbsp;</P>
<P>
<FONT face="courier new,courier">Crispin&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Standards Track&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [Page 1]
RFC 3501&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IMAPv4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; March 2003</FONT></P>
<P>
<FONT face="courier new,courier">Table of Contents</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; IMAP4rev1 Protocol Specification ................................&nbsp; 4
&nbsp;&nbsp; 1.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; How to Read This Document ...............................&nbsp; 4
&nbsp;&nbsp; 1.1.&nbsp;&nbsp;&nbsp; Organization of This Document ...........................&nbsp; 4
&nbsp;&nbsp; 1.2.&nbsp;&nbsp;&nbsp; Conventions Used in This Document .......................&nbsp; 4
&nbsp;&nbsp; 1.3.&nbsp;&nbsp;&nbsp; Special Notes to Implementors ...........................&nbsp; 5
&nbsp;&nbsp; 2.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Protocol Overview .......................................&nbsp; 6
&nbsp;&nbsp; 2.1.&nbsp;&nbsp;&nbsp; Link Level ..............................................&nbsp; 6
&nbsp;&nbsp; 2.2.&nbsp;&nbsp;&nbsp; Commands and Responses ..................................&nbsp; 6
&nbsp;&nbsp; 2.2.1.&nbsp; Client Protocol Sender and Server Protocol Receiver .....&nbsp; 6
&nbsp;&nbsp; 2.2.2.&nbsp; Server Protocol Sender and Client Protocol Receiver .....&nbsp; 7
&nbsp;&nbsp; 2.3.&nbsp;&nbsp;&nbsp; Message Attributes ......................................&nbsp; 8
&nbsp;&nbsp; 2.3.1.&nbsp; Message Numbers .........................................&nbsp; 8
&nbsp;&nbsp; 2.3.1.1.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Unique Identifier (UID) Message Attribute .......&nbsp; 8
&nbsp;&nbsp; 2.3.1.2.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Message Sequence Number Message Attribute ....... 10
&nbsp;&nbsp; 2.3.2.&nbsp; Flags Message Attribute ................................. 11
&nbsp;&nbsp; 2.3.3.&nbsp; Internal Date Message Attribute ......................... 12
&nbsp;&nbsp; 2.3.4.&nbsp; [RFC-2822] Size Message Attribute ....................... 12
&nbsp;&nbsp; 2.3.5.&nbsp; Envelope Structure Message Attribute .................... 12
&nbsp;&nbsp; 2.3.6.&nbsp; Body Structure Message Attribute ........................ 12
&nbsp;&nbsp; 2.4.&nbsp;&nbsp;&nbsp; Message Texts ........................................... 13
&nbsp;&nbsp; 3.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; State and Flow Diagram .................................. 13
&nbsp;&nbsp; 3.1.&nbsp;&nbsp;&nbsp; Not Authenticated State ................................. 13
&nbsp;&nbsp; 3.2.&nbsp;&nbsp;&nbsp; Authenticated State ..................................... 13
&nbsp;&nbsp; 3.3.&nbsp;&nbsp;&nbsp; Selected State .......................................... 13
&nbsp;&nbsp; 3.4.&nbsp;&nbsp;&nbsp; Logout State ............................................ 14
&nbsp;&nbsp; 4.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Data Formats ............................................ 16
&nbsp;&nbsp; 4.1.&nbsp;&nbsp;&nbsp; Atom .................................................... 16
&nbsp;&nbsp; 4.2.&nbsp;&nbsp;&nbsp; Number .................................................. 16
&nbsp;&nbsp; 4.3.&nbsp;&nbsp;&nbsp; String .................................................. 16
&nbsp;&nbsp; 4.3.1.&nbsp; 8-bit and Binary Strings ................................ 17
&nbsp;&nbsp; 4.4.&nbsp;&nbsp;&nbsp; Parenthesized List ...................................... 17
&nbsp;&nbsp; 4.5.&nbsp;&nbsp;&nbsp; NIL ..................................................... 17
&nbsp;&nbsp; 5.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Operational Considerations .............................. 18
&nbsp;&nbsp; 5.1.&nbsp;&nbsp;&nbsp; Mailbox Naming .......................................... 18
&nbsp;&nbsp; 5.1.1.&nbsp; Mailbox Hierarchy Naming ................................ 19
&nbsp;&nbsp; 5.1.2.&nbsp; Mailbox Namespace Naming Convention ..................... 19
&nbsp;&nbsp; 5.1.3.&nbsp; Mailbox International Naming Convention ................. 19
&nbsp;&nbsp; 5.2.&nbsp;&nbsp;&nbsp; Mailbox Size and Message Status Updates ................. 21
&nbsp;&nbsp; 5.3.&nbsp;&nbsp;&nbsp; Response when no Command in Progress .................... 21
&nbsp;&nbsp; 5.4.&nbsp;&nbsp;&nbsp; Autologout Timer ........................................ 22
&nbsp;&nbsp; 5.5.&nbsp;&nbsp;&nbsp; Multiple Commands in Progress ........................... 22
&nbsp;&nbsp; 6.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Client Commands ........................................&nbsp; 23
&nbsp;&nbsp; 6.1.&nbsp;&nbsp;&nbsp; Client Commands - Any State ............................&nbsp; 24
&nbsp;&nbsp; 6.1.1.&nbsp; CAPABILITY Command .....................................&nbsp; 24
&nbsp;&nbsp; 6.1.2.&nbsp; NOOP Command ...........................................&nbsp; 25
&nbsp;&nbsp; 6.1.3.&nbsp; LOGOUT Command .........................................&nbsp; 26</FONT></P>
<P><FONT face="courier new,courier"></FONT>&nbsp;</P>
<P><FONT face="courier new,courier">Crispin&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Standards Track&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [Page 2]
RFC 3501&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IMAPv4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; March 2003</FONT></P>
<P>
<FONT face="courier new,courier">&nbsp;&nbsp; 6.2.&nbsp;&nbsp;&nbsp; Client Commands - Not Authenticated State ..............&nbsp; 26
&nbsp;&nbsp; 6.2.1.&nbsp; STARTTLS Command .......................................&nbsp; 27
&nbsp;&nbsp; 6.2.2.&nbsp; AUTHENTICATE Command ...................................&nbsp; 28
&nbsp;&nbsp; 6.2.3.&nbsp; LOGIN Command ..........................................&nbsp; 30
&nbsp;&nbsp; 6.3.&nbsp;&nbsp;&nbsp; Client Commands - Authenticated State ..................&nbsp; 31
&nbsp;&nbsp; 6.3.1.&nbsp; SELECT Command .........................................&nbsp; 32
&nbsp;&nbsp; 6.3.2.&nbsp; EXAMINE Command ........................................&nbsp; 34
&nbsp;&nbsp; 6.3.3.&nbsp; CREATE Command .........................................&nbsp; 34
&nbsp;&nbsp; 6.3.4.&nbsp; DELETE Command .........................................&nbsp; 35
&nbsp;&nbsp; 6.3.5.&nbsp; RENAME Command .........................................&nbsp; 37
&nbsp;&nbsp; 6.3.6.&nbsp; SUBSCRIBE Command ......................................&nbsp; 39
&nbsp;&nbsp; 6.3.7.&nbsp; UNSUBSCRIBE Command ....................................&nbsp; 39
&nbsp;&nbsp; 6.3.8.&nbsp; LIST Command ...........................................&nbsp; 40
&nbsp;&nbsp; 6.3.9.&nbsp; LSUB Command ...........................................&nbsp; 43
&nbsp;&nbsp; 6.3.10. STATUS Command .........................................&nbsp; 44
&nbsp;&nbsp; 6.3.11. APPEND Command .........................................&nbsp; 46
&nbsp;&nbsp; 6.4.&nbsp;&nbsp;&nbsp; Client Commands - Selected State .......................&nbsp; 47
&nbsp;&nbsp; 6.4.1.&nbsp; CHECK Command ..........................................&nbsp; 47
&nbsp;&nbsp; 6.4.2.&nbsp; CLOSE Command ..........................................&nbsp; 48
&nbsp;&nbsp; 6.4.3.&nbsp; EXPUNGE Command ........................................&nbsp; 49
&nbsp;&nbsp; 6.4.4.&nbsp; SEARCH Command .........................................&nbsp; 49
&nbsp;&nbsp; 6.4.5.&nbsp; FETCH Command ..........................................&nbsp; 54
&nbsp;&nbsp; 6.4.6.&nbsp; STORE Command ..........................................&nbsp; 58
&nbsp;&nbsp; 6.4.7.&nbsp; COPY Command ...........................................&nbsp; 59
&nbsp;&nbsp; 6.4.8.&nbsp; UID Command ............................................&nbsp; 60
&nbsp;&nbsp; 6.5.&nbsp;&nbsp;&nbsp; Client Commands - Experimental/Expansion ...............&nbsp; 62
&nbsp;&nbsp; 6.5.1.&nbsp; X&lt;atom&gt; Command ........................................&nbsp; 62
&nbsp;&nbsp; 7.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Server Responses .......................................&nbsp; 62
&nbsp;&nbsp; 7.1.&nbsp;&nbsp;&nbsp; Server Responses - Status Responses ....................&nbsp; 63
&nbsp;&nbsp; 7.1.1.&nbsp; OK Response ............................................&nbsp; 65
&nbsp;&nbsp; 7.1.2.&nbsp; NO Response ............................................&nbsp; 66
&nbsp;&nbsp; 7.1.3.&nbsp; BAD Response ...........................................&nbsp; 66
&nbsp;&nbsp; 7.1.4.&nbsp; PREAUTH Response .......................................&nbsp; 67
&nbsp;&nbsp; 7.1.5.&nbsp; BYE Response ...........................................&nbsp; 67
&nbsp;&nbsp; 7.2.&nbsp;&nbsp;&nbsp; Server Responses - Server and Mailbox Status ...........&nbsp; 68
&nbsp;&nbsp; 7.2.1.&nbsp; CAPABILITY Response ....................................&nbsp; 68
&nbsp;&nbsp; 7.2.2.&nbsp; LIST Response ..........................................&nbsp; 69
&nbsp;&nbsp; 7.2.3.&nbsp; LSUB Response ..........................................&nbsp; 70
&nbsp;&nbsp; 7.2.4&nbsp;&nbsp; STATUS Response ........................................&nbsp; 70
&nbsp;&nbsp; 7.2.5.&nbsp; SEARCH Response ........................................&nbsp; 71
&nbsp;&nbsp; 7.2.6.&nbsp; FLAGS Response .........................................&nbsp; 71
&nbsp;&nbsp; 7.3.&nbsp;&nbsp;&nbsp; Server Responses - Mailbox Size ........................&nbsp; 71
&nbsp;&nbsp; 7.3.1.&nbsp; EXISTS Response ........................................&nbsp; 71
&nbsp;&nbsp; 7.3.2.&nbsp; RECENT Response ........................................&nbsp; 72
&nbsp;&nbsp; 7.4.&nbsp;&nbsp;&nbsp; Server Responses - Message Status ......................&nbsp; 72
&nbsp;&nbsp; 7.4.1.&nbsp; EXPUNGE Response .......................................&nbsp; 72
&nbsp;&nbsp; 7.4.2.&nbsp; FETCH Response .........................................&nbsp; 73
&nbsp;&nbsp; 7.5.&nbsp;&nbsp;&nbsp; Server Responses - Command Continuation Request ........&nbsp; 79</FONT></P>
<P><FONT face="courier new,courier"></FONT>&nbsp;</P>
<P><FONT face="courier new,courier">Crispin&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Standards Track&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [Page 3]
RFC 3501&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IMAPv4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; March 2003</FONT></P>
<P>
<FONT face="courier new,courier">&nbsp;&nbsp; 8.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sample IMAP4rev1 connection ............................&nbsp; 80
&nbsp;&nbsp; 9.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Formal Syntax ..........................................&nbsp; 81
&nbsp;&nbsp; 10.&nbsp;&nbsp;&nbsp;&nbsp; Author's Note ..........................................&nbsp; 92
&nbsp;&nbsp; 11.&nbsp;&nbsp;&nbsp;&nbsp; Security Considerations ................................&nbsp; 92
&nbsp;&nbsp; 11.1.&nbsp;&nbsp; STARTTLS Security Considerations .......................&nbsp; 92
&nbsp;&nbsp; 11.2.&nbsp;&nbsp; Other Security Considerations ..........................&nbsp; 93
&nbsp;&nbsp; 12.&nbsp;&nbsp;&nbsp;&nbsp; IANA Considerations ....................................&nbsp; 94
&nbsp;&nbsp; Appendices .....................................................&nbsp; 95
&nbsp;&nbsp; A.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; References .............................................&nbsp; 95
&nbsp;&nbsp; B.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Changes from RFC 2060 ..................................&nbsp; 97
&nbsp;&nbsp; C.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Key Word Index ......................................... 103
&nbsp;&nbsp; Author's Address ............................................... 107
&nbsp;&nbsp; Full Copyright Statement ....................................... 108</FONT></P>
<P><FONT face="courier new,courier">IMAP4rev1 Protocol Specification</FONT></P>
<P><FONT face="courier new,courier">1.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; How to Read This Document</FONT></P>
<P><FONT face="courier new,courier">1.1.&nbsp;&nbsp;&nbsp; Organization of This Document</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; This document is written from the point of view of the implementor of
&nbsp;&nbsp; an IMAP4rev1 client or server.&nbsp; Beyond the protocol overview in
&nbsp;&nbsp; section 2, it is not optimized for someone trying to understand the
&nbsp;&nbsp; operation of the protocol.&nbsp; The material in sections 3 through 5
&nbsp;&nbsp; provides the general context and definitions with which IMAP4rev1
&nbsp;&nbsp; operates.</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; Sections 6, 7, and 9 describe the IMAP commands, responses, and
&nbsp;&nbsp; syntax, respectively.&nbsp; The relationships among these are such that it
&nbsp;&nbsp; is almost impossible to understand any of them separately.&nbsp; In
&nbsp;&nbsp; particular, do not attempt to deduce command syntax from the command
&nbsp;&nbsp; section alone; instead refer to the Formal Syntax section.</FONT></P>
<P><FONT face="courier new,courier">1.2.&nbsp;&nbsp;&nbsp; Conventions Used in This Document</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; "Conventions" are basic principles or procedures.&nbsp; Document
&nbsp;&nbsp; conventions are noted in this section.</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; In examples, "C:" and "S:" indicate lines sent by the client and
&nbsp;&nbsp; server respectively.</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
&nbsp;&nbsp; "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to
&nbsp;&nbsp; be interpreted as described in [KEYWORDS].</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; The word "can" (not "may") is used to refer to a possible
&nbsp;&nbsp; circumstance or situation, as opposed to an optional facility of the
&nbsp;&nbsp; protocol.</FONT></P>
<P><FONT face="courier new,courier"></FONT>&nbsp;</P>
<P><FONT face="courier new,courier">Crispin&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Standards Track&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [Page 4]
RFC 3501&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IMAPv4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; March 2003</FONT></P>
<P>
<FONT face="courier new,courier">&nbsp;&nbsp; "User" is used to refer to a human user, whereas "client" refers to
&nbsp;&nbsp; the software being run by the user.</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; "Connection" refers to the entire sequence of client/server
&nbsp;&nbsp; interaction from the initial establishment of the network connection
&nbsp;&nbsp; until its termination.</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; "Session" refers to the sequence of client/server interaction from
&nbsp;&nbsp; the time that a mailbox is selected (SELECT or EXAMINE command) until
&nbsp;&nbsp; the time that selection ends (SELECT or EXAMINE of another mailbox,
&nbsp;&nbsp; CLOSE command, or connection termination).</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; Characters are 7-bit US-ASCII unless otherwise specified.&nbsp; Other
&nbsp;&nbsp; character sets are indicated using a "CHARSET", as described in
&nbsp;&nbsp; [MIME-IMT] and defined in [CHARSET].&nbsp; CHARSETs have important
&nbsp;&nbsp; additional semantics in addition to defining character set; refer to
&nbsp;&nbsp; these documents for more detail.</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; There are several protocol conventions in IMAP.&nbsp; These refer to
&nbsp;&nbsp; aspects of the specification which are not strictly part of the IMAP
&nbsp;&nbsp; protocol, but reflect generally-accepted practice.&nbsp; Implementations
&nbsp;&nbsp; need to be aware of these conventions, and avoid conflicts whether or
&nbsp;&nbsp; not they implement the convention.&nbsp; For example, "&amp;" may not be used
&nbsp;&nbsp; as a hierarchy delimiter since it conflicts with the Mailbox
&nbsp;&nbsp; International Naming Convention, and other uses of "&amp;" in mailbox
&nbsp;&nbsp; names are impacted as well.</FONT></P>
<P><FONT face="courier new,courier">1.3.&nbsp;&nbsp;&nbsp; Special Notes to Implementors</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; Implementors of the IMAP protocol are strongly encouraged to read the
&nbsp;&nbsp; IMAP implementation recommendations document [IMAP-IMPLEMENTATION] in
&nbsp;&nbsp; conjunction with this document, to help understand the intricacies of
&nbsp;&nbsp; this protocol and how best to build an interoperable product.</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; IMAP4rev1 is designed to be upwards compatible from the [IMAP2] and
&nbsp;&nbsp; unpublished IMAP2bis protocols.&nbsp; IMAP4rev1 is largely compatible with
&nbsp;&nbsp; the IMAP4 protocol described in RFC 1730; the exception being in
&nbsp;&nbsp; certain facilities added in RFC 1730 that proved problematic and were
&nbsp;&nbsp; subsequently removed.&nbsp; In the course of the evolution of IMAP4rev1,
&nbsp;&nbsp; some aspects in the earlier protocols have become obsolete.&nbsp; Obsolete
&nbsp;&nbsp; commands, responses, and data formats which an IMAP4rev1
&nbsp;&nbsp; implementation can encounter when used with an earlier implementation
&nbsp;&nbsp; are described in [IMAP-OBSOLETE].</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; Other compatibility issues with IMAP2bis, the most common variant of
&nbsp;&nbsp; the earlier protocol, are discussed in [IMAP-COMPAT].&nbsp; A full
&nbsp;&nbsp; discussion of compatibility issues with rare (and presumed extinct)</FONT></P>
<P><FONT face="courier new,courier"></FONT>&nbsp;</P>
<P>
<FONT face="courier new,courier">Crispin&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Standards Track&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [Page 5]
RFC 3501&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IMAPv4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; March 2003</FONT></P>
<P>
<FONT face="courier new,courier">&nbsp;&nbsp; variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is
&nbsp;&nbsp; primarily of historical interest.</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; IMAP was originally developed for the older [RFC-822] standard, and
&nbsp;&nbsp; as a consequence several fetch items in IMAP incorporate "RFC822" in
&nbsp;&nbsp; their name.&nbsp; With the exception of RFC822.SIZE, there are more modern
&nbsp;&nbsp; replacements; for example, the modern version of RFC822.HEADER is
&nbsp;&nbsp; BODY.PEEK[HEADER].&nbsp; In all cases, "RFC822" should be interpreted as a
&nbsp;&nbsp; reference to the updated [RFC-2822] standard.</FONT></P>
<P><FONT face="courier new,courier">2.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Protocol Overview</FONT></P>
<P><FONT face="courier new,courier">2.1.&nbsp;&nbsp;&nbsp; Link Level</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; The IMAP4rev1 protocol assumes a reliable data stream such as that
&nbsp;&nbsp; provided by TCP.&nbsp; When TCP is used, an IMAP4rev1 server listens on
&nbsp;&nbsp; port 143.</FONT></P>
<P><FONT face="courier new,courier">2.2.&nbsp;&nbsp;&nbsp; Commands and Responses</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; An IMAP4rev1 connection consists of the establishment of a
&nbsp;&nbsp; client/server network connection, an initial greeting from the
&nbsp;&nbsp; server, and client/server interactions.&nbsp; These client/server
&nbsp;&nbsp; interactions consist of a client command, server data, and a server
&nbsp;&nbsp; completion result response.</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; All interactions transmitted by client and server are in the form of
&nbsp;&nbsp; lines, that is, strings that end with a CRLF.&nbsp; The protocol receiver
&nbsp;&nbsp; of an IMAP4rev1 client or server is either reading a line, or is
&nbsp;&nbsp; reading a sequence of octets with a known count followed by a line.</FONT></P>
<P><FONT face="courier new,courier">2.2.1.&nbsp; Client Protocol Sender and Server Protocol Receiver</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; The client command begins an operation.&nbsp; Each client command is
&nbsp;&nbsp; prefixed with an identifier (typically a short alphanumeric string,
&nbsp;&nbsp; e.g., A0001, A0002, etc.) called a "tag".&nbsp; A different tag is
&nbsp;&nbsp; generated by the client for each command.</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; Clients MUST follow the syntax outlined in this specification
&nbsp;&nbsp; strictly.&nbsp; It is a syntax error to send a command with missing or
&nbsp;&nbsp; extraneous spaces or arguments.</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; There are two cases in which a line from the client does not
&nbsp;&nbsp; represent a complete command.&nbsp; In one case, a command argument is
&nbsp;&nbsp; quoted with an octet count (see the description of literal in String
&nbsp;&nbsp; under Data Formats); in the other case, the command arguments require
&nbsp;&nbsp; server feedback (see the AUTHENTICATE command).&nbsp; In either case, the</FONT></P>
<P><FONT face="courier new,courier"></FONT>&nbsp;</P>
<P>
<FONT face="courier new,courier">Crispin&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Standards Track&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [Page 6]
RFC 3501&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IMAPv4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; March 2003</FONT></P>
<P>
<FONT face="courier new,courier">&nbsp;&nbsp; server sends a command continuation request response if it is ready
&nbsp;&nbsp; for the octets (if appropriate) and the remainder of the command.
&nbsp;&nbsp; This response is prefixed with the token "+".</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Note: If instead, the server detected an error in the
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; command, it sends a BAD completion response with a tag
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; matching the command (as described below) to reject the
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; command and prevent the client from sending any more of the
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; command.</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; It is also possible for the server to send a completion
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; response for some other command (if multiple commands are
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; in progress), or untagged data.&nbsp; In either case, the
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; command continuation request is still pending; the client
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; takes the appropriate action for the response, and reads
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; another response from the server.&nbsp; In all cases, the client
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MUST send a complete command (including receiving all
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; command continuation request responses and command
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; continuations for the command) before initiating a new
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; command.</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; The protocol receiver of an IMAP4rev1 server reads a command line
&nbsp;&nbsp; from the client, parses the command and its arguments, and transmits
&nbsp;&nbsp; server data and a server command completion result response.</FONT></P>
<P><FONT face="courier new,courier">2.2.2.&nbsp; Server Protocol Sender and Client Protocol Receiver</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; Data transmitted by the server to the client and status responses
&nbsp;&nbsp; that do not indicate command completion are prefixed with the token
&nbsp;&nbsp; "*", and are called untagged responses.</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; Server data MAY be sent as a result of a client command, or MAY be
&nbsp;&nbsp; sent unilaterally by the server.&nbsp; There is no syntactic difference
&nbsp;&nbsp; between server data that resulted from a specific command and server
&nbsp;&nbsp; data that were sent unilaterally.</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; The server completion result response indicates the success or
&nbsp;&nbsp; failure of the operation.&nbsp; It is tagged with the same tag as the
&nbsp;&nbsp; client command which began the operation.&nbsp; Thus, if more than one
&nbsp;&nbsp; command is in progress, the tag in a server completion response
&nbsp;&nbsp; identifies the command to which the response applies.&nbsp; There are
&nbsp;&nbsp; three possible server completion responses: OK (indicating success),
&nbsp;&nbsp; NO (indicating failure), or BAD (indicating a protocol error such as
&nbsp;&nbsp; unrecognized command or command syntax error).</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; Servers SHOULD enforce the syntax outlined in this specification
&nbsp;&nbsp; strictly.&nbsp; Any client command with a protocol syntax error, including
&nbsp;&nbsp; (but not limited to) missing or extraneous spaces or arguments,</FONT></P>
<P><FONT face="courier new,courier"></FONT>&nbsp;</P>
<P><FONT face="courier new,courier">Crispin&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Standards Track&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [Page 7]
RFC 3501&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IMAPv4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; March 2003</FONT></P>
<P>
<FONT face="courier new,courier">&nbsp;&nbsp; SHOULD be rejected, and the client given a BAD server completion
&nbsp;&nbsp; response.</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; The protocol receiver of an IMAP4rev1 client reads a response line
&nbsp;&nbsp; from the server.&nbsp; It then takes action on the response based upon the
&nbsp;&nbsp; first token of the response, which can be a tag, a "*", or a "+".</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; A client MUST be prepared to accept any server response at all times.
&nbsp;&nbsp; This includes server data that was not requested.&nbsp; Server data SHOULD
&nbsp;&nbsp; be recorded, so that the client can reference its recorded copy
&nbsp;&nbsp; rather than sending a command to the server to request the data.&nbsp; In
&nbsp;&nbsp; the case of certain server data, the data MUST be recorded.</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; This topic is discussed in greater detail in the Server Responses
&nbsp;&nbsp; section.</FONT></P>
<P><FONT face="courier new,courier">2.3.&nbsp;&nbsp;&nbsp; Message Attributes</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; In addition to message text, each message has several attributes
&nbsp;&nbsp; associated with it.&nbsp; These attributes can be retrieved individually
&nbsp;&nbsp; or in conjunction with other attributes or message texts.</FONT></P>
<P><FONT face="courier new,courier">2.3.1.&nbsp; Message Numbers</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; Messages in IMAP4rev1 are accessed by one of two numbers; the unique
&nbsp;&nbsp; identifier or the message sequence number.</FONT></P>
<P>
<FONT face="courier new,courier">2.3.1.1.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Unique Identifier (UID) Message Attribute</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; A 32-bit value assigned to each message, which when used with the
&nbsp;&nbsp; unique identifier validity value (see below) forms a 64-bit value
&nbsp;&nbsp; that MUST NOT refer to any other message in the mailbox or any
&nbsp;&nbsp; subsequent mailbox with the same name forever.&nbsp; Unique identifiers
&nbsp;&nbsp; are assigned in a strictly ascending fashion in the mailbox; as each
&nbsp;&nbsp; message is added to the mailbox it is assigned a higher UID than the
&nbsp;&nbsp; message(s) which were added previously.&nbsp; Unlike message sequence
&nbsp;&nbsp; numbers, unique identifiers are not necessarily contiguous.</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; The unique identifier of a message MUST NOT change during the
&nbsp;&nbsp; session, and SHOULD NOT change between sessions.&nbsp; Any change of
&nbsp;&nbsp; unique identifiers between sessions MUST be detectable using the
&nbsp;&nbsp; UIDVALIDITY mechanism discussed below.&nbsp; Persistent unique identifiers
&nbsp;&nbsp; are required for a client to resynchronize its state from a previous
&nbsp;&nbsp; session with the server (e.g., disconnected or offline access
&nbsp;&nbsp; clients); this is discussed further in [IMAP-DISC].</FONT></P>
<P><FONT face="courier new,courier"></FONT>&nbsp;</P>
<P><FONT face="courier new,courier"></FONT>&nbsp;</P>
<P><FONT face="courier new,courier">Crispin&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Standards Track&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [Page 8]
RFC 3501&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IMAPv4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; March 2003</FONT></P>
<P>
<FONT face="courier new,courier">&nbsp;&nbsp; Associated with every mailbox are two values which aid in unique
&nbsp;&nbsp; identifier handling: the next unique identifier value and the unique
&nbsp;&nbsp; identifier validity value.</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; The next unique identifier value is the predicted value that will be
&nbsp;&nbsp; assigned to a new message in the mailbox.&nbsp; Unless the unique
&nbsp;&nbsp; identifier validity also changes (see below), the next unique
&nbsp;&nbsp; identifier value MUST have the following two characteristics.&nbsp; First,
&nbsp;&nbsp; the next unique identifier value MUST NOT change unless new messages
&nbsp;&nbsp; are added to the mailbox; and second, the next unique identifier
&nbsp;&nbsp; value MUST change whenever new messages are added to the mailbox,
&nbsp;&nbsp; even if those new messages are subsequently expunged.</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Note: The next unique identifier value is intended to
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; provide a means for a client to determine whether any
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; messages have been delivered to the mailbox since the
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; previous time it checked this value.&nbsp; It is not intended to
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; provide any guarantee that any message will have this
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; unique identifier.&nbsp; A client can only assume, at the time
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; that it obtains the next unique identifier value, that
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; messages arriving after that time will have a UID greater
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; than or equal to that value.</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; The unique identifier validity value is sent in a UIDVALIDITY
&nbsp;&nbsp; response code in an OK untagged response at mailbox selection time.
&nbsp;&nbsp; If unique identifiers from an earlier session fail to persist in this
&nbsp;&nbsp; session, the unique identifier validity value MUST be greater than
&nbsp;&nbsp; the one used in the earlier session.</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Note: Ideally, unique identifiers SHOULD persist at all
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; times.&nbsp; Although this specification recognizes that failure
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to persist can be unavoidable in certain server
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; environments, it STRONGLY ENCOURAGES message store
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; implementation techniques that avoid this problem.&nbsp; For
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; example:</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1) Unique identifiers MUST be strictly ascending in the
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; mailbox at all times.&nbsp; If the physical message store is
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; re-ordered by a non-IMAP agent, this requires that the
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; unique identifiers in the mailbox be regenerated, since
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the former unique identifiers are no longer strictly
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ascending as a result of the re-ordering.</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2) If the message store has no mechanism to store unique
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; identifiers, it must regenerate unique identifiers at
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; each session, and each session must have a unique
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; UIDVALIDITY value.</FONT></P>
<P><FONT face="courier new,courier"></FONT>&nbsp;</P>
<P>
<FONT face="courier new,courier">Crispin&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Standards Track&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [Page 9]
RFC 3501&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IMAPv4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; March 2003</FONT></P>
<P>
<FONT face="courier new,courier">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3) If the mailbox is deleted and a new mailbox with the
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; same name is created at a later date, the server must
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; either keep track of unique identifiers from the
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; previous instance of the mailbox, or it must assign a
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; new UIDVALIDITY value to the new instance of the
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; mailbox.&nbsp; A good UIDVALIDITY value to use in this case
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; is a 32-bit representation of the creation date/time of
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the mailbox.&nbsp; It is alright to use a constant such as
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1, but only if it guaranteed that unique identifiers
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; will never be reused, even in the case of a mailbox
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; being deleted (or renamed) and a new mailbox by the
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; same name created at some future time.</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4) The combination of mailbox name, UIDVALIDITY, and UID
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; must refer to a single immutable message on that server
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; forever.&nbsp; In particular, the internal date, [RFC-2822]
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; size, envelope, body structure, and message texts
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (RFC822, RFC822.HEADER, RFC822.TEXT, and all BODY[...]
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fetch data items) must never change.&nbsp; This does not
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; include message numbers, nor does it include attributes
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; that can be set by a STORE command (e.g., FLAGS).</FONT></P>
<P>
<FONT face="courier new,courier">2.3.1.2.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Message Sequence Number Message Attribute</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; A relative position from 1 to the number of messages in the mailbox.
&nbsp;&nbsp; This position MUST be ordered by ascending unique identifier.&nbsp; As
&nbsp;&nbsp; each new message is added, it is assigned a message sequence number
&nbsp;&nbsp; that is 1 higher than the number of messages in the mailbox before
&nbsp;&nbsp; that new message was added.</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; Message sequence numbers can be reassigned during the session.&nbsp; For
&nbsp;&nbsp; example, when a message is permanently removed (expunged) from the
&nbsp;&nbsp; mailbox, the message sequence number for all subsequent messages is
&nbsp;&nbsp; decremented.&nbsp; The number of messages in the mailbox is also
&nbsp;&nbsp; decremented.&nbsp; Similarly, a new message can be assigned a message
&nbsp;&nbsp; sequence number that was once held by some other message prior to an
&nbsp;&nbsp; expunge.</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; In addition to accessing messages by relative position in the
&nbsp;&nbsp; mailbox, message sequence numbers can be used in mathematical
&nbsp;&nbsp; calculations.&nbsp; For example, if an untagged "11 EXISTS" is received,
&nbsp;&nbsp; and previously an untagged "8 EXISTS" was received, three new
&nbsp;&nbsp; messages have arrived with message sequence numbers of 9, 10, and 11.
&nbsp;&nbsp; Another example, if message 287 in a 523 message mailbox has UID
&nbsp;&nbsp; 12345, there are exactly 286 messages which have lesser UIDs and 236
&nbsp;&nbsp; messages which have greater UIDs.</FONT></P>
<P><FONT face="courier new,courier"></FONT>&nbsp;</P>
<P>
<FONT face="courier new,courier">Crispin&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Standards Track&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [Page 10]
RFC 3501&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IMAPv4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; March 2003</FONT></P>
<P>
<FONT face="courier new,courier">2.3.2.&nbsp; Flags Message Attribute</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; A list of zero or more named tokens associated with the message.&nbsp; A
&nbsp;&nbsp; flag is set by its addition to this list, and is cleared by its
&nbsp;&nbsp; removal.&nbsp; There are two types of flags in IMAP4rev1.&nbsp; A flag of
&nbsp;&nbsp; either type can be permanent or session-only.</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; A system flag is a flag name that is pre-defined in this
&nbsp;&nbsp; specification.&nbsp; All system flags begin with "\".&nbsp; Certain system
&nbsp;&nbsp; flags (\Deleted and \Seen) have special semantics described
&nbsp;&nbsp; elsewhere.&nbsp; The currently-defined system flags are:</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \Seen
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Message has been read</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \Answered
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Message has been answered</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \Flagged
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Message is "flagged" for urgent/special attention</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \Deleted
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Message is "deleted" for removal by later EXPUNGE</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \Draft
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Message has not completed composition (marked as a draft).</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \Recent
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Message is "recently" arrived in this mailbox.&nbsp; This session
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; is the first session to have been notified about this
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; message; if the session is read-write, subsequent sessions
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; will not see \Recent set for this message.&nbsp; This flag can not
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; be altered by the client.</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If it is not possible to determine whether or not this
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; session is the first session to be notified about a message,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; then that message SHOULD be considered recent.</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If multiple connections have the same mailbox selected
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; simultaneously, it is undefined which of these connections
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; will see newly-arrived messages with \Recent set and which
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; will see it without \Recent set.</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; A keyword is defined by the server implementation.&nbsp; Keywords do not
&nbsp;&nbsp; begin with "\".&nbsp; Servers MAY permit the client to define new keywords
&nbsp;&nbsp; in the mailbox (see the description of the PERMANENTFLAGS response
&nbsp;&nbsp; code for more information).</FONT></P>
<P><FONT face="courier new,courier"></FONT>&nbsp;</P>
<P>
<FONT face="courier new,courier">Crispin&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Standards Track&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [Page 11]
RFC 3501&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IMAPv4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; March 2003</FONT></P>
<P>
<FONT face="courier new,courier">&nbsp;&nbsp; A flag can be permanent or session-only on a per-flag basis.
&nbsp;&nbsp; Permanent flags are those which the client can add or remove from the
&nbsp;&nbsp; message flags permanently; that is, concurrent and subsequent
&nbsp;&nbsp; sessions will see any change in permanent flags.&nbsp; Changes to session
&nbsp;&nbsp; flags are valid only in that session.</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Note: The \Recent system flag is a special case of a
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; session flag.&nbsp; \Recent can not be used as an argument in a
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; STORE or APPEND command, and thus can not be changed at
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; all.</FONT></P>
<P><FONT face="courier new,courier">2.3.3.&nbsp; Internal Date Message Attribute</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; The internal date and time of the message on the server.&nbsp; This
&nbsp;&nbsp; is not the date and time in the [RFC-2822] header, but rather a
&nbsp;&nbsp; date and time which reflects when the message was received.&nbsp; In
&nbsp;&nbsp; the case of messages delivered via [SMTP], this SHOULD be the
&nbsp;&nbsp; date and time of final delivery of the message as defined by
&nbsp;&nbsp; [SMTP].&nbsp; In the case of messages delivered by the IMAP4rev1 COPY
&nbsp;&nbsp; command, this SHOULD be the internal date and time of the source
&nbsp;&nbsp; message.&nbsp; In the case of messages delivered by the IMAP4rev1
&nbsp;&nbsp; APPEND command, this SHOULD be the date and time as specified in
&nbsp;&nbsp; the APPEND command description.&nbsp; All other cases are
&nbsp;&nbsp; implementation defined.</FONT></P>
<P><FONT face="courier new,courier">2.3.4.&nbsp; [RFC-2822] Size Message Attribute</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; The number of octets in the message, as expressed in [RFC-2822]
&nbsp;&nbsp; format.</FONT></P>
<P><FONT face="courier new,courier">2.3.5.&nbsp; Envelope Structure Message Attribute</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; A parsed representation of the [RFC-2822] header of the message.
&nbsp;&nbsp; Note that the IMAP Envelope structure is not the same as an
&nbsp;&nbsp; [SMTP] envelope.</FONT></P>
<P><FONT face="courier new,courier">2.3.6.&nbsp; Body Structure Message Attribute</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; A parsed representation of the [MIME-IMB] body structure
&nbsp;&nbsp; information of the message.</FONT></P>
<P><FONT face="courier new,courier"></FONT>&nbsp;</P>
<P><FONT face="courier new,courier"></FONT>&nbsp;</P>
<P><FONT face="courier new,courier"></FONT>&nbsp;</P>
<P><FONT face="courier new,courier"></FONT>&nbsp;</P>
<P><FONT face="courier new,courier"></FONT>&nbsp;</P>
<P><FONT face="courier new,courier">Crispin&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Standards Track&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [Page 12]
RFC 3501&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IMAPv4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; March 2003</FONT></P>
<P>
<FONT face="courier new,courier">2.4.&nbsp;&nbsp;&nbsp; Message Texts</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; In addition to being able to fetch the full [RFC-2822] text of a
&nbsp;&nbsp; message, IMAP4rev1 permits the fetching of portions of the full
&nbsp;&nbsp; message text.&nbsp; Specifically, it is possible to fetch the
&nbsp;&nbsp; [RFC-2822] message header, [RFC-2822] message body, a [MIME-IMB]
&nbsp;&nbsp; body part, or a [MIME-IMB] header.</FONT></P>
<P><FONT face="courier new,courier">3.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; State and Flow Diagram</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; Once the connection between client and server is established, an
&nbsp;&nbsp; IMAP4rev1 connection is in one of four states.&nbsp; The initial
&nbsp;&nbsp; state is identified in the server greeting.&nbsp; Most commands are
&nbsp;&nbsp; only valid in certain states.&nbsp; It is a protocol error for the
&nbsp;&nbsp; client to attempt a command while the connection is in an
&nbsp;&nbsp; inappropriate state, and the server will respond with a BAD or
&nbsp;&nbsp; NO (depending upon server implementation) command completion
&nbsp;&nbsp; result.</FONT></P>
<P><FONT face="courier new,courier">3.1.&nbsp;&nbsp;&nbsp; Not Authenticated State</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; In the not authenticated state, the client MUST supply
&nbsp;&nbsp; authentication credentials before most commands will be
&nbsp;&nbsp; permitted.&nbsp; This state is entered when a connection starts
&nbsp;&nbsp; unless the connection has been pre-authenticated.</FONT></P>
<P><FONT face="courier new,courier">3.2.&nbsp;&nbsp;&nbsp; Authenticated State</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; In the authenticated state, the client is authenticated and MUST
&nbsp;&nbsp; select a mailbox to access before commands that affect messages
&nbsp;&nbsp; will be permitted.&nbsp; This state is entered when a
&nbsp;&nbsp; pre-authenticated connection starts, when acceptable
&nbsp;&nbsp; authentication credentials have been provided, after an error in
&nbsp;&nbsp; selecting a mailbox, or after a successful CLOSE command.</FONT></P>
<P><FONT face="courier new,courier">3.3.&nbsp;&nbsp;&nbsp; Selected State</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; In a selected state, a mailbox has been selected to access.
&nbsp;&nbsp; This state is entered when a mailbox has been successfully
&nbsp;&nbsp; selected.</FONT></P>
<P><FONT face="courier new,courier"></FONT>&nbsp;</P>
<P><FONT face="courier new,courier"></FONT>&nbsp;</P>
<P><FONT face="courier new,courier"></FONT>&nbsp;</P>
<P><FONT face="courier new,courier"></FONT>&nbsp;</P>
<P><FONT face="courier new,courier"></FONT>&nbsp;</P>
<P><FONT face="courier new,courier">Crispin&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Standards Track&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [Page 13]
RFC 3501&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IMAPv4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; March 2003</FONT></P>
<P>
<FONT face="courier new,courier">3.4.&nbsp;&nbsp;&nbsp; Logout State</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; In the logout state, the connection is being terminated.&nbsp; This
&nbsp;&nbsp; state can be entered as a result of a client request (via the
&nbsp;&nbsp; LOGOUT command) or by unilateral action on the part of either
&nbsp;&nbsp; the client or server.</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; If the client requests the logout state, the server MUST send an
&nbsp;&nbsp; untagged BYE response and a tagged OK response to the LOGOUT
&nbsp;&nbsp; command before the server closes the connection; and the client
&nbsp;&nbsp; MUST read the tagged OK response to the LOGOUT command before
&nbsp;&nbsp; the client closes the connection.</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp; A server MUST NOT unilaterally close the connection without
&nbsp;&nbsp; sending an untagged BYE response that contains the reason for
&nbsp;&nbsp; having done so.&nbsp; A client SHOULD NOT unilaterally close the
&nbsp;&nbsp; connection, and instead SHOULD issue a LOGOUT command.&nbsp; If the
&nbsp;&nbsp; server detects that the client has unilaterally closed the
&nbsp;&nbsp; connection, the server MAY omit the untagged BYE response and
&nbsp;&nbsp; simply close its connection.</FONT></P>
<P><FONT face="courier new,courier"></FONT>&nbsp;</P>
<P><FONT face="courier new,courier"></FONT>&nbsp;</P>
<P><FONT face="courier new,courier"></FONT>&nbsp;</P>
<P><FONT face="courier new,courier"></FONT>&nbsp;</P>
<P><FONT face="courier new,courier"></FONT>&nbsp;</P>
<P><FONT face="courier new,courier"></FONT>&nbsp;</P>
<P><FONT face="courier new,courier"></FONT>&nbsp;</P>
<P><FONT face="courier new,courier"></FONT>&nbsp;</P>
<P><FONT face="courier new,courier"></FONT>&nbsp;</P>
<P><FONT face="courier new,courier"></FONT>&nbsp;</P>
<P><FONT face="courier new,courier"></FONT>&nbsp;</P>
<P><FONT face="courier new,courier"></FONT>&nbsp;</P>
<P><FONT face="courier new,courier"></FONT>&nbsp;</P>
<P><FONT face="courier new,courier"></FONT>&nbsp;</P>
<P><FONT face="courier new,courier"></FONT>&nbsp;</P>
<P><FONT face="courier new,courier">Crispin&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Standards Track&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [Page 14]
RFC 3501&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IMAPv4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; March 2003</FONT></P>
<P>
<FONT face="courier new,courier">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +----------------------+
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |connection established|
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +----------------------+
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \/
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +--------------------------------------+
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; server greeting&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +--------------------------------------+
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; || (1)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; || (2)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; || (3)
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-----------------+&nbsp;&nbsp;&nbsp; ||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |Not Authenticated|&nbsp;&nbsp;&nbsp; ||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-----------------+&nbsp;&nbsp;&nbsp; ||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; || (7)&nbsp;&nbsp; || (4)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp;&nbsp;&nbsp;&nbsp; +----------------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp;&nbsp;&nbsp;&nbsp; | Authenticated&nbsp; |&lt;=++&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp;&nbsp;&nbsp;&nbsp; +----------------+&nbsp; ||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; || (7)&nbsp;&nbsp; || (5)&nbsp;&nbsp; || (6)&nbsp;&nbsp; ||
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp;&nbsp;&nbsp; +--------+&nbsp; ||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp;&nbsp;&nbsp; |Selected|==++&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp;&nbsp;&nbsp; +--------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; || (7)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \/&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \/
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +--------------------------------------+
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Logout&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +--------------------------------------+
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ||
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; \/
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-------------------------------+
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |both sides close the connection|
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-------------------------------+</FONT></P>
<P><FONT face="courier new,courier">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (1) connection without pre-authentication (OK greeting)
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (2) pre-authenticated connection (PREAUTH greeting)
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (3) rejected connection (BYE greeting)
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (4) successful LOGIN or AUTHENTICATE command
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp