diff options
| -rw-r--r-- | .gitignore | 6 | ||||
| -rw-r--r-- | .includepath | bin | 714 -> 714 bytes | |||
| -rw-r--r-- | .project | bin | 365 -> 365 bytes | |||
| -rw-r--r-- | previousAttempts/RFC/rfc2060.txt | 4595 | ||||
| -rw-r--r-- | previousAttempts/RFC/rfc2177.txt | 227 | ||||
| -rw-r--r-- | previousAttempts/java/ArchivableFolder.java | 69 | ||||
| -rw-r--r-- | previousAttempts/java/Archives.java | 85 | ||||
| -rw-r--r-- | previousAttempts/java/imapList.java | 95 | ||||
| -rw-r--r-- | previousAttempts/jython/imapArchive.py | 205 | ||||
| -rw-r--r-- | previousAttempts/jython/purgeObsolete.py | 151 | ||||
| -rw-r--r-- | previousAttempts/jython/purgeObsoleteTest.py | 43 | ||||
| -rw-r--r-- | previousAttempts/jython/pydoctest.py | 63 | ||||
| -rw-r--r-- | previousAttempts/perl/archiveIMAP.pl | bin | 0 -> 4986 bytes | |||
| -rw-r--r-- | previousAttempts/perl/expireIMAP.pl | bin | 0 -> 862 bytes | |||
| -rw-r--r-- | previousAttempts/perl/listFolders.pl | 23 | ||||
| -rw-r--r-- | previousAttempts/perl/playWithImap.pl | bin | 0 -> 2203 bytes |
16 files changed, 5557 insertions, 5 deletions
@@ -1,5 +1 @@ -*~ -java/ -jython/ -rfc2060.txt -rfc2177.txt +.ÆððÙ~{»þ$¿vØY[x&¬˜ò²-Ïu¶ëOLšš)pøÙ™JJ‡
\ No newline at end of file diff --git a/.includepath b/.includepath Binary files differBinary files differindex b0aa2aa..79c8d1c 100644 --- a/.includepath +++ b/.includepath diff --git a/previousAttempts/RFC/rfc2060.txt b/previousAttempts/RFC/rfc2060.txt new file mode 100644 index 0000000..cf46159 --- /dev/null +++ b/previousAttempts/RFC/rfc2060.txt @@ -0,0 +1,4595 @@ + + + + + + +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 <foobar@Blurdybloop.COM> + C: Subject: afternoon meeting + C: To: mooch@owatagu.siam.edu + C: Message-Id: <B27397-0100000@Blurdybloop.COM> + C: MIME-Version: 1.0 + C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII + C: + C: Hello Joe, do you think we can meet at 3:30 tomorrow? + C: + S: A003 OK APPEND completed + + Note: the APPEND command is not used for message delivery, because + it does not provide a mechanism to transfer [SMTP] envelope + information. + +6.4. Client Commands - Selected State + + In selected state, commands that manipulate messages in a mailbox are + permitted. + + In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), + and the authenticated state commands (SELECT, EXAMINE, CREATE, + DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, 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] + +RFC 2060 IMAP4rev1 December 1996 + + + BEFORE <date> Messages whose internal date is earlier than the + specified date. + + BODY <string> Messages that contain the specified string in the + body of the message. + + CC <string> Messages that contain the specified string in the + envelope structure's CC field. + + DELETED Messages with the \Deleted flag set. + + DRAFT Messages with the \Draft flag set. + + FLAGGED Messages with the \Flagged flag set. + + FROM <string> Messages that contain the specified string in the + envelope structure's FROM field. + + HEADER <field-name> <string> + Messages that have a header with the specified + field-name (as defined in [RFC-822]) and that + contains the specified string in the [RFC-822] + field-body. + + KEYWORD <flag> Messages with the specified keyword set. + + LARGER <n> Messages with an [RFC-822] 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)". + + NOT <search-key> + Messages that do not match the specified search + key. + + OLD Messages that do not have the \Recent flag set. + This is functionally equivalent to "NOT RECENT" (as + opposed to "NOT NEW"). + + ON <date> Messages whose internal date is within the + specified date. + + OR <search-key1> <search-key2> + Messages that match either search key. + + RECENT Messages that have the \Recent flag set. + + + +Crispin Standards Track [Page 39] + +RFC 2060 IMAP4rev1 December 1996 + + + SEEN Messages that have the \Seen flag set. + + SENTBEFORE <date> + Messages whose [RFC-822] Date: header is earlier + than the specified date. + + SENTON <date> Messages whose [RFC-822] Date: header is within the + specified date. + + SENTSINCE <date> + Messages whose [RFC-822] Date: header is within or + later than the specified date. + + SINCE <date> Messages whose internal date is within or later + than the specified date. + + SMALLER <n> Messages with an [RFC-822] size smaller than the + specified number of octets. + + SUBJECT <string> + Messages that contain the specified string in the + envelope structure's SUBJECT field. + + TEXT <string> Messages that contain the specified string in the + header or body of the message. + + TO <string> Messages that contain the specified string in the + envelope structure's TO field. + + UID <message set> + Messages with unique identifiers corresponding to + the specified unique identifier set. + + UNANSWERED Messages that do not have the \Answered flag set. + + UNDELETED Messages that do not have the \Deleted flag set. + + UNDRAFT Messages that do not have the \Draft flag set. + + UNFLAGGED Messages that do not have the \Flagged flag set. + + UNKEYWORD <flag> + Messages that do not have the specified keyword + set. + + UNSEEN Messages that do not have the \Seen flag set. + + + + + +Crispin Standards Track [Page 40] + +RFC 2060 IMAP4rev1 December 1996 + + + Example: C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith" + S: * SEARCH 2 84 882 + S: A282 OK SEARCH completed + +6.4.5. FETCH Command + + Arguments: message set + message data item names + + 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. + + The currently defined data items that can be fetched are: + + ALL Macro equivalent to: (FLAGS INTERNALDATE + RFC822.SIZE ENVELOPE) + + BODY Non-extensible form of BODYSTRUCTURE. + + BODY[<section>]<<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. + + + + + + +Crispin Standards Track [Page 41] + +RFC 2060 IMAP4rev1 December 1996 + + + 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-822] 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-822]) names, and + return a 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. In all + cases, the delimiting blank line between the header + and the body is always included. + + 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-822] header. + + + + + + + + + + + + + + + + + + +Crispin Standards Track [Page 42] + +RFC 2060 IMAP4rev1 December 1996 + + + Here is an example of a complex message + with some of its part specifiers: + + HEADER ([RFC-822] header of the message) + TEXT MULTIPART/MIXED + 1 TEXT/PLAIN + 2 APPLICATION/OCTET-STREAM + 3 MESSAGE/RFC822 + 3.HEADER ([RFC-822] header of the message) + 3.TEXT ([RFC-822] text body of the message) + 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-822] header of the message) + 4.2.TEXT ([RFC-822] text body of the message) + 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. + + 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. + + + + + +Crispin Standards Track [Page 43] + +RFC 2060 IMAP4rev1 December 1996 + + + 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-822] header and + [MIME-IMB] headers. + + ENVELOPE The envelope structure of the message. This is + computed by the server by parsing the [RFC-822] + header into the component parts, defaulting various + fields as necessary. + + FAST Macro equivalent to: (FLAGS INTERNALDATE + RFC822.SIZE) + + FLAGS The flags that are set for this message. + + FULL Macro equivalent to: (FLAGS INTERNALDATE + RFC822.SIZE ENVELOPE BODY) + + INTERNALDATE The 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-822] size of the message. + + 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. + + + + + + + + +Crispin Standards Track [Page 44] + +RFC 2060 IMAP4rev1 December 1996 + + + 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: message 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. + + The currently defined data items that can be stored are: + + FLAGS <flag list> + Replace the flags for the message with the + argument. The new value of the flags are returned + as if a FETCH of those flags was done. + + FLAGS.SILENT <flag list> + Equivalent to FLAGS, but without returning a new + value. + + +FLAGS <flag list> + Add the argument to the flags for the message. The + new value of the flags are returned as if a FETCH + of those flags was done. + + + + + +Crispin Standards Track [Page 45] + +RFC 2060 IMAP4rev1 December 1996 + + + +FLAGS.SILENT <flag list> + Equivalent to +FLAGS, but without returning a new + value. + + -FLAGS <flag list> + Remove the argument from the flags for the message. + The new value of the flags are returned as if a + FETCH of those flags was done. + + -FLAGS.SILENT <flag list> + Equivalent to -FLAGS, but without returning a new + value. + + Example: C: A003 STORE 2:4 +FLAGS (\Deleted) + S: * 2 FETCH FLAGS (\Deleted \Seen) + S: * 3 FETCH FLAGS (\Deleted) + S: * 4 FETCH FLAGS (\Deleted \Flagged \Seen) + S: A003 OK STORE completed + +6.4.7. COPY Command + + Arguments: message 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 + + 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 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. + + + + + + + + + +Crispin Standards Track [Page 46] + +RFC 2060 IMAP4rev1 December 1996 + + + 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 message set argument are unique identifiers instead of message + sequence numbers. + + In the second form, the UID command takes a SEARCH command with + SEARCH command arguments. The interpretation of the arguments is + the same as with SEARCH; however, the numbers returned in a SEARCH + response for a UID SEARCH command are unique identifiers instead + of message sequence numbers. For example, the command UID SEARCH + 1:100 UID 443:557 returns the unique identifiers corresponding to + the intersection of the message sequence number set 1:100 and the + UID set 443:557. + + Message set ranges are permitted; however, there is no guarantee + that unique identifiers be contiguous. A non-existent unique + identifier within a message set range is ignored without any error + message generated. + + The number after the "*" in an untagged FETCH response is always a + message sequence number, not a unique identifier, even for a UID + command response. However, server implementations MUST implicitly + include the UID message data item as part of any FETCH response + caused by a UID command, regardless of whether a UID was specified + as a message data item to the FETCH. + + + + + + + +Crispin Standards Track [Page 47] + +RFC 2060 IMAP4rev1 December 1996 + + + 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 UID FETCH completed + +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 AUTH=KERBEROS_V4 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. + + + + + + +Crispin Standards Track [Page 48] + +RFC 2060 IMAP4rev1 December 1996 + + + 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 + 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 selected state. In 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 + may 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 + + + +Crispin Standards Track [Page 49] + +RFC 2060 IMAP4rev1 December 1996 + + + contains additional information or status codes for client software + beyond the OK/NO/BAD condition, and are defined when there is a + specific action that a client can take based upon the additional + information. + + The currently defined response codes are: + + ALERT The human-readable text contains a special alert + that MUST be presented to the user in a fashion + that calls the user's attention to the message. + + NEWNAME Followed by a mailbox name and a new mailbox name. + A SELECT or EXAMINE is failing because the target + mailbox name no longer exists because it was + renamed to the new mailbox name. This is a hint to + the client that the operation can succeed if the + SELECT or EXAMINE is reissued with the new mailbox + name. + + PARSE The human-readable text represents an error in + parsing the [RFC-822] 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 that 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 reject + it with a NO reply or store the state 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. + + 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. + + + + + + + +Crispin Standards Track [Page 50] + +RFC 2060 IMAP4rev1 December 1996 + + + 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. + + UIDVALIDITY Followed by a decimal number, indicates the unique + identifier validity value. + + 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 + 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. + + + +Crispin Standards Track [Page 51] + +RFC 2060 IMAP4rev1 December 1996 + + + 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. + + 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 and + 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 + + + + + + +Crispin Standards Track [Page 52] + +RFC 2060 IMAP4rev1 December 1996 + + + 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. + + 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. + + 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". + + A capability name which begins with "AUTH=" indicates that the + server supports that particular authentication mechanism. + + + + + + + +Crispin Standards Track [Page 53] + +RFC 2060 IMAP4rev1 December 1996 + + + 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 + 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. + + Example: S: * CAPABILITY IMAP4rev1 AUTH=KERBEROS_V4 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. + + If it is not feasible for the server to determine whether the + mailbox is "interesting" or not, or if the name is a \Noselect + name, the server SHOULD NOT send either \Marked or \Unmarked. + + + +Crispin Standards Track [Page 54] + +RFC 2060 IMAP4rev1 December 1996 + + + 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) + +7.2.5. SEARCH Response + + Contents: zero or more numbers + + + + + + + + + +Crispin Standards Track [Page 55] + +RFC 2060 IMAP4rev1 December 1996 + + + 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 trasnmitted 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 mail). + + The update from the EXISTS response MUST be recorded by the + client. + + Example: S: * 23 EXISTS + + + + + + + + + + +Crispin Standards Track [Page 56] + +RFC 2060 IMAP4rev1 December 1996 + + +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 + mail). + + 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). + + 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 + + + +Crispin Standards Track [Page 57] + +RFC 2060 IMAP4rev1 December 1996 + + + numbers to higher numbers, or from higher numbers to lower + numbers. For example, if the last 5 messages in a 9-message + mailbox are expunged; a "lower to higher" server will send five + untagged EXPUNGE responses for message sequence number 5, whereas + a "higher to lower server" will send successive untagged EXPUNGE + responses for message sequence numbers 9, 8, 7, 6, and 5. + + An EXPUNGE response MUST NOT be sent when no command is in + progress; nor while responding to a FETCH, STORE, or SEARCH + command. This rule is necessary to prevent a loss of + synchronization of message sequence numbers between client and + server. + + The update from the EXPUNGE response MUST be recorded by the + client. + + Example: S: * 44 EXPUNGE + +7.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. + + 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. + + 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 + + + +Crispin Standards Track [Page 58] + +RFC 2060 IMAP4rev1 December 1996 + + + 7-bit; 8-bit characters are not permitted in + headers. Note also that the blank line at the end + of the header is always included in header data. + + 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 nested + body. The second element of the parenthesized list + is the multipart subtype (mixed, digest, parallel, + alternative, etc.). + + For example, a two part message consisting of a + text and a BASE645-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 + + + +Crispin Standards Track [Page 59] + +RFC 2060 IMAP4rev1 December 1996 + + + "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. The disposition type and + attribute names will be defined in a future + standards-track revision to [DISPOSITION]. + + body language + A string or parenthesized list giving the body + language value as defined in [LANGUAGE-TAGS]. + + 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]. + + 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]. + + + +Crispin Standards Track [Page 60] + +RFC 2060 IMAP4rev1 December 1996 + + + 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]. + + 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]. + + Any following extension data are not yet defined in + this version of the protocol, and would be as + described above under multipart extension data. + + + + + +Crispin Standards Track [Page 61] + +RFC 2060 IMAP4rev1 December 1996 + + + ENVELOPE A parenthesized list that describes the envelope + structure of a message. This is computed by the + server by parsing the [RFC-822] header into the + component parts, defaulting various fields as + necessary. + + The fields of the envelope structure are in the + following order: date, subject, from, sender, + reply-to, to, cc, bcc, in-reply-to, and message-id. + The date, subject, in-reply-to, and message-id + fields are strings. The from, sender, reply-to, + to, cc, and bcc fields are parenthesized lists of + address structures. + + An address structure is a parenthesized list that + describes an electronic mail address. The fields + of an address structure are in the following order: + personal name, [SMTP] at-domain-list (source + route), mailbox name, and host name. + + [RFC-822] group syntax is indicated by a special + form of address structure in which the host name + field is NIL. If the mailbox name field is also + NIL, this is an end of group marker (semi-colon in + RFC 822 syntax). If the mailbox name field is + non-NIL, this is a start of group marker, and the + mailbox name field holds the group name phrase. + + Any field of an envelope or address structure that + is not applicable is presented as NIL. Note that + the server MUST default the reply-to and sender + fields from the from field; a client is not + expected to know to do this. + + 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.PEEK[HEADER]. + + RFC822.SIZE A number expressing the [RFC-822] size of the + message. + + RFC822.TEXT Equivalent to BODY[TEXT]. + + + +Crispin Standards Track [Page 62] + +RFC 2060 IMAP4rev1 December 1996 + + + 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 AUTHORIZATION command to transmit server + data to the client, and request additional client data. This + response is also used if an argument to any command is a literal. + + The client is not permitted to send the octets of the literal unless + the server indicates that it expects it. This permits the server to + process commands and reject errors on a line-by-line basis. The + remainder of the command, including the CRLF that terminates a + command, follows the octets of the literal. If there are any + additional command arguments the literal octets are followed by a + space and those arguments. + + Example: C: A001 LOGIN {11} + S: + Ready for additional command text + C: FRED FOOBAR {7} + S: + Ready for additional command text + C: fat man + S: A001 OK LOGIN completed + C: A044 BLURDYBLOOP {102856} + S: A044 BAD No such command as "BLURDYBLOOP" + +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 + + + +Crispin Standards Track [Page 63] + +RFC 2060 IMAP4rev1 December 1996 + + +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" "INFOODS.MIT.EDU")) NIL NIL + "<B27397-0100000@cac.washington.edu>") + BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028 92)) +S: a003 OK FETCH completed +C: a004 fetch 12 body[header] +S: * 12 FETCH (BODY[HEADER] {350} +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@INFOODS.MIT.EDU> +S: Message-Id: <B27397-0100000@cac.washington.edu> +S: MIME-Version: 1.0 +S: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII +S: +S: ) +S: a004 OK FETCH completed +C: a005 store 12 +flags \deleted +S: * 12 FETCH (FLAGS (\Seen \Deleted)) +S: a005 OK +FLAGS completed +C: a006 logout +S: * BYE IMAP4rev1 server terminating connection +S: a006 OK LOGOUT completed + +9. Formal Syntax + + The following syntax specification uses the augmented Backus-Naur + Form (BNF) notation as specified in [RFC-822] with one exception; the + delimiter used with the "#" construct is a single space (SPACE) and + not one or more commas. + + 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" could be + parsed as a flag_extension. Some, but not all, instances of this + rule are noted below. + + + + +Crispin Standards Track [Page 64] + +RFC 2060 IMAP4rev1 December 1996 + + + 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. + +address ::= "(" addr_name SPACE addr_adl SPACE addr_mailbox + SPACE addr_host ")" + +addr_adl ::= nstring + ;; Holds route from [RFC-822] route-addr if + ;; non-NIL + +addr_host ::= nstring + ;; NIL indicates [RFC-822] group syntax. + ;; Otherwise, holds [RFC-822] domain name + +addr_mailbox ::= nstring + ;; NIL indicates end of [RFC-822] group; if + ;; non-NIL and addr_host is NIL, holds + ;; [RFC-822] group name. + ;; Otherwise, holds [RFC-822] local-part + +addr_name ::= nstring + ;; Holds phrase from [RFC-822] mailbox if + ;; non-NIL + +alpha ::= "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" / + "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" / + "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" / + "Y" / "Z" / + "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / + "i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" / + "q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" / + "y" / "z" + ;; Case-sensitive + +append ::= "APPEND" SPACE mailbox [SPACE flag_list] + [SPACE date_time] SPACE literal + +astring ::= atom / string + +atom ::= 1*ATOM_CHAR + +ATOM_CHAR ::= <any CHAR except atom_specials> + +atom_specials ::= "(" / ")" / "{" / SPACE / CTL / list_wildcards / + quoted_specials + + + + +Crispin Standards Track [Page 65] + +RFC 2060 IMAP4rev1 December 1996 + + +authenticate ::= "AUTHENTICATE" SPACE auth_type *(CRLF base64) + +auth_type ::= atom + ;; Defined by [IMAP-AUTH] + +base64 ::= *(4base64_char) [base64_terminal] + +base64_char ::= alpha / digit / "+" / "/" + +base64_terminal ::= (2base64_char "==") / (3base64_char "=") + +body ::= "(" body_type_1part / body_type_mpart ")" + +body_extension ::= nstring / number / "(" 1#body_extension ")" + ;; Future expansion. Client implementations + ;; MUST accept body_extension fields. Server + ;; implementations MUST NOT generate + ;; body_extension fields except as defined by + ;; future standard or standards-track + ;; revisions of this specification. + +body_ext_1part ::= body_fld_md5 [SPACE body_fld_dsp + [SPACE body_fld_lang + [SPACE 1#body_extension]]] + ;; MUST NOT be returned on non-extensible + ;; "BODY" fetch + +body_ext_mpart ::= body_fld_param + [SPACE body_fld_dsp SPACE body_fld_lang + [SPACE 1#body_extension]] + ;; MUST NOT be returned on non-extensible + ;; "BODY" fetch + +body_fields ::= body_fld_param SPACE body_fld_id SPACE + body_fld_desc SPACE body_fld_enc SPACE + body_fld_octets + +body_fld_desc ::= nstring + +body_fld_dsp ::= "(" string SPACE body_fld_param ")" / nil + +body_fld_enc ::= (<"> ("7BIT" / "8BIT" / "BINARY" / "BASE64"/ + "QUOTED-PRINTABLE") <">) / string + +body_fld_id ::= nstring + +body_fld_lang ::= nstring / "(" 1#string ")" + + + + +Crispin Standards Track [Page 66] + +RFC 2060 IMAP4rev1 December 1996 + + +body_fld_lines ::= number + +body_fld_md5 ::= nstring + +body_fld_octets ::= number + +body_fld_param ::= "(" 1#(string SPACE string) ")" / nil + +body_type_1part ::= (body_type_basic / body_type_msg / body_type_text) + [SPACE body_ext_1part] + +body_type_basic ::= media_basic SPACE body_fields + ;; MESSAGE subtype MUST NOT be "RFC822" + +body_type_mpart ::= 1*body SPACE media_subtype + [SPACE body_ext_mpart] + +body_type_msg ::= media_message SPACE body_fields SPACE envelope + SPACE body SPACE body_fld_lines + +body_type_text ::= media_text SPACE body_fields SPACE body_fld_lines + +capability ::= "AUTH=" auth_type / atom + ;; New capabilities MUST begin with "X" or be + ;; registered with IANA as standard or + ;; standards-track + +capability_data ::= "CAPABILITY" SPACE [1#capability SPACE] "IMAP4rev1" + [SPACE 1#capability] + ;; IMAP4rev1 servers which offer RFC 1730 + ;; compatibility MUST list "IMAP4" as the first + ;; capability. + +CHAR ::= <any 7-bit US-ASCII character except NUL, + 0x01 - 0x7f> + +CHAR8 ::= <any 8-bit octet except NUL, 0x01 - 0xff> + +command ::= tag SPACE (command_any / command_auth / + command_nonauth / command_select) CRLF + ;; Modal based on state + +command_any ::= "CAPABILITY" / "LOGOUT" / "NOOP" / x_command + ;; Valid in all states + +command_auth ::= append / create / delete / examine / list / lsub / + rename / select / status / subscribe / unsubscribe + ;; Valid only in Authenticated or Selected state + + + +Crispin Standards Track [Page 67] + +RFC 2060 IMAP4rev1 December 1996 + + +command_nonauth ::= login / authenticate + ;; Valid only when in Non-Authenticated state + +command_select ::= "CHECK" / "CLOSE" / "EXPUNGE" / + copy / fetch / store / uid / search + ;; Valid only when in Selected state + +continue_req ::= "+" SPACE (resp_text / base64) + +copy ::= "COPY" SPACE set SPACE mailbox + +CR ::= <ASCII CR, carriage return, 0x0D> + +create ::= "CREATE" SPACE mailbox + ;; Use of INBOX gives a NO error + +CRLF ::= CR LF + +CTL ::= <any ASCII control character and DEL, + 0x00 - 0x1f, 0x7f> + +date ::= date_text / <"> date_text <"> + +date_day ::= 1*2digit + ;; Day of month + +date_day_fixed ::= (SPACE digit) / 2digit + ;; Fixed-format version of date_day + +date_month ::= "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" / + "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec" + +date_text ::= date_day "-" date_month "-" date_year + +date_year ::= 4digit + +date_time ::= <"> date_day_fixed "-" date_month "-" date_year + SPACE time SPACE zone <"> + +delete ::= "DELETE" SPACE mailbox + ;; Use of INBOX gives a NO error + +digit ::= "0" / digit_nz + +digit_nz ::= "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / + "9" + + + + + +Crispin Standards Track [Page 68] + +RFC 2060 IMAP4rev1 December 1996 + + +envelope ::= "(" env_date SPACE env_subject SPACE env_from + SPACE env_sender SPACE env_reply_to SPACE env_to + SPACE env_cc SPACE env_bcc SPACE env_in_reply_to + SPACE env_message_id ")" + +env_bcc ::= "(" 1*address ")" / nil + +env_cc ::= "(" 1*address ")" / nil + +env_date ::= nstring + +env_from ::= "(" 1*address ")" / nil + +env_in_reply_to ::= nstring + +env_message_id ::= nstring + +env_reply_to ::= "(" 1*address ")" / nil + +env_sender ::= "(" 1*address ")" / nil + +env_subject ::= nstring + +env_to ::= "(" 1*address ")" / nil + +examine ::= "EXAMINE" SPACE mailbox + +fetch ::= "FETCH" SPACE set SPACE ("ALL" / "FULL" / + "FAST" / fetch_att / "(" 1#fetch_att ")") + +fetch_att ::= "ENVELOPE" / "FLAGS" / "INTERNALDATE" / + "RFC822" [".HEADER" / ".SIZE" / ".TEXT"] / + "BODY" ["STRUCTURE"] / "UID" / + "BODY" [".PEEK"] section + ["<" number "." nz_number ">"] + +flag ::= "\Answered" / "\Flagged" / "\Deleted" / + "\Seen" / "\Draft" / flag_keyword / flag_extension + +flag_extension ::= "\" atom + ;; Future expansion. Client implementations + ;; MUST accept flag_extension flags. Server + ;; implementations MUST NOT generate + ;; flag_extension flags except as defined by + ;; future standard or standards-track + ;; revisions of this specification. + +flag_keyword ::= atom + + + +Crispin Standards Track [Page 69] + +RFC 2060 IMAP4rev1 December 1996 + + +flag_list ::= "(" #flag ")" + +greeting ::= "*" SPACE (resp_cond_auth / resp_cond_bye) CRLF + +header_fld_name ::= astring + +header_list ::= "(" 1#header_fld_name ")" + +LF ::= <ASCII LF, line feed, 0x0A> + +list ::= "LIST" SPACE mailbox SPACE list_mailbox + +list_mailbox ::= 1*(ATOM_CHAR / list_wildcards) / string + +list_wildcards ::= "%" / "*" + +literal ::= "{" number "}" CRLF *CHAR8 + ;; Number represents the number of CHAR8 octets + +login ::= "LOGIN" SPACE userid SPACE password + +lsub ::= "LSUB" SPACE mailbox SPACE list_mailbox + +mailbox ::= "INBOX" / astring + ;; INBOX is case-insensitive. All case variants of + ;; INBOX (e.g. "iNbOx") MUST be interpreted as INBOX + ;; not as an astring. Refer to section 5.1 for + ;; further semantic details of mailbox names. + +mailbox_data ::= "FLAGS" SPACE flag_list / + "LIST" SPACE mailbox_list / + "LSUB" SPACE mailbox_list / + "MAILBOX" SPACE text / + "SEARCH" [SPACE 1#nz_number] / + "STATUS" SPACE mailbox SPACE + "(" #<status_att number ")" / + number SPACE "EXISTS" / number SPACE "RECENT" + +mailbox_list ::= "(" #("\Marked" / "\Noinferiors" / + "\Noselect" / "\Unmarked" / flag_extension) ")" + SPACE (<"> QUOTED_CHAR <"> / nil) SPACE mailbox + +media_basic ::= (<"> ("APPLICATION" / "AUDIO" / "IMAGE" / + "MESSAGE" / "VIDEO") <">) / string) + SPACE media_subtype + ;; Defined in [MIME-IMT] + +media_message ::= <"> "MESSAGE" <"> SPACE <"> "RFC822" <"> + + + +Crispin Standards Track [Page 70] + +RFC 2060 IMAP4rev1 December 1996 + + + ;; Defined in [MIME-IMT] + +media_subtype ::= string + ;; Defined in [MIME-IMT] + +media_text ::= <"> "TEXT" <"> SPACE media_subtype + ;; Defined in [MIME-IMT] + +message_data ::= nz_number SPACE ("EXPUNGE" / + ("FETCH" SPACE msg_att)) + +msg_att ::= "(" 1#("ENVELOPE" SPACE envelope / + "FLAGS" SPACE "(" #(flag / "\Recent") ")" / + "INTERNALDATE" SPACE date_time / + "RFC822" [".HEADER" / ".TEXT"] SPACE nstring / + "RFC822.SIZE" SPACE number / + "BODY" ["STRUCTURE"] SPACE body / + "BODY" section ["<" number ">"] SPACE nstring / + "UID" SPACE uniqueid) ")" + +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 ::= <"> *QUOTED_CHAR <"> + +QUOTED_CHAR ::= <any TEXT_CHAR except quoted_specials> / + "\" quoted_specials + +quoted_specials ::= <"> / "\" + +rename ::= "RENAME" SPACE mailbox SPACE mailbox + ;; Use of INBOX as a destination gives a NO error + +response ::= *(continue_req / response_data) response_done + +response_data ::= "*" SPACE (resp_cond_state / resp_cond_bye / + mailbox_data / message_data / capability_data) + + + +Crispin Standards Track [Page 71] + +RFC 2060 IMAP4rev1 December 1996 + + + CRLF + +response_done ::= response_tagged / response_fatal + +response_fatal ::= "*" SPACE resp_cond_bye CRLF + ;; Server closes connection immediately + +response_tagged ::= tag SPACE resp_cond_state CRLF + +resp_cond_auth ::= ("OK" / "PREAUTH") SPACE resp_text + ;; Authentication condition + +resp_cond_bye ::= "BYE" SPACE resp_text + +resp_cond_state ::= ("OK" / "NO" / "BAD") SPACE resp_text + ;; Status condition + +resp_text ::= ["[" resp_text_code "]" SPACE] (text_mime2 / text) + ;; text SHOULD NOT begin with "[" or "=" + +resp_text_code ::= "ALERT" / "PARSE" / + "PERMANENTFLAGS" SPACE "(" #(flag / "\*") ")" / + "READ-ONLY" / "READ-WRITE" / "TRYCREATE" / + "UIDVALIDITY" SPACE nz_number / + "UNSEEN" SPACE nz_number / + atom [SPACE 1*<any TEXT_CHAR except "]">] + +search ::= "SEARCH" SPACE ["CHARSET" SPACE astring SPACE] + 1#search_key + ;; [CHARSET] MUST be registered with IANA + +search_key ::= "ALL" / "ANSWERED" / "BCC" SPACE astring / + "BEFORE" SPACE date / "BODY" SPACE astring / + "CC" SPACE astring / "DELETED" / "FLAGGED" / + "FROM" SPACE astring / + "KEYWORD" SPACE flag_keyword / "NEW" / "OLD" / + "ON" SPACE date / "RECENT" / "SEEN" / + "SINCE" SPACE date / "SUBJECT" SPACE astring / + "TEXT" SPACE astring / "TO" SPACE astring / + "UNANSWERED" / "UNDELETED" / "UNFLAGGED" / + "UNKEYWORD" SPACE flag_keyword / "UNSEEN" / + ;; Above this line were in [IMAP2] + "DRAFT" / + "HEADER" SPACE header_fld_name SPACE astring / + "LARGER" SPACE number / "NOT" SPACE search_key / + "OR" SPACE search_key SPACE search_key / + "SENTBEFORE" SPACE date / "SENTON" SPACE date / + "SENTSINCE" SPACE date / "SMALLER" SPACE number / + + + +Crispin Standards Track [Page 72] + +RFC 2060 IMAP4rev1 December 1996 + + + "UID" SPACE set / "UNDRAFT" / set / + "(" 1#search_key ")" + +section ::= "[" [section_text / (nz_number *["." nz_number] + ["." (section_text / "MIME")])] "]" + +section_text ::= "HEADER" / "HEADER.FIELDS" [".NOT"] + SPACE header_list / "TEXT" + +select ::= "SELECT" SPACE mailbox + +sequence_num ::= nz_number / "*" + ;; * is the largest number in use. For message + ;; sequence numbers, it is the number of messages + ;; in the mailbox. For unique identifiers, it is + ;; the unique identifier of the last message in + ;; the mailbox. + +set ::= sequence_num / (sequence_num ":" sequence_num) / + (set "," set) + ;; Identifies a set of messages. For message + ;; sequence numbers, these are consecutive + ;; numbers from 1 to the number of messages in + ;; the mailbox + ;; Comma delimits individual numbers, colon + ;; delimits between two numbers inclusive. + ;; Example: 2,4:7,9,12:* is 2,4,5,6,7,9,12,13, + ;; 14,15 for a mailbox with 15 messages. + +SPACE ::= <ASCII SP, space, 0x20> + +status ::= "STATUS" SPACE mailbox SPACE "(" 1#status_att ")" + +status_att ::= "MESSAGES" / "RECENT" / "UIDNEXT" / "UIDVALIDITY" / + "UNSEEN" + +store ::= "STORE" SPACE set SPACE store_att_flags + +store_att_flags ::= (["+" / "-"] "FLAGS" [".SILENT"]) SPACE + (flag_list / #flag) + +string ::= quoted / literal + +subscribe ::= "SUBSCRIBE" SPACE mailbox + +tag ::= 1*<any ATOM_CHAR except "+"> + +text ::= 1*TEXT_CHAR + + + +Crispin Standards Track [Page 73] + +RFC 2060 IMAP4rev1 December 1996 + + +text_mime2 ::= "=?" <charset> "?" <encoding> "?" + <encoded-text> "?=" + ;; Syntax defined in [MIME-HDRS] + +TEXT_CHAR ::= <any CHAR except CR and LF> + +time ::= 2digit ":" 2digit ":" 2digit + ;; Hours minutes seconds + +uid ::= "UID" SPACE (copy / fetch / search / store) + ;; Unique identifiers used instead of message + ;; sequence numbers + +uniqueid ::= nz_number + ;; Strictly ascending + +unsubscribe ::= "UNSUBSCRIBE" SPACE mailbox + +userid ::= astring + +x_command ::= "X" atom <experimental command arguments> + +zone ::= ("+" / "-") 4digit + ;; Signed four-digit value of hhmm representing + ;; hours and minutes west of Greenwich (that is, + ;; (the amount that the given time differs from + ;; Universal Time). Subtracting the timezone + ;; from the given time will give the UT form. + ;; The Universal Time zone is "+0000". + +10. Author's Note + + This document is a revision or rewrite of earlier documents, and + supercedes the protocol specification in those documents: 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 privacy protection is + negotiated in the AUTHENTICATE command. + + A server error message for an AUTHENTICATE command which fails due to + invalid credentials SHOULD NOT detail why the credentials are + invalid. + + Use of the LOGIN command sends passwords in the clear. This can be + avoided by using the AUTHENTICATE command instead. + + + +Crispin Standards Track [Page 74] + +RFC 2060 IMAP4rev1 December 1996 + + + A server error message for a failing LOGIN command SHOULD NOT specify + that the user name, as opposed to the password, is invalid. + + Additional security considerations are discussed in the section + discussing the AUTHENTICATE and LOGIN commands. + +12. Author's Address + + Mark R. Crispin + Networks and Distributed Computing + University of Washington + 4545 15th Aveneue NE + Seattle, WA 98105-4527 + + Phone: (206) 543-5762 + + EMail: MRC@CAC.Washington.EDU + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Crispin Standards Track [Page 75] + +RFC 2060 IMAP4rev1 December 1996 + + +Appendices + +A. References + +[ACAP] Myers, J. "ACAP -- Application Configuration Access Protocol", +Work in Progress. + +[CHARSET] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, +RFC 1700, USC/Information Sciences Institute, October 1994. + +[DISPOSITION] Troost, R., and Dorner, S., "Communicating Presentation +Information in Internet Messages: The Content-Disposition Header", +RFC 1806, June 1995. + +[IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731. +Carnegie-Mellon University, December 1994. + +[IMAP-COMPAT] Crispin, M., "IMAP4 Compatibility with IMAP2bis", RFC +2061, University of Washington, November 1996. + +[IMAP-DISC] Austein, R., "Synchronization Operations for Disconnected +IMAP4 Clients", Work in Progress. + +[IMAP-HISTORICAL] Crispin, M. "IMAP4 Compatibility with IMAP2 and +IMAP2bis", RFC 1732, University of Washington, December 1994. + +[IMAP-MODEL] Crispin, M., "Distributed Electronic Mail Models in +IMAP4", RFC 1733, University of Washington, December 1994. + +[IMAP-OBSOLETE] Crispin, M., "Internet Message Access Protocol - +Obsolete Syntax", RFC 2062, University of Washington, November 1996. + +[IMAP2] Crispin, M., "Interactive Mail Access Protocol - Version 2", +RFC 1176, University of Washington, August 1990. + +[LANGUAGE-TAGS] Alvestrand, H., "Tags for the Identification of +Languages", RFC 1766, March 1995. + +[MD5] Myers, J., and M. Rose, "The Content-MD5 Header Field", RFC +1864, October 1995. + +[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. + + + +Crispin Standards Track [Page 76] + +RFC 2060 IMAP4rev1 December 1996 + + +[MIME-HDRS] Moore, K., "MIME (Multipurpose Internet Mail Extensions) +Part Three: Message Header Extensions for Non-ASCII Text", RFC +2047, November 1996. + +[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text +Messages", STD 11, RFC 822, University of Delaware, August 1982. + +[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, +RFC 821, USC/Information Sciences Institute, August 1982. + +[UTF-7] Goldsmith, D., and Davis, M., "UTF-7: A Mail-Safe +Transformation Format of Unicode", RFC 1642, July 1994. + +B. Changes from RFC 1730 + +1) The STATUS command has been added. + +2) Clarify in the formal syntax that the "#" construct can never +refer to multiple spaces. + +3) Obsolete syntax has been moved to a separate document. + +4) The PARTIAL command has been obsoleted. + +5) The RFC822.HEADER.LINES, RFC822.HEADER.LINES.NOT, RFC822.PEEK, and +RFC822.TEXT.PEEK fetch attributes have been obsoleted. + +6) The "<" origin "." size ">" suffix for BODY text attributes has +been added. + +7) The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, MIME, and TEXT part +specifiers have been added. + +8) Support for Content-Disposition and Content-Language has been +added. + +9) The restriction on fetching nested MULTIPART parts has been +removed. + +10) Body part number 0 has been obsoleted. + +11) Server-supported authenticators are now identified by +capabilities. + + + + + + + + +Crispin Standards Track [Page 77] + +RFC 2060 IMAP4rev1 December 1996 + + +12) The capability that identifies this protocol is now called +"IMAP4rev1". A server that provides backwards support for RFC 1730 +SHOULD emit the "IMAP4" capability in addition to "IMAP4rev1" in its +CAPABILITY response. Because RFC-1730 required "IMAP4" to appear as +the first capability, it MUST listed first in the response. + +13) A description of the mailbox name namespace convention has been +added. + +14) A description of the international mailbox name convention has +been added. + +15) The UID-NEXT and UID-VALIDITY status items are now called UIDNEXT +and UIDVALIDITY. This is a change from the IMAP STATUS +Work in Progress and not from RFC-1730 + +16) Add a clarification that a null mailbox name argument to the LIST +command returns an untagged LIST response with the hierarchy +delimiter and root of the reference argument. + +17) Define terms such as "MUST", "SHOULD", and "MUST NOT". + +18) Add a section which defines message attributes and more +thoroughly details the semantics of message sequence numbers, UIDs, +and flags. + +19) Add a clarification detailing the circumstances when a client may +send multiple commands without waiting for a response, and the +circumstances in which ambiguities may result. + +20) Add a recommendation on server behavior for DELETE and RENAME +when inferior hierarchical names of the given name exist. + +21) Add a clarification that a mailbox name may not be unilaterally +unsubscribed by the server, even if that mailbox name no longer +exists. + +22) Add a clarification that LIST should return its results quickly +without undue delay. + +23) Add a clarification that the date_time argument to APPEND sets +the internal date of the message. + +24) Add a clarification on APPEND behavior when the target mailbox is +the currently selected mailbox. + + + + + + +Crispin Standards Track [Page 78] + +RFC 2060 IMAP4rev1 December 1996 + + +25) Add a clarification that external changes to flags should be +always announced via an untagged FETCH even if the current command is +a STORE with the ".SILENT" suffix. + +26) Add a clarification that COPY appends to the target mailbox. + +27) Add the NEWNAME response code. + +28) Rewrite the description of the untagged BYE response to clarify +its semantics. + +29) Change the reference for the body MD5 to refer to the proper RFC. + +30) Clarify that the formal syntax contains rules which may overlap, +and that in the event of such an overlap the rule which occurs first +takes precedence. + +31) Correct the definition of body_fld_param. + +32) More formal syntax for capability_data. + +33) Clarify that any case variant of "INBOX" must be interpreted as +INBOX. + +34) Clarify that the human-readable text in resp_text should not +begin with "[" or "=". + +35) Change MIME references to Draft Standard documents. + +36) Clarify \Recent semantics. + +37) Additional examples. + +C. Key Word Index + + +FLAGS <flag list> (store command data item) ............... 45 + +FLAGS.SILENT <flag list> (store command data item) ........ 46 + -FLAGS <flag list> (store command data item) ............... 46 + -FLAGS.SILENT <flag list> (store command data item) ........ 46 + ALERT (response code) ...................................... 50 + ALL (fetch item) ........................................... 41 + ALL (search key) ........................................... 38 + ANSWERED (search key) ...................................... 38 + APPEND (command) ........................................... 34 + AUTHENTICATE (command) ..................................... 20 + BAD (response) ............................................. 52 + BCC <string> (search key) .................................. 38 + BEFORE <date> (search key) ................................. 39 + + + +Crispin Standards Track [Page 79] + +RFC 2060 IMAP4rev1 December 1996 + + + BODY (fetch item) .......................................... 41 + BODY (fetch result) ........................................ 58 + BODY <string> (search key) ................................. 39 + BODY.PEEK[<section>]<<partial>> (fetch item) ............... 44 + BODYSTRUCTURE (fetch item) ................................. 44 + BODYSTRUCTURE (fetch result) ............................... 59 + BODY[<section>]<<origin_octet>> (fetch result) ............. 58 + BODY[<section>]<<partial>> (fetch item) .................... 41 + BYE (response) ............................................. 52 + Body Structure (message attribute) ......................... 11 + CAPABILITY (command) ....................................... 18 + CAPABILITY (response) ...................................... 53 + CC <string> (search key) ................................... 39 + CHECK (command) ............................................ 36 + CLOSE (command) ............................................ 36 + COPY (command) ............................................. 46 + CREATE (command) ........................................... 25 + DELETE (command) ........................................... 26 + DELETED (search key) ....................................... 39 + DRAFT (search key) ......................................... 39 + ENVELOPE (fetch item) ...................................... 44 + ENVELOPE (fetch result) .................................... 62 + EXAMINE (command) .......................................... 24 + EXISTS (response) .......................................... 56 + EXPUNGE (command) .......................................... 37 + EXPUNGE (response) ......................................... 57 + Envelope Structure (message attribute) ..................... 11 + FAST (fetch item) .......................................... 44 + FETCH (command) ............................................ 41 + FETCH (response) ........................................... 58 + FLAGGED (search key) ....................................... 39 + FLAGS (fetch item) ......................................... 44 + FLAGS (fetch result) ....................................... 62 + FLAGS (response) ........................................... 56 + FLAGS <flag list> (store command data item) ................ 45 + FLAGS.SILENT <flag list> (store command data item) ......... 45 + FROM <string> (search key) ................................. 39 + FULL (fetch item) .......................................... 44 + Flags (message attribute) .................................. 9 + HEADER (part specifier) .................................... 41 + HEADER <field-name> <string> (search key) .................. 39 + HEADER.FIELDS <header_list> (part specifier) ............... 41 + HEADER.FIELDS.NOT <header_list> (part specifier) ........... 41 + INTERNALDATE (fetch item) .................................. 44 + INTERNALDATE (fetch result) ................................ 62 + Internal Date (message attribute) .......................... 10 + KEYWORD <flag> (search key) ................................ 39 + Keyword (type of flag) ..................................... 10 + + + +Crispin Standards Track [Page 80] + +RFC 2060 IMAP4rev1 December 1996 + + + LARGER <n> (search key) .................................... 39 + LIST (command) ............................................. 30 + LIST (response) ............................................ 54 + LOGIN (command) ............................................ 22 + LOGOUT (command) ........................................... 20 + LSUB (command) ............................................. 32 + LSUB (response) ............................................ 55 + MAY (specification requirement term) ....................... 5 + MESSAGES (status item) ..................................... 33 + MIME (part specifier) ...................................... 42 + MUST (specification requirement term) ...................... 4 + MUST NOT (specification requirement term) .................. 4 + Message Sequence Number (message attribute) ................ 9 + NEW (search key) ........................................... 39 + NEWNAME (response code) .................................... 50 + NO (response) .............................................. 51 + NOOP (command) ............................................. 19 + NOT <search-key> (search key) .............................. 39 + OK (response) .............................................. 51 + OLD (search key) ........................................... 39 + ON <date> (search key) ..................................... 39 + OPTIONAL (specification requirement term) .................. 5 + OR <search-key1> <search-key2> (search key) ................ 39 + PARSE (response code) ...................................... 50 + PERMANENTFLAGS (response code) ............................. 50 + PREAUTH (response) ......................................... 52 + Permanent Flag (class of flag) ............................. 10 + READ-ONLY (response code) .................................. 50 + READ-WRITE (response code) ................................. 50 + RECENT (response) .......................................... 57 + RECENT (search key) ........................................ 39 + RECENT (status item) ....................................... 33 + RENAME (command) ........................................... 27 + REQUIRED (specification requirement term) .................. 4 + RFC822 (fetch item) ........................................ 44 + RFC822 (fetch result) ...................................... 63 + RFC822.HEADER (fetch item) ................................. 44 + RFC822.HEADER (fetch result) ............................... 62 + RFC822.SIZE (fetch item) ................................... 44 + RFC822.SIZE (fetch result) ................................. 62 + RFC822.TEXT (fetch item) ................................... 44 + RFC822.TEXT (fetch result) ................................. 62 + SEARCH (command) ........................................... 37 + SEARCH (response) .......................................... 55 + SEEN (search key) .......................................... 40 + SELECT (command) ........................................... 23 + SENTBEFORE <date> (search key) ............................. 40 + SENTON <date> (search key) ................................. 40 + + + +Crispin Standards Track [Page 81] + +RFC 2060 IMAP4rev1 December 1996 + + + SENTSINCE <date> (search key) .............................. 40 + SHOULD (specification requirement term) .................... 5 + SHOULD NOT (specification requirement term) ................ 5 + SINCE <date> (search key) .................................. 40 + SMALLER <n> (search key) ................................... 40 + STATUS (command) ........................................... 33 + STATUS (response) .......................................... 55 + STORE (command) ............................................ 45 + SUBJECT <string> (search key) .............................. 40 + SUBSCRIBE (command) ........................................ 29 + Session Flag (class of flag) ............................... 10 + System Flag (type of flag) ................................. 9 + TEXT (part specifier) ...................................... 42 + TEXT <string> (search key) ................................. 40 + TO <string> (search key) ................................... 40 + TRYCREATE (response code) .................................. 51 + UID (command) .............................................. 47 + UID (fetch item) ........................................... 44 + UID (fetch result) ......................................... 63 + UID <message set> (search key) ............................. 40 + UIDNEXT (status item) ...................................... 33 + UIDVALIDITY (response code) ................................ 51 + UIDVALIDITY (status item) .................................. 34 + UNANSWERED (search key) .................................... 40 + UNDELETED (search key) ..................................... 40 + UNDRAFT (search key) ....................................... 40 + UNFLAGGED (search key) ..................................... 40 + UNKEYWORD <flag> (search key) .............................. 40 + UNSEEN (response code) ..................................... 51 + UNSEEN (search key) ........................................ 40 + UNSEEN (status item) ....................................... 34 + UNSUBSCRIBE (command) ...................................... 30 + Unique Identifier (UID) (message attribute) ................ 7 + X<atom> (command) .......................................... 48 + [RFC-822] Size (message attribute) ......................... 11 + \Answered (system flag) .................................... 9 + \Deleted (system flag) ..................................... 9 + \Draft (system flag) ....................................... 9 + \Flagged (system flag) ..................................... 9 + \Marked (mailbox name attribute) ........................... 54 + \Noinferiors (mailbox name attribute) ...................... 54 + \Noselect (mailbox name attribute) ......................... 54 + \Recent (system flag) ...................................... 10 + \Seen (system flag) ........................................ 9 + \Unmarked (mailbox name attribute) ......................... 54 + + + + + + +Crispin Standards Track [Page 82] + diff --git a/previousAttempts/RFC/rfc2177.txt b/previousAttempts/RFC/rfc2177.txt new file mode 100644 index 0000000..c11c765 --- /dev/null +++ b/previousAttempts/RFC/rfc2177.txt @@ -0,0 +1,227 @@ + + + + + + +Network Working Group B. Leiba +Request for Comments: 2177 IBM T.J. Watson Research Center +Category: Standards Track June 1997 + + + IMAP4 IDLE command + +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. + +1. Abstract + + The Internet Message Access Protocol [IMAP4] requires a client to + poll the server for changes to the selected mailbox (new mail, + deletions). It's often more desirable to have the server transmit + updates to the client in real time. This allows a user to see new + mail immediately. It also helps some real-time applications based on + IMAP, which might otherwise need to poll extremely often (such as + every few seconds). (While the spec actually does allow a server to + push EXISTS responses aysynchronously, a client can't expect this + behaviour and must poll.) + + This document specifies the syntax of an IDLE command, which will + allow a client to tell the server that it's ready to accept such + real-time updates. + +2. Conventions Used in this Document + + In examples, "C:" and "S:" indicate lines sent by the client and + server respectively. + + The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" + in this document are to be interpreted as described in RFC 2060 + [IMAP4]. + +3. Specification + + IDLE Command + + Arguments: none + + Responses: continuation data will be requested; the client sends + the continuation data "DONE" to end the command + + + +Leiba Standards Track [Page 1] + +RFC 2177 IMAP4 IDLE command June 1997 + + + + Result: OK - IDLE completed after client sent "DONE" + NO - failure: the server will not allow the IDLE + command at this time + BAD - command unknown or arguments invalid + + The IDLE command may be used with any IMAP4 server implementation + that returns "IDLE" as one of the supported capabilities to the + CAPABILITY command. If the server does not advertise the IDLE + capability, the client MUST NOT use the IDLE command and must poll + for mailbox updates. In particular, the client MUST continue to be + able to accept unsolicited untagged responses to ANY command, as + specified in the base IMAP specification. + + The IDLE command is sent from the client to the server when the + client is ready to accept unsolicited mailbox update messages. The + server requests a response to the IDLE command using the continuation + ("+") response. The IDLE command remains active until the client + responds to the continuation, and as long as an IDLE command is + active, the server is now free to send untagged EXISTS, EXPUNGE, and + other messages at any time. + + The IDLE command is terminated by the receipt of a "DONE" + continuation from the client; such response satisfies the server's + continuation request. At that point, the server MAY send any + remaining queued untagged responses and then MUST immediately send + the tagged response to the IDLE command and prepare to process other + commands. As in the base specification, the processing of any new + command may cause the sending of unsolicited untagged responses, + subject to the ambiguity limitations. The client MUST NOT send a + command while the server is waiting for the DONE, since the server + will not be able to distinguish a command from a continuation. + + The server MAY consider a client inactive if it has an IDLE command + running, and if such a server has an inactivity timeout it MAY log + the client off implicitly at the end of its timeout period. Because + of that, clients using IDLE are advised to terminate the IDLE and + re-issue it at least every 29 minutes to avoid being logged off. + This still allows a client to receive immediate mailbox updates even + though it need only "poll" at half hour intervals. + + + + + + + + + + + +Leiba Standards Track [Page 2] + +RFC 2177 IMAP4 IDLE command June 1997 + + + Example: C: A001 SELECT INBOX + S: * FLAGS (Deleted Seen) + S: * 3 EXISTS + S: * 0 RECENT + S: * OK [UIDVALIDITY 1] + S: A001 OK SELECT completed + C: A002 IDLE + S: + idling + ...time passes; new mail arrives... + S: * 4 EXISTS + C: DONE + S: A002 OK IDLE terminated + ...another client expunges message 2 now... + C: A003 FETCH 4 ALL + S: * 4 FETCH (...) + S: A003 OK FETCH completed + C: A004 IDLE + S: * 2 EXPUNGE + S: * 3 EXISTS + S: + idling + ...time passes; another client expunges message 3... + S: * 3 EXPUNGE + S: * 2 EXISTS + ...time passes; new mail arrives... + S: * 3 EXISTS + C: DONE + S: A004 OK IDLE terminated + C: A005 FETCH 3 ALL + S: * 3 FETCH (...) + S: A005 OK FETCH completed + C: A006 IDLE + +4. Formal Syntax + + The following syntax specification uses the augmented Backus-Naur + Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4]. + Non-terminals referenced but not defined below are as defined by + [IMAP4]. + + command_auth ::= append / create / delete / examine / list / lsub / + rename / select / status / subscribe / unsubscribe + / idle + ;; Valid only in Authenticated or Selected state + + idle ::= "IDLE" CRLF "DONE" + + + + + + +Leiba Standards Track [Page 3] + +RFC 2177 IMAP4 IDLE command June 1997 + + +5. References + + [IMAP4] Crispin, M., "Internet Message Access Protocol - Version + 4rev1", RFC 2060, December 1996. + +6. Security Considerations + + There are no known security issues with this extension. + +7. Author's Address + + Barry Leiba + IBM T.J. Watson Research Center + 30 Saw Mill River Road + Hawthorne, NY 10532 + + Email: leiba@watson.ibm.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Leiba Standards Track [Page 4] + diff --git a/previousAttempts/java/ArchivableFolder.java b/previousAttempts/java/ArchivableFolder.java new file mode 100644 index 0000000..47a5764 --- /dev/null +++ b/previousAttempts/java/ArchivableFolder.java @@ -0,0 +1,69 @@ +import java.util.ArrayList; + +import javax.mail.Flags; +import javax.mail.Folder; +import javax.mail.Message; +import javax.mail.MessagingException; + +/** + * Class servers as a container for messages to be archived from the + * particular folder and does the actual archivation. + * @author matej + * + */ +@SuppressWarnings("serial") +public class ArchivableFolder extends ArrayList<Message> { + private Folder sourceFolder; + private Folder targetFolder; + + /** + * Constructor for the folder. + * @param source + * @param year + * @throws MessagingException + */ + public ArchivableFolder(Folder source, int year) throws MessagingException { + sourceFolder = source; + targetFolder = getArchiveFolderName(source,year); + } + + /** + * + * @throws MessagingException + */ + public void doArchive() throws MessagingException { + Message[] intArray; + intArray = (Message[]) this.toArray(); + sourceFolder.copyMessages(intArray, targetFolder); + for (Message message : intArray) { + message.setFlag(Flags.Flag.DELETED, true); + } + sourceFolder.expunge(); + } + + /** + * + * @param msg + * @return + */ + @Override + public boolean add(Message msg) { + return this.add(msg); + } + + /** + * + * @param folder + * @param year + * @return + * @throws MessagingException + */ + private static Folder getArchiveFolderName(Folder folder,int year) throws MessagingException { + String archFolder = "INBOX/Archiv/"; + int rootLen = "INBOX/".length(); + String baseName = folder.getFullName(); + baseName = baseName.substring(rootLen, baseName.length()); + archFolder = "/" + archFolder + year + "/" + baseName; + return(folder.getFolder(archFolder)); + } +} diff --git a/previousAttempts/java/Archives.java b/previousAttempts/java/Archives.java new file mode 100644 index 0000000..c882e75 --- /dev/null +++ b/previousAttempts/java/Archives.java @@ -0,0 +1,85 @@ +import java.util.Calendar; +import java.util.GregorianCalendar; +import java.util.HashMap; + +import javax.mail.Folder; +import javax.mail.Message; +import javax.mail.MessagingException; + +/** + * + */ + +/** + * @author matej + * + */ +@SuppressWarnings("serial") +public class Archives extends HashMap<Object[],ArchivableFolder> { + + public Archives() { + ; + } + + /** + * create a key for the list + * @param fldName String with the full name of the folder + * @param year int of the year of the messages to be stored + * there + * @return array consisting from the both parameters of + * this function. + */ + private Object[] createKey(String fldName, int year) { + Object[] out = {fldName,year}; + return(out); + } + + /** + * Find out whether the object with the key consisting of + * the folder name and year exists in this object. + * + * @param fld Folder where the message is stored + * @param year int year of the message date + * @return boolean saying whether the folder for this message + * has been already added to this object. + */ + private boolean search(Folder fld, int year) { + Object[] key = createKey(fld.getFullName(), year); + return(this.containsKey(key)); + } + + /** + * Return the date of the message + * + * @param msg analyzed message + * @return GregorianCalendar of the messages date + * @throws MessagingException + */ + static GregorianCalendar getMessageDate(Message msg) + throws MessagingException { + GregorianCalendar date = new GregorianCalendar(); + date.setTime(msg.getReceivedDate()); + return(date); + } + + /** + * Check whether the ArchivableFolder (@see ArchivableFolder) + * for the particular year actually exists, and if not then create + * it. In any event add + * @param msg + * @throws MessagingException + */ + public void add(Message msg) throws MessagingException { + Folder fld = msg.getFolder(); + GregorianCalendar msgDate = getMessageDate(msg); + int year = msgDate.get(Calendar.YEAR); + + if (!search(fld,year)) { + ArchivableFolder archfld = new ArchivableFolder(fld,year); + Object[] key = createKey(fld.getFullName(), year); + this.put(key, archfld); + } + } + +// public ArchivableFolder get() +}
\ No newline at end of file diff --git a/previousAttempts/java/imapList.java b/previousAttempts/java/imapList.java new file mode 100644 index 0000000..fd2ef1d --- /dev/null +++ b/previousAttempts/java/imapList.java @@ -0,0 +1,95 @@ +import java.io.File; +import java.util.Calendar; +import java.util.GregorianCalendar; +import java.util.Properties; +import java.util.prefs.BackingStoreException; +import java.util.prefs.Preferences; + +import javax.mail.Folder; +import javax.mail.Message; +import javax.mail.MessagingException; +import javax.mail.NoSuchProviderException; +import javax.mail.Session; +import javax.mail.Store; + +import org.ini4j.IniFile; + +/** testing class for javax.mail functions + * @author matej + * + */ +public class imapList { + private static Archives archiveList = new Archives(); + private static GregorianCalendar threeMonthAgo = + new GregorianCalendar(); + + private static void archiveFolder(Folder fld) throws MessagingException { + fld.open(Folder.READ_WRITE); + + for (Message msg : fld.getMessages()) { + GregorianCalendar msgDate = Archives.getMessageDate(msg); + System.out.println(msgDate); + if (msgDate.before(threeMonthAgo)) { + archiveList.add(msg); + } + } + + fld.close(false); + } + + /** + * main() method setting up internal properties and then running + * remaining classes and methods. + * @param args + * @throws BackingStoreException + * @throws MessagingException + */ + public static void main(String[] args) throws BackingStoreException, MessagingException { + Store store = null; + String folderName = ""; + + Properties props = System.getProperties(); + String homeFolder = props.getProperty("user.home"); + props.setProperty("javax.net.ssl.keyStore", + homeFolder+"/.keystore"); + props.setProperty("javax.net.ssl.trustStore", + homeFolder+"/.keystore"); + + String iniFileName = homeFolder+"/.bugzillarc"; + Preferences prefs = new IniFile(new File(iniFileName)); + String login = prefs.node("localhost").get("user", + props.getProperty("user.name")); + String password = prefs.node("localhost").get("password", null); + String hostname = prefs.node("localhost").get("host", "localhost"); + int port = prefs.node("localhost").getInt("port", 993); + + threeMonthAgo = (GregorianCalendar) Calendar.getInstance(); + threeMonthAgo.set(Calendar.MONTH, + threeMonthAgo.get(Calendar.MONTH)-3); + + Session session = Session.getInstance(props,null); + //session.setDebug(true); + try { + store = session.getStore("imaps"); + } catch (NoSuchProviderException e) { + System.out.println(e.getMessage()); + System.exit(1); + } + try { + store.connect(hostname, port, login, password); + } catch (MessagingException e) { + System.out.print(e.getMessage()); + System.exit(1); + } + Folder folder = store.getDefaultFolder(); + Folder inboxfolder = folder.getFolder("INBOX"); + Folder[] folderList = inboxfolder.list("*"); + for (Folder fld : folderList) { + folderName = fld.getFullName(); + if (!folderName.startsWith("INBOX/Archiv")) { + archiveFolder(fld); + } + } + store.close(); + } +}
\ No newline at end of file diff --git a/previousAttempts/jython/imapArchive.py b/previousAttempts/jython/imapArchive.py new file mode 100644 index 0000000..f965c95 --- /dev/null +++ b/previousAttempts/jython/imapArchive.py @@ -0,0 +1,205 @@ +# -*- coding: utf-8 -*- +# note http://docs.python.org/lib/module-doctest.html +# resp. file:///usr/share/doc/python-docs-*/html/lib/module-doctest.html +# for testing +from __future__ import division +from java.util import Properties, Date +from java.lang import System +from javax.mail import * +from jarray import array +import sys, os +from datetime import date +from ConfigParser import ConfigParser + +debug=False + +def __getMessageDate(msg): + """ + Return the date of the message + + @param msg analyzed message + @return GregorianCalendar of the messages date + @throws MessagingException + """ + dateMS = msg.getReceivedDate().getTime()//1000 + dateStruct = date.fromtimestamp(dateMS) + return dateStruct + +class ArchivableFolder(list): + def __init__(self,source,year): + """ + Constructor for the folder. + + @param source folder from the messages should be archived + @param year int of the year for which the messages are + archived + """ + self.sourceFolder = source + targetName = self.__getArchiveFolderName(source.getFullName(), year) + self.targetFolder = self.sourceFolder.getFolder(targetName) + + def __getArchiveFolderName(self,srcFldName,year): + """ + @param folder string with the folder name + @param year int + @return + """ + archFolder = "INBOX/Archiv/" + rootLen = len("INBOX/") + if not(srcFldName[:rootLen]=="/INBOX/"): + raise FolderNotFoundException(\ + "We expect all folders to be under INBOX folder.") + baseName = srcFldName[rootLen:] + archFolder = "/" + archFolder + year + "/" + baseName + return archFolder + + def add(self,msg): + self.append(msg) + + def doArchive(self): + if debug: + for message in self: + print >>sys.stderr, "Moving %s from %s to %s." \ + % (message,self.sourceFolder.getFullName(), + self.targetFolder.getFullName()) + else: + self.sourceFolder.copyMessages(array(self,Message),\ + self.targetFolder) + for message in self: + message.setFlag(Flags.Flag.DELETED, true) + self.sourceFolder.expunge() + +class Archives(dict): + """Collects archivable folders indexed by tuple of + folderName and year + """ + def __init__(self): + pass + + def add(self,msg): + """ + Check whether the ArchivableFolder (@see ArchivableFolder) + for the particular year actually exists, and if not then create + it. In any event add + @param msg + """ + fld = msg.getFolder() + msgDate = __getMessageDate(msg) + year = msgDate.year + + if not(self.search(fld, year)): + archfld = ArchivableFolder(fld,year) + self[self.__createKey(fld,year)] = archfld + + def __createKey(self,name,year): + """ + Create a key for the list + @param fldName String with the full name of the folder + @param year int of the year of the messages to be stored + there + @return tuple consisting from the both parameters of + this function. + """ + return(name,year) + + def search(self,fld,year): + """ + Find out whether the object with the key consisting of + the folder name and year exists in this object. + + @param fld Folder where the message is stored + @param year int year of the message date + @return boolean saying whether the folder for this message + has been already added to this object. + """ + key = self.__createKey(fld.getFullName(), year) + return self.has_key(key) + + def archive(self): + for key in self: + self.doArchive() + +class ArchivedStore(object): + def __init__(self,paramServer="localhost",paramUser="",paramPassword=""): + self.props = System.getProperties() + self.session = Session.getInstance(self.props,None) + self.props.setProperty("javax.net.ssl.keyStore", "/home/matej/.keystore") + self.props.setProperty("javax.net.ssl.trustStore", "/home/matej/.keystore") + if debug: + self.session.setDebug(True) + try: + self.store = self.session.getStore("imaps") + except: + print >> sys.stderr, "Cannot get Store" + raise + + self._threeMonthAgo = date.today() + newmonth = self._threeMonthAgo.month-3 + self._threeMonthAgo = self._threeMonthAgo.replace(month=newmonth) + + conffile = os.path.expanduser("~/.bugzillarc") + confUser = ConfigParser() + defSection = "localhost" + user,host,port,password = self.props.getProperty("user.name"),\ + "localhost",993,"" + if confUser.read(conffile): + if confUser.has_section(defSection): + if confUser.has_option(defSection, "name"): + user = confUser.get(defSection, "name") + if confUser.has_option(defSection, "host"): + host = confUser.get(defSection, "host") + if confUser.has_option(defSection, "port"): + port = confUser.get(defSection, "port") + if confUser.has_option(defSection, "password"): + password = confUser.get(defSection, "password") + + if paramServer: + host=paramServer + if paramUser: + user=paramUser + if paramPassword: + password=paramPassword + + print >>sys.stderr,"host = %s, user = %s, password = %s" % \ + (host,user,password) + + self.__login(host,user,password) + + def __login(self,server,user,password): + try: + self.store.connect(server,user,password) + except: + print >> sys.stderr, "Cannot connect to %s as %s with password %s" %\ + (server,user,password) + raise + + def archive(self): + inboxfolder = self.store.getDefaultFolder().getFolder("INBOX") + folderList=inboxfolder.list('*') + + for folder in folderList: + if folder.getFullName()[:len("INBOX/Archiv")] != "INBOX/Archiv": + archMsgsCnt = self.__archiveFolder(folder) + #folder.close(False) + print "Processed messages = %d" % archMsgsCnt + + def __archiveFolder(self,fld): + fld.open(Folder.READ_WRITE) + for msg in fld.getMessages(): + msgDate = __getMessageDate(msg) + print >>sys.stderr,str(msgDate),str(self._threeMonthAgo) + if msgDate < self._threeMonthAgo: + archFolder = self.__getArchiveFolderName(msg) +# print >> sys.stderr, archFolder +# fld.copyMessages(array([msg],type(msg)), archFolder) +# msg.setFlag(Flags.Flag.DELETED, true) + print "%s -> %s : %s" % (fld.getFullName(), + archFolder.getFullName(),msgDate) + folderLen = len(fld.getMessages()) + fld.close(False) + return(folderLen) + +if __name__=='__main__': + myStore = ArchivedStore(paramPassword="lubdkc") + myStore.archive() + myStore.store.close()
\ No newline at end of file diff --git a/previousAttempts/jython/purgeObsolete.py b/previousAttempts/jython/purgeObsolete.py new file mode 100644 index 0000000..4491eec --- /dev/null +++ b/previousAttempts/jython/purgeObsolete.py @@ -0,0 +1,151 @@ +# -*- coding: utf-8 -*- +# note http://docs.python.org/lib/module-doctest.html +# resp. file:///usr/share/doc/python-docs-*/html/lib/module-doctest.html +# for testing +from __future__ import division +from java.util import Properties, Date, GregorianCalendar, Locale +from java.text import SimpleDateFormat +from java.lang import System +from javax.mail import * +from javax.mail.search import * +from com.sun.mail.imap import IMAPFolder, IMAPSSLStore +from jarray import array +import sys, os +from datetime import date +import ConfigParser + +debug=False + +class SimpleDate(GregorianCalendar): + def __init__(self): + pass + + def getDate(): + return self.getTime() + + def decrease(self,howMuch,unit="m"): + pass + + def getMessageDate(msg): + """ + Return the date of the message + + @param msg analyzed message + @return GregorianCalendar of the messages date + @throws MessagingException + """ + dateMS = msg.getReceivedDate().getTime()//1000 + dateStruct = date.fromtimestamp(dateMS) + return dateStruct + +class ArchivedFolder(object): + def __init__(self,store,name): + self.folder = store.store.getDefaultFolder().getFolder(name) + self.folder.open(Folder.READ_WRITE) + + def purgeOld(self,dateLimit): + toBeDeleted = [] + for msg in self.folder.getMessages(): + flags = msg.getFlags() + if (__getMessageDate(msg) < dateLimit) and (flags.contains(Flags.Flag.SEEN)): + toBeDeleted.append(msg) + self.folder.setFlags(toBeDeleted,Flags.Flag.DELETED, true) + self.folder.expunge() + +class ArchivedStore(object): + """ + >>> myStore = ArchivedStore(paramServer="zimbra") + >>> folderList = myStore.store.getDefaultFolder().list("*") + >>> len(folderList)>0 + 1 + >>> myStore.store.close() + + and + >>> myStore = ArchivedStore(paramServer="zimbra") + >>> folder = ArchivedFolder(myStore,"INBOX/bugzilla/xgl") + >>> folder.folder.getMessageCount() > 0 + 1 + >>> myStore.store.close() + + """ + def __init__(self,paramServer="localhost",paramUser="",paramPassword="",maxageMonth=3): + self.props = System.getProperties() + self.session = Session.getInstance(self.props,None) + self.props.setProperty("javax.net.ssl.keyStore", "/home/matej/.keystore") + self.props.setProperty("javax.net.ssl.trustStore", "/home/matej/.keystore") + if debug: + self.session.setDebug(True) + try: + self.store = self.session.getStore("imaps") + except: + print >> sys.stderr, "Cannot get Store" + raise + + conffile = os.path.expanduser("~/.bugzillarc") + if paramServer: + config = ConfigParser.ConfigParser() + config.read([conffile]) + user,host,port,password = self.props.getProperty("user.name"),\ + "localhost",993,"" + + if config: + if config.has_section(paramServer): + if config.has_option(paramServer, "name"): + user = config.get(paramServer, "name") + if config.has_option(paramServer, "host"): + host = config.get(paramServer, "host") + if config.has_option(paramServer, "port"): + port = config.get(paramServer, "port") + if config.has_option(paramServer, "password"): + password = config.get(paramServer, "password") + + if paramUser: + user=paramUser + if paramPassword: + password=paramPassword + + if debug: + print >>sys.stderr,"host = %s, user = %s, password = %s" % \ + (host,user,password) + + self.__login(host,user,password) + + def __login(self,server,user,password): + try: + self.store.connect(server,user,password) + except: + print >> sys.stderr, "Cannot connect to %s as %s with password %s" %\ + (server,user,password) + raise + +def main(): + """ + >>> threeMonthAgo = date.today() + >>> JD3MAgo = GregorianCalendar(threeMonthAgo.year, + threeMonthAgo.month-1, + threeMonthAgo.day,0,0) + >>> formatter = SimpleDateFormat("yyyy-MM-dd",Locale.US); + >>> JD3MAgoStr = formatter.format(JD3MAgo.getTime()) + >>> str(threeMonthAgo)==JD3MAgoStr + 1 + """ + threeMonthAgo = date.today() + newmonth = threeMonthAgo.month-3 + threeMonthAgo = threeMonthAgo.replace(month=newmonth) + JD3MAgo = GregorianCalendar(threeMonthAgo.year, + threeMonthAgo.month-1, + threeMonthAgo.day,0,0).getTime() + + myStore = ArchivedStore(paramServer="zimbra") + folder = ArchivedFolder(myStore,"INBOX/bugzilla/xgl") + + unreadTerm = FlagTerm(Flags(Flags.Flag.SEEN),True) + dateTerm = ReceivedDateTerm(ComparisonTerm.LT,JD3MAgo) + searchTerm = AndTerm(unreadTerm,dateTerm) + msgsFound = folder.folder.search(searchTerm) + + print len(msgsFound) + myStore.store.close() + +if __name__=='__main__': + main() diff --git a/previousAttempts/jython/purgeObsoleteTest.py b/previousAttempts/jython/purgeObsoleteTest.py new file mode 100644 index 0000000..c4d1ec9 --- /dev/null +++ b/previousAttempts/jython/purgeObsoleteTest.py @@ -0,0 +1,43 @@ +# -*- coding: utf-8 -*- +from __future__ import division +import unittest + +class SimpleDateTest(unittest.TestCase): + def setUp(self): + from purgeObsolete import SimpleDate + + def runInnerTest(self): + threeMonthAgo = date.today() + JD3MAgo = GregorianCalendar(threeMonthAgo.year, + threeMonthAgo.month-1, + threeMonthAgo.day,0,0) + formatter = SimpleDateFormat("yyyy-MM-dd",Locale.US); + JD3MAgoStr = formatter.format(JD3MAgo.getTime()) + self.assertEqual(str(threeMonthAgo),JD3MAgoStr) + + def runTest(self): + pass + +class ArchivedStoreTest(unittest.TestCase): + def setUp(self): + from purgeObsolete import ArchivedStore + self.store = ArchivedStore(paramServer="zimbra") + + def tearDown(self): + self.store.store.close() + + def testConnect(self): + folderList = self.store.store.getDefaultFolder().list("*") + self.assertEqual(len(folderList)>0,True) + + def testOpeningFolder(self): + from purgeObsolete import ArchivedFolder + folder = ArchivedFolder(self.store,"INBOX/bugzilla/xgl") + self.assertEqual(folder.folder.getMessageCount() > 0,True) + + def runTest(self): + self.testConnect() + self.testOpeningFolder() + +if __name__=="__main__": + unittest.main() diff --git a/previousAttempts/jython/pydoctest.py b/previousAttempts/jython/pydoctest.py new file mode 100644 index 0000000..863be80 --- /dev/null +++ b/previousAttempts/jython/pydoctest.py @@ -0,0 +1,63 @@ +""" +This is the "example" module. + +The example module supplies one function, factorial(). For example, + +>>> factorial(5) +120 +""" + +def factorial(n): + """Return the factorial of n, an exact integer >= 0. + + If the result is small enough to fit in an int, return an int. + Else return a long. + + >>> [factorial(n) for n in range(6)] + [1, 1, 2, 6, 24, 120] + >>> [factorial(long(n)) for n in range(6)] + [1, 1, 2, 6, 24, 120] + >>> factorial(30) + 265252859812191058636308480000000L + >>> factorial(30L) + 265252859812191058636308480000000L + >>> factorial(-1) + Traceback (most recent call last): + ... + ValueError: n must be >= 0 + + Factorials of floats are OK, but the float must be an exact integer: + >>> factorial(30.1) + Traceback (most recent call last): + ... + ValueError: n must be exact integer + >>> factorial(30.0) + 265252859812191058636308480000000L + + It must also not be ridiculously large: + >>> factorial(1e100) + Traceback (most recent call last): + ... + OverflowError: n too large + """ + + import math + if not n >= 0: + raise ValueError("n must be >= 0") + if math.floor(n) != n: + raise ValueError("n must be exact integer") + if n+1 == n: # catch a value like 1e300 + raise OverflowError("n too large") + result = 1 + factor = 2 + while factor <= n: + result *= factor + factor += 1 + return result + +def _test(): + import doctest + doctest.testmod() + +if __name__ == "__main__": + _test() diff --git a/previousAttempts/perl/archiveIMAP.pl b/previousAttempts/perl/archiveIMAP.pl Binary files differnew file mode 100644 index 0000000..818dad9 --- /dev/null +++ b/previousAttempts/perl/archiveIMAP.pl diff --git a/previousAttempts/perl/expireIMAP.pl b/previousAttempts/perl/expireIMAP.pl Binary files differnew file mode 100644 index 0000000..873c275 --- /dev/null +++ b/previousAttempts/perl/expireIMAP.pl diff --git a/previousAttempts/perl/listFolders.pl b/previousAttempts/perl/listFolders.pl new file mode 100644 index 0000000..5be4bc6 --- /dev/null +++ b/previousAttempts/perl/listFolders.pl @@ -0,0 +1,23 @@ +#!/usr/bin/perl + +use strict; +use warnings; +use Mail::IMAPClient; +use Data::Dumper; + +my $msg; +my $hostname = "localhost"; +my $login = "matej"; +my $passwd = "lubdkc"; + +my $imap = Mail::IMAPClient->new(); +$imap = Mail::IMAPClient->new( + Server => $hostname, + User => $login, + Password => $passwd, + UID => 1 +) or die "Cannot connect to localhost as matej: $@"; + +print "\n===============================\n"; +my @folders = $imap->folders; +print join("\n",@folders),"\n";
\ No newline at end of file diff --git a/previousAttempts/perl/playWithImap.pl b/previousAttempts/perl/playWithImap.pl Binary files differnew file mode 100644 index 0000000..f062d73 --- /dev/null +++ b/previousAttempts/perl/playWithImap.pl |