As per Relevance of the word complete, we have this rfc below:
Network Working Group M.
Request for Comments: 1730 University of
Category: Standards Track December 1994
INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4
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 4 (IMAP4) allows
client to access and manipulate electronic mail messages on a server
IMAP4 permits manipulation of remote message folders,
"mailboxes", in a way that is functionally equivalent to
mailboxes. IMAP4 also provides the capability for an offline
to resynchronize with the server (see also [IMAP-DISC]).
IMAP4 includes operations for creating, deleting, and
mailboxes; checking for new messages; permanently removing messages
setting and clearing flags; RFC 822 and MIME parsing; searching;
selective fetching of message attributes, texts, and
thereof. Messages in IMAP4 are accessed by the use of numbers
These numbers are either message sequence numbers (relative
from 1 to the number of messages in the mailbox) or
identifiers (immutable, strictly ascending values assigned to
message, but which are not necessarily contiguous).
IMAP4 supports a single server. A mechanism for supporting
IMAP4 servers is discussed in [IMSP].
IMAP4 does not specify a means of posting mail; this function
handled by a mail transfer protocol such as [SMTP].
IMAP4 is designed to be upwards compatible from the [IMAP2] protocol
Compatibility issues are discussed in [IMAP-COMPAT].
Crispin [Page i
RFC 1730 IMAP4 December 1994
Table of
IMAP4 Protocol Specification ...................................... 1
1. Organization of this Document ............................. 1
1.1. How to Read This Document ................................. 1
1.2. Conventions Used in this Document ......................... 1
2. Protocol Overview ......................................... 1
2.1. Link Level ................................................ 1
2.2. Commands and Responses .................................... 1
2.2.1. Client Protocol Sender and Server Protocol Receiver ....... 2
2.2.2. Server Protocol Sender and Client Protocol Receiver ....... 2
3. State and Flow Diagram .................................... 4
3.1. Non-Authenticated State ................................... 4
3.2. Authenticated State ....................................... 4
3.3. Selected State ............................................ 4
3.4. Logout State .............................................. 4
4. Data Formats .............................................. 6
4.1. Atom ...................................................... 6
4.2. Number .................................................... 6
4.3. String .................................................... 6
4.3.1. 8-bit and Binary Strings .................................. 7
4.4. Parenthesized List ........................................ 7
4.5. NIL ....................................................... 7
5. Operational Considerations ................................ 8
5.1. Mailbox Naming ............................................ 8
5.2. Mailbox Size and Message Status Updates ................... 8
5.3. Response when no Command in Progress ...................... 8
5.4. Autologout Timer .......................................... 9
5.5. Multiple Commands in Progress ............................. 9
6. Client Commands ........................................... 10
6.1. Client Commands - Any State ............................... 10
6.1.1. CAPABILITY Command ........................................ 10
6.1.2. NOOP Command .............................................. 11
6.1.3. LOGOUT Command ............................................ 11
6.2. Client Commands - Non-Authenticated State ................. 12
6.2.1. AUTHENTICATE Command ...................................... 12
6.2.2. LOGIN Command ............................................. 14
6.3. Client Commands - Authenticated State ..................... 14
6.3.1. SELECT Command ............................................ 15
6.3.2. EXAMINE Command ........................................... 16
6.3.3. CREATE Command ............................................ 17
6.3.4. DELETE Command ............................................ 18
6.3.5. RENAME Command ............................................ 18
Crispin [Page ii
RFC 1730 IMAP4 December 1994
6.3.6. SUBSCRIBE Command ......................................... 19
6.3.7. UNSUBSCRIBE Command ....................................... 19
6.3.8. LIST Command .............................................. 20
6.3.9. LSUB Command .............................................. 22
6.3.10. APPEND Command ............................................ 22
6.4. Client Commands - Selected State .......................... 23
6.4.1. CHECK Command ............................................. 23
6.4.2. CLOSE Command ............................................. 24
6.4.3. EXPUNGE Command ........................................... 25
6.4.4. SEARCH Command ............................................ 25
6.4.5. FETCH Command ............................................. 29
6.4.6. PARTIAL Command ........................................... 32
6.4.7. STORE Command ............................................. 33
6.4.8. COPY Command .............................................. 34
6.4.9. UID Command ............................................... 35
6.5. Client Commands - Experimental/Expansion .................. 37
6.5.1. X Command ........................................... 37
7. Server Responses .......................................... 38
7.1. Server Responses - Status Responses ....................... 39
7.1.1. OK Response ............................................... 40
7.1.2. NO Response ............................................... 40
7.1.3. BAD Response .............................................. 41
7.1.4. PREAUTH Response .......................................... 41
7.1.5. BYE Response .............................................. 41
7.2. Server Responses - Server and Mailbox Status .............. 42
7.2.1. CAPABILITY Response ....................................... 42
7.2.2. LIST Response ............................................. 43
7.2.3. LSUB Response ............................................. 44
7.2.4. SEARCH Response ........................................... 44
7.2.5. FLAGS Response ............................................ 44
7.3. Server Responses - Message Status ......................... 45
7.3.1. EXISTS Response ........................................... 45
7.3.2. RECENT Response ........................................... 45
7.3.3. EXPUNGE Response .......................................... 45
7.3.4. FETCH Response ............................................ 46
7.3.5. Obsolete Responses ........................................ 51
7.4. Server Responses - Command Continuation Request ........... 51
8. Sample IMAP4 session ...................................... 52
9. Formal Syntax ............................................. 53
10. Author's Note ............................................. 64
11. Security Considerations ................................... 64
12. Author's Address .......................................... 64
Appendices ........................................................ 65
A. Obsolete Commands ......................................... 65
A.6.3.OBS.1. FIND ALL.MAILBOXES Command ........................ 65
A.6.3.OBS.2. FIND MAILBOXES Command ............................ 65
A.6.3.OBS.3. SUBSCRIBE MAILBOX Command ......................... 66
A.6.3.OBS.4. UNSUBSCRIBE MAILBOX Command ....................... 66
Crispin [Page iii
RFC 1730 IMAP4 December 1994
B. Obsolete Responses ........................................ 68
B.7.2.OBS.1. MAILBOX Response .................................. 68
B.7.3.OBS.1. COPY Response ..................................... 68
B.7.3.OBS.2. STORE Response .................................... 69
C. References ................................................ 70
E. IMAP4 Keyword Index ....................................... 71
Crispin [Page iv
RFC 1730 IMAP4 December 1994
IMAP4 Protocol
1. Organization of this
1.1. How to Read This
This document is written from the point of view of the implementor
an IMAP4 client or server. Beyond the protocol overview in
2, it is not optimized for someone trying to understand the
of the protocol. The material in sections 3 through 5 provides
general context and definitions with which IMAP4 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, one should not attempt to deduce command syntax from
command section alone; one should instead refer to the formal
section
1.2. Conventions Used in this
In examples, "C:" and "S:" indicate lines sent by the client
server respectively
2. Protocol
2.1. Link
The IMAP4 protocol assumes a reliable data stream such as provided
TCP. When TCP is used, an IMAP4 server listens on port 143.
2.2. Commands and
An IMAP4 session consists of the establishment of a client/
connection, an initial greeting from the server, and client/
interactions. These client/server interactions consist of a
command, server data, and a server 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 IMAP4 client or server is either reading a line, or is
a sequence of octets with a known count followed by a line
Crispin [Page 1]
RFC 1730 IMAP4 December 1994
2.2.1. Client Protocol Sender and Server Protocol
The client command begins an operation. Each client command
prefixed with a 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
command, it sends a BAD completion response with
matching the command (as described below) to reject
command and prevent the client from sending any more of
command
It is also possible for the server to send a
response for some other command (if multiple commands
in progress), or untagged data. In either case,
command continuation request is still pending; the
takes the appropriate action for the response, and
another response from the server
The protocol receiver of an IMAP4 server reads a command line
the client, parses the command and its arguments, and
server data and a server command completion result response
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
Crispin [Page 2]
RFC 1730 IMAP4 December 1994
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 IMAP4 client reads a response line
the server. It then takes action on the response based upon
first token of the response, which may be a tag, a "*", or a "+".
described above
A client MUST be prepared to accept any server response at all times
This includes server data that it may not have requested.
data SHOULD be recorded, so that the client can reference
recorded copy rather than sending a command to the server to
the data. In the case of certain server data, recording the data
mandatory
This topic is discussed in greater detail in the Server
section
Crispin [Page 3]
RFC 1730 IMAP4 December 1994
3. State and Flow
An IMAP4 server is in one of four states. Most commands are valid
only certain states. It is a protocol error for the client
attempt a command while the command is in an inappropriate state.
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 user must supply
credentials before most commands will be permitted. This state
entered when a connection starts unless the connection has
pre-authenticated
3.2. Authenticated
In authenticated state, the user 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
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 session is being terminated, and the server
close the connection. This state can be entered as a result of
client request or by unilateral server decision
Crispin [Page 4]
RFC 1730 IMAP4 December 1994
+--------------------------------------+
|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
Crispin [Page 5]
RFC 1730 IMAP4 December 1994
4. Data
IMAP4 uses textual commands and responses. Data in IMAP4 can be
one of several forms: atom, number, string, parenthesized list,
NIL
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 restrictions of what may be in a quoted 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 respresented 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
request
Crispin [Page 6]
RFC 1730 IMAP4 December 1994
4.3.1. 8-bit and Binary
8-bit textual and binary mail is supported through the use
[MIME-1] encoding. IMAP4 implementations MAY transmit 8-bit
multi-octet characters in literals, but should do so only when
character set is identified
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, although this is not required
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 may itself contain
parenthesized lists, using multiple levels of parentheses to
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 ().
Crispin [Page 7]
RFC 1730 IMAP4 December 1994
5. Operational
5.1. Mailbox
The interpretation of mailbox names is implementation-dependent
However, the mailbox name INBOX is a special name reserved to
"the primary mailbox for this user on this server". If it is
to export hierarchical mailbox names, mailbox names must
left-to-right hierarchical using a single character to
levels of hierarchy. The same hierarchy separator character is
for all levels of hierarchy within a single name
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 details
Regardless of what implementation decisions a client may take
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
Crispin [Page 8]
RFC 1730 IMAP4 December 1994
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
5.5. Multiple Commands in
The client is not required to wait for the completion result
of a command before sending another command, subject to flow
constraints on the underlying data stream. Similarly, a server
not required to process a command to completion before
processing of the next command, unless an ambiguity would
because of a command that would affect the results of other commands
If there is such an ambiguity, the server executes commands
completion in the order given by the client
Crispin [Page 9]
RFC 1730 IMAP4 December 1994
6. Client
IMAP4 commands are described in this section. Commands are
by the state in which the command is permitted. Commands which
permitted in multiple states are listed in the minimum
state (for example, commands valid in authenticated and
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 data to be returned; these
identified by "Data:" in the command descriptions below. See
response descriptions in the Responses section for information
these responses, and the Formal Syntax section for the precise
of these responses. It is possible for server data to be
as a result of any command; thus, commands that do not
require server data specify "no specific data for 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:
Data: mandatory 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 "IMAP4" as the first listed
before the (tagged) OK response. This listing of capabilities
not dependent upon connection state or user. It is therefore
necessary to issue a CAPABILITY command more than once in
session
Crispin [Page 10]
RFC 1730 IMAP4 December 1994
Capability names other than "IMAP4" refer to extensions
revisions, or amendments to this specification. See
documentation of the CAPABILITY response for
information. No capabilities are enabled without explicit
action to invoke the capability. See the section entitled "
Commands - Experimental/Expansion" for information about the
of site or implementation-specific capabilities
Example: C: abcd
S: * CAPABILITY IMAP
S: abcd OK CAPABILITY
6.1.2. NOOP
Arguments:
Data: no specific data 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 [Page 11]
RFC 1730 IMAP4 December 1994
6.1.3. LOGOUT
Arguments:
Data: mandatory untagged response:
Result: OK - logout
BAD - command unknown or arguments
The LOGOUT command informs the server that the client is done
the session. The server must send a BYE untagged response
the (tagged) OK response, and then close the network connection
Example: C: A023
S: * BYE IMAP4 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 [Page 12]
RFC 1730 IMAP4 December 1994
6.2.1. AUTHENTICATE
Arguments: authentication mechanism
Data: continuation data may 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
user. Optionally, it also negotiates a protection mechanism
subsequent protocol interactions. If the requested
mechanism is not supported, the server should reject
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 should issue a line with
single "*". If the server receives such an answer, it must
the AUTHENTICATE command by sending a tagged BAD response
A protection mechanism provides integrity and privacy
to the protocol session. If a protection mechanism is negotiated
it is applied to all subsequent data sent over the connection
The protection mechanism takes effect immediately following
CRLF that concludes the authentication exchange for the client
and the 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
The server is not required to support any
authentication mechanism, nor are authentication
required to support any protection mechanisms. If an
command fails with a NO response, the client may try
Crispin [Page 13]
RFC 1730 IMAP4 December 1994
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 IMAP4
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
editorial clarity and are not in real authenticators
6.2.2. LOGIN
Arguments: user
Data: no specific data 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 user 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
Crispin [Page 14]
RFC 1730 IMAP4 December 1994
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
and APPEND
6.3.1. SELECT
Arguments: mailbox
Data: mandatory 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
EXISTS The number of messages in the
RECENT The number of messages added to the mailbox
the previous time this mailbox was
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. If
is not possible to determine the messages that were added
the previous time a mailbox was read, then all messages SHOULD
considered recent
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 may change permanently
Only one mailbox may be selected at a time in a session
simultaneous access to multiple mailboxes requires
Crispin [Page 15]
RFC 1730 IMAP4 December 1994
sessions. 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
If the user is permitted to modify the mailbox, the server
prefix the text of the tagged OK response with the "[READ-WRITE]"
response code
If the user 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 user's .newsrc file are an example of such per-user
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
Data: mandatory 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 [Page 16]
RFC 1730 IMAP4 December 1994
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
Data: no specific data 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 may, in
future, create mailbox names under this name in the hierarchy
Server implementations that do not require this declaration
ignore it
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
Example: C: A003 CREATE owatagusiam
S: A003 OK CREATE
C: A004 CREATE owatagusiam/
S: A004 OK CREATE
Crispin [Page 17]
RFC 1730 IMAP4 December 1994
Note: the interpretation of this example depends on
"/" was returned as the hierarchy separator from LIST.
"/" is the hierarchy separator, a new level of
named "owatagusiam" with a member called "blurdybloop"
created. Otherwise, two mailboxes at the same
level are created
6.3.4. DELETE
Arguments: mailbox
Data: no specific data 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. Any error in deletion
return a tagged NO response
The value of the highest-used unique indentifier 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
Example: C: A683 DELETE
S: A683 OK DELETE
6.3.5. RENAME
Arguments: existing mailbox
new mailbox
Data: no specific data 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
Crispin [Page 18]
RFC 1730 IMAP4 December 1994
The RENAME command changes the name of a mailbox. A tagged
response is returned only if the mailbox has been renamed. It
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
Renaming INBOX is permitted; a new, empty INBOX is created in
place
Example: C: Z4S9 RENAME blurdybloop
S: Z4S9 OK RENAME
6.3.6. SUBSCRIBE
Arguments:
Data: no specific data 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
Example: C: A002 SUBSCRIBE #news.comp.mail.
S: A002 OK SUBSCRIBE
6.3.7. UNSUBSCRIBE
Arguments: mailbox
Data: no specific data 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
Crispin [Page 19]
RFC 1730 IMAP4 December 1994
Example: C: A002 UNSUBSCRIBE #news.comp.mail.
S: A002 OK UNSUBSCRIBE
6.3.8. LIST
Arguments: reference
mailbox name with possible
Data: 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 user. Zero or more untagged
replies are returned, containing the name attributes,
delimiter, and name; see the description of the LIST reply
more detail
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
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 reference argument.
this rule, the client would have to have knowledge of the server'
naming semantics including what characters are "breakouts"
override a naming context
Crispin [Page 20]
RFC 1730 IMAP4 December 1994
For example, here are some examples of how
and mailbox names might be interpreted on a UNIX-
server
Reference Mailbox Name
------------ ------------ --------------
~smith/Mail/ foo.* ~smith/Mail/foo.*
archive/ % archive/%
#news. comp.mail.* #news.comp.mail.*
~smith/Mail/ /usr/doc/foo /usr/doc/
archive/ ~fred/Mail/* ~fred/Mail/*
The first three examples demonstrate interpretations
the context of the reference argument. Note
"~smith/Mail" should not be transformed into
like "/u2/users/smith/Mail", or it would be
for the client to determine that the interpretation
in the context of the reference
The character "*" is a wildcard, and matches zero or
characters at this position. The character "%" is similar to "*",
but it does not match a hierarchy delimiter. If the "%"
is the last character of a mailbox name argument, matching
of hierarchy are also returned. If these levels of hierarchy
not also selectable mailboxes, they are returned with
\Noselect mailbox name attribute (see the description of the
response for more detail).
Server implementations are permitted to "hide"
accessible mailboxes from the wildcard characters, by
certain characters or names from matching a wildcard in
situations. For example, a UNIX-based server might restrict
interpretation of "*" so that an initial "/" character does
match
The special name INBOX is included in the output from LIST if
matches the input arguments and INBOX is supported by this
for this user. The criteria for omitting INBOX is whether
INBOX will return failure; it is not relevant whether the user'
real INBOX resides on this or some other server
Example: C: A002 LIST "~/Mail/" "%"
S: * LIST (\Noselect) "/" ~/Mail/
S: * LIST () "/" ~/Mail/
S: A002 OK LIST
Crispin [Page 21]
RFC 1730 IMAP4 December 1994
6.3.9. LSUB
Arguments: reference
mailbox name with possible
Data: untagged responses:
Result: OK - lsub
NO - lsub failure: can't list that reference or
BAD - command unknown or arguments
The LSUB command returns a subset of names from the set of
that the user has declared as being "active" or "subscribed".
Zero or more untagged LSUB replies are returned. The arguments
LSUB are in the same form as those for LIST
Example: C: A002 LSUB "#news." "comp.mail.*"
S: * LSUB () "." #news.comp.mail.
S: * LSUB () "." #news.comp.mail.
S: A002 OK LSUB
6.3.10. APPEND
Arguments: mailbox
optional flag parenthesized
optional date/time
message
Data: no specific data for this
Result: OK - append
NO - append error: can't append to that mailbox,
in flags or date/time or message
BAD - command unknown or arguments
The APPEND command appends the literal argument as a new
in the specified destination mailbox. This argument is in
format of an [RFC-822] message. 8-bit characters are permitted
the message. A server implementation that is unable to
8-bit data properly MUST be able to reversibly convert 8-
APPEND data to 7-bit using [MIME-1] encoding
If a flag parenthesized list or date_time are specified, that
SHOULD be set in the resulting message; otherwise, the defaults
empty flags and the current date/time are used
Crispin [Page 22]
RFC 1730 IMAP4 December 1994
If the append is unsuccessful for any reason, the mailbox MUST
restored to its state before the APPEND attempt; no
appending is permitted. If the mailbox is currently selected,
normal new mail actions should occur
If the destination mailbox does not exist, a server MUST return
error, and MUST NOT automatically create the mailbox. Unless
is certain that the destination mailbox can not be created,
server MUST send the response code "[TRYCREATE]" as the prefix
the text of the tagged NO response. This gives a hint to
client that it can attempt a CREATE command and retry the
if the CREATE is successful
Example: C: A003 APPEND saved-messages (\Seen) {310}
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST
C: From: Fred Foobar
C: Subject: afternoon
C: To: mooch@owatagu.siam.
C: Message-Id:
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-
C
C: Hello Joe, do you think we can meet at 3:30 tomorrow
C
S: A003 OK APPEND
Note: the APPEND command is not used for message delivery
because it does not provide a mechanism to transfer [SMTP
envelope information
6.4. Client Commands - Selected
In selected state, commands that manipulate messages in a mailbox
permitted
In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
and the authenticated state commands (SELECT, EXAMINE, CREATE
DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB,
ALL.MAILBOXES, FIND MAILBOXES, and APPEND), the following
are valid in the selected state: CHECK, CLOSE, EXPUNGE, SEARCH
FETCH, PARTIAL, STORE, COPY, and UID
Crispin [Page 23]
RFC 1730 IMAP4 December 1994
6.4.1. CHECK
Arguments:
Data: no specific data for this
Result: OK - check
BAD - command unknown or arguments
The CHECK command requests a checkpoint of the currently
mailbox. A checkpoint refers to any implementation-
housekeeping associated with the mailbox (e.g. resolving
server's in-memory state of the mailbox with the state on
disk) that is not normally executed as part of each command.
checkpoint may take a non-instantaneous amount of real time
complete. If a server implementation has no such
considerations, CHECK is equivalent to NOOP
There is no guarantee that an EXISTS untagged response will
as a result of CHECK. NOOP, not CHECK, should be used for
mail polling
Example: C: FXXZ
S: FXXZ OK CHECK
6.4.2. CLOSE
Arguments:
Data: no specific data for this
Result: OK - close completed, now in authenticated
NO - close failure: no mailbox
BAD - command unknown or arguments
The CLOSE command permanently removes from the currently
mailbox all messages that have the \Deleted flag set, and
to authenticated state from selected state. No untagged
responses are sent
No messages are removed, and no error is given, if the mailbox
selected by an EXAMINE command or is otherwise selected read-only
Even when a mailbox is selected, it is not required to send
CLOSE command before a SELECT, EXAMINE, or LOGOUT command.
SELECT, EXAMINE, and LOGOUT commands implicitly close
currently selected mailbox without doing an expunge. However
Crispin [Page 24]
RFC 1730 IMAP4 December 1994
when many messages are deleted, a CLOSE-LOGOUT or CLOSE-
sequence is considerably faster than an EXPUNGE-LOGOUT
EXPUNGE-SELECT because no untagged EXPUNGE responses (which
client would probably ignore) are sent
Example: C: A341
S: A341 OK CLOSE
6.4.3. EXPUNGE
Arguments:
Data: untagged responses:
Result: OK - expunge
NO - expunge failure: can't expunge (e.g.
denied
BAD - command unknown or arguments
The EXPUNGE command permanently removes from the
selected mailbox all messages that have the \Deleted flag set
Before returning an OK to the client, an untagged EXPUNGE
is sent for each message that is removed
Example: C: A202
S: * 3
S: * 3
S: * 5
S: * 8
S: A202 OK EXPUNGE
Note: in this example, messages 3, 4, 7, and 11 had
\Deleted flag set. See the description of the
response for further explanation
Crispin [Page 25]
RFC 1730 IMAP4 December 1994
6.4.4. SEARCH
Arguments: optional character set
searching criteria (one or more
Data: mandatory untagged response:
Result: OK - search
NO - search error: can't search that character set
BAD - command unknown or arguments
The SEARCH command searches the mailbox for messages that
the given searching criteria. Searching criteria consist of
or more search keys. The untagged SEARCH response from the
contains a listing of message sequence numbers corresponding
those messages that match the searching criteria
When multiple keys are specified, the result is the
(AND function) of all the messages that match those keys.
example, the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994
to all deleted messages from Smith that were placed in the
since February 1, 1994. A search key may also be a
list of one or more search keys (e.g. for use with the OR and
keys).
Server implementations MAY exclude [MIME-1] body parts
terminal content types other than TEXT and MESSAGE
consideration in SEARCH matching
The optional character set specification consists of the
"CHARSET" followed by a registered MIME character set.
indicates the character set of the strings that appear in
search criteria. [MIME-2] strings that appear in RFC 822/
message headers, and [MIME-1] content transfer encodings, MUST
decoded before matching. Except for US-ASCII, it is not
that any particular character set be supported. If the
does not support the specified character set, it MUST return
tagged NO response (not a BAD).
In all search keys that use strings, a message matches the key
the string is a substring of the field. The matching
case-insensitive
Crispin [Page 26]
RFC 1730 IMAP4 December 1994
The defined search keys are as follows. Refer to the
Syntax section for the precise syntactic definitions of
arguments
Messages with message sequence
corresponding to the specified message
number
ALL All messages in the mailbox; the default
key for ANDing
ANSWERED Messages with the \Answered flag set
BCC Messages that contain the specified string in
envelope structure's BCC field
BEFORE Messages whose internal date is earlier than
specified date
BODY Messages that contain the specified string in
body of the message
CC Messages that contain the specified string in
envelope structure's CC field
DELETED Messages with the \Deleted flag set
DRAFT Messages with the \Draft flag set
FLAGGED Messages with the \Flagged flag set
FROM Messages that contain the specified string in
envelope structure's FROM field
HEADER
Messages that have a header with the
field-name (as defined in [RFC-822]) and
contains the specified string in the [RFC-822]
field-body
KEYWORD Messages with the specified keyword set
LARGER Messages with an RFC822.SIZE larger than
specified number of octets
NEW Messages that have the \Recent flag set but not
\Seen flag. This is functionally equivalent
"(RECENT UNSEEN)".
Crispin [Page 27]
RFC 1730 IMAP4 December 1994
NOT
Messages that do not match the specified
key
OLD Messages that do not have the \Recent flag set
This is functionally equivalent to "NOT RECENT" (
opposed to "NOT NEW").
ON Messages whose internal date is within
specified date
OR
Messages that match either search key
RECENT Messages that have the \Recent flag set
SEEN Messages that have the \Seen flag set
SENTBEFORE
Messages whose [RFC-822] Date: header is
than the specified date
SENTON Messages whose [RFC-822] Date: header is within
specified date
SENTSINCE
Messages whose [RFC-822] Date: header is within
later than the specified date
SINCE Messages whose internal date is within or
than the specified date
SMALLER Messages with an RFC822.SIZE smaller than
specified number of octets
SUBJECT
Messages that contain the specified string in
envelope structure's SUBJECT field
TEXT Messages that contain the specified string in
header or body of the message
TO Messages that contain the specified string in
envelope structure's TO field
UID
Messages with unique identifiers corresponding
the specified unique identifier set
Crispin [Page 28]
RFC 1730 IMAP4 December 1994
UNANSWERED Messages that do not have the \Answered flag set
UNDELETED Messages that do not have the \Deleted flag set
UNDRAFT Messages that do not have the \Draft flag set
UNFLAGGED Messages that do not have the \Flagged flag set
UNKEYWORD
Messages that do not have the specified
set
UNSEEN Messages that do not have the \Seen flag set
Example: C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith
S: * SEARCH 2 84 882
S: A282 OK SEARCH
6.4.5. FETCH
Arguments: message
message data item
Data: untagged responses:
Result: OK - fetch
NO - fetch error: can't fetch that
BAD - command unknown or arguments
The FETCH command retrieves data associated with a message in
mailbox. The data items to be fetched may be either a single
or a parenthesized list. The currently defined data items
can be fetched are
ALL Macro equivalent to: (FLAGS
RFC822.SIZE ENVELOPE
BODY Non-extensible form of BODYSTRUCTURE
BODY[]
The text of a particular body section. The
specification is a set of one or more part
delimited by periods
Single-part messages only have a part 1.
Crispin [Page 29]
RFC 1730 IMAP4 December 1994
Multipart messages are assigned consecutive
numbers, as they occur in the message. If
particular part is of type message or multipart
its parts must be indicated by a period followed
the part number within that nested multipart part
It is not permitted to fetch a multipart
itself, only its individual members
A part of type MESSAGE and subtype RFC822 also
nested parts. These are the parts of the
part's body. Nested part 0 of a part of
MESSAGE and subtype RFC822 is the [RFC-822]
of the message
Every message has at least one part
Here is an example of a complex
with its associated
specifications
0 ([RFC-822] header of the message
MULTIPART/
1 TEXT/
2 APPLICATION/OCTET-
3 MESSAGE/RFC822
3.0 ([RFC-822] header of the message
3.1 TEXT/
3.2 APPLICATION/OCTET-
MULTIPART/
4.1 IMAGE/
4.2 MESSAGE/RFC822
4.2.0 ([RFC-822] header of the message
4.2.1 TEXT/
MULTIPART/
4.2.2.1 TEXT/
4.2.2.2 TEXT/
Note that there is no
specification for the Multi-part
(no section 4 or 4.2.2).
The \Seen flag is implicitly set; if this
the flags to change they should be included as
of the fetch responses
BODY.PEEK[]
An alternate form of BODY[section] that does
implicitly set the \Seen flag
Crispin [Page 30]
RFC 1730 IMAP4 December 1994
BODYSTRUCTURE The [MIME-1] body structure of the message.
is computed by the server by parsing the [MIME-1]
header lines
ENVELOPE The envelope structure of the message. This
computed by the server by parsing the [RFC-822]
header into the component parts, defaulting
fields as necessary
FAST Macro equivalent to: (FLAGS
RFC822.SIZE
FLAGS The flags that are set for this message
FULL Macro equivalent to: (FLAGS
RFC822.SIZE ENVELOPE BODY
INTERNALDATE The date and time of final delivery of the
as defined by RFC 821.
RFC822 The message in [RFC-822] format. The \Seen flag
implicitly set; if this causes the flags to
they should be included as part of the
responses. This is the concatenation
RFC822.HEADER and RFC822.TEXT
RFC822.PEEK An alternate form of RFC822 that does
implicitly set the \Seen flag
RFC822.HEADER The [RFC-822] format header of the message
stored on the server including the delimiting
line between the header and the body
RFC822.HEADER.LINES
All header lines (including continuation lines)
the [RFC-822] format header of the message with
field-name (as defined in [RFC-822]) that
any of the strings in header_list. The matching
case-insensitive but otherwise exact.
delimiting blank line between the header and
body is always included
Crispin [Page 31]
RFC 1730 IMAP4 December 1994
RFC822.HEADER.LINES.NOT
All header lines (including continuation lines)
the [RFC-822] format header of the message with
field-name (as defined in [RFC-822]) that does
match any of the strings in header_list.
matching is case-insensitive but otherwise exact
The delimiting blank line between the header
the body is always included
RFC822.SIZE The number of octets in the message, as
in [RFC-822] format
RFC822.TEXT The text body of the message, omitting
[RFC-822] header. The \Seen flag is
set; if this causes the flags to change they
be included as part of the fetch responses
RFC822.TEXT.
An alternate form of RFC822.TEXT that does
implicitly set the \Seen flag
UID The unique identifier for the message
Example: C: A654 FETCH 2:4 (FLAGS RFC822.HEADER.LINES (DATE FROM))
S: * 2 FETCH ....
S: * 3 FETCH ....
S: * 4 FETCH ....
S: A003 OK FETCH
6.4.6. PARTIAL
Arguments: message sequence
message data item
position of first
number of
Data: untagged responses:
Result: OK - partial
NO - partial error: can't fetch that
BAD - command unknown or arguments
The PARTIAL command is 