As per Relevance of the word messages, we have this rfc below:
Network Working Group M.
Request for Comments: 1064 SUMEX-
July 1988
INTERACTIVE MAIL ACCESS PROTOCOL - VERSION 2
Status of this
This RFC suggests a method for workstations to dynamically
mail from a mailbox server ("repository"). This RFC specifies
standard for the SUMEX-AIM community and a proposed
protocol for the Internet community. Discussion and suggestions
improvement are requested. Distribution of this memo is unlimited
The intent of the Interactive Mail Access Protocol, Version 2 (IMAP2)
is to allow a workstation or similar small machine to
electronic mail from a mailbox server. IMAP2 is the protocol used
the SUMEX-AIM MM-D (MM Distributed) mail system
Although different in many ways from POP2 (RFC 937), IMAP2 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, IMAP2 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 IMAP2 server
on port 143.
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
Crispin [Page 1]
RFC 1064 IMAP2 July 1988
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 system to
user at the console. As a result, background tasks,
receiving mail, could well be kept from running for long
of time either because the user is asking to use all of
machine's resources, or because, in the course of working,
user has (perhaps accidentally) manipulated the environment
such a way as to prevent mail reception. This could lead
repeated failed delivery attempts by 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 the
number of workstations spread throughout office environments
quick repair would not be assured, whereas a centralized
is generally repaired very soon after failure
(3) It is more difficult to keep track of mailing addresses
each person is associated with a distinct machine. Consider
difficulty in keeping track of a large number of postal
or phone numbers, particularly if there was no single address
phone 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
(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. Each
has to 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 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
Crispin [Page 2]
RFC 1064 IMAP2 July 1988
machine would be isolated from direct user manipulation, it
achieve high software reliability easily, and, as a shared resource
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, IMAP2 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, IMAP2 offers several facilities for managing a
beyond the simple "delete message" functionality of POP2.
In spite of this, IMAP2 is a relatively simple protocol.
servers should implement the full set of IMAP2 functions, a
client can be written which uses IMAP2 in much the way as a POP
client
IMAP2 differs from the DMSP protocol of PCMAIL (RFC 1056) in a
fundamental manner, reflecting the differing architectures of MM-
and PCMAIL. PCMAIL is either an online ("interactive mode"),
Crispin [Page 3]
RFC 1064 IMAP2 July 1988
offline ("batch mode") system. MM-D is primarily an online system
which real-time and simultaneous mail access were
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 MM-D, the client/server relationship lasts only for the
of the IMAP2 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 IMAP2 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 IMAP2 and DMSP
DMSP has explicit support for bulletin boards which are only
implicitly in IMAP2. DMSP has functions for sending messages
printing messages, listing mailboxes, and changing passwords, all
which are done outside of IMAP2. DMSP has 16 binary flags of which 8
are defined by the system. IMAP has flag names; there are
5 defined system flag names and a facility for some number (30 in
current implementations) of user flag names. IMAP2 has
sophisticated message search facility in the server to
interesting messages based on dates, addresses, flag status,
textual contents without compelling the client to fetch this data
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, IMAP2 was designed to easily identify
Crispin [Page 4]
RFC 1064 IMAP2 July 1988
"interesting" messages so that the client could fetch the state
those messages and not those 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 "*".
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. When commands are received
server acts on them and responds with responses, often
with data
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 unsolicited data, followed by an OK response. The
may terminate access to this mailbox and access a different one
another SELECT command
The client reads mailbox information by means of FETCH commands.
actual data is transmitted via the unsolicited data mechanism (
is, FETCH should be viewed as poking the server to include
desired data along with any other data it wishes to transmit to
client). There are three major categories of data which may
fetched
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
Crispin [Page 5]
RFC 1064 IMAP2 July 1988
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.] IMAP2 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 IMAP2 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 (presently only the flags) by
of a STORE command. As an example, a message is deleted from
mailbox by a STORE command which includes the \DELETED flag as one
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).
The client terminates the session with the LOGOUT command.
server returns a "BYE" followed by an "OK".
Crispin [Page 6]
RFC 1064 IMAP2 July 1988
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
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
Crispin [Page 7]
RFC 1064 IMAP2 July 1988
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 IMAP2 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
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
Crispin [Page 8]
RFC 1064 IMAP2 July 1988
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 || * message_number
tag CHECK || * FLAGS flag_
tag EXPUNGE || * SEARCH
tag COPY sequence mailbox || * BYE
tag FETCH sequence data || * OK
tag STORE sequence data value || * NO
tag SEARCH search_program || * BAD
|| +
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 an unsolicited BYE response before the (tagged
OK response, and then closes the connection
tag SELECT
The SELECT command selects a particular mailbox. The server
Crispin [Page 9]
RFC 1064 IMAP2 July 1988
check that the user is permitted read access to this mailbox
Prior to returning an OK to the client, the server must send
unsolicited 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
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 the mailbox file on the current servers).
EXAMPLE: A002 SELECT INBOX selects the default 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 should
an unsolicited 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
an unsolicited EXPUNGE response is sent indicating
message was removed. The message number of each
message in the mailbox is immediately decremented by 1; this
that if the last 5 messages in a 9-message mail file are
you will receive 5 "* 5 EXPUNGE" responses. 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
file the server must lock the mail file for exclusive access
an expunge is taking place
Crispin [Page 10]
RFC 1064 IMAP2 July 1988
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. Prior to returning an OK to
client, the server should return an unsolicited COPY
for each message copied. A copy should set the \SEEN flag for
messages which were successfully copied (provided, of course,
the user has write access to this mailbox).
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
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
Crispin [Page 11]
RFC 1064 IMAP2 July 1988
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.
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
Crispin [Page 12]
RFC 1064 IMAP2 July 1988
-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
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 unsolicited SEARCH <1#number
response from the server is a list of messages which express
intersection (AND function) of all the messages. The
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
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
Crispin [Page 13]
RFC 1064 IMAP2 July 1988
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
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.
Crispin [Page 14]
RFC 1064 IMAP2 July 1988
tag OK
This response identifies successful completion of the command
the indicated tag. The text is a line of human-readable
which may be useful in a protocol telemetry log for
purposes
tag NO
This response identifies unsuccessful completion of the
with the indicated tag. The text is a line of human-readable
which probably should be displayed to the user in an error
by the client
tag BAD
This response indicates faulty protocol received from the
and indicates a bug in the client. The text is a line of human
readable text which should be recorded in any telemetry as part
a bug report to the maintainer of the 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
last 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
Functionally equivalent to FETCH, only it happens as
result of a STORE command
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 which describes
Crispin [Page 15]
RFC 1064 IMAP2 July 1988
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 (a.k.a.
at-domain-list in SMTP), mailbox name,
host name
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 mail
\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
Crispin [Page 16]
RFC 1064 IMAP2 July 1988
characters in the message as
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) which are applicable for this mailbox. Flags other
the 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 those messages which match the search criteria
Each number is delimited by a space, e.g., "SEARCH 2 3 6".
* BYE
This response indicates that the server is about to close
connection. The text is a line of human-readable text
should be displayed to the user in a status report by the client
This may be sent as part of a normal logout sequence, or as
panic shutdown announcement by the server. It is also used
some servers as an announcement of an inactivity autologout
* OK
This response indicates that the server is alive. No
action on the part of the client is called for. This is
only used by servers at startup as a greeting message
that they are ready to accept the first command. The text is
line of human-readable text which may be logged in
telemetry
* NO
This response indicates some operational error at the server
cannot be traced to any protocol command. The text is a line
human-readable text which should be logged in protocol
for the maintainer of the server and/or the client. No
server currently outputs such a response
* BAD
This response indicates some protocol error at the server
Crispin [Page 17]
RFC 1064 IMAP2 July 1988
cannot be traced to any protocol command. The text is a line
human-readable text which should be logged in protocol
for the maintainer of the server and/or the client.
generally indicates a protocol synchronization problem on the
of the client, and examination of the protocol telemetry
advised to determine the cause of the problem
+
This response indicates 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 in the case of commands which contain literals
since a literal can be an arbitrarily long amount of text, and
server may not even be expecting a literal. This mechanism
provided so the client knows not to send a literal until
server definitely expects it, preserving client/
synchronization
In actual practice, this situation is rarely encountered. In
current protocol, the only client command likely to contain
literal is the LOGIN command. Consider a situation in which
server validates the user before checking the password. If
password contains "funny" characters and hence is sent as
literal, then if the user is invalid an error would occur
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 due to a
in the client or server and not for some operational problem
Crispin [Page 18]
RFC 1064 IMAP2 July 1988
Sample IMAP2
The following is a transcript of an actual IMAP2 session.
output is identified by "S:" and client output by "U:". In
where lines were too long to fit within the boundaries of
document, the line was continued on the next line preceded by a tab
S: * OK SUMEX-AIM.Stanford.EDU Interim Mail Access Protocol
Service 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
Question Note \XXXX \YYYY \Answered \Flagged \
\Seen
S: * 16
S: * 0
S: a002 OK Select
U: a003 fetch 16
S: * 16 Fetch (Flags (\Seen) InternalDate " 9-Jun-88 12:55:
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: -------
Crispin [Page 19]
RFC 1064 IMAP2 July 1988
S: )
S: pa004 OK Fetch
U: a005
S: * BYE DEC-20 IMAP II server terminating
S: a005 OK SUMEX-AIM.Stanford.EDU Interim Mail Access
Service
Crispin [Page 20]
RFC 1064 IMAP2 July 1988
Implementation
As of this writing, SUMEX has completed an IMAP2 client for
Lisp machines written in hybrid Interlisp/CommonLisp and is beta
testing a client for TI Explorers written entirely in CommonLisp
SUMEX has also completed a portable IMAP2 client protocol
module written in C. This library, with the addition of a small
program (primarily user interface) and a TCP/IP driver, became
rudimentary remote system mail-reading program under Unix. The
production use of this library will be as a part of a MacII
which is under development
As of this writing, SUMEX has completed IMAP2 servers for TOPS-20
written in DEC-20 assembly language and 4.2/3 BSD Unix written in C
The TOPS-20 server is fully compatible with MM-20, the
TOPS-20 mailsystem, and requires no special action or setup on
part of the user. The INBOX under TOPS-20 is the user's MAIL.TXT
The TOPS-20 server also supports multiple simultaneous access to
same mailbox, including simultaneous access between the IMAP2
and MM-20. The 4.2/3 BSD Unix server requires that the user
mail.txt format which is compatible only with SRI MM-32 or
MM-C. The 4.2/3 BSD Unix server only allows simultaneous
access; write access must be exclusive
The Xerox Lisp client and DEC-20 server have been in production
for over a year; the Unix server was put into production use a
months ago. IMAP2 has been used to access mailboxes at remote
from a local workstation via the Internet. For example, from
Stanford local network the author has read his mailbox at a
site
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
To date, nobody has run up against any of these limitations, many
which are substantially larger than most current user mail
programs
There are several advantages to the scheme of tags and
Crispin [Page 21]
RFC 1064 IMAP2 July 1988
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 which would signal
client when the tagged response comes in. Under
circumstances, the client could even have more than one
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 relatively rare; a mechanism (the
"+" tag response) was introduced to handle those few cases
could happen. The proper way to address this problem in all cases
probably to move towards a record-oriented architecture instead
the text stream model provided by TCP
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 means of sending "unsolicited data",
the server is in effect sending a command to the client -- to
and/or extend its (incomplete) model of the mailbox with
information from the server. In this viewpoint, a "fetch" command
merely a request to the server to include the desired data in
other "unsolicited" data the server may send, and a
acknowledgement to the "fetch" is a statement that all the
data has been sent
In terms of implementation, the client may have a local cache of
from the mailbox. This cache is incomplete, and at startup is empty
A listener processes all unsolicited data, and updates the
based on this data. If a tagged response arrives, the
unblocks the process which sent the tagged request
Perhaps as a result of opening a mailbox, unsolicited data from
server arrives. The first piece of data is the number of messages
This is used to size the cache; note that by sending a new "number
messages" unsolicited data message the cache would be re-sized (
is how newly arrived mail is handled). If the client attempts
access information from the cache, it will encounter empty
which will trigger "fetch" requests. The request would be sent,
Crispin [Page 22]
RFC 1064 IMAP2 July 1988
unsolicited data including the answer to the fetch will flow back
and then the "fetch" response will unblock the client
People familiar with demand-paged virtual memory operating
design will recognize this model as being very similar to page-
handling on a demand-paged system
Crispin [Page 23]
RFC 1064 IMAP2 July 1988
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 /
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 ")"
env_sender ::= nil / "(" 1*address ")"
Crispin [Page 24]
RFC 1064 IMAP2 July 1988
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
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 ::=
nil ::= "NIL
noop ::= "NOOP
password ::=
Crispin [Page 25]
RFC 1064 IMAP2 July 1988
recent_flag ::= "\RECENT
ready ::= "+" SP text_
request ::= tag SP (noop / login / logout / select / check /
expunge / copy / fetch / store / search)
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 ::=
Bill Yeager and Rich Acuff both contributed invaluable suggestions
the evolution of IMAP2 from the original IMAP. The SUMEX IMAP
software was written by Mark Crispin (DEC-20 server, Xerox
client, C client), Frank Gilmurray (Common Lisp client),
Lane (Xerox Lisp client), and Bill Yeager (Unix server).
mistakes or flaws in this IMAP2 protocol specification are, however
strictly my own
Crispin [Page 26]
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
