As per Relevance of the word complete, we have this rfc below:
Network Working Group M.
Request for Comments: 2060 University of
Obsoletes: 1730 December 1996
Category: Standards
INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1)
allows a client to access and manipulate electronic mail messages
a server. IMAP4rev1 permits manipulation of remote message folders
called "mailboxes", in a way that is functionally equivalent to
mailboxes. IMAP4rev1 also provides the capability for an
client to resynchronize with the server (see also [IMAP-DISC]).
IMAP4rev1 includes operations for creating, deleting, and
mailboxes; checking for new messages; permanently removing messages
setting and clearing flags; [RFC-822] and [MIME-IMB] parsing
searching; and selective fetching of message attributes, texts,
portions thereof. Messages in IMAP4rev1 are accessed by the use
numbers. These numbers are either message sequence numbers or
identifiers
IMAP4rev1 supports a single server. A mechanism for
configuration information to support multiple IMAP4rev1 servers
discussed in [ACAP].
IMAP4rev1 does not specify a means of posting mail; this function
handled by a mail transfer protocol such as [SMTP].
IMAP4rev1 is designed to be upwards compatible from the [IMAP2]
unpublished IMAP2bis protocols. In the course of the evolution
IMAP4rev1, some aspects in the earlier protocol have become obsolete
Obsolete commands, responses, and data formats which an IMAP4rev
implementation may encounter when used with an earlier
are described in [IMAP-OBSOLETE].
Crispin Standards Track [Page 1]
RFC 2060 IMAP4rev1 December 1996
Other compatibility issues with IMAP2bis, the most common variant
the earlier protocol, are discussed in [IMAP-COMPAT]. A
discussion of compatibility issues with rare (and presumed extinct
variants of [IMAP2] is in [IMAP-HISTORICAL]; this document
primarily of historical interest
Table of
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
2. Protocol Overview ......................................... 5
2.1. Link Level ................................................ 5
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 ........................................ 7
2.3.1. Message Numbers ........................................... 7
2.3.1.1. Unique Identifier (UID) Message Attribute ......... 7
2.3.1.2. Message Sequence Number Message Attribute ......... 9
2.3.2. Flags Message Attribute .................................... 9
2.3.3. Internal Date Message Attribute ........................... 10
2.3.4. [RFC-822] Size Message Attribute .......................... 11
2.3.5. Envelope Structure Message Attribute ...................... 11
2.3.6. Body Structure Message Attribute .......................... 11
2.4. Message Texts ............................................. 11
3. State and Flow Diagram .................................... 11
3.1. Non-Authenticated State ................................... 11
3.2. Authenticated State ....................................... 11
3.3. Selected State ............................................ 12
3.4. Logout State .............................................. 12
4. Data Formats .............................................. 12
4.1. Atom ...................................................... 13
4.2. Number .................................................... 13
4.3. String ..................................................... 13
4.3.1. 8-bit and Binary Strings .................................. 13
4.4. Parenthesized List ........................................ 14
4.5. NIL ....................................................... 14
5. Operational Considerations ................................ 14
5.1. Mailbox Naming ............................................ 14
5.1.1. Mailbox Hierarchy Naming .................................. 14
5.1.2. Mailbox Namespace Naming Convention ....................... 14
5.1.3. Mailbox International Naming Convention ................... 15
5.2. Mailbox Size and Message Status Updates ................... 16
5.3. Response when no Command in Progress ...................... 16
5.4. Autologout Timer .......................................... 16
5.5. Multiple Commands in Progress ............................. 17
Crispin Standards Track [Page 2]
RFC 2060 IMAP4rev1 December 1996
6. Client Commands ........................................... 17
6.1. Client Commands - Any State ............................... 18
6.1.1. CAPABILITY Command ........................................ 18
6.1.2. NOOP Command .............................................. 19
6.1.3. LOGOUT Command ............................................ 20
6.2. Client Commands - Non-Authenticated State ................. 20
6.2.1. AUTHENTICATE Command ...................................... 21
6.2.2. LOGIN Command ............................................. 22
6.3. Client Commands - Authenticated State ..................... 22
6.3.1. SELECT Command ............................................ 23
6.3.2. EXAMINE Command ........................................... 24
6.3.3. CREATE Command ............................................ 25
6.3.4. DELETE Command ............................................ 26
6.3.5. RENAME Command ............................................ 27
6.3.6. SUBSCRIBE Command ......................................... 29
6.3.7. UNSUBSCRIBE Command ....................................... 30
6.3.8. LIST Command .............................................. 30
6.3.9. LSUB Command .............................................. 32
6.3.10. STATUS Command ............................................ 33
6.3.11. APPEND Command ............................................ 34
6.4. Client Commands - Selected State .......................... 35
6.4.1. CHECK Command ............................................. 36
6.4.2. CLOSE Command ............................................. 36
6.4.3. EXPUNGE Command ........................................... 37
6.4.4. SEARCH Command ............................................ 37
6.4.5. FETCH Command ............................................. 41
6.4.6. STORE Command ............................................. 45
6.4.7. COPY Command .............................................. 46
6.4.8. UID Command ............................................... 47
6.5. Client Commands - Experimental/Expansion .................. 48
6.5.1. X Command ........................................... 48
7. Server Responses .......................................... 48
7.1. Server Responses - Status Responses ....................... 49
7.1.1. OK Response ............................................... 51
7.1.2. NO Response ............................................... 51
7.1.3. BAD Response .............................................. 52
7.1.4. PREAUTH Response .......................................... 52
7.1.5. BYE Response .............................................. 52
7.2. Server Responses - Server and Mailbox Status .............. 53
7.2.1. CAPABILITY Response ....................................... 53
7.2.2. LIST Response .............................................. 54
7.2.3. LSUB Response ............................................. 55
7.2.4 STATUS Response ........................................... 55
7.2.5. SEARCH Response ........................................... 55
7.2.6. FLAGS Response ............................................ 56
7.3. Server Responses - Mailbox Size ........................... 56
7.3.1. EXISTS Response ........................................... 56
7.3.2. RECENT Response ........................................... 57
Crispin Standards Track [Page 3]
RFC 2060 IMAP4rev1 December 1996
7.4. Server Responses - Message Status ......................... 57
7.4.1. EXPUNGE Response .......................................... 57
7.4.2. FETCH Response ............................................ 58
7.5. Server Responses - Command Continuation Request ........... 63
8. Sample IMAP4rev1 connection ............................... 63
9. Formal Syntax ............................................. 64
10. Author's Note ............................................. 74
11. Security Considerations ................................... 74
12. Author's Address .......................................... 75
Appendices ........................................................ 76
A. References ................................................ 76
B. Changes from RFC 1730 ..................................... 77
C. Key Word Index ............................................ 79
IMAP4rev1 Protocol
1. How to Read This
1.1. Organization of This
This document is written from the point of view of the implementor
an IMAP4rev1 client or server. Beyond the protocol overview
section 2, it is not optimized for someone trying to understand
operation of the protocol. The material in sections 3 through 5
provides the general context and definitions with which IMAP4rev
operates
Sections 6, 7, and 9 describe the IMAP commands, responses,
syntax, respectively. The relationships among these are such that
is almost impossible to understand any of them separately.
particular, do not attempt to deduce command syntax from the
section alone; instead refer to the Formal Syntax section
1.2. Conventions Used in This
In examples, "C:" and "S:" indicate lines sent by the client
server respectively
The following terms are used in this document to signify
requirements of this specification
1) MUST, or the adjective REQUIRED, means that the definition
an absolute requirement of the specification
2) MUST NOT that the definition is an absolute prohibition of
specification
Crispin Standards Track [Page 4]
RFC 2060 IMAP4rev1 December 1996
3) SHOULD means that there may exist valid reasons in
circumstances to ignore a particular item, but the
implications MUST be understood and carefully weighed
choosing a different course
4) SHOULD NOT means that there may exist valid reasons
particular circumstances when the particular behavior
acceptable or even useful, but the full implications SHOULD
understood and the case carefully weighed before
any behavior described with this label
5) MAY, or the adjective OPTIONAL, means that an item is
optional. One vendor may choose to include the item because
particular marketplace requires it or because the vendor
that it enhances the product while another vendor may omit
same item. An implementation which does not include
particular option MUST be prepared to interoperate with
implementation which does include the option
"Can" is used instead of "may" when referring to a
circumstance or situation, as opposed to an optional facility
the protocol
"User" is used to refer to a human user, whereas "client"
to the software being run by the user
"Connection" refers to the entire sequence of client/
interaction from the initial establishment of the
connection until its termination. "Session" refers to
sequence of client/server interaction from the time that a
is selected (SELECT or EXAMINE command) until the time
selection ends (SELECT or EXAMINE of another mailbox,
command, or connection termination).
Characters are 7-bit US-ASCII unless otherwise specified.
character sets are indicated using a "CHARSET", as described
[MIME-IMT] and defined in [CHARSET]. CHARSETs have
additional semantics in addition to defining character set;
to these documents for more detail
2. Protocol
2.1. Link
The IMAP4rev1 protocol assumes a reliable data stream such
provided by TCP. When TCP is used, an IMAP4rev1 server listens
port 143.
Crispin Standards Track [Page 5]
RFC 2060 IMAP4rev1 December 1996
2.2. Commands and
An IMAP4rev1 connection consists of the establishment of
client/server network connection, an initial greeting from
server, and client/server interactions. These client/
interactions consist of a client command, server data, and a
completion result response
All interactions transmitted by client and server are in the form
lines; that is, strings that end with a CRLF. The protocol
of an IMAP4rev1 client or server is either reading a line, or
reading a sequence of octets with a known count followed by a line
2.2.1. Client Protocol Sender and Server Protocol
The client command begins an operation. Each client command
prefixed with an identifier (typically a short alphanumeric string
e.g. A0001, A0002, etc.) called a "tag". A different tag
generated by the client for each command
There are two cases in which a line from the client does
represent a complete command. In one case, a command argument
quoted with an octet count (see the description of literal in
under Data Formats); in the other case, the command arguments
server feedback (see the AUTHENTICATE command). In either case,
server sends a command continuation request response if it is
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,
sends a BAD completion response with tag matching the command (
described below) to reject the command and prevent the client
sending any more of the command
It is also possible for the server to send a completion
for some other command (if multiple commands are in progress),
untagged data. In either case, the command continuation
is still pending; the client takes the appropriate action for
response, and reads another response from the server. In
cases, the client MUST send a complete command (
receiving all command continuation request responses and
continuations for the command) before initiating a new command
The protocol receiver of an IMAP4rev1 server reads a command
from the client, parses the command and its arguments, and
server data and a server command completion result response
Crispin Standards Track [Page 6]
RFC 2060 IMAP4rev1 December 1996
2.2.2. Server Protocol Sender and Client Protocol
Data transmitted by the server to the client and status
that do not indicate command completion are prefixed with the
"*", and are called untagged responses
Server data MAY be sent as a result of a client command, or MAY
sent unilaterally by the server. There is no syntactic
between server data that resulted from a specific command and
data that were sent unilaterally
The server completion result response indicates the success
failure of the operation. It is tagged with the same tag as
client command which began the operation. Thus, if more than
command is in progress, the tag in a server completion
identifies the command to which the response applies. There
three possible server completion responses: OK (indicating success),
NO (indicating failure), or BAD (indicating protocol error such
unrecognized command or command syntax error).
The protocol receiver of an IMAP4rev1 client reads a response
from the server. It then takes action on the response based upon
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
be recorded, so that the client can reference its recorded
rather than sending a command to the server to request the data.
the case of certain server data, the data MUST be recorded
This topic is discussed in greater detail in the Server
section
2.3. Message
In addition to message text, each message has several
associated with it. These attributes may be retrieved
or in conjunction with other attributes or message texts
2.3.1. Message
Messages in IMAP4rev1 are accessed by one of two numbers; the
identifier and the message sequence number
2.3.1.1. Unique Identifier (UID) Message
A 32-bit value assigned to each message, which when used with
unique identifier validity value (see below) forms a 64-bit
Crispin Standards Track [Page 7]
RFC 2060 IMAP4rev1 December 1996
that is permanently guaranteed not to refer to any other message
the mailbox. Unique identifiers are assigned in a strictly
fashion in the mailbox; as each message is added to the mailbox it
assigned a higher UID than the message(s) which were
previously
Unlike message sequence numbers, unique identifiers are
necessarily contiguous. Unique identifiers also persist
sessions. This permits a client to resynchronize its state from
previous session with the server (e.g. disconnected or offline
clients); this is discussed further in [IMAP-DISC].
Associated with every mailbox is a unique identifier validity value
which is sent in an UIDVALIDITY response code in an OK
response at mailbox selection time. If unique identifiers from
earlier session fail to persist to this session, the
identifier validity value MUST be greater than the one used in
earlier session
Note: Unique identifiers MUST be strictly ascending in the
at all times. If the physical message store is re-ordered by
non-IMAP agent, this requires that the unique identifiers in
mailbox be regenerated, since the former unique identifers are
longer strictly ascending as a result of the re-ordering.
instance in which unique identifiers are regenerated is if
message store has no mechanism to store unique identifiers
Although this specification recognizes that this may
unavoidable in certain server environments, it STRONGLY
message store implementation techniques that avoid this problem
Another cause of non-persistance is if the mailbox is deleted
a new mailbox with the same name is created at a later date,
the name is the same, a client may not know that this is a
mailbox unless the unique identifier validity is different.
good value to use for the unique identifier validity value is
32-bit representation of the creation date/time of the mailbox
It is alright to use a constant such as 1, but only if
guaranteed that unique identifiers will never be reused, even
the case of a mailbox being deleted (or renamed) and a new
by the same name created at some future time
The unique identifier of a message MUST NOT change during
session, and SHOULD NOT change between sessions. However, if it
not possible to preserve the unique identifier of a message in
subsequent session, each subsequent session MUST have a new
identifier validity value that is larger than any that was
previously
Crispin Standards Track [Page 8]
RFC 2060 IMAP4rev1 December 1996
2.3.1.2. Message Sequence Number Message
A relative position from 1 to the number of messages in the mailbox
This position MUST be ordered by ascending unique identifier.
each new message is added, it is assigned a message sequence
that is 1 higher than the number of messages in the mailbox
that new message was added
Message sequence numbers can be reassigned during the session.
example, when a message is permanently removed (expunged) from
mailbox, the message sequence number for all subsequent messages
decremented. Similarly, a new message can be assigned a
sequence number that was once held by some other message prior to
expunge
In addition to accessing messages by relative position in
mailbox, message sequence numbers can be used in
calculations. For example, if an untagged "EXISTS 11" is received
and previously an untagged "8 EXISTS" was received, three
messages have arrived with message sequence numbers of 9, 10, and 11.
Another example; if message 287 in a 523 message mailbox has
12345, there are exactly 286 messages which have lesser UIDs and 236
messages which have greater UIDs
2.3.2. Flags Message
A list of zero or more named tokens associated with the message.
flag is set by its addition to this list, and is cleared by
removal. There are two types of flags in IMAP4rev1. A flag
either type may be permanent or session-only
A system flag is a flag name that is pre-defined in
specification. All system flags begin with "\". Certain
flags (\Deleted and \Seen) have special semantics
elsewhere. The currently-defined system flags are
\Seen Message has been
\Answered Message has been
\Flagged Message is "flagged" for urgent/special
\Deleted Message is "deleted" for removal by later
\Draft Message has not completed composition (marked as
draft).
Crispin Standards Track [Page 9]
RFC 2060 IMAP4rev1 December 1996
\Recent Message is "recently" arrived in this mailbox.
session is the first session to have been
about this message; subsequent sessions will not
\Recent set for this message. This flag can not
altered by the client
If it is not possible to determine whether or
this session is the first session to be
about a message, then that message SHOULD
considered recent
If multiple connections have the same
selected simultaneously, it is undefined which
these connections will see newly-arrives
with \Recent set and which will see it
\Recent set
A keyword is defined by the server implementation. Keywords
not begin with "\". Servers MAY permit the client to define
keywords in the mailbox (see the description of
PERMANENTFLAGS response code for more information).
A flag may be permanent or session-only on a per-flag basis
Permanent flags are those which the client can add or
from the message flags permanently; that is, subsequent
will see any change in permanent flags. Changes to
flags are valid only in that session
Note: The \Recent system flag is a special case of
session flag. \Recent can not be used as an argument in
STORE command, and thus can not be changed at all
2.3.3. Internal Date Message
The internal date and time of the message on the server. This is
the date and time in the [RFC-822] header, but rather a date and
which reflects when the message was received. In the case
messages delivered via [SMTP], this SHOULD be the date and time
final delivery of the message as defined by [SMTP]. In the case
messages delivered by the IMAP4rev1 COPY command, this SHOULD be
internal date and time of the source message. In the case
messages delivered by the IMAP4rev1 APPEND command, this SHOULD
the date and time as specified in the APPEND command description
All other cases are implementation defined
Crispin Standards Track [Page 10]
RFC 2060 IMAP4rev1 December 1996
2.3.4. [RFC-822] Size Message
The number of octets in the message, as expressed in [RFC-822]
format
2.3.5. Envelope Structure Message
A parsed representation of the [RFC-822] envelope information (not
be confused with an [SMTP] envelope) of the message
2.3.6. Body Structure Message
A parsed representation of the [MIME-IMB] body structure
of the message
2.4. Message
In addition to being able to fetch the full [RFC-822] text of
message, IMAP4rev1 permits the fetching of portions of the
message text. Specifically, it is possible to fetch the [RFC-822]
message header, [RFC-822] message body, a [MIME-IMB] body part, or
[MIME-IMB] header
3. State and Flow
An IMAP4rev1 server is in one of four states. Most commands
valid in only certain states. It is a protocol error for the
to attempt a command while the command is in an inappropriate state
In this case, a server will respond with a BAD or NO (depending
server implementation) command completion result
3.1. Non-Authenticated
In non-authenticated state, the client MUST supply
credentials before most commands will be permitted. This state
entered when a connection starts unless the connection has been pre
authenticated
3.2. Authenticated
In authenticated state, the client is authenticated and MUST select
mailbox to access before commands that affect messages will
permitted. This state is entered when a pre-authenticated
starts, when acceptable authentication credentials have
provided, or after an error in selecting a mailbox
Crispin Standards Track [Page 11]
RFC 2060 IMAP4rev1 December 1996
3.3. Selected
In selected state, a mailbox has been selected to access. This
is entered when a mailbox has been successfully selected
3.4. Logout
In logout state, the connection is being terminated, and the
will close the connection. This state can be entered as a result
a client request or by unilateral server decision
+--------------------------------------+
|initial connection and server greeting
+--------------------------------------+
|| (1) || (2) || (3)
VV || ||
+-----------------+ || ||
|non-authenticated| || ||
+-----------------+ || ||
|| (7) || (4) || ||
|| VV VV ||
|| +----------------+ ||
|| | authenticated |<=++ ||
|| +----------------+ || ||
|| || (7) || (5) || (6) ||
|| || VV || ||
|| || +--------+ || ||
|| || |selected|==++ ||
|| || +--------+ ||
|| || || (7) ||
VV VV VV
+--------------------------------------+
| logout and close connection |
+--------------------------------------+
(1) connection without pre-authentication (OK greeting
(2) pre-authenticated connection (PREAUTH greeting
(3) rejected connection (BYE greeting
(4) successful LOGIN or AUTHENTICATE
(5) successful SELECT or EXAMINE
(6) CLOSE command, or failed SELECT or EXAMINE
(7) LOGOUT command, server shutdown, or connection
4. Data
IMAP4rev1 uses textual commands and responses. Data in IMAP4rev1
be in one of several forms: atom, number, string, parenthesized list
or NIL
Crispin Standards Track [Page 12]
RFC 2060 IMAP4rev1 December 1996
4.1.
An atom consists of one or more non-special characters
4.2.
A number consists of one or more digit characters, and represents
numeric value
4.3.
A string is in one of two forms: literal and quoted string.
literal form is the general form of string. The quoted string
is an alternative that avoids the overhead of processing a literal
the cost of limitations of characters that can be used in a
string
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
literals transmitted from server to client, the CRLF is
followed by the octet data. In the case of literals transmitted
client to server, the client MUST wait to receive a
continuation request (described later in this document)
sending the octet data (and the remainder of the command).
A quoted string is a sequence of zero or more 7-bit characters
excluding CR and LF, with double quote (<">) characters at each end
The empty string is represented as either "" (a quoted string
zero characters between double quotes) or as {0} followed by CRLF (
literal with an octet count of 0).
Note: Even if the octet count is 0, a client transmitting
literal MUST wait to receive a command continuation request
4.3.1. 8-bit and Binary
8-bit textual and binary mail is supported through the use of
[MIME-IMB] content transfer encoding. IMAP4rev1 implementations
transmit 8-bit or multi-octet characters in literals, but SHOULD
so only when the [CHARSET] is identified
Crispin Standards Track [Page 13]
RFC 2060 IMAP4rev1 December 1996
Although a BINARY body encoding is defined, unencoded binary
are not permitted. A "binary string" is any string with
characters. Implementations MUST encode binary data into a
form such as BASE64 before transmitting the data. A string with
excessive amount of CTL characters MAY also be considered to
binary
4.4. Parenthesized
Data structures are represented as a "parenthesized list"; a
of data items, delimited by space, and bounded at each end
parentheses. A parenthesized list can contain other
lists, using multiple levels of parentheses to indicate nesting
The empty list is represented as () -- a parenthesized list with
members
4.5.
The special atom "NIL" represents the non-existence of a
data item that is represented as a string or parenthesized list,
distinct from the empty string "" or the empty parenthesized list ().
5. Operational
5.1. Mailbox
The interpretation of mailbox names is implementation-dependent
However, the case-insensitive mailbox name INBOX is a special
reserved to mean "the primary mailbox for this user on this server".
5.1.1. Mailbox Hierarchy
If it is desired to export hierarchical mailbox names, mailbox
MUST be left-to-right hierarchical using a single character
separate levels of hierarchy. The same hierarchy separator
is used for all levels of hierarchy within a single name
5.1.2. Mailbox Namespace Naming
By convention, the first hierarchical element of any mailbox
which begins with "#" identifies the "namespace" of the remainder
the name. This makes it possible to disambiguate between
types of mailbox stores, each of which have their own namespaces
Crispin Standards Track [Page 14]
RFC 2060 IMAP4rev1 December 1996
For example, implementations which offer access to
newsgroups MAY use the "#news" namespace to partition the
newsgroup namespace from that of other mailboxes. Thus,
comp.mail.misc newsgroup would have an mailbox name
"#news.comp.mail.misc", and the name "comp.mail.misc" could
to a different object (e.g. a user's private mailbox).
5.1.3. Mailbox International Naming
By convention, international mailbox names are specified using
modified version of the UTF-7 encoding described in [UTF-7].
purpose of these modifications is to correct the following
with UTF-7:
1) UTF-7 uses the "+" character for shifting; this conflicts
the common use of "+" in mailbox names, in particular
newsgroup names
2) UTF-7's encoding is BASE64 which uses the "/" character;
conflicts with the use of "/" as a popular hierarchy delimiter
3) UTF-7 prohibits the unencoded usage of "\"; this conflicts
the use of "\" as a popular hierarchy delimiter
4) UTF-7 prohibits the unencoded usage of "~"; this conflicts
the use of "~" in some servers as a home directory indicator
5) UTF-7 permits multiple alternate forms to represent the
string; in particular, printable US-ASCII chararacters can
represented in encoded form
In modified UTF-7, printable US-ASCII characters except for "&"
represent themselves; that is, characters with octet values 0x20-0x25
and 0x27-0x7e. The character "&" (0x26) is represented by the two
octet sequence "&-".
All other characters (octet values 0x00-0x1f, 0x7f-0xff, and
Unicode 16-bit octets) are represented in modified BASE64, with
further modification from [UTF-7] that "," is used instead of "/".
Modified BASE64 MUST NOT be used to represent any printing US-
character which can represent itself
"&" is used to shift to modified BASE64 and "-" to shift back to US
ASCII. All names start in US-ASCII, and MUST end in US-ASCII (
is, a name that ends with a Unicode 16-bit octet MUST end with a "-
").
Crispin Standards Track [Page 15]
RFC 2060 IMAP4rev1 December 1996
For example, here is a mailbox name which mixes English, Japanese
and Chinese text: ~peter/mail/&ZeVnLIqe-/&U,BTFw
5.2. Mailbox Size and Message Status
At any time, a server can send data that the client did not request
Sometimes, such behavior is REQUIRED. For example, agents other
the server MAY add messages to the mailbox (e.g. new mail delivery),
change the flags of message in the mailbox (e.g. simultaneous
to the same mailbox by multiple agents), or even remove messages
the mailbox. A server MUST send mailbox size updates
if a mailbox size change is observed during the processing of
command. A server SHOULD send message flag updates automatically
without requiring the client to request such updates explicitly
Special rules exist for server notification of a client about
removal of messages to prevent synchronization errors; see
description of the EXPUNGE response for more detail
Regardless of what implementation decisions a client makes
remembering data from the server, a client implementation MUST
mailbox size updates. It MUST NOT assume that any command
initial mailbox selection will return the size of the mailbox
5.3. Response when no Command in
Server implementations are permitted to send an untagged
(except for EXPUNGE) while there is no command in progress.
implementations that send such responses MUST deal with flow
considerations. Specifically, they MUST either (1) verify that
size of the data does not exceed the underlying transport's
window size, or (2) use non-blocking writes
5.4. Autologout
If a server has an inactivity autologout timer, that timer MUST be
at least 30 minutes' duration. The receipt of ANY command from
client during that interval SHOULD suffice to reset the
timer
Crispin Standards Track [Page 16]
RFC 2060 IMAP4rev1 December 1996
5.5. Multiple Commands in
The client MAY send another command without waiting for
completion result response of a command, subject to ambiguity
(see below) and flow control constraints on the underlying
stream. Similarly, a server MAY begin processing another
before processing the current command to completion, subject
ambiguity rules. However, any command continuation request
and command continuations MUST be negotiated before any
command is initiated
The exception is if an ambiguity would result because of a
that would affect the results of other commands. Clients MUST
send multiple commands without waiting if an ambiguity would result
If the server detects a possible ambiguity, it MUST execute
to completion in the order given by the client
The most obvious example of ambiguity is when a command would
the results of another command; for example, a FETCH of a message'
flags and a STORE of that same message's flags
A non-obvious ambiguity occurs with commands that permit an
EXPUNGE response (commands other than FETCH, STORE, and SEARCH),
since an untagged EXPUNGE response can invalidate sequence numbers
a subsequent command. This is not a problem for FETCH, STORE,
SEARCH commands because servers are prohibited from sending
responses while any of those commands are in progress. Therefore,
the client sends any command other than FETCH, STORE, or SEARCH,
MUST wait for a response before sending a command with
sequence numbers
For example, the following non-waiting command sequences are invalid
FETCH + NOOP +
STORE + COPY +
COPY +
CHECK +
The following are examples of valid non-waiting command sequences
FETCH + STORE + SEARCH +
STORE + COPY +
6. Client
IMAP4rev1 commands are described in this section. Commands
organized by the state in which the command is permitted.
which are permitted in multiple states are listed in the
Crispin Standards Track [Page 17]
RFC 2060 IMAP4rev1 December 1996
permitted state (for example, commands valid in authenticated
selected state are listed in the authenticated state commands).
Command arguments, identified by "Arguments:" in the
descriptions below, are described by function, not by syntax.
precise syntax of command arguments is described in the Formal
section
Some commands cause specific server responses to be returned;
are identified by "Responses:" in the command descriptions below
See the response descriptions in the Responses section
information on these responses, and the Formal Syntax section for
precise syntax of these responses. It is possible for server data
be transmitted as a result of any command; thus, commands that do
specifically require server data specify "no specific responses
this command" instead of "none".
The "Result:" in the command description refers to the
tagged status responses to a command, and any special
of these status responses
6.1. Client Commands - Any
The following commands are valid in any state: CAPABILITY, NOOP,
LOGOUT
6.1.1. CAPABILITY
Arguments:
Responses: REQUIRED untagged response:
Result: OK - capability
BAD - command unknown or arguments
The CAPABILITY command requests a listing of capabilities that
server supports. The server MUST send a single
CAPABILITY response with "IMAP4rev1" as one of the
capabilities before the (tagged) OK response. This listing
capabilities is not dependent upon connection state or user.
is therefore not necessary to issue a CAPABILITY command more
once in a connection
Crispin Standards Track [Page 18]
RFC 2060 IMAP4rev1 December 1996
A capability name which begins with "AUTH=" indicates that
server supports that particular authentication mechanism.
such names are, by definition, part of this specification.
example, the authorization capability for an
"blurdybloop" authenticator would be "AUTH=XBLURDYBLOOP" and
"XAUTH=BLURDYBLOOP" or "XAUTH=XBLURDYBLOOP".
Other capability names refer to extensions, revisions,
amendments to this specification. See the documentation of
CAPABILITY response for additional information. No capabilities
beyond the base IMAP4rev1 set defined in this specification,
enabled without explicit client action to invoke the capability
See the section entitled "Client Commands -
Experimental/Expansion" for information about the form of site
implementation-specific capabilities
Example: C: abcd
S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V
S: abcd OK CAPABILITY
6.1.2. NOOP
Arguments:
Responses: no specific responses for this command (but see below
Result: OK - noop
BAD - command unknown or arguments
The NOOP command always succeeds. It does nothing
Since any command can return a status update as untagged data,
NOOP command can be used as a periodic poll for new messages
message status updates during a period of inactivity. The
command can also be used to reset any inactivity autologout
on the server
Example: C: a002
S: a002 OK NOOP
. . .
C: a047
S: * 22
S: * 23
S: * 3
S: * 14 FETCH (FLAGS (\Seen \Deleted))
S: a047 OK NOOP
Crispin Standards Track [Page 19]
RFC 2060 IMAP4rev1 December 1996
6.1.3. LOGOUT
Arguments:
Responses: REQUIRED untagged response:
Result: OK - logout
BAD - command unknown or arguments
The LOGOUT command informs the server that the client is done
the connection. The server MUST send a BYE untagged
before the (tagged) OK response, and then close the
connection
Example: C: A023
S: * BYE IMAP4rev1 Server logging
S: A023 OK LOGOUT
(Server and client then close the connection
6.2. Client Commands - Non-Authenticated
In non-authenticated state, the AUTHENTICATE or LOGIN
establishes authentication and enter authenticated state.
AUTHENTICATE command provides a general mechanism for a variety
authentication techniques, whereas the LOGIN command uses
traditional user name and plaintext password pair
Server implementations MAY allow non-authenticated access to
mailboxes. The convention is to use a LOGIN command with the
"anonymous". A password is REQUIRED. It is implementation-
what requirements, if any, are placed on the password and what
restrictions are placed on anonymous users
Once authenticated (including as anonymous), it is not possible
re-enter non-authenticated state
In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
the following commands are valid in non-authenticated state
AUTHENTICATE and LOGIN
Crispin Standards Track [Page 20]
RFC 2060 IMAP4rev1 December 1996
6.2.1. AUTHENTICATE
Arguments: authentication mechanism
Responses: continuation data can be
Result: OK - authenticate completed, now in authenticated
NO - authenticate failure: unsupported
mechanism, credentials
BAD - command unknown or arguments invalid
authentication exchange
The AUTHENTICATE command indicates an authentication mechanism
such as described in [IMAP-AUTH], to the server. If the
supports the requested authentication mechanism, it performs
authentication protocol exchange to authenticate and identify
client. It MAY also negotiate an OPTIONAL protection
for subsequent protocol interactions. If the
authentication mechanism is not supported, the server
reject the AUTHENTICATE command by sending a tagged NO response
The authentication protocol exchange consists of a series
server challenges and client answers that are specific to
authentication mechanism. A server challenge consists of
command continuation request response with the "+" token
by a BASE64 encoded string. The client answer consists of a
consisting of a BASE64 encoded string. If the client wishes
cancel an authentication exchange, it issues a line with a
"*". If the server receives such an answer, it MUST reject
AUTHENTICATE command by sending a tagged BAD response
A protection mechanism provides integrity and privacy
to the connection. If a protection mechanism is negotiated, it
applied to all subsequent data sent over the connection.
protection mechanism takes effect immediately following the
that concludes the authentication exchange for the client, and
CRLF of the tagged OK response for the server. Once
protection mechanism is in effect, the stream of command
response octets is processed into buffers of ciphertext.
buffer is transferred over the connection as a stream of
prepended with a four octet field in network byte order
represents the length of the following data. The
ciphertext buffer length is defined by the protection mechanism
Authentication mechanisms are OPTIONAL. Protection mechanisms
also OPTIONAL; an authentication mechanism MAY be
without any protection mechanism. If an AUTHENTICATE
fails with a NO response, the client MAY try
Crispin Standards Track [Page 21]
RFC 2060 IMAP4rev1 December 1996
authentication mechanism by issuing another AUTHENTICATE command
or MAY attempt to authenticate by using the LOGIN command.
other words, the client MAY request authentication types
decreasing order of preference, with the LOGIN command as a
resort
Example: S: * OK KerberosV4 IMAP4rev1
C: A001 AUTHENTICATE KERBEROS_V
S: + AmFYig==
C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4
+nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/
WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1
S: + or//EoAADZI
C: DiAF5A4gA+oOIALuBkAAmw==
S: A001 OK Kerberos V4 authentication
Note: the line breaks in the first client answer are for
clarity and are not in real authenticators
6.2.2. LOGIN
Arguments: user
Responses: no specific responses for this
Result: OK - login completed, now in authenticated
NO - login failure: user name or password
BAD - command unknown or arguments
The LOGIN command identifies the client to the server and
the plaintext password authenticating this user
Example: C: a001 LOGIN SMITH
S: a001 OK LOGIN
6.3. Client Commands - Authenticated
In authenticated state, commands that manipulate mailboxes as
entities are permitted. Of these commands, the SELECT and
commands will select a mailbox for access and enter selected state
In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
the following commands are valid in authenticated state: SELECT
EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB
STATUS, and APPEND
Crispin Standards Track [Page 22]
RFC 2060 IMAP4rev1 December 1996
6.3.1. SELECT
Arguments: mailbox
Responses: REQUIRED untagged responses: FLAGS, EXISTS,
OPTIONAL OK untagged responses: UNSEEN,
Result: OK - select completed, now in selected
NO - select failure, now in authenticated state:
such mailbox, can't access
BAD - command unknown or arguments
The SELECT command selects a mailbox so that messages in
mailbox can be accessed. Before returning an OK to the client
the server MUST send the following untagged data to the client
FLAGS Defined flags in the mailbox. See the
of the FLAGS response for more detail
EXISTS The number of messages in the mailbox. See
description of the EXISTS response for more detail
RECENT The number of messages with the \Recent flag set
See the description of the RECENT response for
detail
OK [UIDVALIDITY ]
The unique identifier validity value. See
description of the UID command for more detail
to define the initial state of the mailbox at the client
The server SHOULD also send an UNSEEN response code in an
untagged response, indicating the message sequence number of
first unseen message in the mailbox
If the client can not change the permanent state of one or more
the flags listed in the FLAGS untagged response, the server
send a PERMANENTFLAGS response code in an OK untagged response
listing the flags that the client can change permanently
Only one mailbox can be selected at a time in a connection
simultaneous access to multiple mailboxes requires
connections. The SELECT command automatically deselects
currently selected mailbox before attempting the new selection
Consequently, if a mailbox is selected and a SELECT command
fails is attempted, no mailbox is selected
Crispin Standards Track [Page 23]
RFC 2060 IMAP4rev1 December 1996
If the client is permitted to modify the mailbox, the
SHOULD prefix the text of the tagged OK response with
"[READ-WRITE]" response code
If the client is not permitted to modify the mailbox but
permitted read access, the mailbox is selected as read-only,
the server MUST prefix the text of the tagged OK response
SELECT with the "[READ-ONLY]" response code. Read-only
through SELECT differs from the EXAMINE command in that
read-only mailboxes MAY permit the change of permanent state on
per-user (as opposed to global) basis. Netnews messages marked
a server-based .newsrc file are an example of such per-
permanent state that can be modified with read-only mailboxes
Example: C: A142 SELECT
S: * 172
S: * 1
S: * OK [UNSEEN 12] Message 12 is first
S: * OK [UIDVALIDITY 3857529045] UIDs
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft
S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)]
S: A142 OK [READ-WRITE] SELECT
6.3.2. EXAMINE
Arguments: mailbox
Responses: REQUIRED untagged responses: FLAGS, EXISTS,
OPTIONAL OK untagged responses: UNSEEN,
Result: OK - examine completed, now in selected
NO - examine failure, now in authenticated state:
such mailbox, can't access
BAD - command unknown or arguments
The EXAMINE command is identical to SELECT and returns the
output; however, the selected mailbox is identified as read-only
No changes to the permanent state of the mailbox,
per-user state, are permitted
Crispin Standards Track [Page 24]
RFC 2060 IMAP4rev1 December 1996
The text of the tagged OK response to the EXAMINE command
begin with the "[READ-ONLY]" response code
Example: C: A932 EXAMINE
S: * 17
S: * 2
S: * OK [UNSEEN 8] Message 8 is first
S: * OK [UIDVALIDITY 3857529045] UIDs
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft
S: * OK [PERMANENTFLAGS ()] No permanent flags
S: A932 OK [READ-ONLY] EXAMINE
6.3.3. CREATE
Arguments: mailbox
Responses: no specific responses for this
Result: OK - create
NO - create failure: can't create mailbox with that
BAD - command unknown or arguments
The CREATE command creates a mailbox with the given name. An
response is returned only if a new mailbox with that name has
created. It is an error to attempt to create INBOX or a
with a name that refers to an extant mailbox. Any error
creation will return a tagged NO response
If the mailbox name is suffixed with the server's
separator character (as returned from the server by a
command), this is a declaration that the client intends to
mailbox names under this name in the hierarchy.
implementations that do not require this declaration MUST
it
If the server's hierarchy separator character appears elsewhere
the name, the server SHOULD create any superior hierarchical
that are needed for the CREATE command to complete successfully
In other words, an attempt to create "foo/bar/zap" on a server
which "/" is the hierarchy separator character SHOULD create foo
and foo/bar/ if they do not already exist
If a new mailbox is created with the same name as a mailbox
was deleted, its unique identifiers MUST be greater than
unique identifiers used in the previous incarnation of the
UNLESS the new incarnation has a different unique
validity value. See the description of the UID command for
detail
Crispin Standards Track [Page 25]
RFC 2060 IMAP4rev1 December 1996
Example: C: A003 CREATE owatagusiam
S: A003 OK CREATE
C: A004 CREATE owatagusiam/
S: A004 OK CREATE
Note: the interpretation of this example depends on whether "/"
was returned as the hierarchy separator from LIST. If "/" is
hierarchy separator, a new level of hierarchy named "owatagusiam
with a member called "blurdybloop" is created. Otherwise,
mailboxes at the same hierarchy level are created
6.3.4. DELETE
Arguments: mailbox
Responses: no specific responses for this
Result: OK - delete
NO - delete failure: can't delete mailbox with that
BAD - command unknown or arguments
The DELETE command permanently removes the mailbox with the
name. A tagged OK response is returned only if the mailbox
been deleted. It is an error to attempt to delete INBOX or
mailbox name that does not exist
The DELETE command MUST NOT remove inferior hierarchical names
For example, if a mailbox "foo" has an inferior "foo.bar
(assuming "." is the hierarchy delimiter character),
"foo" MUST NOT remove "foo.bar". It is an error to attempt
delete a name that has inferior hierarchical names and also
the \Noselect mailbox name attribute (see the description of
LIST response for more details).
It is permitted to delete a name that has inferior
names and does not have the \Noselect mailbox name attribute.
this case, all messages in that mailbox are removed, and the
will acquire the \Noselect mailbox name attribute
The value of the highest-used unique identifier of the
mailbox MUST be preserved so that a new mailbox created with
same name will not reuse the identifiers of the
incarnation, UNLESS the new incarnation has a different
identifier validity value. See the description of the UID
for more detail
Crispin Standards Track [Page 26]
RFC 2060 IMAP4rev1 December 1996
Examples: C: A682 LIST "" *
S: * LIST () "/"
S: * LIST (\Noselect) "/"
S: * LIST () "/" foo/
S: A682 OK LIST
C: A683 DELETE
S: A683 OK DELETE
C: A684 DELETE
S: A684 NO Name "foo" has inferior hierarchical
C: A685 DELETE foo/
S: A685 OK DELETE
C: A686 LIST "" *
S: * LIST (\Noselect) "/"
S: A686 OK LIST
C: A687 DELETE
S: A687 OK DELETE
C: A82 LIST "" *
S: * LIST () "."
S: * LIST () "."
S: * LIST () "." foo.
S: A82 OK LIST
C: A83 DELETE
S: A83 OK DELETE
C: A84 DELETE
S: A84 OK DELETE
C: A85 LIST "" *
S: * LIST () "." foo.
S: A85 OK LIST
C: A86 LIST "" %
S: * LIST (\Noselect) "."
S: A86 OK LIST
6.3.5. RENAME
Arguments: existing mailbox
new mailbox
Responses: no specific responses for this
Result: OK - rename
NO - rename failure: can't rename mailbox with that name
can't rename to mailbox with that
BAD - command unknown or arguments
The RENAME command changes the name of a mailbox. A tagged
response is returned only if the mailbox has been renamed. It
Crispin Standards Track [Page 27]
RFC 2060 IMAP4rev1 December 1996
an error to attempt to rename from a mailbox name that does
exist or to a mailbox name that already exists. Any error
renaming will return a tagged NO response
If the name has inferior hierarchical names, then the
hierarchical names MUST also be renamed. For example, a rename
"foo" to "zap" will rename "foo/bar" (assuming "/" is
hierarchy delimiter character) to "zap/bar".
The value of the highest-used unique identifier of the old
name MUST be preserved so that a new mailbox created with the
name will not reuse the identifiers of the former incarnation
UNLESS the new incarnation has a different unique
validity value. See the description of the UID command for
detail
Renaming INBOX is permitted, and has special behavior. It
all messages in INBOX to a new mailbox with the given name
leaving INBOX empty. If the server implementation
inferior hierarchical names of INBOX, these are unaffected by
rename of INBOX
Examples: C: A682 LIST "" *
S: * LIST () "/"
S: * LIST (\Noselect) "/"
S: * LIST () "/" foo/
S: A682 OK LIST
C: A683 RENAME blurdybloop
S: A683 OK RENAME
C: A684 RENAME foo
S: A684 OK RENAME
C: A685 LIST "" *
S: * LIST () "/"
S: * LIST (\Noselect) "/"
S: * LIST () "/" zowie/
S: A685 OK LIST
Crispin Standards Track [Page 28]
RFC 2060 IMAP4rev1 December 1996
C: Z432 LIST "" *
S: * LIST () "."
S: * LIST () "." INBOX.
S: Z432 OK LIST
C: Z433 RENAME INBOX old-
S: Z433 OK RENAME
C: Z434 LIST "" *
S: * LIST () "."
S: * LIST () "." INBOX.
S: * LIST () "." old-
S: Z434 OK LIST
6.3.6. SUBSCRIBE
Arguments:
Responses: no specific responses for this
Result: OK - subscribe
NO - subscribe failure: can't subscribe to that
BAD - command unknown or arguments
The SUBSCRIBE command adds the specified mailbox name to
server's set of "active" or "subscribed" mailboxes as returned
the LSUB command. This command returns a tagged OK response
if the subscription is successful
A server MAY validate the mailbox argument to SUBSCRIBE to
that it exists. However, it MUST NOT unilaterally remove
existing mailbox name from the subscription list even if a
by that name no longer exists
Note: this requirement is because some server sites may
remove a mailbox with a well-known name (e.g. "system-alerts")
after its contents expire, with the intention of recreating
when new contents are appropriate
Example: C: A002 SUBSCRIBE #news.comp.mail.
S: A002 OK SUBSCRIBE
Crispin Standards Track [Page 29]
RFC 2060 IMAP4rev1 December 1996
6.3.7. UNSUBSCRIBE
Arguments: mailbox
Responses: no specific responses for this
Result: OK - unsubscribe
NO - unsubscribe failure: can't unsubscribe that
BAD - command unknown or arguments
The UNSUBSCRIBE command removes the specified mailbox name
the server's set of "active" or "subscribed" mailboxes as
by the LSUB command. This command returns a tagged OK
only if the unsubscription is successful
Example: C: A002 UNSUBSCRIBE #news.comp.mail.
S: A002 OK UNSUBSCRIBE
6.3..8. LIST
Arguments: reference
mailbox name with possible
Responses: untagged responses:
Result: OK - list
NO - list failure: can't list that reference or
BAD - command unknown or arguments
The LIST command returns a subset of names from the complete
of all names available to the client. Zero or more untagged
replies are returned, containing the name attributes,
delimiter, and name; see the description of the LIST reply
more detail
The LIST command SHOULD return its data quickly, without
delay. For example, it SHOULD NOT go to excess trouble
calculate \Marked or \Unmarked status or perform other processing
if each name requires 1 second of processing, then a list of 1200
names would take 20 minutes
An empty ("" string) reference name argument indicates that
mailbox name is interpreted as by SELECT. The returned
names MUST match the supplied mailbox name pattern. A non-
reference name argument is the name of a mailbox or a level
mailbox hierarchy, and indicates a context in which the
name is interpreted in an implementation-defined manner
Crispin Standards Track [Page 30]
RFC 2060 IMAP4rev1 December 1996
An empty ("" string) mailbox name argument is a special request
return the hierarchy delimiter and the root name of the name
in the reference. The value returned as the root MAY be null
the reference is non-rooted or is null. In all cases,
hierarchy delimiter is returned. This permits a client to get
hierarchy delimiter even when no mailboxes by that name
exist
The reference and mailbox name arguments are interpreted, in
implementation-dependent fashion, into a canonical form
represents an unambiguous left-to-right hierarchy. The
mailbox names will be in the interpreted form
Any part of the reference argument that is included in
interpreted form SHOULD prefix the interpreted form. It
also be in the same form as the reference name argument.
rule permits the client to determine if the returned mailbox
is in the context of the reference argument, or if something
the mailbox argument overrode the 