You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by ba...@apache.org on 2006/07/29 15:16:01 UTC
svn commit: r426798 [10/30] - in
/james/server/trunk/src/site/resources/rfclist: ./ basic/ imap4/ ldap/
nntp/ pop3/ smtp/
Added: james/server/trunk/src/site/resources/rfclist/imap4/rfc2060.txt
URL: http://svn.apache.org/viewvc/james/server/trunk/src/site/resources/rfclist/imap4/rfc2060.txt?rev=426798&view=auto
==============================================================================
--- james/server/trunk/src/site/resources/rfclist/imap4/rfc2060.txt (added)
+++ james/server/trunk/src/site/resources/rfclist/imap4/rfc2060.txt Sat Jul 29 06:15:59 2006
@@ -0,0 +1,4596 @@
+
+
+
+
+
+Network Working Group M. Crispin
+Request for Comments: 2060 University of Washington
+Obsoletes: 1730 December 1996
+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.
+
+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 remote message folders,
+ called "mailboxes", in a way that is functionally equivalent to local
+ mailboxes. IMAP4rev1 also provides the capability for an offline
+ client to resynchronize with the server (see also [IMAP-DISC]).
+
+ IMAP4rev1 includes operations for creating, deleting, and renaming
+ mailboxes; checking for new messages; permanently removing messages;
+ setting and clearing flags; [RFC-822] and [MIME-IMB] 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 [ACAP].
+
+ IMAP4rev1 does not specify a means of posting mail; this function is
+ handled by a mail transfer protocol such as [SMTP].
+
+ IMAP4rev1 is designed to be upwards compatible from the [IMAP2] and
+ unpublished IMAP2bis protocols. In the course of the evolution of
+ IMAP4rev1, some aspects in the earlier protocol have become obsolete.
+ Obsolete commands, responses, and data formats which an IMAP4rev1
+ implementation may encounter when used with an earlier implementation
+ are described in [IMAP-OBSOLETE].
+
+
+
+
+
+Crispin Standards Track [Page 1]
+
+RFC 2060 IMAP4rev1 December 1996
+
+
+ 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)
+ variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is
+ primarily of historical interest.
+
+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
+2. Protocol Overview ......................................... 5
+2.1. Link Level ................................................ 5
+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 ........................................ 7
+2.3.1. Message Numbers ........................................... 7
+2.3.1.1. Unique Identifier (UID) Message Attribute ......... 7
+2.3.1.2. Message Sequence Number Message Attribute ......... 9
+2.3.2. Flags Message Attribute .................................... 9
+2.3.3. Internal Date Message Attribute ........................... 10
+2.3.4. [RFC-822] Size Message Attribute .......................... 11
+2.3.5. Envelope Structure Message Attribute ...................... 11
+2.3.6. Body Structure Message Attribute .......................... 11
+2.4. Message Texts ............................................. 11
+3. State and Flow Diagram .................................... 11
+3.1. Non-Authenticated State ................................... 11
+3.2. Authenticated State ....................................... 11
+3.3. Selected State ............................................ 12
+3.4. Logout State .............................................. 12
+4. Data Formats .............................................. 12
+4.1. Atom ...................................................... 13
+4.2. Number .................................................... 13
+4.3. String ..................................................... 13
+4.3.1. 8-bit and Binary Strings .................................. 13
+4.4. Parenthesized List ........................................ 14
+4.5. NIL ....................................................... 14
+5. Operational Considerations ................................ 14
+5.1. Mailbox Naming ............................................ 14
+5.1.1. Mailbox Hierarchy Naming .................................. 14
+5.1.2. Mailbox Namespace Naming Convention ....................... 14
+5.1.3. Mailbox International Naming Convention ................... 15
+5.2. Mailbox Size and Message Status Updates ................... 16
+5.3. Response when no Command in Progress ...................... 16
+5.4. Autologout Timer .......................................... 16
+5.5. Multiple Commands in Progress ............................. 17
+
+
+
+Crispin Standards Track [Page 2]
+
+RFC 2060 IMAP4rev1 December 1996
+
+
+6. Client Commands ........................................... 17
+6.1. Client Commands - Any State ............................... 18
+6.1.1. CAPABILITY Command ........................................ 18
+6.1.2. NOOP Command .............................................. 19
+6.1.3. LOGOUT Command ............................................ 20
+6.2. Client Commands - Non-Authenticated State ................. 20
+6.2.1. AUTHENTICATE Command ...................................... 21
+6.2.2. LOGIN Command ............................................. 22
+6.3. Client Commands - Authenticated State ..................... 22
+6.3.1. SELECT Command ............................................ 23
+6.3.2. EXAMINE Command ........................................... 24
+6.3.3. CREATE Command ............................................ 25
+6.3.4. DELETE Command ............................................ 26
+6.3.5. RENAME Command ............................................ 27
+6.3.6. SUBSCRIBE Command ......................................... 29
+6.3.7. UNSUBSCRIBE Command ....................................... 30
+6.3.8. LIST Command .............................................. 30
+6.3.9. LSUB Command .............................................. 32
+6.3.10. STATUS Command ............................................ 33
+6.3.11. APPEND Command ............................................ 34
+6.4. Client Commands - Selected State .......................... 35
+6.4.1. CHECK Command ............................................. 36
+6.4.2. CLOSE Command ............................................. 36
+6.4.3. EXPUNGE Command ........................................... 37
+6.4.4. SEARCH Command ............................................ 37
+6.4.5. FETCH Command ............................................. 41
+6.4.6. STORE Command ............................................. 45
+6.4.7. COPY Command .............................................. 46
+6.4.8. UID Command ............................................... 47
+6.5. Client Commands - Experimental/Expansion .................. 48
+6.5.1. X<atom> Command ........................................... 48
+7. Server Responses .......................................... 48
+7.1. Server Responses - Status Responses ....................... 49
+7.1.1. OK Response ............................................... 51
+7.1.2. NO Response ............................................... 51
+7.1.3. BAD Response .............................................. 52
+7.1.4. PREAUTH Response .......................................... 52
+7.1.5. BYE Response .............................................. 52
+7.2. Server Responses - Server and Mailbox Status .............. 53
+7.2.1. CAPABILITY Response ....................................... 53
+7.2.2. LIST Response .............................................. 54
+7.2.3. LSUB Response ............................................. 55
+7.2.4 STATUS Response ........................................... 55
+7.2.5. SEARCH Response ........................................... 55
+7.2.6. FLAGS Response ............................................ 56
+7.3. Server Responses - Mailbox Size ........................... 56
+7.3.1. EXISTS Response ........................................... 56
+7.3.2. RECENT Response ........................................... 57
+
+
+
+Crispin Standards Track [Page 3]
+
+RFC 2060 IMAP4rev1 December 1996
+
+
+7.4. Server Responses - Message Status ......................... 57
+7.4.1. EXPUNGE Response .......................................... 57
+7.4.2. FETCH Response ............................................ 58
+7.5. Server Responses - Command Continuation Request ........... 63
+8. Sample IMAP4rev1 connection ............................... 63
+9. Formal Syntax ............................................. 64
+10. Author's Note ............................................. 74
+11. Security Considerations ................................... 74
+12. Author's Address .......................................... 75
+Appendices ........................................................ 76
+A. References ................................................ 76
+B. Changes from RFC 1730 ..................................... 77
+C. Key Word Index ............................................ 79
+
+
+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
+
+ In examples, "C:" and "S:" indicate lines sent by the client and
+ server respectively.
+
+ The following terms are used in this document to signify the
+ requirements of this specification.
+
+ 1) MUST, or the adjective REQUIRED, means that the definition is
+ an absolute requirement of the specification.
+
+ 2) MUST NOT that the definition is an absolute prohibition of the
+ specification.
+
+
+
+
+Crispin Standards Track [Page 4]
+
+RFC 2060 IMAP4rev1 December 1996
+
+
+ 3) SHOULD means that there may exist valid reasons in particular
+ circumstances to ignore a particular item, but the full
+ implications MUST be understood and carefully weighed before
+ choosing a different course.
+
+ 4) SHOULD NOT means that there may exist valid reasons in
+ particular circumstances when the particular behavior is
+ acceptable or even useful, but the full implications SHOULD be
+ understood and the case carefully weighed before implementing
+ any behavior described with this label.
+
+ 5) MAY, or the adjective OPTIONAL, means that an item is truly
+ optional. One vendor may choose to include the item because a
+ particular marketplace requires it or because the vendor feels
+ that it enhances the product while another vendor may omit the
+ same item. An implementation which does not include a
+ particular option MUST be prepared to interoperate with another
+ implementation which does include the option.
+
+ "Can" is used instead of "may" when referring to a possible
+ circumstance or situation, as opposed to an optional facility of
+ the protocol.
+
+ "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.
+
+2. Protocol Overview
+
+2.1. Link Level
+
+ The IMAP4rev1 protocol assumes a reliable data stream such as
+ provided by TCP. When TCP is used, an IMAP4rev1 server listens on
+ port 143.
+
+
+
+
+Crispin Standards Track [Page 5]
+
+RFC 2060 IMAP4rev1 December 1996
+
+
+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.
+
+ There are two cases in which a line from the client does not
+ represent a complete command. In one case, a command argument is
+ quoted with an octet count (see the description of literal in String
+ under Data Formats); in the other case, the command arguments require
+ server feedback (see the AUTHENTICATE command). In either case, the
+ server sends a command continuation request response if it is ready
+ for the octets (if appropriate) and the remainder of the command.
+ This response is prefixed with the token "+".
+
+ Note: If, instead, the server detected an error in the command, it
+ sends a BAD completion response with tag matching the command (as
+ described below) to reject the command and prevent the client from
+ sending any more of the command.
+
+ It is also possible for the server to send a completion response
+ for some other command (if multiple commands are in progress), or
+ untagged data. In either case, the command continuation request
+ is still pending; the client takes the appropriate action for the
+ response, and reads another response from the server. 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.
+
+
+
+
+
+Crispin Standards Track [Page 6]
+
+RFC 2060 IMAP4rev1 December 1996
+
+
+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 protocol error such as
+ unrecognized command or command syntax error).
+
+ 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 may 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 and 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
+
+
+
+Crispin Standards Track [Page 7]
+
+RFC 2060 IMAP4rev1 December 1996
+
+
+ that is permanently guaranteed not to refer to any other message in
+ the mailbox. 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. Unique identifiers also persist across
+ sessions. This permits a client to resynchronize its state from a
+ previous session with the server (e.g. disconnected or offline access
+ clients); this is discussed further in [IMAP-DISC].
+
+ Associated with every mailbox is a unique identifier validity value,
+ which is sent in an UIDVALIDITY response code in an OK untagged
+ response at mailbox selection time. If unique identifiers from an
+ earlier session fail to persist to this session, the unique
+ identifier validity value MUST be greater than the one used in the
+ earlier session.
+
+ Note: 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 identifers are no
+ longer strictly ascending as a result of the re-ordering. Another
+ instance in which unique identifiers are regenerated is if the
+ message store has no mechanism to store unique identifiers.
+ Although this specification recognizes that this may be
+ unavoidable in certain server environments, it STRONGLY ENCOURAGES
+ message store implementation techniques that avoid this problem.
+
+ Another cause of non-persistance is if the mailbox is deleted and
+ a new mailbox with the same name is created at a later date, Since
+ the name is the same, a client may not know that this is a new
+ mailbox unless the unique identifier validity is different. A
+ good value to use for the unique identifier validity value 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.
+
+ The unique identifier of a message MUST NOT change during the
+ session, and SHOULD NOT change between sessions. However, if it is
+ not possible to preserve the unique identifier of a message in a
+ subsequent session, each subsequent session MUST have a new unique
+ identifier validity value that is larger than any that was used
+ previously.
+
+
+
+
+Crispin Standards Track [Page 8]
+
+RFC 2060 IMAP4rev1 December 1996
+
+
+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. 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 "EXISTS 11" 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.
+
+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 may 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).
+
+
+
+
+
+Crispin Standards Track [Page 9]
+
+RFC 2060 IMAP4rev1 December 1996
+
+
+ \Recent Message is "recently" arrived in this mailbox. This
+ session is the first session to have been notified
+ about this message; 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-arrives 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).
+
+ A flag may 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, 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 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-822] 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.
+
+
+
+
+
+
+
+Crispin Standards Track [Page 10]
+
+RFC 2060 IMAP4rev1 December 1996
+
+
+2.3.4. [RFC-822] Size Message Attribute
+
+ The number of octets in the message, as expressed in [RFC-822]
+ format.
+
+2.3.5. Envelope Structure Message Attribute
+
+ A parsed representation of the [RFC-822] envelope information (not to
+ be confused with an [SMTP] envelope) of the message.
+
+2.3.6. Body Structure Message Attribute
+
+ A parsed representation of the [MIME-IMB] body structure information
+ of the message.
+
+2.4. Message Texts
+
+ In addition to being able to fetch the full [RFC-822] text of a
+ message, IMAP4rev1 permits the fetching of portions of the full
+ message text. Specifically, it is possible to fetch the [RFC-822]
+ message header, [RFC-822] message body, a [MIME-IMB] body part, or a
+ [MIME-IMB] header.
+
+3. State and Flow Diagram
+
+ An IMAP4rev1 server is in one of four states. Most commands are
+ valid in only certain states. It is a protocol error for the client
+ to attempt a command while the command is in an inappropriate state.
+ In this case, a server will respond with a BAD or NO (depending upon
+ server implementation) command completion result.
+
+3.1. Non-Authenticated State
+
+ In non-authenticated state, the 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 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, or after an error in selecting a mailbox.
+
+
+
+
+
+
+Crispin Standards Track [Page 11]
+
+RFC 2060 IMAP4rev1 December 1996
+
+
+3.3. Selected State
+
+ In selected state, a mailbox has been selected to access. This state
+ is entered when a mailbox has been successfully selected.
+
+3.4. Logout State
+
+ In logout state, the connection is being terminated, and the server
+ will close the connection. This state can be entered as a result of
+ a client request or by unilateral server decision.
+
+ +--------------------------------------+
+ |initial connection and server greeting|
+ +--------------------------------------+
+ || (1) || (2) || (3)
+ VV || ||
+ +-----------------+ || ||
+ |non-authenticated| || ||
+ +-----------------+ || ||
+ || (7) || (4) || ||
+ || VV VV ||
+ || +----------------+ ||
+ || | authenticated |<=++ ||
+ || +----------------+ || ||
+ || || (7) || (5) || (6) ||
+ || || VV || ||
+ || || +--------+ || ||
+ || || |selected|==++ ||
+ || || +--------+ ||
+ || || || (7) ||
+ VV VV VV VV
+ +--------------------------------------+
+ | logout and close connection |
+ +--------------------------------------+
+
+ (1) connection without pre-authentication (OK greeting)
+ (2) pre-authenticated connection (PREAUTH greeting)
+ (3) rejected connection (BYE greeting)
+ (4) successful LOGIN or AUTHENTICATE command
+ (5) successful SELECT or EXAMINE command
+ (6) CLOSE command, or failed SELECT or EXAMINE command
+ (7) LOGOUT command, server shutdown, or connection closed
+
+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.
+
+
+
+Crispin Standards Track [Page 12]
+
+RFC 2060 IMAP4rev1 December 1996
+
+
+4.1. Atom
+
+ An atom consists of one or more non-special characters.
+
+4.2. Number
+
+ A number consists of one or more digit characters, and represents a
+ numeric value.
+
+4.3. String
+
+ A string is in one of two forms: literal and quoted string. The
+ literal form is the general form of string. The quoted string form
+ is an alternative that avoids the overhead of processing a literal at
+ the cost of limitations of characters that can be used in a quoted
+ string.
+
+ A literal is a sequence of zero or more octets (including CR and LF),
+ prefix-quoted with an octet count in the form of an open brace ("{"),
+ the number of octets, close brace ("}"), and CRLF. In the case of
+ literals transmitted from server to client, the CRLF is immediately
+ followed by the octet data. In the case of literals transmitted from
+ client to server, the client MUST wait to receive a command
+ continuation request (described later in this document) before
+ sending the octet data (and the remainder of the command).
+
+ A quoted string is a sequence of zero or more 7-bit characters,
+ excluding CR and LF, with double quote (<">) characters at each end.
+
+ The empty string is 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.
+
+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.
+
+
+
+
+
+
+
+
+
+Crispin Standards Track [Page 13]
+
+RFC 2060 IMAP4rev1 December 1996
+
+
+ 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 atom "NIL" represents the non-existence of a particular
+ data item that is represented as a string or parenthesized list, as
+ distinct from the empty string "" or the empty parenthesized list ().
+
+5. Operational Considerations
+
+5.1. Mailbox Naming
+
+ The interpretation of mailbox names is implementation-dependent.
+ However, the case-insensitive mailbox name INBOX is a special name
+ reserved to mean "the primary mailbox for this user on this server".
+
+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.
+
+
+
+
+
+
+
+Crispin Standards Track [Page 14]
+
+RFC 2060 IMAP4rev1 December 1996
+
+
+ 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 an mailbox name of
+ "#news.comp.mail.misc", and the name "comp.mail.misc" could refer
+ to a different object (e.g. a user's private mailbox).
+
+5.1.3. Mailbox International Naming Convention
+
+ By convention, international mailbox names are specified using a
+ modified version of the UTF-7 encoding described in [UTF-7]. 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 chararacters can be
+ represented in encoded form.
+
+ 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, 0x7f-0xff, and all
+ Unicode 16-bit octets) 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.
+
+ "&" is used to shift to modified BASE64 and "-" to shift back to US-
+ ASCII. All names start in US-ASCII, and MUST end in US-ASCII (that
+ is, a name that ends with a Unicode 16-bit octet MUST end with a "-
+ ").
+
+
+
+
+
+Crispin Standards Track [Page 15]
+
+RFC 2060 IMAP4rev1 December 1996
+
+
+ For example, here is a mailbox name which mixes English, Japanese,
+ and Chinese text: ~peter/mail/&ZeVnLIqe-/&U,BTFw-
+
+5.2. Mailbox Size and Message Status Updates
+
+ At any time, a server can send data that the client did not request.
+ Sometimes, such behavior is REQUIRED. For example, agents other than
+ the server MAY add messages to the mailbox (e.g. new mail delivery),
+ change the flags of message in the mailbox (e.g. simultaneous access
+ to the same mailbox by multiple agents), or even remove messages from
+ the mailbox. A server MUST send mailbox size updates automatically
+ if a mailbox size change is observed during the processing of a
+ command. A server SHOULD send message flag updates automatically,
+ without requiring the client to request such updates explicitly.
+ Special rules exist for server notification of a client about the
+ removal of messages to prevent synchronization errors; see the
+ description of the EXPUNGE response for more detail.
+
+ 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
+ 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.
+
+5.4. Autologout Timer
+
+ If a server has an inactivity autologout timer, that timer MUST be of
+ at least 30 minutes' duration. The receipt of ANY command from the
+ client during that interval SHOULD suffice to reset the autologout
+ timer.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin Standards Track [Page 16]
+
+RFC 2060 IMAP4rev1 December 1996
+
+
+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; for example, 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 a response before sending a command with message
+ sequence numbers.
+
+ 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
+
+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
+
+
+
+Crispin Standards Track [Page 17]
+
+RFC 2060 IMAP4rev1 December 1996
+
+
+ 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.
+
+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. This listing of
+ capabilities is not dependent upon connection state or user. It
+ is therefore not necessary to issue a CAPABILITY command more than
+ once in a connection.
+
+
+
+
+
+
+
+
+
+Crispin Standards Track [Page 18]
+
+RFC 2060 IMAP4rev1 December 1996
+
+
+ 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.
+
+ See the section entitled "Client Commands -
+ Experimental/Expansion" for information about the form of site or
+ implementation-specific capabilities.
+
+ Example: C: abcd CAPABILITY
+ S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4
+ S: abcd 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. 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 19]
+
+RFC 2060 IMAP4rev1 December 1996
+
+
+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 - Non-Authenticated State
+
+ In non-authenticated state, the AUTHENTICATE or LOGIN command
+ establishes authentication and enter authenticated state. The
+ AUTHENTICATE command provides a general mechanism for a variety of
+ authentication techniques, whereas the LOGIN command uses the
+ traditional user name and plaintext password pair.
+
+ Server implementations MAY allow non-authenticated access to certain
+ mailboxes. The convention is to use a LOGIN command with the userid
+ "anonymous". A password is REQUIRED. It is implementation-dependent
+ what requirements, if any, are placed on the password and what access
+ restrictions are placed on anonymous users.
+
+ Once authenticated (including as anonymous), it is not possible to
+ re-enter non-authenticated state.
+
+ In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
+ the following commands are valid in non-authenticated state:
+ AUTHENTICATE and LOGIN.
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin Standards Track [Page 20]
+
+RFC 2060 IMAP4rev1 December 1996
+
+
+6.2.1. 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 an authentication mechanism,
+ such as described in [IMAP-AUTH], to the server. If the server
+ supports the requested authentication mechanism, it performs an
+ authentication protocol exchange to authenticate and identify the
+ client. It MAY also negotiate an OPTIONAL protection mechanism
+ for subsequent protocol interactions. If the requested
+ authentication mechanism is not supported, the server SHOULD
+ reject the AUTHENTICATE command by sending a tagged NO response.
+
+ The authentication protocol exchange consists of a series of
+ server challenges and client answers that are specific to the
+ authentication mechanism. A server challenge consists of a
+ command continuation request response with the "+" token followed
+ by a BASE64 encoded string. The client answer consists of a line
+ consisting of a BASE64 encoded string. If the client wishes to
+ cancel an authentication exchange, it issues a line with a single
+ "*". If the server receives such an answer, it MUST reject the
+ AUTHENTICATE command by sending a tagged BAD response.
+
+ A protection mechanism provides integrity and privacy protection
+ to the connection. If a protection mechanism is negotiated, it is
+ applied to all subsequent data sent over the connection. The
+ protection mechanism takes effect immediately following the CRLF
+ that concludes the authentication exchange for the client, and the
+ CRLF of the tagged OK response for the server. Once the
+ protection mechanism is in effect, the stream of command and
+ response octets is processed into buffers of ciphertext. Each
+ buffer is transferred over the connection as a stream of octets
+ prepended with a four octet field in network byte order that
+ represents the length of the following data. The maximum
+ ciphertext buffer length is defined by the protection mechanism.
+
+ Authentication mechanisms are OPTIONAL. Protection mechanisms are
+ also OPTIONAL; an authentication mechanism MAY be implemented
+ without any protection mechanism. If an AUTHENTICATE command
+ fails with a NO response, the client MAY try another
+
+
+
+Crispin Standards Track [Page 21]
+
+RFC 2060 IMAP4rev1 December 1996
+
+
+ authentication mechanism by issuing another AUTHENTICATE command,
+ or MAY attempt to authenticate by using the LOGIN command. In
+ other words, the client MAY request authentication types in
+ decreasing order of preference, with the LOGIN command as a last
+ resort.
+
+ Example: S: * OK KerberosV4 IMAP4rev1 Server
+ C: A001 AUTHENTICATE KERBEROS_V4
+ S: + AmFYig==
+ C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
+ +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
+ WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
+ S: + or//EoAADZI=
+ C: DiAF5A4gA+oOIALuBkAAmw==
+ S: A001 OK Kerberos V4 authentication successful
+
+ Note: the line breaks in the first client answer are for editorial
+ clarity and are not in real authenticators.
+
+6.2.2. LOGIN Command
+
+ Arguments: user name
+ password
+
+ 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.
+
+ Example: C: a001 LOGIN SMITH SESAME
+ S: a001 OK LOGIN completed
+
+6.3. Client Commands - Authenticated State
+
+ In authenticated state, commands that manipulate mailboxes as atomic
+ entities are permitted. Of these commands, the SELECT and EXAMINE
+ commands will select a mailbox for access and enter selected state.
+
+ In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
+ the following commands are valid in authenticated state: SELECT,
+ EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB,
+ STATUS, and APPEND.
+
+
+
+
+
+Crispin Standards Track [Page 22]
+
+RFC 2060 IMAP4rev1 December 1996
+
+
+6.3.1. SELECT Command
+
+ Arguments: mailbox name
+
+ Responses: REQUIRED untagged responses: FLAGS, EXISTS, RECENT
+ OPTIONAL OK untagged responses: UNSEEN, PERMANENTFLAGS
+
+ Result: OK - select completed, now in selected state
+ NO - select failure, now in authenticated state: no
+ such mailbox, can't access mailbox
+ BAD - command unknown or arguments invalid
+
+ The SELECT command selects a mailbox so that messages in the
+ mailbox can be accessed. Before returning an OK to the client,
+ the server MUST send the following untagged data to the client:
+
+ FLAGS Defined flags in the mailbox. 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 [UIDVALIDITY <n>]
+ The unique identifier validity value. See the
+ description of the UID command for more detail.
+
+ to define the initial state of the mailbox at the client.
+
+ The server SHOULD also send an UNSEEN response code in an OK
+ untagged response, indicating the message sequence number of the
+ first unseen message in the mailbox.
+
+ If the client can not change the permanent state of one or more of
+ the flags listed in the FLAGS untagged response, the server SHOULD
+ send a PERMANENTFLAGS response code in an OK untagged response,
+ listing the flags that the client can change permanently.
+
+ 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.
+
+
+
+
+Crispin Standards Track [Page 23]
+
+RFC 2060 IMAP4rev1 December 1996
+
+
+ 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: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
+ S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
+ S: A142 OK [READ-WRITE] SELECT completed
+
+6.3.2. EXAMINE Command
+
+ Arguments: mailbox name
+
+ Responses: REQUIRED untagged responses: FLAGS, EXISTS, RECENT
+ OPTIONAL OK untagged responses: UNSEEN, PERMANENTFLAGS
+
+ Result: OK - examine completed, now in selected state
+ NO - examine failure, now in authenticated state: no
+ such mailbox, can't access mailbox
+ BAD - command unknown or arguments invalid
+
+ The EXAMINE command is identical to SELECT and returns the same
+ output; however, the selected mailbox is identified as read-only.
+ No changes to the permanent state of the mailbox, including
+ per-user state, are permitted.
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin Standards Track [Page 24]
+
+RFC 2060 IMAP4rev1 December 1996
+
+
+ The text of the tagged OK response to the EXAMINE command MUST
+ begin with the "[READ-ONLY]" response code.
+
+ Example: C: A932 EXAMINE blurdybloop
+ S: * 17 EXISTS
+ S: * 2 RECENT
+ S: * OK [UNSEEN 8] Message 8 is first unseen
+ S: * OK [UIDVALIDITY 3857529045] UIDs valid
+ S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
+ S: * OK [PERMANENTFLAGS ()] No permanent flags permitted
+ S: A932 OK [READ-ONLY] EXAMINE completed
+
+6.3.3. CREATE Command
+
+ Arguments: mailbox name
+
+ 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.
+
+ 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
+ it.
+
+ 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 complete successfully.
+ 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.
+
+
+
+Crispin Standards Track [Page 25]
+
+RFC 2060 IMAP4rev1 December 1996
+
+
+ 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
+
+ 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.
+
+
+
+
+
+
+Crispin Standards Track [Page 26]
+
+RFC 2060 IMAP4rev1 December 1996
+
+
+ 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
+
+
+ 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
+
+
+
+Crispin Standards Track [Page 27]
+
+RFC 2060 IMAP4rev1 December 1996
+
+
+ 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".
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin Standards Track [Page 28]
+
+RFC 2060 IMAP4rev1 December 1996
+
+
+ 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
+
+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 some server sites may 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
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin Standards Track [Page 29]
+
+RFC 2060 IMAP4rev1 December 1996
+
+
+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
+
+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 \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 a context in which the mailbox
+ name is interpreted in an implementation-defined manner.
+
+
+
+
+Crispin Standards Track [Page 30]
+
+RFC 2060 IMAP4rev1 December 1996
+
+
+ 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 null if
+ the reference is non-rooted or is null. In all cases, the
+ hierarchy delimiter is returned. This permits a client to get the
+ hierarchy delimiter even when no mailboxes by that name currently
+ exist.
+
+ The reference and mailbox name arguments are interpreted, in an
+ implementation-dependent fashion, into a canonical form that
+ represents an unambiguous left-to-right hierarchy. The returned
+ mailbox names will be in the interpreted form.
+
+ Any part of the reference argument that is included in the
+ interpreted form SHOULD prefix the interpreted form. It SHOULD
+ also be in the same form as the reference name argument. This
+ rule permits the client to determine if the returned mailbox name
+ is in the context of the reference argument, or if something about
+ the mailbox argument overrode the reference argument. Without
+ this rule, the client would have to have knowledge of the server's
+ naming semantics including what characters are "breakouts" that
+ override a naming context.
+
+ 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).
+
+
+
+Crispin Standards Track [Page 31]
+
+RFC 2060 IMAP4rev1 December 1996
+
+
+ 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.
+
+ 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.
+
+ A server MAY validate the subscribed names to see if they still
+ exist. If a name does not exist, it SHOULD be flagged with the
+ \Noselect attribute in the LSUB response. The server MUST NOT
+
+
+
+Crispin Standards Track [Page 32]
+
+RFC 2060 IMAP4rev1 December 1996
+
+
+ unilaterally remove an existing mailbox name from the subscription
+ list even if a mailbox by that name no longer exists.
+
+ Example: C: A002 LSUB "#news." "comp.mail.*"
+ S: * LSUB () "." #news.comp.mail.mime
+ S: * LSUB () "." #news.comp.mail.misc
+ S: A002 OK LSUB completed
+
+6.3.10. 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. 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.
+
+ 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 UID value that will be assigned to a new
+ message in the mailbox. It is guaranteed that this
+ value will not change unless new messages are added
+ to the mailbox; and that it will change when new
+ messages are added even if those new messages are
+ subsequently expunged.
+
+
+
+Crispin Standards Track [Page 33]
+
+RFC 2060 IMAP4rev1 December 1996
+
+
+ UIDVALIDITY The unique identifier validity value of the
+ mailbox.
+
+ 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
+
+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-822] message. 8-bit characters
+ are permitted in the message. A server implementation that is
+ unable to preserve 8-bit data properly MUST be able to reversibly
+ convert 8-bit APPEND data to 7-bit using a [MIME-IMB] content
+ transfer encoding.
+
+ Note: There MAY be exceptions, e.g. draft messages, in which
+ required [RFC-822] 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 empty by default.
+
+ 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.
+
+
+
+
+
+
+Crispin Standards Track [Page 34]
+
+RFC 2060 IMAP4rev1 December 1996
+
+
+ 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.
+
+ If the mailbox is currently selected, the normal new mail 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}
+ C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
+ C: From: Fred Foobar <fo...@Blurdybloop.COM>
+ C: Subject: afternoon meeting
+ C: To: mooch@owatagu.siam.edu
+ C: Message-Id: <B2...@Blurdybloop.COM>
+ C: MIME-Version: 1.0
+ C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
+ C:
+ C: Hello Joe, do you think we can meet at 3:30 tomorrow?
+ C:
+ S: A003 OK APPEND completed
+
+ Note: the APPEND command is not used for message delivery, because
+ it does not provide a mechanism to transfer [SMTP] envelope
+ information.
+
+6.4. Client Commands - Selected State
+
+ In selected state, commands that manipulate messages in a mailbox are
+ permitted.
+
+ In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
+ and the authenticated state commands (SELECT, EXAMINE, CREATE,
+ DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS, and
+ APPEND), the following commands are valid in the selected state:
+ CHECK, CLOSE, EXPUNGE, SEARCH, FETCH, STORE, COPY, and UID.
+
+
+
+
+
+
+Crispin Standards Track [Page 35]
+
+RFC 2060 IMAP4rev1 December 1996
+
+
+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
+ disk) that is not normally executed as part of each command. A
+ checkpoint MAY take a non-instantaneous amount of real time to
+ complete. If a server implementation has no such housekeeping
+ considerations, CHECK is equivalent to NOOP.
+
+ There is no guarantee that an EXISTS untagged response will happen
+ as a result of CHECK. NOOP, not CHECK, SHOULD be used for new
+ mail polling.
+
+ Example: C: FXXZ CHECK
+ S: FXXZ OK CHECK Completed
+
+6.4.2. CLOSE Command
+
+ Arguments: none
+
+ Responses: no specific responses for this command
+
+ Result: OK - close completed, now in authenticated state
+ NO - close failure: no mailbox selected
+ BAD - command unknown or arguments invalid
+
+ The CLOSE command permanently removes from the currently selected
+ mailbox all messages that have the \Deleted flag set, and returns
+ to authenticated state from selected state. No untagged EXPUNGE
+ responses are sent.
+
+ No messages are removed, and no error is given, if the mailbox is
+ selected by an EXAMINE command or is otherwise selected read-only.
+
+ Even 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
+
+
+
+Crispin Standards Track [Page 36]
+
+RFC 2060 IMAP4rev1 December 1996
+
+
+ sequence is considerably faster than an EXPUNGE-LOGOUT or
+ EXPUNGE-SELECT because no untagged EXPUNGE responses (which the
+ client would probably ignore) are sent.
+
+ Example: C: A341 CLOSE
+ S: A341 OK CLOSE completed
+
+6.4.3. EXPUNGE Command
+
+ Arguments: none
+
+ 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 from the currently
+ selected mailbox all messages that have the \Deleted flag set.
+ Before returning an OK to the client, an untagged EXPUNGE response
+ is sent for each message that is removed.
+
+ Example: C: A202 EXPUNGE
+ S: * 3 EXPUNGE
+ S: * 3 EXPUNGE
+ S: * 5 EXPUNGE
+ S: * 8 EXPUNGE
+ S: A202 OK EXPUNGE completed
+
+ Note: in this example, messages 3, 4, 7, and 11 had the
+ \Deleted flag set. See the description of the EXPUNGE
+ response for further explanation.
+
+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
+
+
+
+
+
+
+Crispin Standards Track [Page 37]
+
+RFC 2060 IMAP4rev1 December 1996
+
+
+ The SEARCH command searches the mailbox for messages that match
+ the given searching criteria. Searching criteria consist of one
+ or more search keys. The untagged SEARCH response from the server
+ contains a listing of message sequence numbers corresponding to
+ those messages that match the searching criteria.
+
+ When multiple keys are specified, the result is the intersection
+ (AND function) of all the messages that match those keys. For
+ example, the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers
+ to all deleted messages from Smith that were placed in the mailbox
+ since February 1, 1994. A search key 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-822]/[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).
+
+ 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.
+
+ <message set> Messages with message sequence numbers
+ corresponding to the specified message sequence
+ number set
+
+ ALL All messages in the mailbox; the default initial
+ key for ANDing.
+
+ ANSWERED Messages with the \Answered flag set.
+
+ BCC <string> Messages that contain the specified string in the
+ envelope structure's BCC field.
+
+
+
+
+Crispin Standards Track [Page 38]
+
[... 2467 lines stripped ...]
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org