As per Relevance of the word response, we have this rfc below:
Network Working Group M.
Request for Comments: 1176
Obsoletes: RFC 1064 August 1990
INTERACTIVE MAIL ACCESS PROTOCOL - VERSION 2
Status of this
This RFC suggests a method for personal computers and workstations
dynamically access mail from a mailbox server ("repository").
obosoletes RFC 1064. This RFC specifies an Experimental Protocol
the Internet community. Discussion and suggestions for
are requested. Please refer to the current edition of the "
Official Protocol Standards" for the standardization state and
of this protocol. Distribution of this memo is unlimited
The intent of the Interactive Mail Access Protocol, Version 2 (IMAP2)
is to allow a workstation, personal computer, or similar
machine to access electronic mail from a mailbox server. Since
distinction between personal computers and workstations is
over time, it is desirable to have a single solution that
the need in a general fashion. IMAP2 is the "glue" of a
electronic mail system consisting of a family of client and
implementations on a wide variety of platforms, from small single
tasking personal computing engines to complex multi-user
systems
Although different in many ways from the Post Office Protocols (POP
and POP3, hereafter referred to collectively as "POP") described
RFC 937 and RFC 1081, IMAP2 may be thought of as a
superset of these. RFC 937 was used as a model for this RFC.
was a cognizant reason for this; POP deals with a similar problem
albeit with a less comprehensive solution, and it was desirable
offer a basis for comparison
Like POP, IMAP2 specifies a means of accessing stored mail and not
posting mail; this function is handled by a mail transfer
such as SMTP (RFC 821).
This protocol assumes a reliable data stream such as provided by
or any similar protocol. When TCP is used, the IMAP2 server
on port 143.
Crispin [Page 1]
RFC 1176 IMAP2 August 1990
System Model and
Electronic mail is a primary means of communication for the
spread Internet community. The advent of distributed
computers and workstations has forced a significant rethinking of
mechanisms employed to manage electronic mail. With mainframes,
user tends to receive and process mail at the computer he uses
of the time, his "primary host". The first inclination of many
when an independent workstation is placed in front of them is
begin receiving mail at the workstation, and many vendors
implemented facilities to do this. However, this approach
several disadvantages
(1) Personal computers and many workstations have a
design that gives full control of all aspects of the system to
user at the console. As a result, background tasks such
receiving mail may not run for long periods of time;
because the user is asking to use all the machine's resources,
because the user has (perhaps accidentally) manipulated
environment in such a way that it prevents mail reception.
many personal computers, the operating system is single-
and this is the only mode of operation. Any of these
could lead to repeated failed delivery attempts by outside agents
(2) The hardware failure of a single machine can keep its
"off the air" for a considerable time, since repair of
units may be delayed. Given the growing number of
computers and workstations spread throughout office environments
quick repair of such systems is not assured. On the other hand,
central mainframe is generally repaired soon after failure
(3) Personal computers and workstations are often not backed
with as much diligence as a central mainframe, if at all
(4) It is more difficult to keep track of mailing addresses
each person is associated with a distinct machine. Consider
difficulty in keeping track of many postal addresses or
numbers, particularly if there was no single address or
number for an organization through which you could reach
person in that organization. Traditionally, electronic mail
the ARPANET involved 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 less
today unless the concept of a host is changed to refer to
organizational entity and not a particular machine
(5) It is difficult to keep a multitude of heterogeneous
Crispin [Page 2]
RFC 1176 IMAP2 August 1990
working properly with complex mailing protocols, making
difficult to move forward as progress is made in
communication and as new standards emerge. Each system has
worry about receiving incoming mail, routing and
outgoing mail, formatting, storing, and providing for
stability of mailboxes over a variety of possible filing
mailing protocols
Consequently, while a personal computer or workstation may be
as an Internet host in the sense that it implements TCP/IP, it
not be viewed as the entity that contains the user's mailbox
Instead, a mail server machine ("server", sometimes called
"repository") should hold the mailbox, and the personal computer
workstation (hereafter referred to as a "client") should access
mailbox via mail transactions
Because the mail server machine is isolated from direct
manipulation, it should achieve high software reliability easily
and, as a shared resource, it should also achieve high
reliability, perhaps through redundancy. The mail server may
accessed from arbitrary locations, allowing users to read mail
campus, town, or country using commonly available clients
Furthermore, the same user may access his mailbox from
clients at different times, and multiple users may access the
mailbox simultaneously
The mail server acts an an interface among users, data storage,
other mailers. A mail access protocol retrieves messages,
and changes properties of messages, and otherwise manages mailboxes
This differs from some approaches (e.g., Unix mail via NFS) in
the mail access protocol is used for all message manipulations
isolating the user and the client from all knowledge of how the
storage is used. This means that the mail server can use the
storage in whatever way is most efficient to organize the mail
that particular environment, without having to worry about
representation compatibility across different machines
A mail access protocol further differs in that it
information only on demand. A well-designed mail access
requires considerably less network traffic than Unix mail via NFS
particularly when the mail file is large. The result is that a
access protocol can scale well to situations of large mailboxes
networks with high latency or low speed
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 is desirable to allow for
Crispin [Page 3]
RFC 1176 IMAP2 August 1990
growth path beyond the hoary text-only RFC 822 protocol,
in the area of attachments and multi-media mail, to ease the
transition to ISO solutions
Unlike POP, IMAP2 has extensive features for remote searching
parsing of messages on the server. A free text search (
with other searching) can be made in the entire mailbox by the
and the results made available to the client without the
having to transfer the entire mailbox and searching itself.
remote parsing of a message into a structured (and standard format
"envelope" is available, a client can display envelope
and implement commands such as REPLY without having any
of how to parse RFC 822, etc. headers. The effect of this
twofold: it further improves the ability to scale well in
where network traffic must be reduced, and it reduces the
of the client program
Additionally, IMAP2 offers several facilities for managing
message state and the mailbox as a whole beyond the simple "
message" functionality of POP. Another benefit of IMAP2 is the
of tagged responses to reduce the possibility of
errors and the concept of state on the client (a "local cache")
the server may update without explicit request by the client.
concepts and how they are used are explained under "
Discussion" below
In spite of this functional richness, IMAP2 is a small protocol
Although servers should implement the full set of IMAP2 functions,
simple client can be written that uses IMAP2 in much the way as a
client
A related protocol to POP and IMAP2 is the DMSP protocol of
(RFC 1056). IMAP2 differs from DMSP more fundamentally, reflecting
differing architecture from PCMAIL. PCMAIL is either an
("interactive mode"), or offline ("batch mode") system with long-
shared state. Some POP based systems are also offline; in
systems, since there is no long-term shared state POP is little
than a download mechanism of the "mail file" to the client. IMAP2-
based software is primarily an online system in which real-time
simultaneous mail access were considered 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 that 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
Crispin [Page 4]
RFC 1176 IMAP2 August 1990
state from the server
In IMAP2-based software, the client/server relationship lasts
for the duration of the TCP connection. All mailbox state
maintained on the server. There is no registration of clients.
function of a descriptor is handled by a structured representation
the message "envelope" as noted above. There is no client/
synchronization since the client does not remember state
IMAP2 connections. This is not a problem since in general the
never needs the entire state of the mailbox in a single session
therefore there isn't much overhead in fetching the state
that is needed as it is needed
There are also some functional differences between IMAP2 and DMSP
DMSP has functions for sending messages, printing messages,
mailboxes, and changing passwords; these are done outside IMAP2.
DMSP has 16 binary flags of which 8 are defined by the system. IMAP
has flag names; there are currently 5 defined system flag names and
facility for some number (30 in the current implementations) of
flag names. IMAP2 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 small set of "interesting" messages, which were
new mail or mail based on some user-selected criteria. Consequently
IMAP2 was designed to easily identify those "interesting" messages
that the client could fetch the state of those messages and not
that were not "interesting".
The
The IMAP2 protocol consists of a sequence of client commands
server responses, with server data interspersed between
responses. Unlike most Internet protocols, commands and
are tagged. That is, a command begins with a unique
(typically a short alphanumeric sequence such as a Lisp "gensym
function would generate e.g., A0001, A0002, etc.), called a tag.
response to this command is given the same tag from the server
Additionally, the server may send an arbitrary amount of "
data", which is identified by the special reserved tag of "*".
Crispin [Page 5]
RFC 1176 IMAP2 August 1990
is another special reserved tag, "+", discussed below
The server must be listening for a connection. When a connection
opened the server sends an unsolicited OK response as a
message and then waits for commands
The client opens a connection and waits for the greeting. The
must not send any commands until it has received the greeting
the server
Once the greeting has been received, the client may begin
commands and is not under any obligation to wait for a
response to this command before sending another command, within
constraints of TCP flow control. When commands are received
server acts on them and responds with command responses,
interspersed with data. The effect of a command can not
considered complete until a command response with a tag matching
command is received from the server
Although all known IMAP2 servers at the time of this writing
commands to completion before processing the next command, it is
required that a server do so. However, many commands can affect
results of other commands, creating processing-order
(or, for SEARCH and FIND, ambiguities about which data is
with which command). All implementations that operate in a non
lockstep fashion must recognize such dependencies and defer
synchronize execution as necessary. In general, such multi
processing is limited to consecutive FETCH commands
Generally, the first command from the client is a LOGIN command
user name and password arguments to establish identity and
authorization, unless this has already been accomplished
other means, e.g. Kerberos. Until identity and access
have been established, no operations other than LOGIN or LOGOUT
permitted
Once identity and authorization have been established, the
must send a SELECT command to access the desired mailbox; no
is selected by default. SELECT's argument is implementation
dependent; however the word "INBOX" must be implemented to mean
primary or default mailbox for this user, independent of any
server semantics. On a successful SELECT, the server will send
list of valid flags, number of messages, and number of
arrived since last access for this mailbox as unsolicited data
followed by an OK response. The client may terminate access to
mailbox and access a different one with another SELECT command
The client reads mailbox information with FETCH commands. The
Crispin [Page 6]
RFC 1176 IMAP2 August 1990
data is transmitted via the unsolicited data mechanism (that is
FETCH should be viewed as instructing the server to include
desired data along with any other data it wishes to transmit to
client). There are three major categories of data that may
fetched
The first category is data that is associated with a message as
entity in the mailbox. There are now three such items of data:
"internal date", the "RFC 822 size", and the "flags". The
date is the date and time that the message was placed in the mailbox
The RFC 822 size is subject to deletion in the future; it is the
in bytes of the message, expressed as an RFC 822 text string
Current clients only use it as part of a status display line.
flags are a list of status flags associated with the message (
below). All the first category data can be fetched by using
macro-fetch word "FAST"; that is, "FAST" expands to "(
INTERNALDATE RFC822.SIZE)".
The second category is that data that describes the composition
delivery information of a message; that is, information such as
message sender, recipient lists, message-ID, subject, etc. This
the information that 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.] IMAP2 defines
structured and unambiguous representation for the envelope that
particularly suited 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
categories of 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 that is intended for direct
viewing. The present RFC 822 based IMAP2 defines three such items
RFC822.HEADER, RFC822.TEXT, and RFC822 (the latter being the
former appended together in a single text string). RFC822.HEADER
the "raw", unprocessed RFC 822 format header of the message
Fetching "RFC822" is equivalent to fetching the RFC 822
representation of the message as stored on the mailbox without
filtering or processing
An intelligent client will "FETCH ALL" for some (or all) of
messages in the mailbox for use as a presentation menu, and when
user wishes to read a particular message will "FETCH RFC822.TEXT"
get the message body. A more primitive client could, of course
simply "FETCH RFC822" a`la POP-type functionality
Crispin [Page 7]
RFC 1176 IMAP2 August 1990
The client can alter certain data (currently only the flags) by
STORE command. As an example, a message is deleted from a mailbox
a STORE command that includes the \DELETED flag as a flag 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 that match certain criteria (SEARCH command).
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 IMAP2 Server
{Wait for command
A001 LOGIN Fred Secret -->
<-- A001 OK User Fred logged
{Wait for command
A002 SELECT INBOX -->
<-- * FLAGS (Meeting Notice \
\Flagged \Deleted \Seen
<-- * 19
<-- * 2
<-- A0002 OK Select
{Wait for command
A003 FETCH 1:19 ALL -->
<-- * 1 Fetch (......)
...
<-- * 18 Fetch (......)
<-- * 19 Fetch (......)
<-- A003 OK Fetch
{Wait for command
A004 FETCH 8 RFC822.TEXT -->
<-- * 8 Fetch (RFC822.TEXT {893}
...893 characters of text...
<-- )
<-- A004 OK Fetch
{Wait for command
Crispin [Page 8]
RFC 1176 IMAP2 August 1990
A005 STORE 8 +Flags \Deleted -->
<-- * 8 Store (Flags (\
\Seen))
<-- A005 OK Store
{Wait for command
A006 EXPUNGE -->
<-- * 19
<-- * 8
<-- * 18
<-- A006 Expunge
{Wait for command
A007 LOGOUT -->
<-- * BYE IMAP2 server
<-- A007 OK Logout
{Close Connection} --><-- {Close connection
{Go back to start
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 that
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
A common field in the IMAP2 protocol is a STRING, which may be
ATOM, QUOTED-STRING (a sequence of CHARACTERs inside double-quotes),
or a LITERAL. A literal consists of an open brace ("{"), a number,
close brace ("}"), a CRLF, and then an ASCII-STRING of n characters
where n is the value of the number inside the brace. In general,
string should be represented as an ATOM or QUOTED-STRING if at
possible. The semantics for QUOTED-STRING or LITERAL are
before those for ATOM; therefore an ATOM used in a STRING may
Crispin [Page 9]
RFC 1176 IMAP2 August 1990
contain CHARACTERs. Literals are most often sent from the server
the client; in the rare case of a client to server literal there is
special consideration (see the "+ text" response below).
Another important field is the SEQUENCE, which identifies a set
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 (equivalent to all
between those two numbers), or a list of single numbers or
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 those messages
Definitions of Commands and
Summary of Commands and
Commands ||
-------- || -------
tag NOOP || tag OK
tag LOGIN user password || tag NO
tag LOGOUT || tag BAD
tag SELECT mailbox || * number message_
tag BBOARD bulletin_board || * FLAGS flag_
tag FIND MAILBOXES pattern || * SEARCH
tag FIND BBOARDS pattern || * BBOARD
tag CHECK || * MAILBOX
tag EXPUNGE || * BYE
tag COPY sequence mailbox || * OK
tag FETCH sequence data || * NO
tag STORE sequence data value || * BAD
tag SEARCH search_program || +
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 that 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 that 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
Crispin [Page 10]
RFC 1176 IMAP2 August 1990
by the server to control access to the mailboxes
EXAMPLE: A001 LOGIN SMITH
logs in as user SMITH with password SESAME
tag
The LOGOUT command informs the server that the client is done
the session. The server should send an unsolicited BYE
before the (tagged) OK response, and then close the
connection
tag SELECT
The SELECT command selects a particular mailbox. The server
check that the user is permitted read access to this mailbox
Before returning an OK to the client, the server must send
following unsolicited data to the client
FLAGS mailbox's defined
EXISTS the number of messages in the
RECENT the number of new messages in the
in order to define the initial state of the mailbox at the client
Multiple SELECT commands are permitted in a session, in which
the previous mailbox is automatically deselected when a new
is made
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 the mailbox file on the current servers).
It is customary, although not required, for the text of an
response to the SELECT command to begin with either "[READ-ONLY]"
or "[READ-WRITE]" to show the mailbox's access status
EXAMPLE: A002 SELECT
selects the default mailbox
tag BBOARD bulletin_
The BBOARD command is equivalent to SELECT, and returns the
output. However, it differs from SELECT in that its argument is
shared mailbox (bulletin board) name instead of an
mailbox. The format of a bulletin name is
specific, although it is strongly encouraged to use something
resembles a name in a generic sense and not a file or mailbox
Crispin [Page 11]
RFC 1176 IMAP2 August 1990
on the particular system. There is no requirement that a
board name be a mailbox name or a file name (in particular,
netnews has a completely different namespace from mailbox or
names).
Support for BBOARD is optional
tag FIND MAILBOXES
The FIND MAILBOXES command accepts as an argument a
(including wildcards) that specifies some set of mailbox
that are usable by the SELECT command. The format of mailboxes
implementation dependent. The special mailbox name INBOX is
included in the output
Two wildcard characters are defined; "*" specifies any
(including zero) characters may match at this position and "%"
specifies a single character may match at this position.
example, FOO*BAR will match FOOBAR, FOOD.ON.THE.BAR and FOO.BAR
whereas FOO%BAR will match only FOO.BAR. "*" will match
mailboxes
The FIND MAILBOXES command will return some set of
MAILBOX replies that have as their value a single mailbox name
EXAMPLE: A002 FIND MAILBOXES *
* MAILBOX
* MAILBOX
A002 FIND
Although the use of explicit file or path names for mailboxes
discouraged by this standard, it may be unavoidable. It
important that the value returned in the MAILBOX unsolicited
be usable in the SELECT command without remembering any
specification that may have been used in the FIND
pattern
Support for FIND MAILBOXES is optional. If a client's
returns BAD as a response then the client can make no
about what mailboxes exist on the server other than INBOX
tag FIND BBOARDS
The FIND BBOARDS command accepts as an argument a pattern
specifies some set of bulletin board names that are usable by
BBOARD command. Wildcards are permitted as in FIND MAILBOXES
The FIND BBOARDS command will return some set of
Crispin [Page 12]
RFC 1176 IMAP2 August 1990
BBOARD replies that have as their value a single bulletin
name
EXAMPLE: A002 FIND BBOARDS *
* BBOARD
* BBOARD
A002 FIND
Support for FIND BBOARDS is optional. If a client's
returns BAD as a response then the client can make no
about what bulletin boards exist on the server, or that they
at all
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 mailbox
It is recommend that periodic implicit checks for new mail be
by servers as well. The server should send unsolicited EXISTS
RECENT responses with the current status before returning an OK
the client
tag
The EXPUNGE command permanently removes all messages with
\DELETED flag set in its flags from the mailbox. Before
an OK to the client, for each message that is removed,
unsolicited EXPUNGE response is sent. The message number for
successive message in the mailbox is immediately decremented by 1;
this means that if the last 5 messages in a 9-message mail
are expunged you will receive 5 unsolicited EXPUNGE responses
message 5. To ensure mailbox integrity and server/
synchronization, it is recommended that the server do an
check before commencing the expunge and again when the expunge
completed. Furthermore, if the server allows
simultaneous access to the same mail file the server must lock
mail file for exclusive access while an expunge is taking place
EXPUNGE is not allowed if the user does not have write access
this 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. Before returning an OK to
client, the server should return an unsolicited COPY
Crispin [Page 13]
RFC 1176 IMAP2 August 1990
for each message copied. A copy should set the \SEEN flag for
messages that were successfully copied (provided, of course,
the user has write access to this mailbox).
EXAMPLE: A003 COPY 2:4
copies messages 2, 3, and 4 to mailbox "MEETING".
COPY is not allowed if the user does not have write access to
destination mailbox
tag FETCH sequence
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 currently defined data items
can be fetched are
ALL Macro equivalent to
(FLAGS INTERNALDATE RFC822.SIZE ENVELOPE
ENVELOPE The envelope of the message. The envelope
computed by the server by parsing the RFC 822
header into the component parts,
various fields as necessary
FAST Macro equivalent to
(FLAGS INTERNALDATE RFC822.SIZE
FLAGS The flags that are set for this message
This may include the following system flags
\RECENT Message arrived since
previous time this
was
\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
Crispin [Page 14]
RFC 1176 IMAP2 August 1990
RFC822 The message in RFC 822 format. The \
flag is implicitly set; if this causes
flags to change they should be included
part of the fetch results. This is
concatenation of RFC822.HEADER and RFC822.TEXT
RFC822.HEADER The "raw" RFC 822 format header of the
as stored on the server
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. The \SEEN flag is
set as with RFC822 above
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.
Note: An attempt to FETCH already-transmitted data may have
result. See the Implementation Discussion below
tag STORE sequence data
The STORE command alters data associated with a message in
mailbox. The currently defined data items that can be stored are
FLAGS Replace the flags for the message with
argument (in flag list format).
+FLAGS Add the flags in the argument to
message's flag list
-FLAGS Remove the flags in the argument from
message's flag list
STORE is not allowed if the user does not have write access
this mailbox
Crispin [Page 15]
RFC 1176 IMAP2 August 1990
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 that
the given set of criteria. The unsolicited SEARCH <1#number
response from the server is a list of messages that express
intersection (AND function) of all the messages which match
criteria. For example
A003 SEARCH DELETED FROM "SMITH" SINCE 1-OCT-87
returns the message numbers for all deleted messages from
that were placed in the mail file since October 1, 1987.
In all search criteria which use strings, a message matches
criteria if the string is a case-independent substring of
field. The currently defined criteria are
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
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
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".
Crispin [Page 16]
RFC 1176 IMAP2 August 1990
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
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
Crispin [Page 17]
RFC 1176 IMAP2 August 1990
tag OK
This response identifies successful completion of the command
that tag. The text is a line of human-readable text that may
useful in a protocol telemetry log for debugging purposes
tag NO
This response identifies unsuccessful completion of the
with that tag. The text is a line of human-readable text
probably should be displayed to the user in an error report by
client
tag BAD
This response identifies faulty protocol received from the client
The text is a line of human-readable text that should be
in any telemetry as part of a bug report to the maintainer of
client
* number message_
This response occurs as a result of several different commands
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
previous time this mailbox was read
EXPUNGE The specified message number has been
removed from the mailbox, and the next message in
mailbox (if any) becomes that message number
STORE
Obsolete and functionally equivalent to FETCH
FETCH
This is the principle means by which data about
message is returned to the client. The data is in
Lisp-like S-expression property list form. The
properties are
ENVELOPE An S-expression format list that describes
envelope of a message. The envelope is
by the server by parsing the RFC 822 header
Crispin [Page 18]
RFC 1176 IMAP2 August 1990
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 (a.k.a.
at-domain-list in SMTP), mailbox name,
host name
Any field of an envelope or address that
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 that are
for this message. This may include the
system flags
\RECENT Message arrived since
previous time this
was
\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
RFC822.HEADER A string expressing the RFC 822
header of the
RFC822.SIZE A number indicating the number
characters in the message as
Crispin [Page 19]
RFC 1176 IMAP2 August 1990
in RFC 822 format
RFC822.TEXT A string expressing the text body of
message, omitting the RFC 822 header
* FLAGS flag_
This response occurs as a result of a SELECT command. The
list are the list of flags (at a minimum, the system-
flags) that are applicable for this mailbox. Flags other than
system flags are a function of the server implementation
* SEARCH number(s
This response occurs as a result of a SEARCH command.
number(s) refer to those messages that match the search criteria
Each number is delimited by a space, e.g., "SEARCH 2 3 6".
* BBOARD
This response occurs as a result of a FIND BBOARDS command.
string is a bulletin board name that matches the pattern in
command
* MAILBOX
This response occurs as a result of a FIND MAILBOXES command.
string is a mailbox name that matches the pattern in the command
* BYE
This response identifies that the server is about to close
connection. The text is a line of human-readable text that
be displayed to the user in a status report by the client.
may be sent as part of a normal logout sequence, or as a
shutdown announcement by the server. It is also used by
servers as an announcement of an inactivity autologout
* OK
This response identifies normal operation on the server.
special action by the client is called for, however, the
should be displayed to the user in some fashion. This
currently only used by servers at startup as a greeting message
show they are ready to accept the first command
Crispin [Page 20]
RFC 1176 IMAP2 August 1990
* NO
This response identifies a warning from the server that does
affect the overall results of any particular request. The text
a line of human-readable text that should be presented to the
as a warning of improper operation
* BAD
This response identifies a serious error at the server; it
also indicate faulty protocol from the client in which a tag
not be parsed. The text is a line of human-readable text
should be presented to the user as a serious or possibly
error. It should also be recorded in any telemetry as part of
bug report to the maintainer of the client and server
+
This response identifies that the server is ready to accept
text of a literal from the client. Normally, a command from
client is a single text line. If the server detects an error
the command, it can simply discard the remainder of the line.
cannot do this for commands that contain literals, since a
can be an arbitrarily long amount of text, and the server may
even be expecting a literal. This mechanism is provided so
client knows not to send a literal until the server expects it
preserving client/server synchronization
In practice, this condition is rarely encountered. In the
protocol, the only client command likely to contain a literal
the LOGIN command. Consider a server that validates the
before checking the password. If the password contains "funny
characters and hence is sent as a literal, then if the user
invalid an error would occur before the password is parsed
No such synchronization protection is provided for literals
from the server to the client, for performance reasons.
synchronization problems in this direction would be caused by
bug in the client or server
Crispin [Page 21]
RFC 1176 IMAP2 August 1990
Sample IMAP2
The following is a transcript of an IMAP2 session. Server output
identified by "S:" and client output by "U:". In cases where
are too long to fit within the boundaries of this document, the
is continued on the next line
S: * OK SUMEX-AIM.Stanford.EDU Interim Mail Access Protocol II
6.1(349) at Thu, 9 Jun 88 14:58:30
U: a001 login crispin
S: a002 OK User CRISPIN logged in at Thu, 9 Jun 88 14:58:42 PDT, job 76
U: a002 select
S: * FLAGS (Bugs SF Party Skating Meeting Flames Request AI
Note \XXXX \YYYY \Answered \Flagged \Deleted \Seen
S: * 16
S: * 0
S: a002 OK Select
U: a003 fetch 16
S: * 16 Fetch (Flags (\Seen) InternalDate " 9-Jun-88 12:55:44 PDT
RFC822.Size 637 Envelope ("Sat, 4 Jun 88 13:27:11 PDT
"INFO-MAC Mail Message" (("Larry Fagan" NIL "FAGAN
"SUMEX-AIM.Stanford.EDU")) (("Larry Fagan" NIL "FAGAN
"SUMEX-AIM.Stanford.EDU")) (("Larry Fagan" NIL "FAGAN
"SUMEX-AIM.Stanford.EDU")) ((NIL NIL "rindflEISCH
"SUMEX-AIM.Stanford.EDU")) NIL NIL
"<12403828905.13.FAGAN@SUMEX-AIM.Stanford.EDU>"))
S: a003 OK Fetch
U: a004 fetch 16 rfc822
S: * 16 Fetch (RFC822 {637}
S: Mail-From: RINDFLEISCH created at 9-Jun-88 12:55:43
S: Mail-From: FAGAN created at 4-Jun-88 13:27:12
S: Date: Sat, 4 Jun 88 13:27:11
S: From: Larry Fagan Stanford.EDU
S: To: rindflEISCH@SUMEX-AIM.Stanford.
S: Subject: INFO-MAC Mail
S: Message-ID: <12403828905.13.FAGAN@SUMEX-AIM.Stanford.EDU
S: ReSent-Date: Thu, 9 Jun 88 12:55:43
S: ReSent-From: TC Rindfleisch Stanford.EDU
S: ReSent-To: Yeager@SUMEX-AIM.Stanford.EDU
Crispin@SUMEX-AIM.Stanford.
S: ReSent-Message-ID
<12405133897.80.RINDFLEISCH@SUMEX-AIM.Stanford.EDU
S
S: The file is usenetv4-55.arc ...
S:
S: -------
S: )
S: a004 OK Fetch
Crispin [Page 22]
RFC 1176 IMAP2 August 1990
U: a005
S: * BYE DEC-20 IMAP II server terminating
S: a005 OK SUMEX-AIM.Stanford.EDU Interim Mail Access
Service
Crispin [Page 23]
RFC 1176 IMAP2 August 1990
Implementation
There are several advantages to the scheme of tags and
responses. First, the infamous synchronization problems of SMTP
similar protocols do not happen with tagged commands; a command
not considered satisfied until a response with the same tag is seen
Tagging allows an arbitrary amount of other responses ("unsolicited
data) to be sent by the server with no possibility of the
losing synchronization. Compare this with the problems that FTP
SMTP clients have with continuation, partial completion,
commentary reply codes
Another advantage is that a non-lockstep client implementation
possible. The client could send a command, and entrust the
of the server responses to a different process that would signal
client when the tagged response comes in. Under
circumstances, the client may have more than one command outstanding
It was observed that synchronization problems can occur with
if the literal is not recognized as such. Fortunately, the cases
which this can happen are rare; a mechanism (the special "+"
response) was introduced to handle those few cases. The proper
to address this problem is probably to move towards a record-
architecture instead of the text stream model provided by TCP
An IMAP2 client must maintain a local cache of data from the mailbox
This cache is an incomplete model of the mailbox, and at startup
empty. A listener processes all unsolicited data, and updates
cache based on this data. If a tagged response arrives, the
unblocks the process that sent the tagged request
Unsolicited data needs some discussion. Unlike most protocols,
which the server merely does the client's bidding, an IMAP2
has a semi-autonomous role. By sending "unsolicited data",
server is in effect sending a command to the client -- to update
extend the client's cache with new information from the server.
other words, a "fetch" command is merely a request to the server
ensure that the client's cache has the most up-to-date version of
requested information. A server acknowledgement to the "fetch" is
statement that all the requested data has been sent
Although no current server does this, a server is not obliged by
protocol to send data that it has already sent and is unchanged.
exception to this is the actual message text fetching
(RFC822, RFC822.HEADER, and RFC822.TEXT), owing to the
excessive resource consumption of maintaining this data in a cache
It can not be assumed that a FETCH will transmit any data; only
an OK to the FETCH means that the client's cache has the most up-to
Crispin [Page 24]
RFC 1176 IMAP2 August 1990
date information
When a mailbox is selected, the initial unsolicited data from
server arrives. The first piece of data is the number of messages
By sending a new EXISTS unsolicited data message the server
the client to resize its cache (this is how newly arrived mail
handled). If the client attempts to access information from
cache, it will encounter empty spots that will trigger "fetch
requests. The request would be sent, some unsolicited data
the answer to the fetch will flow back, and then the "fetch"
will unblock the client
People familiar with demand-paged virtual memory operating
design will recognize this model as being similar to page-
handling on a demand-paged system
Crispin [Page 25]
RFC 1176 IMAP2 August 1990
Formal
The following syntax specification uses the augmented Backus-
Form (BNF) notation as specified in RFC 822 with one exception;
delimiter used with the "#" construct is a single space (SP) and
a comma
address ::= "(" addr_name SP addr_adl SP addr_mailbox
addr_host ")"
addr_adl ::= nil /
addr_host ::= nil /
addr_mailbox ::= nil /
addr_name ::= nil /
bboard ::= "BBOARD" SP
check ::= "CHECK
copy ::= "COPY" SP sequence SP
data ::= ("FLAGS" SP flag_list / "SEARCH" SP 1#number /
"BYE" SP text_line / "OK" SP text_line /
"NO" SP text_line / "BAD" SP text_line
date ::= string in form "dd-mmm-yy hh:mm:ss-zzz
envelope ::= "(" env_date SP env_subject SP env_from
env_sender SP env_reply-to SP env_to
env_cc SP env_bcc SP env_in-reply-to
env_message-id ")"
env_bcc ::= nil / "(" 1*address ")"
env_cc ::= nil / "(" 1*address ")"
env_date ::=
env_from ::= nil / "(" 1*address ")"
env_in-reply-to ::= nil /
env_message-id ::= nil /
env_reply-to ::= nil / "(" 1*address ")"
Crispin [Page 26]
RFC 1176 IMAP2 August 1990
env_sender ::= nil / "(" 1*address ")"
env_subject ::= nil /
env_to ::= nil / "(" 1*address ")"
expunge ::= "EXPUNGE
fetch ::= "FETCH" SP sequence SP ("ALL" / "FAST" /
fetch_att / "(" 1#fetch_att ")")
fetch_att ::= "ENVELOPE" / "FLAGS" / "INTERNALDATE" /
"RFC822" / "RFC822.HEADER" / "RFC822.SIZE" /
"RFC822.TEXT
find ::= "FIND" SP find_option SP
find_option ::= "MAILBOXES" / "BBOARDS
flag_list ::= ATOM / "(" 1#ATOM ")"
literal ::= "{" NUMBER "}" CRLF ASCII-
login ::= "LOGIN" SP userid SP
logout ::= "LOGOUT
mailbox ::= "INBOX" /
msg_copy ::= "COPY
msg_data ::= (msg_exists / msg_recent / msg_expunge /
msg_fetch / msg_copy
msg_exists ::= "EXISTS
msg_expunge ::= "EXPUNGE
msg_fetch ::= ("FETCH" / "STORE") SP "(" 1#("ENVELOPE"
envelope / "FLAGS" SP "(" 1#(recent_
flag_list) ")" / "INTERNALDATE" SP date /
"RFC822" SP string / "RFC822.HEADER" SP string /
"RFC822.SIZE" SP NUMBER / "RFC822.TEXT"
string) ")"
msg_recent ::= "RECENT
msg_num ::=
Crispin [Page 27]
RFC 1176 IMAP2 August 1990
nil ::= "NIL
noop ::= "NOOP
password ::=
recent_flag ::= "\RECENT
ready ::= "+" SP text_
request ::= tag SP (noop / login / logout / select / check /
expunge / copy / fetch / store / search / find /
bboard)
response ::= tag SP ("OK" / "NO" / "BAD") SP text_line
search ::= "SEARCH" SP 1#("ALL" / "ANSWERED" /
"BCC" SP string / "BEFORE" SP string /
"BODY" SP string / "CC" SP string / "DELETED" /
"FLAGGED" / "KEYWORD" SP atom / "NEW" / "OLD" /
"ON" SP string / "RECENT" / "SEEN" /
"SINCE" SP string / "TEXT" SP string /
"TO" SP string / "UNANSWERED" / "UNDELETED" /
"UNFLAGGED" / "UNKEYWORD" / "UNSEEN")
select ::= "SELECT" SP
sequence ::= NUMBER / (NUMBER "," sequence) / (NUMBER ":"
sequence
store ::= "STORE" SP sequence SP store_
store_att ::= ("+FLAGS" SP flag_list / "-FLAGS" SP flag_list /
"FLAGS" SP flag_list
string ::= atom / """" 1*character """" /
system_flags ::= "\ANSWERED" SP "\FLAGGED" SP "\DELETED"
"\SEEN
tag ::=
unsolicited ::= "*" SP (msg_num SP msg_data / data)
userid ::=
Crispin [Page 28]
RFC 1176 IMAP2 August 1990
Implementation
This information is current as of this writing
The University of Washington has developed an electronic mail
library called the "C-Client". It provides complete IMAP2, SMTP,
local mailbox (both /usr/spool/mail and mail.txt formats) services
a well-defined way to a user interface main program. Using the C
Client, the University of Washington has created an
client for BSD Unix and two operational clients (one basic,
advanced) for the NeXT
Stanford University/SUMEX has developed operational IMAP2 clients
Xerox Lisp machines, Texas Instruments Explorers, and the
Macintosh. The core of the Macintosh client is an early version
the C-Client. SUMEX has also developed IMAP2 servers for TOPS-20
BSD Unix
All of the above software is in production use, with
local user communities. Active development continues on
Macintosh and C-Client based clients and the BSD Unix server.
software is freely available from the University of Washington
SUMEX
IMAP2 software exists for other platforms; for example
Telephone and Telegraph (NTT) has developed an operational IMAP
client for the NTT ELIS. Several organizations are working on a
client
IMAP2 can be used to access mailboxes at very remote sites,
echo delays and frequent outages make TELNET and running a local
reader intolerable. For example, from a desktop workstation on
University of Washington local network the author routinely
IMAP2 to read and manage mailboxes on various University
Washington local servers, at two systems at Stanford University, at
Milnet site, and at a site in Tokyo, Japan
This specification does not make any formal definition of
restrictions, but the DEC-20 server has the following limitations
. length of a mailbox: 7,077,888
. maximum number of messages: 18,432
. length of a command line: 10,000
. length of the local host name: 64
. length of a "short" argument: 39
. length of a "long" argument: 491,520
. maximum amount of data output in a single fetch
655,360
Crispin [Page 29]
RFC 1176 IMAP2 August 1990
To date, nobody has run up against any of these limitations, many
which are substantially larger than most current user mail
programs
Bill Yeager and Rich Acuff both contributed invaluable suggestions
the evolution of IMAP2 from the original IMAP. James Rice
out several ambiguities in the previous IMAP2 specification
otherwise would not allow me to leave bad enough along.
Lundblade reviewed a draft of this version and made several
suggestions
Many dedicated individuals have worked on IMAP2 software, including
Mark Crispin, Frank Gilmurray, Christopher Lane, Hiroshi Okuno
Christopher Schmidt, and Bill Yeager
Any mistakes, flaws, or sins of omission in this IMAP2
specification are, however, strictly my own; and the mention of
name above does not imply an endorsement
Security
Security issues are not discussed in this memo
Author's
Mark R.
Panda
6158 Lariat Loop
Bainbridge Island, WA 98110-2020
Phone: (206) 842-2385
EMail: mrc@Tomobiki-Cho.CAC.Washington.
Crispin [Page 30]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
