diff options
Diffstat (limited to 'RFC/rfc1730.txt')
| -rw-r--r-- | RFC/rfc1730.txt | 4318 |
1 files changed, 0 insertions, 4318 deletions
diff --git a/RFC/rfc1730.txt b/RFC/rfc1730.txt deleted file mode 100644 index fcf72ad7..00000000 --- a/RFC/rfc1730.txt +++ /dev/null @@ -1,4318 +0,0 @@ -
-
-
-
-
-
-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]
-
|