similar protocols do not happen with tagged commands; a command is
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 client
losing synchronization. Compare this with the problems that FTP or
SMTP clients have with continuation, partial completion, and
commentary reply codes.
Another advantage is that a non-lockstep client implementation is
possible. The client could send a command, and entrust the handling
of the server responses to a different process that would signal the
client when the tagged response comes in. Under certain
circumstances, the client may have more than one command outstanding.
It was observed that synchronization problems can occur with literals
if the literal is not recognized as such. Fortunately, the cases in
which this can happen are rare; a mechanism (the special "+" tag
response) was introduced to handle those few cases. The proper way
to address this problem is probably to move towards a record-oriented
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 is
empty. A listener processes all unsolicited data, and updates the
cache based on this data. If a tagged response arrives, the listener
unblocks the process that sent the tagged request.
Unsolicited data needs some discussion. Unlike most protocols, in
which the server merely does the client's bidding, an IMAP2 server
has a semi-autonomous role. By sending "unsolicited data", the
server is in effect sending a command to the client -- to update or
extend the client's cache with new information from the server. In
other words, a "fetch" command is merely a request to the server to
ensure that the client's cache has the most up-to-date version of the
requested information. A server acknowledgement to the "fetch" is a
statement that all the requested data has been sent.
Although no current server does this, a server is not obliged by the
protocol to send data that it has already sent and is unchanged. An
exception to this is the actual message text fetching operations
(RFC822, RFC822.HEADER, and RFC822.TEXT), owing to the possibly
excessive resource consumption of maintaining this data in a cache.
It can not be assumed that a FETCH will transmit any data; only that
an OK to the FETCH means that the client's cache has the most up-to-
date information.
When a mailbox is selected, the initial unsolicited data from the
server arrives. The first piece of data is the number of messages.
By sending a new EXISTS unsolicited data message the server causes
the client to resize its cache (this is how newly arrived mail is
handled). If the client attempts to access information from the
cache, it will encounter empty spots that will trigger "fetch"
requests. The request would be sent, some 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 system
design will recognize this model as being similar to page-fault
handling on a demand-paged system.
Formal Syntax
The following syntax specification uses the augmented Backus-Naur
Form (BNF) notation as specified in RFC822 with one exception; the
delimiter used with the "#" construct is a single space (SP) and not
a comma.
address ::= "(" addr_name SP addr_adl SP addr_mailbox SP
addr_host ")"
addr_adl ::= nil / string
addr_host ::= nil / string
addr_mailbox ::= nil / string
addr_name ::= nil / string
bboard ::= "BBOARD" SP string
check ::= "CHECK"
copy ::= "COPY" SP sequence SP mailbox
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 SP
env_sender SP env_reply-to SP env_to SP
env_cc SP env_bcc SP env_in-reply-to SP
env_message-id ")"
env_bcc ::= nil / "(" 1*address ")"
env_cc ::= nil / "(" 1*address ")"
env_date ::= string
env_from ::= nil / "(" 1*address ")"
env_in-reply-to ::= nil / string
env_message-id ::= nil / string
env_reply-to ::= nil / "(" 1*address ")"
env_sender ::= nil / "(" 1*address ")"
env_subject ::= nil / string
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 string
find_option ::= "MAILBOXES" / "BBOARDS"
flag_list ::= ATOM / "(" 1#ATOM ")"
literal ::= "{" NUMBER "}" CRLF ASCII-STRING
login ::= "LOGIN" SP userid SP password
logout ::= "LOGOUT"
mailbox ::= "INBOX" / string
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" SP
envelope / "FLAGS" SP "(" 1#(recent_flag
flag_list) ")" / "INTERNALDATE" SP date /
"RFC822" SP string / "RFC822.HEADER" SP string /
"RFC822.SIZE" SP NUMBER / "RFC822.TEXT" SP
string) ")"
msg_recent ::= "RECENT"
msg_num ::= NUMBER
nil ::= "NIL"
noop ::= "NOOP"
password ::= string
recent_flag ::= "\RECENT"
ready ::= "+" SP text_line
request ::= tag SP (noop / login / logout / select / check /
expunge / copy / fetch / store / search / find /
bboard) CRLF
response ::= tag SP ("OK" / "NO" / "BAD") SP text_line CRLF
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 mailbox
sequence ::= NUMBER / (NUMBER "," sequence) / (NUMBER ":"
sequence)
store ::= "STORE" SP sequence SP store_att
store_att ::= ("+FLAGS" SP flag_list / "-FLAGS" SP flag_list /
"FLAGS" SP flag_list)
string ::= atom / """" 1*character """" / literal
system_flags ::= "\ANSWERED" SP "\FLAGGED" SP "\DELETED" SP
"\SEEN"
tag ::= atom
unsolicited ::= "*" SP (msg_num SP msg_data / data) CRLF
userid ::= string
Implementation Status
This information is current as of this writing.
The University of Washington has developed an electronic mail client
library called the "C-Client". It provides complete IMAP2, SMTP, and
local mailbox (both /usr/spool/mail and mail.txt formats) services in
a well-defined way to a user interface main program. Using the C-
Client, the University of Washington has created an operational
client for BSD Unix and two operational clients (one basic, one
advanced) for the NeXT.
Stanford University/SUMEX has developed operational IMAP2 clients for
Xerox Lisp machines, Texas Instruments Explorers, and the Apple
Macintosh. The core of the Macintosh client is an early version of
the C-Client. SUMEX has also developed IMAP2 servers for TOPS-20 and
BSD Unix.
All of the above software is in production use, with enthusiastic
local user communities. Active development continues on the
Macintosh and C-Client based clients and the BSD Unix server. This
software is freely available from the University of Washington and
SUMEX.
IMAP2 software exists for other platforms; for example Nippon
Telephone and Telegraph (NTT) has developed an operational IMAP2
client for the NTT ELIS. Several organizations are working on a PC
client.
IMAP2 can be used to access mailboxes at very remote sites, where
echo delays and frequent outages make TELNET and running a local mail
reader intolerable. For example, from a desktop workstation on the
University of Washington local network the author routinely uses
IMAP2 to read and manage mailboxes on various University of
Washington local servers, at two systems at Stanford University, at a
Milnet site, and at a site in Tokyo, Japan.
This specification does not make any formal definition of size
restrictions, but the DEC-20 server has the following limitations:
. length of a mailbox: 7,077,888 characters
. maximum number of messages: 18,432 messages
. length of a command line: 10,000 characters
. length of the local host name: 64 characters
. length of a "short" argument: 39 characters
. length of a "long" argument: 491,520 characters
. maximum amount of data output in a single fetch:
655,360 characters
To date, nobody has run up against any of these limitations, many of
which are substantially larger than most current user mail reading
programs.
Acknowledgements
Bill Yeager and Rich Acuff both contributed invaluable suggestions in
the evolution of IMAP2 from the original IMAP. James Rice pointed
out several ambiguities in the previous IMAP2 specification and
otherwise would not allow me to leave bad enough along. Laurence
Lundblade reviewed a draft of this version and made several helpful
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 protocol
specification are, however, strictly my own; and the mention of any
name above does not imply an endorsement.
Security Considerations
Security issues are not discussed in this memo.
Author's Address
Mark R. Crispin
Panda Programming
6158 Lariat Loop NE
Bainbridge Island, WA 98110-2020
Phone: (206) 842-2385