diff options
| author | Rob Funk <rfunk@funknet.net> | 2004-06-08 03:59:01 +0000 |
|---|---|---|
| committer | Rob Funk <rfunk@funknet.net> | 2004-06-08 03:59:01 +0000 |
| commit | d78b61e3efaea197a6e5b2b72bf2981a9ed69461 (patch) | |
| tree | 1704e13ce5d767d59868a2d5e834cb2e988ed90f /RFC/rfc1730.txt | |
| parent | d9e84e176fe538e110d9612f9832d69846e8d3e7 (diff) | |
| download | fetchmail-d78b61e3efaea197a6e5b2b72bf2981a9ed69461.tar.gz fetchmail-d78b61e3efaea197a6e5b2b72bf2981a9ed69461.tar.bz2 fetchmail-d78b61e3efaea197a6e5b2b72bf2981a9ed69461.zip | |
Add files from ESR's dev directory that weren't under version control
svn path=/trunk/; revision=3881
Diffstat (limited to 'RFC/rfc1730.txt')
| -rw-r--r-- | RFC/rfc1730.txt | 4318 |
1 files changed, 4318 insertions, 0 deletions
diff --git a/RFC/rfc1730.txt b/RFC/rfc1730.txt new file mode 100644 index 00000000..fcf72ad7 --- /dev/null +++ b/RFC/rfc1730.txt @@ -0,0 +1,4318 @@ +
+
+
+
+
+
+Network Working Group M. Crispin
+Request for Comments: 1730 University of Washington
+Category: Standards Track December 1994
+
+
+ INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4
+
+
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+
+Abstract
+
+ The Internet Message Access Protocol, Version 4 (IMAP4) allows a
+ client to access and manipulate electronic mail messages on a server.
+ IMAP4 permits manipulation of remote message folders, called
+ "mailboxes", in a way that is functionally equivalent to local
+ mailboxes. IMAP4 also provides the capability for an offline client
+ to resynchronize with the server (see also [IMAP-DISC]).
+
+ IMAP4 includes operations for creating, deleting, and renaming
+ mailboxes; checking for new messages; permanently removing messages;
+ setting and clearing flags; RFC 822 and MIME parsing; searching; and
+ selective fetching of message attributes, texts, and portions
+ thereof. Messages in IMAP4 are accessed by the use of numbers.
+ These numbers are either message sequence numbers (relative position
+ from 1 to the number of messages in the mailbox) or unique
+ identifiers (immutable, strictly ascending values assigned to each
+ message, but which are not necessarily contiguous).
+
+ IMAP4 supports a single server. A mechanism for supporting multiple
+ IMAP4 servers is discussed in [IMSP].
+
+ IMAP4 does not specify a means of posting mail; this function is
+ handled by a mail transfer protocol such as [SMTP].
+
+ IMAP4 is designed to be upwards compatible from the [IMAP2] protocol.
+ Compatibility issues are discussed in [IMAP-COMPAT].
+
+
+
+
+
+
+Crispin [Page i]
+
+RFC 1730 IMAP4 December 1994
+
+
+
+
+
+Table of Contents
+
+
+
+IMAP4 Protocol Specification ...................................... 1
+1. Organization of this Document ............................. 1
+1.1. How to Read This Document ................................. 1
+1.2. Conventions Used in this Document ......................... 1
+2. Protocol Overview ......................................... 1
+2.1. Link Level ................................................ 1
+2.2. Commands and Responses .................................... 1
+2.2.1. Client Protocol Sender and Server Protocol Receiver ....... 2
+2.2.2. Server Protocol Sender and Client Protocol Receiver ....... 2
+3. State and Flow Diagram .................................... 4
+3.1. Non-Authenticated State ................................... 4
+3.2. Authenticated State ....................................... 4
+3.3. Selected State ............................................ 4
+3.4. Logout State .............................................. 4
+4. Data Formats .............................................. 6
+4.1. Atom ...................................................... 6
+4.2. Number .................................................... 6
+4.3. String .................................................... 6
+4.3.1. 8-bit and Binary Strings .................................. 7
+4.4. Parenthesized List ........................................ 7
+4.5. NIL ....................................................... 7
+5. Operational Considerations ................................ 8
+5.1. Mailbox Naming ............................................ 8
+5.2. Mailbox Size and Message Status Updates ................... 8
+5.3. Response when no Command in Progress ...................... 8
+5.4. Autologout Timer .......................................... 9
+5.5. Multiple Commands in Progress ............................. 9
+6. Client Commands ........................................... 10
+6.1. Client Commands - Any State ............................... 10
+6.1.1. CAPABILITY Command ........................................ 10
+6.1.2. NOOP Command .............................................. 11
+6.1.3. LOGOUT Command ............................................ 11
+6.2. Client Commands - Non-Authenticated State ................. 12
+6.2.1. AUTHENTICATE Command ...................................... 12
+6.2.2. LOGIN Command ............................................. 14
+6.3. Client Commands - Authenticated State ..................... 14
+6.3.1. SELECT Command ............................................ 15
+6.3.2. EXAMINE Command ........................................... 16
+6.3.3. CREATE Command ............................................ 17
+6.3.4. DELETE Command ............................................ 18
+6.3.5. RENAME Command ............................................ 18
+
+
+
+Crispin [Page ii]
+
+RFC 1730 IMAP4 December 1994
+
+
+6.3.6. SUBSCRIBE Command ......................................... 19
+6.3.7. UNSUBSCRIBE Command ....................................... 19
+6.3.8. LIST Command .............................................. 20
+6.3.9. LSUB Command .............................................. 22
+6.3.10. APPEND Command ............................................ 22
+6.4. Client Commands - Selected State .......................... 23
+6.4.1. CHECK Command ............................................. 23
+6.4.2. CLOSE Command ............................................. 24
+6.4.3. EXPUNGE Command ........................................... 25
+6.4.4. SEARCH Command ............................................ 25
+6.4.5. FETCH Command ............................................. 29
+6.4.6. PARTIAL Command ........................................... 32
+6.4.7. STORE Command ............................................. 33
+6.4.8. COPY Command .............................................. 34
+6.4.9. UID Command ............................................... 35
+6.5. Client Commands - Experimental/Expansion .................. 37
+6.5.1. X<atom> Command ........................................... 37
+7. Server Responses .......................................... 38
+7.1. Server Responses - Status Responses ....................... 39
+7.1.1. OK Response ............................................... 40
+7.1.2. NO Response ............................................... 40
+7.1.3. BAD Response .............................................. 41
+7.1.4. PREAUTH Response .......................................... 41
+7.1.5. BYE Response .............................................. 41
+7.2. Server Responses - Server and Mailbox Status .............. 42
+7.2.1. CAPABILITY Response ....................................... 42
+7.2.2. LIST Response ............................................. 43
+7.2.3. LSUB Response ............................................. 44
+7.2.4. SEARCH Response ........................................... 44
+7.2.5. FLAGS Response ............................................ 44
+7.3. Server Responses - Message Status ......................... 45
+7.3.1. EXISTS Response ........................................... 45
+7.3.2. RECENT Response ........................................... 45
+7.3.3. EXPUNGE Response .......................................... 45
+7.3.4. FETCH Response ............................................ 46
+7.3.5. Obsolete Responses ........................................ 51
+7.4. Server Responses - Command Continuation Request ........... 51
+8. Sample IMAP4 session ...................................... 52
+9. Formal Syntax ............................................. 53
+10. Author's Note ............................................. 64
+11. Security Considerations ................................... 64
+12. Author's Address .......................................... 64
+Appendices ........................................................ 65
+A. Obsolete Commands ......................................... 65
+A.6.3.OBS.1. FIND ALL.MAILBOXES Command ........................ 65
+A.6.3.OBS.2. FIND MAILBOXES Command ............................ 65
+A.6.3.OBS.3. SUBSCRIBE MAILBOX Command ......................... 66
+A.6.3.OBS.4. UNSUBSCRIBE MAILBOX Command ....................... 66
+
+
+
+Crispin [Page iii]
+
+RFC 1730 IMAP4 December 1994
+
+
+B. Obsolete Responses ........................................ 68
+B.7.2.OBS.1. MAILBOX Response .................................. 68
+B.7.3.OBS.1. COPY Response ..................................... 68
+B.7.3.OBS.2. STORE Response .................................... 69
+C. References ................................................ 70
+E. IMAP4 Keyword Index ....................................... 71
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin [Page iv]
+
+RFC 1730 IMAP4 December 1994
+
+
+IMAP4 Protocol Specification
+
+1. Organization of this Document
+
+1.1. How to Read This Document
+
+ This document is written from the point of view of the implementor of
+ an IMAP4 client or server. Beyond the protocol overview in section
+ 2, it is not optimized for someone trying to understand the operation
+ of the protocol. The material in sections 3 through 5 provides the
+ general context and definitions with which IMAP4 operates.
+
+ Sections 6, 7, and 9 describe the IMAP commands, responses, and
+ syntax, respectively. The relationships among these are such that it
+ is almost impossible to understand any of them separately. In
+ particular, one should not attempt to deduce command syntax from the
+ command section alone; one should instead refer to the formal syntax
+ section.
+
+
+1.2. Conventions Used in this Document
+
+ In examples, "C:" and "S:" indicate lines sent by the client and
+ server respectively.
+
+
+2. Protocol Overview
+
+2.1. Link Level
+
+ The IMAP4 protocol assumes a reliable data stream such as provided by
+ TCP. When TCP is used, an IMAP4 server listens on port 143.
+
+
+2.2. Commands and Responses
+
+ An IMAP4 session consists of the establishment of a client/server
+ connection, an initial greeting from the server, and client/server
+ interactions. These client/server interactions consist of a client
+ command, server data, and a server completion result response.
+
+ All interactions transmitted by client and server are in the form of
+ lines; that is, strings that end with a CRLF. The protocol receiver
+ of an IMAP4 client or server is either reading a line, or is reading
+ a sequence of octets with a known count followed by a line.
+
+
+
+
+
+
+Crispin [Page 1]
+
+RFC 1730 IMAP4 December 1994
+
+
+2.2.1. Client Protocol Sender and Server Protocol Receiver
+
+ The client command begins an operation. Each client command is
+ prefixed with a identifier (typically a short alphanumeric string,
+ e.g. A0001, A0002, etc.) called a "tag". A different tag is
+ generated by the client for each command.
+
+ There are two cases in which a line from the client does not
+ represent a complete command. In one case, a command argument is
+ quoted with an octet count (see the description of literal in String
+ under Data Formats); in the other case, the command arguments require
+ server feedback (see the AUTHENTICATE command). In either case, the
+ server sends a command continuation request response if it is ready
+ for the octets (if appropriate) and the remainder of the command.
+ This response is prefixed with the token "+".
+
+ Note: If, instead, the server detected an error in the
+ command, it sends a BAD completion response with tag
+ matching the command (as described below) to reject the
+ command and prevent the client from sending any more of the
+ command.
+
+ It is also possible for the server to send a completion
+ response for some other command (if multiple commands are
+ in progress), or untagged data. In either case, the
+ command continuation request is still pending; the client
+ takes the appropriate action for the response, and reads
+ another response from the server.
+
+ The protocol receiver of an IMAP4 server reads a command line from
+ the client, parses the command and its arguments, and transmits
+ server data and a server command completion result response.
+
+
+2.2.2. Server Protocol Sender and Client Protocol Receiver
+
+ Data transmitted by the server to the client and status responses
+ that do not indicate command completion are prefixed with the token
+ "*", and are called untagged responses.
+
+ Server data may be sent as a result of a client command, or may be
+ sent unilaterally by the server. There is no syntactic difference
+ between server data that resulted from a specific command and server
+ data that were sent unilaterally.
+
+ The server completion result response indicates the success or
+ failure of the operation. It is tagged with the same tag as the
+ client command which began the operation. Thus, if more than one
+
+
+
+Crispin [Page 2]
+
+RFC 1730 IMAP4 December 1994
+
+
+ command is in progress, the tag in a server completion response
+ identifies the command to which the response applies. There are
+ three possible server completion responses: OK (indicating success),
+ NO (indicating failure), or BAD (indicating protocol error such as
+ unrecognized command or command syntax error).
+
+ The protocol receiver of an IMAP4 client reads a response line from
+ the server. It then takes action on the response based upon the
+ first token of the response, which may be a tag, a "*", or a "+". As
+ described above.
+
+ A client MUST be prepared to accept any server response at all times.
+ This includes server data that it may not have requested. Server
+ data SHOULD be recorded, so that the client can reference its
+ recorded copy rather than sending a command to the server to request
+ the data. In the case of certain server data, recording the data is
+ mandatory.
+
+ This topic is discussed in greater detail in the Server Responses
+ section.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin [Page 3]
+
+RFC 1730 IMAP4 December 1994
+
+
+3. State and Flow Diagram
+
+ An IMAP4 server is in one of four states. Most commands are valid in
+ only certain states. It is a protocol error for the client to
+ attempt a command while the command is in an inappropriate state. In
+ this case, a server will respond with a BAD or NO (depending upon
+ server implementation) command completion result.
+
+
+3.1. Non-Authenticated State
+
+ In non-authenticated state, the user must supply authentication
+ credentials before most commands will be permitted. This state is
+ entered when a connection starts unless the connection has been
+ pre-authenticated.
+
+
+3.2. Authenticated State
+
+ In authenticated state, the user is authenticated and must select a
+ mailbox to access before commands that affect messages will be
+ permitted. This state is entered when a pre-authenticated connection
+ starts, when acceptable authentication credentials have been
+ provided, or after an error in selecting a mailbox.
+
+
+3.3. Selected State
+
+ In selected state, a mailbox has been selected to access. This state
+ is entered when a mailbox has been successfully selected.
+
+
+3.4. Logout State
+
+ In logout state, the session is being terminated, and the server will
+ close the connection. This state can be entered as a result of a
+ client request or by unilateral server decision.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin [Page 4]
+
+RFC 1730 IMAP4 December 1994
+
+
+ +--------------------------------------+
+ |initial connection and server greeting|
+ +--------------------------------------+
+ || (1) || (2) || (3)
+ VV || ||
+ +-----------------+ || ||
+ |non-authenticated| || ||
+ +-----------------+ || ||
+ || (7) || (4) || ||
+ || VV VV ||
+ || +----------------+ ||
+ || | authenticated |<=++ ||
+ || +----------------+ || ||
+ || || (7) || (5) || (6) ||
+ || || VV || ||
+ || || +--------+ || ||
+ || || |selected|==++ ||
+ || || +--------+ ||
+ || || || (7) ||
+ VV VV VV VV
+ +--------------------------------------+
+ | logout and close connection |
+ +--------------------------------------+
+
+ (1) connection without pre-authentication (OK greeting)
+ (2) pre-authenticated connection (PREAUTH greeting)
+ (3) rejected connection (BYE greeting)
+ (4) successful LOGIN or AUTHENTICATE command
+ (5) successful SELECT or EXAMINE command
+ (6) CLOSE command, or failed SELECT or EXAMINE command
+ (7) LOGOUT command, server shutdown, or connection closed
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin [Page 5]
+
+RFC 1730 IMAP4 December 1994
+
+
+4. Data Formats
+
+ IMAP4 uses textual commands and responses. Data in IMAP4 can be in
+ one of several forms: atom, number, string, parenthesized list, or
+ NIL.
+
+
+4.1. Atom
+
+ An atom consists of one or more non-special characters.
+
+
+4.2. Number
+
+ A number consists of one or more digit characters, and represents a
+ numeric value.
+
+
+4.3. String
+
+ A string is in one of two forms: literal and quoted string. The
+ literal form is the general form of string. The quoted string form
+ is an alternative that avoids the overhead of processing a literal at
+ the cost of restrictions of what may be in a quoted string.
+
+ A literal is a sequence of zero or more octets (including CR and LF),
+ prefix-quoted with an octet count in the form of an open brace ("{"),
+ the number of octets, close brace ("}"), and CRLF. In the case of
+ literals transmitted from server to client, the CRLF is immediately
+ followed by the octet data. In the case of literals transmitted from
+ client to server, the client must wait to receive a command
+ continuation request (described later in this document) before
+ sending the octet data (and the remainder of the command).
+
+ A quoted string is a sequence of zero or more 7-bit characters,
+ excluding CR and LF, with double quote (<">) characters at each end.
+
+ The empty string is respresented as either "" (a quoted string with
+ zero characters between double quotes) or as {0} followed by CRLF (a
+ literal with an octet count of 0).
+
+ Note: Even if the octet count is 0, a client transmitting a
+ literal must wait to receive a command continuation
+ request.
+
+
+
+
+
+
+
+Crispin [Page 6]
+
+RFC 1730 IMAP4 December 1994
+
+
+4.3.1. 8-bit and Binary Strings
+
+ 8-bit textual and binary mail is supported through the use of
+ [MIME-1] encoding. IMAP4 implementations MAY transmit 8-bit or
+ multi-octet characters in literals, but should do so only when the
+ character set is identified.
+
+ Although a BINARY body encoding is defined, unencoded binary strings
+ are not permitted. A "binary string" is any string with NUL
+ characters. Implementations MUST encode binary data into a textual
+ form such as BASE64 before transmitting the data. A string with an
+ excessive amount of CTL characters may also be considered to be
+ binary, although this is not required.
+
+
+4.4. Parenthesized List
+
+ Data structures are represented as a "parenthesized list"; a sequence
+ of data items, delimited by space, and bounded at each end by
+ parentheses. A parenthesized list may itself contain other
+ parenthesized lists, using multiple levels of parentheses to indicate
+ nesting.
+
+ The empty list is represented as () -- a parenthesized list with no
+ members.
+
+
+4.5. NIL
+
+ The special atom "NIL" represents the non-existence of a particular
+ data item that is represented as a string or parenthesized list, as
+ distinct from the empty string "" or the empty parenthesized list ().
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin [Page 7]
+
+RFC 1730 IMAP4 December 1994
+
+
+5. Operational Considerations
+
+5.1. Mailbox Naming
+
+ The interpretation of mailbox names is implementation-dependent.
+ However, the mailbox name INBOX is a special name reserved to mean
+ "the primary mailbox for this user on this server". If it is desired
+ to export hierarchical mailbox names, mailbox names must be
+ left-to-right hierarchical using a single character to separate
+ levels of hierarchy. The same hierarchy separator character is used
+ for all levels of hierarchy within a single name.
+
+5.2. Mailbox Size and Message Status Updates
+
+ At any time, a server can send data that the client did not request.
+ Sometimes, such behavior is required. For example, agents other than
+ the server may add messages to the mailbox (e.g. new mail delivery),
+ change the flags of message in the mailbox (e.g. simultaneous access
+ to the same mailbox by multiple agents), or even remove messages from
+ the mailbox. A server MUST send mailbox size updates automatically
+ if a mailbox size change is observed during the processing of a
+ command. A server SHOULD send message flag updates automatically,
+ without requiring the client to request such updates explicitly.
+ Special rules exist for server notification of a client about the
+ removal of messages to prevent synchronization errors; see the
+ description of the EXPUNGE response for more details.
+
+ Regardless of what implementation decisions a client may take on
+ remembering data from the server, a client implementation MUST record
+ mailbox size updates. It MUST NOT assume that any command after
+ initial mailbox selection will return the size of the mailbox.
+
+
+5.3. Response when no Command in Progress
+
+ Server implementations are permitted to send an untagged response
+ (except for EXPUNGE) while there is no command in progress. Server
+ implementations that send such responses MUST deal with flow control
+ considerations. Specifically, they must either (1) verify that the
+ size of the data does not exceed the underlying transport's available
+ window size, or (2) use non-blocking writes.
+
+
+
+
+
+
+
+
+
+
+Crispin [Page 8]
+
+RFC 1730 IMAP4 December 1994
+
+
+5.4. Autologout Timer
+
+ If a server has an inactivity autologout timer, that timer MUST be of
+ at least 30 minutes' duration. The receipt of ANY command from the
+ client during that interval should suffice to reset the autologout
+ timer.
+
+
+5.5. Multiple Commands in Progress
+
+ The client is not required to wait for the completion result response
+ of a command before sending another command, subject to flow control
+ constraints on the underlying data stream. Similarly, a server is
+ not required to process a command to completion before beginning
+ processing of the next command, unless an ambiguity would result
+ because of a command that would affect the results of other commands.
+ If there is such an ambiguity, the server executes commands to
+ completion in the order given by the client.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin [Page 9]
+
+RFC 1730 IMAP4 December 1994
+
+
+6. Client Commands
+
+ IMAP4 commands are described in this section. Commands are organized
+ by the state in which the command is permitted. Commands which are
+ permitted in multiple states are listed in the minimum permitted
+ state (for example, commands valid in authenticated and selected
+ state are listed in the authenticated state commands).
+
+ Command arguments, identified by "Arguments:" in the command
+ descriptions below, are described by function, not by syntax. The
+ precise syntax of command arguments is described in the Formal Syntax
+ section.
+
+ Some commands cause specific server data to be returned; these are
+ identified by "Data:" in the command descriptions below. See the
+ response descriptions in the Responses section for information on
+ these responses, and the Formal Syntax section for the precise syntax
+ of these responses. It is possible for server data to be transmitted
+ as a result of any command; thus, commands that do not specifically
+ require server data specify "no specific data for this command"
+ instead of "none".
+
+ The "Result:" in the command description refers to the possible
+ tagged status responses to a command, and any special interpretation
+ of these status responses.
+
+
+6.1. Client Commands - Any State
+
+ The following commands are valid in any state: CAPABILITY, NOOP, and
+ LOGOUT.
+
+6.1.1. CAPABILITY Command
+
+ Arguments: none
+
+ Data: mandatory untagged response: CAPABILITY
+
+ Result: OK - capability completed
+ BAD - command unknown or arguments invalid
+
+ The CAPABILITY command requests a listing of capabilities that the
+ server supports. The server MUST send a single untagged
+ CAPABILITY response with "IMAP4" as the first listed capability
+ before the (tagged) OK response. This listing of capabilities is
+ not dependent upon connection state or user. It is therefore not
+ necessary to issue a CAPABILITY command more than once in a
+ session.
+
+
+
+Crispin [Page 10]
+
+RFC 1730 IMAP4 December 1994
+
+
+ Capability names other than "IMAP4" refer to extensions,
+ revisions, or amendments to this specification. See the
+ documentation of the CAPABILITY response for additional
+ information. No capabilities are enabled without explicit client
+ action to invoke the capability. See the section entitled "Client
+ Commands - Experimental/Expansion" for information about the form
+ of site or implementation-specific capabilities.
+
+ Example: C: abcd CAPABILITY
+ S: * CAPABILITY IMAP4
+ S: abcd OK CAPABILITY completed
+
+
+6.1.2. NOOP Command
+
+ Arguments: none
+
+ Data: no specific data for this command (but see below)
+
+ Result: OK - noop completed
+ BAD - command unknown or arguments invalid
+
+ The NOOP command always succeeds. It does nothing.
+
+ Since any command can return a status update as untagged data, the
+ NOOP command can be used as a periodic poll for new messages or
+ message status updates during a period of inactivity. The NOOP
+ command can also be used to reset any inactivity autologout timer
+ on the server.
+
+ Example: C: a002 NOOP
+ S: a002 OK NOOP completed
+ . . .
+ C: a047 NOOP
+ S: * 22 EXPUNGE
+ S: * 23 EXISTS
+ S: * 3 RECENT
+ S: * 14 FETCH (FLAGS (\Seen \Deleted))
+ S: a047 OK NOOP completed
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin [Page 11]
+
+RFC 1730 IMAP4 December 1994
+
+
+6.1.3. LOGOUT Command
+
+ Arguments: none
+
+ Data: mandatory untagged response: BYE
+
+ Result: OK - logout completed
+ BAD - command unknown or arguments invalid
+
+ The LOGOUT command informs the server that the client is done with
+ the session. The server must send a BYE untagged response before
+ the (tagged) OK response, and then close the network connection.
+
+ Example: C: A023 LOGOUT
+ S: * BYE IMAP4 Server logging out
+ S: A023 OK LOGOUT completed
+ (Server and client then close the connection)
+
+
+
+6.2. Client Commands - Non-Authenticated State
+
+ In non-authenticated state, the AUTHENTICATE or LOGIN command
+ establishes authentication and enter authenticated state. The
+ AUTHENTICATE command provides a general mechanism for a variety of
+ authentication techniques, whereas the LOGIN command uses the
+ traditional user name and plaintext password pair.
+
+ Server implementations may allow non-authenticated access to certain
+ mailboxes. The convention is to use a LOGIN command with the userid
+ "anonymous". A password is required. It is implementation-dependent
+ what requirements, if any, are placed on the password and what access
+ restrictions are placed on anonymous users.
+
+ Once authenticated (including as anonymous), it is not possible to
+ re-enter non-authenticated state.
+
+ In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
+ the following commands are valid in non-authenticated state:
+ AUTHENTICATE and LOGIN.
+
+
+
+
+
+
+
+
+
+
+
+Crispin [Page 12]
+
+RFC 1730 IMAP4 December 1994
+
+
+6.2.1. AUTHENTICATE Command
+
+ Arguments: authentication mechanism name
+
+ Data: continuation data may be requested
+
+ Result: OK - authenticate completed, now in authenticated state
+ NO - authenticate failure: unsupported authentication
+ mechanism, credentials rejected
+ BAD - command unknown or arguments invalid,
+ authentication exchange cancelled
+
+ The AUTHENTICATE command indicates an authentication mechanism,
+ such as described in [IMAP-AUTH], to the server. If the server
+ supports the requested authentication mechanism, it performs an
+ authentication protocol exchange to authenticate and identify the
+ user. Optionally, it also negotiates a protection mechanism for
+ subsequent protocol interactions. If the requested authentication
+ mechanism is not supported, the server should reject the
+ AUTHENTICATE command by sending a tagged NO response.
+
+ The authentication protocol exchange consists of a series of
+ server challenges and client answers that are specific to the
+ authentication mechanism. A server challenge consists of a
+ command continuation request response with the "+" token followed
+ by a BASE64 encoded string. The client answer consists of a line
+ consisting of a BASE64 encoded string. If the client wishes to
+ cancel an authentication exchange, it should issue a line with a
+ single "*". If the server receives such an answer, it must reject
+ the AUTHENTICATE command by sending a tagged BAD response.
+
+ A protection mechanism provides integrity and privacy protection
+ to the protocol session. If a protection mechanism is negotiated,
+ it is applied to all subsequent data sent over the connection.
+ The protection mechanism takes effect immediately following the
+ CRLF that concludes the authentication exchange for the client,
+ and the CRLF of the tagged OK response for the server. Once the
+ protection mechanism is in effect, the stream of command and
+ response octets is processed into buffers of ciphertext. Each
+ buffer is transferred over the connection as a stream of octets
+ prepended with a four octet field in network byte order that
+ represents the length of the following data. The maximum
+ ciphertext buffer length is defined by the protection mechanism.
+
+ The server is not required to support any particular
+ authentication mechanism, nor are authentication mechanisms
+ required to support any protection mechanisms. If an AUTHENTICATE
+ command fails with a NO response, the client may try another
+
+
+
+Crispin [Page 13]
+
+RFC 1730 IMAP4 December 1994
+
+
+ authentication mechanism by issuing another AUTHENTICATE command,
+ or may attempt to authenticate by using the LOGIN command. In
+ other words, the client may request authentication types in
+ decreasing order of preference, with the LOGIN command as a last
+ resort.
+
+ Example: S: * OK KerberosV4 IMAP4 Server
+ C: A001 AUTHENTICATE KERBEROS_V4
+ S: + AmFYig==
+ C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
+ +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
+ WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
+ S: + or//EoAADZI=
+ C: DiAF5A4gA+oOIALuBkAAmw==
+ S: A001 OK Kerberos V4 authentication successful
+
+ Note: the line breaks in the first client answer are for
+ editorial clarity and are not in real authenticators.
+
+
+6.2.2. LOGIN Command
+
+ Arguments: user name
+ password
+
+ Data: no specific data for this command
+
+ Result: OK - login completed, now in authenticated state
+ NO - login failure: user name or password rejected
+ BAD - command unknown or arguments invalid
+
+ The LOGIN command identifies the user to the server and carries
+ the plaintext password authenticating this user.
+
+ Example: C: a001 LOGIN SMITH SESAME
+ S: a001 OK LOGIN completed
+
+
+
+6.3. Client Commands - Authenticated State
+
+ In authenticated state, commands that manipulate mailboxes as atomic
+ entities are permitted. Of these commands, the SELECT and EXAMINE
+ commands will select a mailbox for access and enter selected state.
+
+
+
+
+
+
+
+Crispin [Page 14]
+
+RFC 1730 IMAP4 December 1994
+
+
+ In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
+ the following commands are valid in authenticated state: SELECT,
+ EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB,
+ and APPEND.
+
+6.3.1. SELECT Command
+
+ Arguments: mailbox name
+
+ Data: mandatory untagged responses: FLAGS, EXISTS, RECENT
+ optional OK untagged responses: UNSEEN, PERMANENTFLAGS
+
+ Result: OK - select completed, now in selected state
+ NO - select failure, now in authenticated state: no
+ such mailbox, can't access mailbox
+ BAD - command unknown or arguments invalid
+
+ The SELECT command selects a mailbox so that messages in the
+ mailbox can be accessed. Before returning an OK to the client,
+ the server MUST send the following untagged data to the client:
+
+ FLAGS Defined flags in the mailbox
+
+ <n> EXISTS The number of messages in the mailbox
+
+ <n> RECENT The number of messages added to the mailbox since
+ the previous time this mailbox was read
+
+ OK [UIDVALIDITY <n>]
+ The unique identifier validity value. See the
+ description of the UID command for more detail.
+
+ to define the initial state of the mailbox at the client. If it
+ is not possible to determine the messages that were added since
+ the previous time a mailbox was read, then all messages SHOULD be
+ considered recent.
+
+ The server SHOULD also send an UNSEEN response code in an OK
+ untagged response, indicating the message sequence number of the
+ first unseen message in the mailbox.
+
+ If the client can not change the permanent state of one or more of
+ the flags listed in the FLAGS untagged response, the server SHOULD
+ send a PERMANENTFLAGS response code in an OK untagged response,
+ listing the flags that the client may change permanently.
+
+ Only one mailbox may be selected at a time in a session;
+ simultaneous access to multiple mailboxes requires multiple
+
+
+
+Crispin [Page 15]
+
+RFC 1730 IMAP4 December 1994
+
+
+ sessions. The SELECT command automatically deselects any
+ currently selected mailbox before attempting the new selection.
+ Consequently, if a mailbox is selected and a SELECT command that
+ fails is attempted, no mailbox is selected.
+
+ If the user is permitted to modify the mailbox, the server SHOULD
+ prefix the text of the tagged OK response with the "[READ-WRITE]"
+ response code.
+
+ If the user is not permitted to modify the mailbox but is
+ permitted read access, the mailbox is selected as read-only, and
+ the server MUST prefix the text of the tagged OK response to
+ SELECT with the "[READ-ONLY]" response code. Read-only access
+ through SELECT differs from the EXAMINE command in that certain
+ read-only mailboxes may permit the change of permanent state on a
+ per-user (as opposed to global) basis. Netnews messages marked in
+ a user's .newsrc file are an example of such per-user permanent
+ state that can be modified with read-only mailboxes.
+
+ Example: C: A142 SELECT INBOX
+ S: * 172 EXISTS
+ S: * 1 RECENT
+ S: * OK [UNSEEN 12] Message 12 is first unseen
+ S: * OK [UIDVALIDITY 3857529045] UIDs valid
+ S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
+ S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
+ S: A142 OK [READ-WRITE] SELECT completed
+
+
+6.3.2. EXAMINE Command
+
+ Arguments: mailbox name
+
+ Data: mandatory untagged responses: FLAGS, EXISTS, RECENT
+ optional OK untagged responses: UNSEEN, PERMANENTFLAGS
+
+ Result: OK - examine completed, now in selected state
+ NO - examine failure, now in authenticated state: no
+ such mailbox, can't access mailbox
+ BAD - command unknown or arguments invalid
+
+ The EXAMINE command is identical to SELECT and returns the same
+ output; however, the selected mailbox is identified as read-only.
+ No changes to the permanent state of the mailbox, including
+ per-user state, are permitted.
+
+
+
+
+
+
+Crispin [Page 16]
+
+RFC 1730 IMAP4 December 1994
+
+
+ The text of the tagged OK response to the EXAMINE command MUST
+ begin with the "[READ-ONLY]" response code.
+
+ Example: C: A932 EXAMINE blurdybloop
+ S: * 17 EXISTS
+ S: * 2 RECENT
+ S: * OK [UNSEEN 8] Message 8 is first unseen
+ S: * OK [UIDVALIDITY 3857529045] UIDs valid
+ S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
+ S: * OK [PERMANENTFLAGS ()] No permanent flags permitted
+ S: A932 OK [READ-ONLY] EXAMINE completed
+
+
+6.3.3. CREATE Command
+
+ Arguments: mailbox name
+
+ Data: no specific data for this command
+
+ Result: OK - create completed
+ NO - create failure: can't create mailbox with that name
+ BAD - command unknown or arguments invalid
+
+ The CREATE command creates a mailbox with the given name. An OK
+ response is returned only if a new mailbox with that name has been
+ created. It is an error to attempt to create INBOX or a mailbox
+ with a name that refers to an extant mailbox. Any error in
+ creation will return a tagged NO response.
+
+ If the mailbox name is suffixed with the server's hierarchy
+ separator character (as returned from the server by a LIST
+ command), this is a declaration that the client may, in the
+ future, create mailbox names under this name in the hierarchy.
+ Server implementations that do not require this declaration MUST
+ ignore it.
+
+ If a new mailbox is created with the same name as a mailbox which
+ was deleted, its unique identifiers MUST be greater than any
+ unique identifiers used in the previous incarnation of the mailbox
+ UNLESS the new incarnation has a different unique identifier
+ validity value. See the description of the UID command for more
+ detail.
+
+ Example: C: A003 CREATE owatagusiam/
+ S: A003 OK CREATE completed
+ C: A004 CREATE owatagusiam/blurdybloop
+ S: A004 OK CREATE completed
+
+
+
+
+Crispin [Page 17]
+
+RFC 1730 IMAP4 December 1994
+
+
+ Note: the interpretation of this example depends on whether
+ "/" was returned as the hierarchy separator from LIST. If
+ "/" is the hierarchy separator, a new level of hierarchy
+ named "owatagusiam" with a member called "blurdybloop" is
+ created. Otherwise, two mailboxes at the same hierarchy
+ level are created.
+
+
+6.3.4. DELETE Command
+
+ Arguments: mailbox name
+
+ Data: no specific data for this command
+
+ Result: OK - delete completed
+ NO - delete failure: can't delete mailbox with that name
+ BAD - command unknown or arguments invalid
+
+ The DELETE command permanently removes the mailbox with the given
+ name. A tagged OK response is returned only if the mailbox has
+ been deleted. It is an error to attempt to delete INBOX or a
+ mailbox name that does not exist. Any error in deletion will
+ return a tagged NO response.
+
+ The value of the highest-used unique indentifier of the deleted
+ mailbox MUST be preserved so that a new mailbox created with the
+ same name will not reuse the identifiers of the former
+ incarnation, UNLESS the new incarnation has a different unique
+ identifier validity value. See the description of the UID command
+ for more detail.
+
+ Example: C: A683 DELETE blurdybloop
+ S: A683 OK DELETE completed
+
+
+6.3.5. RENAME Command
+
+ Arguments: existing mailbox name
+ new mailbox name
+
+ Data: no specific data for this command
+
+ Result: OK - rename completed
+ NO - rename failure: can't rename mailbox with that name,
+ can't rename to mailbox with that name
+ BAD - command unknown or arguments invalid
+
+
+
+
+
+Crispin [Page 18]
+
+RFC 1730 IMAP4 December 1994
+
+
+ The RENAME command changes the name of a mailbox. A tagged OK
+ response is returned only if the mailbox has been renamed. It is
+ an error to attempt to rename from a mailbox name that does not
+ exist or to a mailbox name that already exists. Any error in
+ renaming will return a tagged NO response.
+
+ Renaming INBOX is permitted; a new, empty INBOX is created in its
+ place.
+
+ Example: C: Z4S9 RENAME blurdybloop owatagusiam
+ S: Z4S9 OK RENAME completed
+
+
+6.3.6. SUBSCRIBE Command
+
+ Arguments: mailbox
+
+ Data: no specific data for this command
+
+ Result: OK - subscribe completed
+ NO - subscribe failure: can't subscribe to that name
+ BAD - command unknown or arguments invalid
+
+ The SUBSCRIBE command adds the specified mailbox name to the
+ server's set of "active" or "subscribed" mailboxes as returned by
+ the LSUB command. This command returns a tagged OK response only
+ if the subscription is successful.
+
+ Example: C: A002 SUBSCRIBE #news.comp.mail.mime
+ S: A002 OK SUBSCRIBE completed
+
+
+6.3.7. UNSUBSCRIBE Command
+
+ Arguments: mailbox name
+
+ Data: no specific data for this command
+
+ Result: OK - unsubscribe completed
+ NO - unsubscribe failure: can't unsubscribe that name
+ BAD - command unknown or arguments invalid
+
+ The UNSUBSCRIBE command removes the specified mailbox name from
+ the server's set of "active" or "subscribed" mailboxes as returned
+ by the LSUB command. This command returns a tagged OK response
+ only if the unsubscription is successful.
+
+
+
+
+
+Crispin [Page 19]
+
+RFC 1730 IMAP4 December 1994
+
+
+ Example: C: A002 UNSUBSCRIBE #news.comp.mail.mime
+ S: A002 OK UNSUBSCRIBE completed
+
+
+6.3.8. LIST Command
+
+ Arguments: reference name
+ mailbox name with possible wildcards
+
+ Data: untagged responses: LIST
+
+ Result: OK - list completed
+ NO - list failure: can't list that reference or name
+ BAD - command unknown or arguments invalid
+
+ The LIST command returns a subset of names from the complete set
+ of all names available to the user. Zero or more untagged LIST
+ replies are returned, containing the name attributes, hierarchy
+ delimiter, and name; see the description of the LIST reply for
+ more detail.
+
+ An empty ("" string) reference name argument indicates that the
+ mailbox name is interpreted as by SELECT. The returned mailbox
+ names MUST match the supplied mailbox name pattern. A non-empty
+ reference name argument is the name of a mailbox or a level of
+ mailbox hierarchy, and indicates a context in which the mailbox
+ name is interpreted in an implementation-defined manner.
+
+ The reference and mailbox name arguments are interpreted, in an
+ implementation-dependent fashion, into a canonical form that
+ represents an unambiguous left-to-right hierarchy. The returned
+ mailbox names will be in the interpreted form.
+
+ Any part of the reference argument that is included in the
+ interpreted form SHOULD prefix the interpreted form. It should
+ also be in the same form as the reference name argument. This
+ rule permits the client to determine if the returned mailbox name
+ is in the context of the reference argument, or if something about
+ the mailbox argument overrode the reference argument. Without
+ this rule, the client would have to have knowledge of the server's
+ naming semantics including what characters are "breakouts" that
+ override a naming context.
+
+
+
+
+
+
+
+
+
+Crispin [Page 20]
+
+RFC 1730 IMAP4 December 1994
+
+
+ For example, here are some examples of how references
+ and mailbox names might be interpreted on a UNIX-based
+ server:
+
+ Reference Mailbox Name Interpretation
+ ------------ ------------ --------------
+ ~smith/Mail/ foo.* ~smith/Mail/foo.*
+ archive/ % archive/%
+ #news. comp.mail.* #news.comp.mail.*
+ ~smith/Mail/ /usr/doc/foo /usr/doc/foo
+ archive/ ~fred/Mail/* ~fred/Mail/*
+
+ The first three examples demonstrate interpretations in
+ the context of the reference argument. Note that
+ "~smith/Mail" should not be transformed into something
+ like "/u2/users/smith/Mail", or it would be impossible
+ for the client to determine that the interpretation was
+ in the context of the reference.
+
+ The character "*" is a wildcard, and matches zero or more
+ characters at this position. The character "%" is similar to "*",
+ but it does not match a hierarchy delimiter. If the "%" wildcard
+ is the last character of a mailbox name argument, matching levels
+ of hierarchy are also returned. If these levels of hierarchy are
+ not also selectable mailboxes, they are returned with the
+ \Noselect mailbox name attribute (see the description of the LIST
+ response for more detail).
+
+ Server implementations are permitted to "hide" otherwise
+ accessible mailboxes from the wildcard characters, by preventing
+ certain characters or names from matching a wildcard in certain
+ situations. For example, a UNIX-based server might restrict the
+ interpretation of "*" so that an initial "/" character does not
+ match.
+
+ The special name INBOX is included in the output from LIST if it
+ matches the input arguments and INBOX is supported by this server
+ for this user. The criteria for omitting INBOX is whether SELECT
+ INBOX will return failure; it is not relevant whether the user's
+ real INBOX resides on this or some other server.
+
+ Example: C: A002 LIST "~/Mail/" "%"
+ S: * LIST (\Noselect) "/" ~/Mail/foo
+ S: * LIST () "/" ~/Mail/meetings
+ S: A002 OK LIST completed
+
+
+
+
+
+
+Crispin [Page 21]
+
+RFC 1730 IMAP4 December 1994
+
+
+6.3.9. LSUB Command
+
+ Arguments: reference name
+ mailbox name with possible wildcards
+
+ Data: untagged responses: LSUB
+
+ Result: OK - lsub completed
+ NO - lsub failure: can't list that reference or name
+ BAD - command unknown or arguments invalid
+
+ The LSUB command returns a subset of names from the set of names
+ that the user has declared as being "active" or "subscribed".
+ Zero or more untagged LSUB replies are returned. The arguments to
+ LSUB are in the same form as those for LIST.
+
+ Example: C: A002 LSUB "#news." "comp.mail.*"
+ S: * LSUB () "." #news.comp.mail.mime
+ S: * LSUB () "." #news.comp.mail.misc
+ S: A002 OK LSUB completed
+
+
+6.3.10. APPEND Command
+
+ Arguments: mailbox name
+ optional flag parenthesized list
+ optional date/time string
+ message literal
+
+ Data: no specific data for this command
+
+ Result: OK - append completed
+ NO - append error: can't append to that mailbox, error
+ in flags or date/time or message text
+ BAD - command unknown or arguments invalid
+
+ The APPEND command appends the literal argument as a new message
+ in the specified destination mailbox. This argument is in the
+ format of an [RFC-822] message. 8-bit characters are permitted in
+ the message. A server implementation that is unable to preserve
+ 8-bit data properly MUST be able to reversibly convert 8-bit
+ APPEND data to 7-bit using [MIME-1] encoding.
+
+ If a flag parenthesized list or date_time are specified, that data
+ SHOULD be set in the resulting message; otherwise, the defaults of
+ empty flags and the current date/time are used.
+
+
+
+
+
+Crispin [Page 22]
+
+RFC 1730 IMAP4 December 1994
+
+
+ If the append is unsuccessful for any reason, the mailbox MUST be
+ restored to its state before the APPEND attempt; no partial
+ appending is permitted. If the mailbox is currently selected, the
+ normal new mail actions should occur.
+
+ If the destination mailbox does not exist, a server MUST return an
+ error, and MUST NOT automatically create the mailbox. Unless it
+ is certain that the destination mailbox can not be created, the
+ server MUST send the response code "[TRYCREATE]" as the prefix of
+ the text of the tagged NO response. This gives a hint to the
+ client that it can attempt a CREATE command and retry the APPEND
+ if the CREATE is successful.
+
+ Example: C: A003 APPEND saved-messages (\Seen) {310}
+ C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
+ C: From: Fred Foobar <foobar@Blurdybloop.COM>
+ C: Subject: afternoon meeting
+ C: To: mooch@owatagu.siam.edu
+ C: Message-Id: <B27397-0100000@Blurdybloop.COM>
+ C: MIME-Version: 1.0
+ C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
+ C:
+ C: Hello Joe, do you think we can meet at 3:30 tomorrow?
+ C:
+ S: A003 OK APPEND completed
+
+ Note: the APPEND command is not used for message delivery,
+ because it does not provide a mechanism to transfer [SMTP]
+ envelope information.
+
+
+
+6.4. Client Commands - Selected State
+
+ In selected state, commands that manipulate messages in a mailbox are
+ permitted.
+
+ In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
+ and the authenticated state commands (SELECT, EXAMINE, CREATE,
+ DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, FIND
+ ALL.MAILBOXES, FIND MAILBOXES, and APPEND), the following commands
+ are valid in the selected state: CHECK, CLOSE, EXPUNGE, SEARCH,
+ FETCH, PARTIAL, STORE, COPY, and UID.
+
+
+
+
+
+
+
+
+Crispin [Page 23]
+
+RFC 1730 IMAP4 December 1994
+
+
+6.4.1. CHECK Command
+
+ Arguments: none
+
+ Data: no specific data for this command
+
+ Result: OK - check completed
+ BAD - command unknown or arguments invalid
+
+ The CHECK command requests a checkpoint of the currently selected
+ mailbox. A checkpoint refers to any implementation-dependent
+ housekeeping associated with the mailbox (e.g. resolving the
+ server's in-memory state of the mailbox with the state on its
+ disk) that is not normally executed as part of each command. A
+ checkpoint may take a non-instantaneous amount of real time to
+ complete. If a server implementation has no such housekeeping
+ considerations, CHECK is equivalent to NOOP.
+
+ There is no guarantee that an EXISTS untagged response will happen
+ as a result of CHECK. NOOP, not CHECK, should be used for new
+ mail polling.
+
+ Example: C: FXXZ CHECK
+ S: FXXZ OK CHECK Completed
+
+
+6.4.2. CLOSE Command
+
+ Arguments: none
+
+ Data: no specific data for this command
+
+ Result: OK - close completed, now in authenticated state
+ NO - close failure: no mailbox selected
+ BAD - command unknown or arguments invalid
+
+ The CLOSE command permanently removes from the currently selected
+ mailbox all messages that have the \Deleted flag set, and returns
+ to authenticated state from selected state. No untagged EXPUNGE
+ responses are sent.
+
+ No messages are removed, and no error is given, if the mailbox is
+ selected by an EXAMINE command or is otherwise selected read-only.
+
+ Even when a mailbox is selected, it is not required to send a
+ CLOSE command before a SELECT, EXAMINE, or LOGOUT command. The
+ SELECT, EXAMINE, and LOGOUT commands implicitly close the
+ currently selected mailbox without doing an expunge. However,
+
+
+
+Crispin [Page 24]
+
+RFC 1730 IMAP4 December 1994
+
+
+ when many messages are deleted, a CLOSE-LOGOUT or CLOSE-SELECT
+ sequence is considerably faster than an EXPUNGE-LOGOUT or
+ EXPUNGE-SELECT because no untagged EXPUNGE responses (which the
+ client would probably ignore) are sent.
+
+ Example: C: A341 CLOSE
+ S: A341 OK CLOSE completed
+
+
+6.4.3. EXPUNGE Command
+
+ Arguments: none
+
+ Data: untagged responses: EXPUNGE
+
+ Result: OK - expunge completed
+ NO - expunge failure: can't expunge (e.g. permission
+ denied)
+ BAD - command unknown or arguments invalid
+
+ The EXPUNGE command permanently removes from the currently
+ selected mailbox all messages that have the \Deleted flag set.
+ Before returning an OK to the client, an untagged EXPUNGE response
+ is sent for each message that is removed.
+
+ Example: C: A202 EXPUNGE
+ S: * 3 EXPUNGE
+ S: * 3 EXPUNGE
+ S: * 5 EXPUNGE
+ S: * 8 EXPUNGE
+ S: A202 OK EXPUNGE completed
+
+ Note: in this example, messages 3, 4, 7, and 11 had the
+ \Deleted flag set. See the description of the EXPUNGE
+ response for further explanation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin [Page 25]
+
+RFC 1730 IMAP4 December 1994
+
+
+6.4.4. SEARCH Command
+
+ Arguments: optional character set specification
+ searching criteria (one or more)
+
+ Data: mandatory untagged response: SEARCH
+
+ Result: OK - search completed
+ NO - search error: can't search that character set or
+ criteria
+ BAD - command unknown or arguments invalid
+
+ The SEARCH command searches the mailbox for messages that match
+ the given searching criteria. Searching criteria consist of one
+ or more search keys. The untagged SEARCH response from the server
+ contains a listing of message sequence numbers corresponding to
+ those messages that match the searching criteria.
+
+ When multiple keys are specified, the result is the intersection
+ (AND function) of all the messages that match those keys. For
+ example, the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers
+ to all deleted messages from Smith that were placed in the mailbox
+ since February 1, 1994. A search key may also be a parenthesized
+ list of one or more search keys (e.g. for use with the OR and NOT
+ keys).
+
+ Server implementations MAY exclude [MIME-1] body parts with
+ terminal content types other than TEXT and MESSAGE from
+ consideration in SEARCH matching.
+
+ The optional character set specification consists of the word
+ "CHARSET" followed by a registered MIME character set. It
+ indicates the character set of the strings that appear in the
+ search criteria. [MIME-2] strings that appear in RFC 822/MIME
+ message headers, and [MIME-1] content transfer encodings, MUST be
+ decoded before matching. Except for US-ASCII, it is not required
+ that any particular character set be supported. If the server
+ does not support the specified character set, it MUST return a
+ tagged NO response (not a BAD).
+
+ In all search keys that use strings, a message matches the key if
+ the string is a substring of the field. The matching is
+ case-insensitive.
+
+
+
+
+
+
+
+
+Crispin [Page 26]
+
+RFC 1730 IMAP4 December 1994
+
+
+ The defined search keys are as follows. Refer to the Formal
+ Syntax section for the precise syntactic definitions of the
+ arguments.
+
+ <message set> Messages with message sequence numbers
+ corresponding to the specified message sequence
+ number set
+
+ ALL All messages in the mailbox; the default initial
+ key for ANDing.
+
+ ANSWERED Messages with the \Answered flag set.
+
+ BCC <string> Messages that contain the specified string in the
+ envelope structure's BCC field.
+
+ BEFORE <date> Messages whose internal date is earlier than the
+ specified date.
+
+ BODY <string> Messages that contain the specified string in the
+ body of the message.
+
+ CC <string> Messages that contain the specified string in the
+ envelope structure's CC field.
+
+ DELETED Messages with the \Deleted flag set.
+
+ DRAFT Messages with the \Draft flag set.
+
+ FLAGGED Messages with the \Flagged flag set.
+
+ FROM <string> Messages that contain the specified string in the
+ envelope structure's FROM field.
+
+ HEADER <field-name> <string>
+ Messages that have a header with the specified
+ field-name (as defined in [RFC-822]) and that
+ contains the specified string in the [RFC-822]
+ field-body.
+
+ KEYWORD <flag> Messages with the specified keyword set.
+
+ LARGER <n> Messages with an RFC822.SIZE larger than the
+ specified number of octets.
+
+ NEW Messages that have the \Recent flag set but not the
+ \Seen flag. This is functionally equivalent to
+ "(RECENT UNSEEN)".
+
+
+
+Crispin [Page 27]
+
+RFC 1730 IMAP4 December 1994
+
+
+ NOT <search-key>
+ Messages that do not match the specified search
+ key.
+
+ OLD Messages that do not have the \Recent flag set.
+ This is functionally equivalent to "NOT RECENT" (as
+ opposed to "NOT NEW").
+
+ ON <date> Messages whose internal date is within the
+ specified date.
+
+ OR <search-key1> <search-key2>
+ Messages that match either search key.
+
+ RECENT Messages that have the \Recent flag set.
+
+ SEEN Messages that have the \Seen flag set.
+
+ SENTBEFORE <date>
+ Messages whose [RFC-822] Date: header is earlier
+ than the specified date.
+
+ SENTON <date> Messages whose [RFC-822] Date: header is within the
+ specified date.
+
+ SENTSINCE <date>
+ Messages whose [RFC-822] Date: header is within or
+ later than the specified date.
+
+ SINCE <date> Messages whose internal date is within or later
+ than the specified date.
+
+ SMALLER <n> Messages with an RFC822.SIZE smaller than the
+ specified number of octets.
+
+ SUBJECT <string>
+ Messages that contain the specified string in the
+ envelope structure's SUBJECT field.
+
+ TEXT <string> Messages that contain the specified string in the
+ header or body of the message.
+
+ TO <string> Messages that contain the specified string in the
+ envelope structure's TO field.
+
+ UID <message set>
+ Messages with unique identifiers corresponding to
+ the specified unique identifier set.
+
+
+
+Crispin [Page 28]
+
+RFC 1730 IMAP4 December 1994
+
+
+ UNANSWERED Messages that do not have the \Answered flag set.
+
+ UNDELETED Messages that do not have the \Deleted flag set.
+
+ UNDRAFT Messages that do not have the \Draft flag set.
+
+ UNFLAGGED Messages that do not have the \Flagged flag set.
+
+ UNKEYWORD <flag>
+ Messages that do not have the specified keyword
+ set.
+
+ UNSEEN Messages that do not have the \Seen flag set.
+
+
+ Example: C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith"
+ S: * SEARCH 2 84 882
+ S: A282 OK SEARCH completed
+
+
+6.4.5. FETCH Command
+
+ Arguments: message set
+ message data item names
+
+ Data: untagged responses: FETCH
+
+ Result: OK - fetch completed
+ NO - fetch error: can't fetch that data
+ BAD - command unknown or arguments invalid
+
+ 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 a parenthesized list. The currently defined data items that
+ can be fetched are:
+
+ ALL Macro equivalent to: (FLAGS INTERNALDATE
+ RFC822.SIZE ENVELOPE)
+
+ BODY Non-extensible form of BODYSTRUCTURE.
+
+ BODY[<section>]
+ The text of a particular body section. The section
+ specification is a set of one or more part numbers
+ delimited by periods.
+
+ Single-part messages only have a part 1.
+
+
+
+
+Crispin [Page 29]
+
+RFC 1730 IMAP4 December 1994
+
+
+ Multipart messages are assigned consecutive part
+ numbers, as they occur in the message. If a
+ particular part is of type message or multipart,
+ its parts must be indicated by a period followed by
+ the part number within that nested multipart part.
+ It is not permitted to fetch a multipart part
+ itself, only its individual members.
+
+ A part of type MESSAGE and subtype RFC822 also has
+ nested parts. These are the parts of the MESSAGE
+ part's body. Nested part 0 of a part of type
+ MESSAGE and subtype RFC822 is the [RFC-822] header
+ of the message.
+
+ Every message has at least one part.
+
+ Here is an example of a complex message
+ with its associated section
+ specifications:
+
+ 0 ([RFC-822] header of the message)
+ MULTIPART/MIXED
+ 1 TEXT/PLAIN
+ 2 APPLICATION/OCTET-STREAM
+ 3 MESSAGE/RFC822
+ 3.0 ([RFC-822] header of the message)
+ 3.1 TEXT/PLAIN
+ 3.2 APPLICATION/OCTET-STREAM
+ MULTIPART/MIXED
+ 4.1 IMAGE/GIF
+ 4.2 MESSAGE/RFC822
+ 4.2.0 ([RFC-822] header of the message)
+ 4.2.1 TEXT/PLAIN
+ MULTIPART/ALTERNATIVE
+ 4.2.2.1 TEXT/PLAIN
+ 4.2.2.2 TEXT/RICHTEXT
+
+ Note that there is no section
+ specification for the Multi-part parts
+ (no section 4 or 4.2.2).
+
+ The \Seen flag is implicitly set; if this causes
+ the flags to change they should be included as part
+ of the fetch responses.
+
+ BODY.PEEK[<section>]
+ An alternate form of BODY[section] that does not
+ implicitly set the \Seen flag.
+
+
+
+Crispin [Page 30]
+
+RFC 1730 IMAP4 December 1994
+
+
+ BODYSTRUCTURE The [MIME-1] body structure of the message. This
+ is computed by the server by parsing the [MIME-1]
+ header lines.
+
+ ENVELOPE The envelope structure of the message. This 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 that are set for this message.
+
+ FULL Macro equivalent to: (FLAGS INTERNALDATE
+ RFC822.SIZE ENVELOPE BODY)
+
+ INTERNALDATE The date and time of final delivery of the message
+ as defined by RFC 821.
+
+ RFC822 The message in [RFC-822] format. The \Seen flag is
+ implicitly set; if this causes the flags to change
+ they should be included as part of the fetch
+ responses. This is the concatenation of
+ RFC822.HEADER and RFC822.TEXT.
+
+ RFC822.PEEK An alternate form of RFC822 that does not
+ implicitly set the \Seen flag.
+
+ RFC822.HEADER The [RFC-822] format header of the message as
+ stored on the server including the delimiting blank
+ line between the header and the body.
+
+ RFC822.HEADER.LINES <header_list>
+ All header lines (including continuation lines) of
+ the [RFC-822] format header of the message with a
+ field-name (as defined in [RFC-822]) that matches
+ any of the strings in header_list. The matching is
+ case-insensitive but otherwise exact. The
+ delimiting blank line between the header and the
+ body is always included.
+
+
+
+
+
+
+
+
+
+
+Crispin [Page 31]
+
+RFC 1730 IMAP4 December 1994
+
+
+ RFC822.HEADER.LINES.NOT <header_list>
+ All header lines (including continuation lines) of
+ the [RFC-822] format header of the message with a
+ field-name (as defined in [RFC-822]) that does not
+ match any of the strings in header_list. The
+ matching is case-insensitive but otherwise exact.
+ The delimiting blank line between the header and
+ the body is always included.
+
+ RFC822.SIZE The number of octets in the message, as expressed
+ in [RFC-822] format.
+
+ RFC822.TEXT The text body of the message, omitting the
+ [RFC-822] header. The \Seen flag is implicitly
+ set; if this causes the flags to change they should
+ be included as part of the fetch responses.
+
+ RFC822.TEXT.PEEK
+ An alternate form of RFC822.TEXT that does not
+ implicitly set the \Seen flag.
+
+ UID The unique identifier for the message.
+
+
+ Example: C: A654 FETCH 2:4 (FLAGS RFC822.HEADER.LINES (DATE FROM))
+ S: * 2 FETCH ....
+ S: * 3 FETCH ....
+ S: * 4 FETCH ....
+ S: A003 OK FETCH completed
+
+
+6.4.6. PARTIAL Command
+
+ Arguments: message sequence number
+ message data item name
+ position of first octet
+ number of octets
+
+ Data: untagged responses: FETCH
+
+ Result: OK - partial completed
+ NO - partial error: can't fetch that data
+ BAD - command unknown or arguments invalid
+
+ The PARTIAL command is equivalent to the associated FETCH command,
+ with the added functionality that only the specified number of
+ octets, beginning at the specified starting octet, are returned.
+ Only a single message can be fetched at a time. The first octet
+
+
+
+Crispin [Page 32]
+
+RFC 1730 IMAP4 December 1994
+
+
+ of a message, and hence the minimum for the starting octet, is
+ octet 1.
+
+ The following FETCH items are valid data for PARTIAL: RFC822,
+ RFC822.HEADER, RFC822.TEXT, BODY[section], as well as any .PEEK
+ forms of these.
+
+ Any partial fetch that attempts to read beyond the end of the text
+ is truncated as appropriate. If the starting octet is beyond the
+ end of the text, an empty string is returned.
+
+ The data are returned with the FETCH response. There is no
+ indication of the range of the partial data in this response. It
+ is not possible to stream multiple PARTIAL commands of the same
+ data item without processing and synchronizing at each step, since
+ streamed commands may be executed out of order.
+
+ There is no requirement that partial fetches follow any sequence.
+ For example, if a partial fetch of octets 1 through 10000 breaks
+ in an awkward place for BASE64 decoding, it is permitted to
+ continue with a partial fetch of 9987 through 19987, etc.
+
+ The handling of the \Seen flag is the same as in the associated
+ FETCH command.
+
+ Example: C: A005 PARTIAL 4 RFC822 1 1024
+ S: * 1 FETCH (RFC822 {1024}
+ S: Return-Path: <gray@cac.washington.edu>
+ S: ...
+ S: ......... FLAGS (\Seen))
+ S: A005 OK PARTIAL completed
+
+
+6.4.7. STORE Command
+
+ Arguments: message set
+ message data item name
+ value for message data item
+
+ Data: untagged responses: FETCH
+
+ Result: OK - store completed
+ NO - store error: can't store that data
+ BAD - command unknown or arguments invalid
+
+ The STORE command alters data associated with a message in the
+ mailbox. Normally, STORE will return the updated value of the
+ data with an untagged FETCH response. A suffix of ".SILENT" in
+
+
+
+Crispin [Page 33]
+
+RFC 1730 IMAP4 December 1994
+
+
+ the data item name prevents the untagged FETCH, and the server
+ should assume that the client has determined the updated value
+ itself or does not care about the updated value.
+
+ The currently defined data items that can be stored are:
+
+ FLAGS <flag list>
+ Replace the flags for the message with the
+ argument. The new value of the flags are returned
+ as if a FETCH of those flags was done.
+
+ FLAGS.SILENT <flag list>
+ Equivalent to FLAGS, but without returning a new
+ value.
+
+ +FLAGS <flag list>
+ Add the argument to the flags for the message. The
+ new value of the flags are returned as if a FETCH
+ of those flags was done.
+
+ +FLAGS.SILENT <flag list>
+ Equivalent to +FLAGS, but without returning a new
+ value.
+
+ -FLAGS <flag list>
+ Remove the argument from the flags for the message.
+ The new value of the flags are returned as if a
+ FETCH of those flags was done.
+
+ -FLAGS.SILENT <flag list>
+ Equivalent to -FLAGS, but without returning a new
+ value.
+
+
+ Example: C: A003 STORE 2:4 +FLAGS (\Deleted)
+ S: * 2 FETCH FLAGS (\Deleted \Seen)
+ S: * 3 FETCH FLAGS (\Deleted)
+ S: * 4 FETCH FLAGS (\Deleted \Flagged \Seen)
+ S: A003 OK STORE completed
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin [Page 34]
+
+RFC 1730 IMAP4 December 1994
+
+
+6.4.8. COPY Command
+
+ Arguments: message set
+ mailbox name
+
+ Data: no specific data for this command
+
+ Result: OK - copy completed
+ NO - copy error: can't copy those messages or to that
+ name
+ BAD - command unknown or arguments invalid
+
+ The COPY command copies the specified message(s) to the specified
+ destination mailbox. The flags and internal date of the
+ message(s) SHOULD be preserved in the copy.
+
+ If the destination mailbox does not exist, a server SHOULD return
+ an error. It SHOULD NOT automatically create the mailbox. Unless
+ it is certain that the destination mailbox can not be created, the
+ server MUST send the response code "[TRYCREATE]" as the prefix of
+ the text of the tagged NO response. This gives a hint to the
+ client that it can attempt a CREATE command and retry the COPY if
+ the CREATE is successful.
+
+ If the COPY command is unsuccessful for any reason, server
+ implementations MUST restore the destination mailbox to its state
+ before the COPY attempt.
+
+ Example: C: A003 COPY 2:4 MEETING
+ S: A003 OK COPY completed
+
+
+6.4.9. UID Command
+
+ Arguments: command name
+ command arguments
+
+ Data: untagged responses: FETCH, SEARCH
+
+ Result: OK - UID command completed
+ NO - UID command error
+ BAD - command unknown or arguments invalid
+
+ The UID command has two forms. In the first form, it takes as its
+ arguments a COPY, FETCH, or STORE command with arguments
+ appropriate for the associated command. However, the numbers in
+ the message set argument are unique identifiers instead of message
+ sequence numbers.
+
+
+
+Crispin [Page 35]
+
+RFC 1730 IMAP4 December 1994
+
+
+ In the second form, the UID command takes a SEARCH command with
+ SEARCH command arguments. The interpretation of the arguments is
+ the same as with SEARCH; however, the numbers returned in a SEARCH
+ response for a UID SEARCH command are unique identifiers instead
+ of message sequence numbers. For example, the command UID SEARCH
+ 1:100 UID 443:557 returns the unique identifiers corresponding to
+ the intersection of the message sequence number set 1:100 and the
+ UID set 443:557.
+
+ A unique identifier of a message is a number, and is guaranteed
+ not to refer to any other message in the mailbox. Unique
+ identifiers are assigned in a strictly ascending fashion for each
+ message added to the mailbox. Unlike message sequence numbers,
+ unique identifiers persist across sessions. This permits a client
+ to resynchronize its state from a previous session with the server
+ (e.g. disconnected or offline access clients); this is discussed
+ further in [IMAP-DISC].
+
+ Associated with every mailbox is a unique identifier validity
+ value, which is sent in an UIDVALIDITY response code in an OK
+ untagged response at message selection time. If unique
+ identifiers from an earlier session fail to persist to this
+ session, the unique identifier validity value MUST be greater than
+ in the earlier session.
+
+ Note: An example of a good value to use for the unique
+ identifier validity value would be a 32-bit
+ representation of the creation date/time of the mailbox.
+ It is alright to use a constant such as 1, but only if
+ it guaranteed that unique identifers will never be
+ reused, even in the case of a mailbox being deleted and
+ a new mailbox by the same name created at some future
+ time.
+
+
+ Message set ranges are permitted; however, there is no guarantee
+ that unique identifiers be contiguous. A non-existent unique
+ identifier within a message set range is ignored without any error
+ message generated.
+
+ The number after the "*" in an untagged FETCH response is always a
+ message sequence number, not a unique identifier, even for a UID
+ command response. However, server implementations MUST implicitly
+ include the UID message data item as part of any FETCH response
+ caused by a UID command, regardless of whether UID was specified
+ as a message data item to the FETCH.
+
+
+
+
+
+Crispin [Page 36]
+
+RFC 1730 IMAP4 December 1994
+
+
+ Example: C: A003 UID FETCH 4827313:4828442 FLAGS
+ S: * 23 FETCH (FLAGS (\Seen) UID 4827313)
+ S: * 24 FETCH (FLAGS (\Seen) UID 4827943)
+ S: * 25 FETCH (FLAGS (\Seen) UID 4828442)
+ S: A999 UID FETCH completed
+
+
+
+6.5. Client Commands - Experimental/Expansion
+
+
+6.5.1. X<atom> Command
+
+ Arguments: implementation defined
+
+ Data: implementation defined
+
+ Result: OK - command completed
+ NO - failure
+ BAD - command unknown or arguments invalid
+
+ Any command prefixed with an X is an experimental command.
+ Commands which are not part of this specification, or a standard
+ or standards-track revision of this specification, MUST use the X
+ prefix.
+
+ Any added untagged responses issued by an experimental command
+ MUST also be prefixed with an X. Server implementations MUST NOT
+ send any such untagged responses, unless the client requested it
+ by issuing the associated experimental command.
+
+ Example: C: a441 CAPABILITY
+ S: * CAPABILITY IMAP4 XPIG-LATIN
+ S: a441 OK CAPABILITY completed
+ C: A442 XPIG-LATIN
+ S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay
+ S: A442 OK XPIG-LATIN ompleted-cay
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin [Page 37]
+
+RFC 1730 IMAP4 December 1994
+
+
+7. Server Responses
+
+ Server responses are in three forms: status responses, server data,
+ and command continuation request.
+
+ Server response data, identified by "Data:" in the response
+ descriptions below, are described by function, not by syntax. The
+ precise syntax of server response data is described in the Formal
+ Syntax section.
+
+ The client MUST be prepared to accept any response at all times.
+
+ Status responses that are tagged indicate the completion result of a
+ client command, and have a tag matching the command.
+
+ Some status responses, and all server data, are untagged. An
+ untagged response is indicated by the token "*" instead of a tag.
+ Untagged status responses indicate server greeting, or server status
+ that does not indicate the completion of a command. For historical
+ reasons, untagged server data responses are also called "unsolicited
+ data", although strictly speaking only unilateral server data is
+ truly "unsolicited".
+
+ Certain server data MUST be recorded by the client when it is
+ received; this is noted in the description of that data. Such data
+ conveys critical information which affects the interpretation of all
+ subsequent commands and responses (e.g. updates reflecting the
+ creation or destruction of messags).
+
+ Other server data SHOULD be recorded for later reference; if the
+ client does not need to record the data, or if recording the data has
+ no obvious purpose (e.g. a SEARCH response when no SEARCH command is
+ in progress), the data SHOULD be ignored.
+
+ An example of unilateral untagged responses occurs when the IMAP
+ connection is in selected state. In selected state, the server
+ checks the mailbox for new messages as part of the execution of each
+ command. If new messages are found, the server sends untagged EXISTS
+ and RECENT responses reflecting the new size of the mailbox. Server
+ implementations that offer multiple simultaneous access to the same
+ mailbox should also send appropriate unilateral untagged FETCH and
+ EXPUNGE responses if another agent changes the state of any message
+ flags or expunges any messages.
+
+ Command continuation request responses use the token "+" instead of a
+ tag. These responses are sent by the server to indicate acceptance
+ of an incomplete client command and readiness for the remainder of
+ the command.
+
+
+
+Crispin [Page 38]
+
+RFC 1730 IMAP4 December 1994
+
+
+7.1. Server Responses - Status Responses
+
+ Status responses may include an optional response code. A response
+ code consists of data inside square brackets in the form of an atom,
+ possibly followed by a space and arguments. The response code
+ contains additional information or status codes for client software
+ beyond the OK/NO/BAD condition, and are defined when there is a
+ specific action that a client can take based upon the additional
+ information.
+
+ The currently defined response codes are:
+
+ ALERT The human-readable text contains a special alert
+ that MUST be presented to the user in a fashion
+ that calls the user's attention to the message.
+
+ PARSE The human-readable text represents an error in
+ parsing the [RFC-822] or [MIME-1] headers of a
+ message in the mailbox.
+
+ PERMANENTFLAGS Followed by a parenthesized list of flags,
+ indicates which of the known flags that the client
+ may change permanently. Any flags that are in the
+ FLAGS untagged response, but not the PERMANENTFLAGS
+ list, can not be set permanently. If the client
+ attempts to STORE a flag that is not in the
+ PERMANENTFLAGS list, the server will either reject
+ it with a NO reply or store the state for the
+ remainder of the current session only. The
+ PERMANENTFLAGS list may also include the special
+ flag \*, which indicates that it is possible to
+ create new keywords by attempting to store those
+ flags in the mailbox.
+
+ READ-ONLY The mailbox is selected read-only, or its access
+ while selected has changed from read-write to
+ read-only.
+
+ READ-WRITE The mailbox is selected read-write, or its access
+ while selected has changed from read-only to
+ read-write.
+
+ TRYCREATE An APPEND or COPY attempt is failing because the
+ target mailbox does not exist (as opposed to some
+ other reason). This is a hint to the client that
+ the operation may succeed if the mailbox is first
+ created by the CREATE command.
+
+
+
+
+Crispin [Page 39]
+
+RFC 1730 IMAP4 December 1994
+
+
+ UIDVALIDITY Followed by a decimal number, indicates the unique
+ identifier validity value. See the description of
+ the UID command for more detail.
+
+ UNSEEN Followed by a decimal number, indicates the number
+ of the first message without the \Seen flag set.
+
+ Additional response codes defined by particular client or server
+ implementations should be prefixed with an "X" until they are
+ added to a revision of this protocol. Client implementations
+ should ignore response codes that they do not recognize.
+
+
+7.1.1. OK Response
+
+ Data: optional response code
+ human-readable text
+
+ The OK response indicates an information message from the server.
+ When tagged, it indicates successful completion of the associated
+ command. The human-readable text may be presented to the user as
+ an information message. The untagged form indicates an
+ information-only message; the nature of the information may be
+ indicated by a response code.
+
+ The untagged form is also used as one of three possible greetings
+ at session startup. It indicates that the session is not yet
+ authenticated and that a LOGIN command is needed.
+
+ Example: S: * OK IMAP4 server ready
+ C: A001 LOGIN fred blurdybloop
+ S: * OK [ALERT] System shutdown in 10 minutes
+ S: A001 OK LOGIN Completed
+
+
+7.1.2. NO Response
+
+ Data: optional response code
+ human-readable text
+
+ The NO response indicates an operational error message from the
+ server. When tagged, it indicates unsuccessful completion of the
+ associated command. The untagged form indicates a warning; the
+ command may still complete successfully. The human-readable text
+ describes the condition.
+
+
+
+
+
+
+Crispin [Page 40]
+
+RFC 1730 IMAP4 December 1994
+
+
+ Example: C: A222 COPY 1:2 owatagusiam
+ S: * NO Disk is 98% full, please delete unnecessary data
+ S: A222 OK COPY completed
+ C: A222 COPY 3:200 blurdybloop
+ S: * NO Disk is 98% full, please delete unnecessary data
+ S: * NO Disk is 99% full, please delete unnecessary data
+ S: A222 NO COPY failed: disk is full
+
+
+7.1.3. BAD Response
+
+ Data: optional response code
+ human-readable text
+
+ The BAD response indicates an error message from the server. When
+ tagged, it reports a protocol-level error in the client's command;
+ the tag indicates the command that caused the error. The untagged
+ form indicates a protocol-level error for which the associated
+ command can not be determined; it may also indicate an internal
+ server failure. The human-readable text describes the condition.
+
+ Example: C: ...very long command line...
+ S: * BAD Command line too long
+ C: ...empty line...
+ S: * BAD Empty command line
+ C: A443 EXPUNGE
+ S: * BAD Disk crash, attempting salvage to a new disk!
+ S: * OK Salvage successful, no data lost
+ S: A443 OK Expunge completed
+
+
+7.1.4. PREAUTH Response
+
+ Data: optional response code
+ human-readable text
+
+ The PREAUTH response is always untagged, and is one of three
+ possible greetings at session startup. It indicates that the
+ session has already been authenticated by external means and thus
+ no LOGIN command is needed.
+
+ Example: S: * PREAUTH IMAP4 server ready and logged in as Smith
+
+
+
+
+
+
+
+
+
+Crispin [Page 41]
+
+RFC 1730 IMAP4 December 1994
+
+
+7.1.5. BYE Response
+
+ Data: optional response code
+ human-readable text
+
+ The BYE response is always untagged, and indicates that the server
+ is about to close the connection. The human-readable text may be
+ displayed to the user in a status report by the client. The BYE
+ response 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 server implementations as an announcement of an inactivity
+ autologout.
+
+ This response is also used as one of three possible greetings at
+ session startup. It indicates that the server is not willing to
+ accept a session from this client.
+
+ Example: S: * BYE Autologout; idle for too long
+
+
+
+7.2. Server Responses - Server and Mailbox Status
+
+ These responses are always untagged. This is how server data are
+ transmitted from the server to the client, often as a result of a
+ command with the same name.
+
+7.2.1. CAPABILITY Response
+
+ Data: capability listing
+
+ The CAPABILITY response occurs as a result of a CAPABILITY
+ command. The capability listing contains a space-separated
+ listing of capability names that the server supports. The first
+ name in the capability listing MUST be the atom "IMAP4".
+
+ A capability name other than IMAP4 indicates that the server
+ supports an extension, revision, or amendment to the IMAP4
+ protocol. Server responses MUST conform to this document until
+ the client issues a command that uses the associated capability.
+
+ Capability names MUST either begin with "X" or be standard or
+ standards-track IMAP4 extensions, revisions, or amendments
+ registered with IANA. A server MUST NOT offer unregistered or
+ non-standard capability names, unless such names are prefixed with
+ an "X".
+
+
+
+
+
+Crispin [Page 42]
+
+RFC 1730 IMAP4 December 1994
+
+
+ Client implementations SHOULD NOT require any capability name
+ other than "IMAP4", and MUST ignore any unknown capability names.
+
+ Example: S: * CAPABILITY IMAP4 XPIG-LATIN
+
+
+7.2.2. LIST Response
+
+ Data: name attributes
+ hierarchy delimiter
+ name
+
+ The LIST response occurs as a result of a LIST command. It
+ returns a single name that matches the LIST specification. There
+ may be multiple LIST responses for a single LIST command.
+
+ Four name attributes are defined:
+
+ \Noinferiors It is not possible for any child levels of
+ hierarchy to exist under this name; no child levels
+ exist now and none can be created in the future.
+
+ \Noselect It is not possible to use this name as a selectable
+ mailbox.
+
+ \Marked The mailbox has been marked "interesting" by the
+ server; the mailbox probably contains messages that
+ have been added since the last time the mailbox was
+ selected.
+
+ \Unmarked The mailbox does not contain any additional
+ messages since the last time the mailbox was
+ selected.
+
+ If it is not feasible for the server to determine whether the
+ mailbox is "interesting" or not, or if the name is a \Noselect
+ name, the server should not send either \Marked or \Unmarked.
+
+ The hierarchy delimiter is a character used to delimit levels of
+ hierarchy in a mailbox name. A client may use it to create child
+ mailboxes, and to search higher or lower levels of naming
+ hierarchy. All children of a top-level hierarchy node must use
+ the same separator character. A NIL hierarchy delimiter means
+ that no hierarchy exists; the name is a "flat" name.
+
+
+
+
+
+
+
+Crispin [Page 43]
+
+RFC 1730 IMAP4 December 1994
+
+
+ The name represents an unambiguous left-to-right hierarchy, and
+ MUST be valid for use as a reference in LIST and LSUB commands.
+ Unless \Noselect is indicated, the name must also be valid as an
+ argument for commands, such as SELECT, that accept mailbox names.
+
+ Example: S: * LIST (\Noselect) "/" ~/Mail/foo
+
+
+7.2.3. LSUB Response
+
+ Data: name attributes
+ hierarchy delimiter
+ name
+
+ The LSUB response occurs as a result of an LSUB command. It
+ returns a single name that matches the LSUB specification. There
+ may be multiple LSUB responses for a single LSUB command. The
+ data is identical in format to the LIST response.
+
+ Example: S: * LSUB () "." #news.comp.mail.misc
+
+
+7.2.4. SEARCH Response
+
+ Data: zero or more numbers
+
+ The SEARCH response occurs as a result of a SEARCH or UID SEARCH
+ command. The number(s) refer to those messages that match the
+ search criteria. For SEARCH, these are message sequence numbers;
+ for UID SEARCH, these are unique identifiers. Each number is
+ delimited by a space.
+
+ Example: S: * SEARCH 2 3 6
+
+
+7.2.5. FLAGS Response
+
+ Data: flag parenthesized list
+
+ The FLAGS response occurs as a result of a SELECT or EXAMINE
+ command. The flag parenthesized list identifies the flags (at a
+ minimum, the system-defined flags) that are applicable for this
+ mailbox. Flags other than the system flags may also exist,
+ depending on server implementation.
+
+ The update from the FLAGS response MUST be recorded by the client.
+
+ Example: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
+
+
+
+Crispin [Page 44]
+
+RFC 1730 IMAP4 December 1994
+
+
+7.3. Server Responses - Message Status
+
+ These responses are always untagged. This is how message data are
+ transmitted from the server to the client, often as a result of a
+ command with the same name. Immediately following the "*" token is a
+ number that represents either a message sequence number or a message
+ count.
+
+7.3.1. EXISTS Response
+
+ Data: none
+
+ The EXISTS response reports the number of messages in the mailbox.
+ This response occurs as a result of a SELECT or EXAMINE command,
+ and if the size of the mailbox changes (e.g. new mail).
+
+ The update from the EXISTS response MUST be recorded by the
+ client.
+
+ Example: S: * 23 EXISTS
+
+
+7.3.2. RECENT Response
+
+ Data: none
+
+ The RECENT response reports the number of messages that have
+ arrived since the previous time a SELECT command was done on this
+ mailbox. This response occurs as a result of a SELECT or EXAMINE
+ command, and if the size of the mailbox changes (e.g. new mail).
+
+ The update from the RECENT response MUST be recorded by the
+ client.
+
+ Example: S: * 5 RECENT
+
+
+7.3.3. EXPUNGE Response
+
+ Data: none
+
+ The EXPUNGE response reports that the specified message sequence
+ number has been permanently removed from the mailbox. The message
+ sequence number for each successive message in the mailbox is
+ immediately decremented by 1, and this decrement is reflected in
+ message sequence numbers in subsequent responses (including other
+ untagged EXPUNGE responses).
+
+
+
+
+Crispin [Page 45]
+
+RFC 1730 IMAP4 December 1994
+
+
+ As a result of the immediate decrement rule, message sequence
+ numbers that appear in a set of successive EXPUNGE responses
+ depend upon whether the messages are removed starting from lower
+ numbers to higher numbers, or from higher numbers to lower
+ numbers. For example, if the last 5 messages in a 9-message
+ mailbox are expunged; a "lower to higher" server will send five
+ untagged EXPUNGE responses for message sequence number 5, whereas
+ a "higher to lower server" will send successive untagged EXPUNGE
+ responses for message sequence numbers 9, 8, 7, 6, and 5.
+
+ An EXPUNGE response MUST NOT be sent when no command is in
+ progress; nor while responding to a FETCH, STORE, or SEARCH
+ command. This rule is necessary to prevent a loss of
+ synchronization of message sequence numbers between client and
+ server.
+
+ The update from the EXPUNGE response MUST be recorded by the
+ client.
+
+ Example: S: * 44 EXPUNGE
+
+
+7.3.4. FETCH Response
+
+ Data: message data
+
+ The FETCH response returns data about a message to the client.
+ The data are pairs of data item names and their values in
+ parentheses. This response occurs as the result of a FETCH or
+ STORE command, as well as by unilateral server decision (e.g. flag
+ updates).
+
+ The current data items are:
+
+ BODY A form of BODYSTRUCTURE without extension data.
+
+ BODY[section] A string expressing the body contents of the
+ specified section. The string should be
+ interpreted by the client according to the content
+ transfer encoding, body type, and subtype.
+
+ 8-bit textual data is permitted if a character set
+ identifier is part of the body parameter
+ parenthesized list for this section.
+
+ Non-textual data such as binary data must be
+ transfer encoded into a textual form such as BASE64
+ prior to being sent to the client. To derive the
+
+
+
+Crispin [Page 46]
+
+RFC 1730 IMAP4 December 1994
+
+
+ original binary data, the client must decode the
+ transfer encoded string.
+
+ BODYSTRUCTURE A parenthesized list that describes the body
+ structure of a message. This is computed by the
+ server by parsing the [RFC-822] header and body
+ into the component parts, defaulting various fields
+ as necessary.
+
+ Multiple parts are indicated by parenthesis
+ nesting. Instead of a body type as the first
+ element of the parenthesized list there is a nested
+ body. The second element of the parenthesized list
+ is the multipart subtype (mixed, digest, parallel,
+ alternative, etc.).
+
+ Extension data follows the multipart subtype.
+ Extension data is never returned with the BODY
+ fetch, but may be returned with a BODYSTRUCTURE
+ fetch. Extension data, if present, must be in the
+ defined order.
+
+ The extension data of a multipart body part are in
+ the following order:
+
+ body parameter parenthesized list
+ A parenthesized list of attribute/value pairs
+ [e.g. (foo bar baz rag) where "bar" is the value
+ of "foo" and "rag" is the value of "baz"] as
+ defined in [MIME-1].
+
+ Any following extension data are not yet defined in
+ this version of the protocol. Such extension data
+ may consist of zero or more NILs, strings, numbers,
+ or potentially nested parenthesized lists of such
+ data. Client implementations that do a
+ BODYSTRUCTURE fetch MUST be prepared to accept such
+ extension data. Server implementations MUST NOT
+ send such extension data until it has been defined
+ by a revision of this protocol.
+
+ The basic fields of a non-multipart body part are
+ in the following order:
+
+ body type
+ A string giving the content type name as defined
+ in [MIME-1].
+
+
+
+
+Crispin [Page 47]
+
+RFC 1730 IMAP4 December 1994
+
+
+ body subtype
+ A string giving the content subtype name as
+ defined in [MIME-1].
+
+ body parameter parenthesized list
+ A parenthesized list of attribute/value pairs
+ [e.g. (foo bar baz rag) where "bar" is the value
+ of "foo" and "rag" is the value of "baz"] as
+ defined in [MIME-1].
+
+ body id
+ A string giving the content id as defined in
+ [MIME-1].
+
+ body description
+ A string giving the content description as
+ defined in [MIME-1].
+
+ body encoding
+ A string giving the content transfer encoding as
+ defined in [MIME-1].
+
+ body size
+ A number giving the size of the body in octets.
+ Note that this size is the size in its transfer
+ encoding and not the resulting size after any
+ decoding.
+
+ A body type of type MESSAGE and subtype RFC822
+ contains, immediately after the basic fields, the
+ envelope structure, body structure, and size in
+ text lines of the encapsulated message.
+
+ A body type of type TEXT contains, immediately
+ after the basic fields, the size of the body in
+ text lines. Note that this size is the size in its
+ transfer encoding and not the resulting size after
+ any decoding.
+
+ Extension data follows the basic fields and the
+ type-specific fields listed above. Extension data
+ is never returned with the BODY fetch, but may be
+ returned with a BODYSTRUCTURE fetch. Extension
+ data, if present, must be in the defined order.
+
+ The extension data of a non-multipart body part are
+ in the following order:
+
+
+
+
+Crispin [Page 48]
+
+RFC 1730 IMAP4 December 1994
+
+
+ body MD5
+ A string giving the content MD5 value as defined
+ in [MIME-1].
+
+ Any following extension data are not yet defined in
+ this version of the protocol, and would be as
+ described above under multipart extension data.
+
+ ENVELOPE A parenthesized list that describes the envelope
+ structure of a message. This 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 structure 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 parenthesized lists of
+ address structures.
+
+ An address structure is a parenthesized list that
+ describes an electronic mail address. The fields
+ of an address structure are in the following order:
+ personal name, [SMTP] at-domain-list (source
+ route), mailbox name, and host name.
+
+ [RFC-822] group syntax is indicated by a special
+ form of address structure in which the host name
+ field is NIL. If the mailbox name field is also
+ NIL, this is an end of group marker (semi-colon in
+ RFC 822 syntax). If the mailbox name field is
+ non-NIL, this is a start of group marker, and the
+ mailbox name field holds the group name phrase.
+
+ Any field of an envelope or address structure that
+ is not applicable is presented as 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.
+
+
+
+
+
+
+
+
+
+
+Crispin [Page 49]
+
+RFC 1730 IMAP4 December 1994
+
+
+ FLAGS A parenthesized list of flags that are set for this
+ message. This may include keywords as well as the
+ following system flags:
+
+ \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
+
+ \Draft Message has not completed composition
+ (marked as a draft).
+
+ as well as the following special flag, which may be
+ fetched but not stored:
+
+ \Recent Message has arrived since the previous
+ time this mailbox was selected.
+
+ INTERNALDATE A string containing the date and time of final
+ delivery of the message as defined by [SMTP].
+
+ RFC822 A string expressing the message in [RFC-822]
+ format. The header portion of the message must be
+ 7-bit. 8-bit characters are permitted only in the
+ non-header portion of the message only if there are
+ [MIME-1] data in the message that identify the
+ character set of the message.
+
+ RFC822.HEADER A string expressing the [RFC-822] format header of
+ the message, including the delimiting blank line
+ between the header and the body. The entire string
+ must be 7-bit; 8-bit characters are not permitted
+ in headers. RFC822.HEADER is used to return data
+ for the RFC822.HEADER, RFC822.HEADER.LINES, and
+ RFC822.HEADER.LINES.NOT FETCH data items. Note
+ that a blank line is always included regardless of
+ header line restrictions.
+
+ RFC822.SIZE A number expressing the number of octets in the
+ message in [RFC-822] format.
+
+
+
+
+
+
+Crispin [Page 50]
+
+RFC 1730 IMAP4 December 1994
+
+
+ RFC822.TEXT A string expressing the text body of the message,
+ omitting the [RFC-822] header. 8-bit characters
+ are permitted only if there are [MIME-1] data in
+ the message that identify the character set of the
+ message.
+
+ UID A number expressing the unique identifier of the
+ message.
+
+
+ Example: S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827)
+
+
+7.3.5. Obsolete Responses
+
+ In addition to the responses listed in here, client implementations
+ MUST accept and implement the obsolete responses described in
+ Appendix B.
+
+
+
+7.4. Server Responses - Command Continuation Request
+
+ The command completion request response is indicated by a "+" token
+ instead of a tag. This form of response indicates that the server is
+ ready to accept the continuation of a command from the client. The
+ remainder of this response is a line of text.
+
+ This response is used in the AUTHORIZATION command to transmit server
+ data to the client, and request additional client data. This
+ response is also used if an argument to any command is a literal.
+
+ The client is not permitted to send the octets of the literal unless
+ the server indicates that it expects it. This permits the server to
+ process commands and reject errors on a line-by-line basis. The
+ remainder of the command, including the CRLF that terminates a
+ command, follows the octets of the literal. If there are any
+ additional command arguments the literal octets are followed by a
+ space and those arguments.
+
+ Example: C: A001 LOGIN {11}
+ S: + Ready for additional command text
+ C: FRED FOOBAR {7}
+ S: + Ready for additional command text
+ C: fat man
+ S: A001 OK LOGIN completed
+ C: A044 BLURDYBLOOP {102856}
+ S: A044 BAD No such command as "BLURDYBLOOP"
+
+
+
+Crispin [Page 51]
+
+RFC 1730 IMAP4 December 1994
+
+
+8. Sample IMAP4 session
+
+ The following is a transcript of an IMAP4 session. A long line in
+ this sample is broken for editorial clarity.
+
+ S: * OK IMAP4 Service Ready
+ C: a001 login mrc secret
+ S: a001 OK LOGIN completed
+ C: a002 select inbox
+ S: * 18 EXISTS
+ S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
+ S: * 2 RECENT
+ S: * OK [UNSEEN 17] Message 17 is the first unseen message
+ S: * OK [UIDVALIDITY 3857529045] UIDs valid
+ S: a002 OK [READ-WRITE] SELECT completed
+ C: a003 fetch 12 full
+ S: * 12 FETCH (FLAGS (\Seen) INTERNALDATE "14-Jul-1993 02:44:25 -0700"
+ RFC822.SIZE 4282 ENVELOPE ("Wed, 14 Jul 1993 02:23:25 -0700 (PDT)"
+ "IMAP4 WG mtg summary and minutes"
+ (("Terry Gray" NIL "gray" "cac.washington.edu"))
+ (("Terry Gray" NIL "gray" "cac.washington.edu"))
+ (("Terry Gray" NIL "gray" "cac.washington.edu"))
+ ((NIL NIL "imap" "cac.washington.edu"))
+ ((NIL NIL "minutes" "CNRI.Reston.VA.US")
+ ("John Klensin" NIL "KLENSIN" "INFOODS.MIT.EDU")) NIL NIL
+ "<B27397-0100000@cac.washington.edu>")
+ BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028 92))
+ S: a003 OK FETCH completed
+ C: a004 fetch 12 rfc822.header
+ S: * 12 FETCH (RFC822.HEADER {346}
+ S: Date: Wed, 14 Jul 1993 02:23:25 -0700 (PDT)
+ S: From: Terry Gray <gray@cac.washington.edu>
+ S: Subject: IMAP4 WG mtg summary and minutes
+ S: To: imap@cac.washington.edu
+ S: cc: minutes@CNRI.Reston.VA.US, John Klensin <KLENSIN@INFOODS.MIT.EDU>
+ S: Message-Id: <B27397-0100000@cac.washington.edu>
+ S: MIME-Version: 1.0
+ S: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
+ S:
+ S: )
+ S: a004 OK FETCH completed
+ C: a005 store 12 +flags \deleted
+ S: * 12 FETCH (FLAGS (\Seen \Deleted))
+ S: a005 OK +FLAGS completed
+ C: a006 logout
+ S: * BYE IMAP4 server terminating connection
+ S: a006 OK LOGOUT completed
+
+
+
+
+Crispin [Page 52]
+
+RFC 1730 IMAP4 December 1994
+
+
+9. 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 (SPACE) and
+ not a comma.
+
+ Except as noted otherwise, all alphabetic characters are
+ case-insensitive. The use of upper or lower case characters to
+ define token strings is for editorial clarity only. Implementations
+ MUST accept these strings in a case-insensitive fashion.
+
+ Syntax marked as obsolete may be encountered with implementations
+ written for an earlier version of this protocol (e.g. IMAP2). New
+ implementations SHOULD accept obsolete syntax as input, but MUST NOT
+ otherwise use such syntax.
+
+ address ::= "(" addr_name SPACE addr_adl SPACE addr_mailbox
+ SPACE addr_host ")"
+
+ addr_adl ::= nstring
+
+ addr_host ::= nstring
+ ;; NIL indicates [RFC-822] group syntax
+
+ addr_mailbox ::= nstring
+ ;; NIL indicates end of [RFC-822] group; if
+ ;; non-NIL and addr_host is NIL, holds
+ ;; [RFC-822] group name
+
+ addr_name ::= nstring
+
+ alpha ::= "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" /
+ "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" /
+ "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" /
+ "Y" / "Z" /
+ "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" /
+ "i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" /
+ "q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" /
+ "y" / "z" /
+ ;; Case-sensitive
+
+ append ::= "APPEND" SPACE mailbox [SPACE flag_list]
+ [SPACE date_time] SPACE literal
+
+ astring ::= atom / string
+
+
+
+
+
+Crispin [Page 53]
+
+RFC 1730 IMAP4 December 1994
+
+
+ atom ::= 1*ATOM_CHAR
+
+ ATOM_CHAR ::= <any CHAR except atom_specials>
+
+ atom_specials ::= "(" / ")" / "{" / SPACE / CTLs / list_wildcards /
+ quoted_specials
+
+ authenticate ::= "AUTHENTICATE" SPACE auth_type *(CRLF base64)
+
+ auth_type ::= atom
+
+ base64 ::= *(4base64_char) [base64_terminal]
+
+ base64_char ::= alpha / digit / "+" / "/"
+
+ base64_terminal ::= (2base64_char "==") / (3base64_char "=")
+
+ body ::= "(" body_type_1part / body_type_mpart ")"
+
+ body_extension ::= nstring / number / "(" 1#body_extension ")"
+ ;; Future expansion. Client implementations
+ ;; MUST accept body_extension fields. Server
+ ;; implementations MUST NOT generate
+ ;; body_extension fields except as defined by
+ ;; future standard or standards-track
+ ;; revisions of this specification.
+
+ body_ext_1part ::= body_fld_md5 [SPACE 1#body_extension]
+ ;; MUST NOT be returned on non-extensible
+ ;; "BODY" fetch
+
+ body_ext_mpart ::= body_fld_param [SPACE 1#body_extension]]
+ ;; MUST NOT be returned on non-extensible
+ ;; "BODY" fetch
+
+ body_fields ::= body_fld_param SPACE body_fld_id SPACE
+ body_fld_desc SPACE body_fld_enc SPACE
+ body_fld_octets
+
+ body_fld_desc ::= nstring
+
+ body_fld_enc ::= (<"> ("7BIT" / "8BIT" / "BINARY" / "BASE64"/
+ "QUOTED-PRINTABLE") <">) / string
+
+ body_fld_id ::= nstring
+
+ body_fld_lines ::= number
+
+
+
+
+Crispin [Page 54]
+
+RFC 1730 IMAP4 December 1994
+
+
+ body_fld_md5 ::= nstring
+
+ body_fld_octets ::= number
+
+ body_fld_param ::= "(" 1#(string string) ")" / nil
+
+ body_fld_subtyp ::= string
+
+ body_type_1part ::= (body_type_basic / body_type_msg / body_type_text)
+ [SPACE body_ext_1part]
+
+ body_type_basic ::= (<"> ("APPLICATION" / "AUDIO" / "IMAGE" /
+ "MESSAGE" / "VIDEO") <">) / string) SPACE
+ body_fld_subtyp SPACE body_fields
+ ;; MESSAGE subtype MUST NOT be "RFC822"
+
+ body_type_mpart ::= 1*body SPACE body_fld_subtyp
+ [SPACE body_ext_mpart]
+
+ body_type_msg ::= <"> "MESSAGE" <"> SPACE <"> "RFC822" <"> SPACE
+ body_fields SPACE envelope SPACE body SPACE
+ body_fld_lines
+
+ body_type_text ::= <"> "TEXT" <"> SPACE body_fld_subtyp SPACE
+ body_fields SPACE body_fld_lines
+
+ capability ::= atom
+ ;; Must begin with "X" or be registered with
+ ;; IANA as standard or standards-track
+
+ capability_data ::= "CAPABILITY" SPACE "IMAP4" [SPACE 1#capability]
+
+ CHAR ::= <any 7-bit US-ASCII character except NUL,
+ 0x01 - 0x7f>
+
+ CHAR8 ::= <any 8-bit octet except NUL, 0x01 - 0xff>
+
+ command ::= tag SPACE (command_any / command_auth /
+ command_nonauth / command_select) CRLF
+ ;; Modal based on state
+
+ command_any ::= "CAPABILITY" / "LOGOUT" / "NOOP" / x_command
+ ;; Valid in all states
+
+ command_auth ::= append / create / delete / examine / find / list /
+ lsub / rename / select / subscribe / unsubscribe /
+ ;; Valid only in Authenticated or Selected state
+
+
+
+
+Crispin [Page 55]
+
+RFC 1730 IMAP4 December 1994
+
+
+ command_nonauth ::= login / authenticate
+ ;; Valid only when in Non-Authenticated state
+
+ command_select ::= "CHECK" / "CLOSE" / "EXPUNGE" /
+ copy / fetch / partial / store / uid / search
+ ;; Valid only when in Selected state
+
+ continue_req ::= "+" SPACE (resp_text / base64)
+
+ copy ::= "COPY" SPACE set SPACE mailbox
+
+ CR ::= <ASCII CR, carriage return, 0x0C>
+
+ create ::= "CREATE" SPACE mailbox
+ ;; Use of INBOX gives a NO error
+
+ CRLF ::= CR LF
+
+ CTL ::= <any ASCII control character and DEL,
+ 0x00 - 0x1f, 0x7f>
+
+ date ::= date_text / <"> date_text <">
+
+ date_day ::= 1*2digit
+ ;; Day of month
+
+ date_day_fixed ::= (SPACE digit) / 2digit
+ ;; Fixed-format version of date_day
+
+ date_month ::= "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" /
+ "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec"
+
+ date_text ::= date_day "-" date_month "-" (date_year /
+ date_year_old)
+
+ date_year ::= 4digit
+
+ date_year_old ::= 2digit
+ ;; OBSOLETE, (year - 1900)
+
+ date_time ::= <"> (date_time_new / date_time_old) <">
+
+ date_time_new ::= date_day_fixed "-" date_month "-" date_year
+ SPACE time SPACE zone
+
+ date_time_old ::= date_day_fixed "-" date_month "-" date_year_old
+ SPACE time "-" zone_old
+ ;; OBSOLETE
+
+
+
+Crispin [Page 56]
+
+RFC 1730 IMAP4 December 1994
+
+
+ delete ::= "DELETE" SPACE mailbox
+ ;; Use of INBOX gives a NO error
+
+ digit ::= "0" / digit_nz
+
+ digit_nz ::= "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" /
+ "9"
+
+ envelope ::= "(" env_date SPACE env_subject SPACE env_from
+ SPACE env_sender SPACE env_reply-to SPACE env_to
+ SPACE env_cc SPACE env_bcc SPACE env_in-reply-to
+ SPACE env_message-id ")"
+
+ env_bcc ::= "(" 1*address ")" / nil
+
+ env_cc ::= "(" 1*address ")" / nil
+
+ env_date ::= nstring
+
+ env_from ::= "(" 1*address ")" / nil
+
+ env_in-reply-to ::= nstring
+
+ env_message-id ::= nstring
+
+ env_reply-to ::= "(" 1*address ")" / nil
+
+ env_sender ::= "(" 1*address ")" / nil
+
+ env_subject ::= nstring
+
+ env_to ::= "(" 1*address ")" / nil
+
+ examine ::= "EXAMINE" SPACE mailbox
+
+ fetch ::= "FETCH" SPACE set SPACE ("ALL" / "FULL" /
+ "FAST" / fetch_att / "(" 1#fetch_att ")")
+
+ fetch_att ::= "BODY" / "BODYSTRUCTURE" /
+ "BODY" [".PEEK"] "[" section "]" / "ENVELOPE" /
+ "FLAGS" / "INTERNALDATE" / "UID" /
+ "RFC822" (([".TEXT"] [".PEEK"]) / ".SIZE" /
+ (".HEADER" [".LINES" [".NOT"] SPACE header_list])
+
+ find ::= "FIND" SPACE ["ALL."] "MAILBOXES" SPACE
+ list_mailbox
+ ;; OBSOLETE
+
+
+
+
+Crispin [Page 57]
+
+RFC 1730 IMAP4 December 1994
+
+
+ flag ::= "\Answered" / "\Flagged" / "\Deleted" /
+ "\Seen" / "\Draft" / flag_keyword /
+ flag_extension
+
+ flag_extension ::= "\" atom
+ ;; Future expansion. Client implementations
+ ;; MUST accept flag_extension flags. Server
+ ;; implementations MUST NOT generate
+ ;; flag_extension flags except as defined by
+ ;; future standard or standards-track
+ ;; revisions of this specification.
+
+ flag_keyword ::= atom
+
+ flag_list ::= "(" #flag ")"
+
+ greeting ::= "*" SPACE (resp_cond_auth / resp_cond_bye) CRLF
+
+ header_line ::= astring
+
+ header_list ::= "(" 1#header_line ")"
+
+ LF ::= <ASCII LF, line feed, 0x0A>
+
+ list ::= "LIST" SPACE mailbox SPACE list_mailbox
+
+ list_mailbox ::= 1*(ATOM_CHAR / list_wildcards) / string
+
+ list_wildcards ::= "%" / "*"
+
+ literal ::= "{" number "}" CRLF *CHAR8
+ ;; Number represents the number of CHAR8 octets
+
+ login ::= "LOGIN" SPACE userid SPACE password
+
+ lsub ::= "LSUB" SPACE mailbox SPACE list_mailbox
+
+ mailbox ::= "INBOX" / astring
+ ;; INBOX is case-insensitive; other names may be
+ ;; case-sensitive depending on implementation.
+
+ mailbox_data ::= "FLAGS" SPACE flag_list /
+ "LIST" SPACE mailbox_list /
+ "LSUB" SPACE mailbox_list /
+ "MAILBOX" SPACE text /
+ "SEARCH" [SPACE 1#nz_number] /
+ number SPACE "EXISTS" / number SPACE "RECENT"
+
+
+
+
+Crispin [Page 58]
+
+RFC 1730 IMAP4 December 1994
+
+
+ mailbox_list ::= "(" #("\Marked" / "\Noinferiors" /
+ "\Noselect" / "\Unmarked" / flag_extension) ")"
+ SPACE (<"> QUOTED_CHAR <"> / nil) SPACE mailbox
+
+ message_data ::= nz_number SPACE ("EXPUNGE" /
+ ("FETCH" SPACE msg_fetch) / msg_obsolete)
+
+ msg_fetch ::= "(" 1#("BODY" SPACE body /
+ "BODYSTRUCTURE" SPACE body /
+ "BODY[" section "]" SPACE nstring /
+ "ENVELOPE" SPACE envelope /
+ "FLAGS" SPACE "(" #(flag / "\Recent") ")" /
+ "INTERNALDATE" SPACE date_time /
+ "RFC822" [".HEADER" / ".TEXT"] SPACE nstring /
+ "RFC822.SIZE" SPACE number /
+ "UID" SPACE uniqueid) ")"
+
+ msg_obsolete ::= "COPY" / ("STORE" SPACE msg_fetch)
+ ;; OBSOLETE untagged data responses
+
+ nil ::= "NIL"
+
+ nstring ::= string / nil
+
+ number ::= 1*digit
+ ;; Unsigned 32-bit integer
+ ;; (0 <= n < 4,294,967,296)
+
+ nz_number ::= digit_nz *digit
+ ;; Non-zero unsigned 32-bit integer
+ ;; (0 < n < 4,294,967,296)
+
+ partial ::= "PARTIAL" SPACE nz_number SPACE
+ ("BODY" [".PEEK"] "[" section "]" /
+ "RFC822" (([".TEXT"] [".PEEK"]) / ".HEADER")
+ SPACE number SPACE number
+
+ password ::= astring
+
+ quoted ::= <"> *QUOTED_CHAR <">
+
+ QUOTED_CHAR ::= <any TEXT_CHAR except quoted_specials> /
+ "\" quoted_specials
+
+ quoted_specials ::= <"> / "\"
+
+ rename ::= "RENAME" SPACE mailbox SPACE mailbox
+ ;; Use of INBOX as a destination gives a NO error
+
+
+
+Crispin [Page 59]
+
+RFC 1730 IMAP4 December 1994
+
+
+ response ::= *response_data response_done
+
+ response_data ::= "*" SPACE (resp_cond_state / resp_cond_bye /
+ mailbox_data / message_data / capability_data)
+ CRLF
+
+ response_done ::= response_tagged / response_fatal
+
+ response_fatal ::= "*" SPACE resp_cond_bye CRLF
+
+ response_tagged ::= tag SPACE resp_cond_state CRLF
+
+ resp_cond_auth ::= ("OK" / "PREAUTH") SPACE resp_text
+ ;; Authentication condition
+
+ resp_cond_bye ::= "BYE" SPACE resp_text
+ ;; Server will disconnect condition
+
+ resp_cond_state ::= ("OK" / "NO" / "BAD") SPACE resp_text
+ ;; Status condition
+
+ resp_text ::= ["[" resp_text_code "]" SPACE] (text_mime2 / text)
+
+ resp_text_code ::= "ALERT" / "PARSE" /
+ "PERMANENTFLAGS" SPACE "(" #(flag / "\*") ")" /
+ "READ-ONLY" / "READ-WRITE" / "TRYCREATE" /
+ "UIDVALIDITY" SPACE nz_number /
+ "UNSEEN" SPACE nz_number /
+ atom [SPACE 1*<any TEXT_CHAR except "]">]
+
+ search ::= "SEARCH" SPACE ["CHARSET" SPACE astring SPACE]
+ search_criteria
+ ;; Character set must be registered with IANA
+ ;; as a MIME character set
+
+ search_criteria ::= 1#search_key
+
+ search_key ::= search_new / search_old
+
+ search_new ::= "DRAFT" /
+ "HEADER" SPACE header_line SPACE astring /
+ "LARGER" SPACE number / "NOT" SPACE search_key /
+ "OR" SPACE search_key SPACE search_key /
+ "SENTBEFORE" SPACE date / "SENTON" SPACE date /
+ "SENTSINCE" SPACE date / "SMALLER" SPACE number /
+ "UID" SPACE set / "UNDRAFT" / set /
+ "(" search_criteria ")"
+ ;; New in IMAP4
+
+
+
+Crispin [Page 60]
+
+RFC 1730 IMAP4 December 1994
+
+
+ search_old ::= "ALL" / "ANSWERED" / "BCC" SPACE astring /
+ "BEFORE" SPACE date / "BODY" SPACE astring /
+ "CC" SPACE astring / "DELETED" / "FLAGGED" /
+ "FROM" SPACE astring /
+ "KEYWORD" SPACE flag_keyword / "NEW" / "OLD" /
+ "ON" SPACE date / "RECENT" / "SEEN" /
+ "SINCE" SPACE date / "SUBJECT" SPACE astring /
+ "TEXT" SPACE astring / "TO" SPACE astring /
+ "UNANSWERED" / "UNDELETED" / "UNFLAGGED" /
+ "UNKEYWORD" SPACE flag_keyword / "UNSEEN"
+ ;; Defined in [IMAP2]
+
+ section ::= "0" / nz_number ["." section]
+
+ select ::= "SELECT" SPACE mailbox
+
+ sequence_num ::= nz_number / "*"
+ ;; * is the largest number in use. For message
+ ;; sequence numbers, it is the number of messages
+ ;; in the mailbox. For unique identifiers, it is
+ ;; the unique identifier of the last message in
+ ;; the mailbox.
+
+ set ::= sequence_num / (sequence_num ":" sequence_num) /
+ (set "," set)
+ ;; Identifies a set of messages. For message
+ ;; sequence numbers, these are consecutive
+ ;; numbers from 1 to the number of messages in
+ ;; the mailbox
+ ;; Comma delimits individual numbers, colon
+ ;; delimits between two numbers inclusive.
+ ;; Example: 2,4:7,9,12:* is 2,4,5,6,7,9,12,13,
+ ;; 14,15 for a mailbox with 15 messages.
+
+ SPACE ::= <ASCII SP, space, 0x20>
+
+ store ::= "STORE" SPACE set SPACE store_att_flags
+
+ store_att_flags ::= (["+" / "-"] "FLAGS" [".SILENT"]) SPACE
+ (flag_list / #flag)
+
+ string ::= quoted / literal
+
+ subscribe ::= ("SUBSCRIBE" SPACE mailbox) / subscribe_obs
+
+ subscribe_obs ::= "SUBSCRIBE" SPACE "MAILBOX" SPACE mailbox
+ ;;OBSOLETE
+
+
+
+
+Crispin [Page 61]
+
+RFC 1730 IMAP4 December 1994
+
+
+ tag ::= 1*<any ATOM_CHAR except "+">
+
+ text ::= 1*TEXT_CHAR
+
+ text_mime2 ::= "=?" <charset> "?" <encoding> "?"
+ <encoded-text> "?="
+ ;; Syntax defined in [MIME-2]
+
+ TEXT_CHAR ::= <any CHAR except CR and LF>
+
+ time ::= 2digit ":" 2digit ":" 2digit
+ ;; Hours minutes seconds
+
+ uid ::= "UID" SPACE (copy / fetch / search / store)
+ ;; Unique identifiers used instead of message
+ ;; sequence numbers
+
+ uniqueid ::= nz_number
+ ;; Strictly ascending
+
+ unsubscribe ::= ("UNSUBSCRIBE" SPACE mailbox) / unsubscribe_obs
+
+ unsubscribe_obs ::= "UNSUBSCRIBE" SPACE "MAILBOX" SPACE mailbox
+ ;;OBSOLETE
+
+ userid ::= astring
+
+ x_command ::= "X" atom <experimental command arguments>
+
+ zone ::= ("+" / "-") 4digit
+ ;; Signed four-digit value of hhmm representing
+ ;; hours and minutes west of Greenwich (that is,
+ ;; (the amount that the given time differs from
+ ;; Universal Time). Subtracting the timezone
+ ;; from the given time will give the UT form.
+ ;; The Universal Time zone is "+0000".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin [Page 62]
+
+RFC 1730 IMAP4 December 1994
+
+
+ zone_old ::= "UT" / "GMT" / "Z" / ;; +0000
+ "AST" / "EDT" / ;; -0400
+ "EST" / "CDT" / ;; -0500
+ "CST" / "MDT" / ;; -0600
+ "MST" / "PDT" / ;; -0700
+ "PST" / "YDT" / ;; -0800
+ "YST" / "HDT" / ;; -0900
+ "HST" / "BDT" / ;; -1000
+ "BST" / ;; -1100
+ "A" / "B" / "C" / "D" / "E" / "F" / ;; +1 to +6
+ "G" / "H" / "I" / "K" / "L" / "M" / ;; +7 to +12
+ "N" / "O" / "P" / "Q" / "R" / "S" / ;; -1 to -6
+ "T" / "U" / "V" / "W" / "X" / "Y" ;; -7 to -12
+ ;; OBSOLETE
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin [Page 63]
+
+RFC 1730 IMAP4 December 1994
+
+
+10. Author's Note
+
+ This document is a revision or rewrite of earlier documents, and
+ supercedes the protocol specification in those documents: IMAP4
+ Internet drafts, the IMAP2bis Internet drafts, unpublished
+ IMAP2bis.TXT document, RFC 1176, and RFC 1064.
+
+
+11. Security Considerations
+
+ IMAP4 protocol transactions, including electronic mail data, are sent
+ in the clear over the network unless the optional privacy protection
+ is negotiated in the AUTHENTICATE command.
+
+ A server error message for an AUTHENTICATE command which fails due to
+ invalid credentials should not detail why the credentials are
+ invalid.
+
+ Use of the LOGIN command sends passwords in the clear. This can be
+ avoided by using the AUTHENTICATE command instead.
+
+ A server error message for a failing LOGIN command should not specify
+ that the user name, as opposed to the password, is invalid.
+
+ Additional security considerations are discussed in the section
+ discussing the AUTHENTICATE and LOGIN commands.
+
+
+12. Author's Address
+
+ Mark R. Crispin
+ Networks and Distributed Computing, JE-30
+ University of Washington
+ Seattle, WA 98195
+
+ Phone: (206) 543-5762
+
+ EMail: MRC@CAC.Washington.EDU
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin [Page 64]
+
+RFC 1730 IMAP4 December 1994
+
+
+Appendices
+
+A. Obsolete Commands
+
+ The following commands are OBSOLETE. It is NOT required to support
+ any of these commands in new server implementations. These commands
+ are documented here for the benefit of implementors who may wish to
+ support them for compatibility with old client implementations.
+
+ The section headings of these commands are intended to correspond
+ with where they would be located in the main document if they were
+ not obsoleted.
+
+
+A.6.3.OBS.1. FIND ALL.MAILBOXES Command
+
+ Arguments: mailbox name with possible wildcards
+
+ Data: untagged responses: MAILBOX
+
+ Result: OK - find completed
+ NO - find failure: can't list that name
+ BAD - command unknown or arguments invalid
+
+ The FIND ALL.MAILBOXES command returns a subset of names from the
+ complete set of all names available to the user. It returns zero
+ or more untagged MAILBOX replies. The mailbox argument to FIND
+ ALL.MAILBOXES is similar to that for LIST with an empty reference,
+ except that the characters "%" and "?" match a single character.
+
+ Example: C: A002 FIND ALL.MAILBOXES *
+ S: * MAILBOX blurdybloop
+ S: * MAILBOX INBOX
+ S: A002 OK FIND ALL.MAILBOXES completed
+
+
+A.6.3.OBS.2. FIND MAILBOXES Command
+
+ Arguments: mailbox name with possible wildcards
+
+ Data: untagged responses: MAILBOX
+
+ Result: OK - find completed
+ NO - find failure: can't list that name
+ BAD - command unknown or arguments invalid
+
+ The FIND MAILBOXES command returns a subset of names from the set
+ of names that the user has declared as being "active" or
+
+
+
+Crispin [Page 65]
+
+RFC 1730 IMAP4 December 1994
+
+
+ "subscribed". It returns zero or more untagged MAILBOX replies.
+ The mailbox argument to FIND MAILBOXES is similar to that for LSUB
+ with an empty reference, except that the characters "%" and "?"
+ match a single character.
+
+ Example: C: A002 FIND MAILBOXES *
+ S: * MAILBOX blurdybloop
+ S: * MAILBOX INBOX
+ S: A002 OK FIND MAILBOXES completed
+
+
+A.6.3.OBS.3. SUBSCRIBE MAILBOX Command
+
+ Arguments: mailbox name
+
+ Data: no specific data for this command
+
+ Result: OK - subscribe completed
+ NO - subscribe failure: can't subscribe to that name
+ BAD - command unknown or arguments invalid
+
+ The SUBSCRIBE MAILBOX command is identical in effect to the
+ SUBSCRIBE command. A server which implements this command must be
+ able to distinguish between a SUBSCRIBE MAILBOX command and a
+ SUBSCRIBE command with a mailbox name argument of "MAILBOX".
+
+ Example: C: A002 SUBSCRIBE MAILBOX #news.comp.mail.mime
+ S: A002 OK SUBSCRIBE MAILBOX to #news.comp.mail.mime
+ completed
+ C: A003 SUBSCRIBE MAILBOX
+ S: A003 OK SUBSCRIBE to MAILBOX completed
+
+
+A.6.3.OBS.4. UNSUBSCRIBE MAILBOX Command
+
+ Arguments: mailbox name
+
+ Data: no specific data for this command
+
+ Result: OK - unsubscribe completed
+ NO - unsubscribe failure: can't unsubscribe that name
+ BAD - command unknown or arguments invalid
+
+ The UNSUBSCRIBE MAILBOX command is identical in effect to the
+ UNSUBSCRIBE command. A server which implements this command must
+ be able to distinguish between a UNSUBSCRIBE MAILBOX command and
+ an UNSUBSCRIBE command with a mailbox name argument of "MAILBOX".
+
+
+
+
+Crispin [Page 66]
+
+RFC 1730 IMAP4 December 1994
+
+
+ Example: C: A002 UNSUBSCRIBE MAILBOX #news.comp.mail.mime
+ S: A002 OK UNSUBSCRIBE MAILBOX from #news.comp.mail.mime
+ completed
+ C: A003 UNSUBSCRIBE MAILBOX
+ S: A003 OK UNSUBSCRIBE from MAILBOX completed
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin [Page 67]
+
+RFC 1730 IMAP4 December 1994
+
+
+B. Obsolete Responses
+
+ The following responses are OBSOLETE. Except as noted below, these
+ responses MUST NOT be transmitted by new server implementations.
+
+ The section headings of these responses are intended to correspond
+ with where they would be located in the main document if they were
+ not obsoleted.
+
+
+B.7.2.OBS.1. MAILBOX Response
+
+ Data: name
+
+ The MAILBOX response MUST NOT be transmitted by server
+ implementations except in response to the obsolete FIND MAILBOXES
+ and FIND ALL.MAILBOXES commands. Client implementations that do
+ not use these commands MAY ignore this response. It is documented
+ here for the benefit of implementors who may wish to support it
+ for compatibility with old client implementations.
+
+ This response occurs as a result of the FIND MAILBOXES and FIND
+ ALL.MAILBOXES commands. It returns a single name that matches the
+ FIND specification. There are no attributes or hierarchy
+ delimiter.
+
+ Example: S: * MAILBOX blurdybloop
+
+
+B.7.3.OBS.1. COPY Response
+
+ Data: none
+
+ The COPY response MUST NOT be transmitted by new server
+ implementations. Client implementations MUST ignore the COPY
+ response. It is documented here for the benefit of client
+ implementors who may encounter this response from old server
+ implementations.
+
+ In some experimental versions of this protocol, this response was
+ returned in response to a COPY command to indicate on a
+ per-message basis that the message was copied successfully.
+
+ Example: S: * 44 COPY
+
+
+
+
+
+
+
+Crispin [Page 68]
+
+RFC 1730 IMAP4 December 1994
+
+
+B.7.3.OBS.2. STORE Response
+
+ Data: message data
+
+ The STORE response MUST NOT be transmitted by new server
+ implementations. Client implementations MUST treat the STORE
+ response as equivalent to the FETCH response. It is documented
+ here for the benefit of client implementors who may encounter this
+ response from old server implementations.
+
+ In some experimental versions of this protocol, this response was
+ returned instead of FETCH in response to a STORE command to report
+ the new value of the flags.
+
+ Example: S: * 69 STORE (FLAGS (\Deleted))
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin [Page 69]
+
+RFC 1730 IMAP4 December 1994
+
+
+C. References
+
+
+ [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731.
+ Carnegie-Mellon University, December 1994.
+
+ [IMAP-COMPAT] Crispin, M. "IMAP4 Compatibility with IMAP2 and
+ IMAP2bis", RFC 1732, University of Washington, December 1994.
+
+ [IMAP-DISC] Austein, R. "Synchronization Operations for Disconnected
+ IMAP4 Clients", Work in Progress.
+
+ [IMAP-MODEL] Crispin, M. "Distributed Electronic Mail Models in
+ IMAP4", RFC 1733, University of Washington, December 1994.
+
+ [IMAP-NAMING] Crispin, M. "Mailbox Naming Convention in IMAP4", Work
+ in Progress.
+
+ [IMAP2] Crispin, M., "Interactive Mail Access Protocol - Version 2",
+ RFC 1176, University of Washington, August 1990.
+
+ [IMSP] Myers, J. "IMSP -- Internet Message Support Protocol", Work in
+ Progress.
+
+ [MIME-1] Borenstein, N., and Freed, N., "MIME (Multipurpose Internet
+ Mail Extensions) Part One: Mechanisms for Specifying and Describing
+ the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft,
+ September 1993.
+
+ [MIME-2] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
+ Part Two: Message Header Extensions for Non-ASCII Text", RFC 1522,
+ University of Tennessee, September 1993.
+
+ [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
+ Messages", STD 11, RFC 822, University of Delaware, August 1982.
+
+ [SMTP] Postel, Jonathan B. "Simple Mail Transfer Protocol", STD 10,
+ RFC 821, USC/Information Sciences Institute, August 1982.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin [Page 70]
+
+RFC 1730 IMAP4 December 1994
+
+
+E. IMAP4 Keyword Index
+
+
+ +FLAGS <flag list> (store command data item) ............... 34
+ +FLAGS.SILENT <flag list> (store command data item) ........ 34
+ -FLAGS <flag list> (store command data item) ............... 34
+ -FLAGS.SILENT <flag list> (store command data item) ........ 34
+ ALERT (response code) ...................................... 39
+ ALL (fetch item) ........................................... 29
+ ALL (search key) ........................................... 27
+ ANSWERED (search key) ...................................... 27
+ APPEND (command) ........................................... 22
+ AUTHENTICATE (command) ..................................... 12
+ BAD (response) ............................................. 41
+ BCC <string> (search key) .................................. 27
+ BEFORE <date> (search key) ................................. 27
+ BODY (fetch item) .......................................... 29
+ BODY (fetch result) ........................................ 46
+ BODY <string> (search key) ................................. 27
+ BODY.PEEK[<section>] (fetch item) .......................... 30
+ BODYSTRUCTURE (fetch item) ................................. 31
+ BODYSTRUCTURE (fetch result) ............................... 47
+ BODY[<section>] (fetch item) ............................... 29
+ BODY[section] (fetch result) ............................... 46
+ BYE (response) ............................................. 41
+ CAPABILITY (command) ....................................... 10
+ CAPABILITY (response) ...................................... 42
+ CC <string> (search key) ................................... 27
+ CHECK (command) ............................................ 23
+ CLOSE (command) ............................................ 24
+ COPY (command) ............................................. 34
+ COPY (response) ............................................ 68
+ CREATE (command) ........................................... 17
+ DELETE (command) ........................................... 18
+ DELETED (search key) ....................................... 27
+ DRAFT (search key) ......................................... 27
+ ENVELOPE (fetch item) ...................................... 31
+ ENVELOPE (fetch result) .................................... 49
+ EXAMINE (command) .......................................... 16
+ EXISTS (response) .......................................... 45
+ EXPUNGE (command) .......................................... 25
+ EXPUNGE (response) ......................................... 45
+ FAST (fetch item) .......................................... 31
+ FETCH (command) ............................................ 29
+ FETCH (response) ........................................... 46
+ FIND ALL.MAILBOXES (command) ............................... 65
+ FIND MAILBOXES (command) ................................... 65
+ FLAGGED (search key) ....................................... 27
+ FLAGS (fetch item) ......................................... 31
+
+
+
+Crispin [Page 71]
+
+RFC 1730 IMAP4 December 1994
+
+
+
+ FLAGS (fetch result) ....................................... 50
+ FLAGS (response) ........................................... 44
+ FLAGS <flag list> (store command data item) ................ 34
+ FLAGS.SILENT <flag list> (store command data item) ......... 34
+ FROM <string> (search key) ................................. 27
+ FULL (fetch item) .......................................... 31
+ HEADER <field-name> <string> (search key) .................. 27
+ INTERNALDATE (fetch item) .................................. 31
+ INTERNALDATE (fetch result) ................................ 50
+ KEYWORD <flag> (search key) ................................ 27
+ LARGER <n> (search key) .................................... 27
+ LIST (command) ............................................. 20
+ LIST (response) ............................................ 43
+ LOGIN (command) ............................................ 14
+ LOGOUT (command) ........................................... 11
+ LSUB (command) ............................................. 22
+ LSUB (response) ............................................ 44
+ MAILBOX (response) ......................................... 68
+ NEW (search key) ........................................... 27
+ NO (response) .............................................. 40
+ NOOP (command) ............................................. 11
+ NOT <search-key> (search key) .............................. 28
+ OK (response) .............................................. 40
+ OLD (search key) ........................................... 28
+ ON <date> (search key) ..................................... 28
+ OR <search-key1> <search-key2> (search key) ................ 28
+ PARSE (response code) ...................................... 39
+ PARTIAL (command) .......................................... 32
+ PERMANENTFLAGS (response code) ............................. 39
+ PREAUTH (response) ......................................... 41
+ READ-ONLY (response code) .................................. 39
+ READ-WRITE (response code) ................................. 39
+ RECENT (response) .......................................... 45
+ RECENT (search key) ........................................ 28
+ RENAME (command) ........................................... 18
+ RFC822 (fetch item) ........................................ 31
+ RFC822 (fetch result) ...................................... 50
+ RFC822.HEADER (fetch item) ................................. 31
+ RFC822.HEADER (fetch result) ............................... 50
+ RFC822.HEADER.LINES <header_list> (fetch item) ............. 31
+ RFC822.HEADER.LINES.NOT <header_list> (fetch item) ......... 32
+ RFC822.PEEK (fetch item) ................................... 31
+ RFC822.SIZE (fetch item) ................................... 32
+ RFC822.SIZE (fetch result) ................................. 50
+ RFC822.TEXT (fetch item) ................................... 32
+ RFC822.TEXT (fetch result) ................................. 51
+ RFC822.TEXT.PEEK (fetch item) .............................. 32
+ SEARCH (command) ........................................... 25
+
+
+
+Crispin [Page 72]
+
+RFC 1730 IMAP4 December 1994
+
+
+
+ SEARCH (response) .......................................... 44
+ SEEN (search key) .......................................... 28
+ SELECT (command) ........................................... 15
+ SENTBEFORE <date> (search key) ............................. 28
+ SENTON <date> (search key) ................................. 28
+ SENTSINCE <date> (search key) .............................. 28
+ SINCE <date> (search key) .................................. 28
+ SMALLER <n> (search key) ................................... 28
+ STORE (command) ............................................ 33
+ STORE (response) ........................................... 69
+ SUBJECT <string> (search key) .............................. 28
+ SUBSCRIBE (command) ........................................ 19
+ SUBSCRIBE MAILBOX (command) ................................ 66
+ TEXT <string> (search key) ................................. 28
+ TO <string> (search key) ................................... 28
+ TRYCREATE (response code) .................................. 39
+ UID (command) .............................................. 35
+ UID (fetch item) ........................................... 32
+ UID (fetch result) ......................................... 51
+ UID <message set> (search key) ............................. 28
+ UIDVALIDITY (response code) ................................ 40
+ UNANSWERED (search key) .................................... 29
+ UNDELETED (search key) ..................................... 29
+ UNDRAFT (search key) ....................................... 29
+ UNFLAGGED (search key) ..................................... 29
+ UNKEYWORD <flag> (search key) .............................. 29
+ UNSEEN (response code) ..................................... 40
+ UNSEEN (search key) ........................................ 29
+ UNSUBSCRIBE (command) ...................................... 19
+ UNSUBSCRIBE MAILBOX (command) .............................. 66
+ X<atom> (command) .......................................... 37
+ \Answered (system flag) .................................... 50
+ \Deleted (system flag) ..................................... 50
+ \Draft (system flag) ....................................... 50
+ \Flagged (system flag) ..................................... 50
+ \Marked (mailbox name attribute) ........................... 43
+ \Noinferiors (mailbox name attribute) ...................... 43
+ \Noselect (mailbox name attribute) ......................... 43
+ \Recent (system flag) ...................................... 50
+ \Seen (system flag) ........................................ 50
+ \Unmarked (mailbox name attribute) ......................... 43
+
+
+
+
+
+
+
+
+
+
+Crispin [Page 73]
+
|