RFC relevance of february

As per Relevance of the word february, we have this rfc below:

Network Working Group J.
Request for Comments: 1203
Obsoletes: RFC 1064 February 1991

INTERACTIVE MAIL ACCESS PROTOCOL - VERSION 3

Status of this

This RFC suggests a method for workstations to access
dynamically from a mailbox server ("repository"). This RFC
a standard for the SUMEX-AIM community and an Experimental
for the Internet community. Discussion and suggestions
improvement are requested. Please refer to the current edition
the "IAB Official Protocol Standards" for the standardization
and status of this protocol. Distribution of this memo is unlimited

The following document is a modified version of RFC 1064,
definition of the IMAP2 protocol. This RFC has been
specifically as a counter proposal to RFC 1176, which itself
modifications to IMAP2. Sadly, RFC 1176 was made without
consultation with the IMAP community, so we are in a position
feeling we have to present a counter proposal to what, if we do
act, will become a de facto standard. The reasons for this
proposal are numerous but fall mostly into the following categories

- IMAP2 is insufficiently powerful for a number of server/
interactions which we believe to be important. RFC 1176
negligibly enhances the functionality of IMAP2.

- IMAP2 makes what we believe to be an erroneous definition
unsolicited vs. solicited data. IMAP3 as specified
attempts to correct this. RFC 1176 makes no effort to
these problems

- RFC 1176 has explicitly modified the intent of RFC 1064
allowing the server to make assumptions about the client'
caching architecture. We believe this to be a grave
and do not support it in this proposal

- RFC 1176 specifies a number of "optional" features in
protocol without specifying a suitable metaprotocol by
servers and clients can adequately negotiate over the set
implemented features. This proposal specifies a
by which servers and clients can come to an
understanding about which features are usable by each party

Rice [Page 1]

RFC 1203 IMAP3 February 1991

- RFC 1176 pays only lip-service to being network
independent and, in fact assumes the use of TCP/IP.
RFC 1064 nor this proposal make any such assumption

Although there are numerous other detailed objections to RFC 1176,
believe that the above will serve to show that we believe strongly
the importance of mailbox abstraction level mail protocols and,
a couple of years of use of IMAP2 under RFC 1064 we believe that
have a good enough understanding of the issues involved to be able
take the next step

It is important to take this next step because of the rapid pace
both mail system and user interface development. We believe that
for IMAP not to die in its infancy, IMAP must be ready to respond
emerging ISO and RFC standards in mail, such as for multi-media mail
We believe that RFC 1176 not only provides a very small increment
functionality over RFC 1064 but also adds a number of bugs,
would be detrimental to the IMAP cause. Thus we propose
following definition for IMAP3.

Compatibility notes

In revising the IMAP2 protocol it has been our intent,
possible to make upwards compatible changes to produce IMAP3.
were, however, some places that had to be changed incompatibly
order to compensate for either ambiguities in the IMAP2 protocol
defined by RFC 1064 or behavior that proved undesirable in the
of experience

It is our goal, however, that existing IMAP2 clients should still
supported and that, at least for the foreseeable future, all IMAP
servers will support IMAP2 behavior as their default mode

The following are the major differences between this proposal,
1176 and RFC 1064:

- In this proposal we specify a difference between "solicited"
"unsolicited" data sent from the server. It is generally
case that data sent by the server can be sent either in
to an explicit request by the client or by the server of its
volition. Any data that the server is required to sent to
client as the result of a request is said to be solicited
carries the same tag as the request that provoked it. Any
sent by the server to the client that is not required by
protocol is said to be unsolicited and carries the special "*"
tag. RFC 1176 preserves the original RFC 1064 terminology
calls all such data sent by the server "unsolicited" even

Rice [Page 2]

RFC 1203 IMAP3 February 1991

it is, in fact, solicited

- This proposal introduces the experimental concept
distinguishing between Generic, Canonical and Concrete keys
allowing the mailbox to be viewed as a relational
indexed by these keys. This should allow the IMAP
to evolve away from its current reliance on RFC 822. RFC 1176
does not have such a unifying model

- The SEARCH command has been changed so as to allow
simultaneous searches to be made and to allow
search messages to be sent by the server. Such a change
essential to allow more sophisticated servers that can
commands asynchronously, possibly substantially
searches over slow backing storage media, for example. It
also important to allow servers to be able to send
search messages that might inform the client of
patterns of messages, such as new and unseen mail

- This proposal introduces a specific protocol for the
of protocol versions and server features. This is
because it allows client/server pairs to come to an agreement
what behavior is really available to it. RFC 1176 introduces
number of "optional" commands, which are in some way
to "feature-introduced" commands in this proposal. The
distinction between these is that in RFC 1176 there is no
for a client to discover the set of optional commands, nor
there a way for it to determine whether a specific
really is supported, since RFC 1176 requires the use of
"BAD" response if a feature is not supported. There is
therefore, no way for the client to determine why the
command did not work. This also means that, for example,
client cannot disable certain user commands or make
invisible on menus if they are not supported, since
is no way for the client to discover whether the commands
indeed supported without trying to execute such a command

- This proposal introduces a mechanism for clients to create
delete user flags (keywords). This is nor supported in
RFC 1176 or RFC 1064, requiring the user to add keys
on the server, generally by editing some form of "init" file

- RFC 1064 has no mechanism for determining whether a mailbox
readonly or not. RFC 1176 introduces a non-enforced
of encoding data about the readonly status of a mailbox in
SELECT message's OK respose comment field. This is not
with respect to the rest of the protocol, in which the
field is used for no purpose other than documentation.

Rice [Page 3]

RFC 1203 IMAP3 February 1991

proposal introduces specific protocol additions for the
determination and modification of the readonly/readwrite
of mailboxes

The intent of the Interactive Mail Access Protocol, Version 3 (IMAP3)
is to allow a (possibly unreliable) workstation or similar machine
access electronic mail from a reliable mailbox server in an
manner

Although different in many ways from POP2 (RFC 937), IMAP3 may
thought of as a functional superset of POP2, and the POP2 RFC
used as a model for this RFC. There was a cognizant reason for this
RFC 937 deals with an identical problem and it was desirable to
a basis for comparison

Like POP2, IMAP3 specifies a means of accessing stored mail and
of posting mail; this function is handled by a mail transfer
such as SMTP (RFC 821). A comparison with the DMSP protocol
PCMAIL can be found at the end of "System Model and Philosophy
section

This protocol assumes a reliable data stream such as provided by
or any similar protocol. When TCP is used, the IMAP server
on port 220. When CHAOS is used the IMAP server listens for
logical contact name "IMAP3".

Communication in IMAP is defined to be using the ASCII
interpretation of data. Communication using other conventions may
possible by the selection of features on some servers

System Model and

Electronic mail is a primary means of communication for the
spread SUMEX-AIM community. The advent of distributed
is forcing a significant rethinking of the mechanisms employed
manage such mail. With mainframes, each user tends to receive
process mail at the computer he used most of the time, his "
host". The first inclination of many users when an
workstation is placed in front of them is to begin receiving mail
the workstation, and, in fact, many vendors have
facilities to do this. However, this approach has
disadvantages

(1) Workstations (especially Lisp workstations) have a
design that gives full control of all aspects of the
to the user at the console. As a result, background tasks

Rice [Page 4]

RFC 1203 IMAP3 February 1991

like receiving mail, could well be kept from running
long periods of time either because the user is asking
use all of the machine's resources, or because, in the
of working, the user has (perhaps accidentally)
the environment in such a way as to prevent mail reception
This could lead to repeated failed delivery attempts
outside agents

(2) The hardware failure of a single workstation could keep
user "off the air" for a considerable time, since repair
individual workstation units might be delayed. Given
growing number of workstations spread throughout
environments, quick repair would not be assured, whereas
centralized mainframe is generally repaired very soon
failure

(3) It is more difficult to keep track of mailing addresses
each person is associated with a distinct machine.
the difficulty in keeping track of a large number of
addresses or phone numbers, particularly if there was
single address or phone number for an organization
which you could reach any person in that organization
Traditionally, electronic mail on the ARPANET
remembering a name and one of several "hosts" (machines
whose name reflected the organization in which
individual worked. This was suitable at a time when
organizations had only one central host. It is
satisfactory today unless the concept of a host is
to refer to an organizational entity and not a
machine

(4) It is very difficult to keep a multitude of
workstations working properly with complex mailing protocols
making it difficult to move forward as progress is made
electronic communication and as new standards emerge.
system has to worry about receiving incoming mail,
and delivering outgoing mail, formatting, storing,
providing for the stability of mailboxes over a variety
possible filing and mailing protocols

Consequently, while the workstation may be viewed as an Internet
in the sense that it implements IP, it should not be viewed as
entity which contains the user's mailbox. Rather, a mail
machine (sometimes called a "repository") should hold the mailbox
and the workstation (hereafter referred to as a "client")
access the mailbox via mail transactions. Because the mail
machine would be isolated from direct user manipulation, it
achieve high software reliability easily, and, as a shared resource

Rice [Page 5]

RFC 1203 IMAP3 February 1991

it could achieve high hardware reliability, perhaps
redundancy. The mail server could be used from arbitrary locations
allowing users to read mail across campus, town, or country
more and more commonly available clients. Furthermore, the same
may access his mailbox from different clients at different times,
multiple users may access the same mailbox simultaneously

The mail server acts an an interface among users, data storage,
other mailers. The mail access protocol is used to
messages, access and change properties of messages, and
mailboxes. This differs from some approaches (e.g., Unix mail
NFS) in that the mail access protocol is used for all
manipulations, isolating the user and the client from all
of how the data storage is used. This means that the mail server
utilize the data storage in whatever way is most efficient
organize the mail in that particular environment, without having
worry about storage representation compatibility across
machines

In defining a mail access protocol, it is important to keep in
that the client and server form a macrosystem, in which it should
possible to exploit the strong points of both while compensating
each other's weaknesses. Furthermore, it's desirable to allow for
growth path beyond the hoary text-only RFC 822 protocol.
POP2, IMAP3 has extensive features for remote searching and
of messages on the server. For example, a free text
(optionally in conjunction with other searching) can be
throughout the entire mailbox by the server and the results
available to the client without the client having to transfer
entire mailbox and searching itself. Since remote parsing of
message into a structured (and standard format) "envelope"
available, a client can display envelope information and
commands such as REPLY without having any understanding of how
parse RFC 822, etc., headers

Additionally, IMAP3 offers several facilities for managing a
beyond the simple "delete message" functionality of POP2.

In spite of this, IMAP3 is a relatively simple protocol.
servers should implement the full set of IMAP3 functions, a
client can be written which uses IMAP3 in much the way as a POP
client

IMAP3 differs from the DMSP protocol of PCMAIL (RFC 1056) in a
fundamental manner, reflecting the differing architectures of
and PCMAIL. PCMAIL is either an online ("interactive mode"),
offline ("batch mode") system. IMAP is primarily an online system
which real-time and simultaneous mail access were

Rice [Page 6]

RFC 1203 IMAP3 February 1991

important

In PCMAIL, there is a long-term client/server relationship in
some mailbox state is preserved on the client. There is
registration of clients used by a particular user, and the
keeps a set of "descriptors" for each message which summarize
message. The server and client synchronize their states when
DMSP connection starts up, and, if a client has not accessed
server for a while, the client does a complete reset (reload) of
state from the server

In IMAP, the client/server relationship lasts only for the
of the IMAP3 connection. All mailbox state is maintained on
server. There is no registration of clients. The function of
descriptor is handled by a structured representation of the
"envelope". This structure makes it unnecessary for a client to
anything about RFC 822 parsing. There is no synchronization
the client does not remember state between IMAP3 connections.
is not a problem since in general the client never needs the
state of the mailbox in a single session, therefore there isn't
overhead in fetching the state information that is needed as it
needed

There are also some functional differences between IMAP3 and DMSP
DMSP has functions for sending messages, printing messages,
changing passwords, all of which are done outside of IMAP3. DMSP
16 binary flags of which 8 are defined by the system. IMAP has
names; there are currently 5 defined system flag names and a
for some number (29 in the current implementations) of user
names. IMAP3 has a sophisticated message search facility in
server to identify interesting messages based on dates, addresses
flag status, or textual contents without compelling the client
fetch this data for every message

It was felt that maintaining state on the client is advantageous
in those cases where the client is only used by a single user, or
there is some means on the client to restrict access to
user's data. It can be a serious disadvantage in an environment
which multiple users routinely use the same client, the same
routinely uses different clients, and where there are no
restrictions on the client. It was also observed that most user
access is to a relatively small set of "interesting" messages,
were either "new" mail or mail based upon some user-
criteria. Consequently, IMAP3 was designed to easily identify
"interesting" messages so that the client could fetch the state
those messages and not those that were not "interesting".

One crucial philosophical difference between IMAP and other

Rice [Page 7]

RFC 1203 IMAP3 February 1991

mail protocols is that IMAP is a mailbox access protocol, not
protocol for manipulating mail files. In the IMAP model,
other mail system models in which mail is stored in a linear
file, no specification is made for the implementation
for mail storage. Servers may choose to implement mailboxes as
but this is a detail of which the client can be totally unaware

What is more, in the IMAP model, mailboxes are viewed as
from keys into values. There are broadly three types of keys
generic, canonical and concrete. Generic keys are generic,
protocol independent keys defined by IMAP which are meaningful
multiple mail encoding formats. An example of such a generic
might be "TO", which would be associated with the "To:" field of
RFC 822 format message

Canonical keys represent the way in which the server can
values that are generally "about" a certain key concept,
integrating several mail format specific fields, without having
worry the client with the particular details of any
message format. Thus, the canonical TO key (called $TO) could
anything that could reasonably be construed as being directed
someone. Hence, in an RFC 822 message the server could find
union of the "To:", "Resent-To", "Apparently-To:" and "CC:" fields
be the appropriate value associated with the canonical $TO key

Concrete keys allow the client to gain access to certain mail
specific concepts, that are not pre-specified by the IMAP protocol
in a well defined manner. For example, If the client asks for
value associated with the "APPARENTLY-TO" key then, if the
were to be in RFC 822 format, the server would look for a
field called "Apparently-To:". If no such field is found or
field is not implemented or meaningful for the particular
format then the server will respond with the null value, called NIL
indicating the non-existence of the field

Thus, IMAP servers are at liberty to implement mailboxes as
relational databases if it seems convenient. Indeed, we
that future mail systems will tend to use database technology for
storage and indexing of mailboxes as a result of the pressure
by the increasing size of mailboxes

Although for historical reasons IMAP is currently somewhat
associated with RFC 822, we anticipate that future developments
IMAP will remove these mail format specific components and will
towards the generic model mentioned above. This will allow IMAP
easily to incorporate such things as multi-media mail

Rice [Page 8]

RFC 1203 IMAP3 February 1991

The

The IMAP3 protocol consists of a sequence of client commands
server responses to those commands, with extra information from
server data being sent asynchronously to and independent to
responses to client commands. Unlike most Internet protocols
commands and responses are tagged. That is, a command begins with
unique identifier (typically a short alphanumeric sequence such as
Lisp "gensym" function would generate e.g., A0001, A0002, etc.),
called a tag. The response to this command is given the same
from the server

We distinguish between data sent by the server as the result of
client request, which we term "SOLICITED" and data sent by the
not as the result of a client request, which we term "UNSOLICITED".
The server may send unsolicited data at any time that would
fragment another piece of data on the same stream rendering
unintelligible. The server is contractually required, however,
return all data that is solicited by the client before the return
the completion signal for that command, i.e., all solicited data
be returned within the temporal extent of the request/
acknowledgement wrapper. This does not, however, preclude
simultaneous processing of multiple requests by the client, it
requires that the client be confident that it has all the
data when a request finishes. This allows the implementation of
synchronous and asynchronous clients

Solicited data is identified by the tag of the initial request by
client. Unsolicited data is identified by the special reserved
of "*". There is another special reserved tag, "+", discussed below

Note: the tagging of SOLICITED data is only permitted for a
server version other than 2.0.

No assumptions concerning serial or monolithic processing by
server can be made by a correct client. The server is at liberty
process multiple requests by the same client in any order.
allows servers to process costly searches over mailboxes on
backing storage media in the background, while still
interactive performance. Clients can, however, assume
serialization of the request/data/completion behavior
above

When a connection is opened the server sends an unsolicited
response as a greeting message and then waits for commands.
commands are received the server acts on them and responds
responses, often interspersed with data

Rice [Page 9]

RFC 1203 IMAP3 February 1991

The client opens a connection, waits for the greeting, then sends
LOGIN command with user name and password arguments to
authorization. Following an OK response from the server, the
then sends a SELECT command to access the desired mailbox.
user's default mailbox has a special reserved name of "INBOX"
is independent of the operating system that the server is
on. The server will generally send a list of valid flags, number
messages, and number of messages arrived since last access for
mailbox as solicited data, followed by an OK response. The
may terminate access to this mailbox and access a different one
another SELECT command

Because the SELECT command affects the state of the server in
fundamental way, the server is required to process all
commands for any given mailbox before sending the OK tag for
SELECT command. Thus, the client will always know that all
before an OK SELECT response will refer to the old mailbox and
responses following it will apply to the new mailbox

Because, in the real world, local needs or experimental work
dictate that servers will support both supersets of the
behavior and incompatible changes, servers will support
SELECT.VERSION command and a SELECT.FEATURES command, the purpose
which is to allow clients to select the overall behavior and
features that they want from a server. The default behavior of
server is to process commands and to have interaction syntax the
as is specified by IMAP2 in RFC 1064. A server may not behave in
other manner unless the SELECT.VERSION or SELECT.FEATURES
are used to select different behavior

Over time, when groups of generally useful changes to the current
default behavior of the server are found, these will be
together and incorporated in such a way that all of the features
be selected simply by selecting a particular major version number
the protocol. It should be noted that the version numbers (
major and minor) selected by the SELECT.VERSION command
versions of the IMAP protocol, not versions of the server per se
Thus, although in general changes to the protocol specification
be made in such a way that they are upwards compatible, this
be guaranteed. No client should rely on tests of the form "
major_version > 2 then..." being valid for all protocol versions
since incompatible changes might be made in the future

The client reads mailbox information by means of FETCH commands.
actual data is transmitted via the solicited data mechanism (that is
FETCH should be viewed as poking the server to include the
data along with any other data it wishes to transmit to the client).
There are three major categories of data which may be fetched

Rice [Page 10]

RFC 1203 IMAP3 February 1991

The first category is that data which is associated with a message
an entity in the mailbox. There are presently three such items
data: the "internal date", the "RFC 822 size", and the "flags".
internal date is the date and time that the message was placed in
mailbox. The RFC 822 size is subject to deletion in the future;
is the size in bytes of the message, expressed as an RFC 822
string. Current clients only use it as part of a status
line. The flags are a list of status flags associated with
message (see below). All of the first category data can be
by using the macro-fetch word "FAST"; that is, "FAST" expands
"(FLAGS INTERNALDATE RFC822.SIZE)".

The second category is that data which describes the composition
delivery information of a message; that is, information such as
message sender, recipient lists, message-ID, subject, etc. This
the information which is stored in the message header in RFC 822
format message and is traditionally called the "envelope". [Note
this should not be confused with the SMTP (RFC 821) envelope,
is strictly limited to delivery information.] IMAP3 defines
structured and unambiguous representation for the envelope which
particularly nice for Lisp-based parsers. A client can use
envelope for operations such as replying and not worry about RFC 822
at all. Envelopes are discussed in more detail below. The first
second category data can be fetched together by using the macro-
word "ALL"; that is, "ALL" expands to "(FLAGS
RFC822.SIZE ENVELOPE)".

The third category is that data which is intended for direct
viewing. The present RFC 822 based IMAP3 defines three such items
RFC822.HEADER, RFC822.TEXT, and RFC822 (the latter being the
former appended together in a single text string). Fetching "RFC822"
is equivalent to typing the RFC 822 representation of the message
stored on the mailbox without any filtering or processing

Typically, a client will "FETCH ALL" for some or all of the
in the mailbox for use as a presentation menu, and when the
wishes to read a particular message will "FETCH RFC822.TEXT" to
the message body. A more primitive client could, of course,
"FETCH RFC822" a la POP2-type functionality

The client can alter certain data by means of a STORE command. As
example, a message is deleted from a mailbox by a STORE command
includes the \DELETED flag as one of the flags being set

Other client operations include copying a message to another
(COPY command), permanently removing deleted messages (
command), checking for new messages (CHECK command), and
for messages which match certain criteria (SEARCH command).

Rice [Page 11]

RFC 1203 IMAP3 February 1991

The client terminates the session with the LOGOUT command.
server returns a "BYE" followed by an "OK".

A Typical

Client
------ ------
{Wait for Connection
{Open Connection} -->
<-- * OK IMAP3 Server
{Wait for command
A001 SUPPORTED.VERSIONS -->
<-- * SUPPORTED.VERSIONS ((2 0 )
(3 0 EIGHT.BIT.
AUTO.SET.
TAGGED.SOLICITED))
A001 OK Supported Versions returned
{Wait for command
A002 SELECT.VERSION (3 0) -->
<-- A002 OK Version 3.0 Selected
{Wait for command
A002 SELECT.FEATURES TAGGED.SOLICITED -->
<-- A002 OK Features selected
{Wait for command
A003 LOGIN Fred Secret -->
<-- A003 OK User Fred logged
{Wait for command
A004 SELECT INBOX -->
<-- A004 FLAGS (Meeting Notice \
\Flagged \Deleted \Seen
<-- A004 19
<-- A004 2
<-- A004 OK Select
{Wait for command
A005 FETCH 1:19 ALL -->
<-- A005 1 Fetch (......)
...
<-- A005 18 Fetch (......)
<-- A005 19 Fetch (......)
<-- A005 OK Fetch
{Wait for command
A006 FETCH 8 RFC822.TEXT -->
<-- A006 8 Fetch (RFC822.TEXT {893}
...893 characters of text...
<-- )
<-- A006 OK Fetch
{Wait for command

Rice [Page 12]

RFC 1203 IMAP3 February 1991

A007 STORE 8 +Flags \Deleted -->
<-- A007 8 Store (Flags (\
\Seen))
<-- A007 OK Store
{Wait for command
A008 EXPUNGE -->
<-- A008 19
<-- A008 8
<-- A008 18
<-- A008 Expunge
{Wait for command
A009 LOGOUT -->
<-- A009 BYE IMAP3 server
<-- A009 OK Logout
{Close Connection} --><-- {Close connection
{Go back to start

A more complex scenario produced by a pipelining multiprocess client

Client
------ ------
{Wait for Connection
{Open session as above
<-- A004 19
<-- A004 2
<-- A004 OK Select
{Wait for command
A005 SEARCH RECENT -->
<-- A005 SEARCH (18 19) (RECENT
<---A005 OK Search
A006 FETCH 18:19 ALL RFC822.
A007 STORE 18:19 +FLAGS (\SEEN
A008 FETCH 1:17 ALL -->
<-- A006 18 Fetch (... RFC822.TEXT ...)
A009 STORE 18 +FLAGS (\DELETED
<-- A006 19 Fetch (... RFC822.TEXT ...)
<-- A006 OK Fetch
<-- A007 18 STORE (Flags (\Seen))
A010 STORE 19 +FLAGS (\DELETED
<-- A007 19 STORE (Flags (\Seen))
<-- A007 OK Store
<-- A008 1 Fetch (......)
...
<-- A008 16 Fetch (......)
<-- A008 17 Fetch (......)
<-- A008 OK Fetch
<-- A009 18 STORE (Flags (\
\Deleted))

Rice [Page 13]

RFC 1203 IMAP3 February 1991

<-- A009 OK Store
<-- A010 19 STORE (Flags (\
\Deleted))
<-- A010 OK Store
{Wait for command
<-- * EXISTS 23
<-- * RECENT 4
<-- * SEARCH (20 21 22 23) (RECENT
A011 FETCH 20:23 ALL RFC822.

The following terms are used in a meta-sense in the
specification below

An ASCII-STRING is a sequence of arbitrary ASCII characters

An ATOM is a sequence of ASCII characters delimited by SP or CRLF

A CHARACTER is any ASCII character except """", "{", CR, LF, "%",
or "\".

A CRLF is an ASCII carriage-return character followed
by an ASCII linefeed character

A NUMBER is a sequence of the ASCII characters which
decimal numerals ("0" through "9"), delimited by SP, CRLF, ",",
":".

A SP is the ASCII space character

A TEXT_LINE is a human-readable sequence of ASCII characters up
but not including a terminating CRLF

One of the most common fields in the IMAP3 protocol is a STRING
which may be an ATOM, QUOTED-STRING (a sequence of CHARACTERs
double-quotes), or a LITERAL. A literal consists of an open
("{"), a number, a close brace ("}"), a CRLF, and then an ASCII
STRING of n characters, where n is the value of the number inside
brace. In general, a string should be represented as an ATOM
QUOTED-STRING if at all possible. The semantics for QUOTED-STRING
LITERAL are checked before those for ATOM; therefore an ATOM used
a STRING may only contain CHARACTERs. Literals are most often
from the server to the client; in the rare case of a client to
literal there is a special consideration (see the "+ text"
below).

Another important field is the SEQUENCE, which identifies a set

Rice [Page 14]

RFC 1203 IMAP3 February 1991

messages by consecutive numbers from 1 to n where n is the number
messages in the mailbox. A sequence may consist of a single number
a pair of numbers delimited by colon indicating all numbers
those two numbers, or a list of single numbers and/or number pairs
For example, the sequence 2,4:7,9,12:15 is equivalent
2,4,5,6,7,9,12,13,14,15 and identifies all of those messages

Definitions of Commands and

Summary of Commands and

Commands
tag
tag LOGIN user
tag
tag SELECT
tag
tag
tag COPY sequence
tag FETCH sequence
tag STORE sequence data
tag SEARCH
tag BBOARD
tag FIND (BBOARDS / MAILBOXES)
tag
tag
tag SELECT.VERSION (major_version minor_version
tag SELECT.FEATURES
tag SUPPORTED.
tag
tag SET.

Responses (can be either solicited or unsolicited):
*/tag FLAGS flag_
*/tag SEARCH (numbers) (criteria
*/tag
*/tag
*/tag
*/tag STORE
*/tag FETCH
*/tag BBOARD bboard_
*/tag MAILBOX non_inbox_mailbox_
*/tag SUPPORTED.VERSIONS version_
*/tag
*/tag
*/tag OK
*/tag NO
*/tag BAD

Rice [Page 15]

RFC 1203 IMAP3 February 1991

*/tag BYE

Responses (can only be solicited):
tag COPY message_

Responses (can only be unsolicited):
+

tag

The NOOP command returns an OK to the client. By itself, it
nothing, but certain things may happen as side effects.
example, server implementations which implicitly check the
for new mail may do so as a result of this command. The
use of this command is to for the client to see if the server
still alive (and notify the server that the client is still alive
for those servers which have inactivity autologout timers).

tag LOGIN user

The LOGIN command identifies the user to the server and
the password authenticating this user. This information is
by the server to control access to the mailboxes

EXAMPLE: A001 LOGIN SMITH SESAME logs in as user SMITH
password SESAME

tag

The LOGOUT command indicates the client is done with the session
The server sends a solicited BYE response before the (tagged)
response, and then closes the connection

tag SELECT

The SELECT command selects a particular mailbox. The server
check that the user is permitted read access to this mailbox
Prior to returning an OK to the client, the server must send
solicited FLAGS and EXISTS response to the client giving
flags list for this mailbox (simply the system flags if
mailbox doesn't have any special flags) and the number of
in the mailbox. It is also recommended that the server send a RECENT unsolicited response to the client for the benefit
clients which make use of the number of new messages in a mailbox
It is further recommended that servers should send an
READONLY message if the mailbox that has been selected is

Rice [Page 16]

RFC 1203 IMAP3 February 1991

writable by the user

Multiple SELECT commands are permitted in a session, in which
the prior mailbox is deselected first

The default mailbox for the SELECT command is INBOX, which is
special name reserved to mean "the primary mailbox for this
on this server". The format of other mailbox names is
system dependent (as of this writing, it reflects the path of
mailbox on the current servers), though it could reflect
server-specific naming convention for the namespace of mailboxes
Such a namespace need not and should not be viewed as
equivalent or linked to the server machine's file system

EXAMPLES: A002 SELECT INBOX ;; selects the default mailbox
A002 197 EXISTS ;; server says 197 messages in
A002 5 RECENT ;; server says 5 are recent
A002 OK Select complete

A003 SELECT /usr/fred/my-mail.
;; select a different user specified mailbox
...

tag

The CHECK command forces a check for new messages and a rescan
the mailbox for internal change for those implementations
allow multiple simultaneous read/write access to the same
(e.g., TOPS-20). It is recommend that periodic implicit
for new mail be done by servers as well. The server must send
solicited EXISTS response prior to returning an OK to
client

tag

The EXPUNGE command permanently removes all messages with
\DELETED flag set in its flags from the mailbox. Prior
returning an OK to the client, for each message which is removed
a solicited EXPUNGE response is sent indicating which
was removed. The message number of each subsequent message in
mailbox is immediately decremented by 1; this means that if
last 5 messages in a 9-message mailbox are expunged you
receive 5 "5 EXPUNGE" responses for message 5. To ensure
integrity and server/client synchronization, it is
that the server do an implicit check prior to commencing
expunge and again when the expunge is completed. Furthermore,
the server allows multiple simultaneous access to the same
the server must guarantee both the integrity of the mailbox

Rice [Page 17]

RFC 1203 IMAP3 February 1991

the views of it held by the clients

EXPUNGE is not allowed if the user does not have write access
this mailbox. If a user does not have write access to the
then the server is required to signal this fact by replying with
NO response with a suitable text string that can be presented
the user explaining that the mailbox is read-only. It is
recommended that servers send an unsolicited READONLY message
clients that attempt an expunge operation on a read only mailbox

tag COPY sequence

The COPY command copies the specified message(s) to the
destination mailbox. If the destination mailbox does not exist
the server should create it. Prior to returning an OK to
client, the server must return a solicited COPY response
each message copied

EXAMPLE: A003 COPY 2:4 MEETING copies messages 2, 3, and 4
mailbox "MEETING".

COPY is not allowed if the user does not have write access to
destination mailbox. If a user does not have write access to
destination mailbox then the server is required to signal
fact by replying with a NO response with a suitable text
that can be presented to the user explaining that the mailbox
read-only. It is further recommended that servers send
unsolicited READONLY message to clients that attempt to copy to
read only mailbox. IMAP3 does not specify "where" the
will be put in the mailbox to which it has been copied

tag FETCH sequence fetch_

The FETCH command retrieves data associated with a message in
mailbox. The data items to be fetched may be either a single
or an S-expression list. The attributes that can be fetched
any of those mentioned specifically below along with any generic
canonical or concrete key. The set of predefined generic keys is
{BCC, BODY, CC, FROM, HEADER, SIZE, SUBJECT, TEXT, TO}. The
of predefined canonical keys is {$CC, $FROM, $SUBJECT, $TO}.
value returned by the server for a non-existent or non-
key is defined to be the null value, NIL

ALL Equivalent to
(FLAGS INTERNALDATE RFC822.SIZE ENVELOPE

ENVELOPE The envelope of the message. The envelope
computed by the server by parsing the header

Rice [Page 18]

RFC 1203 IMAP3 February 1991

i.e., the RFC 822 header for an RFC822
message, into the component parts,
various fields as necessary

FAST Macro equivalent to
(FLAGS INTERNALDATE RFC822.SIZE

FLAGS The flags which are set for this message
This may include the following system flags

\RECENT Message arrived
last read of this
\SEEN Message has been
\ANSWERED Message has been
\FLAGGED Message is "flagged"
urgent/special
\DELETED Message is "deleted"
removal by later

INTERNALDATE The date and time the message was written
the mailbox

RFC822 The message in RFC 822 format

RFC822.HEADER The RFC 822 format header of the message

RFC822.SIZE The number of characters in the message
expressed in RFC 822 format

RFC822.TEXT The text body of the message, omitting
RFC 822 header

EXAMPLES

A003 FETCH 2:4
fetches the flags, internal date, RFC 822 size, and
for messages 2, 3, and 4.

A004 FETCH 3 RFC822
fetches the RFC 822 representation for message 3.

A005 FETCH 4 (FLAGS RFC822.HEADER
fetches the flags and RFC 822 format header for message 4.

A006 FETCH 42 $
A006 FETCH $SUBJECT "Some subject text..."
A006 OK FETCH completed ok
fetches the canonical subject field

Rice [Page 19]

RFC 1203 IMAP3 February 1991

A007 FETCH 42 APPARENTLY-
A007 FETCH APPARENTLY-TO
A007 OK FETCH found no value
fetches the concrete apparently-to field

tag STORE sequence data

The STORE command alters the values associated with
keys for a message in the mailbox. As is the case for the
command, any generic, canonical or concrete key may be used
index the value provided. In addition to these, the
pre-defined keys are provided

FLAGS Replace the flags for the message with
argument (in flag list format).
The server must respond with a solicited STORE
message, showing the new state of the flags
the store

+FLAGS Add the flags in the argument to
message's flag list
The server must respond with a solicited STORE
message, showing the new state of the flags
the store

-FLAGS Remove the flags in the argument from
message's flag list
The server must respond with a solicited STORE
message, showing the new state of the flags
the store

RFC822.HEADER Replace the header of the message(s) with
specified. This allows users to use their
as databases with header fields as keys
The server must respond with
STORE RFC822.HEADER, STORE RFC822.SIZE
STORE ENVELOPE messages, showing the new
of the reparsed header after the store

RFC822.TEXT Replace the body of the messages with that specified
The server must respond with
STORE RFC822.TEXT and STORE RFC822.SIZE messages
showing the new state of the message after the store

STORE is not allowed if the user does not have write access
this mailbox

The server is required to send a solicited STORE response

Rice [Page 20]

RFC 1203 IMAP3 February 1991

each store operation that results in a format transformation
the server. For example, the server is required to send
STORE FLAGS response when the client performs a STORE +FLAGS
a STORE -FLAGS, since the client may not easily be able to
what the result of this command will be. Similarly, if
client emits a STORE FROM command then the server
respond with a suitable STORE FROM response because the
would be sending a string value to be stored and the
should transform this into a set of addresses. In general
however, although it is legal for the server to send
solicited STORE response for each STORE operation, this
discouraged, since it might result in the retransmission
very large and unnecessary amounts of data that have
stored

EXAMPLE: A003 STORE 2:4 +FLAGS (\DELETED) marks messages 2, 3,
and 4 for deletion

tag SEARCH search_

The SEARCH command searches the mailbox for messages which
the given set of criteria. The server response SEARCH (criteria
(numbers) gives the set of messages which match the conjunction
the criteria specified. In addition to each of the
criteria there is its logical inverse. The logical
criterion is denoted by the ~ (tilda) sign

Thus, no message that matches the criterion
FROM

will match the criterion
~FROM

The criteria for the search can be any generic, canonical
concrete key. In addition to these, the following pre-
keys are also provided

ALL All messages in the mailbox; the
initial criterion for ANDing

ANSWERED Messages with the \ANSWERED flag set

BCC string Messages which contain the specified
in the envelope's BCC field

BEFORE date Messages whose internal date is earlier
the specified date

Rice [Page 21]

RFC 1203 IMAP3 February 1991

BODY string Messages which contain the specified
in the body of the message

CC string Messages which contain the specified
in the envelope's CC field

DELETED Messages with the \DELETED flag set

FLAGGED Messages with the \FLAGGED flag set

FROM string Messages which contain the specified
in the envelope's FROM field

HEADER string Messages which contain the specified
in the message header

KEYWORD flag Messages with the specified flag set

NEW Messages which have the \RECENT flag set
not the \SEEN flag. This is
equivalent to "RECENT UNSEEN".

OLD Messages which do not have the \RECENT
set

ON date Messages whose internal date is the same
the specified date

RECENT Messages which have the \RECENT flag set

SEEN Messages which have the \SEEN flag set

SINCE date Messages whose internal date is later
the specified date

SUBJECT string Messages which contain the specified
in the envelope's SUBJECT field

TEXT string Messages which contain the specified string

TO string Messages which contain the specified string
the envelope's TO field

EXAMPLE: A003 SEARCH DELETED FROM "SMITH" SINCE 1-OCT-87
returns the message numbers for all deleted messages from
that were placed in the mailbox since October 1, 1987.

Implementation note: The UNANSWERED, UNDELETED, UNFLAGGED

Rice [Page 22]

RFC 1203 IMAP3 February 1991

UNKEYWORD and UNSEEN criteria, described below, are preserved
IMAP3 for IMAP2 compatibility. They are, however,
obsolete and new Client programs are encouraged to use the ~
notation for the logical inverses of search criteria with a
to the dropping of this outmoded syntax in later versions

UNANSWERED Messages which do not have the \ANSWERED
set

UNDELETED Messages which do not have the \DELETED
set

UNFLAGGED Messages which do not have the \FLAGGED
set

UNKEYWORD flag Messages which do not have the specified
set

UNSEEN Messages which do not have the \SEEN flag set

tag

The READONLY command indicates that the client wishes to make
mailbox read-only. The server is required to reply with
solicited READONLY or READWRITE response

tag

The READWRITE command indicates that the client wishes to make
mailbox read-write. The server is required to reply with
solicited READONLY or READWRITE response

tag SUPPORTED.

The SUPPORTED.VERSIONS solicits from the server
SUPPORTED.VERSIONS message, which encapsulates information
which versions and features the server supports

tag SELECT.VERSION (major_version minor_version

The SELECT.VERSION command indicates that the client wishes
select certain behavior on the part of the server. The major
minor versions indicate the specific version of the protocol
selected

EXAMPLE: A002 SELECT.VERSION (3 0)

A client may not request a server version that is not supported

Rice [Page 23]

RFC 1203 IMAP3 February 1991

the server, i.e., which is specifically mentioned in the
to a SUPPORTED.VERSIONS command. An attempt to do so by a
will result in a NO response from the server. It is an error
the SELECT.VERSION command to be used after a mailbox has
selected. The rationale for this is that for some
implementations it might be necessary to spawn separate
to implement widely divergent protocol versions. Thus, the
cannot be allowed to expect any server state to be preserved
the use of the SELECT.VERSION command. The default version of
servers is 2.0, i.e., IMAP2 as defined by RFC 1064.

tag SELECT.FEATURES 1#

The SELECT.FEATURES command indicates that the client wishes
select certain specific features on the part of the server.
client may not request a feature that is not supported by
server, i.e., one that is explicitly mentioned in the set
features for the selected version returned by
SUPPORTED.VERSIONS command. An attempt to do so by a client
result in a NO response from the server

EXAMPLE: A002 SELECT.FEATURES AUTO.SET.SEEN ~TAGGED.
EIGHT.BIT.

i.e., select the set of features called AUTO.SET.SEEN
EIGHT.BIT.TRANSPARENT and deselect the feature
TAGGED.SOLICITED. The use of the SELECT.FEATURES
completely resets the set of selected features. Note: These
only example feature names and are not necessarily supported
any server. See the appendix on features for more information
features. Note: Some features, when present in the server,
cause the upwards compatible extension of the grammar, i.e.,
adding extra commands. The server is at liberty not to
these upwards compatible extensions to the command tables when
feature is disabled. Thus, it is an error for a client to rely
getting a NO or BAD response in any way, for instance to
the selectedness or presence of a feature

tag BBOARD

The BBOARD command is equivalent to SELECT, except that
argument is a bulletin board (BBoard) name. The format of
BBoard name is implementation specific, although it is
encouraged to use something that resembles a name in a
sense and not a file or mailbox name on the particular system
There is no requirement that a BBoard name be a mailbox name or
file name (in particular, Unix netnews has a completely
namespace from mailbox or file names).

Rice [Page 24]

RFC 1203 IMAP3 February 1991

The result from the BBOARD command is identical from that of
SELECT command. For example, in the TOPS-20
implementation, the
A0002 BBOARD
is exactly equivalent to the
A0002 SELECT POBOX:FOO.
Note: the equivalence in this example is *not* required by
protocol, and merely reflects the fuzzy distinction
mailboxes and BBoards on TOPS-20.

tag FIND (BBOARDS / MAILBOXES)

The FIND command accepts as arguments the keywords BBOARDS
MAILBOXES and a pattern which specifies some set of BBoard/
names which are usable by the BBOARD/SELECT command. Two
characters are defined; "*" specifies that any number (
zero) characters may match at this position and "%" specifies
a single character may match at this position. For example
FOO*BAR will match FOOBAR, FOOD.ON.THE.BAR and FOO.BAR,
FOO%BAR will match only FOO.BAR; furthermore, "*" will match
BBoards/mailboxes. The following quoting convention applies
wildcards: "\*" is the literal "*" character, "\%" is the
"%" character and "\\" is the literal "\" character. Notes:
format of mailboxes is server implementation dependent.
special mailbox name INBOX is not included in the output to
FIND MAILBOXES command

The FIND command solicits any number of BBOARD or
responses from the server as appropriate

Examples
A0002 FIND BBOARDS *
A0002 BBOARD
A0002 BBOARD
A0002 OK FIND

A0002 FIND MAILBOXES FOO%BA
A0002 MAILBOX FOO.
A0002 MAILBOX FOO.
A0002 OK FIND

Note: Although the use of explicit file or path names
mailboxes is discouraged by this standard, it may be unavoidable
It is important that the value returned in the MAILBOX
reply be usable in the SELECT command without remembering any
specification which may have been used in the FIND
pattern

Rice [Page 25]

RFC 1203 IMAP3 February 1991

tag

The FLAGS command solicits a FLAGS response from the server

tag SET.FLAGS flag_

The SET.FLAGS command defines the user specifiable flags for
mailbox, i.e., the keywords. If this set does not include
formerly sent to the client by the server in a FLAGS message
this constitutes a request to delete the flag. Any new
should be created. This command does not affect the
defined flags and any system flags that are included in
flag_list will be ignored. The server must respond to
command with a solicited FLAGS message. If the deletion of a
results in the invalidation of the flag sets of any messages
the server is required to send solicited STORE FLAGS messages
the client for each modified message

Responses

*/tag OK

In its solicited form this response identifies
completion of the command with the indicated tag. The text is
line of human-readable text which may be useful in a
telemetry log for debugging purposes

In its unsolicited form, this response indicates simply that
server is alive. No special action on the part of the client
called for. This is presently only used by servers at startup
a greeting message indicating that they are ready to accept
first command. This usage, although legal, is by no
required. The text is a line of human-readable text which may
logged in protocol telemetry

*/tag NO

In its solicited form this response identifies
completion of the command with the indicated tag. The text is
line of human-readable text which probably should be displayed
the user in an error report by the client

In its unsolicited form this response indicates some
error at the server which cannot be traced to any
command. The text is a line of human-readable text which
be logged in protocol telemetry for the maintainer of the
and/or the client

Rice [Page 26]

RFC 1203 IMAP3 February 1991

*/tag BAD

In its solicited form response indicates faulty protocol
from the client and indicates a bug. The text is a line
human-readable text which should be recorded in any telemetry
part of a bug report to the maintainer of the client

In its unsolicited form response indicates some protocol error
the server which cannot be traced to any protocol command.
text is a line of human-readable text which should be logged
protocol telemetry for the maintainer of the server and/or
client. This generally indicates a protocol
problem, and examination of the protocol telemetry is advised
determine the cause of the problem

*/tag BYE

This indicates that the server is about to close the connection
The text is a line of human-readable text which should
displayed to the user in a status report by the client. IMAP
requires that the server emit a solicited BYE response as part
a normal logout sequence. This solicited form is not
under IMAP3, though is still legal for compatibility. In
unsolicited form the BYE response is used as a panic
announcement by the server. It is required to be used by
server which performs autologouts due to inactivity

*/tag number message_

The solicited (tag number message_data) response is generated
the result of a number of client requests. The server may
emit any the following at any time as unsolicited data (i.e., *
number message_data). The message_data is one of the following

EXISTS The specified number of messages exists in the mailbox

RECENT The specified number of messages have arrived since
last time this mailbox was selected with the
command or equivalent

EXPUNGE The specified message number has been
removed from the mailbox, and the next message in
mailbox (if any) becomes that message number
The server must send a solicited EXPUNGE
for each message that it expunges as the
of an EXPUNGE command. Note: future versions of
protocol may allow the use of a message
as a value returned by the EXPUNGE response to allow

Rice [Page 27]

RFC 1203 IMAP3 February 1991

more efficient compaction of client representations
mailboxes

STORE
Functionally equivalent to FETCH, only it is sent by
server when the state of a mailbox changes. The
must send solicited STORE responses as the result
any change caused by a STORE command

FETCH
This is the principle means by which data about
message is sent to the client. The data is in
Lisp-like S-expression property list form. Just as
FETCH request from the client can fetch any generic
canonical or concrete key, so also the FETCH
can return values for any of these keys as well as
the pre-defined attributes mentioned below. Note
the server is permitted to send any unsolicited
or STORE messages that it should choose, be they
values associated with generic, canonical or
keys. Clients are required to ignore any
FETCH responses that it cannot interpret. For example
clients are not required to be able to understand, i.e.,
use fruitfully, the canonical $TO key, but they
required to be able to ignore an unsolicited $TO
correctly

ENVELOPE An S-expression format list which describes
envelope of a message. The envelope is
by the server by parsing the RFC 822 header
the component parts, defaulting various
as necessary

The fields of the envelope are in the
order: date, subject, from, sender, reply-to, to
cc, bcc, in-reply-to, and message-id. The date
subject, in-reply-to, and message-id fields
strings. The from, sender, reply-to, to, cc
and bcc fields are lists of addresses

An address is an S-expression format list
describes an electronic mail address. The
of an address are in the following order
personal name, source-route (i.e.,
at-domain-list in SMTP), mailbox name, host
and comments. Implementation note: The
of the comment field is an incompatible
from IMAP2. The server is required not to

Rice [Page 28]

RFC 1203 IMAP3 February 1991

this field when running in IMAP2 mode

Any field of an envelope or address which
not applicable is presented as the atom NIL
Note that the server must default the reply-
and sender fields from the from field; a client
not expected to know to do this

FLAGS An S-expression format list of flags which are
for this message. This may include the
system flags

\RECENT Message arrived since
read of this
\SEEN Message has been
\ANSWERED Message has been
\FLAGGED Message is "flagged"
urgent/special
\DELETED Message is "deleted"
removal by later

INTERNALDATE A string containing the date and time
message was written to the mailbox

RFC822 A string expressing the message in RFC 822
format
Note: Some implementations of IMAP2
had the (undocumented) behavior of
the \SEEN flag as a side effect of
the body of a message. This resulted
erroneous behavior for clients that
messages that the user might not
around to reading. Thus, this behavior
explicitly disallowed in IMAP3.
Note: this is not a significant
restriction because it is always possible
IMAP3 clients to use an interaction with
server of the following type
A001 FETCH 42 RFC822
A002 STORE 42 +FLAGS (\SEEN
A001 42 FETCH RFC822 {637} ......
A001 OK Fetch
A002 42 STORE FLAGS (\SEEN \FLAGGED...)
A002 OK Store Completed

RFC822.HEADER A string expressing the RFC 822
header of the

Rice [Page 29]

RFC 1203 IMAP3 February 1991

RFC822.SIZE A number