summaryrefslogtreecommitdiff
path: root/imap/docs/rfc/rfc3501.txt
diff options
context:
space:
mode:
Diffstat (limited to 'imap/docs/rfc/rfc3501.txt')
-rw-r--r--imap/docs/rfc/rfc3501.txt6052
1 files changed, 0 insertions, 6052 deletions
diff --git a/imap/docs/rfc/rfc3501.txt b/imap/docs/rfc/rfc3501.txt
deleted file mode 100644
index 6f470dd1..00000000
--- a/imap/docs/rfc/rfc3501.txt
+++ /dev/null
@@ -1,6052 +0,0 @@
-
-
-
-
-
-
-Network Working Group M. Crispin
-Request for Comments: 3501 University of Washington
-Obsoletes: 2060 March 2003
-Category: Standards Track
-
-
- INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1
-
-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.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-Abstract
-
- The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1)
- allows a client to access and manipulate electronic mail messages on
- a server. IMAP4rev1 permits manipulation of mailboxes (remote
- message folders) in a way that is functionally equivalent to local
- folders. IMAP4rev1 also provides the capability for an offline
- client to resynchronize with the server.
-
- IMAP4rev1 includes operations for creating, deleting, and renaming
- mailboxes, checking for new messages, permanently removing messages,
- setting and clearing flags, RFC 2822 and RFC 2045 parsing, searching,
- and selective fetching of message attributes, texts, and portions
- thereof. Messages in IMAP4rev1 are accessed by the use of numbers.
- These numbers are either message sequence numbers or unique
- identifiers.
-
- IMAP4rev1 supports a single server. A mechanism for accessing
- configuration information to support multiple IMAP4rev1 servers is
- discussed in RFC 2244.
-
- IMAP4rev1 does not specify a means of posting mail; this function is
- handled by a mail transfer protocol such as RFC 2821.
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 1]
-
-RFC 3501 IMAPv4 March 2003
-
-
-Table of Contents
-
- IMAP4rev1 Protocol Specification ................................ 4
- 1. How to Read This Document ............................... 4
- 1.1. Organization of This Document ........................... 4
- 1.2. Conventions Used in This Document ....................... 4
- 1.3. Special Notes to Implementors ........................... 5
- 2. Protocol Overview ....................................... 6
- 2.1. Link Level .............................................. 6
- 2.2. Commands and Responses .................................. 6
- 2.2.1. Client Protocol Sender and Server Protocol Receiver ..... 6
- 2.2.2. Server Protocol Sender and Client Protocol Receiver ..... 7
- 2.3. Message Attributes ...................................... 8
- 2.3.1. Message Numbers ......................................... 8
- 2.3.1.1. Unique Identifier (UID) Message Attribute ....... 8
- 2.3.1.2. Message Sequence Number Message Attribute ....... 10
- 2.3.2. Flags Message Attribute ................................. 11
- 2.3.3. Internal Date Message Attribute ......................... 12
- 2.3.4. [RFC-2822] Size Message Attribute ....................... 12
- 2.3.5. Envelope Structure Message Attribute .................... 12
- 2.3.6. Body Structure Message Attribute ........................ 12
- 2.4. Message Texts ........................................... 13
- 3. State and Flow Diagram .................................. 13
- 3.1. Not Authenticated State ................................. 13
- 3.2. Authenticated State ..................................... 13
- 3.3. Selected State .......................................... 13
- 3.4. Logout State ............................................ 14
- 4. Data Formats ............................................ 16
- 4.1. Atom .................................................... 16
- 4.2. Number .................................................. 16
- 4.3. String .................................................. 16
- 4.3.1. 8-bit and Binary Strings ................................ 17
- 4.4. Parenthesized List ...................................... 17
- 4.5. NIL ..................................................... 17
- 5. Operational Considerations .............................. 18
- 5.1. Mailbox Naming .......................................... 18
- 5.1.1. Mailbox Hierarchy Naming ................................ 19
- 5.1.2. Mailbox Namespace Naming Convention ..................... 19
- 5.1.3. Mailbox International Naming Convention ................. 19
- 5.2. Mailbox Size and Message Status Updates ................. 21
- 5.3. Response when no Command in Progress .................... 21
- 5.4. Autologout Timer ........................................ 22
- 5.5. Multiple Commands in Progress ........................... 22
- 6. Client Commands ........................................ 23
- 6.1. Client Commands - Any State ............................ 24
- 6.1.1. CAPABILITY Command ..................................... 24
- 6.1.2. NOOP Command ........................................... 25
- 6.1.3. LOGOUT Command ......................................... 26
-
-
-
-Crispin Standards Track [Page 2]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 6.2. Client Commands - Not Authenticated State .............. 26
- 6.2.1. STARTTLS Command ....................................... 27
- 6.2.2. AUTHENTICATE Command ................................... 28
- 6.2.3. LOGIN Command .......................................... 30
- 6.3. Client Commands - Authenticated State .................. 31
- 6.3.1. SELECT Command ......................................... 32
- 6.3.2. EXAMINE Command ........................................ 34
- 6.3.3. CREATE Command ......................................... 34
- 6.3.4. DELETE Command ......................................... 35
- 6.3.5. RENAME Command ......................................... 37
- 6.3.6. SUBSCRIBE Command ...................................... 39
- 6.3.7. UNSUBSCRIBE Command .................................... 39
- 6.3.8. LIST Command ........................................... 40
- 6.3.9. LSUB Command ........................................... 43
- 6.3.10. STATUS Command ......................................... 44
- 6.3.11. APPEND Command ......................................... 46
- 6.4. Client Commands - Selected State ....................... 47
- 6.4.1. CHECK Command .......................................... 47
- 6.4.2. CLOSE Command .......................................... 48
- 6.4.3. EXPUNGE Command ........................................ 49
- 6.4.4. SEARCH Command ......................................... 49
- 6.4.5. FETCH Command .......................................... 54
- 6.4.6. STORE Command .......................................... 58
- 6.4.7. COPY Command ........................................... 59
- 6.4.8. UID Command ............................................ 60
- 6.5. Client Commands - Experimental/Expansion ............... 62
- 6.5.1. X<atom> Command ........................................ 62
- 7. Server Responses ....................................... 62
- 7.1. Server Responses - Status Responses .................... 63
- 7.1.1. OK Response ............................................ 65
- 7.1.2. NO Response ............................................ 66
- 7.1.3. BAD Response ........................................... 66
- 7.1.4. PREAUTH Response ....................................... 67
- 7.1.5. BYE Response ........................................... 67
- 7.2. Server Responses - Server and Mailbox Status ........... 68
- 7.2.1. CAPABILITY Response .................................... 68
- 7.2.2. LIST Response .......................................... 69
- 7.2.3. LSUB Response .......................................... 70
- 7.2.4 STATUS Response ........................................ 70
- 7.2.5. SEARCH Response ........................................ 71
- 7.2.6. FLAGS Response ......................................... 71
- 7.3. Server Responses - Mailbox Size ........................ 71
- 7.3.1. EXISTS Response ........................................ 71
- 7.3.2. RECENT Response ........................................ 72
- 7.4. Server Responses - Message Status ...................... 72
- 7.4.1. EXPUNGE Response ....................................... 72
- 7.4.2. FETCH Response ......................................... 73
- 7.5. Server Responses - Command Continuation Request ........ 79
-
-
-
-Crispin Standards Track [Page 3]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 8. Sample IMAP4rev1 connection ............................ 80
- 9. Formal Syntax .......................................... 81
- 10. Author's Note .......................................... 92
- 11. Security Considerations ................................ 92
- 11.1. STARTTLS Security Considerations ....................... 92
- 11.2. Other Security Considerations .......................... 93
- 12. IANA Considerations .................................... 94
- Appendices ..................................................... 95
- A. References ............................................. 95
- B. Changes from RFC 2060 .................................. 97
- C. Key Word Index ......................................... 103
- Author's Address ............................................... 107
- Full Copyright Statement ....................................... 108
-
-IMAP4rev1 Protocol Specification
-
-1. How to Read This Document
-
-1.1. Organization of This Document
-
- This document is written from the point of view of the implementor of
- an IMAP4rev1 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 IMAP4rev1
- 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, do not attempt to deduce command syntax from the command
- section alone; instead refer to the Formal Syntax section.
-
-1.2. Conventions Used in This Document
-
- "Conventions" are basic principles or procedures. Document
- conventions are noted in this section.
-
- In examples, "C:" and "S:" indicate lines sent by the client and
- server respectively.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to
- be interpreted as described in [KEYWORDS].
-
- The word "can" (not "may") is used to refer to a possible
- circumstance or situation, as opposed to an optional facility of the
- protocol.
-
-
-
-Crispin Standards Track [Page 4]
-
-RFC 3501 IMAPv4 March 2003
-
-
- "User" is used to refer to a human user, whereas "client" refers to
- the software being run by the user.
-
- "Connection" refers to the entire sequence of client/server
- interaction from the initial establishment of the network connection
- until its termination.
-
- "Session" refers to the sequence of client/server interaction from
- the time that a mailbox is selected (SELECT or EXAMINE command) until
- the time that selection ends (SELECT or EXAMINE of another mailbox,
- CLOSE command, or connection termination).
-
- Characters are 7-bit US-ASCII unless otherwise specified. Other
- character sets are indicated using a "CHARSET", as described in
- [MIME-IMT] and defined in [CHARSET]. CHARSETs have important
- additional semantics in addition to defining character set; refer to
- these documents for more detail.
-
- There are several protocol conventions in IMAP. These refer to
- aspects of the specification which are not strictly part of the IMAP
- protocol, but reflect generally-accepted practice. Implementations
- need to be aware of these conventions, and avoid conflicts whether or
- not they implement the convention. For example, "&" may not be used
- as a hierarchy delimiter since it conflicts with the Mailbox
- International Naming Convention, and other uses of "&" in mailbox
- names are impacted as well.
-
-1.3. Special Notes to Implementors
-
- Implementors of the IMAP protocol are strongly encouraged to read the
- IMAP implementation recommendations document [IMAP-IMPLEMENTATION] in
- conjunction with this document, to help understand the intricacies of
- this protocol and how best to build an interoperable product.
-
- IMAP4rev1 is designed to be upwards compatible from the [IMAP2] and
- unpublished IMAP2bis protocols. IMAP4rev1 is largely compatible with
- the IMAP4 protocol described in RFC 1730; the exception being in
- certain facilities added in RFC 1730 that proved problematic and were
- subsequently removed. In the course of the evolution of IMAP4rev1,
- some aspects in the earlier protocols have become obsolete. Obsolete
- commands, responses, and data formats which an IMAP4rev1
- implementation can encounter when used with an earlier implementation
- are described in [IMAP-OBSOLETE].
-
- Other compatibility issues with IMAP2bis, the most common variant of
- the earlier protocol, are discussed in [IMAP-COMPAT]. A full
- discussion of compatibility issues with rare (and presumed extinct)
-
-
-
-
-Crispin Standards Track [Page 5]
-
-RFC 3501 IMAPv4 March 2003
-
-
- variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is
- primarily of historical interest.
-
- IMAP was originally developed for the older [RFC-822] standard, and
- as a consequence several fetch items in IMAP incorporate "RFC822" in
- their name. With the exception of RFC822.SIZE, there are more modern
- replacements; for example, the modern version of RFC822.HEADER is
- BODY.PEEK[HEADER]. In all cases, "RFC822" should be interpreted as a
- reference to the updated [RFC-2822] standard.
-
-2. Protocol Overview
-
-2.1. Link Level
-
- The IMAP4rev1 protocol assumes a reliable data stream such as that
- provided by TCP. When TCP is used, an IMAP4rev1 server listens on
- port 143.
-
-2.2. Commands and Responses
-
- An IMAP4rev1 connection consists of the establishment of a
- client/server network 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 IMAP4rev1 client or server is either reading a line, or is
- reading a sequence of octets with a known count followed by a line.
-
-2.2.1. Client Protocol Sender and Server Protocol Receiver
-
- The client command begins an operation. Each client command is
- prefixed with an 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.
-
- Clients MUST follow the syntax outlined in this specification
- strictly. It is a syntax error to send a command with missing or
- extraneous spaces or arguments.
-
- 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
-
-
-
-
-Crispin Standards Track [Page 6]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 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 a 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. In all cases, the client
- MUST send a complete command (including receiving all
- command continuation request responses and command
- continuations for the command) before initiating a new
- command.
-
- The protocol receiver of an IMAP4rev1 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
- 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 a protocol error such as
- unrecognized command or command syntax error).
-
- Servers SHOULD enforce the syntax outlined in this specification
- strictly. Any client command with a protocol syntax error, including
- (but not limited to) missing or extraneous spaces or arguments,
-
-
-
-Crispin Standards Track [Page 7]
-
-RFC 3501 IMAPv4 March 2003
-
-
- SHOULD be rejected, and the client given a BAD server completion
- response.
-
- The protocol receiver of an IMAP4rev1 client reads a response line
- from the server. It then takes action on the response based upon the
- first token of the response, which can be a tag, a "*", or a "+".
-
- A client MUST be prepared to accept any server response at all times.
- This includes server data that was not 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, the data MUST be recorded.
-
- This topic is discussed in greater detail in the Server Responses
- section.
-
-2.3. Message Attributes
-
- In addition to message text, each message has several attributes
- associated with it. These attributes can be retrieved individually
- or in conjunction with other attributes or message texts.
-
-2.3.1. Message Numbers
-
- Messages in IMAP4rev1 are accessed by one of two numbers; the unique
- identifier or the message sequence number.
-
-
-2.3.1.1. Unique Identifier (UID) Message Attribute
-
- A 32-bit value assigned to each message, which when used with the
- unique identifier validity value (see below) forms a 64-bit value
- that MUST NOT refer to any other message in the mailbox or any
- subsequent mailbox with the same name forever. Unique identifiers
- are assigned in a strictly ascending fashion in the mailbox; as each
- message is added to the mailbox it is assigned a higher UID than the
- message(s) which were added previously. Unlike message sequence
- numbers, unique identifiers are not necessarily contiguous.
-
- The unique identifier of a message MUST NOT change during the
- session, and SHOULD NOT change between sessions. Any change of
- unique identifiers between sessions MUST be detectable using the
- UIDVALIDITY mechanism discussed below. Persistent unique identifiers
- are required for 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].
-
-
-
-
-
-Crispin Standards Track [Page 8]
-
-RFC 3501 IMAPv4 March 2003
-
-
- Associated with every mailbox are two values which aid in unique
- identifier handling: the next unique identifier value and the unique
- identifier validity value.
-
- The next unique identifier value is the predicted value that will be
- assigned to a new message in the mailbox. Unless the unique
- identifier validity also changes (see below), the next unique
- identifier value MUST have the following two characteristics. First,
- the next unique identifier value MUST NOT change unless new messages
- are added to the mailbox; and second, the next unique identifier
- value MUST change whenever new messages are added to the mailbox,
- even if those new messages are subsequently expunged.
-
- Note: The next unique identifier value is intended to
- provide a means for a client to determine whether any
- messages have been delivered to the mailbox since the
- previous time it checked this value. It is not intended to
- provide any guarantee that any message will have this
- unique identifier. A client can only assume, at the time
- that it obtains the next unique identifier value, that
- messages arriving after that time will have a UID greater
- than or equal to that value.
-
- The unique identifier validity value is sent in a UIDVALIDITY
- response code in an OK untagged response at mailbox selection time.
- If unique identifiers from an earlier session fail to persist in this
- session, the unique identifier validity value MUST be greater than
- the one used in the earlier session.
-
- Note: Ideally, unique identifiers SHOULD persist at all
- times. Although this specification recognizes that failure
- to persist can be unavoidable in certain server
- environments, it STRONGLY ENCOURAGES message store
- implementation techniques that avoid this problem. For
- example:
-
- 1) Unique identifiers MUST be strictly ascending in the
- mailbox at all times. If the physical message store is
- re-ordered by a non-IMAP agent, this requires that the
- unique identifiers in the mailbox be regenerated, since
- the former unique identifiers are no longer strictly
- ascending as a result of the re-ordering.
-
- 2) If the message store has no mechanism to store unique
- identifiers, it must regenerate unique identifiers at
- each session, and each session must have a unique
- UIDVALIDITY value.
-
-
-
-
-Crispin Standards Track [Page 9]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 3) If the mailbox is deleted and a new mailbox with the
- same name is created at a later date, the server must
- either keep track of unique identifiers from the
- previous instance of the mailbox, or it must assign a
- new UIDVALIDITY value to the new instance of the
- mailbox. A good UIDVALIDITY value to use in this case
- is 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 identifiers
- will never be reused, even in the case of a mailbox
- being deleted (or renamed) and a new mailbox by the
- same name created at some future time.
-
- 4) The combination of mailbox name, UIDVALIDITY, and UID
- must refer to a single immutable message on that server
- forever. In particular, the internal date, [RFC-2822]
- size, envelope, body structure, and message texts
- (RFC822, RFC822.HEADER, RFC822.TEXT, and all BODY[...]
- fetch data items) must never change. This does not
- include message numbers, nor does it include attributes
- that can be set by a STORE command (e.g., FLAGS).
-
-
-2.3.1.2. Message Sequence Number Message Attribute
-
- A relative position from 1 to the number of messages in the mailbox.
- This position MUST be ordered by ascending unique identifier. As
- each new message is added, it is assigned a message sequence number
- that is 1 higher than the number of messages in the mailbox before
- that new message was added.
-
- Message sequence numbers can be reassigned during the session. For
- example, when a message is permanently removed (expunged) from the
- mailbox, the message sequence number for all subsequent messages is
- decremented. The number of messages in the mailbox is also
- decremented. Similarly, a new message can be assigned a message
- sequence number that was once held by some other message prior to an
- expunge.
-
- In addition to accessing messages by relative position in the
- mailbox, message sequence numbers can be used in mathematical
- calculations. For example, if an untagged "11 EXISTS" is received,
- and previously an untagged "8 EXISTS" was received, three new
- messages have arrived with message sequence numbers of 9, 10, and 11.
- Another example, if message 287 in a 523 message mailbox has UID
- 12345, there are exactly 286 messages which have lesser UIDs and 236
- messages which have greater UIDs.
-
-
-
-
-Crispin Standards Track [Page 10]
-
-RFC 3501 IMAPv4 March 2003
-
-
-2.3.2. Flags Message Attribute
-
- A list of zero or more named tokens associated with the message. A
- flag is set by its addition to this list, and is cleared by its
- removal. There are two types of flags in IMAP4rev1. A flag of
- either type can be permanent or session-only.
-
- A system flag is a flag name that is pre-defined in this
- specification. All system flags begin with "\". Certain system
- flags (\Deleted and \Seen) have special semantics described
- elsewhere. The currently-defined system flags are:
-
- \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).
-
- \Recent
- Message is "recently" arrived in this mailbox. This session
- is the first session to have been notified about this
- message; if the session is read-write, subsequent sessions
- will not see \Recent set for this message. This flag can not
- be altered by the client.
-
- If it is not possible to determine whether or not this
- session is the first session to be notified about a message,
- then that message SHOULD be considered recent.
-
- If multiple connections have the same mailbox selected
- simultaneously, it is undefined which of these connections
- will see newly-arrived messages with \Recent set and which
- will see it without \Recent set.
-
- A keyword is defined by the server implementation. Keywords do not
- begin with "\". Servers MAY permit the client to define new keywords
- in the mailbox (see the description of the PERMANENTFLAGS response
- code for more information).
-
-
-
-
-Crispin Standards Track [Page 11]
-
-RFC 3501 IMAPv4 March 2003
-
-
- A flag can be permanent or session-only on a per-flag basis.
- Permanent flags are those which the client can add or remove from the
- message flags permanently; that is, concurrent and subsequent
- sessions will see any change in permanent flags. Changes to session
- flags are valid only in that session.
-
- Note: The \Recent system flag is a special case of a
- session flag. \Recent can not be used as an argument in a
- STORE or APPEND command, and thus can not be changed at
- all.
-
-2.3.3. Internal Date Message Attribute
-
- The internal date and time of the message on the server. This
- is not the date and time in the [RFC-2822] header, but rather a
- date and time which reflects when the message was received. In
- the case of messages delivered via [SMTP], this SHOULD be the
- date and time of final delivery of the message as defined by
- [SMTP]. In the case of messages delivered by the IMAP4rev1 COPY
- command, this SHOULD be the internal date and time of the source
- message. In the case of messages delivered by the IMAP4rev1
- APPEND command, this SHOULD be the date and time as specified in
- the APPEND command description. All other cases are
- implementation defined.
-
-2.3.4. [RFC-2822] Size Message Attribute
-
- The number of octets in the message, as expressed in [RFC-2822]
- format.
-
-2.3.5. Envelope Structure Message Attribute
-
- A parsed representation of the [RFC-2822] header of the message.
- Note that the IMAP Envelope structure is not the same as an
- [SMTP] envelope.
-
-2.3.6. Body Structure Message Attribute
-
- A parsed representation of the [MIME-IMB] body structure
- information of the message.
-
-
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 12]
-
-RFC 3501 IMAPv4 March 2003
-
-
-2.4. Message Texts
-
- In addition to being able to fetch the full [RFC-2822] text of a
- message, IMAP4rev1 permits the fetching of portions of the full
- message text. Specifically, it is possible to fetch the
- [RFC-2822] message header, [RFC-2822] message body, a [MIME-IMB]
- body part, or a [MIME-IMB] header.
-
-3. State and Flow Diagram
-
- Once the connection between client and server is established, an
- IMAP4rev1 connection is in one of four states. The initial
- state is identified in the server greeting. Most commands are
- only valid in certain states. It is a protocol error for the
- client to attempt a command while the connection is in an
- inappropriate state, and the server will respond with a BAD or
- NO (depending upon server implementation) command completion
- result.
-
-3.1. Not Authenticated State
-
- In the not authenticated state, the client 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 the authenticated state, the client 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, after an error in
- selecting a mailbox, or after a successful CLOSE command.
-
-3.3. Selected State
-
- In a selected state, a mailbox has been selected to access.
- This state is entered when a mailbox has been successfully
- selected.
-
-
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 13]
-
-RFC 3501 IMAPv4 March 2003
-
-
-3.4. Logout State
-
- In the logout state, the connection is being terminated. This
- state can be entered as a result of a client request (via the
- LOGOUT command) or by unilateral action on the part of either
- the client or server.
-
- If the client requests the logout state, the server MUST send an
- untagged BYE response and a tagged OK response to the LOGOUT
- command before the server closes the connection; and the client
- MUST read the tagged OK response to the LOGOUT command before
- the client closes the connection.
-
- A server MUST NOT unilaterally close the connection without
- sending an untagged BYE response that contains the reason for
- having done so. A client SHOULD NOT unilaterally close the
- connection, and instead SHOULD issue a LOGOUT command. If the
- server detects that the client has unilaterally closed the
- connection, the server MAY omit the untagged BYE response and
- simply close its connection.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 14]
-
-RFC 3501 IMAPv4 March 2003
-
-
- +----------------------+
- |connection established|
- +----------------------+
- ||
- \/
- +--------------------------------------+
- | server greeting |
- +--------------------------------------+
- || (1) || (2) || (3)
- \/ || ||
- +-----------------+ || ||
- |Not Authenticated| || ||
- +-----------------+ || ||
- || (7) || (4) || ||
- || \/ \/ ||
- || +----------------+ ||
- || | Authenticated |<=++ ||
- || +----------------+ || ||
- || || (7) || (5) || (6) ||
- || || \/ || ||
- || || +--------+ || ||
- || || |Selected|==++ ||
- || || +--------+ ||
- || || || (7) ||
- \/ \/ \/ \/
- +--------------------------------------+
- | Logout |
- +--------------------------------------+
- ||
- \/
- +-------------------------------+
- |both sides close the 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 Standards Track [Page 15]
-
-RFC 3501 IMAPv4 March 2003
-
-
-4. Data Formats
-
- IMAP4rev1 uses textual commands and responses. Data in
- IMAP4rev1 can be in one of several forms: atom, number, string,
- parenthesized list, or NIL. Note that a particular data item
- may take more than one form; for example, a data item defined as
- using "astring" syntax may be either an atom or a string.
-
-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: either literal or 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 limitations of characters
- which may be used.
-
- 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 represented 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 Standards Track [Page 16]
-
-RFC 3501 IMAPv4 March 2003
-
-
-4.3.1. 8-bit and Binary Strings
-
- 8-bit textual and binary mail is supported through the use of a
- [MIME-IMB] content transfer encoding. IMAP4rev1 implementations MAY
- transmit 8-bit or multi-octet characters in literals, but SHOULD do
- so only when the [CHARSET] 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.
-
-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 can 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 form "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 ().
-
- Note: NIL is never used for any data item which takes the
- form of an atom. For example, a mailbox name of "NIL" is a
- mailbox named NIL as opposed to a non-existent mailbox
- name. This is because mailbox uses "astring" syntax which
- is an atom or a string. Conversely, an addr-name of NIL is
- a non-existent personal name, because addr-name uses
- "nstring" syntax which is NIL or a string, but never an
- atom.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 17]
-
-RFC 3501 IMAPv4 March 2003
-
-
-5. Operational Considerations
-
- The following rules are listed here to ensure that all IMAP4rev1
- implementations interoperate properly.
-
-5.1. Mailbox Naming
-
- Mailbox names are 7-bit. Client implementations MUST NOT attempt to
- create 8-bit mailbox names, and SHOULD interpret any 8-bit mailbox
- names returned by LIST or LSUB as UTF-8. Server implementations
- SHOULD prohibit the creation of 8-bit mailbox names, and SHOULD NOT
- return 8-bit mailbox names in LIST or LSUB. See section 5.1.3 for
- more information on how to represent non-ASCII mailbox names.
-
- Note: 8-bit mailbox names were undefined in earlier
- versions of this protocol. Some sites used a local 8-bit
- character set to represent non-ASCII mailbox names. Such
- usage is not interoperable, and is now formally deprecated.
-
- The case-insensitive mailbox name INBOX is a special name reserved to
- mean "the primary mailbox for this user on this server". The
- interpretation of all other names is implementation-dependent.
-
- In particular, this specification takes no position on case
- sensitivity in non-INBOX mailbox names. Some server implementations
- are fully case-sensitive; others preserve case of a newly-created
- name but otherwise are case-insensitive; and yet others coerce names
- to a particular case. Client implementations MUST interact with any
- of these. If a server implementation interprets non-INBOX mailbox
- names as case-insensitive, it MUST treat names using the
- international naming convention specially as described in section
- 5.1.3.
-
- There are certain client considerations when creating a new mailbox
- name:
-
- 1) Any character which is one of the atom-specials (see the Formal
- Syntax) will require that the mailbox name be represented as a
- quoted string or literal.
-
- 2) CTL and other non-graphic characters are difficult to represent
- in a user interface and are best avoided.
-
- 3) Although the list-wildcard characters ("%" and "*") are valid
- in a mailbox name, it is difficult to use such mailbox names
- with the LIST and LSUB commands due to the conflict with
- wildcard interpretation.
-
-
-
-
-Crispin Standards Track [Page 18]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 4) Usually, a character (determined by the server implementation)
- is reserved to delimit levels of hierarchy.
-
- 5) Two characters, "#" and "&", have meanings by convention, and
- should be avoided except when used in that convention.
-
-5.1.1. Mailbox Hierarchy Naming
-
- 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.1.2. Mailbox Namespace Naming Convention
-
- By convention, the first hierarchical element of any mailbox name
- which begins with "#" identifies the "namespace" of the remainder of
- the name. This makes it possible to disambiguate between different
- types of mailbox stores, each of which have their own namespaces.
-
- For example, implementations which offer access to USENET
- newsgroups MAY use the "#news" namespace to partition the
- USENET newsgroup namespace from that of other mailboxes.
- Thus, the comp.mail.misc newsgroup would have a mailbox
- name of "#news.comp.mail.misc", and the name
- "comp.mail.misc" can refer to a different object (e.g., a
- user's private mailbox).
-
-5.1.3. Mailbox International Naming Convention
-
- By convention, international mailbox names in IMAP4rev1 are specified
- using a modified version of the UTF-7 encoding described in [UTF-7].
- Modified UTF-7 may also be usable in servers that implement an
- earlier version of this protocol.
-
- In modified UTF-7, printable US-ASCII characters, except for "&",
- represent themselves; that is, characters with octet values 0x20-0x25
- and 0x27-0x7e. The character "&" (0x26) is represented by the
- two-octet sequence "&-".
-
- All other characters (octet values 0x00-0x1f and 0x7f-0xff) are
- represented in modified BASE64, with a further modification from
- [UTF-7] that "," is used instead of "/". Modified BASE64 MUST NOT be
- used to represent any printing US-ASCII character which can represent
- itself.
-
-
-
-
-
-
-Crispin Standards Track [Page 19]
-
-RFC 3501 IMAPv4 March 2003
-
-
- "&" is used to shift to modified BASE64 and "-" to shift back to
- US-ASCII. There is no implicit shift from BASE64 to US-ASCII, and
- null shifts ("-&" while in BASE64; note that "&-" while in US-ASCII
- means "&") are not permitted. However, all names start in US-ASCII,
- and MUST end in US-ASCII; that is, a name that ends with a non-ASCII
- ISO-10646 character MUST end with a "-").
-
- The purpose of these modifications is to correct the following
- problems with UTF-7:
-
- 1) UTF-7 uses the "+" character for shifting; this conflicts with
- the common use of "+" in mailbox names, in particular USENET
- newsgroup names.
-
- 2) UTF-7's encoding is BASE64 which uses the "/" character; this
- conflicts with the use of "/" as a popular hierarchy delimiter.
-
- 3) UTF-7 prohibits the unencoded usage of "\"; this conflicts with
- the use of "\" as a popular hierarchy delimiter.
-
- 4) UTF-7 prohibits the unencoded usage of "~"; this conflicts with
- the use of "~" in some servers as a home directory indicator.
-
- 5) UTF-7 permits multiple alternate forms to represent the same
- string; in particular, printable US-ASCII characters can be
- represented in encoded form.
-
- Although modified UTF-7 is a convention, it establishes certain
- requirements on server handling of any mailbox name with an
- embedded "&" character. In particular, server implementations
- MUST preserve the exact form of the modified BASE64 portion of a
- modified UTF-7 name and treat that text as case-sensitive, even if
- names are otherwise case-insensitive or case-folded.
-
- Server implementations SHOULD verify that any mailbox name with an
- embedded "&" character, used as an argument to CREATE, is: in the
- correctly modified UTF-7 syntax, has no superfluous shifts, and
- has no encoding in modified BASE64 of any printing US-ASCII
- character which can represent itself. However, client
- implementations MUST NOT depend upon the server doing this, and
- SHOULD NOT attempt to create a mailbox name with an embedded "&"
- character unless it complies with the modified UTF-7 syntax.
-
- Server implementations which export a mail store that does not
- follow the modified UTF-7 convention MUST convert to modified
- UTF-7 any mailbox name that contains either non-ASCII characters
- or the "&" character.
-
-
-
-
-Crispin Standards Track [Page 20]
-
-RFC 3501 IMAPv4 March 2003
-
-
- For example, here is a mailbox name which mixes English,
- Chinese, and Japanese text:
- ~peter/mail/&U,BTFw-/&ZeVnLIqe-
-
- For example, the string "&Jjo!" is not a valid mailbox
- name because it does not contain a shift to US-ASCII
- before the "!". The correct form is "&Jjo-!". The
- string "&U,BTFw-&ZeVnLIqe-" is not permitted because it
- contains a superfluous shift. The correct form is
- "&U,BTF2XlZyyKng-".
-
-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 message
- delivery), change the flags of the messages 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 detail. In particular,
- it is NOT permitted to send an EXISTS response that would reduce the
- number of messages in the mailbox; only the EXPUNGE response can do
- this.
-
- Regardless of what implementation decisions a client makes on
- remembering data from the server, a client implementation MUST record
- mailbox size updates. It MUST NOT assume that any command after the
- 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 Standards Track [Page 21]
-
-RFC 3501 IMAPv4 March 2003
-
-
-5.4. Autologout Timer
-
- If a server has an inactivity autologout timer, the duration of that
- timer MUST be at least 30 minutes. 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 MAY send another command without waiting for the
- completion result response of a command, subject to ambiguity rules
- (see below) and flow control constraints on the underlying data
- stream. Similarly, a server MAY begin processing another command
- before processing the current command to completion, subject to
- ambiguity rules. However, any command continuation request responses
- and command continuations MUST be negotiated before any subsequent
- command is initiated.
-
- The exception is if an ambiguity would result because of a command
- that would affect the results of other commands. Clients MUST NOT
- send multiple commands without waiting if an ambiguity would result.
- If the server detects a possible ambiguity, it MUST execute commands
- to completion in the order given by the client.
-
- The most obvious example of ambiguity is when a command would affect
- the results of another command, e.g., a FETCH of a message's flags
- and a STORE of that same message's flags.
-
- A non-obvious ambiguity occurs with commands that permit an untagged
- EXPUNGE response (commands other than FETCH, STORE, and SEARCH),
- since an untagged EXPUNGE response can invalidate sequence numbers in
- a subsequent command. This is not a problem for FETCH, STORE, or
- SEARCH commands because servers are prohibited from sending EXPUNGE
- responses while any of those commands are in progress. Therefore, if
- the client sends any command other than FETCH, STORE, or SEARCH, it
- MUST wait for the completion result response before sending a command
- with message sequence numbers.
-
- Note: UID FETCH, UID STORE, and UID SEARCH are different
- commands from FETCH, STORE, and SEARCH. If the client
- sends a UID command, it must wait for a completion result
- response before sending a command with message sequence
- numbers.
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 22]
-
-RFC 3501 IMAPv4 March 2003
-
-
- For example, the following non-waiting command sequences are invalid:
-
- FETCH + NOOP + STORE
- STORE + COPY + FETCH
- COPY + COPY
- CHECK + FETCH
-
- The following are examples of valid non-waiting command sequences:
-
- FETCH + STORE + SEARCH + CHECK
- STORE + COPY + EXPUNGE
-
- UID SEARCH + UID SEARCH may be valid or invalid as a non-waiting
- command sequence, depending upon whether or not the second UID
- SEARCH contains message sequence numbers.
-
-6. Client Commands
-
- IMAP4rev1 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 responses to be returned; these
- are identified by "Responses:" 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 responses
- 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.
-
- The state of a connection is only changed by successful commands
- which are documented as changing state. A rejected command (BAD
- response) never changes the state of the connection or of the
- selected mailbox. A failed command (NO response) generally does not
- change the state of the connection or of the selected mailbox; the
- exception being the SELECT and EXAMINE commands.
-
-
-
-Crispin Standards Track [Page 23]
-
-RFC 3501 IMAPv4 March 2003
-
-
-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
-
- Responses: REQUIRED 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 "IMAP4rev1" as one of the listed
- capabilities before the (tagged) OK response.
-
- A capability name which begins with "AUTH=" indicates that the
- server supports that particular authentication mechanism. All
- such names are, by definition, part of this specification. For
- example, the authorization capability for an experimental
- "blurdybloop" authenticator would be "AUTH=XBLURDYBLOOP" and not
- "XAUTH=BLURDYBLOOP" or "XAUTH=XBLURDYBLOOP".
-
- Other capability names refer to extensions, revisions, or
- amendments to this specification. See the documentation of the
- CAPABILITY response for additional information. No capabilities,
- beyond the base IMAP4rev1 set defined in this specification, are
- enabled without explicit client action to invoke the capability.
-
- Client and server implementations MUST implement the STARTTLS,
- LOGINDISABLED, and AUTH=PLAIN (described in [IMAP-TLS])
- capabilities. See the Security Considerations section for
- important information.
-
- See the section entitled "Client Commands -
- Experimental/Expansion" for information about the form of site or
- implementation-specific capabilities.
-
-
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 24]
-
-RFC 3501 IMAPv4 March 2003
-
-
- Example: C: abcd CAPABILITY
- S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI
- LOGINDISABLED
- S: abcd OK CAPABILITY completed
- C: efgh STARTTLS
- S: efgh OK STARTLS completed
- <TLS negotiation, further commands are under [TLS] layer>
- C: ijkl CAPABILITY
- S: * CAPABILITY IMAP4rev1 AUTH=GSSAPI AUTH=PLAIN
- S: ijkl OK CAPABILITY completed
-
-
-6.1.2. NOOP Command
-
- Arguments: none
-
- Responses: no specific responses 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 (this is the
- preferred method to do this). 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 Standards Track [Page 25]
-
-RFC 3501 IMAPv4 March 2003
-
-
-6.1.3. LOGOUT Command
-
- Arguments: none
-
- Responses: REQUIRED 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 connection. 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 IMAP4rev1 Server logging out
- S: A023 OK LOGOUT completed
- (Server and client then close the connection)
-
-6.2. Client Commands - Not Authenticated State
-
- In the not authenticated state, the AUTHENTICATE or LOGIN command
- establishes authentication and enters the authenticated state. The
- AUTHENTICATE command provides a general mechanism for a variety of
- authentication techniques, privacy protection, and integrity
- checking; whereas the LOGIN command uses a traditional user name and
- plaintext password pair and has no means of establishing privacy
- protection or integrity checking.
-
- The STARTTLS command is an alternate form of establishing session
- privacy protection and integrity checking, but does not establish
- authentication or enter the authenticated state.
-
- Server implementations MAY allow access to certain mailboxes without
- establishing authentication. This can be done by means of the
- ANONYMOUS [SASL] authenticator described in [ANONYMOUS]. An older
- convention is a LOGIN command using the userid "anonymous"; in this
- case, a password is required although the server may choose to accept
- any password. The restrictions placed on anonymous users are
- implementation-dependent.
-
- Once authenticated (including as anonymous), it is not possible to
- re-enter not authenticated state.
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 26]
-
-RFC 3501 IMAPv4 March 2003
-
-
- In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
- the following commands are valid in the not authenticated state:
- STARTTLS, AUTHENTICATE and LOGIN. See the Security Considerations
- section for important information about these commands.
-
-6.2.1. STARTTLS Command
-
- Arguments: none
-
- Responses: no specific response for this command
-
- Result: OK - starttls completed, begin TLS negotiation
- BAD - command unknown or arguments invalid
-
- A [TLS] negotiation begins immediately after the CRLF at the end
- of the tagged OK response from the server. Once a client issues a
- STARTTLS command, it MUST NOT issue further commands until a
- server response is seen and the [TLS] negotiation is complete.
-
- The server remains in the non-authenticated state, even if client
- credentials are supplied during the [TLS] negotiation. This does
- not preclude an authentication mechanism such as EXTERNAL (defined
- in [SASL]) from using client identity determined by the [TLS]
- negotiation.
-
- Once [TLS] has been started, the client MUST discard cached
- information about server capabilities and SHOULD re-issue the
- CAPABILITY command. This is necessary to protect against man-in-
- the-middle attacks which alter the capabilities list prior to
- STARTTLS. The server MAY advertise different capabilities after
- STARTTLS.
-
- Example: C: a001 CAPABILITY
- S: * CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED
- S: a001 OK CAPABILITY completed
- C: a002 STARTTLS
- S: a002 OK Begin TLS negotiation now
- <TLS negotiation, further commands are under [TLS] layer>
- C: a003 CAPABILITY
- S: * CAPABILITY IMAP4rev1 AUTH=PLAIN
- S: a003 OK CAPABILITY completed
- C: a004 LOGIN joe password
- S: a004 OK LOGIN completed
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 27]
-
-RFC 3501 IMAPv4 March 2003
-
-
-6.2.2. AUTHENTICATE Command
-
- Arguments: authentication mechanism name
-
- Responses: continuation data can 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 a [SASL] authentication
- mechanism to the server. If the server supports the requested
- authentication mechanism, it performs an authentication protocol
- exchange to authenticate and identify the client. It MAY also
- negotiate an OPTIONAL security layer 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 AUTHENTICATE command does not support the optional "initial
- response" feature of [SASL]. Section 5.1 of [SASL] specifies how
- to handle an authentication mechanism which uses an initial
- response.
-
- The service name specified by this protocol's profile of [SASL] is
- "imap".
-
- The authentication protocol exchange consists of a series of
- server challenges and client responses 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 response consists of a
- single line consisting of a BASE64 encoded string. If the client
- wishes to cancel an authentication exchange, it issues a line
- consisting of a single "*". If the server receives such a
- response, it MUST reject the AUTHENTICATE command by sending a
- tagged BAD response.
-
- If a security layer is negotiated through the [SASL]
- authentication exchange, it 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.
-
- While client and server implementations MUST implement the
- AUTHENTICATE command itself, it is not required to implement any
- authentication mechanisms other than the PLAIN mechanism described
-
-
-
-Crispin Standards Track [Page 28]
-
-RFC 3501 IMAPv4 March 2003
-
-
- in [IMAP-TLS]. Also, an authentication mechanism is not required
- to support any security layers.
-
- Note: a server implementation MUST implement a
- configuration in which it does NOT permit any plaintext
- password mechanisms, unless either the STARTTLS command
- has been negotiated or some other mechanism that
- protects the session from password snooping has been
- provided. Server sites SHOULD NOT use any configuration
- which permits a plaintext password mechanism without
- such a protection mechanism against password snooping.
- Client and server implementations SHOULD implement
- additional [SASL] mechanisms that do not use plaintext
- passwords, such the GSSAPI mechanism described in [SASL]
- and/or the [DIGEST-MD5] mechanism.
-
- Servers and clients can support multiple authentication
- mechanisms. The server SHOULD list its supported authentication
- mechanisms in the response to the CAPABILITY command so that the
- client knows which authentication mechanisms to use.
-
- A server MAY include a CAPABILITY response code in the tagged OK
- response of a successful AUTHENTICATE command in order to send
- capabilities automatically. It is unnecessary for a client to
- send a separate CAPABILITY command if it recognizes these
- automatic capabilities. This should only be done if a security
- layer was not negotiated by the AUTHENTICATE command, because the
- tagged OK response as part of an AUTHENTICATE command is not
- protected by encryption/integrity checking. [SASL] requires the
- client to re-issue a CAPABILITY command in this case.
-
- If an AUTHENTICATE command fails with a NO response, the client
- MAY try another authentication mechanism by issuing another
- AUTHENTICATE command. It MAY also attempt to authenticate by
- using the LOGIN command (see section 6.2.3 for more detail). In
- other words, the client MAY request authentication types in
- decreasing order of preference, with the LOGIN command as a last
- resort.
-
- The authorization identity passed from the client to the server
- during the authentication exchange is interpreted by the server as
- the user name whose privileges the client is requesting.
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 29]
-
-RFC 3501 IMAPv4 March 2003
-
-
- Example: S: * OK IMAP4rev1 Server
- C: A001 AUTHENTICATE GSSAPI
- S: +
- C: YIIB+wYJKoZIhvcSAQICAQBuggHqMIIB5qADAgEFoQMCAQ6iBw
- MFACAAAACjggEmYYIBIjCCAR6gAwIBBaESGxB1Lndhc2hpbmd0
- b24uZWR1oi0wK6ADAgEDoSQwIhsEaW1hcBsac2hpdmFtcy5jYW
- Mud2FzaGluZ3Rvbi5lZHWjgdMwgdCgAwIBAaEDAgEDooHDBIHA
- cS1GSa5b+fXnPZNmXB9SjL8Ollj2SKyb+3S0iXMljen/jNkpJX
- AleKTz6BQPzj8duz8EtoOuNfKgweViyn/9B9bccy1uuAE2HI0y
- C/PHXNNU9ZrBziJ8Lm0tTNc98kUpjXnHZhsMcz5Mx2GR6dGknb
- I0iaGcRerMUsWOuBmKKKRmVMMdR9T3EZdpqsBd7jZCNMWotjhi
- vd5zovQlFqQ2Wjc2+y46vKP/iXxWIuQJuDiisyXF0Y8+5GTpAL
- pHDc1/pIGmMIGjoAMCAQGigZsEgZg2on5mSuxoDHEA1w9bcW9n
- FdFxDKpdrQhVGVRDIzcCMCTzvUboqb5KjY1NJKJsfjRQiBYBdE
- NKfzK+g5DlV8nrw81uOcP8NOQCLR5XkoMHC0Dr/80ziQzbNqhx
- O6652Npft0LQwJvenwDI13YxpwOdMXzkWZN/XrEqOWp6GCgXTB
- vCyLWLlWnbaUkZdEYbKHBPjd8t/1x5Yg==
- S: + YGgGCSqGSIb3EgECAgIAb1kwV6ADAgEFoQMCAQ+iSzBJoAMC
- AQGiQgRAtHTEuOP2BXb9sBYFR4SJlDZxmg39IxmRBOhXRKdDA0
- uHTCOT9Bq3OsUTXUlk0CsFLoa8j+gvGDlgHuqzWHPSQg==
- C:
- S: + YDMGCSqGSIb3EgECAgIBAAD/////6jcyG4GE3KkTzBeBiVHe
- ceP2CWY0SR0fAQAgAAQEBAQ=
- C: YDMGCSqGSIb3EgECAgIBAAD/////3LQBHXTpFfZgrejpLlLImP
- wkhbfa2QteAQAgAG1yYwE=
- S: A001 OK GSSAPI authentication successful
-
- Note: The line breaks within server challenges and client
- responses are for editorial clarity and are not in real
- authenticators.
-
-
-6.2.3. LOGIN Command
-
- Arguments: user name
- password
-
- Responses: no specific responses 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 client to the server and carries
- the plaintext password authenticating this user.
-
-
-
-
-
-
-Crispin Standards Track [Page 30]
-
-RFC 3501 IMAPv4 March 2003
-
-
- A server MAY include a CAPABILITY response code in the tagged OK
- response to a successful LOGIN command in order to send
- capabilities automatically. It is unnecessary for a client to
- send a separate CAPABILITY command if it recognizes these
- automatic capabilities.
-
- Example: C: a001 LOGIN SMITH SESAME
- S: a001 OK LOGIN completed
-
- Note: Use of the LOGIN command over an insecure network
- (such as the Internet) is a security risk, because anyone
- monitoring network traffic can obtain plaintext passwords.
- The LOGIN command SHOULD NOT be used except as a last
- resort, and it is recommended that client implementations
- have a means to disable any automatic use of the LOGIN
- command.
-
- Unless either the STARTTLS command has been negotiated or
- some other mechanism that protects the session from
- password snooping has been provided, a server
- implementation MUST implement a configuration in which it
- advertises the LOGINDISABLED capability and does NOT permit
- the LOGIN command. Server sites SHOULD NOT use any
- configuration which permits the LOGIN command without such
- a protection mechanism against password snooping. A client
- implementation MUST NOT send a LOGIN command if the
- LOGINDISABLED capability is advertised.
-
-6.3. Client Commands - Authenticated State
-
- In the 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 the
- selected state.
-
- In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
- the following commands are valid in the authenticated state: SELECT,
- EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB,
- STATUS, and APPEND.
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 31]
-
-RFC 3501 IMAPv4 March 2003
-
-
-6.3.1. SELECT Command
-
- Arguments: mailbox name
-
- Responses: REQUIRED untagged responses: FLAGS, EXISTS, RECENT
- REQUIRED OK untagged responses: UNSEEN, PERMANENTFLAGS,
- UIDNEXT, UIDVALIDITY
-
- 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.
- Note that earlier versions of this protocol only required the
- FLAGS, EXISTS, and RECENT untagged data; consequently, client
- implementations SHOULD implement default behavior for missing data
- as discussed with the individual item.
-
- FLAGS Defined flags in the mailbox. See the description
- of the FLAGS response for more detail.
-
- <n> EXISTS The number of messages in the mailbox. See the
- description of the EXISTS response for more detail.
-
- <n> RECENT The number of messages with the \Recent flag set.
- See the description of the RECENT response for more
- detail.
-
- OK [UNSEEN <n>]
- The message sequence number of the first unseen
- message in the mailbox. If this is missing, the
- client can not make any assumptions about the first
- unseen message in the mailbox, and needs to issue a
- SEARCH command if it wants to find it.
-
- OK [PERMANENTFLAGS (<list of flags>)]
- A list of message flags that the client can change
- permanently. If this is missing, the client should
- assume that all flags can be changed permanently.
-
- OK [UIDNEXT <n>]
- The next unique identifier value. Refer to section
- 2.3.1.1 for more information. If this is missing,
- the client can not make any assumptions about the
- next unique identifier value.
-
-
-
-Crispin Standards Track [Page 32]
-
-RFC 3501 IMAPv4 March 2003
-
-
- OK [UIDVALIDITY <n>]
- The unique identifier validity value. Refer to
- section 2.3.1.1 for more information. If this is
- missing, the server does not support unique
- identifiers.
-
- Only one mailbox can be selected at a time in a connection;
- simultaneous access to multiple mailboxes requires multiple
- connections. 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 client 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 client 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 server-based .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: * OK [UIDNEXT 4392] Predicted next UID
- S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
- S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
- S: A142 OK [READ-WRITE] SELECT completed
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 33]
-
-RFC 3501 IMAPv4 March 2003
-
-
-6.3.2. EXAMINE Command
-
- Arguments: mailbox name
-
- Responses: REQUIRED untagged responses: FLAGS, EXISTS, RECENT
- REQUIRED OK untagged responses: UNSEEN, PERMANENTFLAGS,
- UIDNEXT, UIDVALIDITY
-
- 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; in particular, EXAMINE MUST NOT
- cause messages to lose the \Recent flag.
-
- 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: * OK [UIDNEXT 4392] Predicted next UID
- 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
-
- Responses: no specific responses 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.
-
-
-
-Crispin Standards Track [Page 34]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 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 intends to create
- mailbox names under this name in the hierarchy. Server
- implementations that do not require this declaration MUST ignore
- the declaration. In any case, the name created is without the
- trailing hierarchy delimiter.
-
- If the server's hierarchy separator character appears elsewhere in
- the name, the server SHOULD create any superior hierarchical names
- that are needed for the CREATE command to be successfully
- completed. In other words, an attempt to create "foo/bar/zap" on
- a server in which "/" is the hierarchy separator character SHOULD
- create foo/ and foo/bar/ if they do not already exist.
-
- 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
-
- 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
-
- Responses: no specific responses for this command
-
- Result: OK - delete completed
- NO - delete failure: can't delete mailbox with that name
- BAD - command unknown or arguments invalid
-
-
-
-
-
-
-
-Crispin Standards Track [Page 35]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 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.
-
- The DELETE command MUST NOT remove inferior hierarchical names.
- For example, if a mailbox "foo" has an inferior "foo.bar"
- (assuming "." is the hierarchy delimiter character), removing
- "foo" MUST NOT remove "foo.bar". It is an error to attempt to
- delete a name that has inferior hierarchical names and also has
- the \Noselect mailbox name attribute (see the description of the
- LIST response for more details).
-
- It is permitted to delete a name that has inferior hierarchical
- names and does not have the \Noselect mailbox name attribute. In
- this case, all messages in that mailbox are removed, and the name
- will acquire the \Noselect mailbox name attribute.
-
- The value of the highest-used unique identifier 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.
-
- Examples: C: A682 LIST "" *
- S: * LIST () "/" blurdybloop
- S: * LIST (\Noselect) "/" foo
- S: * LIST () "/" foo/bar
- S: A682 OK LIST completed
- C: A683 DELETE blurdybloop
- S: A683 OK DELETE completed
- C: A684 DELETE foo
- S: A684 NO Name "foo" has inferior hierarchical names
- C: A685 DELETE foo/bar
- S: A685 OK DELETE Completed
- C: A686 LIST "" *
- S: * LIST (\Noselect) "/" foo
- S: A686 OK LIST completed
- C: A687 DELETE foo
- S: A687 OK DELETE Completed
-
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 36]
-
-RFC 3501 IMAPv4 March 2003
-
-
- C: A82 LIST "" *
- S: * LIST () "." blurdybloop
- S: * LIST () "." foo
- S: * LIST () "." foo.bar
- S: A82 OK LIST completed
- C: A83 DELETE blurdybloop
- S: A83 OK DELETE completed
- C: A84 DELETE foo
- S: A84 OK DELETE Completed
- C: A85 LIST "" *
- S: * LIST () "." foo.bar
- S: A85 OK LIST completed
- C: A86 LIST "" %
- S: * LIST (\Noselect) "." foo
- S: A86 OK LIST completed
-
-
-6.3.5. RENAME Command
-
- Arguments: existing mailbox name
- new mailbox name
-
- Responses: no specific responses 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
-
- 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.
-
- If the name has inferior hierarchical names, then the inferior
- hierarchical names MUST also be renamed. For example, a rename of
- "foo" to "zap" will rename "foo/bar" (assuming "/" is the
- hierarchy delimiter character) to "zap/bar".
-
- If the server's hierarchy separator character appears in the name,
- the server SHOULD create any superior hierarchical names that are
- needed for the RENAME command to complete successfully. In other
- words, an attempt to rename "foo/bar/zap" to baz/rag/zowie on a
- server in which "/" is the hierarchy separator character SHOULD
- create baz/ and baz/rag/ if they do not already exist.
-
-
-
-
-
-Crispin Standards Track [Page 37]
-
-RFC 3501 IMAPv4 March 2003
-
-
- The value of the highest-used unique identifier of the old mailbox
- name 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.
-
- Renaming INBOX is permitted, and has special behavior. It moves
- all messages in INBOX to a new mailbox with the given name,
- leaving INBOX empty. If the server implementation supports
- inferior hierarchical names of INBOX, these are unaffected by a
- rename of INBOX.
-
- Examples: C: A682 LIST "" *
- S: * LIST () "/" blurdybloop
- S: * LIST (\Noselect) "/" foo
- S: * LIST () "/" foo/bar
- S: A682 OK LIST completed
- C: A683 RENAME blurdybloop sarasoop
- S: A683 OK RENAME completed
- C: A684 RENAME foo zowie
- S: A684 OK RENAME Completed
- C: A685 LIST "" *
- S: * LIST () "/" sarasoop
- S: * LIST (\Noselect) "/" zowie
- S: * LIST () "/" zowie/bar
- S: A685 OK LIST completed
-
- C: Z432 LIST "" *
- S: * LIST () "." INBOX
- S: * LIST () "." INBOX.bar
- S: Z432 OK LIST completed
- C: Z433 RENAME INBOX old-mail
- S: Z433 OK RENAME completed
- C: Z434 LIST "" *
- S: * LIST () "." INBOX
- S: * LIST () "." INBOX.bar
- S: * LIST () "." old-mail
- S: Z434 OK LIST completed
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 38]
-
-RFC 3501 IMAPv4 March 2003
-
-
-6.3.6. SUBSCRIBE Command
-
- Arguments: mailbox
-
- Responses: no specific responses 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.
-
- A server MAY validate the mailbox argument to SUBSCRIBE to verify
- that it exists. However, it MUST NOT unilaterally remove an
- existing mailbox name from the subscription list even if a mailbox
- by that name no longer exists.
-
- Note: This requirement is because a server site can
- choose to routinely remove a mailbox with a well-known
- name (e.g., "system-alerts") after its contents expire,
- with the intention of recreating it when new contents
- are appropriate.
-
-
- Example: C: A002 SUBSCRIBE #news.comp.mail.mime
- S: A002 OK SUBSCRIBE completed
-
-
-6.3.7. UNSUBSCRIBE Command
-
- Arguments: mailbox name
-
- Responses: no specific responses 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.
-
- Example: C: A002 UNSUBSCRIBE #news.comp.mail.mime
- S: A002 OK UNSUBSCRIBE completed
-
-
-
-Crispin Standards Track [Page 39]
-
-RFC 3501 IMAPv4 March 2003
-
-
-6.3.8. LIST Command
-
- Arguments: reference name
- mailbox name with possible wildcards
-
- Responses: 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 client. 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.
-
- The LIST command SHOULD return its data quickly, without undue
- delay. For example, it SHOULD NOT go to excess trouble to
- calculate the \Marked or \Unmarked status or perform other
- processing; if each name requires 1 second of processing, then a
- list of 1200 names would take 20 minutes!
-
- 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 the context in which the mailbox
- name is interpreted.
-
- An empty ("" string) mailbox name argument is a special request to
- return the hierarchy delimiter and the root name of the name given
- in the reference. The value returned as the root MAY be the empty
- string if the reference is non-rooted or is an empty string. In
- all cases, a hierarchy delimiter (or NIL if there is no hierarchy)
- is returned. This permits a client to get the hierarchy delimiter
- (or find out that the mailbox names are flat) even when no
- mailboxes by that name currently exist.
-
- The reference and mailbox name arguments are interpreted into a
- canonical form that represents an unambiguous left-to-right
- hierarchy. The returned mailbox names will be in the interpreted
- form.
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 40]
-
-RFC 3501 IMAPv4 March 2003
-
-
- Note: The interpretation of the reference argument is
- implementation-defined. It depends upon whether the
- server implementation has a concept of the "current
- working directory" and leading "break out characters",
- which override the current working directory.
-
- For example, on a server which exports a UNIX or NT
- filesystem, the reference argument contains the current
- working directory, and the mailbox name argument would
- contain the name as interpreted in the current working
- directory.
-
- If a server implementation has no concept of break out
- characters, the canonical form is normally the reference
- name appended with the mailbox name. Note that if the
- server implements the namespace convention (section
- 5.1.2), "#" is a break out character and must be treated
- as such.
-
- If the reference argument is not a level of mailbox
- hierarchy (that is, it is a \NoInferiors name), and/or
- the reference argument does not end with the hierarchy
- delimiter, it is implementation-dependent how this is
- interpreted. For example, a reference of "foo/bar" and
- mailbox name of "rag/baz" could be interpreted as
- "foo/bar/rag/baz", "foo/barrag/baz", or "foo/rag/baz".
- A client SHOULD NOT use such a reference argument except
- at the explicit request of the user. A hierarchical
- browser MUST NOT make any assumptions about server
- interpretation of the reference unless the reference is
- a level of mailbox hierarchy AND ends with the hierarchy
- delimiter.
-
- 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 Standards Track [Page 41]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 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 details).
-
- 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
- INBOX is supported by this server for this user and if the
- uppercase string "INBOX" matches the interpreted reference and
- mailbox name arguments with wildcards as described above. 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.
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 42]
-
-RFC 3501 IMAPv4 March 2003
-
-
- Example: C: A101 LIST "" ""
- S: * LIST (\Noselect) "/" ""
- S: A101 OK LIST Completed
- C: A102 LIST #news.comp.mail.misc ""
- S: * LIST (\Noselect) "." #news.
- S: A102 OK LIST Completed
- C: A103 LIST /usr/staff/jones ""
- S: * LIST (\Noselect) "/" /
- S: A103 OK LIST Completed
- C: A202 LIST ~/Mail/ %
- S: * LIST (\Noselect) "/" ~/Mail/foo
- S: * LIST () "/" ~/Mail/meetings
- S: A202 OK LIST completed
-
-
-6.3.9. LSUB Command
-
- Arguments: reference name
- mailbox name with possible wildcards
-
- Responses: 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.
-
- The returned untagged LSUB response MAY contain different mailbox
- flags from a LIST untagged response. If this should happen, the
- flags in the untagged LIST are considered more authoritative.
-
- A special situation occurs when using LSUB with the % wildcard.
- Consider what happens if "foo/bar" (with a hierarchy delimiter of
- "/") is subscribed but "foo" is not. A "%" wildcard to LSUB must
- return foo, not foo/bar, in the LSUB response, and it MUST be
- flagged with the \Noselect attribute.
-
- The server MUST NOT unilaterally remove an existing mailbox name
- from the subscription list even if a mailbox by that name no
- longer exists.
-
-
-
-
-
-
-
-Crispin Standards Track [Page 43]
-
-RFC 3501 IMAPv4 March 2003
-
-
- Example: C: A002 LSUB "#news." "comp.mail.*"
- S: * LSUB () "." #news.comp.mail.mime
- S: * LSUB () "." #news.comp.mail.misc
- S: A002 OK LSUB completed
- C: A003 LSUB "#news." "comp.%"
- S: * LSUB (\NoSelect) "." #news.comp.mail
- S: A003 OK LSUB completed
-
-
-6.3.10. STATUS Command
-
- Arguments: mailbox name
- status data item names
-
- Responses: untagged responses: STATUS
-
- Result: OK - status completed
- NO - status failure: no status for that name
- BAD - command unknown or arguments invalid
-
- The STATUS command requests the status of the indicated mailbox.
- It does not change the currently selected mailbox, nor does it
- affect the state of any messages in the queried mailbox (in
- particular, STATUS MUST NOT cause messages to lose the \Recent
- flag).
-
- The STATUS command provides an alternative to opening a second
- IMAP4rev1 connection and doing an EXAMINE command on a mailbox to
- query that mailbox's status without deselecting the current
- mailbox in the first IMAP4rev1 connection.
-
- Unlike the LIST command, the STATUS command is not guaranteed to
- be fast in its response. Under certain circumstances, it can be
- quite slow. In some implementations, the server is obliged to
- open the mailbox read-only internally to obtain certain status
- information. Also unlike the LIST command, the STATUS command
- does not accept wildcards.
-
- Note: The STATUS command is intended to access the
- status of mailboxes other than the currently selected
- mailbox. Because the STATUS command can cause the
- mailbox to be opened internally, and because this
- information is available by other means on the selected
- mailbox, the STATUS command SHOULD NOT be used on the
- currently selected mailbox.
-
-
-
-
-
-
-Crispin Standards Track [Page 44]
-
-RFC 3501 IMAPv4 March 2003
-
-
- The STATUS command MUST NOT be used as a "check for new
- messages in the selected mailbox" operation (refer to
- sections 7, 7.3.1, and 7.3.2 for more information about
- the proper method for new message checking).
-
- Because the STATUS command is not guaranteed to be fast
- in its results, clients SHOULD NOT expect to be able to
- issue many consecutive STATUS commands and obtain
- reasonable performance.
-
- The currently defined status data items that can be requested are:
-
- MESSAGES
- The number of messages in the mailbox.
-
- RECENT
- The number of messages with the \Recent flag set.
-
- UIDNEXT
- The next unique identifier value of the mailbox. Refer to
- section 2.3.1.1 for more information.
-
- UIDVALIDITY
- The unique identifier validity value of the mailbox. Refer to
- section 2.3.1.1 for more information.
-
- UNSEEN
- The number of messages which do not have the \Seen flag set.
-
-
- Example: C: A042 STATUS blurdybloop (UIDNEXT MESSAGES)
- S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
- S: A042 OK STATUS completed
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 45]
-
-RFC 3501 IMAPv4 March 2003
-
-
-6.3.11. APPEND Command
-
- Arguments: mailbox name
- OPTIONAL flag parenthesized list
- OPTIONAL date/time string
- message literal
-
- Responses: no specific responses 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
- to the end of the specified destination mailbox. This argument
- SHOULD be in the format of an [RFC-2822] 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 a [MIME-IMB]
- content transfer encoding.
-
- Note: There MAY be exceptions, e.g., draft messages, in
- which required [RFC-2822] header lines are omitted in
- the message literal argument to APPEND. The full
- implications of doing so MUST be understood and
- carefully weighed.
-
- If a flag parenthesized list is specified, the flags SHOULD be set
- in the resulting message; otherwise, the flag list of the
- resulting message is set to empty by default. In either case, the
- Recent flag is also set.
-
- If a date-time is specified, the internal date SHOULD be set in
- the resulting message; otherwise, the internal date of the
- resulting message is set to the current date and time by default.
-
- 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 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.
-
-
-
-Crispin Standards Track [Page 46]
-
-RFC 3501 IMAPv4 March 2003
-
-
- If the mailbox is currently selected, the normal new message
- actions SHOULD occur. Specifically, the server SHOULD notify the
- client immediately via an untagged EXISTS response. If the server
- does not do so, the client MAY issue a NOOP command (or failing
- that, a CHECK command) after one or more APPEND commands.
-
- Example: C: A003 APPEND saved-messages (\Seen) {310}
- S: + Ready for literal data
- 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 the 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, STATUS, and
- APPEND), the following commands are valid in the selected state:
- CHECK, CLOSE, EXPUNGE, SEARCH, FETCH, STORE, COPY, and UID.
-
-6.4.1. CHECK Command
-
- Arguments: none
-
- Responses: no specific responses 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
-
-
-
-Crispin Standards Track [Page 47]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 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
- message polling.
-
- Example: C: FXXZ CHECK
- S: FXXZ OK CHECK Completed
-
-
-6.4.2. CLOSE Command
-
- Arguments: none
-
- Responses: no specific responses for this command
-
- Result: OK - close completed, now in authenticated state
- BAD - command unknown or arguments invalid
-
- The CLOSE command permanently removes all messages that have the
- \Deleted flag set from the currently selected mailbox, and returns
- to the authenticated state from the 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 if a mailbox is selected, a SELECT, EXAMINE, or LOGOUT
- command MAY be issued without previously issuing a CLOSE command.
- The SELECT, EXAMINE, and LOGOUT commands implicitly close the
- currently selected mailbox without doing an expunge. However,
- 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
-
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 48]
-
-RFC 3501 IMAPv4 March 2003
-
-
-6.4.3. EXPUNGE Command
-
- Arguments: none
-
- Responses: 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 all messages that have the
- \Deleted flag set from the currently selected mailbox. 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.
-
-
-6.4.4. SEARCH Command
-
- Arguments: OPTIONAL [CHARSET] specification
- searching criteria (one or more)
-
- Responses: REQUIRED untagged response: SEARCH
-
- Result: OK - search completed
- NO - search error: can't search that [CHARSET] 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.
-
-
-
-
-
-
-Crispin Standards Track [Page 49]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 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 can 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-IMB] body parts with
- terminal content media types other than TEXT and MESSAGE from
- consideration in SEARCH matching.
-
- The OPTIONAL [CHARSET] specification consists of the word
- "CHARSET" followed by a registered [CHARSET]. It indicates the
- [CHARSET] of the strings that appear in the search criteria.
- [MIME-IMB] content transfer encodings, and [MIME-HDRS] strings in
- [RFC-2822]/[MIME-IMB] headers, MUST be decoded before comparing
- text in a [CHARSET] other than US-ASCII. US-ASCII MUST be
- supported; other [CHARSET]s MAY be supported.
-
- If the server does not support the specified [CHARSET], it MUST
- return a tagged NO response (not a BAD). This response SHOULD
- contain the BADCHARSET response code, which MAY list the
- [CHARSET]s supported by the server.
-
- 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.
-
- The defined search keys are as follows. Refer to the Formal
- Syntax section for the precise syntactic definitions of the
- arguments.
-
- <sequence 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.
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 50]
-
-RFC 3501 IMAPv4 March 2003
-
-
- BCC <string>
- Messages that contain the specified string in the envelope
- structure's BCC field.
-
- BEFORE <date>
- Messages whose internal date (disregarding time and timezone)
- 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-2822]) and that contains the specified string
- in the text of the header (what comes after the colon). If the
- string to search is zero-length, this matches all messages that
- have a header line with the specified field-name regardless of
- the contents.
-
- KEYWORD <flag>
- Messages with the specified keyword flag set.
-
- LARGER <n>
- Messages with an [RFC-2822] 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 Standards Track [Page 51]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 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 (disregarding time and timezone)
- 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-2822] Date: header (disregarding time and
- timezone) is earlier than the specified date.
-
- SENTON <date>
- Messages whose [RFC-2822] Date: header (disregarding time and
- timezone) is within the specified date.
-
- SENTSINCE <date>
- Messages whose [RFC-2822] Date: header (disregarding time and
- timezone) is within or later than the specified date.
-
- SINCE <date>
- Messages whose internal date (disregarding time and timezone)
- is within or later than the specified date.
-
- SMALLER <n>
- Messages with an [RFC-2822] size smaller than the specified
- number of octets.
-
-
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 52]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 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 <sequence set>
- Messages with unique identifiers corresponding to the specified
- unique identifier set. Sequence set ranges are permitted.
-
- 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 flag set.
-
- UNSEEN
- Messages that do not have the \Seen flag set.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 53]
-
-RFC 3501 IMAPv4 March 2003
-
-
- Example: C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith"
- S: * SEARCH 2 84 882
- S: A282 OK SEARCH completed
- C: A283 SEARCH TEXT "string not in mailbox"
- S: * SEARCH
- S: A283 OK SEARCH completed
- C: A284 SEARCH CHARSET UTF-8 TEXT {6}
- C: XXXXXX
- S: * SEARCH 43
- S: A284 OK SEARCH completed
-
- Note: Since this document is restricted to 7-bit ASCII
- text, it is not possible to show actual UTF-8 data. The
- "XXXXXX" is a placeholder for what would be 6 octets of
- 8-bit data in an actual transaction.
-
-
-6.4.5. FETCH Command
-
- Arguments: sequence set
- message data item names or macro
-
- Responses: 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 can be either a single atom
- or a parenthesized list.
-
- Most data items, identified in the formal syntax under the
- msg-att-static rule, are static and MUST NOT change for any
- particular message. Other data items, identified in the formal
- syntax under the msg-att-dynamic rule, MAY change, either as a
- result of a STORE command or due to external events.
-
- For example, if a client receives an ENVELOPE for a
- message when it already knows the envelope, it can
- safely ignore the newly transmitted envelope.
-
- There are three macros which specify commonly-used sets of data
- items, and can be used instead of data items. A macro must be
- used by itself, and not in conjunction with other macros or data
- items.
-
-
-
-
-
-Crispin Standards Track [Page 54]
-
-RFC 3501 IMAPv4 March 2003
-
-
- ALL
- Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)
-
- FAST
- Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE)
-
- FULL
- Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE
- BODY)
-
- The currently defined data items that can be fetched are:
-
- BODY
- Non-extensible form of BODYSTRUCTURE.
-
- BODY[<section>]<<partial>>
- The text of a particular body section. The section
- specification is a set of zero or more part specifiers
- delimited by periods. A part specifier is either a part number
- or one of the following: HEADER, HEADER.FIELDS,
- HEADER.FIELDS.NOT, MIME, and TEXT. An empty section
- specification refers to the entire message, including the
- header.
-
- Every message has at least one part number. Non-[MIME-IMB]
- messages, and non-multipart [MIME-IMB] messages with no
- encapsulated message, only have a part 1.
-
- 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.
-
- A part of type MESSAGE/RFC822 also has nested part numbers,
- referring to parts of the MESSAGE part's body.
-
- The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, and TEXT part
- specifiers can be the sole part specifier or can be prefixed by
- one or more numeric part specifiers, provided that the numeric
- part specifier refers to a part of type MESSAGE/RFC822. The
- MIME part specifier MUST be prefixed by one or more numeric
- part specifiers.
-
- The HEADER, HEADER.FIELDS, and HEADER.FIELDS.NOT part
- specifiers refer to the [RFC-2822] header of the message or of
- an encapsulated [MIME-IMT] MESSAGE/RFC822 message.
- HEADER.FIELDS and HEADER.FIELDS.NOT are followed by a list of
- field-name (as defined in [RFC-2822]) names, and return a
-
-
-
-Crispin Standards Track [Page 55]
-
-RFC 3501 IMAPv4 March 2003
-
-
- subset of the header. The subset returned by HEADER.FIELDS
- contains only those header fields with a field-name that
- matches one of the names in the list; similarly, the subset
- returned by HEADER.FIELDS.NOT contains only the header fields
- with a non-matching field-name. The field-matching is
- case-insensitive but otherwise exact. Subsetting does not
- exclude the [RFC-2822] delimiting blank line between the header
- and the body; the blank line is included in all header fetches,
- except in the case of a message which has no body and no blank
- line.
-
- The MIME part specifier refers to the [MIME-IMB] header for
- this part.
-
- The TEXT part specifier refers to the text body of the message,
- omitting the [RFC-2822] header.
-
- Here is an example of a complex message with some of its
- part specifiers:
-
- HEADER ([RFC-2822] header of the message)
- TEXT ([RFC-2822] text body of the message) MULTIPART/MIXED
- 1 TEXT/PLAIN
- 2 APPLICATION/OCTET-STREAM
- 3 MESSAGE/RFC822
- 3.HEADER ([RFC-2822] header of the message)
- 3.TEXT ([RFC-2822] text body of the message) MULTIPART/MIXED
- 3.1 TEXT/PLAIN
- 3.2 APPLICATION/OCTET-STREAM
- 4 MULTIPART/MIXED
- 4.1 IMAGE/GIF
- 4.1.MIME ([MIME-IMB] header for the IMAGE/GIF)
- 4.2 MESSAGE/RFC822
- 4.2.HEADER ([RFC-2822] header of the message)
- 4.2.TEXT ([RFC-2822] text body of the message) MULTIPART/MIXED
- 4.2.1 TEXT/PLAIN
- 4.2.2 MULTIPART/ALTERNATIVE
- 4.2.2.1 TEXT/PLAIN
- 4.2.2.2 TEXT/RICHTEXT
-
-
- It is possible to fetch a substring of the designated text.
- This is done by appending an open angle bracket ("<"), the
- octet position of the first desired octet, a period, the
- maximum number of octets desired, and a close angle bracket
- (">") to the part specifier. If the starting octet is beyond
- the end of the text, an empty string is returned.
-
-
-
-
-Crispin Standards Track [Page 56]
-
-RFC 3501 IMAPv4 March 2003
-
-
- Any partial fetch that attempts to read beyond the end of the
- text is truncated as appropriate. A partial fetch that starts
- at octet 0 is returned as a partial fetch, even if this
- truncation happened.
-
- Note: This means that BODY[]<0.2048> of a 1500-octet message
- will return BODY[]<0> with a literal of size 1500, not
- BODY[].
-
- Note: A substring fetch of a HEADER.FIELDS or
- HEADER.FIELDS.NOT part specifier is calculated after
- subsetting the header.
-
- 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>]<<partial>>
- An alternate form of BODY[<section>] that does not implicitly
- set the \Seen flag.
-
- BODYSTRUCTURE
- The [MIME-IMB] body structure of the message. This is computed
- by the server by parsing the [MIME-IMB] header fields in the
- [RFC-2822] header and [MIME-IMB] headers.
-
- ENVELOPE
- The envelope structure of the message. This is computed by the
- server by parsing the [RFC-2822] header into the component
- parts, defaulting various fields as necessary.
-
- FLAGS
- The flags that are set for this message.
-
- INTERNALDATE
- The internal date of the message.
-
- RFC822
- Functionally equivalent to BODY[], differing in the syntax of
- the resulting untagged FETCH data (RFC822 is returned).
-
- RFC822.HEADER
- Functionally equivalent to BODY.PEEK[HEADER], differing in the
- syntax of the resulting untagged FETCH data (RFC822.HEADER is
- returned).
-
- RFC822.SIZE
- The [RFC-2822] size of the message.
-
-
-
-
-Crispin Standards Track [Page 57]
-
-RFC 3501 IMAPv4 March 2003
-
-
- RFC822.TEXT
- Functionally equivalent to BODY[TEXT], differing in the syntax
- of the resulting untagged FETCH data (RFC822.TEXT is returned).
-
- UID
- The unique identifier for the message.
-
-
- Example: C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)])
- S: * 2 FETCH ....
- S: * 3 FETCH ....
- S: * 4 FETCH ....
- S: A654 OK FETCH completed
-
-
-6.4.6. STORE Command
-
- Arguments: sequence set
- message data item name
- value for message data item
-
- Responses: 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
- 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.
-
- Note: Regardless of whether or not the ".SILENT" suffix
- was used, the server SHOULD send an untagged FETCH
- response if a change to a message's flags from an
- external source is observed. The intent is that the
- status of the flags is determinate without a race
- condition.
-
-
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 58]
-
-RFC 3501 IMAPv4 March 2003
-
-
- The currently defined data items that can be stored are:
-
- FLAGS <flag list>
- Replace the flags for the message (other than \Recent) with the
- argument. The new value of the flags is 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 is 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 is 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
-
-
-6.4.7. COPY Command
-
- Arguments: sequence set
- mailbox name
-
- Responses: no specific responses 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
-
-
-
-
-
-
-
-Crispin Standards Track [Page 59]
-
-RFC 3501 IMAPv4 March 2003
-
-
- The COPY command copies the specified message(s) to the end of the
- specified destination mailbox. The flags and internal date of the
- message(s) SHOULD be preserved, and the Recent flag SHOULD be set,
- 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.8. UID Command
-
- Arguments: command name
- command arguments
-
- Responses: 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 sequence set argument are unique identifiers instead of
- message sequence numbers. Sequence set ranges are permitted, but
- there is no guarantee that unique identifiers will be contiguous.
-
- A non-existent unique identifier is ignored without any error
- message generated. Thus, it is possible for a UID FETCH command
- to return an OK without any data or a UID COPY or UID STORE to
- return an OK without performing any operations.
-
- 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
-
-
-
-Crispin Standards Track [Page 60]
-
-RFC 3501 IMAPv4 March 2003
-
-
- of message sequence numbers. For example, the command UID SEARCH
- 1:100 UID 443:557 returns the unique identifiers corresponding to
- the intersection of two sequence sets, the message sequence number
- range 1:100 and the UID range 443:557.
-
- Note: in the above example, the UID range 443:557
- appears. The same comment about a non-existent unique
- identifier being ignored without any error message also
- applies here. Hence, even if neither UID 443 or 557
- exist, this range is valid and would include an existing
- UID 495.
-
- Also note that a UID range of 559:* always includes the
- UID of the last message in the mailbox, even if 559 is
- higher than any assigned UID value. This is because the
- contents of a range are independent of the order of the
- range endpoints. Thus, any UID range with * as one of
- the endpoints indicates at least one message (the
- message with the highest numbered UID), unless the
- mailbox is empty.
-
- 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 a UID was specified
- as a message data item to the FETCH.
-
-
- Note: The rule about including the UID message data item as part
- of a FETCH response primarily applies to the UID FETCH and UID
- STORE commands, including a UID FETCH command that does not
- include UID as a message data item. Although it is unlikely that
- the other UID commands will cause an untagged FETCH, this rule
- applies to these commands as well.
-
- Example: C: A999 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 OK UID FETCH completed
-
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 61]
-
-RFC 3501 IMAPv4 March 2003
-
-
-6.5. Client Commands - Experimental/Expansion
-
-
-6.5.1. X<atom> Command
-
- Arguments: implementation defined
-
- Responses: 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, a standard or
- standards-track revision of this specification, or an
- IESG-approved experimental protocol, 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 IMAP4rev1 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
-
-7. Server Responses
-
- Server responses are in three forms: status responses, server data,
- and command continuation request. The information contained in a
- server response, identified by "Contents:" in the response
- descriptions below, is described by function, not by syntax. The
- precise syntax of server responses is described in the Formal Syntax
- section.
-
- The client MUST be prepared to accept any response at all times.
-
- Status responses can be tagged or untagged. Tagged status responses
- indicate the completion result (OK, NO, or BAD status) 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
-
-
-
-Crispin Standards Track [Page 62]
-
-RFC 3501 IMAPv4 March 2003
-
-
- that does not indicate the completion of a command (for example, an
- impending system shutdown alert). 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 messages).
-
- 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 server data occurs when the IMAP
- connection is in the selected state. In the selected state, the
- server checks the mailbox for new messages as part of command
- execution. Normally, this is part of the execution of every command;
- hence, a NOOP command suffices to check for new messages. 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.
-
-7.1. Server Responses - Status Responses
-
- Status responses are OK, NO, BAD, PREAUTH and BYE. OK, NO, and BAD
- can be tagged or untagged. PREAUTH and BYE are always untagged.
-
- 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.
-
-
-
-
-
-Crispin Standards Track [Page 63]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 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.
-
- BADCHARSET
-
- Optionally followed by a parenthesized list of charsets. A
- SEARCH failed because the given charset is not supported by
- this implementation. If the optional list of charsets is
- given, this lists the charsets that are supported by this
- implementation.
-
- CAPABILITY
-
- Followed by a list of capabilities. This can appear in the
- initial OK or PREAUTH response to transmit an initial
- capabilities list. This makes it unnecessary for a client to
- send a separate CAPABILITY command if it recognizes this
- response.
-
- PARSE
-
- The human-readable text represents an error in parsing the
- [RFC-2822] header or [MIME-IMB] headers of a message in the
- mailbox.
-
- PERMANENTFLAGS
-
- Followed by a parenthesized list of flags, indicates which of
- the known flags the client can 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 ignore the change or store the
- state change for the remainder of the current session only.
- The PERMANENTFLAGS list can also include the special flag \*,
- which indicates that it is possible to create new keywords by
- attempting to store those flags in the mailbox.
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 64]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 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 can succeed if the
- mailbox is first created by the CREATE command.
-
- UIDNEXT
-
- Followed by a decimal number, indicates the next unique
- identifier value. Refer to section 2.3.1.1 for more
- information.
-
- UIDVALIDITY
-
- Followed by a decimal number, indicates the unique identifier
- validity value. Refer to section 2.3.1.1 for more information.
-
- 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
-
- Contents: 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
-
-
-
-
-Crispin Standards Track [Page 65]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 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 connection startup. It indicates that the connection is not
- yet authenticated and that a LOGIN command is needed.
-
- Example: S: * OK IMAP4rev1 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
-
- Contents: 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 can still complete successfully. The human-readable text
- describes the condition.
-
- Example: C: A222 COPY 1:2 owatagusiam
- S: * NO Disk is 98% full, please delete unnecessary data
- S: A222 OK COPY completed
- C: A223 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: A223 NO COPY failed: disk is full
-
-
-7.1.3. BAD Response
-
- Contents: 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 can also indicate an internal
- server failure. The human-readable text describes the condition.
-
-
-
-
-
-
-
-Crispin Standards Track [Page 66]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 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
-
- Contents: OPTIONAL response code
- human-readable text
-
- The PREAUTH response is always untagged, and is one of three
- possible greetings at connection startup. It indicates that the
- connection has already been authenticated by external means; thus
- no LOGIN command is needed.
-
- Example: S: * PREAUTH IMAP4rev1 server logged in as Smith
-
-
-7.1.5. BYE Response
-
- Contents: 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 is sent under one of four conditions:
-
- 1) as part of a normal logout sequence. The server will close
- the connection after sending the tagged OK response to the
- LOGOUT command.
-
- 2) as a panic shutdown announcement. The server closes the
- connection immediately.
-
- 3) as an announcement of an inactivity autologout. The server
- closes the connection immediately.
-
- 4) as one of three possible greetings at connection startup,
- indicating that the server is not willing to accept a
- connection from this client. The server closes the
- connection immediately.
-
-
-
-
-Crispin Standards Track [Page 67]
-
-RFC 3501 IMAPv4 March 2003
-
-
- The difference between a BYE that occurs as part of a normal
- LOGOUT sequence (the first case) and a BYE that occurs because of
- a failure (the other three cases) is that the connection closes
- immediately in the failure case. In all cases the client SHOULD
- continue to read response data from the server until the
- connection is closed; this will ensure that any pending untagged
- or completion responses are read and processed.
-
- 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 and mailbox
- status data are transmitted from the server to the client. Many of
- these responses typically result from a command with the same name.
-
-7.2.1. CAPABILITY Response
-
- Contents: 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
- capability listing MUST include the atom "IMAP4rev1".
-
- In addition, client and server implementations MUST implement the
- STARTTLS, LOGINDISABLED, and AUTH=PLAIN (described in [IMAP-TLS])
- capabilities. See the Security Considerations section for
- important information.
-
- A capability name which begins with "AUTH=" indicates that the
- server supports that particular authentication mechanism.
-
- The LOGINDISABLED capability indicates that the LOGIN command is
- disabled, and that the server will respond with a tagged NO
- response to any attempt to use the LOGIN command even if the user
- name and password are valid. An IMAP client MUST NOT issue the
- LOGIN command if the server advertises the LOGINDISABLED
- capability.
-
- Other capability names indicate that the server supports an
- extension, revision, or amendment to the IMAP4rev1 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 IMAP4rev1 extensions, revisions, or amendments
- registered with IANA. A server MUST NOT offer unregistered or
-
-
-
-Crispin Standards Track [Page 68]
-
-RFC 3501 IMAPv4 March 2003
-
-
- non-standard capability names, unless such names are prefixed with
- an "X".
-
- Client implementations SHOULD NOT require any capability name
- other than "IMAP4rev1", and MUST ignore any unknown capability
- names.
-
- A server MAY send capabilities automatically, by using the
- CAPABILITY response code in the initial PREAUTH or OK responses,
- and by sending an updated CAPABILITY response code in the tagged
- OK response as part of a successful authentication. It is
- unnecessary for a client to send a separate CAPABILITY command if
- it recognizes these automatic capabilities.
-
- Example: S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI XPIG-LATIN
-
-
-7.2.2. LIST Response
-
- Contents: 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
- can 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.
-
-
-
-
-
-
-Crispin Standards Track [Page 69]
-
-RFC 3501 IMAPv4 March 2003
-
-
- If it is not feasible for the server to determine whether or not
- the mailbox is "interesting", 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 can 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.
-
- 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
-
- Contents: 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
- can 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 STATUS Response
-
- Contents: name
- status parenthesized list
-
- The STATUS response occurs as a result of an STATUS command. It
- returns the mailbox name that matches the STATUS specification and
- the requested mailbox status information.
-
- Example: S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 70]
-
-RFC 3501 IMAPv4 March 2003
-
-
-7.2.5. SEARCH Response
-
- Contents: 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.6. FLAGS Response
-
- Contents: 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 can 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)
-
-
-7.3. Server Responses - Mailbox Size
-
- These responses are always untagged. This is how changes in the size
- of the mailbox are transmitted from the server to the client.
- Immediately following the "*" token is a number that represents a
- message count.
-
-7.3.1. EXISTS Response
-
- Contents: 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 messages).
-
- The update from the EXISTS response MUST be recorded by the
- client.
-
- Example: S: * 23 EXISTS
-
-
-
-
-Crispin Standards Track [Page 71]
-
-RFC 3501 IMAPv4 March 2003
-
-
-7.3.2. RECENT Response
-
- Contents: none
-
- The RECENT response reports the number of messages with the
- \Recent flag set. This response occurs as a result of a SELECT or
- EXAMINE command, and if the size of the mailbox changes (e.g., new
- messages).
-
- Note: It is not guaranteed that the message sequence
- numbers of recent messages will be a contiguous range of
- the highest n messages in the mailbox (where n is the
- value reported by the RECENT response). Examples of
- situations in which this is not the case are: multiple
- clients having the same mailbox open (the first session
- to be notified will see it as recent, others will
- probably see it as non-recent), and when the mailbox is
- re-ordered by a non-IMAP agent.
-
- The only reliable way to identify recent messages is to
- look at message flags to see which have the \Recent flag
- set, or to do a SEARCH RECENT.
-
- The update from the RECENT response MUST be recorded by the
- client.
-
- Example: S: * 5 RECENT
-
-
-7.4. 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 a message sequence number.
-
-7.4.1. EXPUNGE Response
-
- Contents: 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 Standards Track [Page 72]
-
-RFC 3501 IMAPv4 March 2003
-
-
- The EXPUNGE response also decrements the number of messages in the
- mailbox; it is not necessary to send an EXISTS response with the
- new value.
-
- 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. A command is not "in progress" until the complete command
- has been received; in particular, a command is not "in progress"
- during the negotiation of command continuation.
-
- Note: UID FETCH, UID STORE, and UID SEARCH are different
- commands from FETCH, STORE, and SEARCH. An EXPUNGE
- response MAY be sent during a UID command.
-
- The update from the EXPUNGE response MUST be recorded by the
- client.
-
- Example: S: * 44 EXPUNGE
-
-
-7.4.2. FETCH Response
-
- Contents: 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.
-
-
-
-
-
-Crispin Standards Track [Page 73]
-
-RFC 3501 IMAPv4 March 2003
-
-
- BODY[<section>]<<origin octet>>
- 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.
-
- If the origin octet is specified, this string is a substring of
- the entire body contents, starting at that origin octet. This
- means that BODY[]<0> MAY be truncated, but BODY[] is NEVER
- truncated.
-
- Note: The origin octet facility MUST NOT be used by a server
- in a FETCH response unless the client specifically requested
- it by means of a FETCH of a BODY[<section>]<<partial>> data
- item.
-
- 8-bit textual data is permitted if a [CHARSET] identifier is
- part of the body parameter parenthesized list for this section.
- Note that headers (part specifiers HEADER or MIME, or the
- header portion of a MESSAGE/RFC822 part), MUST be 7-bit; 8-bit
- characters are not permitted in headers. Note also that the
- [RFC-2822] delimiting blank line between the header and the
- body is not affected by header line subsetting; the blank line
- is always included as part of header data, except in the case
- of a message which has no body and no blank line.
-
- 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 original binary data, the client MUST
- decode the transfer encoded string.
-
- BODYSTRUCTURE
- A parenthesized list that describes the [MIME-IMB] body
- structure of a message. This is computed by the server by
- parsing the [MIME-IMB] header fields, defaulting various fields
- as necessary.
-
- For example, a simple text message of 48 lines and 2279 octets
- can have a body structure of: ("TEXT" "PLAIN" ("CHARSET"
- "US-ASCII") NIL NIL "7BIT" 2279 48)
-
- Multiple parts are indicated by parenthesis nesting. Instead
- of a body type as the first element of the parenthesized list,
- there is a sequence of one or more nested body structures. The
- second element of the parenthesized list is the multipart
- subtype (mixed, digest, parallel, alternative, etc.).
-
-
-
-
-
-
-Crispin Standards Track [Page 74]
-
-RFC 3501 IMAPv4 March 2003
-
-
- For example, a two part message consisting of a text and a
- BASE64-encoded text attachment can have a body structure of:
- (("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152
- 23)("TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" "cc.diff")
- "<960723163407.20117h@cac.washington.edu>" "Compiler diff"
- "BASE64" 4554 73) "MIXED")
-
- Extension data follows the multipart subtype. Extension data
- is never returned with the BODY fetch, but can 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-IMB].
-
- body disposition
- A parenthesized list, consisting of a disposition type
- string, followed by a parenthesized list of disposition
- attribute/value pairs as defined in [DISPOSITION].
-
- body language
- A string or parenthesized list giving the body language
- value as defined in [LANGUAGE-TAGS].
-
- body location
- A string list giving the body content URI as defined in
- [LOCATION].
-
- Any following extension data are not yet defined in this
- version of the protocol. Such extension data can 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 media type name as defined in
- [MIME-IMB].
-
-
-
-
-
-Crispin Standards Track [Page 75]
-
-RFC 3501 IMAPv4 March 2003
-
-
- body subtype
- A string giving the content subtype name as defined in
- [MIME-IMB].
-
- 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-IMB].
-
- body id
- A string giving the content id as defined in [MIME-IMB].
-
- body description
- A string giving the content description as defined in
- [MIME-IMB].
-
- body encoding
- A string giving the content transfer encoding as defined in
- [MIME-IMB].
-
- 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 content 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 can 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:
-
- body MD5
- A string giving the body MD5 value as defined in [MD5].
-
-
-
-
-
-
-Crispin Standards Track [Page 76]
-
-RFC 3501 IMAPv4 March 2003
-
-
- body disposition
- A parenthesized list with the same content and function as
- the body disposition for a multipart body part.
-
- body language
- A string or parenthesized list giving the body language
- value as defined in [LANGUAGE-TAGS].
-
- body location
- A string list giving the body content URI as defined in
- [LOCATION].
-
- 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-2822] 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-2822] 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.
-
- If the Date, Subject, In-Reply-To, and Message-ID header lines
- are absent in the [RFC-2822] header, the corresponding member
- of the envelope is NIL; if these header lines are present but
- empty the corresponding member of the envelope is the empty
- string.
-
-
-
-
-
-Crispin Standards Track [Page 77]
-
-RFC 3501 IMAPv4 March 2003
-
-
- Note: some servers may return a NIL envelope member in the
- "present but empty" case. Clients SHOULD treat NIL and
- empty string as identical.
-
- Note: [RFC-2822] requires that all messages have a valid
- Date header. Therefore, the date member in the envelope can
- not be NIL or the empty string.
-
- Note: [RFC-2822] requires that the In-Reply-To and
- Message-ID headers, if present, have non-empty content.
- Therefore, the in-reply-to and message-id members in the
- envelope can not be the empty string.
-
- If the From, To, cc, and bcc header lines are absent in the
- [RFC-2822] header, or are present but empty, the corresponding
- member of the envelope is NIL.
-
- If the Sender or Reply-To lines are absent in the [RFC-2822]
- header, or are present but empty, the server sets the
- corresponding member of the envelope to be the same value as
- the from member (the client is not expected to know to do
- this).
-
- Note: [RFC-2822] requires that all messages have a valid
- From header. Therefore, the from, sender, and reply-to
- members in the envelope can not be NIL.
-
- FLAGS
- A parenthesized list of flags that are set for this message.
-
- INTERNALDATE
- A string representing the internal date of the message.
-
- RFC822
- Equivalent to BODY[].
-
- RFC822.HEADER
- Equivalent to BODY[HEADER]. Note that this did not result in
- \Seen being set, because RFC822.HEADER response data occurs as
- a result of a FETCH of RFC822.HEADER. BODY[HEADER] response
- data occurs as a result of a FETCH of BODY[HEADER] (which sets
- \Seen) or BODY.PEEK[HEADER] (which does not set \Seen).
-
- RFC822.SIZE
- A number expressing the [RFC-2822] size of the message.
-
-
-
-
-
-
-Crispin Standards Track [Page 78]
-
-RFC 3501 IMAPv4 March 2003
-
-
- RFC822.TEXT
- Equivalent to BODY[TEXT].
-
- UID
- A number expressing the unique identifier of the message.
-
-
- Example: S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827)
-
-
-7.5. Server Responses - Command Continuation Request
-
- The command continuation 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 AUTHENTICATE 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 is expected. 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 Standards Track [Page 79]
-
-RFC 3501 IMAPv4 March 2003
-
-
-8. Sample IMAP4rev1 connection
-
- The following is a transcript of an IMAP4rev1 connection. A long
- line in this sample is broken for editorial clarity.
-
-S: * OK IMAP4rev1 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 "17-Jul-1996 02:44:25 -0700"
- RFC822.SIZE 4286 ENVELOPE ("Wed, 17 Jul 1996 02:23:25 -0700 (PDT)"
- "IMAP4rev1 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" "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 body[header]
-S: * 12 FETCH (BODY[HEADER] {342}
-S: Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)
-S: From: Terry Gray <gray@cac.washington.edu>
-S: Subject: IMAP4rev1 WG mtg summary and minutes
-S: To: imap@cac.washington.edu
-S: cc: minutes@CNRI.Reston.VA.US, John Klensin <KLENSIN@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 IMAP4rev1 server terminating connection
-S: a006 OK LOGOUT completed
-
-
-
-Crispin Standards Track [Page 80]
-
-RFC 3501 IMAPv4 March 2003
-
-
-9. Formal Syntax
-
- The following syntax specification uses the Augmented Backus-Naur
- Form (ABNF) notation as specified in [ABNF].
-
- In the case of alternative or optional rules in which a later rule
- overlaps an earlier rule, the rule which is listed earlier MUST take
- priority. For example, "\Seen" when parsed as a flag is the \Seen
- flag name and not a flag-extension, even though "\Seen" can be parsed
- as a flag-extension. Some, but not all, instances of this rule are
- noted below.
-
- Note: [ABNF] rules MUST be followed strictly; in
- particular:
-
- (1) 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.
-
- (2) In all cases, SP refers to exactly one space. It is
- NOT permitted to substitute TAB, insert additional spaces,
- or otherwise treat SP as being equivalent to LWSP.
-
- (3) The ASCII NUL character, %x00, MUST NOT be used at any
- time.
-
-address = "(" addr-name SP addr-adl SP addr-mailbox SP
- addr-host ")"
-
-addr-adl = nstring
- ; Holds route from [RFC-2822] route-addr if
- ; non-NIL
-
-addr-host = nstring
- ; NIL indicates [RFC-2822] group syntax.
- ; Otherwise, holds [RFC-2822] domain name
-
-addr-mailbox = nstring
- ; NIL indicates end of [RFC-2822] group; if
- ; non-NIL and addr-host is NIL, holds
- ; [RFC-2822] group name.
- ; Otherwise, holds [RFC-2822] local-part
- ; after removing [RFC-2822] quoting
-
-
-
-
-
-
-Crispin Standards Track [Page 81]
-
-RFC 3501 IMAPv4 March 2003
-
-
-addr-name = nstring
- ; If non-NIL, holds phrase from [RFC-2822]
- ; mailbox after removing [RFC-2822] quoting
-
-append = "APPEND" SP mailbox [SP flag-list] [SP date-time] SP
- literal
-
-astring = 1*ASTRING-CHAR / string
-
-ASTRING-CHAR = ATOM-CHAR / resp-specials
-
-atom = 1*ATOM-CHAR
-
-ATOM-CHAR = <any CHAR except atom-specials>
-
-atom-specials = "(" / ")" / "{" / SP / CTL / list-wildcards /
- quoted-specials / resp-specials
-
-authenticate = "AUTHENTICATE" SP auth-type *(CRLF base64)
-
-auth-type = atom
- ; Defined by [SASL]
-
-base64 = *(4base64-char) [base64-terminal]
-
-base64-char = ALPHA / DIGIT / "+" / "/"
- ; Case-sensitive
-
-base64-terminal = (2base64-char "==") / (3base64-char "=")
-
-body = "(" (body-type-1part / body-type-mpart) ")"
-
-body-extension = nstring / number /
- "(" body-extension *(SP 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 [SP body-fld-dsp [SP body-fld-lang
- [SP body-fld-loc *(SP body-extension)]]]
- ; MUST NOT be returned on non-extensible
- ; "BODY" fetch
-
-
-
-
-
-
-Crispin Standards Track [Page 82]
-
-RFC 3501 IMAPv4 March 2003
-
-
-body-ext-mpart = body-fld-param [SP body-fld-dsp [SP body-fld-lang
- [SP body-fld-loc *(SP body-extension)]]]
- ; MUST NOT be returned on non-extensible
- ; "BODY" fetch
-
-body-fields = body-fld-param SP body-fld-id SP body-fld-desc SP
- body-fld-enc SP body-fld-octets
-
-body-fld-desc = nstring
-
-body-fld-dsp = "(" string SP body-fld-param ")" / nil
-
-body-fld-enc = (DQUOTE ("7BIT" / "8BIT" / "BINARY" / "BASE64"/
- "QUOTED-PRINTABLE") DQUOTE) / string
-
-body-fld-id = nstring
-
-body-fld-lang = nstring / "(" string *(SP string) ")"
-
-body-fld-loc = nstring
-
-body-fld-lines = number
-
-body-fld-md5 = nstring
-
-body-fld-octets = number
-
-body-fld-param = "(" string SP string *(SP string SP string) ")" / nil
-
-body-type-1part = (body-type-basic / body-type-msg / body-type-text)
- [SP body-ext-1part]
-
-body-type-basic = media-basic SP body-fields
- ; MESSAGE subtype MUST NOT be "RFC822"
-
-body-type-mpart = 1*body SP media-subtype
- [SP body-ext-mpart]
-
-body-type-msg = media-message SP body-fields SP envelope
- SP body SP body-fld-lines
-
-body-type-text = media-text SP body-fields SP body-fld-lines
-
-capability = ("AUTH=" auth-type) / atom
- ; New capabilities MUST begin with "X" or be
- ; registered with IANA as standard or
- ; standards-track
-
-
-
-
-Crispin Standards Track [Page 83]
-
-RFC 3501 IMAPv4 March 2003
-
-
-capability-data = "CAPABILITY" *(SP capability) SP "IMAP4rev1"
- *(SP capability)
- ; Servers MUST implement the STARTTLS, AUTH=PLAIN,
- ; and LOGINDISABLED capabilities
- ; Servers which offer RFC 1730 compatibility MUST
- ; list "IMAP4" as the first capability.
-
-CHAR8 = %x01-ff
- ; any OCTET except NUL, %x00
-
-command = tag SP (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 / list / lsub /
- rename / select / status / subscribe / unsubscribe
- ; Valid only in Authenticated or Selected state
-
-command-nonauth = login / authenticate / "STARTTLS"
- ; Valid only when in Not Authenticated state
-
-command-select = "CHECK" / "CLOSE" / "EXPUNGE" / copy / fetch / store /
- uid / search
- ; Valid only when in Selected state
-
-continue-req = "+" SP (resp-text / base64) CRLF
-
-copy = "COPY" SP sequence-set SP mailbox
-
-create = "CREATE" SP mailbox
- ; Use of INBOX gives a NO error
-
-date = date-text / DQUOTE date-text DQUOTE
-
-date-day = 1*2DIGIT
- ; Day of month
-
-date-day-fixed = (SP 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
-
-
-
-
-Crispin Standards Track [Page 84]
-
-RFC 3501 IMAPv4 March 2003
-
-
-date-year = 4DIGIT
-
-date-time = DQUOTE date-day-fixed "-" date-month "-" date-year
- SP time SP zone DQUOTE
-
-delete = "DELETE" SP mailbox
- ; Use of INBOX gives a NO error
-
-digit-nz = %x31-39
- ; 1-9
-
-envelope = "(" env-date SP env-subject SP env-from SP
- env-sender SP env-reply-to SP env-to SP env-cc SP
- env-bcc SP env-in-reply-to SP env-message-id ")"
-
-env-bcc = "(" 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" SP mailbox
-
-fetch = "FETCH" SP sequence-set SP ("ALL" / "FULL" / "FAST" /
- fetch-att / "(" fetch-att *(SP fetch-att) ")")
-
-fetch-att = "ENVELOPE" / "FLAGS" / "INTERNALDATE" /
- "RFC822" [".HEADER" / ".SIZE" / ".TEXT"] /
- "BODY" ["STRUCTURE"] / "UID" /
- "BODY" section ["<" number "." nz-number ">"] /
- "BODY.PEEK" section ["<" number "." nz-number ">"]
-
-
-
-
-
-
-Crispin Standards Track [Page 85]
-
-RFC 3501 IMAPv4 March 2003
-
-
-flag = "\Answered" / "\Flagged" / "\Deleted" /
- "\Seen" / "\Draft" / flag-keyword / flag-extension
- ; Does not include "\Recent"
-
-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-fetch = flag / "\Recent"
-
-flag-keyword = atom
-
-flag-list = "(" [flag *(SP flag)] ")"
-
-flag-perm = flag / "\*"
-
-greeting = "*" SP (resp-cond-auth / resp-cond-bye) CRLF
-
-header-fld-name = astring
-
-header-list = "(" header-fld-name *(SP header-fld-name) ")"
-
-list = "LIST" SP mailbox SP list-mailbox
-
-list-mailbox = 1*list-char / string
-
-list-char = ATOM-CHAR / list-wildcards / resp-specials
-
-list-wildcards = "%" / "*"
-
-literal = "{" number "}" CRLF *CHAR8
- ; Number represents the number of CHAR8s
-
-login = "LOGIN" SP userid SP password
-
-lsub = "LSUB" SP mailbox SP list-mailbox
-
-
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 86]
-
-RFC 3501 IMAPv4 March 2003
-
-
-mailbox = "INBOX" / astring
- ; INBOX is case-insensitive. All case variants of
- ; INBOX (e.g., "iNbOx") MUST be interpreted as INBOX
- ; not as an astring. An astring which consists of
- ; the case-insensitive sequence "I" "N" "B" "O" "X"
- ; is considered to be INBOX and not an astring.
- ; Refer to section 5.1 for further
- ; semantic details of mailbox names.
-
-mailbox-data = "FLAGS" SP flag-list / "LIST" SP mailbox-list /
- "LSUB" SP mailbox-list / "SEARCH" *(SP nz-number) /
- "STATUS" SP mailbox SP "(" [status-att-list] ")" /
- number SP "EXISTS" / number SP "RECENT"
-
-mailbox-list = "(" [mbx-list-flags] ")" SP
- (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox
-
-mbx-list-flags = *(mbx-list-oflag SP) mbx-list-sflag
- *(SP mbx-list-oflag) /
- mbx-list-oflag *(SP mbx-list-oflag)
-
-mbx-list-oflag = "\Noinferiors" / flag-extension
- ; Other flags; multiple possible per LIST response
-
-mbx-list-sflag = "\Noselect" / "\Marked" / "\Unmarked"
- ; Selectability flags; only one per LIST response
-
-media-basic = ((DQUOTE ("APPLICATION" / "AUDIO" / "IMAGE" /
- "MESSAGE" / "VIDEO") DQUOTE) / string) SP
- media-subtype
- ; Defined in [MIME-IMT]
-
-media-message = DQUOTE "MESSAGE" DQUOTE SP DQUOTE "RFC822" DQUOTE
- ; Defined in [MIME-IMT]
-
-media-subtype = string
- ; Defined in [MIME-IMT]
-
-media-text = DQUOTE "TEXT" DQUOTE SP media-subtype
- ; Defined in [MIME-IMT]
-
-message-data = nz-number SP ("EXPUNGE" / ("FETCH" SP msg-att))
-
-msg-att = "(" (msg-att-dynamic / msg-att-static)
- *(SP (msg-att-dynamic / msg-att-static)) ")"
-
-msg-att-dynamic = "FLAGS" SP "(" [flag-fetch *(SP flag-fetch)] ")"
- ; MAY change for a message
-
-
-
-Crispin Standards Track [Page 87]
-
-RFC 3501 IMAPv4 March 2003
-
-
-msg-att-static = "ENVELOPE" SP envelope / "INTERNALDATE" SP date-time /
- "RFC822" [".HEADER" / ".TEXT"] SP nstring /
- "RFC822.SIZE" SP number /
- "BODY" ["STRUCTURE"] SP body /
- "BODY" section ["<" number ">"] SP nstring /
- "UID" SP uniqueid
- ; MUST NOT change for a message
-
-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)
-
-password = astring
-
-quoted = DQUOTE *QUOTED-CHAR DQUOTE
-
-QUOTED-CHAR = <any TEXT-CHAR except quoted-specials> /
- "\" quoted-specials
-
-quoted-specials = DQUOTE / "\"
-
-rename = "RENAME" SP mailbox SP mailbox
- ; Use of INBOX as a destination gives a NO error
-
-response = *(continue-req / response-data) response-done
-
-response-data = "*" SP (resp-cond-state / resp-cond-bye /
- mailbox-data / message-data / capability-data) CRLF
-
-response-done = response-tagged / response-fatal
-
-response-fatal = "*" SP resp-cond-bye CRLF
- ; Server closes connection immediately
-
-response-tagged = tag SP resp-cond-state CRLF
-
-resp-cond-auth = ("OK" / "PREAUTH") SP resp-text
- ; Authentication condition
-
-
-
-
-
-Crispin Standards Track [Page 88]
-
-RFC 3501 IMAPv4 March 2003
-
-
-resp-cond-bye = "BYE" SP resp-text
-
-resp-cond-state = ("OK" / "NO" / "BAD") SP resp-text
- ; Status condition
-
-resp-specials = "]"
-
-resp-text = ["[" resp-text-code "]" SP] text
-
-resp-text-code = "ALERT" /
- "BADCHARSET" [SP "(" astring *(SP astring) ")" ] /
- capability-data / "PARSE" /
- "PERMANENTFLAGS" SP "("
- [flag-perm *(SP flag-perm)] ")" /
- "READ-ONLY" / "READ-WRITE" / "TRYCREATE" /
- "UIDNEXT" SP nz-number / "UIDVALIDITY" SP nz-number /
- "UNSEEN" SP nz-number /
- atom [SP 1*<any TEXT-CHAR except "]">]
-
-search = "SEARCH" [SP "CHARSET" SP astring] 1*(SP search-key)
- ; CHARSET argument to MUST be registered with IANA
-
-search-key = "ALL" / "ANSWERED" / "BCC" SP astring /
- "BEFORE" SP date / "BODY" SP astring /
- "CC" SP astring / "DELETED" / "FLAGGED" /
- "FROM" SP astring / "KEYWORD" SP flag-keyword /
- "NEW" / "OLD" / "ON" SP date / "RECENT" / "SEEN" /
- "SINCE" SP date / "SUBJECT" SP astring /
- "TEXT" SP astring / "TO" SP astring /
- "UNANSWERED" / "UNDELETED" / "UNFLAGGED" /
- "UNKEYWORD" SP flag-keyword / "UNSEEN" /
- ; Above this line were in [IMAP2]
- "DRAFT" / "HEADER" SP header-fld-name SP astring /
- "LARGER" SP number / "NOT" SP search-key /
- "OR" SP search-key SP search-key /
- "SENTBEFORE" SP date / "SENTON" SP date /
- "SENTSINCE" SP date / "SMALLER" SP number /
- "UID" SP sequence-set / "UNDRAFT" / sequence-set /
- "(" search-key *(SP search-key) ")"
-
-section = "[" [section-spec] "]"
-
-section-msgtext = "HEADER" / "HEADER.FIELDS" [".NOT"] SP header-list /
- "TEXT"
- ; top-level or MESSAGE/RFC822 part
-
-section-part = nz-number *("." nz-number)
- ; body part nesting
-
-
-
-Crispin Standards Track [Page 89]
-
-RFC 3501 IMAPv4 March 2003
-
-
-section-spec = section-msgtext / (section-part ["." section-text])
-
-section-text = section-msgtext / "MIME"
- ; text other than actual body part (headers, etc.)
-
-select = "SELECT" SP mailbox
-
-seq-number = nz-number / "*"
- ; message sequence number (COPY, FETCH, STORE
- ; commands) or unique identifier (UID COPY,
- ; UID FETCH, UID STORE commands).
- ; * represents the largest number in use. In
- ; the case of message sequence numbers, it is
- ; the number of messages in a non-empty mailbox.
- ; In the case of unique identifiers, it is the
- ; unique identifier of the last message in the
- ; mailbox or, if the mailbox is empty, the
- ; mailbox's current UIDNEXT value.
- ; The server should respond with a tagged BAD
- ; response to a command that uses a message
- ; sequence number greater than the number of
- ; messages in the selected mailbox. This
- ; includes "*" if the selected mailbox is empty.
-
-seq-range = seq-number ":" seq-number
- ; two seq-number values and all values between
- ; these two regardless of order.
- ; Example: 2:4 and 4:2 are equivalent and indicate
- ; values 2, 3, and 4.
- ; Example: a unique identifer sequence range of
- ; 3291:* includes the UID of the last message in
- ; the mailbox, even if that value is less than 3291.
-
-sequence-set = (seq-number / seq-range) *("," sequence-set)
- ; set of seq-number values, regardless of order.
- ; Servers MAY coalesce overlaps and/or execute the
- ; sequence in any order.
- ; Example: a message sequence number set of
- ; 2,4:7,9,12:* for a mailbox with 15 messages is
- ; equivalent to 2,4,5,6,7,9,12,13,14,15
- ; Example: a message sequence number set of *:4,5:7
- ; for a mailbox with 10 messages is equivalent to
- ; 10,9,8,7,6,5,4,5,6,7 and MAY be reordered and
- ; overlap coalesced to be 4,5,6,7,8,9,10.
-
-status = "STATUS" SP mailbox SP
- "(" status-att *(SP status-att) ")"
-
-
-
-
-Crispin Standards Track [Page 90]
-
-RFC 3501 IMAPv4 March 2003
-
-
-status-att = "MESSAGES" / "RECENT" / "UIDNEXT" / "UIDVALIDITY" /
- "UNSEEN"
-
-status-att-list = status-att SP number *(SP status-att SP number)
-
-store = "STORE" SP sequence-set SP store-att-flags
-
-store-att-flags = (["+" / "-"] "FLAGS" [".SILENT"]) SP
- (flag-list / (flag *(SP flag)))
-
-string = quoted / literal
-
-subscribe = "SUBSCRIBE" SP mailbox
-
-tag = 1*<any ASTRING-CHAR except "+">
-
-text = 1*TEXT-CHAR
-
-TEXT-CHAR = <any CHAR except CR and LF>
-
-time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
- ; Hours minutes seconds
-
-uid = "UID" SP (copy / fetch / search / store)
- ; Unique identifiers used instead of message
- ; sequence numbers
-
-uniqueid = nz-number
- ; Strictly ascending
-
-unsubscribe = "UNSUBSCRIBE" SP mailbox
-
-userid = astring
-
-x-command = "X" atom <experimental command arguments>
-
-zone = ("+" / "-") 4DIGIT
- ; Signed four-digit value of hhmm representing
- ; hours and minutes east 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 Standards Track [Page 91]
-
-RFC 3501 IMAPv4 March 2003
-
-
-10. Author's Note
-
- This document is a revision or rewrite of earlier documents, and
- supercedes the protocol specification in those documents: RFC 2060,
- RFC 1730, unpublished IMAP2bis.TXT document, RFC 1176, and RFC 1064.
-
-11. Security Considerations
-
- IMAP4rev1 protocol transactions, including electronic mail data, are
- sent in the clear over the network unless protection from snooping is
- negotiated. This can be accomplished either by the use of STARTTLS,
- negotiated privacy protection in the AUTHENTICATE command, or some
- other protection mechanism.
-
-11.1. STARTTLS Security Considerations
-
- The specification of the STARTTLS command and LOGINDISABLED
- capability in this document replaces that in [IMAP-TLS]. [IMAP-TLS]
- remains normative for the PLAIN [SASL] authenticator.
-
- IMAP client and server implementations MUST implement the
- TLS_RSA_WITH_RC4_128_MD5 [TLS] cipher suite, and SHOULD implement the
- TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] cipher suite. This is
- important as it assures that any two compliant implementations can be
- configured to interoperate. All other cipher suites are OPTIONAL.
- Note that this is a change from section 2.1 of [IMAP-TLS].
-
- During the [TLS] negotiation, the client MUST check its understanding
- of the server hostname against the server's identity as presented in
- the server Certificate message, in order to prevent man-in-the-middle
- attacks. If the match fails, the client SHOULD either ask for
- explicit user confirmation, or terminate the connection and indicate
- that the server's identity is suspect. Matching is performed
- according to these rules:
-
- The client MUST use the server hostname it used to open the
- connection as the value to compare against the server name
- as expressed in the server certificate. The client MUST
- NOT use any form of the server hostname derived from an
- insecure remote source (e.g., insecure DNS lookup). CNAME
- canonicalization is not done.
-
- If a subjectAltName extension of type dNSName is present in
- the certificate, it SHOULD be used as the source of the
- server's identity.
-
- Matching is case-insensitive.
-
-
-
-
-Crispin Standards Track [Page 92]
-
-RFC 3501 IMAPv4 March 2003
-
-
- A "*" wildcard character MAY be used as the left-most name
- component in the certificate. For example, *.example.com
- would match a.example.com, foo.example.com, etc. but would
- not match example.com.
-
- If the certificate contains multiple names (e.g., more than
- one dNSName field), then a match with any one of the fields
- is considered acceptable.
-
- Both the client and server MUST check the result of the STARTTLS
- command and subsequent [TLS] negotiation to see whether acceptable
- authentication or privacy was achieved.
-
-11.2. Other Security Considerations
-
- 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 with a [SASL] mechanism
- that does not use plaintext passwords, by first negotiating
- encryption via STARTTLS or some other protection mechanism.
-
- A server implementation MUST implement a configuration that, at the
- time of authentication, requires:
- (1) The STARTTLS command has been negotiated.
- OR
- (2) Some other mechanism that protects the session from password
- snooping has been provided.
- OR
- (3) The following measures are in place:
- (a) The LOGINDISABLED capability is advertised, and [SASL]
- mechanisms (such as PLAIN) using plaintext passwords are NOT
- advertised in the CAPABILITY list.
- AND
- (b) The LOGIN command returns an error even if the password is
- correct.
- AND
- (c) The AUTHENTICATE command returns an error with all [SASL]
- mechanisms that use plaintext passwords, even if the password
- is correct.
-
- A server error message for a failing LOGIN command SHOULD NOT specify
- that the user name, as opposed to the password, is invalid.
-
- A server SHOULD have mechanisms in place to limit or delay failed
- AUTHENTICATE/LOGIN attempts.
-
-
-
-Crispin Standards Track [Page 93]
-
-RFC 3501 IMAPv4 March 2003
-
-
- Additional security considerations are discussed in the section
- discussing the AUTHENTICATE and LOGIN commands.
-
-12. IANA Considerations
-
- IMAP4 capabilities are registered by publishing a standards track or
- IESG approved experimental RFC. The registry is currently located
- at:
-
- http://www.iana.org/assignments/imap4-capabilities
-
- As this specification revises the STARTTLS and LOGINDISABLED
- extensions previously defined in [IMAP-TLS], the registry will be
- updated accordingly.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 94]
-
-RFC 3501 IMAPv4 March 2003
-
-
-Appendices
-
-A. Normative References
-
- The following documents contain definitions or specifications that
- are necessary to understand this document properly:
- [ABNF] Crocker, D. and P. Overell, "Augmented BNF for
- Syntax Specifications: ABNF", RFC 2234,
- November 1997.
-
- [ANONYMOUS] Newman, C., "Anonymous SASL Mechanism", RFC
- 2245, November 1997.
-
- [CHARSET] Freed, N. and J. Postel, "IANA Character Set
- Registration Procedures", RFC 2978, October
- 2000.
-
- [DIGEST-MD5] Leach, P. and C. Newman, "Using Digest
- Authentication as a SASL Mechanism", RFC 2831,
- May 2000.
-
- [DISPOSITION] Troost, R., Dorner, S. and K. Moore,
- "Communicating Presentation Information in
- Internet Messages: The Content-Disposition
- Header", RFC 2183, August 1997.
-
- [IMAP-TLS] Newman, C., "Using TLS with IMAP, POP3 and
- ACAP", RFC 2595, June 1999.
-
- [KEYWORDS] Bradner, S., "Key words for use in RFCs to
- Indicate Requirement Levels", BCP 14, RFC 2119,
- March 1997.
-
- [LANGUAGE-TAGS] Alvestrand, H., "Tags for the Identification of
- Languages", BCP 47, RFC 3066, January 2001.
-
- [LOCATION] Palme, J., Hopmann, A. and N. Shelness, "MIME
- Encapsulation of Aggregate Documents, such as
- HTML (MHTML)", RFC 2557, March 1999.
-
- [MD5] Myers, J. and M. Rose, "The Content-MD5 Header
- Field", RFC 1864, October 1995.
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 95]
-
-RFC 3501 IMAPv4 March 2003
-
-
- [MIME-HDRS] Moore, K., "MIME (Multipurpose Internet Mail
- Extensions) Part Three: Message Header
- Extensions for Non-ASCII Text", RFC 2047,
- November 1996.
-
- [MIME-IMB] Freed, N. and N. Borenstein, "MIME
- (Multipurpose Internet Mail Extensions) Part
- One: Format of Internet Message Bodies", RFC
- 2045, November 1996.
-
- [MIME-IMT] Freed, N. and N. Borenstein, "MIME
- (Multipurpose Internet Mail Extensions) Part
- Two: Media Types", RFC 2046, November 1996.
-
- [RFC-2822] Resnick, P., "Internet Message Format", RFC
- 2822, April 2001.
-
- [SASL] Myers, J., "Simple Authentication and Security
- Layer (SASL)", RFC 2222, October 1997.
-
- [TLS] Dierks, T. and C. Allen, "The TLS Protocol
- Version 1.0", RFC 2246, January 1999.
-
- [UTF-7] Goldsmith, D. and M. Davis, "UTF-7: A Mail-Safe
- Transformation Format of Unicode", RFC 2152,
- May 1997.
-
- The following documents describe quality-of-implementation issues
- that should be carefully considered when implementing this protocol:
-
- [IMAP-IMPLEMENTATION] Leiba, B., "IMAP Implementation
- Recommendations", RFC 2683, September 1999.
-
- [IMAP-MULTIACCESS] Gahrns, M., "IMAP4 Multi-Accessed Mailbox
- Practice", RFC 2180, July 1997.
-
-A.1 Informative References
-
- The following documents describe related protocols:
-
- [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, December 1994.
-
-
-
-
-
-
-Crispin Standards Track [Page 96]
-
-RFC 3501 IMAPv4 March 2003
-
-
- [ACAP] Newman, C. and J. Myers, "ACAP -- Application
- Configuration Access Protocol", RFC 2244,
- November 1997.
-
- [SMTP] Klensin, J., "Simple Mail Transfer Protocol",
- STD 10, RFC 2821, April 2001.
-
- The following documents are historical or describe historical aspects
- of this protocol:
-
- [IMAP-COMPAT] Crispin, M., "IMAP4 Compatibility with
- IMAP2bis", RFC 2061, December 1996.
-
- [IMAP-HISTORICAL] Crispin, M., "IMAP4 Compatibility with IMAP2
- and IMAP2bis", RFC 1732, December 1994.
-
- [IMAP-OBSOLETE] Crispin, M., "Internet Message Access Protocol
- - Obsolete Syntax", RFC 2062, December 1996.
-
- [IMAP2] Crispin, M., "Interactive Mail Access Protocol
- - Version 2", RFC 1176, August 1990.
-
- [RFC-822] Crocker, D., "Standard for the Format of ARPA
- Internet Text Messages", STD 11, RFC 822,
- August 1982.
-
- [RFC-821] Postel, J., "Simple Mail Transfer Protocol",
- STD 10, RFC 821, August 1982.
-
-B. Changes from RFC 2060
-
- 1) Clarify description of unique identifiers and their semantics.
-
- 2) Fix the SELECT description to clarify that UIDVALIDITY is required
- in the SELECT and EXAMINE responses.
-
- 3) Added an example of a failing search.
-
- 4) Correct store-att-flags: "#flag" should be "1#flag".
-
- 5) Made search and section rules clearer.
-
- 6) Correct the STORE example.
-
- 7) Correct "BASE645" misspelling.
-
- 8) Remove extraneous close parenthesis in example of two-part message
- with text and BASE64 attachment.
-
-
-
-Crispin Standards Track [Page 97]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 9) Remove obsolete "MAILBOX" response from mailbox-data.
-
- 10) A spurious "<" in the rule for mailbox-data was removed.
-
- 11) Add CRLF to continue-req.
-
- 12) Specifically exclude "]" from the atom in resp-text-code.
-
- 13) Clarify that clients and servers should adhere strictly to the
- protocol syntax.
-
- 14) Emphasize in 5.2 that EXISTS can not be used to shrink a mailbox.
-
- 15) Add NEWNAME to resp-text-code.
-
- 16) Clarify that the empty string, not NIL, is used as arguments to
- LIST.
-
- 17) Clarify that NIL can be returned as a hierarchy delimiter for the
- empty string mailbox name argument if the mailbox namespace is flat.
-
- 18) Clarify that addr-mailbox and addr-name have RFC-2822 quoting
- removed.
-
- 19) Update UTF-7 reference.
-
- 20) Fix example in 6.3.11.
-
- 21) Clarify that non-existent UIDs are ignored.
-
- 22) Update DISPOSITION reference.
-
- 23) Expand state diagram.
-
- 24) Clarify that partial fetch responses are only returned in
- response to a partial fetch command.
-
- 25) Add UIDNEXT response code. Correct UIDVALIDITY definition
- reference.
-
- 26) Further clarification of "can" vs. "MAY".
-
- 27) Reference RFC-2119.
-
- 28) Clarify that superfluous shifts are not permitted in modified
- UTF-7.
-
- 29) Clarify that there are no implicit shifts in modified UTF-7.
-
-
-
-Crispin Standards Track [Page 98]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 30) Clarify that "INBOX" in a mailbox name is always INBOX, even if
- it is given as a string.
-
- 31) Add missing open parenthesis in media-basic grammar rule.
-
- 32) Correct attribute syntax in mailbox-data.
-
- 33) Add UIDNEXT to EXAMINE responses.
-
- 34) Clarify UNSEEN, PERMANENTFLAGS, UIDVALIDITY, and UIDNEXT
- responses in SELECT and EXAMINE. They are required now, but weren't
- in older versions.
-
- 35) Update references with RFC numbers.
-
- 36) Flush text-mime2.
-
- 37) Clarify that modified UTF-7 names must be case-sensitive and that
- violating the convention should be avoided.
-
- 38) Correct UID FETCH example.
-
- 39) Clarify UID FETCH, UID STORE, and UID SEARCH vs. untagged EXPUNGE
- responses.
-
- 40) Clarify the use of the word "convention".
-
- 41) Clarify that a command is not "in progress" until it has been
- fully received (specifically, that a command is not "in progress"
- during command continuation negotiation).
-
- 42) Clarify envelope defaulting.
-
- 43) Clarify that SP means one and only one space character.
-
- 44) Forbid silly states in LIST response.
-
- 45) Clarify that the ENVELOPE, INTERNALDATE, RFC822*, BODY*, and UID
- for a message is static.
-
- 46) Add BADCHARSET response code.
-
- 47) Update formal syntax to [ABNF] conventions.
-
- 48) Clarify trailing hierarchy delimiter in CREATE semantics.
-
- 49) Clarify that the "blank line" is the [RFC-2822] delimiting blank
- line.
-
-
-
-Crispin Standards Track [Page 99]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 50) Clarify that RENAME should also create hierarchy as needed for
- the command to complete.
-
- 51) Fix body-ext-mpart to not require language if disposition
- present.
-
- 52) Clarify the RFC822.HEADER response.
-
- 53) Correct missing space after charset astring in search.
-
- 54) Correct missing quote for BADCHARSET in resp-text-code.
-
- 55) Clarify that ALL, FAST, and FULL preclude any other data items
- appearing.
-
- 56) Clarify semantics of reference argument in LIST.
-
- 57) Clarify that a null string for SEARCH HEADER X-FOO means any
- message with a header line with a field-name of X-FOO regardless of
- the text of the header.
-
- 58) Specifically reserve 8-bit mailbox names for future use as UTF-8.
-
- 59) It is not an error for the client to store a flag that is not in
- the PERMANENTFLAGS list; however, the server will either ignore the
- change or make the change in the session only.
-
- 60) Correct/clarify the text regarding superfluous shifts.
-
- 61) Correct typographic errors in the "Changes" section.
-
- 62) Clarify that STATUS must not be used to check for new messages in
- the selected mailbox
-
- 63) Clarify LSUB behavior with "%" wildcard.
-
- 64) Change AUTHORIZATION to AUTHENTICATE in section 7.5.
-
- 65) Clarify description of multipart body type.
-
- 66) Clarify that STORE FLAGS does not affect \Recent.
-
- 67) Change "west" to "east" in description of timezone.
-
- 68) Clarify that commands which break command pipelining must wait
- for a completion result response.
-
- 69) Clarify that EXAMINE does not affect \Recent.
-
-
-
-Crispin Standards Track [Page 100]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 70) Make description of MIME structure consistent.
-
- 71) Clarify that date searches disregard the time and timezone of the
- INTERNALDATE or Date: header. In other words, "ON 13-APR-2000" means
- messages with an INTERNALDATE text which starts with "13-APR-2000",
- even if timezone differential from the local timezone is sufficient
- to move that INTERNALDATE into the previous or next day.
-
- 72) Clarify that the header fetches don't add a blank line if one
- isn't in the [RFC-2822] message.
-
- 73) Clarify (in discussion of UIDs) that messages are immutable.
-
- 74) Add an example of CHARSET searching.
-
- 75) Clarify in SEARCH that keywords are a type of flag.
-
- 76) Clarify the mandatory nature of the SELECT data responses.
-
- 77) Add optional CAPABILITY response code in the initial OK or
- PREAUTH.
-
- 78) Add note that server can send an untagged CAPABILITY command as
- part of the responses to AUTHENTICATE and LOGIN.
-
- 79) Remove statement about it being unnecessary to issue a CAPABILITY
- command more than once in a connection. That statement is no longer
- true.
-
- 80) Clarify that untagged EXPUNGE decrements the number of messages
- in the mailbox.
-
- 81) Fix definition of "body" (concatenation has tighter binding than
- alternation).
-
- 82) Add a new "Special Notes to Implementors" section with reference
- to [IMAP-IMPLEMENTATION].
-
- 83) Clarify that an untagged CAPABILITY response to an AUTHENTICATE
- command should only be done if a security layer was not negotiated.
-
- 84) Change the definition of atom to exclude "]". Update astring to
- include "]" for compatiblity with the past. Remove resp-text-atom.
-
- 85) Remove NEWNAME. It can't work because mailbox names can be
- literals and can include "]". Functionality can be addressed via
- referrals.
-
-
-
-
-Crispin Standards Track [Page 101]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 86) Move modified UTF-7 rationale in order to have more logical
- paragraph flow.
-
- 87) Clarify UID uniqueness guarantees with the use of MUST.
-
- 88) Note that clients should read response data until the connection
- is closed instead of immediately closing on a BYE.
-
- 89) Change RFC-822 references to RFC-2822.
-
- 90) Clarify that RFC-2822 should be followed instead of RFC-822.
-
- 91) Change recommendation of optional automatic capabilities in LOGIN
- and AUTHENTICATE to use the CAPABILITY response code in the tagged
- OK. This is more interoperable than an unsolicited untagged
- CAPABILITY response.
-
- 92) STARTTLS and AUTH=PLAIN are mandatory to implement; add
- recommendations for other [SASL] mechanisms.
-
- 93) Clarify that a "connection" (as opposed to "server" or "command")
- is in one of the four states.
-
- 94) Clarify that a failed or rejected command does not change state.
-
- 95) Split references between normative and informative.
-
- 96) Discuss authentication failure issues in security section.
-
- 97) Clarify that a data item is not necessarily of only one data
- type.
-
- 98) Clarify that sequence ranges are independent of order.
-
- 99) Change an example to clarify that superfluous shifts in
- Modified-UTF7 can not be fixed just by omitting the shift. The
- entire string must be recalculated.
-
- 100) Change Envelope Structure definition since [RFC-2822] uses
- "envelope" to refer to the [SMTP] envelope and not the envelope data
- that appears in the [RFC-2822] header.
-
- 101) Expand on RFC822.HEADER response data vs. BODY[HEADER].
-
- 102) Clarify Logout state semantics, change ASCII art.
-
- 103) Security changes to comply with IESG requirements.
-
-
-
-
-Crispin Standards Track [Page 102]
-
-RFC 3501 IMAPv4 March 2003
-
-
- 104) Add definition for body URI.
-
- 105) Break sequence range definition into three rules, with rewritten
- descriptions for each.
-
- 106) Move STARTTLS and LOGINDISABLED here from [IMAP-TLS].
-
- 107) Add IANA Considerations section.
-
- 108) Clarify valid client assumptions for new message UIDs vs.
- UIDNEXT.
-
- 109) Clarify that changes to permanentflags affect concurrent
- sessions as well as subsequent sessions.
-
- 110) Clarify that authenticated state can be entered by the CLOSE
- command.
-
- 111) Emphasize that SELECT and EXAMINE are the exceptions to the rule
- that a failing command does not change state.
-
- 112) Clarify that newly-appended messages have the Recent flag set.
-
- 113) Clarify that newly-copied messages SHOULD have the Recent flag
- set.
-
- 114) Clarify that UID commands always return the UID in FETCH
- responses.
-
-C. Key Word Index
-
- +FLAGS <flag list> (store command data item) ............... 59
- +FLAGS.SILENT <flag list> (store command data item) ........ 59
- -FLAGS <flag list> (store command data item) ............... 59
- -FLAGS.SILENT <flag list> (store command data item) ........ 59
- ALERT (response code) ...................................... 64
- ALL (fetch item) ........................................... 55
- ALL (search key) ........................................... 50
- ANSWERED (search key) ...................................... 50
- APPEND (command) ........................................... 45
- AUTHENTICATE (command) ..................................... 27
- BAD (response) ............................................. 66
- BADCHARSET (response code) ................................. 64
- BCC <string> (search key) .................................. 51
- BEFORE <date> (search key) ................................. 51
- BODY (fetch item) .......................................... 55
- BODY (fetch result) ........................................ 73
- BODY <string> (search key) ................................. 51
-
-
-
-Crispin Standards Track [Page 103]
-
-RFC 3501 IMAPv4 March 2003
-
-
- BODY.PEEK[<section>]<<partial>> (fetch item) ............... 57
- BODYSTRUCTURE (fetch item) ................................. 57
- BODYSTRUCTURE (fetch result) ............................... 74
- BODY[<section>]<<origin octet>> (fetch result) ............. 74
- BODY[<section>]<<partial>> (fetch item) .................... 55
- BYE (response) ............................................. 67
- Body Structure (message attribute) ......................... 12
- CAPABILITY (command) ....................................... 24
- CAPABILITY (response code) ................................. 64
- CAPABILITY (response) ...................................... 68
- CC <string> (search key) ................................... 51
- CHECK (command) ............................................ 47
- CLOSE (command) ............................................ 48
- COPY (command) ............................................. 59
- CREATE (command) ........................................... 34
- DELETE (command) ........................................... 35
- DELETED (search key) ....................................... 51
- DRAFT (search key) ......................................... 51
- ENVELOPE (fetch item) ...................................... 57
- ENVELOPE (fetch result) .................................... 77
- EXAMINE (command) .......................................... 33
- EXISTS (response) .......................................... 71
- EXPUNGE (command) .......................................... 48
- EXPUNGE (response) ......................................... 72
- Envelope Structure (message attribute) ..................... 12
- FAST (fetch item) .......................................... 55
- FETCH (command) ............................................ 54
- FETCH (response) ........................................... 73
- FLAGGED (search key) ....................................... 51
- FLAGS (fetch item) ......................................... 57
- FLAGS (fetch result) ....................................... 78
- FLAGS (response) ........................................... 71
- FLAGS <flag list> (store command data item) ................ 59
- FLAGS.SILENT <flag list> (store command data item) ......... 59
- FROM <string> (search key) ................................. 51
- FULL (fetch item) .......................................... 55
- Flags (message attribute) .................................. 11
- HEADER (part specifier) .................................... 55
- HEADER <field-name> <string> (search key) .................. 51
- HEADER.FIELDS <header-list> (part specifier) ............... 55
- HEADER.FIELDS.NOT <header-list> (part specifier) ........... 55
- INTERNALDATE (fetch item) .................................. 57
- INTERNALDATE (fetch result) ................................ 78
- Internal Date (message attribute) .......................... 12
- KEYWORD <flag> (search key) ................................ 51
- Keyword (type of flag) ..................................... 11
- LARGER <n> (search key) .................................... 51
- LIST (command) ............................................. 40
-
-
-
-Crispin Standards Track [Page 104]
-
-RFC 3501 IMAPv4 March 2003
-
-
- LIST (response) ............................................ 69
- LOGIN (command) ............................................ 30
- LOGOUT (command) ........................................... 25
- LSUB (command) ............................................. 43
- LSUB (response) ............................................ 70
- MAY (specification requirement term) ....................... 4
- MESSAGES (status item) ..................................... 45
- MIME (part specifier) ...................................... 56
- MUST (specification requirement term) ...................... 4
- MUST NOT (specification requirement term) .................. 4
- Message Sequence Number (message attribute) ................ 10
- NEW (search key) ........................................... 51
- NO (response) .............................................. 66
- NOOP (command) ............................................. 25
- NOT <search-key> (search key) .............................. 52
- OK (response) .............................................. 65
- OLD (search key) ........................................... 52
- ON <date> (search key) ..................................... 52
- OPTIONAL (specification requirement term) .................. 4
- OR <search-key1> <search-key2> (search key) ................ 52
- PARSE (response code) ...................................... 64
- PERMANENTFLAGS (response code) ............................. 64
- PREAUTH (response) ......................................... 67
- Permanent Flag (class of flag) ............................. 12
- READ-ONLY (response code) .................................. 65
- READ-WRITE (response code) ................................. 65
- RECENT (response) .......................................... 72
- RECENT (search key) ........................................ 52
- RECENT (status item) ....................................... 45
- RENAME (command) ........................................... 37
- REQUIRED (specification requirement term) .................. 4
- RFC822 (fetch item) ........................................ 57
- RFC822 (fetch result) ...................................... 78
- RFC822.HEADER (fetch item) ................................. 57
- RFC822.HEADER (fetch result) ............................... 78
- RFC822.SIZE (fetch item) ................................... 57
- RFC822.SIZE (fetch result) ................................. 78
- RFC822.TEXT (fetch item) ................................... 58
- RFC822.TEXT (fetch result) ................................. 79
- SEARCH (command) ........................................... 49
- SEARCH (response) .......................................... 71
- SEEN (search key) .......................................... 52
- SELECT (command) ........................................... 31
- SENTBEFORE <date> (search key) ............................. 52
- SENTON <date> (search key) ................................. 52
- SENTSINCE <date> (search key) .............................. 52
- SHOULD (specification requirement term) .................... 4
- SHOULD NOT (specification requirement term) ................ 4
-
-
-
-Crispin Standards Track [Page 105]
-
-RFC 3501 IMAPv4 March 2003
-
-
- SINCE <date> (search key) .................................. 52
- SMALLER <n> (search key) ................................... 52
- STARTTLS (command) ......................................... 27
- STATUS (command) ........................................... 44
- STATUS (response) .......................................... 70
- STORE (command) ............................................ 58
- SUBJECT <string> (search key) .............................. 53
- SUBSCRIBE (command) ........................................ 38
- Session Flag (class of flag) ............................... 12
- System Flag (type of flag) ................................. 11
- TEXT (part specifier) ...................................... 56
- TEXT <string> (search key) ................................. 53
- TO <string> (search key) ................................... 53
- TRYCREATE (response code) .................................. 65
- UID (command) .............................................. 60
- UID (fetch item) ........................................... 58
- UID (fetch result) ......................................... 79
- UID <sequence set> (search key) ............................ 53
- UIDNEXT (response code) .................................... 65
- UIDNEXT (status item) ...................................... 45
- UIDVALIDITY (response code) ................................ 65
- UIDVALIDITY (status item) .................................. 45
- UNANSWERED (search key) .................................... 53
- UNDELETED (search key) ..................................... 53
- UNDRAFT (search key) ....................................... 53
- UNFLAGGED (search key) ..................................... 53
- UNKEYWORD <flag> (search key) .............................. 53
- UNSEEN (response code) ..................................... 65
- UNSEEN (search key) ........................................ 53
- UNSEEN (status item) ....................................... 45
- UNSUBSCRIBE (command) ...................................... 39
- Unique Identifier (UID) (message attribute) ................ 8
- X<atom> (command) .......................................... 62
- [RFC-2822] Size (message attribute) ........................ 12
- \Answered (system flag) .................................... 11
- \Deleted (system flag) ..................................... 11
- \Draft (system flag) ....................................... 11
- \Flagged (system flag) ..................................... 11
- \Marked (mailbox name attribute) ........................... 69
- \Noinferiors (mailbox name attribute) ...................... 69
- \Noselect (mailbox name attribute) ......................... 69
- \Recent (system flag) ...................................... 11
- \Seen (system flag) ........................................ 11
- \Unmarked (mailbox name attribute) ......................... 69
-
-
-
-
-
-
-
-Crispin Standards Track [Page 106]
-
-RFC 3501 IMAPv4 March 2003
-
-
-Author's Address
-
- Mark R. Crispin
- Networks and Distributed Computing
- University of Washington
- 4545 15th Avenue NE
- Seattle, WA 98105-4527
-
- Phone: (206) 543-5762
-
- EMail: MRC@CAC.Washington.EDU
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 107]
-
-RFC 3501 IMAPv4 March 2003
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns. v This
- document and the information contained herein is provided on an "AS
- IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
- FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
- LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
- NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
- OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Crispin Standards Track [Page 108]
-
-