The following document is a modified version of RFC 1064. The changes that have been made to RFC 1064 are indicated by { characters in column zero for the original text from RFC 1064 and | or + characters in column 0 for any new text. In addition to these changes, references to IMAP2 have globally changed to IMAP3 except in text that is superceeded by { marks. |Compatibility note: | In revising the IMAP2 protocol it has been out intent, wherever possible | to make upwards compatible changes to produce IMAP3. There were, however, | some places that had to be changed incompatibly in order to compensate | for either ambiguities in the IMAP2 protocol as defined by RFC1064 | or behavior that proved undesirable in the light of experience. | | It is our goal, however, that existing IMAP2 clients should still be | supported and that, at least for the forseeable future, all IMAP3 | servers will support IMAP2 behavior as their default mode. INTERACTIVE MAIL ACCESS PROTOCOL - VERSION 3 Status of this Memo This RFC suggests a method for workstations to access mail dynamically from a mailbox server ("repository"). This RFC specifies a standard for the SUMEX-AIM community and a proposed experimental protocol for the Internet community. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. Introduction { The intent of the Interactive Mail Access Protocol, Version 2 (IMAP2) { is to allow a workstation or similar small machine to access { electronic mail from a mailbox server. IMAP2 is the protocol used by { the SUMEX-AIM MM-D (MM Distributed) mail system. | The intent of the Interactive Mail Access Protocol, Version 3 (IMAP3) | is to allow a (possibly unreliable) workstation or similar | machine to access electronic mail from a reliable mailbox server in | an efficient manner. Although different in many ways from POP2 (RFC 937), IMAP3 may be thought of as a functional superset of POP2, and the POP2 RFC was 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 offer a basis for comparison. Like POP2, IMAP3 specifies a means of accessing stored mail and not of posting mail; this function is handled by a mail transfer protocol such as SMTP (RFC 821). A comparison with the DMSP protocol of PCMAIL can be found at the end of "System Model and Philosophy" section. This protocol assumes a reliable data stream such as provided by TCP { or any similar protocol. When TCP is used, the IMAP2 server listens { on port 143. | or any similar protocol. When TCP is used, the IMAP server listens | on port 143. When CHAOS is used the IMAP server listens for the logical | contact name "IMAP". System Model and Philosophy Electronic mail is a primary means of communication for the widely spread SUMEX-AIM community. The advent of distributed workstations is forcing a significant rethinking of the mechanisms employed to manage such mail. With mainframes, each user tends to receive and process mail at the computer he used most of the time, his "primary host". The first inclination of many users when an independent workstation is placed in front of them is to begin receiving mail at the workstation, and, in fact, many vendors have implemented facilities to do this. However, this approach has several disadvantages: (1) Workstations (especially Lisp workstations) have a software design that gives full control of all aspects of the system to the user at the console. As a result, background tasks, like receiving mail, could well be kept from running for long periods of time either because the user is asking to use all of the machine's resources, or because, in the course of working, the user has (perhaps accidentally) manipulated the environment in such a way as to prevent mail reception. This could lead to repeated failed delivery attempts by outside agents. (2) The hardware failure of a single workstation could keep its user "off the air" for a considerable time, since repair of individual workstation units might be delayed. Given the growing number of workstations spread throughout office environments, quick repair would not be assured, whereas a centralized mainframe is generally repaired very soon after failure. (3) It is more difficult to keep track of mailing addresses when each person is associated with a distinct machine. Consider the difficulty in keeping track of a large number of postal addresses or phone numbers, particularly if there was no single address or phone number for an organization through which you could reach any person in that organization. Traditionally, electronic mail on the ARPANET involved remembering a name and one of several "hosts" (machines) whose name reflected the organization in which the individual worked. This was suitable at a time when most organizations had only one central host. It is less satisfactory today unless the concept of a host is changed to refer to an organizational entity and not a particular machine. (4) It is very difficult to keep a multitude of heterogeneous workstations working properly with complex mailing protocols, making it difficult to move forward as progress is made in electronic communication and as new standards emerge. Each system has to worry about receiving incoming mail, routing and delivering outgoing mail, formatting, storing, and providing for the stability of mailboxes over a variety of possible filing and mailing protocols. Consequently, while the workstation may be viewed as an Internet host in the sense that it implements IP, it should not be viewed as the entity which contains the user's mailbox. Rather, a mail server machine (sometimes called a "repository") should hold the mailbox, and the workstation (hereafter referred to as a "client") should access the mailbox via mail transactions. Because the mail server machine would be isolated from direct user manipulation, it could achieve high software reliability easily, and, as a shared resource, it could achieve high hardware reliability, perhaps through redundancy. The mail server could be used from arbitrary locations, allowing users to read mail across campus, town, or country using more and more commonly available clients. Furthermore, the same user may access his mailbox from different clients at different times, and multiple users may access the same mailbox simultaneously. The mail server acts an an interface among users, data storage, and other mailers. The mail access protocol is used to retrieve messages, access and change properties of messages, and manage mailboxes. This differs from some approaches (e.g., Unix mail via NFS) in that the mail access protocol is used for all message manipulations, isolating the user and the client from all knowledge of how the data storage is used. This means that the mail server can utilize the data storage in whatever way is most efficient to organize the mail in that particular environment, without having to worry about storage representation compatibility across different machines. In defining a mail access protocol, it is important to keep in mind that the client and server form a macrosystem, in which it should be possible to exploit the strong points of both while compensating for each other's weaknesses. Furthermore, it's desirable to allow for a growth path beyond the hoary text-only RFC 822 protocol. Unlike POP2, IMAP3 has extensive features for remote searching and parsing of messages on the server. For example, a free text search (optionally in conjunction with other searching) can be made throughout the entire mailbox by the server and the results made available to the client without the client having to transfer the entire mailbox and searching itself. Since remote parsing of a message into a structured (and standard format) "envelope" is available, a client can display envelope information and implement commands such as REPLY without having any understanding of how to parse RFC 822, etc. headers. Additionally, IMAP3 offers several facilities for managing a mailbox beyond the simple "delete message" functionality of POP2. In spite of this, IMAP3 is a relatively simple protocol. Although servers should implement the full set of IMAP3 functions, a simple client can be written which uses IMAP3 in much the way as a POP2 client. IMAP3 differs from the DMSP protocol of PCMAIL (RFC 1056) in a more { fundamental manner, reflecting the differing architectures of MM-D | fundamental manner, reflecting the differing architectures of IMAP and PCMAIL. PCMAIL is either an online ("interactive mode"), or { offline ("batch mode") system. MM-D is primarily an online system in | offline ("batch mode") system. IMAP is primarily an online system in which real-time and simultaneous mail access were considered important. In PCMAIL, there is a long-term client/server relationship in which some mailbox state is preserved on the client. There is a registration of clients used by a particular user, and the client keeps a set of "descriptors" for each message which summarize the message. The server and client synchronize their states when the DMSP connection starts up, and, if a client has not accessed the server for a while, the client does a complete reset (reload) of its state from the server. { In MM-D, the client/server relationship lasts only for the duration | In IMAP, the client/server relationship lasts only for the duration of the IMAP3 connection. All mailbox state is maintained on the server. There is no registration of clients. The function of a descriptor is handled by a structured representation of the message "envelope". This structure makes it unnecessary for a client to know anything about RFC 822 parsing. There is no synchronization since the client does not remember state between IMAP3 connections. This is not a problem since in general the client never needs the entire state of the mailbox in a single session, therefore there isn't much overhead in fetching the state information that is needed as it is needed. There are also some functional differences between IMAP3 and DMSP. { DMSP has explicit support for bulletin boards which are only handled { implicitly in IMAP3. DMSP has functions for sending messages, { printing messages, listing mailboxes, and changing passwords, all of { which are done outside of IMAP3. 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 a facility for some number (30 in the | DMSP has functions for sending messages, printing messages, | and changing passwords, all of which are done outside of IMAP3. | 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 a facility for some number (29 in the current implementations) of user flag names. IMAP3 has a sophisticated message search facility in the server to identify interesting messages based on dates, addresses, flag status, or textual contents without compelling the client to fetch this data for every message. It was felt that maintaining state on the client is advantageous only in those cases where the client is only used by a single user, or if there is some means on the client to restrict access to another user's data. It can be a serious disadvantage in an environment in which multiple users routinely use the same client, the same user routinely uses different clients, and where there are no access restrictions on the client. It was also observed that most user mail access is to a relatively small set of "interesting" messages, which were either "new" mail or mail based upon some user-selected criteria. Consequently, IMAP3 was designed to easily identify those "interesting" messages so that the client could fetch the state of those messages and not those that were not "interesting". The Protocol { The IMAP2 protocol consists of a sequence of client commands and { server responses, with server data interspersed between the { responses. Unlike most Internet protocols, commands and responses { are tagged. That is, a command begins with a unique identifier { (typically a short alphanumeric sequence such as a Lisp "gensym" { function would generate e.g., A0001, A0002, etc.), called a tag. The { response to this command is given the same tag from the server. { Additionally, the server may send an arbitrary amount of "unsolicited { data", which is identified by the special reserved tag of "*". There { is another special reserved tag, "+", discussed below. | The IMAP3 protocol consists of a sequence of client commands and | server responses to those commands, with extra information from the | server data being sent asynchronously to and independent to the | responses to client commands. Unlike most Internet protocols, commands | and responses are tagged. That is, a command begins with a unique | identifier (typically a short alphanumeric sequence such as a Lisp "gensym" | function would generate e.g., A0001, A0002, etc.), called a tag. The | response to this command is given the same tag from the server. | | We distinguish between data sent by the server as the result of a client | request, which we term "SOLICITED" and data sent by the server not as | the result of a client request, which we term "UNSOLICITED". The server | may send unsolicited data at any time that would not fragment another | piece of data on the same stream rendering it unintelligible. The server | is contractually required, however, to return all data that is solicited | by the client before the return of the completion signal for that | command, i.e. all solicited data must be returned within the temporal | extent of the request/completion acknowledgement wrapper. This does | not, however, preclude the simultaneous processing of multiple requests | by the client, it simply requires that the client be confident that | it has all the requested data when a request finishes. This allows the | implementation of both synchronous and asynchronous clients. | | Solicited data is identified by the tag of the initial request by the | client. Unsolicited data is identified by the special reserved tag | of "*". There is another special reserved tag, "+", discussed below. | | Note: the tagging of SOLICITED data is only permitted for a selected | server version greater than 2.0. | No assumptions concerning serial or monolithic processing by the server | can be made by a correct client. The server is at liberty to | process multiple requests by the same client in any order. | This allows future servers to process costly searches over mailboxe | on slow backing storage media in the background, whilst still | preserving interactive performance. Clients can, however, assume | the serialization of the request/data/completion behavior mentioned above. The server must be listening for a connection. When a connection is opened the server sends an unsolicited OK response as a greeting message and then waits for commands. When commands are received the server acts on them and responds with responses, often interspersed with data. The client opens a connection, waits for the greeting, then sends a LOGIN command with user name and password arguments to establish authorization. Following an OK response from the server, the client then sends a SELECT command to access the desired mailbox. The user's default mailbox has a special reserved name of "INBOX" which is independent of the operating system that the server is implemented on. The server will generally send a list of valid flags, number of messages, and number of messages arrived since last access for this { mailbox as unsolicited data, followed by an OK response. The client | mailbox as solicited data, followed by an OK response. The client may terminate access to this mailbox and access a different one with another SELECT command. | Because the SELECT command affects the state of the server in a | fundamental way, the server is required to process all outstanding | commands for any given mailbox before sending the OK tag for the SELECT | command. Thus, the client will always know that all responses before | an OK SELECT response will refer to the old mailbox and all responses | following it will apply to the new mailbox. | Because, in the real world, local needs or experimental work will | dictate that servers will support both supersets of the defined behavior | and incompatible changes, servers will support a VERSION command, the | purpose of which is to allow clients to select the features that they | want from a server. The default behavior of any server is to process | commands in the manner specified by IMAP2 in RFC1064. A server may not | behave in any other manner unless the VERSION command is used to select | different behavior. Over time, when globally useful changes to the | current, default behavior of the server are found, these will be | incorporated in such a way that all of the features can be selected | simply by selecting the version number of the server. The client reads mailbox information by means of FETCH commands. The { actual data is transmitted via the unsolicited data mechanism (that | actual data is transmitted via the solicited data mechanism (that is, FETCH should be viewed as poking the server to include the desired data along with any other data it wishes to transmit to the client). There are three major categories of data which may be fetched. The first category is that data which is associated with a message as an entity in the mailbox. There are presently three such items of data: the "internal date", the "RFC 822 size", and the "flags". The internal 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 size in bytes of the message, expressed as an RFC 822 text string. Current clients only use it as part of a status display line. The flags are a list of status flags associated with the message (see below). All of the first category data can be fetched by using the macro-fetch word "FAST"; that is, "FAST" expands to "(FLAGS INTERNALDATE RFC822.SIZE)". The second category is that data which describes the composition and delivery information of a message; that is, information such as the message sender, recipient lists, message-ID, subject, etc. This is 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, which is strictly limited to delivery information.] IMAP3 defines a structured and unambiguous representation for the envelope which is particularly nice for Lisp-based parsers. A client can use the envelope for operations such as replying and not worry about RFC 822 at all. Envelopes are discussed in more detail below. The first and second category data can be fetched together by using the macro-fetch word "ALL"; that is, "ALL" expands to "(FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)". The third category is that data which is intended for direct human viewing. The present RFC 822 based IMAP3 defines three such items: RFC822.HEADER, RFC822.TEXT, and RFC822 (the latter being the two former appended together in a single text string). Fetching "RFC822" is equivalent to typing the RFC 822 representation of the message as stored on the mailbox without any filtering or processing. Typically, a client will "FETCH ALL" for some or all of the messages in the mailbox for use as a presentation menu, and when the user wishes to read a particular message will "FETCH RFC822.TEXT" to get the message body. A more primitive client could, of course, simply "FETCH RFC822" a la POP2-type functionality. { The client can alter certain data (presently only the flags) by means { of a STORE command. As an example, a message is deleted from a { mailbox by a STORE command which includes the \DELETED flag as one of { the flags being set. | The client can alter certain data by means of a STORE command. As | an example, a message is deleted from a mailbox by a STORE command | which includes the \DELETED flag as one of the flags being set. Other client operations include copying a message to another mailbox (COPY command), permanently removing deleted messages (EXPUNGE command), checking for new messages (CHECK command), and searching for messages which match certain criteria (SEARCH command). The client terminates the session with the LOGOUT command. The server returns a "BYE" followed by an "OK". A Typical Scenario { Client Server { ------ ------ { {Wait for Connection} { {Open Connection} --> { <-- * OK IMAP2 Server Ready { {Wait for command} { A001 LOGIN Fred Secret --> { <-- A001 OK User Fred logged in { {Wait for command} { A002 SELECT INBOX --> { <-- * FLAGS (Meeting Notice \Answered { \Flagged \Deleted \Seen) { <-- * 19 EXISTS { <-- * 2 RECENT { <-- A0002 OK Select complete { {Wait for command} { A003 FETCH 1:19 ALL --> { <-- * 1 Fetch (......) { ... { <-- * 18 Fetch (......) { <-- * 19 Fetch (......) { <-- A003 OK Fetch complete { {Wait for command} { A004 FETCH 8 RFC822.TEXT --> { <-- * 8 Fetch (RFC822.TEXT {893} { ...893 characters of text... { <-- ) { <-- A004 OK Fetch complete { {Wait for command} { { A005 STORE 8 +Flags \Deleted --> { <-- * 8 Store (Flags (\Deleted { \Seen)) { <-- A005 OK Store complete { {Wait for command} { A006 EXPUNGE --> { <-- * 19 EXISTS { <-- * 8 EXPUNGE { <-- * 18 EXISTS { <-- A006 Expunge complete { {Wait for command} { A007 LOGOUT --> { <-- * BYE IMAP2 server quitting { <-- A007 OK Logout complete { {Close Connection} --><-- {Close connection} { {Go back to start} | Client Server | ------ ------ | {Wait for Connection} | {Open Connection} --> | <-- * OK IMAP3 Server Ready | {Wait for command} | A001 SUPPORTEDVERSIONS --> | <-- * SUPPORTEDVERSIONS ((2.0 ) | (3.0 EIGHT-BIT-TRANSPARENT | ~EIGHT-BIT-TRANSPARENT | AUTO-SET-SEEN | ~AUTO-SET-SEEN | ~TAGGED-SOLICITED | TAGGED-SOLICITED)) | A001 Supported Versions returned. | {Wait for command} | A002 VERSION 3.0 TAGGED-SOLICITED --> | <-- A002 VERSION 3.0 TAGGED-SOLICITED | <-- A002 OK Version 3.0 Selected. | {Wait for command} | A003 LOGIN Fred Secret --> | <-- A003 OK User Fred logged in | {Wait for command} | A004 SELECT INBOX --> | <-- A004 FLAGS (Meeting Notice \Answered | \Flagged \Deleted \Seen) | <-- A004 19 EXISTS | <-- A004 2 RECENT | <-- A004 OK Select complete | {Wait for command} | A005 FETCH 1:19 ALL --> | <-- A005 1 Fetch (......) | ... | <-- A005 18 Fetch (......) | <-- A005 19 Fetch (......) | <-- A005 OK Fetch complete | {Wait for command} | A006 FETCH 8 RFC822.TEXT --> | <-- A006 8 Fetch (RFC822.TEXT {893} | ...893 characters of text... | <-- ) | <-- A006 OK Fetch complete | {Wait for command} | | A007 STORE 8 +Flags \Deleted --> | <-- A007 8 Store (Flags (\Deleted | \Seen)) | <-- A007 OK Store complete | {Wait for command} | A008 EXPUNGE --> | <-- A008 19 EXISTS | <-- A008 8 EXPUNGE | <-- A008 18 EXISTS | <-- A008 Expunge complete | {Wait for command} | A009 LOGOUT --> | <-- A009 BYE IMAP3 server quitting | <-- A009 OK Logout complete | {Close Connection} --><-- {Close connection} | {Go back to start} | A more complex scenario produced by a pipelining multiprocess client. | | Client Server | ------ ------ | {Wait for Connection} | {Open session as above} | <-- A004 19 EXISTS | <-- A004 2 RECENT | <-- A004 OK Select complete | {Wait for command} | A005 SEARCH RECENT --> | <-- A005 SEARCH (18 19) (RECENT) | <---A005 OK Search complete | A006 FETCH 18:19 ALL RFC822.TEXT | A007 STORE 18:19 +FLAGS (\SEEN) | A008 FETCH 1:17 ALL --> | <-- A006 18 Fetch (... RFC822.TEXT ...) | A009 STORE 18 +FLAGS (\DELETED) | <-- A006 19 Fetch (... RFC822.TEXT ...) | <-- A006 OK Fetch complete | <-- A007 18 STORE (Flags (\Seen)) | A010 STORE 19 +FLAGS (\DELETED) | <-- A007 19 STORE (Flags (\Seen)) | <-- A007 OK Store complete | <-- A008 1 Fetch (......) | ... | <-- A008 16 Fetch (......) | <-- A008 17 Fetch (......) | <-- A008 OK Fetch complete | <-- A009 18 STORE (Flags (\Seen \Deleted)) | <-- A009 OK Store complete | <-- A010 19 STORE (Flags (\Seen \Deleted)) | <-- A010 OK Store complete | {Wait for command} | <-- * EXISTS 23 | <-- * RECENT 4 | <-- * SEARCH (20 21 22 23) (RECENT) | A011 FETCH 20:23 ALL RFC822.TEXT | ... Conventions The following terms are used in a meta-sense in the syntax 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 immediately by an ASCII linefeed character. A NUMBER is a sequence of the ASCII characters which represent decimal numerals ("0" through "9"), delimited by SP, CRLF, ",", or ":". | A REAL_NUMBER is a sequence of the ASCII characters which represent | decimal numerals ("0" through "9" and "."), delimited by SP, | CRLF, ",", or ":". | A SP is the ASCII space character. A TEXT_LINE is a human-readable sequence of ASCII characters up to but not including a terminating CRLF. One of the most common fields in the IMAP3 protocol is a STRING, which may be an ATOM, QUOTED-STRING (a sequence of CHARACTERs inside double-quotes), or a LITERAL. A literal consists of an open brace ("{"), a number, a 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, a string should be represented as an ATOM or QUOTED-STRING if at all possible. The semantics for QUOTED-STRING or LITERAL are checked before those for ATOM; therefore an ATOM used in a STRING may only contain CHARACTERs. Literals are most often sent from the server to the client; in the rare case of a client to server literal there is a special consideration (see the "+ text" response below). Another important field is the SEQUENCE, which identifies a set of messages by consecutive numbers from 1 to n where n is the number of messages in the mailbox. A sequence may consist of a single number, a pair of numbers delimited by colon indicating all numbers between 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 to 2,4,5,6,7,9,12,13,14,15 and identifies all of those messages. Definitions of Commands and Responses Summary of Commands and Responses { Commands || Responses { -------- || ------- { tag NOOP || tag OK text { tag LOGIN user password || tag NO text { tag LOGOUT || tag BAD text { tag SELECT mailbox || * message_number data { tag CHECK || * FLAGS flag_list { tag EXPUNGE || * SEARCH sequence { tag COPY sequence mailbox || * BYE text { tag FETCH sequence data || * OK text { tag STORE sequence data value || * NO text { tag SEARCH search_program || * BAD text { || + text |Commands: | tag NOOP | tag LOGIN user password | tag LOGOUT | tag SELECT mailbox | tag CHECK | tag EXPUNGE | tag COPY sequence mailbox | tag FETCH sequence data | tag STORE sequence data value | tag SEARCH criteria | tag BBOARD bboard | tag FIND (BBOARDS / MAILBOXES) pattern | tag READONLY | tag READWRITE | tag VERSION real_number features | tag SUPPORTEDVERSIONS | |Responses (can be either solicited or unsolicited): | */tag FLAGS flag_list | */tag SEARCH (numbers) (criteria) | */tag EXISTS | */tag RECENT | */tag EXPUNGE | */tag STORE data | */tag FETCH data | */tag BBOARD bboard_name | */tag MAILBOX non_inbox_mailbox_name | */tag SUPPORTEDVERSIONS version_data | */tag READONLY | */tag READWRITE | */tag OK text | */tag NO text | */tag BAD text | */tag BYE text | |Responses (can only be solicited): | tag VERSION real_number 1#feature | |Responses (can only be unsolicited): | + text Commands tag NOOP The NOOP command returns an OK to the client. By itself, it does nothing, but certain things may happen as side effects. For example, server implementations which implicitly check the mailbox for new mail may do so as a result of this command. The primary use of this command is to for the client to see if the server is still alive (and notify the server that the client is still alive, for those servers which have inactivity autologout timers). tag LOGIN user password The LOGIN command identifies the user to the server and carries the password authenticating this user. This information is used by the server to control access to the mailboxes. EXAMPLE: A001 LOGIN SMITH SESAME logs in as user SMITH with password SESAME. tag LOGOUT The LOGOUT command indicates the client is done with the session. { The server sends an unsolicited BYE response before the (tagged) | The server sends a solicited BYE response before the (tagged) OK response, and then closes the connection. tag SELECT mailbox The SELECT command selects a particular mailbox. The server must check that the user is permitted read access to this mailbox. Prior to returning an OK to the client, the server must send an { unsolicited FLAGS and EXISTS response to the client giving the | solicited FLAGS and EXISTS response to the client giving the flags list for this mailbox (simply the system flags if this mailbox doesn't have any special flags) and the number of messages in the mailbox. It is also recommended that the server send a RECENT unsolicited response to the client for the benefit of clients which make use of the number of new messages in a mailbox. | It is further recommended that servers should send an unsolicited | READONLY message if the mailbox that has been selected is not | writable by the user. Multiple SELECT commands are permitted in a session, in which case the prior mailbox is deselected first. The default mailbox for the SELECT command is INBOX, which is a special name reserved to mean "the primary mailbox for this user on this server". The format of other mailbox names is operating system dependent (as of this writing, it reflects the filename path of the mailbox file on the current servers). EXAMPLE: A002 SELECT INBOX selects the default mailbox. tag CHECK The CHECK command forces a check for new messages and a rescan of the mailbox for internal change for those implementations which allow multiple simultaneous read/write access to the same mailbox (e.g., TOPS-20). It is recommend that periodic implicit checks { for new mail be done by servers as well. The server should send { an unsolicited EXISTS response prior to returning an OK to the | for new mail be done by servers as well. The server must send | a solicited EXISTS response prior to returning an OK to the client. tag EXPUNGE The EXPUNGE command permanently removes all messages with the \DELETED flag set in its flags from the mailbox. Prior to returning an OK to the client, for each message which is removed, { an unsolicited EXPUNGE response is sent indicating which | a solicited EXPUNGE response is sent indicating which message was removed. The message number of each subsequent message in the mailbox is immediately decremented by 1; this means that if the last 5 messages in a 9-message mail file are expunged { you will receive 5 "* 5 EXPUNGE" responses. To ensure mailbox | you will receive 5 "5 EXPUNGE" responses. To ensure mailbox integrity and server/client synchronization, it is recommended that the server do an implicit check prior to commencing the expunge and again when the expunge is completed. Furthermore, if the server allows multiple simultaneous access to the same mail file the server must lock the mail file for exclusive access while an expunge is taking place. EXPUNGE is not allowed if the user does not have write access to { this mailbox. | this mailbox. If a user does not have write access to the mailbox | then the server is required to signal this fact by replying with a | NO response with a suitable text string that can be presented to the | user explaining that the mailbox is read-only. It is further | recommended that servers send an unsolicited READONLY message | to clients that attempt an expunge operation on a read only mailbox. tag COPY sequence mailbox The COPY command copies the specified message(s) to the specified destination mailbox. If the destination mailbox does not exist, the server should create it. Prior to returning an OK to the { client, the server should return an unsolicited COPY response { for each message copied. A copy should set the \SEEN flag for all { messages which were successfully copied (provided, of course, that { the user has write access to this mailbox). | client, the server must return a solicited COPY response | for each message copied. EXAMPLE: A003 COPY 2:4 MEETING copies messages 2, 3, and 4 to mailbox "MEETING". COPY is not allowed if the user does not have write access to the { destination mailbox. | destination mailbox. If a user does not have write access to the | destination mailbox then the server is required to signal this | fact by replying with a NO response with a suitable text string | that can be presented to the user explaining that the mailbox | is read-only. It is further recommended that servers send | an unsolicited READONLY message to clients that attempt to copy | to a read only mailbox. tag FETCH sequence data The FETCH command retrieves data associated with a message in the mailbox. The data items to be fetched may be either a single atom or an S-expression list. The currently defined data items that can be fetched are: ALL Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE) ENVELOPE The envelope of the message. The envelope is computed by the server by parsing the RFC 822 header into the component parts, defaulting various fields as necessary. FAST Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE) FLAGS The flags which are set for this message. This may include the following system flags: \RECENT Message arrived since last read of this mail file \SEEN Message has been read \ANSWERED Message has been answered \FLAGGED Message is "flagged" for urgent/special attention \DELETED Message is "deleted" for removal by later EXPUNGE INTERNALDATE The date and time the message was written to 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 as expressed in RFC 822 format. RFC822.TEXT The text body of the message, omitting the RFC 822 header. EXAMPLES: A003 FETCH 2:4 ALL fetches the flags, internal date, RFC 822 size, and envelope 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 value The STORE command alters data associated with a message in the mailbox. The currently defined data items that can be stored are: FLAGS Replace the flags for the message with the argument (in flag list format). | The server must respond with a solicited STORE FLAGS | message, showing the new state of the flags after | the store. +FLAGS Add the flags in the argument to the message's flag list. | The server must respond with a solicited STORE FLAGS | message, showing the new state of the flags after | the store. -FLAGS Remove the flags in the argument from the message's flag list. | The server must respond with a solicited STORE FLAGS | message, showing the new state of the flags after | the store. | RFC822.HEADER Replace the header of the message(s) with that | specified. This allows users to use their mailboxes | as databases with header fields as keys. | The server must respond with solicited | STORE RFC822.HEADER, STORE RFC822.SIZE and | STORE ENVELOPE messages, showing the new state | of the reparsed header after the store. | | RFC822.TEXT Replace the body of the messages with that specified. | The server must respond with solicited | STORE RFC822.TEXT and STORE RFC822.SIZE messages, | showing the new state of the message after the store. STORE is not allowed if the user does not have write access to this mailbox. EXAMPLE: A003 STORE 2:4 +FLAGS (\DELETED) marks messages 2, 3, and 4 for deletion. tag SEARCH search_criteria { The SEARCH command searches the mailbox for messages which match { the given set of criteria. The unsolicited SEARCH <1#number> { response from the server is a list of messages which express the { intersection (AND function) of all the messages. The currently { defined criteria are: | The SEARCH command searches the mailbox for messages which match | the given set of criteria. The server response SEARCH | (criteria) (numbers) gives the set of messages which | match the conjunction of the criteria specified. In addition to | each of the search criteria there is its logical inverse. | The logical inverse criterion is denoted by the ~ (tilda) sign. | Thus, no message that matches the criterion: | FROM crispin | will match the criterion: | ~FROM crispin | The currently defined search criteria are described below: ALL All messages in the mailbox; the default initial criterion for ANDing. ANSWERED Messages with the \ANSWERED flag set. BCC string Messages which contain the specified string in the envelope's BCC field. BEFORE date Messages whose internal date is earlier than the specified date. BODY string Messages which contain the specified string in the body of the message. CC string Messages which contain the specified string 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 string in the envelope's FROM field. KEYWORD flag Messages with the specified flag set. NEW Messages which have the \RECENT flag set but not the \SEEN flag. This is functionally equivalent to "RECENT UNSEEN". OLD Messages which do not have the \RECENT flag set. ON date Messages whose internal date is the same as 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 than the specified date. SUBJECT string Messages which contain the specified string in the envelope's SUBJECT field. TEXT string Messages which contain the specified string. TO string Messages which contain the specified string in the envelope's TO field. EXAMPLE: A003 SEARCH DELETED FROM "SMITH" SINCE 1-OCT-87 returns the message numbers for all deleted messages from Smith that were placed in the mail file since October 1, 1987. | Implementation note: The UNANSWERED, UNDELETED, UNFLAGGED, | UNKEYWORD and UNSEEN criteria, described below, are preserved in | IMAP3 for IMAP2 compatibility. They are, however, considered | obsolete and new Client programs are encouraged to use the ~ | notation for the logical inverses of search criteria with a | view to the dropping of this outmoded syntax in later versions. UNANSWERED Messages which do not have the \ANSWERED flag set. UNDELETED Messages which do not have the \DELETED flag set. UNFLAGGED Messages which do not have the \FLAGGED flag set. UNKEYWORD flag Messages which do not have the specified flag set. UNSEEN Messages which do not have the \SEEN flag set. | tag READONLY | | The READONLY command indicates that the client wishes to make the | mailbox read-only. The server is required to reply with a solicited | READONLY or READWRITE response. | | tag READWRITE | | The READWRITE command indicates that the client wishes to make the | mailbox read-write. The server is required to reply with a solicited | READONLY or READWRITE response. | | tag SUPPORTEDVERSIONS | The SUPPORTEDVERSIONS solicits from the server a SUPPORTEDVERSIONS | message, which encapsulates information about which versions and | features the server supports. | | tag VERSION real_number features | | The VERSION command indicates that the client wishes to select | certain behavior on the part of the server. The real number | indicates the version number of the IMAP spec that the client | requests. The features allows the client to select certain named | experimental or site specific behavior by name. | | EXAMPLE: A002 VERSION 3.0 EIGHT-BIT-TRANSPARENT NO-RANDOM-LOSSES | | A client may not request a server version or feature that is not | supported by the server. An attempt to do so by a client will | result in a NO response from the server. A client may interrogate | the server to allow the selection of the best version and features | for its own purposes by the use of the SUPPORTEDVERSIONS command. | If the server supports EIGHT-BIT-TRANSPARENT (eight bit characters) and | the NO-RANDOM-LOSSES feature, and has the default features | ENVELOPE-SIZE and TAGGED-SOLICITED then it will respond as follows: | | A002 VERSION 3.0 ENVELOPE-SIZE NO-RANDOM-LOSSES TAGGED-SOLICITED | EIGHT-BIT-TRANSPARENT | | i.e. with at least the version selected and the set of features | requested, and optionally the set of default features as well. | Note: These are only example feature names and are not necessarily | supported by any server. See the appendix on features for more | information on features. | | tag BBOARD bboard | | The BBOARD command is equivalent to SELECT, except that its argument | is a bulletin board (BBoard) name. The format of a BBoard name | is implementation specific, although it is strongly encouraged | to use something that resembles a name in a generic sense and | not a file or mailbox name on the particular system. There is | no requirement that a BBoard name be a mailbox name or a | file name (in particular, Unix netnews has a completely | different namespace from mailbox or file names). | | The result from the BBOARD command is identical from that of the | SELECT command. For example, in the TOPS-20 server implementation, | the command | A0002 BBOARD FOO | is exactly equivalent to the command | A0002 SELECT POBOX:FOO.TXT | Note: the equivalence in this example is *not* required by the | protocol, and merely reflects the fuzzy distinction between mailboxes | and BBoards on TOPS-20. | | tag FIND (BBOARDS / MAILBOXES) pattern | The FIND command accepts as arguments the keywords BBOARDS or | MAILBOXES and a pattern which specifies some set of BBoard/mailbox | names which are usable by the BBOARD/SELECT command. Two wildcard | characters are defined; "*" specifies that any number (including zero) | characters may match at this position and "%" specifies that a | single character may match at this position. For example, FOO*BAR | will match FOOBAR, FOOD.ON.THE.BAR and FOO.BAR, whereas FOO%BAR | will match only FOO.BAR; furthermore, "*" will match all | BBoards/mailboxes. The following quoting convention applies to | wildcards: "\*" is the literal "*" character, "\%" is the literal | "%" character and "\\" is the literal "\" character. | Notes: The format of mailboxes is server implementation dependent. | The special mailbox name INBOX is not included in the output to | the FIND MAILBOXES command. | | The FIND command solicits any number of BBOARD or MAILBOX responses | from the server as appropriate. | Examples: | A0002 FIND BBOARDS * | A0002 BBOARD FOOBAR | A0002 BBOARD GENERAL | A0002 OK FIND completed | or | A0002 FIND MAILBOXES FOO%BA* | A0002 MAILBOX FOO.BAR | A0002 MAILBOX FOO.BAZZAR | A0002 OK FIND completed | Note: Although the use of explict file or path names for mailboxes | is discouraged by this standard, it may be unavoidable. It is | important that the value returned in the MAILBOX solicited | reply be usable in the SELECT command without remembering any | path specification which may have been used in the FIND MAILBOXES | pattern. Responses: { tag OK text { { This response identifies successful completion of the command with { the indicated tag. The text is a line of human-readable text { which may be useful in a protocol telemetry log for debugging { purposes. { { tag NO text { { This response identifies unsuccessful completion of the command { with the indicated tag. The text is a line of human-readable text { which probably should be displayed to the user in an error report { by the client. { { tag BAD text { { This response indicates faulty protocol received from the client { 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 of { a bug report to the maintainer of the client. | */tag OK text | | In its solicited form this response identifies successful | completion of the command with the indicated tag. The text is | a line of human-readable text which may be useful in a protocol | telemetry log for debugging purposes. | | In its unsolicited form, this response indicates simply that | the server is alive. No special action on the part of the client | is called for. This is presently only used by servers at startup | as a greeting message indicating that they are ready to accept | the first command. The text is a line of human-readable text | which may be logged in protocol telemetry. | | */tag NO text | | In its solicited form this response identifies unsuccessful | completion of the command with the indicated tag. The text is | a line of human-readable text which probably should be displayed | to the user in an error report by the client. | | In its unsolicited form this response indicates some operational | error at the server which cannot be traced to any protocol command. | The text is a line of human-readable text which should be logged | in protocol telemetry for the maintainer of the server and/or | the client. | | */tag BAD text | | In its solicited form response indicates faulty protocol received | from the client 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 of a bug report to the maintainer of the client. | | In its unsolicited form response indicates some protocol error at | the server which cannot be traced to any protocol command. | The text is a line of human-readable text which should be | logged in protocol telemetry for the maintainer of the server | and/or the client. This generally indicates a protocol | synchronization problem on the part of the client, and examination | of the protocol telemetry is advised to determine the cause of | the problem. | | */tag BYE text | | This indicates that the server is about to close the connection. | The text is a line of human-readable text which should be displayed | to the user in a status report by the client. | The server is requited to emit a solicited BYE response as part | of a normal logout sequence, and it may also be sent in unsolicited | form as a panic shutdown announcement by the server. It is required | to be used by any server which performs autologouts due to inactivity. { * number message_data | */tag number message_data { This response occurs as a result of several different commands. { The message_data is one of the following: | The solicited (tag number message_data) response is generated as | the result of a number of client requests. The server may also | emit any the following at any time as unsolicited data | (i.e. * number message_data). The message_data is one of the | following: EXISTS The specified number of messages exists in the mailbox. RECENT The specified number of messages have arrived since the | last time this mailbox was selected with the SELECT command | or equivalent. EXPUNGE The specified message number has been permanently removed from the mailbox, and the next message in the mailbox (if any) becomes that message number. | The server must send a solicited EXPUNGE response | for each message that it expunges as the result | of an EXPUNGE command. STORE data { Functionally equivalent to FETCH, only it happens as a { result of a STORE command. | Functionally equivalent to FETCH, only it is sent by the | server when the state of a mailbox changes. The server | must send a solicited STORE response as the result of | a STORE command. FETCH data { This is the principle means by which data about a { message is returned to the client. The data is in a { Lisp-like S-expression property list form. The current { properties are: | This is the principle means by which data about a | message is sent to the client. The data is in a | Lisp-like S-expression property list form. Note that | The server may use the FETCH data type when the state | of the messages in question have not changed. If a change | to the state of the messages, e.g. a flag has changed, the | STORE response type must be used. The current properties are: ENVELOPE An S-expression format list which describes the envelope of a message. The envelope is computed by the server by parsing the RFC 822 header into the component parts, defaulting various fields as necessary. The fields of the envelope are in the following 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 are strings. The from, sender, reply-to, to, cc, and bcc fields are lists of addresses. An address is an S-expression format list which describes an electronic mail address. The fields of an address are in the following order: personal name, source-route (a.k.a. the at-domain-list in SMTP), mailbox name, and host name. Any field of an envelope or address which is not applicable is presented as the atom NIL. Note that the server must default the reply-to and sender fields from the from field; a client is not expected to know to do this. FLAGS An S-expression format list of flags which are set for this message. This may include the following system flags: \RECENT Message arrived since last read of this mail file \SEEN Message has been read \ANSWERED Message has been answered \FLAGGED Message is "flagged" for urgent/special attention \DELETED Message is "deleted" for removal by later EXPUNGE INTERNALDATE A string containing the date and time the message was written to the mailbox. RFC822 A string expressing the message in RFC 822 format. | Note: Some implementations of IMAP2 servers | had the (undocumented) behavior of setting | the \SEEN flag as a side effect of fetching | the body of a message. This resulted in | erroneous behavior for clients that prefetch | messages that the user might not get | around to reading. Thus, this behavior is | explicitly disallowed in IMAP3. RFC822.HEADER A string expressing the RFC 822 format header of the message RFC822.SIZE A number indicating the number of characters in the message as expressed in RFC 822 format. RFC822.TEXT A string expressing the text body of the message, omitting the RFC 822 header. | See also note for RFC822. { * FLAGS flag_list { { This response occurs as a result of a SELECT command. The flag { list are the list of flags (at a minimum, the system-defined { flags) which are applicable for this mailbox. Flags other than { the system flags are a function of the server implementation. | */tag FLAGS flag_list | | A solicited FLAGS response must occur as a result of a SELECT command. | The flag list is the list of flags (at a minimum, the system-defined | flags) which are applicable for this mailbox. Flags other than | the system flags are a function of the server implementation. { * SEARCH number(s) { { This response occurs as a result of a SEARCH command. The { number(s) refer those messages which match the search criteria. { Each number is delimited by a space, e.g., "SEARCH 2 3 6". | */tag SEARCH (numbers) (search_criteria) | | This response occurs as a result of a SEARCH command. The | number(s) refer to those messages which match the search criteria. | In its solicited form this message allows clients to find interesting | groups of messages, e.g. unseen messages from Crispin. In its | unsolicited form it allows the server to inform the client of interesting | patterns, e.g. when new mail arrives, recent and from Crispin. | Compatibility note: The search_criteria are sent by the server | along with the matching numbers so unsolicited SEARCH messages may | be interpretted. This syntax is not upwards compatible with IMAP2 | and so the new syntax is intended to make it simple for clients that | are not able to take advantage of unsolicited SEARCH messages still | to interpret solicited SEARCH messages simply by ignoring everything | that follows the list of numbers with minimal parsing. Such clients | may not, however, simply discard the rest of the line because there | might be LITERALs in the search pattern. | Examples: | A00042 SEARCH (2 3 6) (FROM Crispin ~SEEN) | and | * SEARCH (42) (FROM Crispin RECENT) | The syntax "*/tag SEARCH (numbers) (search_criteria)" is specified for | all servers running IMAP versions greater than 2.0, i.e. the default | behavior of an IMAP server will be the IMAP2 syntax "* SEARCH numbers". | | */tag READONLY | This indicates that the mailbox has become/is read-only. The server | is required to respond to a READONLY or READWRITE command with | either a solicited READONLY or a solicited READWRITE response. | | */tag READWRITE | This indicates that the mailbox has become/is read-write. The server | is required to respond to a READONLY or READWRITE command with | either a solicited READONLY or a solicited READWRITE response. | | */tag BBOARD bboard_name | | This message is produced in its solicited form as a response to | a FIND BBOARDS command. In its unsolicited form it represents a | notification by the server that a new BBoard has been added. | Bboard_name must be a name that can be supplied to the BBOARD | command so as to select the appropriate bboard. | | */tag MAILBOX non_inbox_mailbox_name | | This message is produced in its solicited form as a response to | a FIND MAILBOXES command. In its unsolicited form it represents a | notification by the server that a new mailbox has been added, perhaps | as the result of a COPY command creating a new mailbox. | Non_inbox_mailbox_name must be a name that can be supplied | to the SELECT command so as to select the appropriate mailbox. | Note: non_inbox_mailbox_name is never the string "INBOX". | | */tag SUPPORTEDVERSIONS (version_specs) | | This message is used either as a response to the SUPPORTEDVERSIONS | or, in its unsolicited form, to indicate the dynamic addition or | removal of support for features or server versions. Each version_spec | is of the form (4.2 EIGHT-BIT-TRANSPARENT NO-RANDOM-LOSSES ...), | i.e. a version number for the server and the set of features | supported under that server version. | A server may not dynamically remove support for any version or | feature that has been selected by any currently logged in client | by the use of the VERSION command. | | Example: | A00005 SUPPORTEDVERSIONS ((2.0 ) | (2.2 TAGGED-SOLICITED ~TAGGED-SOLICITED) | (3.0 EIGHT-BIT-TRANSPARENT ~EIGHT-BIT-TRANSPARENT | TAGGED-SOLICITED ~TAGGED-SOLICITED)) | Indicates that two major versions are supported and one minor version | is supported and that tagged solicited messages are supported after | version 2.2 with eight bit characters being supported under | version 3. | Note: These are only example feature names and are not necessarily | supported by any server. See the appendix on features for more | information on features. { * BYE text { { This response indicates that the server is about to close the { connection. The text is a line of human-readable text which { 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 a { panic shutdown announcement by the server. It is also used by { some servers as an announcement of an inactivity autologout. { * OK text { { This response indicates that the server is alive. No special { action on the part of the client is called for. This is presently { only used by servers at startup as a greeting message indicating { that they are ready to accept the first command. The text is a { line of human-readable text which may be logged in protocol { telemetry. { * NO text { { This response indicates some operational error at the server which { cannot be traced to any protocol command. The text is a line of { human-readable text which should be logged in protocol telemetry { for the maintainer of the server and/or the client. No known { server currently outputs such a response. { * BAD text { { This response indicates some protocol error at the server which { cannot be traced to any protocol command. The text is a line of { human-readable text which should be logged in protocol telemetry { for the maintainer of the server and/or the client. This { generally indicates a protocol synchronization problem on the part { of the client, and examination of the protocol telemetry is { advised to determine the cause of the problem. | tag VERSION real_number features | This response indicates that the version of the server indicated | by real_number has been selected successfully. The features list | indicates the list of additional features that have been selected. | The features list must contain all features successfully selected | that were requested by a VERSION command and may also contain | any default features about which the server may wish to inform | the client. | Note: This message type must always be solicited. The protocol | does not allow for the server imposing behavior in clients, since | there is no allowance in the protocol for the client sending NO | or BAD messages to the server. + text This response indicates that the server is ready to accept the text of a literal from the client. Normally, a command from the client is a single text line. If the server detects an error in the command, it can simply discard the remainder of the line. It cannot do this in the case of commands which contain literals, since a literal can be an arbitrarily long amount of text, and the server may not even be expecting a literal. This mechanism is provided so the client knows not to send a literal until the server definitely expects it, preserving client/server synchronization. { In actual practice, this situation is rarely encountered. In the { current protocol, the only client command likely to contain a { literal is the LOGIN command. Consider a situation in which a { server validates the user before checking the password. If the { password contains "funny" characters and hence is sent as a { literal, then if the user is invalid an error would occur before { the password is parsed. | In actual practice, this situation is rarely encountered. In the | current protocol, the only client commands likely to contain | literals are the LOGIN command and the STORE RFC822.HEADER | or STORE RFC822.TEXT commands. Consider a situation in which a | server validates the user before checking the password. If the | password contains "funny" characters and hence is sent as a | literal, then if the user is invalid an error would occur before | the password is parsed. No such synchronization protection is provided for literals sent from the server to the client, for performance reasons. Any synchronization problems in this direction would be due to a bug in the client or server and not for some operational problem. Sample IMAP3 session The following is a transcript of an actual IMAP3 session. Server output is identified by "S:" and client output by "U:". In cases where lines were too long to fit within the boundaries of this document, the line was continued on the next line preceded by a tab. { S: * OK SUMEX-AIM.Stanford.EDU Interim Mail Access Protocol II { Service 6.1(349) at Thu, 9 Jun 88 14:58:30 PDT { U: a001 login crispin secret { S: a002 OK User CRISPIN logged in at Thu, 9 Jun 88 14:58:42 PDT, { job 76 { U: a002 select inbox { S: * FLAGS (Bugs SF Party Skating Meeting Flames Request AI { Question Note \XXXX \YYYY \Answered \Flagged \Deleted { \Seen) { S: * 16 EXISTS { S: * 0 RECENT { S: a002 OK Select complete { U: a003 fetch 16 all { 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 NIL { "<12403828905.13.FAGAN@SUMEX-AIM.Stanford.EDU>")) { S: a003 OK Fetch completed { 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 PDT { S: From: Larry Fagan { S: To: rindflEISCH@SUMEX-AIM.Stanford.EDU { S: Subject: INFO-MAC Mail Message { S: Message-ID: <12403828905.13.FAGAN@SUMEX-AIM.Stanford.EDU> { S: ReSent-Date: Thu, 9 Jun 88 12:55:43 PDT { S: ReSent-From: TC Rindfleisch { S: ReSent-To: Yeager@SUMEX-AIM.Stanford.EDU, { Crispin@SUMEX-AIM.Stanford.EDU { S: ReSent-Message-ID: { <12405133897.80.RINDFLEISCH@SUMEX-AIM.Stanford.EDU> { S: { S: The file is usenetv4-55.arc ... { S: Larry { S: ------- { S: ) { S: a004 OK Fetch completed { U: a005 logout { S: * BYE DEC-20 IMAP II server terminating connection { S: a005 OK SUMEX-AIM.Stanford.EDU Interim Mail Access Protocol { Service logout | S: * OK SUMEX-AIM.Stanford.EDU Interactive Mail Access Protocol III | Service 6.1(349) at Mon, 14 May 90 14:58:30 PDT | U: a001 SUPPORTEDVERSIONS | S: * SUPPORTEDVERSIONS ((2.0 ) (3.0 EIGHT-BIT-TRANSPARENT | ~EIGHT-BIT-TRANSPARENT AUTO-SET-SEEN | ~AUTO-SET-SEEN TAGGED-SOLICITED ~TAGGED-SOLICITED)) | S: A001 Supported Versions returned. | U: a002 VERSION 3.0 TAGGED-SOLICITED | S: a002 VERSION 3.0 TAGGED-SOLICITED | S: a002 OK Version 3.0 Selected. | U: a003 login crispin secret | S: a003 OK User CRISPIN logged in at Thu, 9 Jun 90 14:58:42 PDT, | job 76 | U: a004 select inbox | S: a004 FLAGS (Bugs SF Party Skating Meeting Flames Request AI | Question Note \XXXX \YYYY \Answered \Flagged \Deleted | \Seen) | S: a004 16 EXISTS | S: a004 0 RECENT | S: a005 OK Select complete | U: a005 fetch 16 all | S: a005 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 NIL | "<12403828905.13.FAGAN@SUMEX-AIM.Stanford.EDU>")) | S: a005 OK Fetch completed | U: a006 fetch 16 rfc822 | S: a006 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 PDT | S: From: Larry Fagan | S: To: rindflEISCH@SUMEX-AIM.Stanford.EDU | S: Subject: INFO-MAC Mail Message | S: Message-ID: <12403828905.13.FAGAN@SUMEX-AIM.Stanford.EDU> | S: ReSent-Date: Thu, 9 Jun 88 12:55:43 PDT | S: ReSent-From: TC Rindfleisch | S: ReSent-To: Yeager@SUMEX-AIM.Stanford.EDU, | Crispin@SUMEX-AIM.Stanford.EDU | S: ReSent-Message-ID: | <12405133897.80.RINDFLEISCH@SUMEX-AIM.Stanford.EDU> | S: | S: The file is usenetv4-55.arc ... | S: Larry | S: ------- | S: ) | S: a006 OK Fetch completed | U: a007 logout | S: a007 BYE UNIX IMAP III server terminating connection | S: a007 OK SUMEX-AIM.Stanford.EDU Interim Mail Access Protocol | Service logout Implementation Discussion As of this writing, SUMEX has completed an IMAP2 client for Xerox { Lisp machines written in hybrid Interlisp/CommonLisp and is beta- { testing a client for TI Explorers written entirely in CommonLisp. | Lisp machines written in hybrid Interlisp/CommonLisp and is beginning | distribution of a client for TI Explorers. SUMEX has also completed a portable IMAP3 client protocol library module written in C. This library, with the addition of a small main program (primarily user interface) and a TCP/IP driver, became a rudimentary remote system mail-reading program under Unix. The first { production use of this library will be as a part of a MacII client { which is under development. | production use of this library is as a part of a MacII client | which has now been under daily use (by real users) at Stanford for | quite some time. As of this writing, SUMEX has completed IMAP3 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 standard TOPS-20 mailsystem, and requires no special action or setup on the 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 the same mailbox, including simultaneous access between the IMAP3 server and MM-20. The 4.2/3 BSD Unix server requires that the user use { mail.txt format which is compatible only with SRI MM-32 or Columbia { MM-C. The 4.2/3 BSD Unix server only allows simultaneous read { access; write access must be exclusive. | either Unix Mail format or mail.txt format which is compatible | with SRI MM-32 or Columbia MM-C. The 4.2/3 BSD Unix server allows | simultaneous read access; write access must be exclusive. | There ia also an experimental IMAP3 server running on the TI Explorer | class of machine, which uses MM file format and which can communicate | over both TCP and Chaos. { The Xerox Lisp client and DEC-20 server have been in production use { for over a year; the Unix server was put into production use a few { months ago. IMAP3 has been used to access mailboxes at remote sites | The Xerox Lisp client and DEC-20 server have been in production use | for over two years; the Unix server was been in production use for | over a year. IMAP3 has been used to access mailboxes at remote sites from a local workstation via the Internet. For example, from the { Stanford local network the author has read his mailbox at a Milnet { site. | Stanford local network one of the authors has read his mailbox | at a Milnet site. | A number of IMAP clients have now been developed. Amongst these are | versions that run on the following machines: | . Xerox Lisp machines | . Apple Macintosh | . NeXT | . IBM PC | . TI Explorer Lisp machines | . "Glass teletype" version that runs under Unix | Each of these client programs is carfully tuned to optimize the | performance and user interface in a manner that is consistent with the | the user interface model of the native machine. For example, the | Macintosh client features a "messy-desk" interface that allows the | cutting and pasting of text with the use of the clipboard with a | menu driven interface with keyboard accelerators. This specification does not make any formal definition of size { restrictions, but the DEC-20 server has the following limitations: | restrictions, but the existing servers have the following limitations: | DEC-20 . 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 | !!!!!! Bill can you fill these numbers in???? | Unix | . length of a mailbox: ???? characters | . maximum number of messages: ???? messages | . length of a command line: ???? characters | . length of the local host name: ???? characters | . length of a "short" argument: ???? characters | . length of a "long" argument: ???? characters | . maximum amount of data output in a single fetch: | ???? characters | TI-Explorer | . length of a mailbox: limited by the Minimum of the size of the | virtual address space and the size of the file system | . maximum number of messages: limited by the the size of the | virtual address space | . length of a command line: limited by the the size of the | virtual address space | . length of the local host name: limited by the the size of the | virtual address space | . length of a "short" argument: limited by the the size of the | virtual address space | . length of a "long" argument: limited by the the size of the | virtual address space | . maximum amount of data output in a single fetch: not limited | Typical values for these limits are 30Mb for file systems and 128Mb | for virtual address space. To date, nobody has run up against any of these limitations, many of which are substantially larger than most current user mail reading programs. { There are several advantages to the scheme of tags and unsolicited { responses. First, the infamous synchronization problems of SMTP and { 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. | There are several advantages to the scheme of tags and solicited | responses and unsolicited data. First, the infamous synchronization | problems of SMTP and similar protocols do not happen with tagged | commands; a command is not considered satisfied until a completion | acknowledgement with the same tag is seen. Tagging allows an arbitrary | amount of other responses ("solicited" 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 which would signal the { client when the tagged response comes in. Under certain { circumstances, the client could even have more than one command { outstanding. | client when the tagged response comes in. Some clients might be | implemented in a thoroughly asynchronous manner, having, perhape, | multiple outstanding commands at any given time. Note: this does not | require that the server process these commands in anything other than | a lock-step manner. It simply allows clients to take advantage of | servers that are able to do such asynchronous operations. 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 relatively rare; a mechanism (the special "+" tag response) was introduced to handle those few cases which could happen. The proper way to address this problem in all cases is probably to move towards a record-oriented architecture instead of the text stream model provided by TCP. Unsolicited data needs some discussion. Unlike most protocols, in which the server merely does the client's bidding, an IMAP3 server has a semi-autonomous role. By means of sending "unsolicited data", the server is in effect sending a command to the client -- to update and/or extend its (incomplete) model of the mailbox with new { information from the server. In this viewpoint, a "fetch" command is { merely a request to the server to include the desired data in any { other "unsolicited" data the server may send, and a server { acknowledgement to the "fetch" is a statement that all the requested { data has been sent. | information from the server. In this viewpoint, although a "fetch" | command is a request for specific information from the client, the server | is always at liberty to include more than the desired data as | "unsolicited". A server acknowledgement to the "fetch" is a statement | that at least all the requested data has been sent. In terms of implementation, the client may have a local cache of data from the mailbox. This cache is incomplete, 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 which sent the tagged request. | A listener processes all solicited and unsolicited data symmetrically, | and updates the cache based on this data. If a tagged completion response | arrives, the listener unblocks the process which sent the tagged request. | Clearly, given this model it is not stricly necessary to distinguish | most solicited from unsolicited data. Doing so, however, apart from | being clearer, also allows simplistic lock-step client implementations | that extract the specific value of the response to command by trapping | the tagged response. This allows the client not to have to block on | some complex predicate that involves watching to see an update in a | cache cell. { Perhaps as a result of opening a mailbox, unsolicited data from the { 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 of { messages" unsolicited data message the cache would be re-sized (this { is how newly arrived mail is handled). If the client attempts to { access information from the cache, it will encounter empty spots { which 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. | For example, perhaps as a result of opening a mailbox, solicited data | from the server arrives. The first piece of data is the number of | messages. This is used to size the cache; note that, if new mail | arrives, by sending a new "number of messages" unsolicited data message | server will cause the cache to be re-sized. If the client attempts to | access information from the cache, it will encounter empty spots | which will trigger "fetch" requests. The request would be sent, some | solicited 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 very 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 RFC 822 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 bboard_name | | bboard_name ::= string | | bboard_notify ::= "BBOARD" sp bboard_name check ::= "CHECK" copy ::= "COPY" SP sequence SP mailbox | criterion ::= "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" | criteria ::= 1#criterion { data ::= ("FLAGS" SP flag_list / "SEARCH" SP 1#number / | data ::= ("FLAGS" SP flag_list / | search_notify / bboard_notify / mailbox_notify / | supportedversions_notify / "READONLY" / "READWRITE" / "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_length ::= NUMBER 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" | feature ::= ATOM 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" ("BBOARDS" / "MAILBOXES") pattern flag_list ::= ATOM / "(" 1#ATOM ")" literal ::= "{" NUMBER "}" CRLF ASCII-STRING login ::= "LOGIN" SP userid SP password logout ::= "LOGOUT" mailbox ::= "INBOX" / string | mailbox_notify ::= MAILBOX non_inbox_mailbox_name 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 | env_length 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" | non_inbox_mailbox_name ::= string noop ::= "NOOP" | numbers ::= 1#NUMBER password ::= string | pattern ::= string recent_flag ::= "\RECENT" | read_only ::= "READONLY" | | read_write ::= "READWRITE" ready ::= "+" SP text_line request ::= tag SP (noop / login / logout / select / check / { expunge / copy / fetch / store / search) CRLF | expunge / copy / fetch / store / search / version / | supportedversions / bboard / find / read_only / | read_write) 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") | search ::= "SEARCH" SP criteria | search_notify ::= "SEARCH" SP (numbers) SP (criteria) select ::= "SELECT" SP mailbox sequence ::= NUMBER / (NUMBER "," sequence) / (NUMBER ":" sequence) | solicited ::= tag SP (msg_num SP msg_data / data / | solicited_only) CRLF | solicited_only ::= version_notify store ::= "STORE" SP sequence SP store_att store_att ::= ("+FLAGS" SP flag_list / "-FLAGS" SP flag_list / { "FLAGS" SP flag_list) | "FLAGS" SP flag_list / RFC822.TEXT SP string | / RFC822.HEADER SP string) string ::= atom / """" 1*character """" / literal | supportedversions ::= "SUPPORTEDVERSIONS" | supportedversions_notify ::= "SUPPORTEDVERSIONS" "(" 1#version_spec ")" system_flags ::= "\ANSWERED" SP "\FLAGGED" SP "\DELETED" SP "\SEEN" tag ::= atom unsolicited ::= "*" SP (msg_num SP msg_data / data) CRLF userid ::= string | version ::= "VERSION" SP REAL_NUMBER SP 1#feature | version_notify ::= "VERSION" SP REAL_NUMBER SP 1#feature | version_spec ::= "(" REAL_NUMBER SP 1#feature ")" |Appendix: Features. | | In this section we outline the standard features that are | supported by all IMAP3 servers and identify those features | which are recommended or experimental. For each of these | features the default setting is specified. This means that | it is required of any server that supports a given feature | to make the default enabledness of that feature as is specified | below. | It is required that for each feature supported by a server | the inverse feature should also be supported. The inverse | feature name shall always be defined as the feature name | preceeded by the "~" character. Thus, the AUTO-SET-SEEN | feature is disabled by the ~AUTO-SET-SEEN feature. | | | Required Features: | | AUTO-SET-SEEN - When this features is enabled (default is disabled), | the \SEEN flag is set for all appropriate messages as a side | effect of any of the following: | FETCH of RFC822 | FETCH of RFC822.TEXT | COPY | This feature is provided for the use of clients that either | are unable to pipeline their commands effectively and communicate | over high latency connections. | When disabled, the server will not perform any such side effects. | | | TAGGED-SOLICITED - When this feature is enabled (default is ebled), | solicited responses from the server will have the tag specified | by the client. | When this feature is disabled, solicited responses from the | server will have the IMAP2 compatible tag "*", not the | tag specified by the client. | | Recommended Features. | | EIGHT-BIT-TRANSPARENT - When this feature is enabled | (default is disabled), the server allows the transparent | transmission of eight bit characters. When this feature is | disabled, the value of any bit other than the least significant | 7 bits transmitted by the server is unspecified. If this | feature is enabled, the characters that compose all command | keywords specified in the IMAP3 grammar and all feature names | use only their 7 least significant bits. This feature is | provided for the purpose of supporting national character | sets within messages, encoded languages such as Japenese | Kanji characters and also of binary data, such as graphics | and sound. | tag FLAGS | tag SETFLAGS | tag FLAGS | | The FLAGS command solicites a FLAGS response from the server. | | tag SETFLAGS flag_list | | The SETFLAGS defines the user specifiable flags for this | mailbox, i.e. the keywords. If this set does not include | flags formerly sent to the client by the server in a FLAGS | message then this constitutes a request to delete the flag. | Any new flags should be created. This command does not affect | the system defined flags and any system flags that are included | in the flag_list will be ignored. The server must respond | to this command with a solicited FLAGS message. | If the deletion of a flag results in the invalidation of | the flag sets of any messages then the server is required to | send STORE FLAGS messages to the client for each modified | message. request ::= tag SP (noop / login / logout / select / check / { expunge / copy / fetch / store / search) CRLF | expunge / copy / fetch / store / search / version / | supportedversions / bboard / find / read_only / | read_write / flags / set_flags ) CRLF | flags ::= "FLAGS" | set_flags ::= "SETFLAGS" SP flag_list