commit e4be3727d9a3ba27dc2d67b7dcfdc07ae372e00d
Author: pancake@localhost.localdomain <unknown>
Date: Sat, 10 Oct 2009 14:47:14 +0200
* Initial import of 'dmc' into mercurial
Diffstat:
| README | | | 61 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
| doc/imap-rfc3501.txt | | | 4830 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
| doc/pop3-rfc1939.txt | | | 1291 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
| doc/smtp-rfc821.txt | | | 2707 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
| src/Makefile | | | 10 | ++++++++++ |
| src/dmc | | | 10 | ++++++++++ |
| src/imap4.c | | | 107 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
| src/pop3.c | | | 93 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
8 files changed, 9109 insertions(+), 0 deletions(-)
diff --git a/README b/README
@@ -0,0 +1,61 @@
+ +-----+---------------------+
+ | DMC | Dynamic Mail Client |
+ +-----+---------------------+
+
+Sending mails:
+--------------
+ dmc-smtp ~/mail/outbox/001.eml
+ [ $? = 0 ] && mv ~/mail/outbox/001.* ~/mail/sent/
+
+
+IMAP handling:
+--------------
+ Usage: dmc-imap [options] [host] [port] < commands > output
+ dmc-imap -a plain -d ~/mail [host] [port]
+
+ options:
+ -a : auth method
+ -d : base user mail directory
+
+ commands:
+ cd [folder]
+ # SELECT "folder"
+ 1003 [20:47:15] IMAP4> 51 SELECT "Sent Messages"
+ 1004 [20:47:15] IMAP4< * FLAGS (\Answered \Flagged \Deleted \Seen \Draft $Forwarded)
+ 1005 [20:47:15] IMAP4< * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft $Forwarded \*)] Flags permitted.
+ 1006 [20:47:15] IMAP4< * 340 EXISTS
+ 1007 [20:47:15] IMAP4< * 2 RECENT
+ 1008 [20:47:15] IMAP4< * OK [UIDVALIDITY 1230118148] UIDs valid
+ 1009 [20:47:15] IMAP4< * OK [UIDNEXT 341] Predicted next UID
+ 1010 [20:47:15] IMAP4< 51 OK [READ-WRITE] Select completed.
+
+ st : show status
+ 2508 [20:48:11] IMAP4> 60 STATUS "Spam.learn-ham" (MESSAGES UIDNEXT UIDVALIDITY UNSEEN)
+ 2509 [20:48:12] IMAP4< * STATUS "Spam.learn-ham" (MESSAGES 0 UIDNEXT 1 UIDVALIDITY 1211795420 UNSEEN 0)
+ 2510 [20:48:12] IMAP4< 60 OK Status completed.
+
+ ls [num] : list num mails (can be used to check for new mail)
+ cp = copy a mail from one folder to other
+ mv = copy+remove
+ rm = remove mail
+ lt = list folder tree
+
+LOGIN
+ Example: C: a001 LOGIN SMITH SESAME
+ S: a001 OK LOGIN completed
+SELECT
+ Example: C: A142 SELECT INBOX
+ S: * 172 EXISTS
+ S: * 1 RECENT
+ S: * OK [UNSEEN 12] Message 12 is first unseen
+ S: * OK [UIDVALIDITY 3857529045] UIDs valid
+ S: * OK [UIDNEXT 4392] Predicted next UID
+ S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
+ S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
+ S: A142 OK [READ-WRITE] SELECT completed
+CREATE
+ Example: C: A003 CREATE owatagusiam/
+ S: A003 OK CREATE completed
+ C: A004 CREATE owatagusiam/blurdybloop
+ S: A004 OK CREATE completed
+
diff --git a/doc/imap-rfc3501.txt b/doc/imap-rfc3501.txt
@@ -0,0 +1,4830 @@
+
+ [ _R_F_C_ _I_n_d_e_x | _R_F_C_ _S_e_a_r_c_h | _U_s_e_n_e_t_ _F_A_Q_s | _W_e_b_ _F_A_Q_s | _D_o_c_u_m_e_n_t_s | _C_i_t_i_e_s ]
+ AAlltteerrnnaattee FFoorrmmaattss:: _r_f_c_3_5_0_1_._t_x_t | _r_f_c_3_5_0_1_._t_x_t_._p_d_f
+ ******** RRFFCC 33550011 -- IINNTTEERRNNEETT MMEESSSSAAGGEE AACCCCEESSSS PPRROOTTOOCCOOLL -- VVEERRSSIIOONN 44rreevv11 ********
+===============================================================================
+ * SSeeaarrcchh tthhee AArrcchhiivveess DDiissppllaayy RRFFCC bbyy nnuummbbeerr
+ * [q [display ] [Display RFC By Number]
+ ] [Search RFCs]
+===============================================================================
+
+ ************ RRFFCC33550011 -- IINNTTEERRNNEETT MMEESSSSAAGGEE AACCCCEESSSS PPRROOTTOOCCOOLL -- VVEERRSSIIOONN 44rreevv11 ************
+
+Network Working Group M. Crispin
+Request for Comments: 3501 University of Washington
+Obsoletes: 2060 March 2003
+Category: Standards Track
+
+ INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+Abstract
+
+ The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1)
+ allows a client to access and manipulate electronic mail messages on
+ a server. IMAP4rev1 permits manipulation of mailboxes (remote
+ message folders) in a way that is functionally equivalent to local
+ folders. IMAP4rev1 also provides the capability for an offline
+ client to resynchronize with the server.
+
+ IMAP4rev1 includes operations for creating, deleting, and renaming
+ mailboxes, checking for new messages, permanently removing messages,
+ setting and clearing flags, _R_F_C_ _2_8_2_2 and _R_F_C_ _2_0_4_5 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 _R_F_C_ _2_2_4_4.
+
+ IMAP4rev1 does not specify a means of posting mail; this function is
+ handled by a mail transfer protocol such as _R_F_C_ _2_8_2_1.
+
+Table of Contents
+
+ IMAP4rev1 Protocol Specification ................................ 4
+ 1. How to Read This Document ............................... 4
+ 1.1. Organization of This Document ........................... 4
+ 1.2. Conventions Used in This Document ....................... 4
+ 1.3. Special Notes to Implementors ........................... 5
+ 2. Protocol Overview ....................................... 6
+ 2.1. Link Level .............................................. 6
+ 2.2. Commands and Responses .................................. 6
+ 2.2.1. Client Protocol Sender and Server Protocol Receiver ..... 6
+ 2.2.2. Server Protocol Sender and Client Protocol Receiver ..... 7
+ 2.3. Message Attributes ...................................... 8
+ 2.3.1. Message Numbers ......................................... 8
+ 2.3.1.1. Unique Identifier (UID) Message Attribute ....... 8
+ 2.3.1.2. Message Sequence Number Message Attribute ....... 10
+ 2.3.2. Flags Message Attribute ................................. 11
+ 2.3.3. Internal Date Message Attribute ......................... 12
+ 2.3.4. [_R_F_C_-_2_8_2_2] Size Message Attribute ....................... 12
+ 2.3.5. Envelope Structure Message Attribute .................... 12
+ 2.3.6. Body Structure Message Attribute ........................ 12
+ 2.4. Message Texts ........................................... 13
+ 3. State and Flow Diagram .................................. 13
+ 3.1. Not Authenticated State ................................. 13
+ 3.2. Authenticated State ..................................... 13
+ 3.3. Selected State .......................................... 13
+ 3.4. Logout State ............................................ 14
+ 4. Data Formats ............................................ 16
+ 4.1. Atom .................................................... 16
+ 4.2. Number .................................................. 16
+ 4.3. String .................................................. 16
+ 4.3.1. 8-bit and Binary Strings ................................ 17
+ 4.4. Parenthesized List ...................................... 17
+ 4.5. NIL ..................................................... 17
+ 5. Operational Considerations .............................. 18
+ 5.1. Mailbox Naming .......................................... 18
+ 5.1.1. Mailbox Hierarchy Naming ................................ 19
+ 5.1.2. Mailbox Namespace Naming Convention ..................... 19
+ 5.1.3. Mailbox International Naming Convention ................. 19
+ 5.2. Mailbox Size and Message Status Updates ................. 21
+ 5.3. Response when no Command in Progress .................... 21
+ 5.4. Autologout Timer ........................................ 22
+ 5.5. Multiple Commands in Progress ........................... 22
+ 6. Client Commands ........................................ 23
+ 6.1. Client Commands - Any State ............................ 24
+ 6.1.1. CAPABILITY Command ..................................... 24
+ 6.1.2. NOOP Command ........................................... 25
+ 6.1.3. LOGOUT Command ......................................... 26
+
+ 6.2. Client Commands - Not Authenticated State .............. 26
+ 6.2.1. STARTTLS Command ....................................... 27
+ 6.2.2. AUTHENTICATE Command ................................... 28
+ 6.2.3. LOGIN Command .......................................... 30
+ 6.3. Client Commands - Authenticated State .................. 31
+ 6.3.1. SELECT Command ......................................... 32
+ 6.3.2. EXAMINE Command ........................................ 34
+ 6.3.3. CREATE Command ......................................... 34
+ 6.3.4. DELETE Command ......................................... 35
+ 6.3.5. RENAME Command ......................................... 37
+ 6.3.6. SUBSCRIBE Command ...................................... 39
+ 6.3.7. UNSUBSCRIBE Command .................................... 39
+ 6.3.8. LIST Command ........................................... 40
+ 6.3.9. LSUB Command ........................................... 43
+ 6.3.10. STATUS Command ......................................... 44
+ 6.3.11. APPEND Command ......................................... 46
+ 6.4. Client Commands - Selected State ....................... 47
+ 6.4.1. CHECK Command .......................................... 47
+ 6.4.2. CLOSE Command .......................................... 48
+ 6.4.3. EXPUNGE Command ........................................ 49
+ 6.4.4. SEARCH Command ......................................... 49
+ 6.4.5. FETCH Command .......................................... 54
+ 6.4.6. STORE Command .......................................... 58
+ 6.4.7. COPY Command ........................................... 59
+ 6.4.8. UID Command ............................................ 60
+ 6.5. Client Commands - Experimental/Expansion ............... 62
+ 6.5.1. X<atom> Command ........................................ 62
+ 7. Server Responses ....................................... 62
+ 7.1. Server Responses - Status Responses .................... 63
+ 7.1.1. OK Response ............................................ 65
+ 7.1.2. NO Response ............................................ 66
+ 7.1.3. BAD Response ........................................... 66
+ 7.1.4. PREAUTH Response ....................................... 67
+ 7.1.5. BYE Response ........................................... 67
+ 7.2. Server Responses - Server and Mailbox Status ........... 68
+ 7.2.1. CAPABILITY Response .................................... 68
+ 7.2.2. LIST Response .......................................... 69
+ 7.2.3. LSUB Response .......................................... 70
+ 7.2.4 STATUS Response ........................................ 70
+ 7.2.5. SEARCH Response ........................................ 71
+ 7.2.6. FLAGS Response ......................................... 71
+ 7.3. Server Responses - Mailbox Size ........................ 71
+ 7.3.1. EXISTS Response ........................................ 71
+ 7.3.2. RECENT Response ........................................ 72
+ 7.4. Server Responses - Message Status ...................... 72
+ 7.4.1. EXPUNGE Response ....................................... 72
+ 7.4.2. FETCH Response ......................................... 73
+ 7.5. Server Responses - Command Continuation Request ........ 79
+
+ 8. Sample IMAP4rev1 connection ............................ 80
+ 9. Formal Syntax .......................................... 81
+ 10. Author's Note .......................................... 92
+ 11. Security Considerations ................................ 92
+ 11.1. STARTTLS Security Considerations ....................... 92
+ 11.2. Other Security Considerations .......................... 93
+ 12. IANA Considerations .................................... 94
+ Appendices ..................................................... 95
+ A. References ............................................. 95
+ B. Changes from _R_F_C_ _2_0_6_0 .................................. 97
+ C. Key Word Index ......................................... 103
+ Author's Address ............................................... 107
+ Full Copyright Statement ....................................... 108
+
+IMAP4rev1 Protocol Specification
+
+1. How to Read This Document
+
+1.1. Organization of This Document
+
+ This document is written from the point of view of the implementor of
+ an IMAP4rev1 client or server. Beyond the protocol overview in
+ section 2, it is not optimized for someone trying to understand the
+ operation of the protocol. The material in sections 3 through 5
+ provides the general context and definitions with which IMAP4rev1
+ operates.
+
+ Sections 6, 7, and 9 describe the IMAP commands, responses, and
+ syntax, respectively. The relationships among these are such that it
+ is almost impossible to understand any of them separately. In
+ particular, do not attempt to deduce command syntax from the command
+ section alone; instead refer to the Formal Syntax section.
+
+1.2. Conventions Used in This Document
+
+ "Conventions" are basic principles or procedures. Document
+ conventions are noted in this section.
+
+ In examples, "C:" and "S:" indicate lines sent by the client and
+ server respectively.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to
+ be interpreted as described in [KEYWORDS].
+
+ The word "can" (not "may") is used to refer to a possible
+ circumstance or situation, as opposed to an optional facility of the
+ protocol.
+
+ "User" is used to refer to a human user, whereas "client" refers to
+ the software being run by the user.
+
+ "Connection" refers to the entire sequence of client/server
+ interaction from the initial establishment of the network connection
+ until its termination.
+
+ "Session" refers to the sequence of client/server interaction from
+ the time that a mailbox is selected (SELECT or EXAMINE command) until
+ the time that selection ends (SELECT or EXAMINE of another mailbox,
+ CLOSE command, or connection termination).
+
+ Characters are 7-bit US-ASCII unless otherwise specified. Other
+ character sets are indicated using a "CHARSET", as described in
+ [MIME-IMT] and defined in [CHARSET]. CHARSETs have important
+ additional semantics in addition to defining character set; refer to
+ these documents for more detail.
+
+ There are several protocol conventions in IMAP. These refer to
+ aspects of the specification which are not strictly part of the IMAP
+ protocol, but reflect generally-accepted practice. Implementations
+ need to be aware of these conventions, and avoid conflicts whether or
+ not they implement the convention. For example, "&" may not be used
+ as a hierarchy delimiter since it conflicts with the Mailbox
+ International Naming Convention, and other uses of "&" in mailbox
+ names are impacted as well.
+
+1.3. Special Notes to Implementors
+
+ Implementors of the IMAP protocol are strongly encouraged to read the
+ IMAP implementation recommendations document [IMAP-IMPLEMENTATION] in
+ conjunction with this document, to help understand the intricacies of
+ this protocol and how best to build an interoperable product.
+
+ IMAP4rev1 is designed to be upwards compatible from the [IMAP2] and
+ unpublished IMAP2bis protocols. IMAP4rev1 is largely compatible with
+ the IMAP4 protocol described in _R_F_C_ _1_7_3_0; the exception being in
+ certain facilities added in _R_F_C_ _1_7_3_0 that proved problematic and were
+ subsequently removed. In the course of the evolution of IMAP4rev1,
+ some aspects in the earlier protocols have become obsolete. Obsolete
+ commands, responses, and data formats which an IMAP4rev1
+ implementation can encounter when used with an earlier implementation
+ are described in [IMAP-OBSOLETE].
+
+ Other compatibility issues with IMAP2bis, the most common variant of
+ the earlier protocol, are discussed in [IMAP-COMPAT]. A full
+ discussion of compatibility issues with rare (and presumed extinct)
+
+ variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is
+ primarily of historical interest.
+
+ IMAP was originally developed for the older [_R_F_C_-_8_2_2] standard, and
+ as a consequence several fetch items in IMAP incorporate "_R_F_C_8_2_2" in
+ their name. With the exception of _R_F_C_8_2_2.SIZE, there are more modern
+ replacements; for example, the modern version of _R_F_C_8_2_2.HEADER is
+ BODY.PEEK[HEADER]. In all cases, "_R_F_C_8_2_2" should be interpreted as a
+ reference to the updated [_R_F_C_-_2_8_2_2] standard.
+
+2. Protocol Overview
+
+2.1. Link Level
+
+ The IMAP4rev1 protocol assumes a reliable data stream such as that
+ provided by TCP. When TCP is used, an IMAP4rev1 server listens on
+ port 143.
+
+2.2. Commands and Responses
+
+ An IMAP4rev1 connection consists of the establishment of a
+ client/server network connection, an initial greeting from the
+ server, and client/server interactions. These client/server
+ interactions consist of a client command, server data, and a server
+ completion result response.
+
+ All interactions transmitted by client and server are in the form of
+ lines, that is, strings that end with a CRLF. The protocol receiver
+ of an IMAP4rev1 client or server is either reading a line, or is
+ reading a sequence of octets with a known count followed by a line.
+
+2.2.1. Client Protocol Sender and Server Protocol Receiver
+
+ The client command begins an operation. Each client command is
+ prefixed with an identifier (typically a short alphanumeric string,
+ e.g., A0001, A0002, etc.) called a "tag". A different tag is
+ generated by the client for each command.
+
+ Clients MUST follow the syntax outlined in this specification
+ strictly. It is a syntax error to send a command with missing or
+ extraneous spaces or arguments.
+
+ There are two cases in which a line from the client does not
+ represent a complete command. In one case, a command argument is
+ quoted with an octet count (see the description of literal in String
+ under Data Formats); in the other case, the command arguments require
+ server feedback (see the AUTHENTICATE command). In either case, the
+
+ server sends a command continuation request response if it is ready
+ for the octets (if appropriate) and the remainder of the command.
+ This response is prefixed with the token "+".
+
+ Note: If instead, the server detected an error in the
+ command, it sends a BAD completion response with a tag
+ matching the command (as described below) to reject the
+ command and prevent the client from sending any more of the
+ command.
+
+ It is also possible for the server to send a completion
+ response for some other command (if multiple commands are
+ in progress), or untagged data. In either case, the
+ command continuation request is still pending; the client
+ takes the appropriate action for the response, and reads
+ another response from the server. In all cases, the client
+ MUST send a complete command (including receiving all
+ command continuation request responses and command
+ continuations for the command) before initiating a new
+ command.
+
+ The protocol receiver of an IMAP4rev1 server reads a command line
+ from the client, parses the command and its arguments, and transmits
+ server data and a server command completion result response.
+
+2.2.2. Server Protocol Sender and Client Protocol Receiver
+
+ Data transmitted by the server to the client and status responses
+ that do not indicate command completion are prefixed with the token
+ "*", and are called untagged responses.
+
+ Server data MAY be sent as a result of a client command, or MAY be
+ sent unilaterally by the server. There is no syntactic difference
+ between server data that resulted from a specific command and server
+ data that were sent unilaterally.
+
+ The server completion result response indicates the success or
+ failure of the operation. It is tagged with the same tag as the
+ client command which began the operation. Thus, if more than one
+ command is in progress, the tag in a server completion response
+ identifies the command to which the response applies. There are
+ three possible server completion responses: OK (indicating success),
+ NO (indicating failure), or BAD (indicating a protocol error such as
+ unrecognized command or command syntax error).
+
+ Servers SHOULD enforce the syntax outlined in this specification
+ strictly. Any client command with a protocol syntax error, including
+ (but not limited to) missing or extraneous spaces or arguments,
+
+ SHOULD be rejected, and the client given a BAD server completion
+ response.
+
+ The protocol receiver of an IMAP4rev1 client reads a response line
+ from the server. It then takes action on the response based upon the
+ first token of the response, which can be a tag, a "*", or a "+".
+
+ A client MUST be prepared to accept any server response at all times.
+ This includes server data that was not requested. Server data SHOULD
+ be recorded, so that the client can reference its recorded copy
+ rather than sending a command to the server to request the data. In
+ the case of certain server data, the data MUST be recorded.
+
+ This topic is discussed in greater detail in the Server Responses
+ section.
+
+2.3. Message Attributes
+
+ In addition to message text, each message has several attributes
+ associated with it. These attributes can be retrieved individually
+ or in conjunction with other attributes or message texts.
+
+2.3.1. Message Numbers
+
+ Messages in IMAP4rev1 are accessed by one of two numbers; the unique
+ identifier or the message sequence number.
+
+2.3.1.1. Unique Identifier (UID) Message Attribute
+
+ A 32-bit value assigned to each message, which when used with the
+ unique identifier validity value (see below) forms a 64-bit value
+ that MUST NOT refer to any other message in the mailbox or any
+ subsequent mailbox with the same name forever. Unique identifiers
+ are assigned in a strictly ascending fashion in the mailbox; as each
+ message is added to the mailbox it is assigned a higher UID than the
+ message(s) which were added previously. Unlike message sequence
+ numbers, unique identifiers are not necessarily contiguous.
+
+ The unique identifier of a message MUST NOT change during the
+ session, and SHOULD NOT change between sessions. Any change of
+ unique identifiers between sessions MUST be detectable using the
+ UIDVALIDITY mechanism discussed below. Persistent unique identifiers
+ are required for a client to resynchronize its state from a previous
+ session with the server (e.g., disconnected or offline access
+ clients); this is discussed further in [IMAP-DISC].
+
+ Associated with every mailbox are two values which aid in unique
+ identifier handling: the next unique identifier value and the unique
+ identifier validity value.
+
+ The next unique identifier value is the predicted value that will be
+ assigned to a new message in the mailbox. Unless the unique
+ identifier validity also changes (see below), the next unique
+ identifier value MUST have the following two characteristics. First,
+ the next unique identifier value MUST NOT change unless new messages
+ are added to the mailbox; and second, the next unique identifier
+ value MUST change whenever new messages are added to the mailbox,
+ even if those new messages are subsequently expunged.
+
+ Note: The next unique identifier value is intended to
+ provide a means for a client to determine whether any
+ messages have been delivered to the mailbox since the
+ previous time it checked this value. It is not intended to
+ provide any guarantee that any message will have this
+ unique identifier. A client can only assume, at the time
+ that it obtains the next unique identifier value, that
+ messages arriving after that time will have a UID greater
+ than or equal to that value.
+
+ The unique identifier validity value is sent in a UIDVALIDITY
+ response code in an OK untagged response at mailbox selection time.
+ If unique identifiers from an earlier session fail to persist in this
+ session, the unique identifier validity value MUST be greater than
+ the one used in the earlier session.
+
+ Note: Ideally, unique identifiers SHOULD persist at all
+ times. Although this specification recognizes that failure
+ to persist can be unavoidable in certain server
+ environments, it STRONGLY ENCOURAGES message store
+ implementation techniques that avoid this problem. For
+ example:
+
+ 1) Unique identifiers MUST be strictly ascending in the
+ mailbox at all times. If the physical message store is
+ re-ordered by a non-IMAP agent, this requires that the
+ unique identifiers in the mailbox be regenerated, since
+ the former unique identifiers are no longer strictly
+ ascending as a result of the re-ordering.
+
+ 2) If the message store has no mechanism to store unique
+ identifiers, it must regenerate unique identifiers at
+ each session, and each session must have a unique
+ UIDVALIDITY value.
+
+ 3) If the mailbox is deleted and a new mailbox with the
+ same name is created at a later date, the server must
+ either keep track of unique identifiers from the
+ previous instance of the mailbox, or it must assign a
+ new UIDVALIDITY value to the new instance of the
+ mailbox. A good UIDVALIDITY value to use in this case
+ is a 32-bit representation of the creation date/time of
+ the mailbox. It is alright to use a constant such as
+ 1, but only if it guaranteed that unique identifiers
+ will never be reused, even in the case of a mailbox
+ being deleted (or renamed) and a new mailbox by the
+ same name created at some future time.
+
+ 4) The combination of mailbox name, UIDVALIDITY, and UID
+ must refer to a single immutable message on that server
+ forever. In particular, the internal date, [_R_F_C_-_2_8_2_2]
+ size, envelope, body structure, and message texts
+ (_R_F_C_8_2_2, _R_F_C_8_2_2.HEADER, _R_F_C_8_2_2.TEXT, and all BODY[...]
+ fetch data items) must never change. This does not
+ include message numbers, nor does it include attributes
+ that can be set by a STORE command (e.g., FLAGS).
+
+2.3.1.2. Message Sequence Number Message Attribute
+
+ A relative position from 1 to the number of messages in the mailbox.
+ This position MUST be ordered by ascending unique identifier. As
+ each new message is added, it is assigned a message sequence number
+ that is 1 higher than the number of messages in the mailbox before
+ that new message was added.
+
+ Message sequence numbers can be reassigned during the session. For
+ example, when a message is permanently removed (expunged) from the
+ mailbox, the message sequence number for all subsequent messages is
+ decremented. The number of messages in the mailbox is also
+ decremented. Similarly, a new message can be assigned a message
+ sequence number that was once held by some other message prior to an
+ expunge.
+
+ In addition to accessing messages by relative position in the
+ mailbox, message sequence numbers can be used in mathematical
+ calculations. For example, if an untagged "11 EXISTS" is received,
+ and previously an untagged "8 EXISTS" was received, three new
+ messages have arrived with message sequence numbers of 9, 10, and 11.
+ Another example, if message 287 in a 523 message mailbox has UID
+ 12345, there are exactly 286 messages which have lesser UIDs and 236
+ messages which have greater UIDs.
+
+2.3.2. Flags Message Attribute
+
+ A list of zero or more named tokens associated with the message. A
+ flag is set by its addition to this list, and is cleared by its
+ removal. There are two types of flags in IMAP4rev1. A flag of
+ either type can be permanent or session-only.
+
+ A system flag is a flag name that is pre-defined in this
+ specification. All system flags begin with "\". Certain system
+ flags (\Deleted and \Seen) have special semantics described
+ elsewhere. The currently-defined system flags are:
+
+ \Seen
+ Message has been read
+
+ \Answered
+ Message has been answered
+
+ \Flagged
+ Message is "flagged" for urgent/special attention
+
+ \Deleted
+ Message is "deleted" for removal by later EXPUNGE
+
+ \Draft
+ Message has not completed composition (marked as a draft).
+
+ \Recent
+ Message is "recently" arrived in this mailbox. This session
+ is the first session to have been notified about this
+ message; if the session is read-write, subsequent sessions
+ will not see \Recent set for this message. This flag can not
+ be altered by the client.
+
+ If it is not possible to determine whether or not this
+ session is the first session to be notified about a message,
+ then that message SHOULD be considered recent.
+
+ If multiple connections have the same mailbox selected
+ simultaneously, it is undefined which of these connections
+ will see newly-arrived messages with \Recent set and which
+ will see it without \Recent set.
+
+ A keyword is defined by the server implementation. Keywords do not
+ begin with "\". Servers MAY permit the client to define new keywords
+ in the mailbox (see the description of the PERMANENTFLAGS response
+ code for more information).
+
+ A flag can be permanent or session-only on a per-flag basis.
+ Permanent flags are those which the client can add or remove from the
+ message flags permanently; that is, concurrent and subsequent
+ sessions will see any change in permanent flags. Changes to session
+ flags are valid only in that session.
+
+ Note: The \Recent system flag is a special case of a
+ session flag. \Recent can not be used as an argument in a
+ STORE or APPEND command, and thus can not be changed at
+ all.
+
+2.3.3. Internal Date Message Attribute
+
+ The internal date and time of the message on the server. This
+ is not the date and time in the [_R_F_C_-_2_8_2_2] header, but rather a
+ date and time which reflects when the message was received. In
+ the case of messages delivered via [SMTP], this SHOULD be the
+ date and time of final delivery of the message as defined by
+ [SMTP]. In the case of messages delivered by the IMAP4rev1 COPY
+ command, this SHOULD be the internal date and time of the source
+ message. In the case of messages delivered by the IMAP4rev1
+ APPEND command, this SHOULD be the date and time as specified in
+ the APPEND command description. All other cases are
+ implementation defined.
+
+2.3.4. [_R_F_C_-_2_8_2_2] Size Message Attribute
+
+ The number of octets in the message, as expressed in [_R_F_C_-_2_8_2_2]
+ format.
+
+2.3.5. Envelope Structure Message Attribute
+
+ A parsed representation of the [_R_F_C_-_2_8_2_2] header of the message.
+ Note that the IMAP Envelope structure is not the same as an
+ [SMTP] envelope.
+
+2.3.6. Body Structure Message Attribute
+
+ A parsed representation of the [MIME-IMB] body structure
+ information of the message.
+
+2.4. Message Texts
+
+ In addition to being able to fetch the full [_R_F_C_-_2_8_2_2] text of a
+ message, IMAP4rev1 permits the fetching of portions of the full
+ message text. Specifically, it is possible to fetch the
+ [_R_F_C_-_2_8_2_2] message header, [_R_F_C_-_2_8_2_2] message body, a [MIME-IMB]
+ body part, or a [MIME-IMB] header.
+
+3. State and Flow Diagram
+
+ Once the connection between client and server is established, an
+ IMAP4rev1 connection is in one of four states. The initial
+ state is identified in the server greeting. Most commands are
+ only valid in certain states. It is a protocol error for the
+ client to attempt a command while the connection is in an
+ inappropriate state, and the server will respond with a BAD or
+ NO (depending upon server implementation) command completion
+ result.
+
+3.1. Not Authenticated State
+
+ In the not authenticated state, the client MUST supply
+ authentication credentials before most commands will be
+ permitted. This state is entered when a connection starts
+ unless the connection has been pre-authenticated.
+
+3.2. Authenticated State
+
+ In the authenticated state, the client is authenticated and MUST
+ select a mailbox to access before commands that affect messages
+ will be permitted. This state is entered when a
+ pre-authenticated connection starts, when acceptable
+ authentication credentials have been provided, after an error in
+ selecting a mailbox, or after a successful CLOSE command.
+
+3.3. Selected State
+
+ In a selected state, a mailbox has been selected to access.
+ This state is entered when a mailbox has been successfully
+ selected.
+
+3.4. Logout State
+
+ In the logout state, the connection is being terminated. This
+ state can be entered as a result of a client request (via the
+ LOGOUT command) or by unilateral action on the part of either
+ the client or server.
+
+ If the client requests the logout state, the server MUST send an
+ untagged BYE response and a tagged OK response to the LOGOUT
+ command before the server closes the connection; and the client
+ MUST read the tagged OK response to the LOGOUT command before
+ the client closes the connection.
+
+ A server MUST NOT unilaterally close the connection without
+ sending an untagged BYE response that contains the reason for
+ having done so. A client SHOULD NOT unilaterally close the
+ connection, and instead SHOULD issue a LOGOUT command. If the
+ server detects that the client has unilaterally closed the
+ connection, the server MAY omit the untagged BYE response and
+ simply close its connection.
+
+ +----------------------+
+ |connection established|
+ +----------------------+
+ ||
+ \/
+ +--------------------------------------+
+ | server greeting |
+ +--------------------------------------+
+ || (1) || (2) || (3)
+ \/ || ||
+ +-----------------+ || ||
+ |Not Authenticated| || ||
+ +-----------------+ || ||
+ || (7) || (4) || ||
+ || \/ \/ ||
+ || +----------------+ ||
+ || | Authenticated |<=++ ||
+ || +----------------+ || ||
+ || || (7) || (5) || (6) ||
+ || || \/ || ||
+ || || +--------+ || ||
+ || || |Selected|==++ ||
+ || || +--------+ ||
+ || || || (7) ||
+ \/ \/ \/ \/
+ +--------------------------------------+
+ | Logout |
+ +--------------------------------------+
+ ||
+ \/
+ +-------------------------------+
+ |both sides close the connection|
+ +-------------------------------+
+
+ (1) connection without pre-authentication (OK greeting)
+ (2) pre-authenticated connection (PREAUTH greeting)
+ (3) rejected connection (BYE greeting)
+ (4) successful LOGIN or AUTHENTICATE command
+ (5) successful SELECT or EXAMINE command
+ (6) CLOSE command, or failed SELECT or EXAMINE command
+ (7) LOGOUT command, server shutdown, or connection closed
+
+4. Data Formats
+
+ IMAP4rev1 uses textual commands and responses. Data in
+ IMAP4rev1 can be in one of several forms: atom, number, string,
+ parenthesized list, or NIL. Note that a particular data item
+ may take more than one form; for example, a data item defined as
+ using "astring" syntax may be either an atom or a string.
+
+4.1. Atom
+
+ An atom consists of one or more non-special characters.
+
+4.2. Number
+
+ A number consists of one or more digit characters, and
+ represents a numeric value.
+
+4.3. String
+
+ A string is in one of two forms: either literal or quoted
+ string. The literal form is the general form of string. The
+ quoted string form is an alternative that avoids the overhead of
+ processing a literal at the cost of limitations of characters
+ which may be used.
+
+ A literal is a sequence of zero or more octets (including CR and
+ LF), prefix-quoted with an octet count in the form of an open
+ brace ("{"), the number of octets, close brace ("}"), and CRLF.
+ In the case of literals transmitted from server to client, the
+ CRLF is immediately followed by the octet data. In the case of
+ literals transmitted from client to server, the client MUST wait
+ to receive a command continuation request (described later in
+ this document) before sending the octet data (and the remainder
+ of the command).
+
+ A quoted string is a sequence of zero or more 7-bit characters,
+ excluding CR and LF, with double quote (<">) characters at each
+ end.
+
+ The empty string is represented as either "" (a quoted string
+ with zero characters between double quotes) or as {0} followed
+ by CRLF (a literal with an octet count of 0).
+
+ Note: Even if the octet count is 0, a client transmitting a
+ literal MUST wait to receive a command continuation request.
+
+4.3.1. 8-bit and Binary Strings
+
+ 8-bit textual and binary mail is supported through the use of a
+ [MIME-IMB] content transfer encoding. IMAP4rev1 implementations MAY
+ transmit 8-bit or multi-octet characters in literals, but SHOULD do
+ so only when the [CHARSET] is identified.
+
+ Although a BINARY body encoding is defined, unencoded binary strings
+ are not permitted. A "binary string" is any string with NUL
+ characters. Implementations MUST encode binary data into a textual
+ form, such as BASE64, before transmitting the data. A string with an
+ excessive amount of CTL characters MAY also be considered to be
+ binary.
+
+4.4. Parenthesized List
+
+ Data structures are represented as a "parenthesized list"; a sequence
+ of data items, delimited by space, and bounded at each end by
+ parentheses. A parenthesized list can contain other parenthesized
+ lists, using multiple levels of parentheses to indicate nesting.
+
+ The empty list is represented as () -- a parenthesized list with no
+ members.
+
+4.5. NIL
+
+ The special form "NIL" represents the non-existence of a particular
+ data item that is represented as a string or parenthesized list, as
+ distinct from the empty string "" or the empty parenthesized list ().
+
+ Note: NIL is never used for any data item which takes the
+ form of an atom. For example, a mailbox name of "NIL" is a
+ mailbox named NIL as opposed to a non-existent mailbox
+ name. This is because mailbox uses "astring" syntax which
+ is an atom or a string. Conversely, an addr-name of NIL is
+ a non-existent personal name, because addr-name uses
+ "nstring" syntax which is NIL or a string, but never an
+ atom.
+
+5. Operational Considerations
+
+ The following rules are listed here to ensure that all IMAP4rev1
+ implementations interoperate properly.
+
+5.1. Mailbox Naming
+
+ Mailbox names are 7-bit. Client implementations MUST NOT attempt to
+ create 8-bit mailbox names, and SHOULD interpret any 8-bit mailbox
+ names returned by LIST or LSUB as UTF-8. Server implementations
+ SHOULD prohibit the creation of 8-bit mailbox names, and SHOULD NOT
+ return 8-bit mailbox names in LIST or LSUB. See section 5.1.3 for
+ more information on how to represent non-ASCII mailbox names.
+
+ Note: 8-bit mailbox names were undefined in earlier
+ versions of this protocol. Some sites used a local 8-bit
+ character set to represent non-ASCII mailbox names. Such
+ usage is not interoperable, and is now formally deprecated.
+
+ The case-insensitive mailbox name INBOX is a special name reserved to
+ mean "the primary mailbox for this user on this server". The
+ interpretation of all other names is implementation-dependent.
+
+ In particular, this specification takes no position on case
+ sensitivity in non-INBOX mailbox names. Some server implementations
+ are fully case-sensitive; others preserve case of a newly-created
+ name but otherwise are case-insensitive; and yet others coerce names
+ to a particular case. Client implementations MUST interact with any
+ of these. If a server implementation interprets non-INBOX mailbox
+ names as case-insensitive, it MUST treat names using the
+ international naming convention specially as described in section
+ 5.1.3.
+
+ There are certain client considerations when creating a new mailbox
+ name:
+
+ 1) Any character which is one of the atom-specials (see the Formal
+ Syntax) will require that the mailbox name be represented as a
+ quoted string or literal.
+
+ 2) CTL and other non-graphic characters are difficult to represent
+ in a user interface and are best avoided.
+
+ 3) Although the list-wildcard characters ("%" and "*") are valid
+ in a mailbox name, it is difficult to use such mailbox names
+ with the LIST and LSUB commands due to the conflict with
+ wildcard interpretation.
+
+ 4) Usually, a character (determined by the server implementation)
+ is reserved to delimit levels of hierarchy.
+
+ 5) Two characters, "#" and "&", have meanings by convention, and
+ should be avoided except when used in that convention.
+
+5.1.1. Mailbox Hierarchy Naming
+
+ If it is desired to export hierarchical mailbox names, mailbox names
+ MUST be left-to-right hierarchical using a single character to
+ separate levels of hierarchy. The same hierarchy separator character
+ is used for all levels of hierarchy within a single name.
+
+5.1.2. Mailbox Namespace Naming Convention
+
+ By convention, the first hierarchical element of any mailbox name
+ which begins with "#" identifies the "namespace" of the remainder of
+ the name. This makes it possible to disambiguate between different
+ types of mailbox stores, each of which have their own namespaces.
+
+ For example, implementations which offer access to USENET
+ newsgroups MAY use the "#news" namespace to partition the
+ USENET newsgroup namespace from that of other mailboxes.
+ Thus, the comp.mail.misc newsgroup would have a mailbox
+ name of "#news.comp.mail.misc", and the name
+ "comp.mail.misc" can refer to a different object (e.g., a
+ user's private mailbox).
+
+5.1.3. Mailbox International Naming Convention
+
+ By convention, international mailbox names in IMAP4rev1 are specified
+ using a modified version of the UTF-7 encoding described in [UTF-7].
+ Modified UTF-7 may also be usable in servers that implement an
+ earlier version of this protocol.
+
+ In modified UTF-7, printable US-ASCII characters, except for "&",
+ represent themselves; that is, characters with octet values 0x20-0x25
+ and 0x27-0x7e. The character "&" (0x26) is represented by the
+ two-octet sequence "&-".
+
+ All other characters (octet values 0x00-0x1f and 0x7f-0xff) are
+ represented in modified BASE64, with a further modification from
+ [UTF-7] that "," is used instead of "/". Modified BASE64 MUST NOT be
+ used to represent any printing US-ASCII character which can represent
+ itself.
+
+ "&" is used to shift to modified BASE64 and "-" to shift back to
+ US-ASCII. There is no implicit shift from BASE64 to US-ASCII, and
+ null shifts ("-&" while in BASE64; note that "&-" while in US-ASCII
+ means "&") are not permitted. However, all names start in US-ASCII,
+ and MUST end in US-ASCII; that is, a name that ends with a non-ASCII
+ ISO-10646 character MUST end with a "-").
+
+ The purpose of these modifications is to correct the following
+ problems with UTF-7:
+
+ 1) UTF-7 uses the "+" character for shifting; this conflicts with
+ the common use of "+" in mailbox names, in particular USENET
+ newsgroup names.
+
+ 2) UTF-7's encoding is BASE64 which uses the "/" character; this
+ conflicts with the use of "/" as a popular hierarchy delimiter.
+
+ 3) UTF-7 prohibits the unencoded usage of "\"; this conflicts with
+ the use of "\" as a popular hierarchy delimiter.
+
+ 4) UTF-7 prohibits the unencoded usage of "~"; this conflicts with
+ the use of "~" in some servers as a home directory indicator.
+
+ 5) UTF-7 permits multiple alternate forms to represent the same
+ string; in particular, printable US-ASCII characters can be
+ represented in encoded form.
+
+ Although modified UTF-7 is a convention, it establishes certain
+ requirements on server handling of any mailbox name with an
+ embedded "&" character. In particular, server implementations
+ MUST preserve the exact form of the modified BASE64 portion of a
+ modified UTF-7 name and treat that text as case-sensitive, even if
+ names are otherwise case-insensitive or case-folded.
+
+ Server implementations SHOULD verify that any mailbox name with an
+ embedded "&" character, used as an argument to CREATE, is: in the
+ correctly modified UTF-7 syntax, has no superfluous shifts, and
+ has no encoding in modified BASE64 of any printing US-ASCII
+ character which can represent itself. However, client
+ implementations MUST NOT depend upon the server doing this, and
+ SHOULD NOT attempt to create a mailbox name with an embedded "&"
+ character unless it complies with the modified UTF-7 syntax.
+
+ Server implementations which export a mail store that does not
+ follow the modified UTF-7 convention MUST convert to modified
+ UTF-7 any mailbox name that contains either non-ASCII characters
+ or the "&" character.
+
+ For example, here is a mailbox name which mixes English,
+ Chinese, and Japanese text:
+ ~peter/mail/&U,BTFw-/&ZeVnLIqe-
+
+ For example, the string "&Jjo!" is not a valid mailbox
+ name because it does not contain a shift to US-ASCII
+ before the "!". The correct form is "&Jjo-!". The
+ string "&U,BTFw-&ZeVnLIqe-" is not permitted because it
+ contains a superfluous shift. The correct form is
+ "&U,BTF2XlZyyKng-".
+
+5.2. Mailbox Size and Message Status Updates
+
+ At any time, a server can send data that the client did not request.
+ Sometimes, such behavior is REQUIRED. For example, agents other than
+ the server MAY add messages to the mailbox (e.g., new message
+ delivery), change the flags of the messages in the mailbox (e.g.,
+ simultaneous access to the same mailbox by multiple agents), or even
+ remove messages from the mailbox. A server MUST send mailbox size
+ updates automatically if a mailbox size change is observed during the
+ processing of a command. A server SHOULD send message flag updates
+ automatically, without requiring the client to request such updates
+ explicitly.
+
+ Special rules exist for server notification of a client about the
+ removal of messages to prevent synchronization errors; see the
+ description of the EXPUNGE response for more detail. In particular,
+ it is NOT permitted to send an EXISTS response that would reduce the
+ number of messages in the mailbox; only the EXPUNGE response can do
+ this.
+
+ Regardless of what implementation decisions a client makes on
+ remembering data from the server, a client implementation MUST record
+ mailbox size updates. It MUST NOT assume that any command after the
+ initial mailbox selection will return the size of the mailbox.
+
+5.3. Response when no Command in Progress
+
+ Server implementations are permitted to send an untagged response
+ (except for EXPUNGE) while there is no command in progress. Server
+ implementations that send such responses MUST deal with flow control
+ considerations. Specifically, they MUST either (1) verify that the
+ size of the data does not exceed the underlying transport's available
+ window size, or (2) use non-blocking writes.
+
+5.4. Autologout Timer
+
+ If a server has an inactivity autologout timer, the duration of that
+ timer MUST be at least 30 minutes. The receipt of ANY command from
+ the client during that interval SHOULD suffice to reset the
+ autologout timer.
+
+5.5. Multiple Commands in Progress
+
+ The client MAY send another command without waiting for the
+ completion result response of a command, subject to ambiguity rules
+ (see below) and flow control constraints on the underlying data
+ stream. Similarly, a server MAY begin processing another command
+ before processing the current command to completion, subject to
+ ambiguity rules. However, any command continuation request responses
+ and command continuations MUST be negotiated before any subsequent
+ command is initiated.
+
+ The exception is if an ambiguity would result because of a command
+ that would affect the results of other commands. Clients MUST NOT
+ send multiple commands without waiting if an ambiguity would result.
+ If the server detects a possible ambiguity, it MUST execute commands
+ to completion in the order given by the client.
+
+ The most obvious example of ambiguity is when a command would affect
+ the results of another command, e.g., a FETCH of a message's flags
+ and a STORE of that same message's flags.
+
+ A non-obvious ambiguity occurs with commands that permit an untagged
+ EXPUNGE response (commands other than FETCH, STORE, and SEARCH),
+ since an untagged EXPUNGE response can invalidate sequence numbers in
+ a subsequent command. This is not a problem for FETCH, STORE, or
+ SEARCH commands because servers are prohibited from sending EXPUNGE
+ responses while any of those commands are in progress. Therefore, if
+ the client sends any command other than FETCH, STORE, or SEARCH, it
+ MUST wait for the completion result response before sending a command
+ with message sequence numbers.
+
+ Note: UID FETCH, UID STORE, and UID SEARCH are different
+ commands from FETCH, STORE, and SEARCH. If the client
+ sends a UID command, it must wait for a completion result
+ response before sending a command with message sequence
+ numbers.
+
+ For example, the following non-waiting command sequences are invalid:
+
+ FETCH + NOOP + STORE
+ STORE + COPY + FETCH
+ COPY + COPY
+ CHECK + FETCH
+
+ The following are examples of valid non-waiting command sequences:
+
+ FETCH + STORE + SEARCH + CHECK
+ STORE + COPY + EXPUNGE
+
+ UID SEARCH + UID SEARCH may be valid or invalid as a non-waiting
+ command sequence, depending upon whether or not the second UID
+ SEARCH contains message sequence numbers.
+
+6. Client Commands
+
+ IMAP4rev1 commands are described in this section. Commands are
+ organized by the state in which the command is permitted. Commands
+ which are permitted in multiple states are listed in the minimum
+ permitted state (for example, commands valid in authenticated and
+ selected state are listed in the authenticated state commands).
+
+ Command arguments, identified by "Arguments:" in the command
+ descriptions below, are described by function, not by syntax. The
+ precise syntax of command arguments is described in the Formal Syntax
+ section.
+
+ Some commands cause specific server responses to be returned; these
+ are identified by "Responses:" in the command descriptions below.
+ See the response descriptions in the Responses section for
+ information on these responses, and the Formal Syntax section for the
+ precise syntax of these responses. It is possible for server data to
+ be transmitted as a result of any command. Thus, commands that do
+ not specifically require server data specify "no specific responses
+ for this command" instead of "none".
+
+ The "Result:" in the command description refers to the possible
+ tagged status responses to a command, and any special interpretation
+ of these status responses.
+
+ The state of a connection is only changed by successful commands
+ which are documented as changing state. A rejected command (BAD
+ response) never changes the state of the connection or of the
+ selected mailbox. A failed command (NO response) generally does not
+ change the state of the connection or of the selected mailbox; the
+ exception being the SELECT and EXAMINE commands.
+
+6.1. Client Commands - Any State
+
+ The following commands are valid in any state: CAPABILITY, NOOP, and
+ LOGOUT.
+
+6.1.1. CAPABILITY Command
+
+ Arguments: none
+
+ Responses: REQUIRED untagged response: CAPABILITY
+
+ Result: OK - capability completed
+ BAD - command unknown or arguments invalid
+
+ The CAPABILITY command requests a listing of capabilities that the
+ server supports. The server MUST send a single untagged
+ CAPABILITY response with "IMAP4rev1" as one of the listed
+ capabilities before the (tagged) OK response.
+
+ A capability name which begins with "AUTH=" indicates that the
+ server supports that particular authentication mechanism. All
+ such names are, by definition, part of this specification. For
+ example, the authorization capability for an experimental
+ "blurdybloop" authenticator would be "AUTH=XBLURDYBLOOP" and not
+ "XAUTH=BLURDYBLOOP" or "XAUTH=XBLURDYBLOOP".
+
+ Other capability names refer to extensions, revisions, or
+ amendments to this specification. See the documentation of the
+ CAPABILITY response for additional information. No capabilities,
+ beyond the base IMAP4rev1 set defined in this specification, are
+ enabled without explicit client action to invoke the capability.
+
+ Client and server implementations MUST implement the STARTTLS,
+ LOGINDISABLED, and AUTH=PLAIN (described in [IMAP-TLS])
+ capabilities. See the Security Considerations section for
+ important information.
+
+ See the section entitled "Client Commands -
+ Experimental/Expansion" for information about the form of site or
+ implementation-specific capabilities.
+
+ Example: C: abcd CAPABILITY
+ S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI
+ LOGINDISABLED
+ S: abcd OK CAPABILITY completed
+ C: efgh STARTTLS
+ S: efgh OK STARTLS completed
+ <TLS negotiation, further commands are under [TLS] layer>
+ C: ijkl CAPABILITY
+ S: * CAPABILITY IMAP4rev1 AUTH=GSSAPI AUTH=PLAIN
+ S: ijkl OK CAPABILITY completed
+
+6.1.2. NOOP Command
+
+ Arguments: none
+
+ Responses: no specific responses for this command (but see below)
+
+ Result: OK - noop completed
+ BAD - command unknown or arguments invalid
+
+ The NOOP command always succeeds. It does nothing.
+
+ Since any command can return a status update as untagged data, the
+ NOOP command can be used as a periodic poll for new messages or
+ message status updates during a period of inactivity (this is the
+ preferred method to do this). The NOOP command can also be used
+ to reset any inactivity autologout timer on the server.
+
+ Example: C: a002 NOOP
+ S: a002 OK NOOP completed
+ . . .
+ C: a047 NOOP
+ S: * 22 EXPUNGE
+ S: * 23 EXISTS
+ S: * 3 RECENT
+ S: * 14 FETCH (FLAGS (\Seen \Deleted))
+ S: a047 OK NOOP completed
+
+6.1.3. LOGOUT Command
+
+ Arguments: none
+
+ Responses: REQUIRED untagged response: BYE
+
+ Result: OK - logout completed
+ BAD - command unknown or arguments invalid
+
+ The LOGOUT command informs the server that the client is done with
+ the connection. The server MUST send a BYE untagged response
+ before the (tagged) OK response, and then close the network
+ connection.
+
+ Example: C: A023 LOGOUT
+ S: * BYE IMAP4rev1 Server logging out
+ S: A023 OK LOGOUT completed
+ (Server and client then close the connection)
+
+6.2. Client Commands - Not Authenticated State
+
+ In the not authenticated state, the AUTHENTICATE or LOGIN command
+ establishes authentication and enters the authenticated state. The
+ AUTHENTICATE command provides a general mechanism for a variety of
+ authentication techniques, privacy protection, and integrity
+ checking; whereas the LOGIN command uses a traditional user name and
+ plaintext password pair and has no means of establishing privacy
+ protection or integrity checking.
+
+ The STARTTLS command is an alternate form of establishing session
+ privacy protection and integrity checking, but does not establish
+ authentication or enter the authenticated state.
+
+ Server implementations MAY allow access to certain mailboxes without
+ establishing authentication. This can be done by means of the
+ ANONYMOUS [SASL] authenticator described in [ANONYMOUS]. An older
+ convention is a LOGIN command using the userid "anonymous"; in this
+ case, a password is required although the server may choose to accept
+ any password. The restrictions placed on anonymous users are
+ implementation-dependent.
+
+ Once authenticated (including as anonymous), it is not possible to
+ re-enter not authenticated state.
+
+ In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
+ the following commands are valid in the not authenticated state:
+ STARTTLS, AUTHENTICATE and LOGIN. See the Security Considerations
+ section for important information about these commands.
+
+6.2.1. STARTTLS Command
+
+ Arguments: none
+
+ Responses: no specific response for this command
+
+ Result: OK - starttls completed, begin TLS negotiation
+ BAD - command unknown or arguments invalid
+
+ A [TLS] negotiation begins immediately after the CRLF at the end
+ of the tagged OK response from the server. Once a client issues a
+ STARTTLS command, it MUST NOT issue further commands until a
+ server response is seen and the [TLS] negotiation is complete.
+
+ The server remains in the non-authenticated state, even if client
+ credentials are supplied during the [TLS] negotiation. This does
+ not preclude an authentication mechanism such as EXTERNAL (defined
+ in [SASL]) from using client identity determined by the [TLS]
+ negotiation.
+
+ Once [TLS] has been started, the client MUST discard cached
+ information about server capabilities and SHOULD re-issue the
+ CAPABILITY command. This is necessary to protect against man-in-
+ the-middle attacks which alter the capabilities list prior to
+ STARTTLS. The server MAY advertise different capabilities after
+ STARTTLS.
+
+ Example: C: a001 CAPABILITY
+ S: * CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED
+ S: a001 OK CAPABILITY completed
+ C: a002 STARTTLS
+ S: a002 OK Begin TLS negotiation now
+ <TLS negotiation, further commands are under [TLS] layer>
+ C: a003 CAPABILITY
+ S: * CAPABILITY IMAP4rev1 AUTH=PLAIN
+ S: a003 OK CAPABILITY completed
+ C: a004 LOGIN joe password
+ S: a004 OK LOGIN completed
+
+6.2.2. AUTHENTICATE Command
+
+ Arguments: authentication mechanism name
+
+ Responses: continuation data can be requested
+
+ Result: OK - authenticate completed, now in authenticated state
+ NO - authenticate failure: unsupported authentication
+ mechanism, credentials rejected
+ BAD - command unknown or arguments invalid,
+ authentication exchange cancelled
+
+ The AUTHENTICATE command indicates a [SASL] authentication
+ mechanism to the server. If the server supports the requested
+ authentication mechanism, it performs an authentication protocol
+ exchange to authenticate and identify the client. It MAY also
+ negotiate an OPTIONAL security layer for subsequent protocol
+ interactions. If the requested authentication mechanism is not
+ supported, the server SHOULD reject the AUTHENTICATE command by
+ sending a tagged NO response.
+
+ The AUTHENTICATE command does not support the optional "initial
+ response" feature of [SASL]. Section 5.1 of [SASL] specifies how
+ to handle an authentication mechanism which uses an initial
+ response.
+
+ The service name specified by this protocol's profile of [SASL] is
+ "imap".
+
+ The authentication protocol exchange consists of a series of
+ server challenges and client responses that are specific to the
+ authentication mechanism. A server challenge consists of a
+ command continuation request response with the "+" token followed
+ by a BASE64 encoded string. The client response consists of a
+ single line consisting of a BASE64 encoded string. If the client
+ wishes to cancel an authentication exchange, it issues a line
+ consisting of a single "*". If the server receives such a
+ response, it MUST reject the AUTHENTICATE command by sending a
+ tagged BAD response.
+
+ If a security layer is negotiated through the [SASL]
+ authentication exchange, it takes effect immediately following the
+ CRLF that concludes the authentication exchange for the client,
+ and the CRLF of the tagged OK response for the server.
+
+ While client and server implementations MUST implement the
+ AUTHENTICATE command itself, it is not required to implement any
+ authentication mechanisms other than the PLAIN mechanism described
+
+ in [IMAP-TLS]. Also, an authentication mechanism is not required
+ to support any security layers.
+
+ Note: a server implementation MUST implement a
+ configuration in which it does NOT permit any plaintext
+ password mechanisms, unless either the STARTTLS command
+ has been negotiated or some other mechanism that
+ protects the session from password snooping has been
+ provided. Server sites SHOULD NOT use any configuration
+ which permits a plaintext password mechanism without
+ such a protection mechanism against password snooping.
+ Client and server implementations SHOULD implement
+ additional [SASL] mechanisms that do not use plaintext
+ passwords, such the GSSAPI mechanism described in [SASL]
+ and/or the [DIGEST-MD5] mechanism.
+
+ Servers and clients can support multiple authentication
+ mechanisms. The server SHOULD list its supported authentication
+ mechanisms in the response to the CAPABILITY command so that the
+ client knows which authentication mechanisms to use.
+
+ A server MAY include a CAPABILITY response code in the tagged OK
+ response of a successful AUTHENTICATE command in order to send
+ capabilities automatically. It is unnecessary for a client to
+ send a separate CAPABILITY command if it recognizes these
+ automatic capabilities. This should only be done if a security
+ layer was not negotiated by the AUTHENTICATE command, because the
+ tagged OK response as part of an AUTHENTICATE command is not
+ protected by encryption/integrity checking. [SASL] requires the
+ client to re-issue a CAPABILITY command in this case.
+
+ If an AUTHENTICATE command fails with a NO response, the client
+ MAY try another authentication mechanism by issuing another
+ AUTHENTICATE command. It MAY also attempt to authenticate by
+ using the LOGIN command (see section 6.2.3 for more detail). In
+ other words, the client MAY request authentication types in
+ decreasing order of preference, with the LOGIN command as a last
+ resort.
+
+ The authorization identity passed from the client to the server
+ during the authentication exchange is interpreted by the server as
+ the user name whose privileges the client is requesting.
+
+ Example: S: * OK IMAP4rev1 Server
+ C: A001 AUTHENTICATE GSSAPI
+ S: +
+ C: YIIB+wYJKoZIhvcSAQICAQBuggHqMIIB5qADAgEFoQMCAQ6iBw
+ MFACAAAACjggEmYYIBIjCCAR6gAwIBBaESGxB1Lndhc2hpbmd0
+ b24uZWR1oi0wK6ADAgEDoSQwIhsEaW1hcBsac2hpdmFtcy5jYW
+ Mud2FzaGluZ3Rvbi5lZHWjgdMwgdCgAwIBAaEDAgEDooHDBIHA
+ cS1GSa5b+fXnPZNmXB9SjL8Ollj2SKyb+3S0iXMljen/jNkpJX
+ AleKTz6BQPzj8duz8EtoOuNfKgweViyn/9B9bccy1uuAE2HI0y
+ C/PHXNNU9ZrBziJ8Lm0tTNc98kUpjXnHZhsMcz5Mx2GR6dGknb
+ I0iaGcRerMUsWOuBmKKKRmVMMdR9T3EZdpqsBd7jZCNMWotjhi
+ vd5zovQlFqQ2Wjc2+y46vKP/iXxWIuQJuDiisyXF0Y8+5GTpAL
+ pHDc1/pIGmMIGjoAMCAQGigZsEgZg2on5mSuxoDHEA1w9bcW9n
+ FdFxDKpdrQhVGVRDIzcCMCTzvUboqb5KjY1NJKJsfjRQiBYBdE
+ NKfzK+g5DlV8nrw81uOcP8NOQCLR5XkoMHC0Dr/80ziQzbNqhx
+ O6652Npft0LQwJvenwDI13YxpwOdMXzkWZN/XrEqOWp6GCgXTB
+ vCyLWLlWnbaUkZdEYbKHBPjd8t/1x5Yg==
+ S: + YGgGCSqGSIb3EgECAgIAb1kwV6ADAgEFoQMCAQ+iSzBJoAMC
+ AQGiQgRAtHTEuOP2BXb9sBYFR4SJlDZxmg39IxmRBOhXRKdDA0
+ uHTCOT9Bq3OsUTXUlk0CsFLoa8j+gvGDlgHuqzWHPSQg==
+ C:
+ S: + YDMGCSqGSIb3EgECAgIBAAD/////6jcyG4GE3KkTzBeBiVHe
+ ceP2CWY0SR0fAQAgAAQEBAQ=
+ C: YDMGCSqGSIb3EgECAgIBAAD/////3LQBHXTpFfZgrejpLlLImP
+ wkhbfa2QteAQAgAG1yYwE=
+ S: A001 OK GSSAPI authentication successful
+
+ Note: The line breaks within server challenges and client
+ responses are for editorial clarity and are not in real
+ authenticators.
+
+6.2.3. LOGIN Command
+
+ Arguments: user name
+ password
+
+ Responses: no specific responses for this command
+
+ Result: OK - login completed, now in authenticated state
+ NO - login failure: user name or password rejected
+ BAD - command unknown or arguments invalid
+
+ The LOGIN command identifies the client to the server and carries
+ the plaintext password authenticating this user.
+
+ A server MAY include a CAPABILITY response code in the tagged OK
+ response to a successful LOGIN command in order to send
+ capabilities automatically. It is unnecessary for a client to
+ send a separate CAPABILITY command if it recognizes these
+ automatic capabilities.
+
+ Example: C: a001 LOGIN SMITH SESAME
+ S: a001 OK LOGIN completed
+
+ Note: Use of the LOGIN command over an insecure network
+ (such as the Internet) is a security risk, because anyone
+ monitoring network traffic can obtain plaintext passwords.
+ The LOGIN command SHOULD NOT be used except as a last
+ resort, and it is recommended that client implementations
+ have a means to disable any automatic use of the LOGIN
+ command.
+
+ Unless either the STARTTLS command has been negotiated or
+ some other mechanism that protects the session from
+ password snooping has been provided, a server
+ implementation MUST implement a configuration in which it
+ advertises the LOGINDISABLED capability and does NOT permit
+ the LOGIN command. Server sites SHOULD NOT use any
+ configuration which permits the LOGIN command without such
+ a protection mechanism against password snooping. A client
+ implementation MUST NOT send a LOGIN command if the
+ LOGINDISABLED capability is advertised.
+
+6.3. Client Commands - Authenticated State
+
+ In the authenticated state, commands that manipulate mailboxes as
+ atomic entities are permitted. Of these commands, the SELECT and
+ EXAMINE commands will select a mailbox for access and enter the
+ selected state.
+
+ In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
+ the following commands are valid in the authenticated state: SELECT,
+ EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB,
+ STATUS, and APPEND.
+
+6.3.1. SELECT Command
+
+ Arguments: mailbox name
+
+ Responses: REQUIRED untagged responses: FLAGS, EXISTS, RECENT
+ REQUIRED OK untagged responses: UNSEEN, PERMANENTFLAGS,
+ UIDNEXT, UIDVALIDITY
+
+ Result: OK - select completed, now in selected state
+ NO - select failure, now in authenticated state: no
+ such mailbox, can't access mailbox
+ BAD - command unknown or arguments invalid
+
+ The SELECT command selects a mailbox so that messages in the
+ mailbox can be accessed. Before returning an OK to the client,
+ the server MUST send the following untagged data to the client.
+ Note that earlier versions of this protocol only required the
+ FLAGS, EXISTS, and RECENT untagged data; consequently, client
+ implementations SHOULD implement default behavior for missing data
+ as discussed with the individual item.
+
+ FLAGS Defined flags in the mailbox. See the description
+ of the FLAGS response for more detail.
+
+ <n> EXISTS The number of messages in the mailbox. See the
+ description of the EXISTS response for more detail.
+
+ <n> RECENT The number of messages with the \Recent flag set.
+ See the description of the RECENT response for more
+ detail.
+
+ OK [UNSEEN <n>]
+ The message sequence number of the first unseen
+ message in the mailbox. If this is missing, the
+ client can not make any assumptions about the first
+ unseen message in the mailbox, and needs to issue a
+ SEARCH command if it wants to find it.
+
+ OK [PERMANENTFLAGS (<list of flags>)]
+ A list of message flags that the client can change
+ permanently. If this is missing, the client should
+ assume that all flags can be changed permanently.
+
+ OK [UIDNEXT <n>]
+ The next unique identifier value. Refer to section
+ 2.3.1.1 for more information. If this is missing,
+ the client can not make any assumptions about the
+ next unique identifier value.
+
+ OK [UIDVALIDITY <n>]
+ The unique identifier validity value. Refer to
+ section 2.3.1.1 for more information. If this is
+ missing, the server does not support unique
+ identifiers.
+
+ Only one mailbox can be selected at a time in a connection;
+ simultaneous access to multiple mailboxes requires multiple
+ connections. The SELECT command automatically deselects any
+ currently selected mailbox before attempting the new selection.
+ Consequently, if a mailbox is selected and a SELECT command that
+ fails is attempted, no mailbox is selected.
+
+ If the client is permitted to modify the mailbox, the server
+ SHOULD prefix the text of the tagged OK response with the
+ "[READ-WRITE]" response code.
+
+ If the client is not permitted to modify the mailbox but is
+ permitted read access, the mailbox is selected as read-only, and
+ the server MUST prefix the text of the tagged OK response to
+ SELECT with the "[READ-ONLY]" response code. Read-only access
+ through SELECT differs from the EXAMINE command in that certain
+ read-only mailboxes MAY permit the change of permanent state on a
+ per-user (as opposed to global) basis. Netnews messages marked in
+ a server-based .newsrc file are an example of such per-user
+ permanent state that can be modified with read-only mailboxes.
+
+ Example: C: A142 SELECT INBOX
+ S: * 172 EXISTS
+ S: * 1 RECENT
+ S: * OK [UNSEEN 12] Message 12 is first unseen
+ S: * OK [UIDVALIDITY 3857529045] UIDs valid
+ S: * OK [UIDNEXT 4392] Predicted next UID
+ S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
+ S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
+ S: A142 OK [READ-WRITE] SELECT completed
+
+6.3.2. EXAMINE Command
+
+ Arguments: mailbox name
+
+ Responses: REQUIRED untagged responses: FLAGS, EXISTS, RECENT
+ REQUIRED OK untagged responses: UNSEEN, PERMANENTFLAGS,
+ UIDNEXT, UIDVALIDITY
+
+ Result: OK - examine completed, now in selected state
+ NO - examine failure, now in authenticated state: no
+ such mailbox, can't access mailbox
+ BAD - command unknown or arguments invalid
+
+ The EXAMINE command is identical to SELECT and returns the same
+ output; however, the selected mailbox is identified as read-only.
+ No changes to the permanent state of the mailbox, including
+ per-user state, are permitted; in particular, EXAMINE MUST NOT
+ cause messages to lose the \Recent flag.
+
+ The text of the tagged OK response to the EXAMINE command MUST
+ begin with the "[READ-ONLY]" response code.
+
+ Example: C: A932 EXAMINE blurdybloop
+ S: * 17 EXISTS
+ S: * 2 RECENT
+ S: * OK [UNSEEN 8] Message 8 is first unseen
+ S: * OK [UIDVALIDITY 3857529045] UIDs valid
+ S: * OK [UIDNEXT 4392] Predicted next UID
+ S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
+ S: * OK [PERMANENTFLAGS ()] No permanent flags permitted
+ S: A932 OK [READ-ONLY] EXAMINE completed
+
+6.3.3. CREATE Command
+
+ Arguments: mailbox name
+
+ Responses: no specific responses for this command
+
+ Result: OK - create completed
+ NO - create failure: can't create mailbox with that name
+ BAD - command unknown or arguments invalid
+
+ The CREATE command creates a mailbox with the given name. An OK
+ response is returned only if a new mailbox with that name has been
+ created. It is an error to attempt to create INBOX or a mailbox
+ with a name that refers to an extant mailbox. Any error in
+ creation will return a tagged NO response.
+
+ If the mailbox name is suffixed with the server's hierarchy
+ separator character (as returned from the server by a LIST
+ command), this is a declaration that the client intends to create
+ mailbox names under this name in the hierarchy. Server
+ implementations that do not require this declaration MUST ignore
+ the declaration. In any case, the name created is without the
+ trailing hierarchy delimiter.
+
+ If the server's hierarchy separator character appears elsewhere in
+ the name, the server SHOULD create any superior hierarchical names
+ that are needed for the CREATE command to be successfully
+ completed. In other words, an attempt to create "foo/bar/zap" on
+ a server in which "/" is the hierarchy separator character SHOULD
+ create foo/ and foo/bar/ if they do not already exist.
+
+ If a new mailbox is created with the same name as a mailbox which
+ was deleted, its unique identifiers MUST be greater than any
+ unique identifiers used in the previous incarnation of the mailbox
+ UNLESS the new incarnation has a different unique identifier
+ validity value. See the description of the UID command for more
+ detail.
+
+ Example: C: A003 CREATE owatagusiam/
+ S: A003 OK CREATE completed
+ C: A004 CREATE owatagusiam/blurdybloop
+ S: A004 OK CREATE completed
+
+ Note: The interpretation of this example depends on whether
+ "/" was returned as the hierarchy separator from LIST. If
+ "/" is the hierarchy separator, a new level of hierarchy
+ named "owatagusiam" with a member called "blurdybloop" is
+ created. Otherwise, two mailboxes at the same hierarchy
+ level are created.
+
+6.3.4. DELETE Command
+
+ Arguments: mailbox name
+
+ Responses: no specific responses for this command
+
+ Result: OK - delete completed
+ NO - delete failure: can't delete mailbox with that name
+ BAD - command unknown or arguments invalid
+
+ The DELETE command permanently removes the mailbox with the given
+ name. A tagged OK response is returned only if the mailbox has
+ been deleted. It is an error to attempt to delete INBOX or a
+ mailbox name that does not exist.
+
+ The DELETE command MUST NOT remove inferior hierarchical names.
+ For example, if a mailbox "foo" has an inferior "foo.bar"
+ (assuming "." is the hierarchy delimiter character), removing
+ "foo" MUST NOT remove "foo.bar". It is an error to attempt to
+ delete a name that has inferior hierarchical names and also has
+ the \Noselect mailbox name attribute (see the description of the
+ LIST response for more details).
+
+ It is permitted to delete a name that has inferior hierarchical
+ names and does not have the \Noselect mailbox name attribute. In
+ this case, all messages in that mailbox are removed, and the name
+ will acquire the \Noselect mailbox name attribute.
+
+ The value of the highest-used unique identifier of the deleted
+ mailbox MUST be preserved so that a new mailbox created with the
+ same name will not reuse the identifiers of the former
+ incarnation, UNLESS the new incarnation has a different unique
+ identifier validity value. See the description of the UID command
+ for more detail.
+
+ Examples: C: A682 LIST "" *
+ S: * LIST () "/" blurdybloop
+ S: * LIST (\Noselect) "/" foo
+ S: * LIST () "/" foo/bar
+ S: A682 OK LIST completed
+ C: A683 DELETE blurdybloop
+ S: A683 OK DELETE completed
+ C: A684 DELETE foo
+ S: A684 NO Name "foo" has inferior hierarchical names
+ C: A685 DELETE foo/bar
+ S: A685 OK DELETE Completed
+ C: A686 LIST "" *
+ S: * LIST (\Noselect) "/" foo
+ S: A686 OK LIST completed
+ C: A687 DELETE foo
+ S: A687 OK DELETE Completed
+
+ C: A82 LIST "" *
+ S: * LIST () "." blurdybloop
+ S: * LIST () "." foo
+ S: * LIST () "." foo.bar
+ S: A82 OK LIST completed
+ C: A83 DELETE blurdybloop
+ S: A83 OK DELETE completed
+ C: A84 DELETE foo
+ S: A84 OK DELETE Completed
+ C: A85 LIST "" *
+ S: * LIST () "." foo.bar
+ S: A85 OK LIST completed
+ C: A86 LIST "" %
+ S: * LIST (\Noselect) "." foo
+ S: A86 OK LIST completed
+
+6.3.5. RENAME Command
+
+ Arguments: existing mailbox name
+ new mailbox name
+
+ Responses: no specific responses for this command
+
+ Result: OK - rename completed
+ NO - rename failure: can't rename mailbox with that name,
+ can't rename to mailbox with that name
+ BAD - command unknown or arguments invalid
+
+ The RENAME command changes the name of a mailbox. A tagged OK
+ response is returned only if the mailbox has been renamed. It is
+ an error to attempt to rename from a mailbox name that does not
+ exist or to a mailbox name that already exists. Any error in
+ renaming will return a tagged NO response.
+
+ If the name has inferior hierarchical names, then the inferior
+ hierarchical names MUST also be renamed. For example, a rename of
+ "foo" to "zap" will rename "foo/bar" (assuming "/" is the
+ hierarchy delimiter character) to "zap/bar".
+
+ If the server's hierarchy separator character appears in the name,
+ the server SHOULD create any superior hierarchical names that are
+ needed for the RENAME command to complete successfully. In other
+ words, an attempt to rename "foo/bar/zap" to baz/rag/zowie on a
+ server in which "/" is the hierarchy separator character SHOULD
+ create baz/ and baz/rag/ if they do not already exist.
+
+ The value of the highest-used unique identifier of the old mailbox
+ name MUST be preserved so that a new mailbox created with the same
+ name will not reuse the identifiers of the former incarnation,
+ UNLESS the new incarnation has a different unique identifier
+ validity value. See the description of the UID command for more
+ detail.
+
+ Renaming INBOX is permitted, and has special behavior. It moves
+ all messages in INBOX to a new mailbox with the given name,
+ leaving INBOX empty. If the server implementation supports
+ inferior hierarchical names of INBOX, these are unaffected by a
+ rename of INBOX.
+
+ Examples: C: A682 LIST "" *
+ S: * LIST () "/" blurdybloop
+ S: * LIST (\Noselect) "/" foo
+ S: * LIST () "/" foo/bar
+ S: A682 OK LIST completed
+ C: A683 RENAME blurdybloop sarasoop
+ S: A683 OK RENAME completed
+ C: A684 RENAME foo zowie
+ S: A684 OK RENAME Completed
+ C: A685 LIST "" *
+ S: * LIST () "/" sarasoop
+ S: * LIST (\Noselect) "/" zowie
+ S: * LIST () "/" zowie/bar
+ S: A685 OK LIST completed
+
+ C: Z432 LIST "" *
+ S: * LIST () "." INBOX
+ S: * LIST () "." INBOX.bar
+ S: Z432 OK LIST completed
+ C: Z433 RENAME INBOX old-mail
+ S: Z433 OK RENAME completed
+ C: Z434 LIST "" *
+ S: * LIST () "." INBOX
+ S: * LIST () "." INBOX.bar
+ S: * LIST () "." old-mail
+ S: Z434 OK LIST completed
+
+6.3.6. SUBSCRIBE Command
+
+ Arguments: mailbox
+
+ Responses: no specific responses for this command
+
+ Result: OK - subscribe completed
+ NO - subscribe failure: can't subscribe to that name
+ BAD - command unknown or arguments invalid
+
+ The SUBSCRIBE command adds the specified mailbox name to the
+ server's set of "active" or "subscribed" mailboxes as returned by
+ the LSUB command. This command returns a tagged OK response only
+ if the subscription is successful.
+
+ A server MAY validate the mailbox argument to SUBSCRIBE to verify
+ that it exists. However, it MUST NOT unilaterally remove an
+ existing mailbox name from the subscription list even if a mailbox
+ by that name no longer exists.
+
+ Note: This requirement is because a server site can
+ choose to routinely remove a mailbox with a well-known
+ name (e.g., "system-alerts") after its contents expire,
+ with the intention of recreating it when new contents
+ are appropriate.
+
+ Example: C: A002 SUBSCRIBE #news.comp.mail.mime
+ S: A002 OK SUBSCRIBE completed
+
+6.3.7. UNSUBSCRIBE Command
+
+ Arguments: mailbox name
+
+ Responses: no specific responses for this command
+
+ Result: OK - unsubscribe completed
+ NO - unsubscribe failure: can't unsubscribe that name
+ BAD - command unknown or arguments invalid
+
+ The UNSUBSCRIBE command removes the specified mailbox name from
+ the server's set of "active" or "subscribed" mailboxes as returned
+ by the LSUB command. This command returns a tagged OK response
+ only if the unsubscription is successful.
+
+ Example: C: A002 UNSUBSCRIBE #news.comp.mail.mime
+ S: A002 OK UNSUBSCRIBE completed
+
+6.3.8. LIST Command
+
+ Arguments: reference name
+ mailbox name with possible wildcards
+
+ Responses: untagged responses: LIST
+
+ Result: OK - list completed
+ NO - list failure: can't list that reference or name
+ BAD - command unknown or arguments invalid
+
+ The LIST command returns a subset of names from the complete set
+ of all names available to the client. Zero or more untagged LIST
+ replies are returned, containing the name attributes, hierarchy
+ delimiter, and name; see the description of the LIST reply for
+ more detail.
+
+ The LIST command SHOULD return its data quickly, without undue
+ delay. For example, it SHOULD NOT go to excess trouble to
+ calculate the \Marked or \Unmarked status or perform other
+ processing; if each name requires 1 second of processing, then a
+ list of 1200 names would take 20 minutes!
+
+ An empty ("" string) reference name argument indicates that the
+ mailbox name is interpreted as by SELECT. The returned mailbox
+ names MUST match the supplied mailbox name pattern. A non-empty
+ reference name argument is the name of a mailbox or a level of
+ mailbox hierarchy, and indicates the context in which the mailbox
+ name is interpreted.
+
+ An empty ("" string) mailbox name argument is a special request to
+ return the hierarchy delimiter and the root name of the name given
+ in the reference. The value returned as the root MAY be the empty
+ string if the reference is non-rooted or is an empty string. In
+ all cases, a hierarchy delimiter (or NIL if there is no hierarchy)
+ is returned. This permits a client to get the hierarchy delimiter
+ (or find out that the mailbox names are flat) even when no
+ mailboxes by that name currently exist.
+
+ The reference and mailbox name arguments are interpreted into a
+ canonical form that represents an unambiguous left-to-right
+ hierarchy. The returned mailbox names will be in the interpreted
+ form.
+
+ Note: The interpretation of the reference argument is
+ implementation-defined. It depends upon whether the
+ server implementation has a concept of the "current
+ working directory" and leading "break out characters",
+ which override the current working directory.
+
+ For example, on a server which exports a UNIX or NT
+ filesystem, the reference argument contains the current
+ working directory, and the mailbox name argument would
+ contain the name as interpreted in the current working
+ directory.
+
+ If a server implementation has no concept of break out
+ characters, the canonical form is normally the reference
+ name appended with the mailbox name. Note that if the
+ server implements the namespace convention (section
+ 5.1.2), "#" is a break out character and must be treated
+ as such.
+
+ If the reference argument is not a level of mailbox
+ hierarchy (that is, it is a \NoInferiors name), and/or
+ the reference argument does not end with the hierarchy
+ delimiter, it is implementation-dependent how this is
+ interpreted. For example, a reference of "foo/bar" and
+ mailbox name of "rag/baz" could be interpreted as
+ "foo/bar/rag/baz", "foo/barrag/baz", or "foo/rag/baz".
+ A client SHOULD NOT use such a reference argument except
+ at the explicit request of the user. A hierarchical
+ browser MUST NOT make any assumptions about server
+ interpretation of the reference unless the reference is
+ a level of mailbox hierarchy AND ends with the hierarchy
+ delimiter.
+
+ Any part of the reference argument that is included in the
+ interpreted form SHOULD prefix the interpreted form. It SHOULD
+ also be in the same form as the reference name argument. This
+ rule permits the client to determine if the returned mailbox name
+ is in the context of the reference argument, or if something about
+ the mailbox argument overrode the reference argument. Without
+ this rule, the client would have to have knowledge of the server's
+ naming semantics including what characters are "breakouts" that
+ override a naming context.
+
+ For example, here are some examples of how references
+ and mailbox names might be interpreted on a UNIX-based
+ server:
+
+ Reference Mailbox Name Interpretation
+ ------------ ------------ --------------
+ ~smith/Mail/ foo.* ~smith/Mail/foo.*
+ archive/ % archive/%
+ #news. comp.mail.* #news.comp.mail.*
+ ~smith/Mail/ /usr/doc/foo /usr/doc/foo
+ archive/ ~fred/Mail/* ~fred/Mail/*
+
+ The first three examples demonstrate interpretations in
+ the context of the reference argument. Note that
+ "~smith/Mail" SHOULD NOT be transformed into something
+ like "/u2/users/smith/Mail", or it would be impossible
+ for the client to determine that the interpretation was
+ in the context of the reference.
+
+ The character "*" is a wildcard, and matches zero or more
+ characters at this position. The character "%" is similar to "*",
+ but it does not match a hierarchy delimiter. If the "%" wildcard
+ is the last character of a mailbox name argument, matching levels
+ of hierarchy are also returned. If these levels of hierarchy are
+ not also selectable mailboxes, they are returned with the
+ \Noselect mailbox name attribute (see the description of the LIST
+ response for more details).
+
+ Server implementations are permitted to "hide" otherwise
+ accessible mailboxes from the wildcard characters, by preventing
+ certain characters or names from matching a wildcard in certain
+ situations. For example, a UNIX-based server might restrict the
+ interpretation of "*" so that an initial "/" character does not
+ match.
+
+ The special name INBOX is included in the output from LIST, if
+ INBOX is supported by this server for this user and if the
+ uppercase string "INBOX" matches the interpreted reference and
+ mailbox name arguments with wildcards as described above. The
+ criteria for omitting INBOX is whether SELECT INBOX will return
+ failure; it is not relevant whether the user's real INBOX resides
+ on this or some other server.
+
+ Example: C: A101 LIST "" ""
+ S: * LIST (\Noselect) "/" ""
+ S: A101 OK LIST Completed
+ C: A102 LIST #news.comp.mail.misc ""
+ S: * LIST (\Noselect) "." #news.
+ S: A102 OK LIST Completed
+ C: A103 LIST /usr/staff/jones ""
+ S: * LIST (\Noselect) "/" /
+ S: A103 OK LIST Completed
+ C: A202 LIST ~/Mail/ %
+ S: * LIST (\Noselect) "/" ~/Mail/foo
+ S: * LIST () "/" ~/Mail/meetings
+ S: A202 OK LIST completed
+
+6.3.9. LSUB Command
+
+ Arguments: reference name
+ mailbox name with possible wildcards
+
+ Responses: untagged responses: LSUB
+
+ Result: OK - lsub completed
+ NO - lsub failure: can't list that reference or name
+ BAD - command unknown or arguments invalid
+
+ The LSUB command returns a subset of names from the set of names
+ that the user has declared as being "active" or "subscribed".
+ Zero or more untagged LSUB replies are returned. The arguments to
+ LSUB are in the same form as those for LIST.
+
+ The returned untagged LSUB response MAY contain different mailbox
+ flags from a LIST untagged response. If this should happen, the
+ flags in the untagged LIST are considered more authoritative.
+
+ A special situation occurs when using LSUB with the % wildcard.
+ Consider what happens if "foo/bar" (with a hierarchy delimiter of
+ "/") is subscribed but "foo" is not. A "%" wildcard to LSUB must
+ return foo, not foo/bar, in the LSUB response, and it MUST be
+ flagged with the \Noselect attribute.
+
+ The server MUST NOT unilaterally remove an existing mailbox name
+ from the subscription list even if a mailbox by that name no
+ longer exists.
+
+ Example: C: A002 LSUB "#news." "comp.mail.*"
+ S: * LSUB () "." #news.comp.mail.mime
+ S: * LSUB () "." #news.comp.mail.misc
+ S: A002 OK LSUB completed
+ C: A003 LSUB "#news." "comp.%"
+ S: * LSUB (\NoSelect) "." #news.comp.mail
+ S: A003 OK LSUB completed
+
+6.3.10. STATUS Command
+
+ Arguments: mailbox name
+ status data item names
+
+ Responses: untagged responses: STATUS
+
+ Result: OK - status completed
+ NO - status failure: no status for that name
+ BAD - command unknown or arguments invalid
+
+ The STATUS command requests the status of the indicated mailbox.
+ It does not change the currently selected mailbox, nor does it
+ affect the state of any messages in the queried mailbox (in
+ particular, STATUS MUST NOT cause messages to lose the \Recent
+ flag).
+
+ The STATUS command provides an alternative to opening a second
+ IMAP4rev1 connection and doing an EXAMINE command on a mailbox to
+ query that mailbox's status without deselecting the current
+ mailbox in the first IMAP4rev1 connection.
+
+ Unlike the LIST command, the STATUS command is not guaranteed to
+ be fast in its response. Under certain circumstances, it can be
+ quite slow. In some implementations, the server is obliged to
+ open the mailbox read-only internally to obtain certain status
+ information. Also unlike the LIST command, the STATUS command
+ does not accept wildcards.
+
+ Note: The STATUS command is intended to access the
+ status of mailboxes other than the currently selected
+ mailbox. Because the STATUS command can cause the
+ mailbox to be opened internally, and because this
+ information is available by other means on the selected
+ mailbox, the STATUS command SHOULD NOT be used on the
+ currently selected mailbox.
+
+ The STATUS command MUST NOT be used as a "check for new
+ messages in the selected mailbox" operation (refer to
+ sections 7, 7.3.1, and 7.3.2 for more information about
+ the proper method for new message checking).
+
+ Because the STATUS command is not guaranteed to be fast
+ in its results, clients SHOULD NOT expect to be able to
+ issue many consecutive STATUS commands and obtain
+ reasonable performance.
+
+ The currently defined status data items that can be requested are:
+
+ MESSAGES
+ The number of messages in the mailbox.
+
+ RECENT
+ The number of messages with the \Recent flag set.
+
+ UIDNEXT
+ The next unique identifier value of the mailbox. Refer to
+ section 2.3.1.1 for more information.
+
+ UIDVALIDITY
+ The unique identifier validity value of the mailbox. Refer to
+ section 2.3.1.1 for more information.
+
+ UNSEEN
+ The number of messages which do not have the \Seen flag set.
+
+ Example: C: A042 STATUS blurdybloop (UIDNEXT MESSAGES)
+ S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
+ S: A042 OK STATUS completed
+
+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 [_R_F_C_-_2_8_2_2] 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 [_R_F_C_-_2_8_2_2] header lines are omitted in
+ the message literal argument to APPEND. The full
+ implications of doing so MUST be understood and
+ carefully weighed.
+
+ If a flag parenthesized list is specified, the flags SHOULD be set
+ in the resulting message; otherwise, the flag list of the
+ resulting message is set to empty by default. In either case, the
+ Recent flag is also set.
+
+ If a date-time is specified, the internal date SHOULD be set in
+ the resulting message; otherwise, the internal date of the
+ resulting message is set to the current date and time by default.
+
+ If the append is unsuccessful for any reason, the mailbox MUST be
+ restored to its state before the APPEND attempt; no partial
+ appending is permitted.
+
+ If the destination mailbox does not exist, a server MUST return an
+ error, and MUST NOT automatically create the mailbox. Unless it
+ is certain that the destination mailbox can not be created, the
+ server MUST send the response code "[TRYCREATE]" as the prefix of
+ the text of the tagged NO response. This gives a hint to the
+ client that it can attempt a CREATE command and retry the APPEND
+ if the CREATE is successful.
+
+ If the mailbox is currently selected, the normal new message
+ actions SHOULD occur. Specifically, the server SHOULD notify the
+ client immediately via an untagged EXISTS response. If the server
+ does not do so, the client MAY issue a NOOP command (or failing
+ that, a CHECK command) after one or more APPEND commands.
+
+ Example: C: A003 APPEND saved-messages (\Seen) {310}
+ S: + Ready for literal data
+ C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
+ C: From: Fred Foobar <_f_o_o_b_a_r_@_B_l_u_r_d_y_b_l_o_o_p_._C_O_M>
+ C: Subject: afternoon meeting
+ C: To: _m_o_o_c_h_@_o_w_a_t_a_g_u_._s_i_a_m_._e_d_u
+ C: Message-Id: <B27397-0100000@Blurdybloop.COM>
+ C: MIME-Version: 1.0
+ C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
+ C:
+ C: Hello Joe, do you think we can meet at 3:30 tomorrow?
+ C:
+ S: A003 OK APPEND completed
+
+ Note: The APPEND command is not used for message delivery,
+ because it does not provide a mechanism to transfer [SMTP]
+ envelope information.
+
+6.4. Client Commands - Selected State
+
+ In the selected state, commands that manipulate messages in a mailbox
+ are permitted.
+
+ In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
+ and the authenticated state commands (SELECT, EXAMINE, CREATE,
+ DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS, and
+ APPEND), the following commands are valid in the selected state:
+ CHECK, CLOSE, EXPUNGE, SEARCH, FETCH, STORE, COPY, and UID.
+
+6.4.1. CHECK Command
+
+ Arguments: none
+
+ Responses: no specific responses for this command
+
+ Result: OK - check completed
+ BAD - command unknown or arguments invalid
+
+ The CHECK command requests a checkpoint of the currently selected
+ mailbox. A checkpoint refers to any implementation-dependent
+ housekeeping associated with the mailbox (e.g., resolving the
+ server's in-memory state of the mailbox with the state on its
+
+ disk) that is not normally executed as part of each command. A
+ checkpoint MAY take a non-instantaneous amount of real time to
+ complete. If a server implementation has no such housekeeping
+ considerations, CHECK is equivalent to NOOP.
+
+ There is no guarantee that an EXISTS untagged response will happen
+ as a result of CHECK. NOOP, not CHECK, SHOULD be used for new
+ message polling.
+
+ Example: C: FXXZ CHECK
+ S: FXXZ OK CHECK Completed
+
+6.4.2. CLOSE Command
+
+ Arguments: none
+
+ Responses: no specific responses for this command
+
+ Result: OK - close completed, now in authenticated state
+ BAD - command unknown or arguments invalid
+
+ The CLOSE command permanently removes all messages that have the
+ \Deleted flag set from the currently selected mailbox, and returns
+ to the authenticated state from the selected state. No untagged
+ EXPUNGE responses are sent.
+
+ No messages are removed, and no error is given, if the mailbox is
+ selected by an EXAMINE command or is otherwise selected read-only.
+
+ Even if a mailbox is selected, a SELECT, EXAMINE, or LOGOUT
+ command MAY be issued without previously issuing a CLOSE command.
+ The SELECT, EXAMINE, and LOGOUT commands implicitly close the
+ currently selected mailbox without doing an expunge. However,
+ when many messages are deleted, a CLOSE-LOGOUT or CLOSE-SELECT
+ sequence is considerably faster than an EXPUNGE-LOGOUT or
+ EXPUNGE-SELECT because no untagged EXPUNGE responses (which the
+ client would probably ignore) are sent.
+
+ Example: C: A341 CLOSE
+ S: A341 OK CLOSE completed
+
+6.4.3. EXPUNGE Command
+
+ Arguments: none
+
+ Responses: untagged responses: EXPUNGE
+
+ Result: OK - expunge completed
+ NO - expunge failure: can't expunge (e.g., permission
+ denied)
+ BAD - command unknown or arguments invalid
+
+ The EXPUNGE command permanently removes all messages that have the
+ \Deleted flag set from the currently selected mailbox. Before
+ returning an OK to the client, an untagged EXPUNGE response is
+ sent for each message that is removed.
+
+ Example: C: A202 EXPUNGE
+ S: * 3 EXPUNGE
+ S: * 3 EXPUNGE
+ S: * 5 EXPUNGE
+ S: * 8 EXPUNGE
+ S: A202 OK EXPUNGE completed
+
+ Note: In this example, messages 3, 4, 7, and 11 had the
+ \Deleted flag set. See the description of the EXPUNGE
+ response for further explanation.
+
+6.4.4. SEARCH Command
+
+ Arguments: OPTIONAL [CHARSET] specification
+ searching criteria (one or more)
+
+ Responses: REQUIRED untagged response: SEARCH
+
+ Result: OK - search completed
+ NO - search error: can't search that [CHARSET] or
+ criteria
+ BAD - command unknown or arguments invalid
+
+ The SEARCH command searches the mailbox for messages that match
+ the given searching criteria. Searching criteria consist of one
+ or more search keys. The untagged SEARCH response from the server
+ contains a listing of message sequence numbers corresponding to
+ those messages that match the searching criteria.
+
+ 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
+ [_R_F_C_-_2_8_2_2]/[MIME-IMB] headers, MUST be decoded before comparing
+ text in a [CHARSET] other than US-ASCII. US-ASCII MUST be
+ supported; other [CHARSET]s MAY be supported.
+
+ If the server does not support the specified [CHARSET], it MUST
+ return a tagged NO response (not a BAD). This response SHOULD
+ contain the BADCHARSET response code, which MAY list the
+ [CHARSET]s supported by the server.
+
+ In all search keys that use strings, a message matches the key if
+ the string is a substring of the field. The matching is
+ case-insensitive.
+
+ The defined search keys are as follows. Refer to the Formal
+ Syntax section for the precise syntactic definitions of the
+ arguments.
+
+ <sequence set>
+ Messages with message sequence numbers corresponding to the
+ specified message sequence number set.
+
+ ALL
+ All messages in the mailbox; the default initial key for
+ ANDing.
+
+ ANSWERED
+ Messages with the \Answered flag set.
+
+ BCC <string>
+ Messages that contain the specified string in the envelope
+ structure's BCC field.
+
+ BEFORE <date>
+ Messages whose internal date (disregarding time and timezone)
+ is earlier than the specified date.
+
+ BODY <string>
+ Messages that contain the specified string in the body of the
+ message.
+
+ CC <string>
+ Messages that contain the specified string in the envelope
+ structure's CC field.
+
+ DELETED
+ Messages with the \Deleted flag set.
+
+ DRAFT
+ Messages with the \Draft flag set.
+
+ FLAGGED
+ Messages with the \Flagged flag set.
+
+ FROM <string>
+ Messages that contain the specified string in the envelope
+ structure's FROM field.
+
+ HEADER <field-name> <string>
+ Messages that have a header with the specified field-name (as
+ defined in [_R_F_C_-_2_8_2_2]) and that contains the specified string
+ in the text of the header (what comes after the colon). If the
+ string to search is zero-length, this matches all messages that
+ have a header line with the specified field-name regardless of
+ the contents.
+
+ KEYWORD <flag>
+ Messages with the specified keyword flag set.
+
+ LARGER <n>
+ Messages with an [_R_F_C_-_2_8_2_2] 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 (disregarding time and timezone)
+ is within the specified date.
+
+ OR <search-key1> <search-key2>
+ Messages that match either search key.
+
+ RECENT
+ Messages that have the \Recent flag set.
+
+ SEEN
+ Messages that have the \Seen flag set.
+
+ SENTBEFORE <date>
+ Messages whose [_R_F_C_-_2_8_2_2] Date: header (disregarding time and
+ timezone) is earlier than the specified date.
+
+ SENTON <date>
+ Messages whose [_R_F_C_-_2_8_2_2] Date: header (disregarding time and
+ timezone) is within the specified date.
+
+ SENTSINCE <date>
+ Messages whose [_R_F_C_-_2_8_2_2] Date: header (disregarding time and
+ timezone) is within or later than the specified date.
+
+ SINCE <date>
+ Messages whose internal date (disregarding time and timezone)
+ is within or later than the specified date.
+
+ SMALLER <n>
+ Messages with an [_R_F_C_-_2_8_2_2] 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 <sequence set>
+ Messages with unique identifiers corresponding to the specified
+ unique identifier set. Sequence set ranges are permitted.
+
+ UNANSWERED
+ Messages that do not have the \Answered flag set.
+
+ UNDELETED
+ Messages that do not have the \Deleted flag set.
+
+ UNDRAFT
+ Messages that do not have the \Draft flag set.
+
+ UNFLAGGED
+ Messages that do not have the \Flagged flag set.
+
+ UNKEYWORD <flag>
+ Messages that do not have the specified keyword flag set.
+
+ UNSEEN
+ Messages that do not have the \Seen flag set.
+
+ Example: C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith"
+ S: * SEARCH 2 84 882
+ S: A282 OK SEARCH completed
+ C: A283 SEARCH TEXT "string not in mailbox"
+ S: * SEARCH
+ S: A283 OK SEARCH completed
+ C: A284 SEARCH CHARSET UTF-8 TEXT {6}
+ C: XXXXXX
+ S: * SEARCH 43
+ S: A284 OK SEARCH completed
+
+ Note: Since this document is restricted to 7-bit ASCII
+ text, it is not possible to show actual UTF-8 data. The
+ "XXXXXX" is a placeholder for what would be 6 octets of
+ 8-bit data in an actual transaction.
+
+6.4.5. FETCH Command
+
+ Arguments: sequence set
+ message data item names or macro
+
+ Responses: untagged responses: FETCH
+
+ Result: OK - fetch completed
+ NO - fetch error: can't fetch that data
+ BAD - command unknown or arguments invalid
+
+ The FETCH command retrieves data associated with a message in the
+ mailbox. The data items to be fetched can be either a single atom
+ or a parenthesized list.
+
+ Most data items, identified in the formal syntax under the
+ msg-att-static rule, are static and MUST NOT change for any
+ particular message. Other data items, identified in the formal
+ syntax under the msg-att-dynamic rule, MAY change, either as a
+ result of a STORE command or due to external events.
+
+ For example, if a client receives an ENVELOPE for a
+ message when it already knows the envelope, it can
+ safely ignore the newly transmitted envelope.
+
+ There are three macros which specify commonly-used sets of data
+ items, and can be used instead of data items. A macro must be
+ used by itself, and not in conjunction with other macros or data
+ items.
+
+ ALL
+ Macro equivalent to: (FLAGS INTERNALDATE _R_F_C_8_2_2.SIZE ENVELOPE)
+
+ FAST
+ Macro equivalent to: (FLAGS INTERNALDATE _R_F_C_8_2_2.SIZE)
+
+ FULL
+ Macro equivalent to: (FLAGS INTERNALDATE _R_F_C_8_2_2.SIZE ENVELOPE
+ BODY)
+
+ The currently defined data items that can be fetched are:
+
+ BODY
+ Non-extensible form of BODYSTRUCTURE.
+
+ BODY[<section>]<<partial>>
+ The text of a particular body section. The section
+ specification is a set of zero or more part specifiers
+ delimited by periods. A part specifier is either a part number
+ or one of the following: HEADER, HEADER.FIELDS,
+ HEADER.FIELDS.NOT, MIME, and TEXT. An empty section
+ specification refers to the entire message, including the
+ header.
+
+ Every message has at least one part number. Non-[MIME-IMB]
+ messages, and non-multipart [MIME-IMB] messages with no
+ encapsulated message, only have a part 1.
+
+ Multipart messages are assigned consecutive part numbers, as
+ they occur in the message. If a particular part is of type
+ message or multipart, its parts MUST be indicated by a period
+ followed by the part number within that nested multipart part.
+
+ A part of type MESSAGE/RFC822 also has nested part numbers,
+ referring to parts of the MESSAGE part's body.
+
+ The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, and TEXT part
+ specifiers can be the sole part specifier or can be prefixed by
+ one or more numeric part specifiers, provided that the numeric
+ part specifier refers to a part of type MESSAGE/RFC822. The
+ MIME part specifier MUST be prefixed by one or more numeric
+ part specifiers.
+
+ The HEADER, HEADER.FIELDS, and HEADER.FIELDS.NOT part
+ specifiers refer to the [_R_F_C_-_2_8_2_2] 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 [_R_F_C_-_2_8_2_2]) 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. Subsetting does not
+ exclude the [_R_F_C_-_2_8_2_2] delimiting blank line between the header
+ and the body; the blank line is included in all header fetches,
+ except in the case of a message which has no body and no blank
+ line.
+
+ The MIME part specifier refers to the [MIME-IMB] header for
+ this part.
+
+ The TEXT part specifier refers to the text body of the message,
+ omitting the [_R_F_C_-_2_8_2_2] header.
+
+ Here is an example of a complex message with some of its
+ part specifiers:
+
+ HEADER ([_R_F_C_-_2_8_2_2] header of the message)
+ TEXT ([_R_F_C_-_2_8_2_2] text body of the message) MULTIPART/MIXED
+ 1 TEXT/PLAIN
+ 2 APPLICATION/OCTET-STREAM
+ 3 MESSAGE/RFC822
+ 3.HEADER ([_R_F_C_-_2_8_2_2] header of the message)
+ 3.TEXT ([_R_F_C_-_2_8_2_2] text body of the message) MULTIPART/MIXED
+ 3.1 TEXT/PLAIN
+ 3.2 APPLICATION/OCTET-STREAM
+ 4 MULTIPART/MIXED
+ 4.1 IMAGE/GIF
+ 4.1.MIME ([MIME-IMB] header for the IMAGE/GIF)
+ 4.2 MESSAGE/RFC822
+ 4.2.HEADER ([_R_F_C_-_2_8_2_2] header of the message)
+ 4.2.TEXT ([_R_F_C_-_2_8_2_2] text body of the message) MULTIPART/MIXED
+ 4.2.1 TEXT/PLAIN
+ 4.2.2 MULTIPART/ALTERNATIVE
+ 4.2.2.1 TEXT/PLAIN
+ 4.2.2.2 TEXT/RICHTEXT
+
+ It is possible to fetch a substring of the designated text.
+ This is done by appending an open angle bracket ("<"), the
+ octet position of the first desired octet, a period, the
+ maximum number of octets desired, and a close angle bracket
+ (">") to the part specifier. If the starting octet is beyond
+ the end of the text, an empty string is returned.
+
+ Any partial fetch that attempts to read beyond the end of the
+ text is truncated as appropriate. A partial fetch that starts
+ at octet 0 is returned as a partial fetch, even if this
+ truncation happened.
+
+ Note: This means that BODY[]<0.2048> of a 1500-octet message
+ will return BODY[]<0> with a literal of size 1500, not
+ BODY[].
+
+ Note: A substring fetch of a HEADER.FIELDS or
+ HEADER.FIELDS.NOT part specifier is calculated after
+ subsetting the header.
+
+ The \Seen flag is implicitly set; if this causes the flags to
+ change, they SHOULD be included as part of the FETCH responses.
+
+ BODY.PEEK[<section>]<<partial>>
+ An alternate form of BODY[<section>] that does not implicitly
+ set the \Seen flag.
+
+ BODYSTRUCTURE
+ The [MIME-IMB] body structure of the message. This is computed
+ by the server by parsing the [MIME-IMB] header fields in the
+ [_R_F_C_-_2_8_2_2] header and [MIME-IMB] headers.
+
+ ENVELOPE
+ The envelope structure of the message. This is computed by the
+ server by parsing the [_R_F_C_-_2_8_2_2] header into the component
+ parts, defaulting various fields as necessary.
+
+ FLAGS
+ The flags that are set for this message.
+
+ INTERNALDATE
+ The internal date of the message.
+
+ _R_F_C_8_2_2
+ Functionally equivalent to BODY[], differing in the syntax of
+ the resulting untagged FETCH data (_R_F_C_8_2_2 is returned).
+
+ _R_F_C_8_2_2.HEADER
+ Functionally equivalent to BODY.PEEK[HEADER], differing in the
+ syntax of the resulting untagged FETCH data (_R_F_C_8_2_2.HEADER is
+ returned).
+
+ _R_F_C_8_2_2.SIZE
+ The [_R_F_C_-_2_8_2_2] size of the message.
+
+ _R_F_C_8_2_2.TEXT
+ Functionally equivalent to BODY[TEXT], differing in the syntax
+ of the resulting untagged FETCH data (_R_F_C_8_2_2.TEXT is returned).
+
+ UID
+ The unique identifier for the message.
+
+ Example: C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)])
+ S: * 2 FETCH ....
+ S: * 3 FETCH ....
+ S: * 4 FETCH ....
+ S: A654 OK FETCH completed
+
+6.4.6. STORE Command
+
+ Arguments: sequence set
+ message data item name
+ value for message data item
+
+ Responses: untagged responses: FETCH
+
+ Result: OK - store completed
+ NO - store error: can't store that data
+ BAD - command unknown or arguments invalid
+
+ The STORE command alters data associated with a message in the
+ mailbox. Normally, STORE will return the updated value of the
+ data with an untagged FETCH response. A suffix of ".SILENT" in
+ the data item name prevents the untagged FETCH, and the server
+ SHOULD assume that the client has determined the updated value
+ itself or does not care about the updated value.
+
+ Note: Regardless of whether or not the ".SILENT" suffix
+ was used, the server SHOULD send an untagged FETCH
+ response if a change to a message's flags from an
+ external source is observed. The intent is that the
+ status of the flags is determinate without a race
+ condition.
+
+ The currently defined data items that can be stored are:
+
+ FLAGS <flag list>
+ Replace the flags for the message (other than \Recent) with the
+ argument. The new value of the flags is returned as if a FETCH
+ of those flags was done.
+
+ FLAGS.SILENT <flag list>
+ Equivalent to FLAGS, but without returning a new value.
+
+ +FLAGS <flag list>
+ Add the argument to the flags for the message. The new value
+ of the flags is returned as if a FETCH of those flags was done.
+
+ +FLAGS.SILENT <flag list>
+ Equivalent to +FLAGS, but without returning a new value.
+
+ -FLAGS <flag list>
+ Remove the argument from the flags for the message. The new
+ value of the flags is returned as if a FETCH of those flags was
+ done.
+
+ -FLAGS.SILENT <flag list>
+ Equivalent to -FLAGS, but without returning a new value.
+
+ Example: C: A003 STORE 2:4 +FLAGS (\Deleted)
+ S: * 2 FETCH (FLAGS (\Deleted \Seen))
+ S: * 3 FETCH (FLAGS (\Deleted))
+ S: * 4 FETCH (FLAGS (\Deleted \Flagged \Seen))
+ S: A003 OK STORE completed
+
+6.4.7. COPY Command
+
+ Arguments: sequence set
+ mailbox name
+
+ Responses: no specific responses for this command
+
+ Result: OK - copy completed
+ NO - copy error: can't copy those messages or to that
+ name
+ BAD - command unknown or arguments invalid
+
+ The COPY command copies the specified message(s) to the end of the
+ specified destination mailbox. The flags and internal date of the
+ message(s) SHOULD be preserved, and the Recent flag SHOULD be set,
+ in the copy.
+
+ If the destination mailbox does not exist, a server SHOULD return
+ an error. It SHOULD NOT automatically create the mailbox. Unless
+ it is certain that the destination mailbox can not be created, the
+ server MUST send the response code "[TRYCREATE]" as the prefix of
+ the text of the tagged NO response. This gives a hint to the
+ client that it can attempt a CREATE command and retry the COPY if
+ the CREATE is successful.
+
+ If the COPY command is unsuccessful for any reason, server
+ implementations MUST restore the destination mailbox to its state
+ before the COPY attempt.
+
+ Example: C: A003 COPY 2:4 MEETING
+ S: A003 OK COPY completed
+
+6.4.8. UID Command
+
+ Arguments: command name
+ command arguments
+
+ Responses: untagged responses: FETCH, SEARCH
+
+ Result: OK - UID command completed
+ NO - UID command error
+ BAD - command unknown or arguments invalid
+
+ The UID command has two forms. In the first form, it takes as its
+ arguments a COPY, FETCH, or STORE command with arguments
+ appropriate for the associated command. However, the numbers in
+ the sequence set argument are unique identifiers instead of
+ message sequence numbers. Sequence set ranges are permitted, but
+ there is no guarantee that unique identifiers will be contiguous.
+
+ A non-existent unique identifier is ignored without any error
+ message generated. Thus, it is possible for a UID FETCH command
+ to return an OK without any data or a UID COPY or UID STORE to
+ return an OK without performing any operations.
+
+ In the second form, the UID command takes a SEARCH command with
+ SEARCH command arguments. The interpretation of the arguments is
+ the same as with SEARCH; however, the numbers returned in a SEARCH
+ response for a UID SEARCH command are unique identifiers instead
+
+ of message sequence numbers. For example, the command UID SEARCH
+ 1:100 UID 443:557 returns the unique identifiers corresponding to
+ the intersection of two sequence sets, the message sequence number
+ range 1:100 and the UID range 443:557.
+
+ Note: in the above example, the UID range 443:557
+ appears. The same comment about a non-existent unique
+ identifier being ignored without any error message also
+ applies here. Hence, even if neither UID 443 or 557
+ exist, this range is valid and would include an existing
+ UID 495.
+
+ Also note that a UID range of 559:* always includes the
+ UID of the last message in the mailbox, even if 559 is
+ higher than any assigned UID value. This is because the
+ contents of a range are independent of the order of the
+ range endpoints. Thus, any UID range with * as one of
+ the endpoints indicates at least one message (the
+ message with the highest numbered UID), unless the
+ mailbox is empty.
+
+ The number after the "*" in an untagged FETCH response is always a
+ message sequence number, not a unique identifier, even for a UID
+ command response. However, server implementations MUST implicitly
+ include the UID message data item as part of any FETCH response
+ caused by a UID command, regardless of whether a UID was specified
+ as a message data item to the FETCH.
+
+ Note: The rule about including the UID message data item as part
+ of a FETCH response primarily applies to the UID FETCH and UID
+ STORE commands, including a UID FETCH command that does not
+ include UID as a message data item. Although it is unlikely that
+ the other UID commands will cause an untagged FETCH, this rule
+ applies to these commands as well.
+
+ Example: C: A999 UID FETCH 4827313:4828442 FLAGS
+ S: * 23 FETCH (FLAGS (\Seen) UID 4827313)
+ S: * 24 FETCH (FLAGS (\Seen) UID 4827943)
+ S: * 25 FETCH (FLAGS (\Seen) UID 4828442)
+ S: A999 OK UID FETCH completed
+
+6.5. Client Commands - Experimental/Expansion
+
+6.5.1. X<atom> Command
+
+ Arguments: implementation defined
+
+ Responses: implementation defined
+
+ Result: OK - command completed
+ NO - failure
+ BAD - command unknown or arguments invalid
+
+ Any command prefixed with an X is an experimental command.
+ Commands which are not part of this specification, a standard or
+ standards-track revision of this specification, or an
+ IESG-approved experimental protocol, MUST use the X prefix.
+
+ Any added untagged responses issued by an experimental command
+ MUST also be prefixed with an X. Server implementations MUST NOT
+ send any such untagged responses, unless the client requested it
+ by issuing the associated experimental command.
+
+ Example: C: a441 CAPABILITY
+ S: * CAPABILITY IMAP4rev1 XPIG-LATIN
+ S: a441 OK CAPABILITY completed
+ C: A442 XPIG-LATIN
+ S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay
+ S: A442 OK XPIG-LATIN ompleted-cay
+
+7. Server Responses
+
+ Server responses are in three forms: status responses, server data,
+ and command continuation request. The information contained in a
+ server response, identified by "Contents:" in the response
+ descriptions below, is described by function, not by syntax. The
+ precise syntax of server responses is described in the Formal Syntax
+ section.
+
+ The client MUST be prepared to accept any response at all times.
+
+ Status responses can be tagged or untagged. Tagged status responses
+ indicate the completion result (OK, NO, or BAD status) of a client
+ command, and have a tag matching the command.
+
+ Some status responses, and all server data, are untagged. An
+ untagged response is indicated by the token "*" instead of a tag.
+ Untagged status responses indicate server greeting, or server status
+
+ that does not indicate the completion of a command (for example, an
+ impending system shutdown alert). For historical reasons, untagged
+ server data responses are also called "unsolicited data", although
+ strictly speaking, only unilateral server data is truly
+ "unsolicited".
+
+ Certain server data MUST be recorded by the client when it is
+ received; this is noted in the description of that data. Such data
+ conveys critical information which affects the interpretation of all
+ subsequent commands and responses (e.g., updates reflecting the
+ creation or destruction of messages).
+
+ Other server data SHOULD be recorded for later reference; if the
+ client does not need to record the data, or if recording the data has
+ no obvious purpose (e.g., a SEARCH response when no SEARCH command is
+ in progress), the data SHOULD be ignored.
+
+ An example of unilateral untagged server data occurs when the IMAP
+ connection is in the selected state. In the selected state, the
+ server checks the mailbox for new messages as part of command
+ execution. Normally, this is part of the execution of every command;
+ hence, a NOOP command suffices to check for new messages. If new
+ messages are found, the server sends untagged EXISTS and RECENT
+ responses reflecting the new size of the mailbox. Server
+ implementations that offer multiple simultaneous access to the same
+ mailbox SHOULD also send appropriate unilateral untagged FETCH and
+ EXPUNGE responses if another agent changes the state of any message
+ flags or expunges any messages.
+
+ Command continuation request responses use the token "+" instead of a
+ tag. These responses are sent by the server to indicate acceptance
+ of an incomplete client command and readiness for the remainder of
+ the command.
+
+7.1. Server Responses - Status Responses
+
+ Status responses are OK, NO, BAD, PREAUTH and BYE. OK, NO, and BAD
+ can be tagged or untagged. PREAUTH and BYE are always untagged.
+
+ Status responses MAY include an OPTIONAL "response code". A response
+ code consists of data inside square brackets in the form of an atom,
+ possibly followed by a space and arguments. The response code
+ contains additional information or status codes for client software
+ beyond the OK/NO/BAD condition, and are defined when there is a
+ specific action that a client can take based upon the additional
+ information.
+
+ The currently defined response codes are:
+
+ ALERT
+
+ The human-readable text contains a special alert that MUST be
+ presented to the user in a fashion that calls the user's
+ attention to the message.
+
+ BADCHARSET
+
+ Optionally followed by a parenthesized list of charsets. A
+ SEARCH failed because the given charset is not supported by
+ this implementation. If the optional list of charsets is
+ given, this lists the charsets that are supported by this
+ implementation.
+
+ CAPABILITY
+
+ Followed by a list of capabilities. This can appear in the
+ initial OK or PREAUTH response to transmit an initial
+ capabilities list. This makes it unnecessary for a client to
+ send a separate CAPABILITY command if it recognizes this
+ response.
+
+ PARSE
+
+ The human-readable text represents an error in parsing the
+ [_R_F_C_-_2_8_2_2] header or [MIME-IMB] headers of a message in the
+ mailbox.
+
+ PERMANENTFLAGS
+
+ Followed by a parenthesized list of flags, indicates which of
+ the known flags the client can change permanently. Any flags
+ that are in the FLAGS untagged response, but not the
+ PERMANENTFLAGS list, can not be set permanently. If the client
+ attempts to STORE a flag that is not in the PERMANENTFLAGS
+ list, the server will either ignore the change or store the
+ state change for the remainder of the current session only.
+ The PERMANENTFLAGS list can also include the special flag \*,
+ which indicates that it is possible to create new keywords by
+ attempting to store those flags in the mailbox.
+
+ READ-ONLY
+
+ The mailbox is selected read-only, or its access while selected
+ has changed from read-write to read-only.
+
+ READ-WRITE
+
+ The mailbox is selected read-write, or its access while
+ selected has changed from read-only to read-write.
+
+ TRYCREATE
+
+ An APPEND or COPY attempt is failing because the target mailbox
+ does not exist (as opposed to some other reason). This is a
+ hint to the client that the operation can succeed if the
+ mailbox is first created by the CREATE command.
+
+ UIDNEXT
+
+ Followed by a decimal number, indicates the next unique
+ identifier value. Refer to section 2.3.1.1 for more
+ information.
+
+ UIDVALIDITY
+
+ Followed by a decimal number, indicates the unique identifier
+ validity value. Refer to section 2.3.1.1 for more information.
+
+ UNSEEN
+
+ Followed by a decimal number, indicates the number of the first
+ message without the \Seen flag set.
+
+ Additional response codes defined by particular client or server
+ implementations SHOULD be prefixed with an "X" until they are
+ added to a revision of this protocol. Client implementations
+ SHOULD ignore response codes that they do not recognize.
+
+7.1.1. OK Response
+
+ Contents: OPTIONAL response code
+ human-readable text
+
+ The OK response indicates an information message from the server.
+ When tagged, it indicates successful completion of the associated
+ command. The human-readable text MAY be presented to the user as
+ an information message. The untagged form indicates an
+
+ information-only message; the nature of the information MAY be
+ indicated by a response code.
+
+ The untagged form is also used as one of three possible greetings
+ at connection startup. It indicates that the connection is not
+ yet authenticated and that a LOGIN command is needed.
+
+ Example: S: * OK IMAP4rev1 server ready
+ C: A001 LOGIN fred blurdybloop
+ S: * OK [ALERT] System shutdown in 10 minutes
+ S: A001 OK LOGIN Completed
+
+7.1.2. NO Response
+
+ Contents: OPTIONAL response code
+ human-readable text
+
+ The NO response indicates an operational error message from the
+ server. When tagged, it indicates unsuccessful completion of the
+ associated command. The untagged form indicates a warning; the
+ command can still complete successfully. The human-readable text
+ describes the condition.
+
+ Example: C: A222 COPY 1:2 owatagusiam
+ S: * NO Disk is 98% full, please delete unnecessary data
+ S: A222 OK COPY completed
+ C: A223 COPY 3:200 blurdybloop
+ S: * NO Disk is 98% full, please delete unnecessary data
+ S: * NO Disk is 99% full, please delete unnecessary data
+ S: A223 NO COPY failed: disk is full
+
+7.1.3. BAD Response
+
+ Contents: OPTIONAL response code
+ human-readable text
+
+ The BAD response indicates an error message from the server. When
+ tagged, it reports a protocol-level error in the client's command;
+ the tag indicates the command that caused the error. The untagged
+ form indicates a protocol-level error for which the associated
+ command can not be determined; it can also indicate an internal
+ server failure. The human-readable text describes the condition.
+
+ Example: C: ...very long command line...
+ S: * BAD Command line too long
+ C: ...empty line...
+ S: * BAD Empty command line
+ C: A443 EXPUNGE
+ S: * BAD Disk crash, attempting salvage to a new disk!
+ S: * OK Salvage successful, no data lost
+ S: A443 OK Expunge completed
+
+7.1.4. PREAUTH Response
+
+ Contents: OPTIONAL response code
+ human-readable text
+
+ The PREAUTH response is always untagged, and is one of three
+ possible greetings at connection startup. It indicates that the
+ connection has already been authenticated by external means; thus
+ no LOGIN command is needed.
+
+ Example: S: * PREAUTH IMAP4rev1 server logged in as Smith
+
+7.1.5. BYE Response
+
+ Contents: OPTIONAL response code
+ human-readable text
+
+ The BYE response is always untagged, and indicates that the server
+ is about to close the connection. The human-readable text MAY be
+ displayed to the user in a status report by the client. The BYE
+ response is sent under one of four conditions:
+
+ 1) as part of a normal logout sequence. The server will close
+ the connection after sending the tagged OK response to the
+ LOGOUT command.
+
+ 2) as a panic shutdown announcement. The server closes the
+ connection immediately.
+
+ 3) as an announcement of an inactivity autologout. The server
+ closes the connection immediately.
+
+ 4) as one of three possible greetings at connection startup,
+ indicating that the server is not willing to accept a
+ connection from this client. The server closes the
+ connection immediately.
+
+ The difference between a BYE that occurs as part of a normal
+ LOGOUT sequence (the first case) and a BYE that occurs because of
+ a failure (the other three cases) is that the connection closes
+ immediately in the failure case. In all cases the client SHOULD
+ continue to read response data from the server until the
+ connection is closed; this will ensure that any pending untagged
+ or completion responses are read and processed.
+
+ Example: S: * BYE Autologout; idle for too long
+
+7.2. Server Responses - Server and Mailbox Status
+
+ These responses are always untagged. This is how server and mailbox
+ status data are transmitted from the server to the client. Many of
+ these responses typically result from a command with the same name.
+
+7.2.1. CAPABILITY Response
+
+ Contents: capability listing
+
+ The CAPABILITY response occurs as a result of a CAPABILITY
+ command. The capability listing contains a space-separated
+ listing of capability names that the server supports. The
+ capability listing MUST include the atom "IMAP4rev1".
+
+ In addition, client and server implementations MUST implement the
+ STARTTLS, LOGINDISABLED, and AUTH=PLAIN (described in [IMAP-TLS])
+ capabilities. See the Security Considerations section for
+ important information.
+
+ A capability name which begins with "AUTH=" indicates that the
+ server supports that particular authentication mechanism.
+
+ The LOGINDISABLED capability indicates that the LOGIN command is
+ disabled, and that the server will respond with a tagged NO
+ response to any attempt to use the LOGIN command even if the user
+ name and password are valid. An IMAP client MUST NOT issue the
+ LOGIN command if the server advertises the LOGINDISABLED
+ capability.
+
+ Other capability names indicate that the server supports an
+ extension, revision, or amendment to the IMAP4rev1 protocol.
+ Server responses MUST conform to this document until the client
+ issues a command that uses the associated capability.
+
+ Capability names MUST either begin with "X" or be standard or
+ standards-track IMAP4rev1 extensions, revisions, or amendments
+ registered with IANA. A server MUST NOT offer unregistered or
+
+ non-standard capability names, unless such names are prefixed with
+ an "X".
+
+ Client implementations SHOULD NOT require any capability name
+ other than "IMAP4rev1", and MUST ignore any unknown capability
+ names.
+
+ A server MAY send capabilities automatically, by using the
+ CAPABILITY response code in the initial PREAUTH or OK responses,
+ and by sending an updated CAPABILITY response code in the tagged
+ OK response as part of a successful authentication. It is
+ unnecessary for a client to send a separate CAPABILITY command if
+ it recognizes these automatic capabilities.
+
+ Example: S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI XPIG-LATIN
+
+7.2.2. LIST Response
+
+ Contents: name attributes
+ hierarchy delimiter
+ name
+
+ The LIST response occurs as a result of a LIST command. It
+ returns a single name that matches the LIST specification. There
+ can be multiple LIST responses for a single LIST command.
+
+ Four name attributes are defined:
+
+ \Noinferiors
+ It is not possible for any child levels of hierarchy to exist
+ under this name; no child levels exist now and none can be
+ created in the future.
+
+ \Noselect
+ It is not possible to use this name as a selectable mailbox.
+
+ \Marked
+ The mailbox has been marked "interesting" by the server; the
+ mailbox probably contains messages that have been added since
+ the last time the mailbox was selected.
+
+ \Unmarked
+ The mailbox does not contain any additional messages since the
+ last time the mailbox was selected.
+
+ If it is not feasible for the server to determine whether or not
+ the mailbox is "interesting", or if the name is a \Noselect name,
+ the server SHOULD NOT send either \Marked or \Unmarked.
+
+ The hierarchy delimiter is a character used to delimit levels of
+ hierarchy in a mailbox name. A client can use it to create child
+ mailboxes, and to search higher or lower levels of naming
+ hierarchy. All children of a top-level hierarchy node MUST use
+ the same separator character. A NIL hierarchy delimiter means
+ that no hierarchy exists; the name is a "flat" name.
+
+ The name represents an unambiguous left-to-right hierarchy, and
+ MUST be valid for use as a reference in LIST and LSUB commands.
+ Unless \Noselect is indicated, the name MUST also be valid as an
+ argument for commands, such as SELECT, that accept mailbox names.
+
+ Example: S: * LIST (\Noselect) "/" ~/Mail/foo
+
+7.2.3. LSUB Response
+
+ Contents: name attributes
+ hierarchy delimiter
+ name
+
+ The LSUB response occurs as a result of an LSUB command. It
+ returns a single name that matches the LSUB specification. There
+ can be multiple LSUB responses for a single LSUB command. The
+ data is identical in format to the LIST response.
+
+ Example: S: * LSUB () "." #news.comp.mail.misc
+
+7.2.4 STATUS Response
+
+ Contents: name
+ status parenthesized list
+
+ The STATUS response occurs as a result of an STATUS command. It
+ returns the mailbox name that matches the STATUS specification and
+ the requested mailbox status information.
+
+ Example: S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
+
+7.2.5. SEARCH Response
+
+ Contents: zero or more numbers
+
+ The SEARCH response occurs as a result of a SEARCH or UID SEARCH
+ command. The number(s) refer to those messages that match the
+ search criteria. For SEARCH, these are message sequence numbers;
+ for UID SEARCH, these are unique identifiers. Each number is
+ delimited by a space.
+
+ Example: S: * SEARCH 2 3 6
+
+7.2.6. FLAGS Response
+
+ Contents: flag parenthesized list
+
+ The FLAGS response occurs as a result of a SELECT or EXAMINE
+ command. The flag parenthesized list identifies the flags (at a
+ minimum, the system-defined flags) that are applicable for this
+ mailbox. Flags other than the system flags can also exist,
+ depending on server implementation.
+
+ The update from the FLAGS response MUST be recorded by the client.
+
+ Example: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
+
+7.3. Server Responses - Mailbox Size
+
+ These responses are always untagged. This is how changes in the size
+ of the mailbox are transmitted from the server to the client.
+ Immediately following the "*" token is a number that represents a
+ message count.
+
+7.3.1. EXISTS Response
+
+ Contents: none
+
+ The EXISTS response reports the number of messages in the mailbox.
+ This response occurs as a result of a SELECT or EXAMINE command,
+ and if the size of the mailbox changes (e.g., new messages).
+
+ The update from the EXISTS response MUST be recorded by the
+ client.
+
+ Example: S: * 23 EXISTS
+
+7.3.2. RECENT Response
+
+ Contents: none
+
+ The RECENT response reports the number of messages with the
+ \Recent flag set. This response occurs as a result of a SELECT or
+ EXAMINE command, and if the size of the mailbox changes (e.g., new
+ messages).
+
+ Note: It is not guaranteed that the message sequence
+ numbers of recent messages will be a contiguous range of
+ the highest n messages in the mailbox (where n is the
+ value reported by the RECENT response). Examples of
+ situations in which this is not the case are: multiple
+ clients having the same mailbox open (the first session
+ to be notified will see it as recent, others will
+ probably see it as non-recent), and when the mailbox is
+ re-ordered by a non-IMAP agent.
+
+ The only reliable way to identify recent messages is to
+ look at message flags to see which have the \Recent flag
+ set, or to do a SEARCH RECENT.
+
+ The update from the RECENT response MUST be recorded by the
+ client.
+
+ Example: S: * 5 RECENT
+
+7.4. Server Responses - Message Status
+
+ These responses are always untagged. This is how message data are
+ transmitted from the server to the client, often as a result of a
+ command with the same name. Immediately following the "*" token is a
+ number that represents a message sequence number.
+
+7.4.1. EXPUNGE Response
+
+ Contents: none
+
+ The EXPUNGE response reports that the specified message sequence
+ number has been permanently removed from the mailbox. The message
+ sequence number for each successive message in the mailbox is
+ immediately decremented by 1, and this decrement is reflected in
+ message sequence numbers in subsequent responses (including other
+ untagged EXPUNGE responses).
+
+ The EXPUNGE response also decrements the number of messages in the
+ mailbox; it is not necessary to send an EXISTS response with the
+ new value.
+
+ As a result of the immediate decrement rule, message sequence
+ numbers that appear in a set of successive EXPUNGE responses
+ depend upon whether the messages are removed starting from lower
+ numbers to higher numbers, or from higher numbers to lower
+ numbers. For example, if the last 5 messages in a 9-message
+ mailbox are expunged, a "lower to higher" server will send five
+ untagged EXPUNGE responses for message sequence number 5, whereas
+ a "higher to lower server" will send successive untagged EXPUNGE
+ responses for message sequence numbers 9, 8, 7, 6, and 5.
+
+ An EXPUNGE response MUST NOT be sent when no command is in
+ progress, nor while responding to a FETCH, STORE, or SEARCH
+ command. This rule is necessary to prevent a loss of
+ synchronization of message sequence numbers between client and
+ server. A command is not "in progress" until the complete command
+ has been received; in particular, a command is not "in progress"
+ during the negotiation of command continuation.
+
+ Note: UID FETCH, UID STORE, and UID SEARCH are different
+ commands from FETCH, STORE, and SEARCH. An EXPUNGE
+ response MAY be sent during a UID command.
+
+ The update from the EXPUNGE response MUST be recorded by the
+ client.
+
+ Example: S: * 44 EXPUNGE
+
+7.4.2. FETCH Response
+
+ Contents: message data
+
+ The FETCH response returns data about a message to the client.
+ The data are pairs of data item names and their values in
+ parentheses. This response occurs as the result of a FETCH or
+ STORE command, as well as by unilateral server decision (e.g.,
+ flag updates).
+
+ The current data items are:
+
+ BODY
+ A form of BODYSTRUCTURE without extension data.
+
+ BODY[<section>]<<origin octet>>
+ A string expressing the body contents of the specified section.
+ The string SHOULD be interpreted by the client according to the
+ content transfer encoding, body type, and subtype.
+
+ If the origin octet is specified, this string is a substring of
+ the entire body contents, starting at that origin octet. This
+ means that BODY[]<0> MAY be truncated, but BODY[] is NEVER
+ truncated.
+
+ Note: The origin octet facility MUST NOT be used by a server
+ in a FETCH response unless the client specifically requested
+ it by means of a FETCH of a BODY[<section>]<<partial>> data
+ item.
+
+ 8-bit textual data is permitted if a [CHARSET] identifier is
+ part of the body parameter parenthesized list for this section.
+ Note that headers (part specifiers HEADER or MIME, or the
+ header portion of a MESSAGE/RFC822 part), MUST be 7-bit; 8-bit
+ characters are not permitted in headers. Note also that the
+ [_R_F_C_-_2_8_2_2] delimiting blank line between the header and the
+ body is not affected by header line subsetting; the blank line
+ is always included as part of header data, except in the case
+ of a message which has no body and no blank line.
+
+ Non-textual data such as binary data MUST be transfer encoded
+ into a textual form, such as BASE64, prior to being sent to the
+ client. To derive the original binary data, the client MUST
+ decode the transfer encoded string.
+
+ BODYSTRUCTURE
+ A parenthesized list that describes the [MIME-IMB] body
+ structure of a message. This is computed by the server by
+ parsing the [MIME-IMB] header fields, defaulting various fields
+ as necessary.
+
+ For example, a simple text message of 48 lines and 2279 octets
+ can have a body structure of: ("TEXT" "PLAIN" ("CHARSET"
+ "US-ASCII") NIL NIL "7BIT" 2279 48)
+
+ Multiple parts are indicated by parenthesis nesting. Instead
+ of a body type as the first element of the parenthesized list,
+ there is a sequence of one or more nested body structures. The
+ second element of the parenthesized list is the multipart
+ subtype (mixed, digest, parallel, alternative, etc.).
+
+ For example, a two part message consisting of a text and a
+ BASE64-encoded text attachment can have a body structure of:
+ (("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152
+ 23)("TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" "cc.diff")
+ "<_9_6_0_7_2_3_1_6_3_4_0_7_._2_0_1_1_7_h_@_c_a_c_._w_a_s_h_i_n_g_t_o_n_._e_d_u>" "Compiler diff"
+ "BASE64" 4554 73) "MIXED")
+
+ Extension data follows the multipart subtype. Extension data
+ is never returned with the BODY fetch, but can be returned with
+ a BODYSTRUCTURE fetch. Extension data, if present, MUST be in
+ the defined order. The extension data of a multipart body part
+ are in the following order:
+
+ body parameter parenthesized list
+ A parenthesized list of attribute/value pairs [e.g., ("foo"
+ "bar" "baz" "rag") where "bar" is the value of "foo", and
+ "rag" is the value of "baz"] as defined in [MIME-IMB].
+
+ body disposition
+ A parenthesized list, consisting of a disposition type
+ string, followed by a parenthesized list of disposition
+ attribute/value pairs as defined in [DISPOSITION].
+
+ body language
+ A string or parenthesized list giving the body language
+ value as defined in [LANGUAGE-TAGS].
+
+ body location
+ A string list giving the body content URI as defined in
+ [LOCATION].
+
+ Any following extension data are not yet defined in this
+ version of the protocol. Such extension data can consist of
+ zero or more NILs, strings, numbers, or potentially nested
+ parenthesized lists of such data. Client implementations that
+ do a BODYSTRUCTURE fetch MUST be prepared to accept such
+ extension data. Server implementations MUST NOT send such
+ extension data until it has been defined by a revision of this
+ protocol.
+
+ The basic fields of a non-multipart body part are in the
+ following order:
+
+ body type
+ A string giving the content media type name as defined in
+ [MIME-IMB].
+
+ body subtype
+ A string giving the content subtype name as defined in
+ [MIME-IMB].
+
+ body parameter parenthesized list
+ A parenthesized list of attribute/value pairs [e.g., ("foo"
+ "bar" "baz" "rag") where "bar" is the value of "foo" and
+ "rag" is the value of "baz"] as defined in [MIME-IMB].
+
+ body id
+ A string giving the content id as defined in [MIME-IMB].
+
+ body description
+ A string giving the content description as defined in
+ [MIME-IMB].
+
+ body encoding
+ A string giving the content transfer encoding as defined in
+ [MIME-IMB].
+
+ body size
+ A number giving the size of the body in octets. Note that
+ this size is the size in its transfer encoding and not the
+ resulting size after any decoding.
+
+ A body type of type MESSAGE and subtype _R_F_C_8_2_2 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].
+
+ body location
+ A string list giving the body content URI as defined in
+ [LOCATION].
+
+ Any following extension data are not yet defined in this
+ version of the protocol, and would be as described above under
+ multipart extension data.
+
+ ENVELOPE
+ A parenthesized list that describes the envelope structure of a
+ message. This is computed by the server by parsing the
+ [_R_F_C_-_2_8_2_2] 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.
+
+ [_R_F_C_-_2_8_2_2] 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 _R_F_C_ _8_2_2 syntax). If the mailbox name field is
+ non-NIL, this is a start of group marker, and the mailbox name
+ field holds the group name phrase.
+
+ If the Date, Subject, In-Reply-To, and Message-ID header lines
+ are absent in the [_R_F_C_-_2_8_2_2] header, the corresponding member
+ of the envelope is NIL; if these header lines are present but
+ empty the corresponding member of the envelope is the empty
+ string.
+
+ Note: some servers may return a NIL envelope member in the
+ "present but empty" case. Clients SHOULD treat NIL and
+ empty string as identical.
+
+ Note: [_R_F_C_-_2_8_2_2] requires that all messages have a valid
+ Date header. Therefore, the date member in the envelope can
+ not be NIL or the empty string.
+
+ Note: [_R_F_C_-_2_8_2_2] requires that the In-Reply-To and
+ Message-ID headers, if present, have non-empty content.
+ Therefore, the in-reply-to and message-id members in the
+ envelope can not be the empty string.
+
+ If the From, To, cc, and bcc header lines are absent in the
+ [_R_F_C_-_2_8_2_2] header, or are present but empty, the corresponding
+ member of the envelope is NIL.
+
+ If the Sender or Reply-To lines are absent in the [_R_F_C_-_2_8_2_2]
+ header, or are present but empty, the server sets the
+ corresponding member of the envelope to be the same value as
+ the from member (the client is not expected to know to do
+ this).
+
+ Note: [_R_F_C_-_2_8_2_2] requires that all messages have a valid
+ From header. Therefore, the from, sender, and reply-to
+ members in the envelope can not be NIL.
+
+ FLAGS
+ A parenthesized list of flags that are set for this message.
+
+ INTERNALDATE
+ A string representing the internal date of the message.
+
+ _R_F_C_8_2_2
+ Equivalent to BODY[].
+
+ _R_F_C_8_2_2.HEADER
+ Equivalent to BODY[HEADER]. Note that this did not result in
+ \Seen being set, because _R_F_C_8_2_2.HEADER response data occurs as
+ a result of a FETCH of _R_F_C_8_2_2.HEADER. BODY[HEADER] response
+ data occurs as a result of a FETCH of BODY[HEADER] (which sets
+ \Seen) or BODY.PEEK[HEADER] (which does not set \Seen).
+
+ _R_F_C_8_2_2.SIZE
+ A number expressing the [_R_F_C_-_2_8_2_2] size of the message.
+
+ _R_F_C_8_2_2.TEXT
+ Equivalent to BODY[TEXT].
+
+ UID
+ A number expressing the unique identifier of the message.
+
+ Example: S: * 23 FETCH (FLAGS (\Seen) _R_F_C_8_2_2.SIZE 44827)
+
+7.5. Server Responses - Command Continuation Request
+
+ The command continuation request response is indicated by a "+" token
+ instead of a tag. This form of response indicates that the server is
+ ready to accept the continuation of a command from the client. The
+ remainder of this response is a line of text.
+
+ This response is used in the AUTHENTICATE command to transmit server
+ data to the client, and request additional client data. This
+ response is also used if an argument to any command is a literal.
+
+ The client is not permitted to send the octets of the literal unless
+ the server indicates that it is expected. This permits the server to
+ process commands and reject errors on a line-by-line basis. The
+ remainder of the command, including the CRLF that terminates a
+ command, follows the octets of the literal. If there are any
+ additional command arguments, the literal octets are followed by a
+ space and those arguments.
+
+ Example: C: A001 LOGIN {11}
+ S: + Ready for additional command text
+ C: FRED FOOBAR {7}
+ S: + Ready for additional command text
+ C: fat man
+ S: A001 OK LOGIN completed
+ C: A044 BLURDYBLOOP {102856}
+ S: A044 BAD No such command as "BLURDYBLOOP"
+
+8. Sample IMAP4rev1 connection
+
+ The following is a transcript of an IMAP4rev1 connection. A long
+ line in this sample is broken for editorial clarity.
+
+S: * OK IMAP4rev1 Service Ready
+C: a001 login mrc secret
+S: a001 OK LOGIN completed
+C: a002 select inbox
+S: * 18 EXISTS
+S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
+S: * 2 RECENT
+S: * OK [UNSEEN 17] Message 17 is the first unseen message
+S: * OK [UIDVALIDITY 3857529045] UIDs valid
+S: a002 OK [READ-WRITE] SELECT completed
+C: a003 fetch 12 full
+S: * 12 FETCH (FLAGS (\Seen) INTERNALDATE "17-Jul-1996 02:44:25 -0700"
+ _R_F_C_8_2_2.SIZE 4286 ENVELOPE ("Wed, 17 Jul 1996 02:23:25 -0700 (PDT)"
+ "IMAP4rev1 WG mtg summary and minutes"
+ (("Terry Gray" NIL "gray" "cac.washington.edu"))
+ (("Terry Gray" NIL "gray" "cac.washington.edu"))
+ (("Terry Gray" NIL "gray" "cac.washington.edu"))
+ ((NIL NIL "imap" "cac.washington.edu"))
+ ((NIL NIL "minutes" "CNRI.Reston.VA.US")
+ ("John Klensin" NIL "KLENSIN" "MIT.EDU")) NIL NIL
+ "<_B_2_7_3_9_7_-_0_1_0_0_0_0_0_@_c_a_c_._w_a_s_h_i_n_g_t_o_n_._e_d_u>")
+ BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028
+ 92))
+S: a003 OK FETCH completed
+C: a004 fetch 12 body[header]
+S: * 12 FETCH (BODY[HEADER] {342}
+S: Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)
+S: From: Terry Gray <_g_r_a_y_@_c_a_c_._w_a_s_h_i_n_g_t_o_n_._e_d_u>
+S: Subject: IMAP4rev1 WG mtg summary and minutes
+S: To: _i_m_a_p_@_c_a_c_._w_a_s_h_i_n_g_t_o_n_._e_d_u
+S: cc: _m_i_n_u_t_e_s_@_C_N_R_I_._R_e_s_t_o_n_._V_A_._U_S, John Klensin <_K_L_E_N_S_I_N_@_M_I_T_._E_D_U>
+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 (ABNF) notation as specified in [ABNF].
+
+ In the case of alternative or optional rules in which a later rule
+ overlaps an earlier rule, the rule which is listed earlier MUST take
+ priority. For example, "\Seen" when parsed as a flag is the \Seen
+ flag name and not a flag-extension, even though "\Seen" can be parsed
+ as a flag-extension. Some, but not all, instances of this rule are
+ noted below.
+
+ Note: [ABNF] rules MUST be followed strictly; in
+ particular:
+
+ (1) Except as noted otherwise, all alphabetic characters
+ are case-insensitive. The use of upper or lower case
+ characters to define token strings is for editorial clarity
+ only. Implementations MUST accept these strings in a
+ case-insensitive fashion.
+
+ (2) In all cases, SP refers to exactly one space. It is
+ NOT permitted to substitute TAB, insert additional spaces,
+ or otherwise treat SP as being equivalent to LWSP.
+
+ (3) The ASCII NUL character, %x00, MUST NOT be used at any
+ time.
+
+address = "(" addr-name SP addr-adl SP addr-mailbox SP
+ addr-host ")"
+
+addr-adl = nstring
+ ; Holds route from [_R_F_C_-_2_8_2_2] route-addr if
+ ; non-NIL
+
+addr-host = nstring
+ ; NIL indicates [_R_F_C_-_2_8_2_2] group syntax.
+ ; Otherwise, holds [_R_F_C_-_2_8_2_2] domain name
+
+addr-mailbox = nstring
+ ; NIL indicates end of [_R_F_C_-_2_8_2_2] group; if
+ ; non-NIL and addr-host is NIL, holds
+ ; [_R_F_C_-_2_8_2_2] group name.
+ ; Otherwise, holds [_R_F_C_-_2_8_2_2] local-part
+ ; after removing [_R_F_C_-_2_8_2_2] quoting
+
+addr-name = nstring
+ ; If non-NIL, holds phrase from [_R_F_C_-_2_8_2_2]
+ ; mailbox after removing [_R_F_C_-_2_8_2_2] quoting
+
+append = "APPEND" SP mailbox [SP flag-list] [SP date-time] SP
+ literal
+
+astring = 1*ASTRING-CHAR / string
+
+ASTRING-CHAR = ATOM-CHAR / resp-specials
+
+atom = 1*ATOM-CHAR
+
+ATOM-CHAR = <any CHAR except atom-specials>
+
+atom-specials = "(" / ")" / "{" / SP / CTL / list-wildcards /
+ quoted-specials / resp-specials
+
+authenticate = "AUTHENTICATE" SP auth-type *(CRLF base64)
+
+auth-type = atom
+ ; Defined by [SASL]
+
+base64 = *(4base64-char) [base64-terminal]
+
+base64-char = ALPHA / DIGIT / "+" / "/"
+ ; Case-sensitive
+
+base64-terminal = (2base64-char "==") / (3base64-char "=")
+
+body = "(" (body-type-1part / body-type-mpart) ")"
+
+body-extension = nstring / number /
+ "(" body-extension *(SP body-extension) ")"
+ ; Future expansion. Client implementations
+ ; MUST accept body-extension fields. Server
+ ; implementations MUST NOT generate
+ ; body-extension fields except as defined by
+ ; future standard or standards-track
+ ; revisions of this specification.
+
+body-ext-1part = body-fld-md5 [SP body-fld-dsp [SP body-fld-lang
+ [SP body-fld-loc *(SP body-extension)]]]
+ ; MUST NOT be returned on non-extensible
+ ; "BODY" fetch
+
+body-ext-mpart = body-fld-param [SP body-fld-dsp [SP body-fld-lang
+ [SP body-fld-loc *(SP body-extension)]]]
+ ; MUST NOT be returned on non-extensible
+ ; "BODY" fetch
+
+body-fields = body-fld-param SP body-fld-id SP body-fld-desc SP
+ body-fld-enc SP body-fld-octets
+
+body-fld-desc = nstring
+
+body-fld-dsp = "(" string SP body-fld-param ")" / nil
+
+body-fld-enc = (DQUOTE ("7BIT" / "8BIT" / "BINARY" / "BASE64"/
+ "QUOTED-PRINTABLE") DQUOTE) / string
+
+body-fld-id = nstring
+
+body-fld-lang = nstring / "(" string *(SP string) ")"
+
+body-fld-loc = nstring
+
+body-fld-lines = number
+
+body-fld-md5 = nstring
+
+body-fld-octets = number
+
+body-fld-param = "(" string SP string *(SP string SP string) ")" / nil
+
+body-type-1part = (body-type-basic / body-type-msg / body-type-text)
+ [SP body-ext-1part]
+
+body-type-basic = media-basic SP body-fields
+ ; MESSAGE subtype MUST NOT be "_R_F_C_8_2_2"
+
+body-type-mpart = 1*body SP media-subtype
+ [SP body-ext-mpart]
+
+body-type-msg = media-message SP body-fields SP envelope
+ SP body SP body-fld-lines
+
+body-type-text = media-text SP body-fields SP body-fld-lines
+
+capability = ("AUTH=" auth-type) / atom
+ ; New capabilities MUST begin with "X" or be
+ ; registered with IANA as standard or
+ ; standards-track
+
+capability-data = "CAPABILITY" *(SP capability) SP "IMAP4rev1"
+ *(SP capability)
+ ; Servers MUST implement the STARTTLS, AUTH=PLAIN,
+ ; and LOGINDISABLED capabilities
+ ; Servers which offer _R_F_C_ _1_7_3_0 compatibility MUST
+ ; list "IMAP4" as the first capability.
+
+CHAR8 = %x01-ff
+ ; any OCTET except NUL, %x00
+
+command = tag SP (command-any / command-auth / command-nonauth /
+ command-select) CRLF
+ ; Modal based on state
+
+command-any = "CAPABILITY" / "LOGOUT" / "NOOP" / x-command
+ ; Valid in all states
+
+command-auth = append / create / delete / examine / list / lsub /
+ rename / select / status / subscribe / unsubscribe
+ ; Valid only in Authenticated or Selected state
+
+command-nonauth = login / authenticate / "STARTTLS"
+ ; Valid only when in Not Authenticated state
+
+command-select = "CHECK" / "CLOSE" / "EXPUNGE" / copy / fetch / store /
+ uid / search
+ ; Valid only when in Selected state
+
+continue-req = "+" SP (resp-text / base64) CRLF
+
+copy = "COPY" SP sequence-set SP mailbox
+
+create = "CREATE" SP mailbox
+ ; Use of INBOX gives a NO error
+
+date = date-text / DQUOTE date-text DQUOTE
+
+date-day = 1*2DIGIT
+ ; Day of month
+
+date-day-fixed = (SP DIGIT) / 2DIGIT
+ ; Fixed-format version of date-day
+
+date-month = "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" /
+ "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec"
+
+date-text = date-day "-" date-month "-" date-year
+
+date-year = 4DIGIT
+
+date-time = DQUOTE date-day-fixed "-" date-month "-" date-year
+ SP time SP zone DQUOTE
+
+delete = "DELETE" SP mailbox
+ ; Use of INBOX gives a NO error
+
+digit-nz = %x31-39
+ ; 1-9
+
+envelope = "(" env-date SP env-subject SP env-from SP
+ env-sender SP env-reply-to SP env-to SP env-cc SP
+ env-bcc SP env-in-reply-to SP env-message-id ")"
+
+env-bcc = "(" 1*address ")" / nil
+
+env-cc = "(" 1*address ")" / nil
+
+env-date = nstring
+
+env-from = "(" 1*address ")" / nil
+
+env-in-reply-to = nstring
+
+env-message-id = nstring
+
+env-reply-to = "(" 1*address ")" / nil
+
+env-sender = "(" 1*address ")" / nil
+
+env-subject = nstring
+
+env-to = "(" 1*address ")" / nil
+
+examine = "EXAMINE" SP mailbox
+
+fetch = "FETCH" SP sequence-set SP ("ALL" / "FULL" / "FAST" /
+ fetch-att / "(" fetch-att *(SP fetch-att) ")")
+
+fetch-att = "ENVELOPE" / "FLAGS" / "INTERNALDATE" /
+ "_R_F_C_8_2_2" [".HEADER" / ".SIZE" / ".TEXT"] /
+ "BODY" ["STRUCTURE"] / "UID" /
+ "BODY" section ["<" number "." nz-number ">"] /
+ "BODY.PEEK" section ["<" number "." nz-number ">"]
+
+flag = "\Answered" / "\Flagged" / "\Deleted" /
+ "\Seen" / "\Draft" / flag-keyword / flag-extension
+ ; Does not include "\Recent"
+
+flag-extension = "\" atom
+ ; Future expansion. Client implementations
+ ; MUST accept flag-extension flags. Server
+ ; implementations MUST NOT generate
+ ; flag-extension flags except as defined by
+ ; future standard or standards-track
+ ; revisions of this specification.
+
+flag-fetch = flag / "\Recent"
+
+flag-keyword = atom
+
+flag-list = "(" [flag *(SP flag)] ")"
+
+flag-perm = flag / "\*"
+
+greeting = "*" SP (resp-cond-auth / resp-cond-bye) CRLF
+
+header-fld-name = astring
+
+header-list = "(" header-fld-name *(SP header-fld-name) ")"
+
+list = "LIST" SP mailbox SP list-mailbox
+
+list-mailbox = 1*list-char / string
+
+list-char = ATOM-CHAR / list-wildcards / resp-specials
+
+list-wildcards = "%" / "*"
+
+literal = "{" number "}" CRLF *CHAR8
+ ; Number represents the number of CHAR8s
+
+login = "LOGIN" SP userid SP password
+
+lsub = "LSUB" SP mailbox SP list-mailbox
+
+mailbox = "INBOX" / astring
+ ; INBOX is case-insensitive. All case variants of
+ ; INBOX (e.g., "iNbOx") MUST be interpreted as INBOX
+ ; not as an astring. An astring which consists of
+ ; the case-insensitive sequence "I" "N" "B" "O" "X"
+ ; is considered to be INBOX and not an astring.
+ ; Refer to section 5.1 for further
+ ; semantic details of mailbox names.
+
+mailbox-data = "FLAGS" SP flag-list / "LIST" SP mailbox-list /
+ "LSUB" SP mailbox-list / "SEARCH" *(SP nz-number) /
+ "STATUS" SP mailbox SP "(" [status-att-list] ")" /
+ number SP "EXISTS" / number SP "RECENT"
+
+mailbox-list = "(" [mbx-list-flags] ")" SP
+ (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox
+
+mbx-list-flags = *(mbx-list-oflag SP) mbx-list-sflag
+ *(SP mbx-list-oflag) /
+ mbx-list-oflag *(SP mbx-list-oflag)
+
+mbx-list-oflag = "\Noinferiors" / flag-extension
+ ; Other flags; multiple possible per LIST response
+
+mbx-list-sflag = "\Noselect" / "\Marked" / "\Unmarked"
+ ; Selectability flags; only one per LIST response
+
+media-basic = ((DQUOTE ("APPLICATION" / "AUDIO" / "IMAGE" /
+ "MESSAGE" / "VIDEO") DQUOTE) / string) SP
+ media-subtype
+ ; Defined in [MIME-IMT]
+
+media-message = DQUOTE "MESSAGE" DQUOTE SP DQUOTE "_R_F_C_8_2_2" DQUOTE
+ ; Defined in [MIME-IMT]
+
+media-subtype = string
+ ; Defined in [MIME-IMT]
+
+media-text = DQUOTE "TEXT" DQUOTE SP media-subtype
+ ; Defined in [MIME-IMT]
+
+message-data = nz-number SP ("EXPUNGE" / ("FETCH" SP msg-att))
+
+msg-att = "(" (msg-att-dynamic / msg-att-static)
+ *(SP (msg-att-dynamic / msg-att-static)) ")"
+
+msg-att-dynamic = "FLAGS" SP "(" [flag-fetch *(SP flag-fetch)] ")"
+ ; MAY change for a message
+
+msg-att-static = "ENVELOPE" SP envelope / "INTERNALDATE" SP date-time /
+ "_R_F_C_8_2_2" [".HEADER" / ".TEXT"] SP nstring /
+ "_R_F_C_8_2_2.SIZE" SP number /
+ "BODY" ["STRUCTURE"] SP body /
+ "BODY" section ["<" number ">"] SP nstring /
+ "UID" SP uniqueid
+ ; MUST NOT change for a message
+
+nil = "NIL"
+
+nstring = string / nil
+
+number = 1*DIGIT
+ ; Unsigned 32-bit integer
+ ; (0 <= n < 4,294,967,296)
+
+nz-number = digit-nz *DIGIT
+ ; Non-zero unsigned 32-bit integer
+ ; (0 < n < 4,294,967,296)
+
+password = astring
+
+quoted = DQUOTE *QUOTED-CHAR DQUOTE
+
+QUOTED-CHAR = <any TEXT-CHAR except quoted-specials> /
+ "\" quoted-specials
+
+quoted-specials = DQUOTE / "\"
+
+rename = "RENAME" SP mailbox SP mailbox
+ ; Use of INBOX as a destination gives a NO error
+
+response = *(continue-req / response-data) response-done
+
+response-data = "*" SP (resp-cond-state / resp-cond-bye /
+ mailbox-data / message-data / capability-data) CRLF
+
+response-done = response-tagged / response-fatal
+
+response-fatal = "*" SP resp-cond-bye CRLF
+ ; Server closes connection immediately
+
+response-tagged = tag SP resp-cond-state CRLF
+
+resp-cond-auth = ("OK" / "PREAUTH") SP resp-text
+ ; Authentication condition
+
+resp-cond-bye = "BYE" SP resp-text
+
+resp-cond-state = ("OK" / "NO" / "BAD") SP resp-text
+ ; Status condition
+
+resp-specials = "]"
+
+resp-text = ["[" resp-text-code "]" SP] text
+
+resp-text-code = "ALERT" /
+ "BADCHARSET" [SP "(" astring *(SP astring) ")" ] /
+ capability-data / "PARSE" /
+ "PERMANENTFLAGS" SP "("
+ [flag-perm *(SP flag-perm)] ")" /
+ "READ-ONLY" / "READ-WRITE" / "TRYCREATE" /
+ "UIDNEXT" SP nz-number / "UIDVALIDITY" SP nz-number /
+ "UNSEEN" SP nz-number /
+ atom [SP 1*<any TEXT-CHAR except "]">]
+
+search = "SEARCH" [SP "CHARSET" SP astring] 1*(SP search-key)
+ ; CHARSET argument to MUST be registered with IANA
+
+search-key = "ALL" / "ANSWERED" / "BCC" SP astring /
+ "BEFORE" SP date / "BODY" SP astring /
+ "CC" SP astring / "DELETED" / "FLAGGED" /
+ "FROM" SP astring / "KEYWORD" SP flag-keyword /
+ "NEW" / "OLD" / "ON" SP date / "RECENT" / "SEEN" /
+ "SINCE" SP date / "SUBJECT" SP astring /
+ "TEXT" SP astring / "TO" SP astring /
+ "UNANSWERED" / "UNDELETED" / "UNFLAGGED" /
+ "UNKEYWORD" SP flag-keyword / "UNSEEN" /
+ ; Above this line were in [IMAP2]
+ "DRAFT" / "HEADER" SP header-fld-name SP astring /
+ "LARGER" SP number / "NOT" SP search-key /
+ "OR" SP search-key SP search-key /
+ "SENTBEFORE" SP date / "SENTON" SP date /
+ "SENTSINCE" SP date / "SMALLER" SP number /
+ "UID" SP sequence-set / "UNDRAFT" / sequence-set /
+ "(" search-key *(SP search-key) ")"
+
+section = "[" [section-spec] "]"
+
+section-msgtext = "HEADER" / "HEADER.FIELDS" [".NOT"] SP header-list /
+ "TEXT"
+ ; top-level or MESSAGE/RFC822 part
+
+section-part = nz-number *("." nz-number)
+ ; body part nesting
+
+section-spec = section-msgtext / (section-part ["." section-text])
+
+section-text = section-msgtext / "MIME"
+ ; text other than actual body part (headers, etc.)
+
+select = "SELECT" SP mailbox
+
+seq-number = nz-number / "*"
+ ; message sequence number (COPY, FETCH, STORE
+ ; commands) or unique identifier (UID COPY,
+ ; UID FETCH, UID STORE commands).
+ ; * represents the largest number in use. In
+ ; the case of message sequence numbers, it is
+ ; the number of messages in a non-empty mailbox.
+ ; In the case of unique identifiers, it is the
+ ; unique identifier of the last message in the
+ ; mailbox or, if the mailbox is empty, the
+ ; mailbox's current UIDNEXT value.
+ ; The server should respond with a tagged BAD
+ ; response to a command that uses a message
+ ; sequence number greater than the number of
+ ; messages in the selected mailbox. This
+ ; includes "*" if the selected mailbox is empty.
+
+seq-range = seq-number ":" seq-number
+ ; two seq-number values and all values between
+ ; these two regardless of order.
+ ; Example: 2:4 and 4:2 are equivalent and indicate
+ ; values 2, 3, and 4.
+ ; Example: a unique identifier sequence range of
+ ; 3291:* includes the UID of the last message in
+ ; the mailbox, even if that value is less than 3291.
+
+sequence-set = (seq-number / seq-range) *("," sequence-set)
+ ; set of seq-number values, regardless of order.
+ ; Servers MAY coalesce overlaps and/or execute the
+ ; sequence in any order.
+ ; Example: a message sequence number set of
+ ; 2,4:7,9,12:* for a mailbox with 15 messages is
+ ; equivalent to 2,4,5,6,7,9,12,13,14,15
+ ; Example: a message sequence number set of *:4,5:7
+ ; for a mailbox with 10 messages is equivalent to
+ ; 10,9,8,7,6,5,4,5,6,7 and MAY be reordered and
+ ; overlap coalesced to be 4,5,6,7,8,9,10.
+
+status = "STATUS" SP mailbox SP
+ "(" status-att *(SP status-att) ")"
+
+status-att = "MESSAGES" / "RECENT" / "UIDNEXT" / "UIDVALIDITY" /
+ "UNSEEN"
+
+status-att-list = status-att SP number *(SP status-att SP number)
+
+store = "STORE" SP sequence-set SP store-att-flags
+
+store-att-flags = (["+" / "-"] "FLAGS" [".SILENT"]) SP
+ (flag-list / (flag *(SP flag)))
+
+string = quoted / literal
+
+subscribe = "SUBSCRIBE" SP mailbox
+
+tag = 1*<any ASTRING-CHAR except "+">
+
+text = 1*TEXT-CHAR
+
+TEXT-CHAR = <any CHAR except CR and LF>
+
+time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
+ ; Hours minutes seconds
+
+uid = "UID" SP (copy / fetch / search / store)
+ ; Unique identifiers used instead of message
+ ; sequence numbers
+
+uniqueid = nz-number
+ ; Strictly ascending
+
+unsubscribe = "UNSUBSCRIBE" SP mailbox
+
+userid = astring
+
+x-command = "X" atom <experimental command arguments>
+
+zone = ("+" / "-") 4DIGIT
+ ; Signed four-digit value of hhmm representing
+ ; hours and minutes east of Greenwich (that is,
+ ; the amount that the given time differs from
+ ; Universal Time). Subtracting the timezone
+ ; from the given time will give the UT form.
+ ; The Universal Time zone is "+0000".
+
+10. Author's Note
+
+ This document is a revision or rewrite of earlier documents, and
+ supercedes the protocol specification in those documents: _R_F_C_ _2_0_6_0,
+ _R_F_C_ _1_7_3_0, unpublished IMAP2bis.TXT document, _R_F_C_ _1_1_7_6, and _R_F_C_ _1_0_6_4.
+
+11. Security Considerations
+
+ IMAP4rev1 protocol transactions, including electronic mail data, are
+ sent in the clear over the network unless protection from snooping is
+ negotiated. This can be accomplished either by the use of STARTTLS,
+ negotiated privacy protection in the AUTHENTICATE command, or some
+ other protection mechanism.
+
+11.1. STARTTLS Security Considerations
+
+ The specification of the STARTTLS command and LOGINDISABLED
+ capability in this document replaces that in [IMAP-TLS]. [IMAP-TLS]
+ remains normative for the PLAIN [SASL] authenticator.
+
+ IMAP client and server implementations MUST implement the
+ TLS_RSA_WITH_RC4_128_MD5 [TLS] cipher suite, and SHOULD implement the
+ TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] cipher suite. This is
+ important as it assures that any two compliant implementations can be
+ configured to interoperate. All other cipher suites are OPTIONAL.
+ Note that this is a change from section 2.1 of [IMAP-TLS].
+
+ During the [TLS] negotiation, the client MUST check its understanding
+ of the server hostname against the server's identity as presented in
+ the server Certificate message, in order to prevent man-in-the-middle
+ attacks. If the match fails, the client SHOULD either ask for
+ explicit user confirmation, or terminate the connection and indicate
+ that the server's identity is suspect. Matching is performed
+ according to these rules:
+
+ The client MUST use the server hostname it used to open the
+ connection as the value to compare against the server name
+ as expressed in the server certificate. The client MUST
+ NOT use any form of the server hostname derived from an
+ insecure remote source (e.g., insecure DNS lookup). CNAME
+ canonicalization is not done.
+
+ If a subjectAltName extension of type dNSName is present in
+ the certificate, it SHOULD be used as the source of the
+ server's identity.
+
+ Matching is case-insensitive.
+
+ A "*" wildcard character MAY be used as the left-most name
+ component in the certificate. For example, *.example.com
+ would match a.example.com, foo.example.com, etc. but would
+ not match example.com.
+
+ If the certificate contains multiple names (e.g., more than
+ one dNSName field), then a match with any one of the fields
+ is considered acceptable.
+
+ Both the client and server MUST check the result of the STARTTLS
+ command and subsequent [TLS] negotiation to see whether acceptable
+ authentication or privacy was achieved.
+
+11.2. Other Security Considerations
+
+ A server error message for an AUTHENTICATE command which fails due to
+ invalid credentials SHOULD NOT detail why the credentials are
+ invalid.
+
+ Use of the LOGIN command sends passwords in the clear. This can be
+ avoided by using the AUTHENTICATE command with a [SASL] mechanism
+ that does not use plaintext passwords, by first negotiating
+ encryption via STARTTLS or some other protection mechanism.
+
+ A server implementation MUST implement a configuration that, at the
+ time of authentication, requires:
+ (1) The STARTTLS command has been negotiated.
+ OR
+ (2) Some other mechanism that protects the session from password
+ snooping has been provided.
+ OR
+ (3) The following measures are in place:
+ (a) The LOGINDISABLED capability is advertised, and [SASL]
+ mechanisms (such as PLAIN) using plaintext passwords are NOT
+ advertised in the CAPABILITY list.
+ AND
+ (b) The LOGIN command returns an error even if the password is
+ correct.
+ AND
+ (c) The AUTHENTICATE command returns an error with all [SASL]
+ mechanisms that use plaintext passwords, even if the password
+ is correct.
+
+ A server error message for a failing LOGIN command SHOULD NOT specify
+ that the user name, as opposed to the password, is invalid.
+
+ A server SHOULD have mechanisms in place to limit or delay failed
+ AUTHENTICATE/LOGIN attempts.
+
+ Additional security considerations are discussed in the section
+ discussing the AUTHENTICATE and LOGIN commands.
+
+12. IANA Considerations
+
+ IMAP4 capabilities are registered by publishing a standards track or
+ IESG approved experimental RFC. The registry is currently located
+ at:
+
+ _h_t_t_p_:_/_/_w_w_w_._i_a_n_a_._o_r_g_/_a_s_s_i_g_n_m_e_n_t_s_/_i_m_a_p_4_-_c_a_p_a_b_i_l_i_t_i_e_s
+
+ As this specification revises the STARTTLS and LOGINDISABLED
+ extensions previously defined in [IMAP-TLS], the registry will be
+ updated accordingly.
+
+Appendices
+
+A. Normative References
+
+ The following documents contain definitions or specifications that
+ are necessary to understand this document properly:
+ [ABNF] Crocker, D. and P. Overell, "Augmented BNF for
+ Syntax Specifications: ABNF", _R_F_C_ _2_2_3_4,
+ November 1997.
+
+ [ANONYMOUS] Newman, C., "Anonymous SASL Mechanism", RFC
+ 2245, November 1997.
+
+ [CHARSET] Freed, N. and J. Postel, "IANA Character Set
+ Registration Procedures", _R_F_C_ _2_9_7_8, October
+ 2000.
+
+ [DIGEST-MD5] Leach, P. and C. Newman, "Using Digest
+ Authentication as a SASL Mechanism", _R_F_C_ _2_8_3_1,
+ May 2000.
+
+ [DISPOSITION] Troost, R., Dorner, S. and K. Moore,
+ "Communicating Presentation Information in
+ Internet Messages: The Content-Disposition
+ Header", _R_F_C_ _2_1_8_3, August 1997.
+
+ [IMAP-TLS] Newman, C., "Using TLS with IMAP, POP3 and
+ ACAP", _R_F_C_ _2_5_9_5, June 1999.
+
+ [KEYWORDS] Bradner, S., "Key words for use in RFCs to
+ Indicate Requirement Levels", BCP 14, _R_F_C_ _2_1_1_9,
+ March 1997.
+
+ [LANGUAGE-TAGS] Alvestrand, H., "Tags for the Identification of
+ Languages", BCP 47, _R_F_C_ _3_0_6_6, January 2001.
+
+ [LOCATION] Palme, J., Hopmann, A. and N. Shelness, "MIME
+ Encapsulation of Aggregate Documents, such as
+ HTML (MHTML)", _R_F_C_ _2_5_5_7, March 1999.
+
+ [MD5] Myers, J. and M. Rose, "The Content-MD5 Header
+ Field", _R_F_C_ _1_8_6_4, October 1995.
+
+ [MIME-HDRS] Moore, K., "MIME (Multipurpose Internet Mail
+ Extensions) Part Three: Message Header
+ Extensions for Non-ASCII Text", _R_F_C_ _2_0_4_7,
+ November 1996.
+
+ [MIME-IMB] Freed, N. and N. Borenstein, "MIME
+ (Multipurpose Internet Mail Extensions) Part
+ One: Format of Internet Message Bodies", RFC
+ 2045, November 1996.
+
+ [MIME-IMT] Freed, N. and N. Borenstein, "MIME
+ (Multipurpose Internet Mail Extensions) Part
+ Two: Media Types", _R_F_C_ _2_0_4_6, November 1996.
+
+ [_R_F_C_-_2_8_2_2] Resnick, P., "Internet Message Format", RFC
+ 2822, April 2001.
+
+ [SASL] Myers, J., "Simple Authentication and Security
+ Layer (SASL)", _R_F_C_ _2_2_2_2, October 1997.
+
+ [TLS] Dierks, T. and C. Allen, "The TLS Protocol
+ Version 1.0", _R_F_C_ _2_2_4_6, January 1999.
+
+ [UTF-7] Goldsmith, D. and M. Davis, "UTF-7: A Mail-Safe
+ Transformation Format of Unicode", _R_F_C_ _2_1_5_2,
+ May 1997.
+
+ The following documents describe quality-of-implementation issues
+ that should be carefully considered when implementing this protocol:
+
+ [IMAP-IMPLEMENTATION] Leiba, B., "IMAP Implementation
+ Recommendations", _R_F_C_ _2_6_8_3, September 1999.
+
+ [IMAP-MULTIACCESS] Gahrns, M., "IMAP4 Multi-Accessed Mailbox
+ Practice", _R_F_C_ _2_1_8_0, July 1997.
+
+A.1 Informative References
+
+ The following documents describe related protocols:
+
+ [IMAP-DISC] Austein, R., "Synchronization Operations for
+ Disconnected IMAP4 Clients", Work in Progress.
+
+ [IMAP-MODEL] Crispin, M., "Distributed Electronic Mail
+ Models in IMAP4", _R_F_C_ _1_7_3_3, December 1994.
+
+ [ACAP] Newman, C. and J. Myers, "ACAP -- Application
+ Configuration Access Protocol", _R_F_C_ _2_2_4_4,
+ November 1997.
+
+ [SMTP] Klensin, J., "Simple Mail Transfer Protocol",
+ STD 10, _R_F_C_ _2_8_2_1, April 2001.
+
+ The following documents are historical or describe historical aspects
+ of this protocol:
+
+ [IMAP-COMPAT] Crispin, M., "IMAP4 Compatibility with
+ IMAP2bis", _R_F_C_ _2_0_6_1, December 1996.
+
+ [IMAP-HISTORICAL] Crispin, M., "IMAP4 Compatibility with IMAP2
+ and IMAP2bis", _R_F_C_ _1_7_3_2, December 1994.
+
+ [IMAP-OBSOLETE] Crispin, M., "Internet Message Access Protocol
+ - Obsolete Syntax", _R_F_C_ _2_0_6_2, December 1996.
+
+ [IMAP2] Crispin, M., "Interactive Mail Access Protocol
+ - Version 2", _R_F_C_ _1_1_7_6, August 1990.
+
+ [_R_F_C_-_8_2_2] Crocker, D., "Standard for the Format of ARPA
+ Internet Text Messages", STD 11, _R_F_C_ _8_2_2,
+ August 1982.
+
+ [_R_F_C_-_8_2_1] Postel, J., "Simple Mail Transfer Protocol",
+ STD 10, _R_F_C_ _8_2_1, August 1982.
+
+B. Changes from _R_F_C_ _2_0_6_0
+
+ 1) Clarify description of unique identifiers and their semantics.
+
+ 2) Fix the SELECT description to clarify that UIDVALIDITY is required
+ in the SELECT and EXAMINE responses.
+
+ 3) Added an example of a failing search.
+
+ 4) Correct store-att-flags: "#flag" should be "1#flag".
+
+ 5) Made search and section rules clearer.
+
+ 6) Correct the STORE example.
+
+ 7) Correct "BASE645" misspelling.
+
+ 8) Remove extraneous close parenthesis in example of two-part message
+ with text and BASE64 attachment.
+
+ 9) Remove obsolete "MAILBOX" response from mailbox-data.
+
+ 10) A spurious "<" in the rule for mailbox-data was removed.
+
+ 11) Add CRLF to continue-req.
+
+ 12) Specifically exclude "]" from the atom in resp-text-code.
+
+ 13) Clarify that clients and servers should adhere strictly to the
+ protocol syntax.
+
+ 14) Emphasize in 5.2 that EXISTS can not be used to shrink a mailbox.
+
+ 15) Add NEWNAME to resp-text-code.
+
+ 16) Clarify that the empty string, not NIL, is used as arguments to
+ LIST.
+
+ 17) Clarify that NIL can be returned as a hierarchy delimiter for the
+ empty string mailbox name argument if the mailbox namespace is flat.
+
+ 18) Clarify that addr-mailbox and addr-name have _R_F_C_-_2_8_2_2 quoting
+ removed.
+
+ 19) Update UTF-7 reference.
+
+ 20) Fix example in 6.3.11.
+
+ 21) Clarify that non-existent UIDs are ignored.
+
+ 22) Update DISPOSITION reference.
+
+ 23) Expand state diagram.
+
+ 24) Clarify that partial fetch responses are only returned in
+ response to a partial fetch command.
+
+ 25) Add UIDNEXT response code. Correct UIDVALIDITY definition
+ reference.
+
+ 26) Further clarification of "can" vs. "MAY".
+
+ 27) Reference _R_F_C_-_2_1_1_9.
+
+ 28) Clarify that superfluous shifts are not permitted in modified
+ UTF-7.
+
+ 29) Clarify that there are no implicit shifts in modified UTF-7.
+
+ 30) Clarify that "INBOX" in a mailbox name is always INBOX, even if
+ it is given as a string.
+
+ 31) Add missing open parenthesis in media-basic grammar rule.
+
+ 32) Correct attribute syntax in mailbox-data.
+
+ 33) Add UIDNEXT to EXAMINE responses.
+
+ 34) Clarify UNSEEN, PERMANENTFLAGS, UIDVALIDITY, and UIDNEXT
+ responses in SELECT and EXAMINE. They are required now, but weren't
+ in older versions.
+
+ 35) Update references with RFC numbers.
+
+ 36) Flush text-mime2.
+
+ 37) Clarify that modified UTF-7 names must be case-sensitive and that
+ violating the convention should be avoided.
+
+ 38) Correct UID FETCH example.
+
+ 39) Clarify UID FETCH, UID STORE, and UID SEARCH vs. untagged EXPUNGE
+ responses.
+
+ 40) Clarify the use of the word "convention".
+
+ 41) Clarify that a command is not "in progress" until it has been
+ fully received (specifically, that a command is not "in progress"
+ during command continuation negotiation).
+
+ 42) Clarify envelope defaulting.
+
+ 43) Clarify that SP means one and only one space character.
+
+ 44) Forbid silly states in LIST response.
+
+ 45) Clarify that the ENVELOPE, INTERNALDATE, _R_F_C_8_2_2*, BODY*, and UID
+ for a message is static.
+
+ 46) Add BADCHARSET response code.
+
+ 47) Update formal syntax to [ABNF] conventions.
+
+ 48) Clarify trailing hierarchy delimiter in CREATE semantics.
+
+ 49) Clarify that the "blank line" is the [_R_F_C_-_2_8_2_2] delimiting blank
+ line.
+
+ 50) Clarify that RENAME should also create hierarchy as needed for
+ the command to complete.
+
+ 51) Fix body-ext-mpart to not require language if disposition
+ present.
+
+ 52) Clarify the _R_F_C_8_2_2.HEADER response.
+
+ 53) Correct missing space after charset astring in search.
+
+ 54) Correct missing quote for BADCHARSET in resp-text-code.
+
+ 55) Clarify that ALL, FAST, and FULL preclude any other data items
+ appearing.
+
+ 56) Clarify semantics of reference argument in LIST.
+
+ 57) Clarify that a null string for SEARCH HEADER X-FOO means any
+ message with a header line with a field-name of X-FOO regardless of
+ the text of the header.
+
+ 58) Specifically reserve 8-bit mailbox names for future use as UTF-8.
+
+ 59) It is not an error for the client to store a flag that is not in
+ the PERMANENTFLAGS list; however, the server will either ignore the
+ change or make the change in the session only.
+
+ 60) Correct/clarify the text regarding superfluous shifts.
+
+ 61) Correct typographic errors in the "Changes" section.
+
+ 62) Clarify that STATUS must not be used to check for new messages in
+ the selected mailbox
+
+ 63) Clarify LSUB behavior with "%" wildcard.
+
+ 64) Change AUTHORIZATION to AUTHENTICATE in section 7.5.
+
+ 65) Clarify description of multipart body type.
+
+ 66) Clarify that STORE FLAGS does not affect \Recent.
+
+ 67) Change "west" to "east" in description of timezone.
+
+ 68) Clarify that commands which break command pipelining must wait
+ for a completion result response.
+
+ 69) Clarify that EXAMINE does not affect \Recent.
+
+ 70) Make description of MIME structure consistent.
+
+ 71) Clarify that date searches disregard the time and timezone of the
+ INTERNALDATE or Date: header. In other words, "ON 13-APR-2000" means
+ messages with an INTERNALDATE text which starts with "13-APR-2000",
+ even if timezone differential from the local timezone is sufficient
+ to move that INTERNALDATE into the previous or next day.
+
+ 72) Clarify that the header fetches don't add a blank line if one
+ isn't in the [_R_F_C_-_2_8_2_2] message.
+
+ 73) Clarify (in discussion of UIDs) that messages are immutable.
+
+ 74) Add an example of CHARSET searching.
+
+ 75) Clarify in SEARCH that keywords are a type of flag.
+
+ 76) Clarify the mandatory nature of the SELECT data responses.
+
+ 77) Add optional CAPABILITY response code in the initial OK or
+ PREAUTH.
+
+ 78) Add note that server can send an untagged CAPABILITY command as
+ part of the responses to AUTHENTICATE and LOGIN.
+
+ 79) Remove statement about it being unnecessary to issue a CAPABILITY
+ command more than once in a connection. That statement is no longer
+ true.
+
+ 80) Clarify that untagged EXPUNGE decrements the number of messages
+ in the mailbox.
+
+ 81) Fix definition of "body" (concatenation has tighter binding than
+ alternation).
+
+ 82) Add a new "Special Notes to Implementors" section with reference
+ to [IMAP-IMPLEMENTATION].
+
+ 83) Clarify that an untagged CAPABILITY response to an AUTHENTICATE
+ command should only be done if a security layer was not negotiated.
+
+ 84) Change the definition of atom to exclude "]". Update astring to
+ include "]" for compatibility with the past. Remove resp-text-atom.
+
+ 85) Remove NEWNAME. It can't work because mailbox names can be
+ literals and can include "]". Functionality can be addressed via
+ referrals.
+
+ 86) Move modified UTF-7 rationale in order to have more logical
+ paragraph flow.
+
+ 87) Clarify UID uniqueness guarantees with the use of MUST.
+
+ 88) Note that clients should read response data until the connection
+ is closed instead of immediately closing on a BYE.
+
+ 89) Change _R_F_C_-_8_2_2 references to _R_F_C_-_2_8_2_2.
+
+ 90) Clarify that _R_F_C_-_2_8_2_2 should be followed instead of _R_F_C_-_8_2_2.
+
+ 91) Change recommendation of optional automatic capabilities in LOGIN
+ and AUTHENTICATE to use the CAPABILITY response code in the tagged
+ OK. This is more interoperable than an unsolicited untagged
+ CAPABILITY response.
+
+ 92) STARTTLS and AUTH=PLAIN are mandatory to implement; add
+ recommendations for other [SASL] mechanisms.
+
+ 93) Clarify that a "connection" (as opposed to "server" or "command")
+ is in one of the four states.
+
+ 94) Clarify that a failed or rejected command does not change state.
+
+ 95) Split references between normative and informative.
+
+ 96) Discuss authentication failure issues in security section.
+
+ 97) Clarify that a data item is not necessarily of only one data
+ type.
+
+ 98) Clarify that sequence ranges are independent of order.
+
+ 99) Change an example to clarify that superfluous shifts in
+ Modified-UTF7 can not be fixed just by omitting the shift. The
+ entire string must be recalculated.
+
+ 100) Change Envelope Structure definition since [_R_F_C_-_2_8_2_2] uses
+ "envelope" to refer to the [SMTP] envelope and not the envelope data
+ that appears in the [_R_F_C_-_2_8_2_2] header.
+
+ 101) Expand on _R_F_C_8_2_2.HEADER response data vs. BODY[HEADER].
+
+ 102) Clarify Logout state semantics, change ASCII art.
+
+ 103) Security changes to comply with IESG requirements.
+
+ 104) Add definition for body URI.
+
+ 105) Break sequence range definition into three rules, with rewritten
+ descriptions for each.
+
+ 106) Move STARTTLS and LOGINDISABLED here from [IMAP-TLS].
+
+ 107) Add IANA Considerations section.
+
+ 108) Clarify valid client assumptions for new message UIDs vs.
+ UIDNEXT.
+
+ 109) Clarify that changes to permanentflags affect concurrent
+ sessions as well as subsequent sessions.
+
+ 110) Clarify that authenticated state can be entered by the CLOSE
+ command.
+
+ 111) Emphasize that SELECT and EXAMINE are the exceptions to the rule
+ that a failing command does not change state.
+
+ 112) Clarify that newly-appended messages have the Recent flag set.
+
+ 113) Clarify that newly-copied messages SHOULD have the Recent flag
+ set.
+
+ 114) Clarify that UID commands always return the UID in FETCH
+ responses.
+
+C. Key Word Index
+
+ +FLAGS <flag list> (store command data item) ............... 59
+ +FLAGS.SILENT <flag list> (store command data item) ........ 59
+ -FLAGS <flag list> (store command data item) ............... 59
+ -FLAGS.SILENT <flag list> (store command data item) ........ 59
+ ALERT (response code) ...................................... 64
+ ALL (fetch item) ........................................... 55
+ ALL (search key) ........................................... 50
+ ANSWERED (search key) ...................................... 50
+ APPEND (command) ........................................... 45
+ AUTHENTICATE (command) ..................................... 27
+ BAD (response) ............................................. 66
+ BADCHARSET (response code) ................................. 64
+ BCC <string> (search key) .................................. 51
+ BEFORE <date> (search key) ................................. 51
+ BODY (fetch item) .......................................... 55
+ BODY (fetch result) ........................................ 73
+ BODY <string> (search key) ................................. 51
+
+ BODY.PEEK[<section>]<<partial>> (fetch item) ............... 57
+ BODYSTRUCTURE (fetch item) ................................. 57
+ BODYSTRUCTURE (fetch result) ............................... 74
+ BODY[<section>]<<origin octet>> (fetch result) ............. 74
+ BODY[<section>]<<partial>> (fetch item) .................... 55
+ BYE (response) ............................................. 67
+ Body Structure (message attribute) ......................... 12
+ CAPABILITY (command) ....................................... 24
+ CAPABILITY (response code) ................................. 64
+ CAPABILITY (response) ...................................... 68
+ CC <string> (search key) ................................... 51
+ CHECK (command) ............................................ 47
+ CLOSE (command) ............................................ 48
+ COPY (command) ............................................. 59
+ CREATE (command) ........................................... 34
+ DELETE (command) ........................................... 35
+ DELETED (search key) ....................................... 51
+ DRAFT (search key) ......................................... 51
+ ENVELOPE (fetch item) ...................................... 57
+ ENVELOPE (fetch result) .................................... 77
+ EXAMINE (command) .......................................... 33
+ EXISTS (response) .......................................... 71
+ EXPUNGE (command) .......................................... 48
+ EXPUNGE (response) ......................................... 72
+ Envelope Structure (message attribute) ..................... 12
+ FAST (fetch item) .......................................... 55
+ FETCH (command) ............................................ 54
+ FETCH (response) ........................................... 73
+ FLAGGED (search key) ....................................... 51
+ FLAGS (fetch item) ......................................... 57
+ FLAGS (fetch result) ....................................... 78
+ FLAGS (response) ........................................... 71
+ FLAGS <flag list> (store command data item) ................ 59
+ FLAGS.SILENT <flag list> (store command data item) ......... 59
+ FROM <string> (search key) ................................. 51
+ FULL (fetch item) .......................................... 55
+ Flags (message attribute) .................................. 11
+ HEADER (part specifier) .................................... 55
+ HEADER <field-name> <string> (search key) .................. 51
+ HEADER.FIELDS <header-list> (part specifier) ............... 55
+ HEADER.FIELDS.NOT <header-list> (part specifier) ........... 55
+ INTERNALDATE (fetch item) .................................. 57
+ INTERNALDATE (fetch result) ................................ 78
+ Internal Date (message attribute) .......................... 12
+ KEYWORD <flag> (search key) ................................ 51
+ Keyword (type of flag) ..................................... 11
+ LARGER <n> (search key) .................................... 51
+ LIST (command) ............................................. 40
+
+ LIST (response) ............................................ 69
+ LOGIN (command) ............................................ 30
+ LOGOUT (command) ........................................... 25
+ LSUB (command) ............................................. 43
+ LSUB (response) ............................................ 70
+ MAY (specification requirement term) ....................... 4
+ MESSAGES (status item) ..................................... 45
+ MIME (part specifier) ...................................... 56
+ MUST (specification requirement term) ...................... 4
+ MUST NOT (specification requirement term) .................. 4
+ Message Sequence Number (message attribute) ................ 10
+ NEW (search key) ........................................... 51
+ NO (response) .............................................. 66
+ NOOP (command) ............................................. 25
+ NOT <search-key> (search key) .............................. 52
+ OK (response) .............................................. 65
+ OLD (search key) ........................................... 52
+ ON <date> (search key) ..................................... 52
+ OPTIONAL (specification requirement term) .................. 4
+ OR <search-key1> <search-key2> (search key) ................ 52
+ PARSE (response code) ...................................... 64
+ PERMANENTFLAGS (response code) ............................. 64
+ PREAUTH (response) ......................................... 67
+ Permanent Flag (class of flag) ............................. 12
+ READ-ONLY (response code) .................................. 65
+ READ-WRITE (response code) ................................. 65
+ RECENT (response) .......................................... 72
+ RECENT (search key) ........................................ 52
+ RECENT (status item) ....................................... 45
+ RENAME (command) ........................................... 37
+ REQUIRED (specification requirement term) .................. 4
+ _R_F_C_8_2_2 (fetch item) ........................................ 57
+ _R_F_C_8_2_2 (fetch result) ...................................... 78
+ _R_F_C_8_2_2.HEADER (fetch item) ................................. 57
+ _R_F_C_8_2_2.HEADER (fetch result) ............................... 78
+ _R_F_C_8_2_2.SIZE (fetch item) ................................... 57
+ _R_F_C_8_2_2.SIZE (fetch result) ................................. 78
+ _R_F_C_8_2_2.TEXT (fetch item) ................................... 58
+ _R_F_C_8_2_2.TEXT (fetch result) ................................. 79
+ SEARCH (command) ........................................... 49
+ SEARCH (response) .......................................... 71
+ SEEN (search key) .......................................... 52
+ SELECT (command) ........................................... 31
+ SENTBEFORE <date> (search key) ............................. 52
+ SENTON <date> (search key) ................................. 52
+ SENTSINCE <date> (search key) .............................. 52
+ SHOULD (specification requirement term) .................... 4
+ SHOULD NOT (specification requirement term) ................ 4
+
+ SINCE <date> (search key) .................................. 52
+ SMALLER <n> (search key) ................................... 52
+ STARTTLS (command) ......................................... 27
+ STATUS (command) ........................................... 44
+ STATUS (response) .......................................... 70
+ STORE (command) ............................................ 58
+ SUBJECT <string> (search key) .............................. 53
+ SUBSCRIBE (command) ........................................ 38
+ Session Flag (class of flag) ............................... 12
+ System Flag (type of flag) ................................. 11
+ TEXT (part specifier) ...................................... 56
+ TEXT <string> (search key) ................................. 53
+ TO <string> (search key) ................................... 53
+ TRYCREATE (response code) .................................. 65
+ UID (command) .............................................. 60
+ UID (fetch item) ........................................... 58
+ UID (fetch result) ......................................... 79
+ UID <sequence set> (search key) ............................ 53
+ UIDNEXT (response code) .................................... 65
+ UIDNEXT (status item) ...................................... 45
+ UIDVALIDITY (response code) ................................ 65
+ UIDVALIDITY (status item) .................................. 45
+ UNANSWERED (search key) .................................... 53
+ UNDELETED (search key) ..................................... 53
+ UNDRAFT (search key) ....................................... 53
+ UNFLAGGED (search key) ..................................... 53
+ UNKEYWORD <flag> (search key) .............................. 53
+ UNSEEN (response code) ..................................... 65
+ UNSEEN (search key) ........................................ 53
+ UNSEEN (status item) ....................................... 45
+ UNSUBSCRIBE (command) ...................................... 39
+ Unique Identifier (UID) (message attribute) ................ 8
+ X<atom> (command) .......................................... 62
+ [_R_F_C_-_2_8_2_2] Size (message attribute) ........................ 12
+ \Answered (system flag) .................................... 11
+ \Deleted (system flag) ..................................... 11
+ \Draft (system flag) ....................................... 11
+ \Flagged (system flag) ..................................... 11
+ \Marked (mailbox name attribute) ........................... 69
+ \Noinferiors (mailbox name attribute) ...................... 69
+ \Noselect (mailbox name attribute) ......................... 69
+ \Recent (system flag) ...................................... 11
+ \Seen (system flag) ........................................ 11
+ \Unmarked (mailbox name attribute) ......................... 69
+
+Author's Address
+
+ Mark R. Crispin
+ Networks and Distributed Computing
+ University of Washington
+ 4545 15th Avenue NE
+ Seattle, WA 98105-4527
+
+ Phone: (206) 543-5762
+
+ EMail: _M_R_C_@_C_A_C_._W_a_s_h_i_n_g_t_o_n_._E_D_U
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns. v This
+ document and the information contained herein is provided on an "AS
+ IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
+ FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
+ LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
+ NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
+ OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+Comments about this RFC:
+ * _R_F_C_ _3_5_0_1_:_ _T_h_o_u_g_h_t_s_ _a_n_d_ _s_u_g_g_e_s_t_i_o_n_s_:_A_b_i_l_i_t_y_ _t_o_ _p_r_o_v_i_d_e_ _m_u_l_t_i_p_l_e
+ _c_o_n_n_e_c_t_i_o_n_s_ _t_o_ _t_h_e_ _s_a_m_e_._._. by Chinmay (10/27/2003)
+ * _R_F_C_ _3_5_0_1_:_ _T_h_e_ _s_e_r_v_e_r_ _s_h_o_u_l_d_ _b_e_ _a_b_l_e_ _t_o_ _a_s_s_i_g_n_ _"_t_e_m_p_o_r_a_r_y_ _c_r_e_d_e_n_t_i_a_l_s_"_,_ _s_o
+ _t_h_a_t_ _a_ _u_s_e_r_._._. by Fredrik Tolf (7/15/2004)
+ * _R_F_C_ _3_5_0_1_:_ _U_N_S_E_E_N_ _v_a_l_u_e_ _w_i_t_h_ _S_t_a_t_u_s_ _C_o_m_m_a_n_d_ _a_n_d_ _U_N_S_E_E_N_ _f_l_a_g_s_ _s_h_o_u_l_d_ _w_i_t_h
+ _d_i_f_f_e_r_e_n_t_ _n_a_m_e_. by Ravi Prakash Gupta (12/28/2004)
+
+Previous: _R_F_C_ _3_4_9_9_ _-_ _R_e_q_u_e_s_t_ _f_o_r Next: _R_F_C_ _3_5_0_2_ _-_ _I_n_t_e_r_n_e_t_ _M_e_s_s_a_g_e
+_C_o_m_m_e_n_t_s_ _S_u_m_m_a_r_y_ _R_F_C_ _N_u_m_b_e_r_s_ _3_4_0_0_-_3_4_9_9 _A_c_c_e_s_s_ _P_r_o_t_o_c_o_l_ _(_I_M_A_P_)_ _-_ _M_U_L_T_I_A_P_P_E_N_D
+ _E_x_t_e_n_s_i_o_n
+
+===============================================================================
+ [ _R_F_C_ _I_n_d_e_x | _R_F_C_ _S_e_a_r_c_h | _U_s_e_n_e_t_ _F_A_Q_s | _W_e_b_ _F_A_Q_s | _D_o_c_u_m_e_n_t_s | _C_i_t_i_e_s ]
+© 2008 FAQS.ORG. All rights reserved.
+
diff --git a/doc/pop3-rfc1939.txt b/doc/pop3-rfc1939.txt
@@ -0,0 +1,1291 @@
+
+
+
+
+
+
+Network Working Group J. Myers
+Request for Comments: 1939 Carnegie Mellon
+STD: 53 M. Rose
+Obsoletes: 1725 Dover Beach Consulting, Inc.
+Category: Standards Track May 1996
+
+
+ Post Office Protocol - Version 3
+
+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.
+
+Table of Contents
+
+ 1. Introduction ................................................ 2
+ 2. A Short Digression .......................................... 2
+ 3. Basic Operation ............................................. 3
+ 4. The AUTHORIZATION State ..................................... 4
+ QUIT Command ................................................ 5
+ 5. The TRANSACTION State ....................................... 5
+ STAT Command ................................................ 6
+ LIST Command ................................................ 6
+ RETR Command ................................................ 8
+ DELE Command ................................................ 8
+ NOOP Command ................................................ 9
+ RSET Command ................................................ 9
+ 6. The UPDATE State ............................................ 10
+ QUIT Command ................................................ 10
+ 7. Optional POP3 Commands ...................................... 11
+ TOP Command ................................................. 11
+ UIDL Command ................................................ 12
+ USER Command ................................................ 13
+ PASS Command ................................................ 14
+ APOP Command ................................................ 15
+ 8. Scaling and Operational Considerations ...................... 16
+ 9. POP3 Command Summary ........................................ 18
+ 10. Example POP3 Session ....................................... 19
+ 11. Message Format ............................................. 19
+ 12. References ................................................. 20
+ 13. Security Considerations .................................... 20
+ 14. Acknowledgements ........................................... 20
+ 15. Authors' Addresses ......................................... 21
+ Appendix A. Differences from RFC 1725 .......................... 22
+
+
+
+Myers & Rose Standards Track [Page 1]
+
+RFC 1939 POP3 May 1996
+
+
+ Appendix B. Command Index ...................................... 23
+
+1. Introduction
+
+ On certain types of smaller nodes in the Internet it is often
+ impractical to maintain a message transport system (MTS). For
+ example, a workstation may not have sufficient resources (cycles,
+ disk space) in order to permit a SMTP server [RFC821] and associated
+ local mail delivery system to be kept resident and continuously
+ running. Similarly, it may be expensive (or impossible) to keep a
+ personal computer interconnected to an IP-style network for long
+ amounts of time (the node is lacking the resource known as
+ "connectivity").
+
+ Despite this, it is often very useful to be able to manage mail on
+ these smaller nodes, and they often support a user agent (UA) to aid
+ the tasks of mail handling. To solve this problem, a node which can
+ support an MTS entity offers a maildrop service to these less endowed
+ nodes. The Post Office Protocol - Version 3 (POP3) is intended to
+ permit a workstation to dynamically access a maildrop on a server
+ host in a useful fashion. Usually, this means that the POP3 protocol
+ is used to allow a workstation to retrieve mail that the server is
+ holding for it.
+
+ POP3 is not intended to provide extensive manipulation operations of
+ mail on the server; normally, mail is downloaded and then deleted. A
+ more advanced (and complex) protocol, IMAP4, is discussed in
+ [RFC1730].
+
+ For the remainder of this memo, the term "client host" refers to a
+ host making use of the POP3 service, while the term "server host"
+ refers to a host which offers the POP3 service.
+
+2. A Short Digression
+
+ This memo does not specify how a client host enters mail into the
+ transport system, although a method consistent with the philosophy of
+ this memo is presented here:
+
+ When the user agent on a client host wishes to enter a message
+ into the transport system, it establishes an SMTP connection to
+ its relay host and sends all mail to it. This relay host could
+ be, but need not be, the POP3 server host for the client host. Of
+ course, the relay host must accept mail for delivery to arbitrary
+ recipient addresses, that functionality is not required of all
+ SMTP servers.
+
+
+
+
+
+Myers & Rose Standards Track [Page 2]
+
+RFC 1939 POP3 May 1996
+
+
+3. Basic Operation
+
+ Initially, the server host starts the POP3 service by listening on
+ TCP port 110. When a client host wishes to make use of the service,
+ it establishes a TCP connection with the server host. When the
+ connection is established, the POP3 server sends a greeting. The
+ client and POP3 server then exchange commands and responses
+ (respectively) until the connection is closed or aborted.
+
+ Commands in the POP3 consist of a case-insensitive keyword, possibly
+ followed by one or more arguments. All commands are terminated by a
+ CRLF pair. Keywords and arguments consist of printable ASCII
+ characters. Keywords and arguments are each separated by a single
+ SPACE character. Keywords are three or four characters long. Each
+ argument may be up to 40 characters long.
+
+ Responses in the POP3 consist of a status indicator and a keyword
+ possibly followed by additional information. All responses are
+ terminated by a CRLF pair. Responses may be up to 512 characters
+ long, including the terminating CRLF. There are currently two status
+ indicators: positive ("+OK") and negative ("-ERR"). Servers MUST
+ send the "+OK" and "-ERR" in upper case.
+
+ Responses to certain commands are multi-line. In these cases, which
+ are clearly indicated below, after sending the first line of the
+ response and a CRLF, any additional lines are sent, each terminated
+ by a CRLF pair. When all lines of the response have been sent, a
+ final line is sent, consisting of a termination octet (decimal code
+ 046, ".") and a CRLF pair. If any line of the multi-line response
+ begins with the termination octet, the line is "byte-stuffed" by
+ pre-pending the termination octet to that line of the response.
+ Hence a multi-line response is terminated with the five octets
+ "CRLF.CRLF". When examining a multi-line response, the client checks
+ to see if the line begins with the termination octet. If so and if
+ octets other than CRLF follow, the first octet of the line (the
+ termination octet) is stripped away. If so and if CRLF immediately
+ follows the termination character, then the response from the POP
+ server is ended and the line containing ".CRLF" is not considered
+ part of the multi-line response.
+
+ A POP3 session progresses through a number of states during its
+ lifetime. Once the TCP connection has been opened and the POP3
+ server has sent the greeting, the session enters the AUTHORIZATION
+ state. In this state, the client must identify itself to the POP3
+ server. Once the client has successfully done this, the server
+ acquires resources associated with the client's maildrop, and the
+ session enters the TRANSACTION state. In this state, the client
+ requests actions on the part of the POP3 server. When the client has
+
+
+
+Myers & Rose Standards Track [Page 3]
+
+RFC 1939 POP3 May 1996
+
+
+ issued the QUIT command, the session enters the UPDATE state. In
+ this state, the POP3 server releases any resources acquired during
+ the TRANSACTION state and says goodbye. The TCP connection is then
+ closed.
+
+ A server MUST respond to an unrecognized, unimplemented, or
+ syntactically invalid command by responding with a negative status
+ indicator. A server MUST respond to a command issued when the
+ session is in an incorrect state by responding with a negative status
+ indicator. There is no general method for a client to distinguish
+ between a server which does not implement an optional command and a
+ server which is unwilling or unable to process the command.
+
+ A POP3 server MAY have an inactivity autologout timer. Such a timer
+ MUST be of at least 10 minutes' duration. The receipt of any command
+ from the client during that interval should suffice to reset the
+ autologout timer. When the timer expires, the session does NOT enter
+ the UPDATE state--the server should close the TCP connection without
+ removing any messages or sending any response to the client.
+
+4. The AUTHORIZATION State
+
+ Once the TCP connection has been opened by a POP3 client, the POP3
+ server issues a one line greeting. This can be any positive
+ response. An example might be:
+
+ S: +OK POP3 server ready
+
+ The POP3 session is now in the AUTHORIZATION state. The client must
+ now identify and authenticate itself to the POP3 server. Two
+ possible mechanisms for doing this are described in this document,
+ the USER and PASS command combination and the APOP command. Both
+ mechanisms are described later in this document. Additional
+ authentication mechanisms are described in [RFC1734]. While there is
+ no single authentication mechanism that is required of all POP3
+ servers, a POP3 server must of course support at least one
+ authentication mechanism.
+
+ Once the POP3 server has determined through the use of any
+ authentication command that the client should be given access to the
+ appropriate maildrop, the POP3 server then acquires an exclusive-
+ access lock on the maildrop, as necessary to prevent messages from
+ being modified or removed before the session enters the UPDATE state.
+ If the lock is successfully acquired, the POP3 server responds with a
+ positive status indicator. The POP3 session now enters the
+ TRANSACTION state, with no messages marked as deleted. If the
+ maildrop cannot be opened for some reason (for example, a lock can
+ not be acquired, the client is denied access to the appropriate
+
+
+
+Myers & Rose Standards Track [Page 4]
+
+RFC 1939 POP3 May 1996
+
+
+ maildrop, or the maildrop cannot be parsed), the POP3 server responds
+ with a negative status indicator. (If a lock was acquired but the
+ POP3 server intends to respond with a negative status indicator, the
+ POP3 server must release the lock prior to rejecting the command.)
+ After returning a negative status indicator, the server may close the
+ connection. If the server does not close the connection, the client
+ may either issue a new authentication command and start again, or the
+ client may issue the QUIT command.
+
+ After the POP3 server has opened the maildrop, it assigns a message-
+ number to each message, and notes the size of each message in octets.
+ The first message in the maildrop is assigned a message-number of
+ "1", the second is assigned "2", and so on, so that the nth message
+ in a maildrop is assigned a message-number of "n". In POP3 commands
+ and responses, all message-numbers and message sizes are expressed in
+ base-10 (i.e., decimal).
+
+ Here is the summary for the QUIT command when used in the
+ AUTHORIZATION state:
+
+ QUIT
+
+ Arguments: none
+
+ Restrictions: none
+
+ Possible Responses:
+ +OK
+
+ Examples:
+ C: QUIT
+ S: +OK dewey POP3 server signing off
+
+5. The TRANSACTION State
+
+ Once the client has successfully identified itself to the POP3 server
+ and the POP3 server has locked and opened the appropriate maildrop,
+ the POP3 session is now in the TRANSACTION state. The client may now
+ issue any of the following POP3 commands repeatedly. After each
+ command, the POP3 server issues a response. Eventually, the client
+ issues the QUIT command and the POP3 session enters the UPDATE state.
+
+
+
+
+
+
+
+
+
+
+Myers & Rose Standards Track [Page 5]
+
+RFC 1939 POP3 May 1996
+
+
+ Here are the POP3 commands valid in the TRANSACTION state:
+
+ STAT
+
+ Arguments: none
+
+ Restrictions:
+ may only be given in the TRANSACTION state
+
+ Discussion:
+ The POP3 server issues a positive response with a line
+ containing information for the maildrop. This line is
+ called a "drop listing" for that maildrop.
+
+ In order to simplify parsing, all POP3 servers are
+ required to use a certain format for drop listings. The
+ positive response consists of "+OK" followed by a single
+ space, the number of messages in the maildrop, a single
+ space, and the size of the maildrop in octets. This memo
+ makes no requirement on what follows the maildrop size.
+ Minimal implementations should just end that line of the
+ response with a CRLF pair. More advanced implementations
+ may include other information.
+
+ NOTE: This memo STRONGLY discourages implementations
+ from supplying additional information in the drop
+ listing. Other, optional, facilities are discussed
+ later on which permit the client to parse the messages
+ in the maildrop.
+
+ Note that messages marked as deleted are not counted in
+ either total.
+
+ Possible Responses:
+ +OK nn mm
+
+ Examples:
+ C: STAT
+ S: +OK 2 320
+
+
+ LIST [msg]
+
+ Arguments:
+ a message-number (optional), which, if present, may NOT
+ refer to a message marked as deleted
+
+
+
+
+
+Myers & Rose Standards Track [Page 6]
+
+RFC 1939 POP3 May 1996
+
+
+ Restrictions:
+ may only be given in the TRANSACTION state
+
+ Discussion:
+ If an argument was given and the POP3 server issues a
+ positive response with a line containing information for
+ that message. This line is called a "scan listing" for
+ that message.
+
+ If no argument was given and the POP3 server issues a
+ positive response, then the response given is multi-line.
+ After the initial +OK, for each message in the maildrop,
+ the POP3 server responds with a line containing
+ information for that message. This line is also called a
+ "scan listing" for that message. If there are no
+ messages in the maildrop, then the POP3 server responds
+ with no scan listings--it issues a positive response
+ followed by a line containing a termination octet and a
+ CRLF pair.
+
+ In order to simplify parsing, all POP3 servers are
+ required to use a certain format for scan listings. A
+ scan listing consists of the message-number of the
+ message, followed by a single space and the exact size of
+ the message in octets. Methods for calculating the exact
+ size of the message are described in the "Message Format"
+ section below. This memo makes no requirement on what
+ follows the message size in the scan listing. Minimal
+ implementations should just end that line of the response
+ with a CRLF pair. More advanced implementations may
+ include other information, as parsed from the message.
+
+ NOTE: This memo STRONGLY discourages implementations
+ from supplying additional information in the scan
+ listing. Other, optional, facilities are discussed
+ later on which permit the client to parse the messages
+ in the maildrop.
+
+ Note that messages marked as deleted are not listed.
+
+ Possible Responses:
+ +OK scan listing follows
+ -ERR no such message
+
+ Examples:
+ C: LIST
+ S: +OK 2 messages (320 octets)
+ S: 1 120
+
+
+
+Myers & Rose Standards Track [Page 7]
+
+RFC 1939 POP3 May 1996
+
+
+ S: 2 200
+ S: .
+ ...
+ C: LIST 2
+ S: +OK 2 200
+ ...
+ C: LIST 3
+ S: -ERR no such message, only 2 messages in maildrop
+
+
+ RETR msg
+
+ Arguments:
+ a message-number (required) which may NOT refer to a
+ message marked as deleted
+
+ Restrictions:
+ may only be given in the TRANSACTION state
+
+ Discussion:
+ If the POP3 server issues a positive response, then the
+ response given is multi-line. After the initial +OK, the
+ POP3 server sends the message corresponding to the given
+ message-number, being careful to byte-stuff the termination
+ character (as with all multi-line responses).
+
+ Possible Responses:
+ +OK message follows
+ -ERR no such message
+
+ Examples:
+ C: RETR 1
+ S: +OK 120 octets
+ S: <the POP3 server sends the entire message here>
+ S: .
+
+
+ DELE msg
+
+ Arguments:
+ a message-number (required) which may NOT refer to a
+ message marked as deleted
+
+ Restrictions:
+ may only be given in the TRANSACTION state
+
+
+
+
+
+
+Myers & Rose Standards Track [Page 8]
+
+RFC 1939 POP3 May 1996
+
+
+ Discussion:
+ The POP3 server marks the message as deleted. Any future
+ reference to the message-number associated with the message
+ in a POP3 command generates an error. The POP3 server does
+ not actually delete the message until the POP3 session
+ enters the UPDATE state.
+
+ Possible Responses:
+ +OK message deleted
+ -ERR no such message
+
+ Examples:
+ C: DELE 1
+ S: +OK message 1 deleted
+ ...
+ C: DELE 2
+ S: -ERR message 2 already deleted
+
+
+ NOOP
+
+ Arguments: none
+
+ Restrictions:
+ may only be given in the TRANSACTION state
+
+ Discussion:
+ The POP3 server does nothing, it merely replies with a
+ positive response.
+
+ Possible Responses:
+ +OK
+
+ Examples:
+ C: NOOP
+ S: +OK
+
+
+ RSET
+
+ Arguments: none
+
+ Restrictions:
+ may only be given in the TRANSACTION state
+
+ Discussion:
+ If any messages have been marked as deleted by the POP3
+ server, they are unmarked. The POP3 server then replies
+
+
+
+Myers & Rose Standards Track [Page 9]
+
+RFC 1939 POP3 May 1996
+
+
+ with a positive response.
+
+ Possible Responses:
+ +OK
+
+ Examples:
+ C: RSET
+ S: +OK maildrop has 2 messages (320 octets)
+
+6. The UPDATE State
+
+ When the client issues the QUIT command from the TRANSACTION state,
+ the POP3 session enters the UPDATE state. (Note that if the client
+ issues the QUIT command from the AUTHORIZATION state, the POP3
+ session terminates but does NOT enter the UPDATE state.)
+
+ If a session terminates for some reason other than a client-issued
+ QUIT command, the POP3 session does NOT enter the UPDATE state and
+ MUST not remove any messages from the maildrop.
+
+ QUIT
+
+ Arguments: none
+
+ Restrictions: none
+
+ Discussion:
+ The POP3 server removes all messages marked as deleted
+ from the maildrop and replies as to the status of this
+ operation. If there is an error, such as a resource
+ shortage, encountered while removing messages, the
+ maildrop may result in having some or none of the messages
+ marked as deleted be removed. In no case may the server
+ remove any messages not marked as deleted.
+
+ Whether the removal was successful or not, the server
+ then releases any exclusive-access lock on the maildrop
+ and closes the TCP connection.
+
+ Possible Responses:
+ +OK
+ -ERR some deleted messages not removed
+
+ Examples:
+ C: QUIT
+ S: +OK dewey POP3 server signing off (maildrop empty)
+ ...
+ C: QUIT
+
+
+
+Myers & Rose Standards Track [Page 10]
+
+RFC 1939 POP3 May 1996
+
+
+ S: +OK dewey POP3 server signing off (2 messages left)
+ ...
+
+7. Optional POP3 Commands
+
+ The POP3 commands discussed above must be supported by all minimal
+ implementations of POP3 servers.
+
+ The optional POP3 commands described below permit a POP3 client
+ greater freedom in message handling, while preserving a simple POP3
+ server implementation.
+
+ NOTE: This memo STRONGLY encourages implementations to support
+ these commands in lieu of developing augmented drop and scan
+ listings. In short, the philosophy of this memo is to put
+ intelligence in the part of the POP3 client and not the POP3
+ server.
+
+ TOP msg n
+
+ Arguments:
+ a message-number (required) which may NOT refer to to a
+ message marked as deleted, and a non-negative number
+ of lines (required)
+
+ Restrictions:
+ may only be given in the TRANSACTION state
+
+ Discussion:
+ If the POP3 server issues a positive response, then the
+ response given is multi-line. After the initial +OK, the
+ POP3 server sends the headers of the message, the blank
+ line separating the headers from the body, and then the
+ number of lines of the indicated message's body, being
+ careful to byte-stuff the termination character (as with
+ all multi-line responses).
+
+ Note that if the number of lines requested by the POP3
+ client is greater than than the number of lines in the
+ body, then the POP3 server sends the entire message.
+
+ Possible Responses:
+ +OK top of message follows
+ -ERR no such message
+
+ Examples:
+ C: TOP 1 10
+ S: +OK
+
+
+
+Myers & Rose Standards Track [Page 11]
+
+RFC 1939 POP3 May 1996
+
+
+ S: <the POP3 server sends the headers of the
+ message, a blank line, and the first 10 lines
+ of the body of the message>
+ S: .
+ ...
+ C: TOP 100 3
+ S: -ERR no such message
+
+
+ UIDL [msg]
+
+ Arguments:
+ a message-number (optional), which, if present, may NOT
+ refer to a message marked as deleted
+
+ Restrictions:
+ may only be given in the TRANSACTION state.
+
+ Discussion:
+ If an argument was given and the POP3 server issues a positive
+ response with a line containing information for that message.
+ This line is called a "unique-id listing" for that message.
+
+ If no argument was given and the POP3 server issues a positive
+ response, then the response given is multi-line. After the
+ initial +OK, for each message in the maildrop, the POP3 server
+ responds with a line containing information for that message.
+ This line is called a "unique-id listing" for that message.
+
+ In order to simplify parsing, all POP3 servers are required to
+ use a certain format for unique-id listings. A unique-id
+ listing consists of the message-number of the message,
+ followed by a single space and the unique-id of the message.
+ No information follows the unique-id in the unique-id listing.
+
+ The unique-id of a message is an arbitrary server-determined
+ string, consisting of one to 70 characters in the range 0x21
+ to 0x7E, which uniquely identifies a message within a
+ maildrop and which persists across sessions. This
+ persistence is required even if a session ends without
+ entering the UPDATE state. The server should never reuse an
+ unique-id in a given maildrop, for as long as the entity
+ using the unique-id exists.
+
+ Note that messages marked as deleted are not listed.
+
+ While it is generally preferable for server implementations
+ to store arbitrarily assigned unique-ids in the maildrop,
+
+
+
+Myers & Rose Standards Track [Page 12]
+
+RFC 1939 POP3 May 1996
+
+
+ this specification is intended to permit unique-ids to be
+ calculated as a hash of the message. Clients should be able
+ to handle a situation where two identical copies of a
+ message in a maildrop have the same unique-id.
+
+ Possible Responses:
+ +OK unique-id listing follows
+ -ERR no such message
+
+ Examples:
+ C: UIDL
+ S: +OK
+ S: 1 whqtswO00WBw418f9t5JxYwZ
+ S: 2 QhdPYR:00WBw1Ph7x7
+ S: .
+ ...
+ C: UIDL 2
+ S: +OK 2 QhdPYR:00WBw1Ph7x7
+ ...
+ C: UIDL 3
+ S: -ERR no such message, only 2 messages in maildrop
+
+
+ USER name
+
+ Arguments:
+ a string identifying a mailbox (required), which is of
+ significance ONLY to the server
+
+ Restrictions:
+ may only be given in the AUTHORIZATION state after the POP3
+ greeting or after an unsuccessful USER or PASS command
+
+ Discussion:
+ To authenticate using the USER and PASS command
+ combination, the client must first issue the USER
+ command. If the POP3 server responds with a positive
+ status indicator ("+OK"), then the client may issue
+ either the PASS command to complete the authentication,
+ or the QUIT command to terminate the POP3 session. If
+ the POP3 server responds with a negative status indicator
+ ("-ERR") to the USER command, then the client may either
+ issue a new authentication command or may issue the QUIT
+ command.
+
+ The server may return a positive response even though no
+ such mailbox exists. The server may return a negative
+ response if mailbox exists, but does not permit plaintext
+
+
+
+Myers & Rose Standards Track [Page 13]
+
+RFC 1939 POP3 May 1996
+
+
+ password authentication.
+
+ Possible Responses:
+ +OK name is a valid mailbox
+ -ERR never heard of mailbox name
+
+ Examples:
+ C: USER frated
+ S: -ERR sorry, no mailbox for frated here
+ ...
+ C: USER mrose
+ S: +OK mrose is a real hoopy frood
+
+
+ PASS string
+
+ Arguments:
+ a server/mailbox-specific password (required)
+
+ Restrictions:
+ may only be given in the AUTHORIZATION state immediately
+ after a successful USER command
+
+ Discussion:
+ When the client issues the PASS command, the POP3 server
+ uses the argument pair from the USER and PASS commands to
+ determine if the client should be given access to the
+ appropriate maildrop.
+
+ Since the PASS command has exactly one argument, a POP3
+ server may treat spaces in the argument as part of the
+ password, instead of as argument separators.
+
+ Possible Responses:
+ +OK maildrop locked and ready
+ -ERR invalid password
+ -ERR unable to lock maildrop
+
+ Examples:
+ C: USER mrose
+ S: +OK mrose is a real hoopy frood
+ C: PASS secret
+ S: -ERR maildrop already locked
+ ...
+ C: USER mrose
+ S: +OK mrose is a real hoopy frood
+ C: PASS secret
+ S: +OK mrose's maildrop has 2 messages (320 octets)
+
+
+
+Myers & Rose Standards Track [Page 14]
+
+RFC 1939 POP3 May 1996
+
+
+ APOP name digest
+
+ Arguments:
+ a string identifying a mailbox and a MD5 digest string
+ (both required)
+
+ Restrictions:
+ may only be given in the AUTHORIZATION state after the POP3
+ greeting or after an unsuccessful USER or PASS command
+
+ Discussion:
+ Normally, each POP3 session starts with a USER/PASS
+ exchange. This results in a server/user-id specific
+ password being sent in the clear on the network. For
+ intermittent use of POP3, this may not introduce a sizable
+ risk. However, many POP3 client implementations connect to
+ the POP3 server on a regular basis -- to check for new
+ mail. Further the interval of session initiation may be on
+ the order of five minutes. Hence, the risk of password
+ capture is greatly enhanced.
+
+ An alternate method of authentication is required which
+ provides for both origin authentication and replay
+ protection, but which does not involve sending a password
+ in the clear over the network. The APOP command provides
+ this functionality.
+
+ A POP3 server which implements the APOP command will
+ include a timestamp in its banner greeting. The syntax of
+ the timestamp corresponds to the `msg-id' in [RFC822], and
+ MUST be different each time the POP3 server issues a banner
+ greeting. For example, on a UNIX implementation in which a
+ separate UNIX process is used for each instance of a POP3
+ server, the syntax of the timestamp might be:
+
+ <process-ID.clock@hostname>
+
+ where `process-ID' is the decimal value of the process's
+ PID, clock is the decimal value of the system clock, and
+ hostname is the fully-qualified domain-name corresponding
+ to the host where the POP3 server is running.
+
+ The POP3 client makes note of this timestamp, and then
+ issues the APOP command. The `name' parameter has
+ identical semantics to the `name' parameter of the USER
+ command. The `digest' parameter is calculated by applying
+ the MD5 algorithm [RFC1321] to a string consisting of the
+ timestamp (including angle-brackets) followed by a shared
+
+
+
+Myers & Rose Standards Track [Page 15]
+
+RFC 1939 POP3 May 1996
+
+
+ secret. This shared secret is a string known only to the
+ POP3 client and server. Great care should be taken to
+ prevent unauthorized disclosure of the secret, as knowledge
+ of the secret will allow any entity to successfully
+ masquerade as the named user. The `digest' parameter
+ itself is a 16-octet value which is sent in hexadecimal
+ format, using lower-case ASCII characters.
+
+ When the POP3 server receives the APOP command, it verifies
+ the digest provided. If the digest is correct, the POP3
+ server issues a positive response, and the POP3 session
+ enters the TRANSACTION state. Otherwise, a negative
+ response is issued and the POP3 session remains in the
+ AUTHORIZATION state.
+
+ Note that as the length of the shared secret increases, so
+ does the difficulty of deriving it. As such, shared
+ secrets should be long strings (considerably longer than
+ the 8-character example shown below).
+
+ Possible Responses:
+ +OK maildrop locked and ready
+ -ERR permission denied
+
+ Examples:
+ S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
+ C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
+ S: +OK maildrop has 1 message (369 octets)
+
+ In this example, the shared secret is the string `tan-
+ staaf'. Hence, the MD5 algorithm is applied to the string
+
+ <1896.697170952@dbc.mtview.ca.us>tanstaaf
+
+ which produces a digest value of
+
+ c4c9334bac560ecc979e58001b3e22fb
+
+8. Scaling and Operational Considerations
+
+ Since some of the optional features described above were added to the
+ POP3 protocol, experience has accumulated in using them in large-
+ scale commercial post office operations where most of the users are
+ unrelated to each other. In these situations and others, users and
+ vendors of POP3 clients have discovered that the combination of using
+ the UIDL command and not issuing the DELE command can provide a weak
+ version of the "maildrop as semi-permanent repository" functionality
+ normally associated with IMAP. Of course the other capabilities of
+
+
+
+Myers & Rose Standards Track [Page 16]
+
+RFC 1939 POP3 May 1996
+
+
+ IMAP, such as polling an existing connection for newly arrived
+ messages and supporting multiple folders on the server, are not
+ present in POP3.
+
+ When these facilities are used in this way by casual users, there has
+ been a tendency for already-read messages to accumulate on the server
+ without bound. This is clearly an undesirable behavior pattern from
+ the standpoint of the server operator. This situation is aggravated
+ by the fact that the limited capabilities of the POP3 do not permit
+ efficient handling of maildrops which have hundreds or thousands of
+ messages.
+
+ Consequently, it is recommended that operators of large-scale multi-
+ user servers, especially ones in which the user's only access to the
+ maildrop is via POP3, consider such options as:
+
+ * Imposing a per-user maildrop storage quota or the like.
+
+ A disadvantage to this option is that accumulation of messages may
+ result in the user's inability to receive new ones into the
+ maildrop. Sites which choose this option should be sure to inform
+ users of impending or current exhaustion of quota, perhaps by
+ inserting an appropriate message into the user's maildrop.
+
+ * Enforce a site policy regarding mail retention on the server.
+
+ Sites are free to establish local policy regarding the storage and
+ retention of messages on the server, both read and unread. For
+ example, a site might delete unread messages from the server after
+ 60 days and delete read messages after 7 days. Such message
+ deletions are outside the scope of the POP3 protocol and are not
+ considered a protocol violation.
+
+ Server operators enforcing message deletion policies should take
+ care to make all users aware of the policies in force.
+
+ Clients must not assume that a site policy will automate message
+ deletions, and should continue to explicitly delete messages using
+ the DELE command when appropriate.
+
+ It should be noted that enforcing site message deletion policies
+ may be confusing to the user community, since their POP3 client
+ may contain configuration options to leave mail on the server
+ which will not in fact be supported by the server.
+
+ One special case of a site policy is that messages may only be
+ downloaded once from the server, and are deleted after this has
+ been accomplished. This could be implemented in POP3 server
+
+
+
+Myers & Rose Standards Track [Page 17]
+
+RFC 1939 POP3 May 1996
+
+
+ software by the following mechanism: "following a POP3 login by a
+ client which was ended by a QUIT, delete all messages downloaded
+ during the session with the RETR command". It is important not to
+ delete messages in the event of abnormal connection termination
+ (ie, if no QUIT was received from the client) because the client
+ may not have successfully received or stored the messages.
+ Servers implementing a download-and-delete policy may also wish to
+ disable or limit the optional TOP command, since it could be used
+ as an alternate mechanism to download entire messages.
+
+9. POP3 Command Summary
+
+ Minimal POP3 Commands:
+
+ USER name valid in the AUTHORIZATION state
+ PASS string
+ QUIT
+
+ STAT valid in the TRANSACTION state
+ LIST [msg]
+ RETR msg
+ DELE msg
+ NOOP
+ RSET
+ QUIT
+
+ Optional POP3 Commands:
+
+ APOP name digest valid in the AUTHORIZATION state
+
+ TOP msg n valid in the TRANSACTION state
+ UIDL [msg]
+
+ POP3 Replies:
+
+ +OK
+ -ERR
+
+ Note that with the exception of the STAT, LIST, and UIDL commands,
+ the reply given by the POP3 server to any command is significant
+ only to "+OK" and "-ERR". Any text occurring after this reply
+ may be ignored by the client.
+
+
+
+
+
+
+
+
+
+Myers & Rose Standards Track [Page 18]
+
+RFC 1939 POP3 May 1996
+
+
+10. Example POP3 Session
+
+ S: <wait for connection on TCP port 110>
+ C: <open connection>
+ S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
+ C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
+ S: +OK mrose's maildrop has 2 messages (320 octets)
+ C: STAT
+ S: +OK 2 320
+ C: LIST
+ S: +OK 2 messages (320 octets)
+ S: 1 120
+ S: 2 200
+ S: .
+ C: RETR 1
+ S: +OK 120 octets
+ S: <the POP3 server sends message 1>
+ S: .
+ C: DELE 1
+ S: +OK message 1 deleted
+ C: RETR 2
+ S: +OK 200 octets
+ S: <the POP3 server sends message 2>
+ S: .
+ C: DELE 2
+ S: +OK message 2 deleted
+ C: QUIT
+ S: +OK dewey POP3 server signing off (maildrop empty)
+ C: <close connection>
+ S: <wait for next connection>
+
+11. Message Format
+
+ All messages transmitted during a POP3 session are assumed to conform
+ to the standard for the format of Internet text messages [RFC822].
+
+ It is important to note that the octet count for a message on the
+ server host may differ from the octet count assigned to that message
+ due to local conventions for designating end-of-line. Usually,
+ during the AUTHORIZATION state of the POP3 session, the POP3 server
+ can calculate the size of each message in octets when it opens the
+ maildrop. For example, if the POP3 server host internally represents
+ end-of-line as a single character, then the POP3 server simply counts
+ each occurrence of this character in a message as two octets. Note
+ that lines in the message which start with the termination octet need
+ not (and must not) be counted twice, since the POP3 client will
+ remove all byte-stuffed termination characters when it receives a
+ multi-line response.
+
+
+
+Myers & Rose Standards Track [Page 19]
+
+RFC 1939 POP3 May 1996
+
+
+12. References
+
+ [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
+ 821, USC/Information Sciences Institute, August 1982.
+
+ [RFC822] Crocker, D., "Standard for the Format of ARPA-Internet Text
+ Messages", STD 11, RFC 822, University of Delaware, August 1982.
+
+ [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
+ MIT Laboratory for Computer Science, April 1992.
+
+ [RFC1730] Crispin, M., "Internet Message Access Protocol - Version
+ 4", RFC 1730, University of Washington, December 1994.
+
+ [RFC1734] Myers, J., "POP3 AUTHentication command", RFC 1734,
+ Carnegie Mellon, December 1994.
+
+13. Security Considerations
+
+ It is conjectured that use of the APOP command provides origin
+ identification and replay protection for a POP3 session.
+ Accordingly, a POP3 server which implements both the PASS and APOP
+ commands should not allow both methods of access for a given user;
+ that is, for a given mailbox name, either the USER/PASS command
+ sequence or the APOP command is allowed, but not both.
+
+ Further, note that as the length of the shared secret increases, so
+ does the difficulty of deriving it.
+
+ Servers that answer -ERR to the USER command are giving potential
+ attackers clues about which names are valid.
+
+ Use of the PASS command sends passwords in the clear over the
+ network.
+
+ Use of the RETR and TOP commands sends mail in the clear over the
+ network.
+
+ Otherwise, security issues are not discussed in this memo.
+
+14. Acknowledgements
+
+ The POP family has a long and checkered history. Although primarily
+ a minor revision to RFC 1460, POP3 is based on the ideas presented in
+ RFCs 918, 937, and 1081.
+
+ In addition, Alfred Grimstad, Keith McCloghrie, and Neil Ostroff
+ provided significant comments on the APOP command.
+
+
+
+Myers & Rose Standards Track [Page 20]
+
+RFC 1939 POP3 May 1996
+
+
+15. Authors' Addresses
+
+ John G. Myers
+ Carnegie-Mellon University
+ 5000 Forbes Ave
+ Pittsburgh, PA 15213
+
+ EMail: jgm+@cmu.edu
+
+
+ Marshall T. Rose
+ Dover Beach Consulting, Inc.
+ 420 Whisman Court
+ Mountain View, CA 94043-2186
+
+ EMail: mrose@dbc.mtview.ca.us
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers & Rose Standards Track [Page 21]
+
+RFC 1939 POP3 May 1996
+
+
+Appendix A. Differences from RFC 1725
+
+ This memo is a revision to RFC 1725, a Draft Standard. It makes the
+ following changes from that document:
+
+ - clarifies that command keywords are case insensitive.
+
+ - specifies that servers must send "+OK" and "-ERR" in
+ upper case.
+
+ - specifies that the initial greeting is a positive response,
+ instead of any string which should be a positive response.
+
+ - clarifies behavior for unimplemented commands.
+
+ - makes the USER and PASS commands optional.
+
+ - clarified the set of possible responses to the USER command.
+
+ - reverses the order of the examples in the USER and PASS
+ commands, to reduce confusion.
+
+ - clarifies that the PASS command may only be given immediately
+ after a successful USER command.
+
+ - clarified the persistence requirements of UIDs and added some
+ implementation notes.
+
+ - specifies a UID length limitation of one to 70 octets.
+
+ - specifies a status indicator length limitation
+ of 512 octets, including the CRLF.
+
+ - clarifies that LIST with no arguments on an empty mailbox
+ returns success.
+
+ - adds a reference from the LIST command to the Message Format
+ section
+
+ - clarifies the behavior of QUIT upon failure
+
+ - clarifies the security section to not imply the use of the
+ USER command with the APOP command.
+
+ - adds references to RFCs 1730 and 1734
+
+ - clarifies the method by which a UA may enter mail into the
+ transport system.
+
+
+
+Myers & Rose Standards Track [Page 22]
+
+RFC 1939 POP3 May 1996
+
+
+ - clarifies that the second argument to the TOP command is a
+ number of lines.
+
+ - changes the suggestion in the Security Considerations section
+ for a server to not accept both PASS and APOP for a given user
+ from a "must" to a "should".
+
+ - adds a section on scaling and operational considerations
+
+Appendix B. Command Index
+
+ APOP ....................................................... 15
+ DELE ....................................................... 8
+ LIST ....................................................... 6
+ NOOP ....................................................... 9
+ PASS ....................................................... 14
+ QUIT ....................................................... 5
+ QUIT ....................................................... 10
+ RETR ....................................................... 8
+ RSET ....................................................... 9
+ STAT ....................................................... 6
+ TOP ........................................................ 11
+ UIDL ....................................................... 12
+ USER ....................................................... 13
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Myers & Rose Standards Track [Page 23]
+
diff --git a/doc/smtp-rfc821.txt b/doc/smtp-rfc821.txt
@@ -0,0 +1,2707 @@
+
+ SIMPLE MAIL TRANSFER PROTOCOL
+
+ Jonathan B. Postel
+
+ August 1982
+
+ Information Sciences Institute
+ University of Southern California
+ 4676 Admiralty Way
+ Marina del Rey, California 90291
+
+ (213) 822-1511
+
+ August 1982
+ Simple Mail Transfer Protocol
+
+ TABLE OF CONTENTS
+
+ 1. INTRODUCTION .................................................. 1
+
+ 2. THE SMTP MODEL ................................................ 2
+
+ 3. THE SMTP PROCEDURE ............................................ 4
+
+ 3.1. Mail ..................................................... 4
+ 3.2. Forwarding ............................................... 7
+ 3.3. Verifying and Expanding .................................. 8
+ 3.4. Sending and Mailing ..................................... 11
+ 3.5. Opening and Closing ..................................... 13
+ 3.6. Relaying ................................................ 14
+ 3.7. Domains ................................................. 17
+ 3.8. Changing Roles .......................................... 18
+
+ 4. THE SMTP SPECIFICATIONS ...................................... 19
+
+ 4.1. SMTP Commands ........................................... 19
+ 4.1.1. Command Semantics ..................................... 19
+ 4.1.2. Command Syntax ........................................ 27
+ 4.2. SMTP Replies ............................................ 34
+ 4.2.1. Reply Codes by Function Group ......................... 35
+ 4.2.2. Reply Codes in Numeric Order .......................... 36
+ 4.3. Sequencing of Commands and Replies ...................... 37
+ 4.4. State Diagrams .......................................... 39
+ 4.5. Details ................................................. 41
+ 4.5.1. Minimum Implementation ................................ 41
+ 4.5.2. Transparency .......................................... 41
+ 4.5.3. Sizes ................................................. 42
+
+ APPENDIX A: TCP ................................................. 44
+ APPENDIX B: NCP ................................................. 45
+ APPENDIX C: NITS ................................................ 46
+ APPENDIX D: X.25 ................................................ 47
+ APPENDIX E: Theory of Reply Codes ............................... 48
+ APPENDIX F: Scenarios ........................................... 51
+
+ GLOSSARY ......................................................... 64
+
+ REFERENCES ....................................................... 67
+
+Network Working Group J. Postel
+Request for Comments: DRAFT ISI
+Replaces: _R_F_C_ _7_8_8, 780, 772 August 1982
+
+ SIMPLE MAIL TRANSFER PROTOCOL
+
+1. INTRODUCTION
+
+ The objective of Simple Mail Transfer Protocol (SMTP) is to transfer
+ mail reliably and efficiently.
+
+ SMTP is independent of the particular transmission subsystem and
+ requires only a reliable ordered data stream channel. Appendices A,
+ B, C, and D describe the use of SMTP with various transport services.
+ A Glossary provides the definitions of terms as used in this
+ document.
+
+ An important feature of SMTP is its capability to relay mail across
+ transport service environments. A transport service provides an
+ interprocess communication environment (IPCE). An IPCE may cover one
+ network, several networks, or a subset of a network. It is important
+ to realize that transport systems (or IPCEs) are not one-to-one with
+ networks. A process can communicate directly with another process
+ through any mutually known IPCE. Mail is an application or use of
+ interprocess communication. Mail can be communicated between
+ processes in different IPCEs by relaying through a process connected
+ to two (or more) IPCEs. More specifically, mail can be relayed
+ between hosts on different transport systems by a host on both
+ transport systems.
+
+August 1982 _R_F_C_ _8_2_1
+Simple Mail Transfer Protocol
+
+2. THE SMTP MODEL
+
+ The SMTP design is based on the following model of communication: as
+ the result of a user mail request, the sender-SMTP establishes a
+ two-way transmission channel to a receiver-SMTP. The receiver-SMTP
+ may be either the ultimate destination or an intermediate. SMTP
+ commands are generated by the sender-SMTP and sent to the
+ receiver-SMTP. SMTP replies are sent from the receiver-SMTP to the
+ sender-SMTP in response to the commands.
+
+ Once the transmission channel is established, the SMTP-sender sends a
+ MAIL command indicating the sender of the mail. If the SMTP-receiver
+ can accept mail it responds with an OK reply. The SMTP-sender then
+ sends a RCPT command identifying a recipient of the mail. If the
+ SMTP-receiver can accept mail for that recipient it responds with an
+ OK reply; if not, it responds with a reply rejecting that recipient
+ (but not the whole mail transaction). The SMTP-sender and
+ SMTP-receiver may negotiate several recipients. When the recipients
+ have been negotiated the SMTP-sender sends the mail data, terminating
+ with a special sequence. If the SMTP-receiver successfully processes
+ the mail data it responds with an OK reply. The dialog is purposely
+ lock-step, one-at-a-time.
+
+ -------------------------------------------------------------
+
+ +----------+ +----------+
+ +------+ | | | |
+ | User |<-->| | SMTP | |
+ +------+ | Sender- |Commands/Replies| Receiver-|
+ +------+ | SMTP |<-------------->| SMTP | +------+
+ | File |<-->| | and Mail | |<-->| File |
+ |System| | | | | |System|
+ +------+ +----------+ +----------+ +------+
+
+ Sender-SMTP Receiver-SMTP
+
+ Model for SMTP Use
+
+ Figure 1
+
+ -------------------------------------------------------------
+
+ The SMTP provides mechanisms for the transmission of mail; directly
+ from the sending user's host to the receiving user's host when the
+
+_R_F_C_ _8_2_1 August 1982
+ Simple Mail Transfer Protocol
+
+ two host are connected to the same transport service, or via one or
+ more relay SMTP-servers when the source and destination hosts are not
+ connected to the same transport service.
+
+ To be able to provide the relay capability the SMTP-server must be
+ supplied with the name of the ultimate destination host as well as
+ the destination mailbox name.
+
+ The argument to the MAIL command is a reverse-path, which specifies
+ who the mail is from. The argument to the RCPT command is a
+ forward-path, which specifies who the mail is to. The forward-path
+ is a source route, while the reverse-path is a return route (which
+ may be used to return a message to the sender when an error occurs
+ with a relayed message).
+
+ When the same message is sent to multiple recipients the SMTP
+ encourages the transmission of only one copy of the data for all the
+ recipients at the same destination host.
+
+ The mail commands and replies have a rigid syntax. Replies also have
+ a numeric code. In the following, examples appear which use actual
+ commands and replies. The complete lists of commands and replies
+ appears in Section 4 on specifications.
+
+ Commands and replies are not case sensitive. That is, a command or
+ reply word may be upper case, lower case, or any mixture of upper and
+ lower case. Note that this is not true of mailbox user names. For
+ some hosts the user name is case sensitive, and SMTP implementations
+ must take case to preserve the case of user names as they appear in
+ mailbox arguments. Host names are not case sensitive.
+
+ Commands and replies are composed of characters from the ASCII
+ character set [1]. When the transport service provides an 8-bit byte
+ (octet) transmission channel, each 7-bit character is transmitted
+ right justified in an octet with the high order bit cleared to zero.
+
+ When specifying the general form of a command or reply, an argument
+ (or special symbol) will be denoted by a meta-linguistic variable (or
+ constant), for example, "<string>" or "<reverse-path>". Here the
+ angle brackets indicate these are meta-linguistic variables.
+ However, some arguments use the angle brackets literally. For
+ example, an actual reverse-path is enclosed in angle brackets, i.e.,
+ "<_J_o_h_n_._S_m_i_t_h_@_U_S_C_-_I_S_I_._A_R_P_A>" is an instance of <reverse-path> (the
+ angle brackets are actually transmitted in the command or reply).
+
+August 1982 _R_F_C_ _8_2_1
+Simple Mail Transfer Protocol
+
+3. THE SMTP PROCEDURES
+
+ This section presents the procedures used in SMTP in several parts.
+ First comes the basic mail procedure defined as a mail transaction.
+ Following this are descriptions of forwarding mail, verifying mailbox
+ names and expanding mailing lists, sending to terminals instead of or
+ in combination with mailboxes, and the opening and closing exchanges.
+ At the end of this section are comments on relaying, a note on mail
+ domains, and a discussion of changing roles. Throughout this section
+ are examples of partial command and reply sequences, several complete
+ scenarios are presented in Appendix F.
+
+ 3.1. MAIL
+
+ There are three steps to SMTP mail transactions. The transaction
+ is started with a MAIL command which gives the sender
+ identification. A series of one or more RCPT commands follows
+ giving the receiver information. Then a DATA command gives the
+ mail data. And finally, the end of mail data indicator confirms
+ the transaction.
+
+ The first step in the procedure is the MAIL command. The
+ <reverse-path> contains the source mailbox.
+
+ MAIL <SP> FROM:<reverse-path> <CRLF>
+
+ This command tells the SMTP-receiver that a new mail
+ transaction is starting and to reset all its state tables and
+ buffers, including any recipients or mail data. It gives the
+ reverse-path which can be used to report errors. If accepted,
+ the receiver-SMTP returns a 250 OK reply.
+
+ The <reverse-path> can contain more than just a mailbox. The
+ <reverse-path> is a reverse source routing list of hosts and
+ source mailbox. The first host in the <reverse-path> should be
+ the host sending this command.
+
+ The second step in the procedure is the RCPT command.
+
+ RCPT <SP> TO:<forward-path> <CRLF>
+
+ This command gives a forward-path identifying one recipient.
+ If accepted, the receiver-SMTP returns a 250 OK reply, and
+ stores the forward-path. If the recipient is unknown the
+ receiver-SMTP returns a 550 Failure reply. This second step of
+ the procedure can be repeated any number of times.
+
+_R_F_C_ _8_2_1 August 1982
+ Simple Mail Transfer Protocol
+
+ The <forward-path> can contain more than just a mailbox. The
+ <forward-path> is a source routing list of hosts and the
+ destination mailbox. The first host in the <forward-path>
+ should be the host receiving this command.
+
+ The third step in the procedure is the DATA command.
+
+ DATA <CRLF>
+
+ If accepted, the receiver-SMTP returns a 354 Intermediate reply
+ and considers all succeeding lines to be the message text.
+ When the end of text is received and stored the SMTP-receiver
+ sends a 250 OK reply.
+
+ Since the mail data is sent on the transmission channel the end
+ of the mail data must be indicated so that the command and
+ reply dialog can be resumed. SMTP indicates the end of the
+ mail data by sending a line containing only a period. A
+ transparency procedure is used to prevent this from interfering
+ with the user's text (see Section 4.5.2).
+
+ Please note that the mail data includes the memo header
+ items such as Date, Subject, To, Cc, From [2].
+
+ The end of mail data indicator also confirms the mail
+ transaction and tells the receiver-SMTP to now process the
+ stored recipients and mail data. If accepted, the
+ receiver-SMTP returns a 250 OK reply. The DATA command should
+ fail only if the mail transaction was incomplete (for example,
+ no recipients), or if resources are not available.
+
+ The above procedure is an example of a mail transaction. These
+ commands must be used only in the order discussed above.
+ Example 1 (below) illustrates the use of these commands in a mail
+ transaction.
+
+August 1982 _R_F_C_ _8_2_1
+Simple Mail Transfer Protocol
+
+ -------------------------------------------------------------
+
+ Example of the SMTP Procedure
+
+ This SMTP example shows mail sent by Smith at host Alpha.ARPA,
+ to Jones, Green, and Brown at host Beta.ARPA. Here we assume
+ that host Alpha contacts host Beta directly.
+
+ S: MAIL FROM:<_S_m_i_t_h_@_A_l_p_h_a_._A_R_P_A>
+ R: 250 OK
+
+ S: RCPT TO:<_J_o_n_e_s_@_B_e_t_a_._A_R_P_A>
+ R: 250 OK
+
+ S: RCPT TO:<_G_r_e_e_n_@_B_e_t_a_._A_R_P_A>
+ R: 550 No such user here
+
+ S: RCPT TO:<_B_r_o_w_n_@_B_e_t_a_._A_R_P_A>
+ R: 250 OK
+
+ S: DATA
+ R: 354 Start mail input; end with <CRLF>.<CRLF>
+ S: Blah blah blah...
+ S: ...etc. etc. etc.
+ S: <CRLF>.<CRLF>
+ R: 250 OK
+
+ The mail has now been accepted for Jones and Brown. Green did
+ not have a mailbox at host Beta.
+
+ Example 1
+
+ -------------------------------------------------------------
+
+_R_F_C_ _8_2_1 August 1982
+ Simple Mail Transfer Protocol
+
+ 3.2. FORWARDING
+
+ There are some cases where the destination information in the
+ <forward-path> is incorrect, but the receiver-SMTP knows the
+ correct destination. In such cases, one of the following replies
+ should be used to allow the sender to contact the correct
+ destination.
+
+ 251 User not local; will forward to <forward-path>
+
+ This reply indicates that the receiver-SMTP knows the user's
+ mailbox is on another host and indicates the correct
+ forward-path to use in the future. Note that either the
+ host or user or both may be different. The receiver takes
+ responsibility for delivering the message.
+
+ 551 User not local; please try <forward-path>
+
+ This reply indicates that the receiver-SMTP knows the user's
+ mailbox is on another host and indicates the correct
+ forward-path to use. Note that either the host or user or
+ both may be different. The receiver refuses to accept mail
+ for this user, and the sender must either redirect the mail
+ according to the information provided or return an error
+ response to the originating user.
+
+ Example 2 illustrates the use of these responses.
+
+ -------------------------------------------------------------
+
+ Example of Forwarding
+
+ Either
+
+ S: RCPT TO:<_P_o_s_t_e_l_@_U_S_C_-_I_S_I_._A_R_P_A>
+ R: 251 User not local; will forward to <_P_o_s_t_e_l_@_U_S_C_-_I_S_I_F_._A_R_P_A>
+
+ Or
+
+ S: RCPT TO:<_P_a_u_l_@_U_S_C_-_I_S_I_B_._A_R_P_A>
+ R: 551 User not local; please try <_M_o_c_k_a_p_e_t_r_i_s_@_U_S_C_-_I_S_I_F_._A_R_P_A>
+
+ Example 2
+
+ -------------------------------------------------------------
+
+August 1982 _R_F_C_ _8_2_1
+Simple Mail Transfer Protocol
+
+ 3.3. VERIFYING AND EXPANDING
+
+ SMTP provides as additional features, commands to verify a user
+ name or expand a mailing list. This is done with the VRFY and
+ EXPN commands, which have character string arguments. For the
+ VRFY command, the string is a user name, and the response may
+ include the full name of the user and must include the mailbox of
+ the user. For the EXPN command, the string identifies a mailing
+ list, and the multiline response may include the full name of the
+ users and must give the mailboxes on the mailing list.
+
+ "User name" is a fuzzy term and used purposely. If a host
+ implements the VRFY or EXPN commands then at least local mailboxes
+ must be recognized as "user names". If a host chooses to
+ recognize other strings as "user names" that is allowed.
+
+ In some hosts the distinction between a mailing list and an alias
+ for a single mailbox is a bit fuzzy, since a common data structure
+ may hold both types of entries, and it is possible to have mailing
+ lists of one mailbox. If a request is made to verify a mailing
+ list a positive response can be given if on receipt of a message
+ so addressed it will be delivered to everyone on the list,
+ otherwise an error should be reported (e.g., "550 That is a
+ mailing list, not a user"). If a request is made to expand a user
+ name a positive response can be formed by returning a list
+ containing one name, or an error can be reported (e.g., "550 That
+ is a user name, not a mailing list").
+
+ In the case of a multiline reply (normal for EXPN) exactly one
+ mailbox is to be specified on each line of the reply. In the case
+ of an ambiguous request, for example, "VRFY Smith", where there
+ are two Smith's the response must be "553 User ambiguous".
+
+ The case of verifying a user name is straightforward as shown in
+ example 3.
+
+_R_F_C_ _8_2_1 August 1982
+ Simple Mail Transfer Protocol
+
+ -------------------------------------------------------------
+
+ Example of Verifying a User Name
+
+ Either
+
+ S: VRFY Smith
+ R: 250 Fred Smith <_S_m_i_t_h_@_U_S_C_-_I_S_I_F_._A_R_P_A>
+
+ Or
+
+ S: VRFY Smith
+ R: 251 User not local; will forward to <_S_m_i_t_h_@_U_S_C_-_I_S_I_Q_._A_R_P_A>
+
+ Or
+
+ S: VRFY Jones
+ R: 550 String does not match anything.
+
+ Or
+
+ S: VRFY Jones
+ R: 551 User not local; please try <_J_o_n_e_s_@_U_S_C_-_I_S_I_Q_._A_R_P_A>
+
+ Or
+
+ S: VRFY Gourzenkyinplatz
+ R: 553 User ambiguous.
+
+ Example 3
+
+ -------------------------------------------------------------
+
+August 1982 _R_F_C_ _8_2_1
+Simple Mail Transfer Protocol
+
+ The case of expanding a mailbox list requires a multiline reply as
+ shown in example 4.
+
+ -------------------------------------------------------------
+
+ Example of Expanding a Mailing List
+
+ Either
+
+ S: EXPN Example-People
+ R: 250-Jon Postel <_P_o_s_t_e_l_@_U_S_C_-_I_S_I_F_._A_R_P_A>
+ R: 250-Fred Fonebone <_F_o_n_e_b_o_n_e_@_U_S_C_-_I_S_I_Q_._A_R_P_A>
+ R: 250-Sam Q. Smith <_S_Q_S_m_i_t_h_@_U_S_C_-_I_S_I_Q_._A_R_P_A>
+ R: 250-Quincy Smith <@USC-ISIF.ARPA:_Q_-_S_m_i_t_h_@_I_S_I_-_V_A_X_A_._A_R_P_A>
+ R: 250-<_j_o_e_@_f_o_o_-_u_n_i_x_._A_R_P_A>
+ R: 250 <_x_y_z_@_b_a_r_-_u_n_i_x_._A_R_P_A>
+
+ Or
+
+ S: EXPN Executive-Washroom-List
+ R: 550 Access Denied to You.
+
+ Example 4
+
+ -------------------------------------------------------------
+
+ The character string arguments of the VRFY and EXPN commands
+ cannot be further restricted due to the variety of implementations
+ of the user name and mailbox list concepts. On some systems it
+ may be appropriate for the argument of the EXPN command to be a
+ file name for a file containing a mailing list, but again there is
+ a variety of file naming conventions in the Internet.
+
+ The VRFY and EXPN commands are not included in the minimum
+ implementation (Section 4.5.1), and are not required to work
+ across relays when they are implemented.
+
+_R_F_C_ _8_2_1 August 1982
+ Simple Mail Transfer Protocol
+
+ 3.4. SENDING AND MAILING
+
+ The main purpose of SMTP is to deliver messages to user's
+ mailboxes. A very similar service provided by some hosts is to
+ deliver messages to user's terminals (provided the user is active
+ on the host). The delivery to the user's mailbox is called
+ "mailing", the delivery to the user's terminal is called
+ "sending". Because in many hosts the implementation of sending is
+ nearly identical to the implementation of mailing these two
+ functions are combined in SMTP. However the sending commands are
+ not included in the required minimum implementation
+ (Section 4.5.1). Users should have the ability to control the
+ writing of messages on their terminals. Most hosts permit the
+ users to accept or refuse such messages.
+
+ The following three command are defined to support the sending
+ options. These are used in the mail transaction instead of the
+ MAIL command and inform the receiver-SMTP of the special semantics
+ of this transaction:
+
+ SEND <SP> FROM:<reverse-path> <CRLF>
+
+ The SEND command requires that the mail data be delivered to
+ the user's terminal. If the user is not active (or not
+ accepting terminal messages) on the host a 450 reply may
+ returned to a RCPT command. The mail transaction is
+ successful if the message is delivered the terminal.
+
+ SOML <SP> FROM:<reverse-path> <CRLF>
+
+ The Send Or MaiL command requires that the mail data be
+ delivered to the user's terminal if the user is active (and
+ accepting terminal messages) on the host. If the user is
+ not active (or not accepting terminal messages) then the
+ mail data is entered into the user's mailbox. The mail
+ transaction is successful if the message is delivered either
+ to the terminal or the mailbox.
+
+ SAML <SP> FROM:<reverse-path> <CRLF>
+
+ The Send And MaiL command requires that the mail data be
+ delivered to the user's terminal if the user is active (and
+ accepting terminal messages) on the host. In any case the
+ mail data is entered into the user's mailbox. The mail
+ transaction is successful if the message is delivered the
+ mailbox.
+
+August 1982 _R_F_C_ _8_2_1
+Simple Mail Transfer Protocol
+
+ The same reply codes that are used for the MAIL commands are used
+ for these commands.
+
+_R_F_C_ _8_2_1 August 1982
+ Simple Mail Transfer Protocol
+
+ 3.5. OPENING AND CLOSING
+
+ At the time the transmission channel is opened there is an
+ exchange to ensure that the hosts are communicating with the hosts
+ they think they are.
+
+ The following two commands are used in transmission channel
+ opening and closing:
+
+ HELO <SP> <domain> <CRLF>
+
+ QUIT <CRLF>
+
+ In the HELO command the host sending the command identifies
+ itself; the command may be interpreted as saying "Hello, I am
+ <domain>".
+
+ -------------------------------------------------------------
+
+ Example of Connection Opening
+
+ R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready
+ S: HELO USC-ISIF.ARPA
+ R: 250 BBN-UNIX.ARPA
+
+ Example 5
+
+ -------------------------------------------------------------
+
+ -------------------------------------------------------------
+
+ Example of Connection Closing
+
+ S: QUIT
+ R: 221 BBN-UNIX.ARPA Service closing transmission channel
+
+ Example 6
+
+ -------------------------------------------------------------
+
+August 1982 _R_F_C_ _8_2_1
+Simple Mail Transfer Protocol
+
+ 3.6. RELAYING
+
+ The forward-path may be a source route of the form
+ "@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE are hosts. This
+ form is used to emphasize the distinction between an address and a
+ route. The mailbox is an absolute address, and the route is
+ information about how to get there. The two concepts should not
+ be confused.
+
+ Conceptually the elements of the forward-path are moved to the
+ reverse-path as the message is relayed from one server-SMTP to
+ another. The reverse-path is a reverse source route, (i.e., a
+ source route from the current location of the message to the
+ originator of the message). When a server-SMTP deletes its
+ identifier from the forward-path and inserts it into the
+ reverse-path, it must use the name it is known by in the
+ environment it is sending into, not the environment the mail came
+ from, in case the server-SMTP is known by different names in
+ different environments.
+
+ If when the message arrives at an SMTP the first element of the
+ forward-path is not the identifier of that SMTP the element is not
+ deleted from the forward-path and is used to determine the next
+ SMTP to send the message to. In any case, the SMTP adds its own
+ identifier to the reverse-path.
+
+ Using source routing the receiver-SMTP receives mail to be relayed
+ to another server-SMTP The receiver-SMTP may accept or reject the
+ task of relaying the mail in the same way it accepts or rejects
+ mail for a local user. The receiver-SMTP transforms the command
+ arguments by moving its own identifier from the forward-path to
+ the beginning of the reverse-path. The receiver-SMTP then becomes
+ a sender-SMTP, establishes a transmission channel to the next SMTP
+ in the forward-path, and sends it the mail.
+
+ The first host in the reverse-path should be the host sending the
+ SMTP commands, and the first host in the forward-path should be
+ the host receiving the SMTP commands.
+
+ Notice that the forward-path and reverse-path appear in the SMTP
+ commands and replies, but not necessarily in the message. That
+ is, there is no need for these paths and especially this syntax to
+ appear in the "To:" , "From:", "CC:", etc. fields of the message
+ header.
+
+ If a server-SMTP has accepted the task of relaying the mail and
+
+_R_F_C_ _8_2_1 August 1982
+ Simple Mail Transfer Protocol
+
+ later finds that the forward-path is incorrect or that the mail
+ cannot be delivered for whatever reason, then it must construct an
+ "undeliverable mail" notification message and send it to the
+ originator of the undeliverable mail (as indicated by the
+ reverse-path).
+
+ This notification message must be from the server-SMTP at this
+ host. Of course, server-SMTPs should not send notification
+ messages about problems with notification messages. One way to
+ prevent loops in error reporting is to specify a null reverse-path
+ in the MAIL command of a notification message. When such a
+ message is relayed it is permissible to leave the reverse-path
+ null. A MAIL command with a null reverse-path appears as follows:
+
+ MAIL FROM:<>
+
+ An undeliverable mail notification message is shown in example 7.
+ This notification is in response to a message originated by JOE at
+ HOSTW and sent via HOSTX to HOSTY with instructions to relay it on
+ to HOSTZ. What we see in the example is the transaction between
+ HOSTY and HOSTX, which is the first step in the return of the
+ notification message.
+
+August 1982 _R_F_C_ _8_2_1
+Simple Mail Transfer Protocol
+
+ -------------------------------------------------------------
+
+ Example Undeliverable Mail Notification Message
+
+ S: MAIL FROM:<>
+ R: 250 ok
+ S: RCPT TO:<@HOSTX.ARPA:_J_O_E_@_H_O_S_T_W_._A_R_P_A>
+ R: 250 ok
+ S: DATA
+ R: 354 send the mail data, end with .
+ S: Date: 23 Oct 81 11:22:33
+ S: From: _S_M_T_P_@_H_O_S_T_Y_._A_R_P_A
+ S: To: _J_O_E_@_H_O_S_T_W_._A_R_P_A
+ S: Subject: Mail System Problem
+ S:
+ S: Sorry JOE, your message to _S_A_M_@_H_O_S_T_Z_._A_R_P_A lost.
+ S: HOSTZ.ARPA said this:
+ S: "550 No Such User"
+ S: .
+ R: 250 ok
+
+ Example 7
+
+ -------------------------------------------------------------
+
+_R_F_C_ _8_2_1 August 1982
+ Simple Mail Transfer Protocol
+
+ 3.7. DOMAINS
+
+ Domains are a recently introduced concept in the ARPA Internet
+ mail system. The use of domains changes the address space from a
+ flat global space of simple character string host names to a
+ hierarchically structured rooted tree of global addresses. The
+ host name is replaced by a domain and host designator which is a
+ sequence of domain element strings separated by periods with the
+ understanding that the domain elements are ordered from the most
+ specific to the most general.
+
+ For example, "USC-ISIF.ARPA", "Fred.Cambridge.UK", and
+ "PC7.LCS.MIT.ARPA" might be host-and-domain identifiers.
+
+ Whenever domain names are used in SMTP only the official names are
+ used, the use of nicknames or aliases is not allowed.
+
+August 1982 _R_F_C_ _8_2_1
+Simple Mail Transfer Protocol
+
+ 3.8. CHANGING ROLES
+
+ The TURN command may be used to reverse the roles of the two
+ programs communicating over the transmission channel.
+
+ If program-A is currently the sender-SMTP and it sends the TURN
+ command and receives an ok reply (250) then program-A becomes the
+ receiver-SMTP.
+
+ If program-B is currently the receiver-SMTP and it receives the
+ TURN command and sends an ok reply (250) then program-B becomes
+ the sender-SMTP.
+
+ To refuse to change roles the receiver sends the 502 reply.
+
+ Please note that this command is optional. It would not normally
+ be used in situations where the transmission channel is TCP.
+ However, when the cost of establishing the transmission channel is
+ high, this command may be quite useful. For example, this command
+ may be useful in supporting be mail exchange using the public
+ switched telephone system as a transmission channel, especially if
+ some hosts poll other hosts for mail exchanges.
+
+_R_F_C_ _8_2_1 August 1982
+ Simple Mail Transfer Protocol
+
+4. THE SMTP SPECIFICATIONS
+
+ 4.1. SMTP COMMANDS
+
+ 4.1.1. COMMAND SEMANTICS
+
+ The SMTP commands define the mail transfer or the mail system
+ function requested by the user. SMTP commands are character
+ strings terminated by <CRLF>. The command codes themselves are
+ alphabetic characters terminated by <SP> if parameters follow
+ and <CRLF> otherwise. The syntax of mailboxes must conform to
+ receiver site conventions. The SMTP commands are discussed
+ below. The SMTP replies are discussed in the Section 4.2.
+
+ A mail transaction involves several data objects which are
+ communicated as arguments to different commands. The
+ reverse-path is the argument of the MAIL command, the
+ forward-path is the argument of the RCPT command, and the mail
+ data is the argument of the DATA command. These arguments or
+ data objects must be transmitted and held pending the
+ confirmation communicated by the end of mail data indication
+ which finalizes the transaction. The model for this is that
+ distinct buffers are provided to hold the types of data
+ objects, that is, there is a reverse-path buffer, a
+ forward-path buffer, and a mail data buffer. Specific commands
+ cause information to be appended to a specific buffer, or cause
+ one or more buffers to be cleared.
+
+ HELLO (HELO)
+
+ This command is used to identify the sender-SMTP to the
+ receiver-SMTP. The argument field contains the host name of
+ the sender-SMTP.
+
+ The receiver-SMTP identifies itself to the sender-SMTP in
+ the connection greeting reply, and in the response to this
+ command.
+
+ This command and an OK reply to it confirm that both the
+ sender-SMTP and the receiver-SMTP are in the initial state,
+ that is, there is no transaction in progress and all state
+ tables and buffers are cleared.
+
+August 1982 _R_F_C_ _8_2_1
+Simple Mail Transfer Protocol
+
+ MAIL (MAIL)
+
+ This command is used to initiate a mail transaction in which
+ the mail data is delivered to one or more mailboxes. The
+ argument field contains a reverse-path.
+
+ The reverse-path consists of an optional list of hosts and
+ the sender mailbox. When the list of hosts is present, it
+ is a "reverse" source route and indicates that the mail was
+ relayed through each host on the list (the first host in the
+ list was the most recent relay). This list is used as a
+ source route to return non-delivery notices to the sender.
+ As each relay host adds itself to the beginning of the list,
+ it must use its name as known in the IPCE to which it is
+ relaying the mail rather than the IPCE from which the mail
+ came (if they are different). In some types of error
+ reporting messages (for example, undeliverable mail
+ notifications) the reverse-path may be null (see Example 7).
+
+ This command clears the reverse-path buffer, the
+ forward-path buffer, and the mail data buffer; and inserts
+ the reverse-path information from this command into the
+ reverse-path buffer.
+
+ RECIPIENT (RCPT)
+
+ This command is used to identify an individual recipient of
+ the mail data; multiple recipients are specified by multiple
+ use of this command.
+
+ The forward-path consists of an optional list of hosts and a
+ required destination mailbox. When the list of hosts is
+ present, it is a source route and indicates that the mail
+ must be relayed to the next host on the list. If the
+ receiver-SMTP does not implement the relay function it may
+ user the same reply it would for an unknown local user
+ (550).
+
+ When mail is relayed, the relay host must remove itself from
+ the beginning forward-path and put itself at the beginning
+ of the reverse-path. When mail reaches its ultimate
+ destination (the forward-path contains only a destination
+ mailbox), the receiver-SMTP inserts it into the destination
+ mailbox in accordance with its host mail conventions.
+
+_R_F_C_ _8_2_1 August 1982
+ Simple Mail Transfer Protocol
+
+ For example, mail received at relay host A with arguments
+
+ FROM:<_U_S_E_R_X_@_H_O_S_T_Y_._A_R_P_A>
+ TO:<@HOSTA.ARPA,@HOSTB.ARPA:_U_S_E_R_C_@_H_O_S_T_D_._A_R_P_A>
+
+ will be relayed on to host B with arguments
+
+ FROM:<@HOSTA.ARPA:_U_S_E_R_X_@_H_O_S_T_Y_._A_R_P_A>
+ TO:<@HOSTB.ARPA:_U_S_E_R_C_@_H_O_S_T_D_._A_R_P_A>.
+
+ This command causes its forward-path argument to be appended
+ to the forward-path buffer.
+
+ DATA (DATA)
+
+ The receiver treats the lines following the command as mail
+ data from the sender. This command causes the mail data
+ from this command to be appended to the mail data buffer.
+ The mail data may contain any of the 128 ASCII character
+ codes.
+
+ The mail data is terminated by a line containing only a
+ period, that is the character sequence "<CRLF>.<CRLF>" (see
+ Section 4.5.2 on Transparency). This is the end of mail
+ data indication.
+
+ The end of mail data indication requires that the receiver
+ must now process the stored mail transaction information.
+ This processing consumes the information in the reverse-path
+ buffer, the forward-path buffer, and the mail data buffer,
+ and on the completion of this command these buffers are
+ cleared. If the processing is successful the receiver must
+ send an OK reply. If the processing fails completely the
+ receiver must send a failure reply.
+
+ When the receiver-SMTP accepts a message either for relaying
+ or for final delivery it inserts at the beginning of the
+ mail data a time stamp line. The time stamp line indicates
+ the identity of the host that sent the message, and the
+ identity of the host that received the message (and is
+ inserting this time stamp), and the date and time the
+ message was received. Relayed messages will have multiple
+ time stamp lines.
+
+ When the receiver-SMTP makes the "final delivery" of a
+ message it inserts at the beginning of the mail data a
+
+August 1982 _R_F_C_ _8_2_1
+Simple Mail Transfer Protocol
+
+ return path line. The return path line preserves the
+ information in the <reverse-path> from the MAIL command.
+ Here, final delivery means the message leaves the SMTP
+ world. Normally, this would mean it has been delivered to
+ the destination user, but in some cases it may be further
+ processed and transmitted by another mail system.
+
+ It is possible for the mailbox in the return path be
+ different from the actual sender's mailbox, for example,
+ if error responses are to be delivered a special error
+ handling mailbox rather than the message senders.
+
+ The preceding two paragraphs imply that the final mail data
+ will begin with a return path line, followed by one or more
+ time stamp lines. These lines will be followed by the mail
+ data header and body [2]. See Example 8.
+
+ Special mention is needed of the response and further action
+ required when the processing following the end of mail data
+ indication is partially successful. This could arise if
+ after accepting several recipients and the mail data, the
+ receiver-SMTP finds that the mail data can be successfully
+ delivered to some of the recipients, but it cannot be to
+ others (for example, due to mailbox space allocation
+ problems). In such a situation, the response to the DATA
+ command must be an OK reply. But, the receiver-SMTP must
+ compose and send an "undeliverable mail" notification
+ message to the originator of the message. Either a single
+ notification which lists all of the recipients that failed
+ to get the message, or separate notification messages must
+ be sent for each failed recipient (see Example 7). All
+ undeliverable mail notification messages are sent using the
+ MAIL command (even if they result from processing a SEND,
+ SOML, or SAML command).
+
+_R_F_C_ _8_2_1 August 1982
+ Simple Mail Transfer Protocol
+
+ -------------------------------------------------------------
+
+ Example of Return Path and Received Time Stamps
+
+ Return-Path: <@GHI.ARPA,@DEF.ARPA,@ABC.ARPA:_J_O_E_@_A_B_C_._A_R_P_A>
+ Received: from GHI.ARPA by JKL.ARPA ; 27 Oct 81 15:27:39 PST
+ Received: from DEF.ARPA by GHI.ARPA ; 27 Oct 81 15:15:13 PST
+ Received: from ABC.ARPA by DEF.ARPA ; 27 Oct 81 15:01:59 PST
+ Date: 27 Oct 81 15:01:01 PST
+ From: _J_O_E_@_A_B_C_._A_R_P_A
+ Subject: Improved Mailing System Installed
+ To: _S_A_M_@_J_K_L_._A_R_P_A
+
+ This is to inform you that ...
+
+ Example 8
+
+ -------------------------------------------------------------
+
+ SEND (SEND)
+
+ This command is used to initiate a mail transaction in which
+ the mail data is delivered to one or more terminals. The
+ argument field contains a reverse-path. This command is
+ successful if the message is delivered to a terminal.
+
+ The reverse-path consists of an optional list of hosts and
+ the sender mailbox. When the list of hosts is present, it
+ is a "reverse" source route and indicates that the mail was
+ relayed through each host on the list (the first host in the
+ list was the most recent relay). This list is used as a
+ source route to return non-delivery notices to the sender.
+ As each relay host adds itself to the beginning of the list,
+ it must use its name as known in the IPCE to which it is
+ relaying the mail rather than the IPCE from which the mail
+ came (if they are different).
+
+ This command clears the reverse-path buffer, the
+ forward-path buffer, and the mail data buffer; and inserts
+ the reverse-path information from this command into the
+ reverse-path buffer.
+
+ SEND OR MAIL (SOML)
+
+ This command is used to initiate a mail transaction in which
+ the mail data is delivered to one or more terminals or
+
+August 1982 _R_F_C_ _8_2_1
+Simple Mail Transfer Protocol
+
+ mailboxes. For each recipient the mail data is delivered to
+ the recipient's terminal if the recipient is active on the
+ host (and accepting terminal messages), otherwise to the
+ recipient's mailbox. The argument field contains a
+ reverse-path. This command is successful if the message is
+ delivered to a terminal or the mailbox.
+
+ The reverse-path consists of an optional list of hosts and
+ the sender mailbox. When the list of hosts is present, it
+ is a "reverse" source route and indicates that the mail was
+ relayed through each host on the list (the first host in the
+ list was the most recent relay). This list is used as a
+ source route to return non-delivery notices to the sender.
+ As each relay host adds itself to the beginning of the list,
+ it must use its name as known in the IPCE to which it is
+ relaying the mail rather than the IPCE from which the mail
+ came (if they are different).
+
+ This command clears the reverse-path buffer, the
+ forward-path buffer, and the mail data buffer; and inserts
+ the reverse-path information from this command into the
+ reverse-path buffer.
+
+ SEND AND MAIL (SAML)
+
+ This command is used to initiate a mail transaction in which
+ the mail data is delivered to one or more terminals and
+ mailboxes. For each recipient the mail data is delivered to
+ the recipient's terminal if the recipient is active on the
+ host (and accepting terminal messages), and for all
+ recipients to the recipient's mailbox. The argument field
+ contains a reverse-path. This command is successful if the
+ message is delivered to the mailbox.
+
+ The reverse-path consists of an optional list of hosts and
+ the sender mailbox. When the list of hosts is present, it
+ is a "reverse" source route and indicates that the mail was
+ relayed through each host on the list (the first host in the
+ list was the most recent relay). This list is used as a
+ source route to return non-delivery notices to the sender.
+ As each relay host adds itself to the beginning of the list,
+ it must use its name as known in the IPCE to which it is
+ relaying the mail rather than the IPCE from which the mail
+ came (if they are different).
+
+ This command clears the reverse-path buffer, the
+
+_R_F_C_ _8_2_1 August 1982
+ Simple Mail Transfer Protocol
+
+ forward-path buffer, and the mail data buffer; and inserts
+ the reverse-path information from this command into the
+ reverse-path buffer.
+
+ RESET (RSET)
+
+ This command specifies that the current mail transaction is
+ to be aborted. Any stored sender, recipients, and mail data
+ must be discarded, and all buffers and state tables cleared.
+ The receiver must send an OK reply.
+
+ VERIFY (VRFY)
+
+ This command asks the receiver to confirm that the argument
+ identifies a user. If it is a user name, the full name of
+ the user (if known) and the fully specified mailbox are
+ returned.
+
+ This command has no effect on any of the reverse-path
+ buffer, the forward-path buffer, or the mail data buffer.
+
+ EXPAND (EXPN)
+
+ This command asks the receiver to confirm that the argument
+ identifies a mailing list, and if so, to return the
+ membership of that list. The full name of the users (if
+ known) and the fully specified mailboxes are returned in a
+ multiline reply.
+
+ This command has no effect on any of the reverse-path
+ buffer, the forward-path buffer, or the mail data buffer.
+
+ HELP (HELP)
+
+ This command causes the receiver to send helpful information
+ to the sender of the HELP command. The command may take an
+ argument (e.g., any command name) and return more specific
+ information as a response.
+
+ This command has no effect on any of the reverse-path
+ buffer, the forward-path buffer, or the mail data buffer.
+
+August 1982 _R_F_C_ _8_2_1
+Simple Mail Transfer Protocol
+
+ NOOP (NOOP)
+
+ This command does not affect any parameters or previously
+ entered commands. It specifies no action other than that
+ the receiver send an OK reply.
+
+ This command has no effect on any of the reverse-path
+ buffer, the forward-path buffer, or the mail data buffer.
+
+ QUIT (QUIT)
+
+ This command specifies that the receiver must send an OK
+ reply, and then close the transmission channel.
+
+ The receiver should not close the transmission channel until
+ it receives and replies to a QUIT command (even if there was
+ an error). The sender should not close the transmission
+ channel until it send a QUIT command and receives the reply
+ (even if there was an error response to a previous command).
+ If the connection is closed prematurely the receiver should
+ act as if a RSET command had been received (canceling any
+ pending transaction, but not undoing any previously
+ completed transaction), the sender should act as if the
+ command or transaction in progress had received a temporary
+ error (4xx).
+
+ TURN (TURN)
+
+ This command specifies that the receiver must either (1)
+ send an OK reply and then take on the role of the
+ sender-SMTP, or (2) send a refusal reply and retain the role
+ of the receiver-SMTP.
+
+ If program-A is currently the sender-SMTP and it sends the
+ TURN command and receives an OK reply (250) then program-A
+ becomes the receiver-SMTP. Program-A is then in the initial
+ state as if the transmission channel just opened, and it
+ then sends the 220 service ready greeting.
+
+ If program-B is currently the receiver-SMTP and it receives
+ the TURN command and sends an OK reply (250) then program-B
+ becomes the sender-SMTP. Program-B is then in the initial
+ state as if the transmission channel just opened, and it
+ then expects to receive the 220 service ready greeting.
+
+ To refuse to change roles the receiver sends the 502 reply.
+
+_R_F_C_ _8_2_1 August 1982
+ Simple Mail Transfer Protocol
+
+ There are restrictions on the order in which these command may
+ be used.
+
+ The first command in a session must be the HELO command.
+ The HELO command may be used later in a session as well. If
+ the HELO command argument is not acceptable a 501 failure
+ reply must be returned and the receiver-SMTP must stay in
+ the same state.
+
+ The NOOP, HELP, EXPN, and VRFY commands can be used at any
+ time during a session.
+
+ The MAIL, SEND, SOML, or SAML commands begin a mail
+ transaction. Once started a mail transaction consists of
+ one of the transaction beginning commands, one or more RCPT
+ commands, and a DATA command, in that order. A mail
+ transaction may be aborted by the RSET command. There may
+ be zero or more transactions in a session.
+
+ If the transaction beginning command argument is not
+ acceptable a 501 failure reply must be returned and the
+ receiver-SMTP must stay in the same state. If the commands
+ in a transaction are out of order a 503 failure reply must
+ be returned and the receiver-SMTP must stay in the same
+ state.
+
+ The last command in a session must be the QUIT command. The
+ QUIT command can not be used at any other time in a session.
+
+ 4.1.2. COMMAND SYNTAX
+
+ The commands consist of a command code followed by an argument
+ field. Command codes are four alphabetic characters. Upper
+ and lower case alphabetic characters are to be treated
+ identically. Thus, any of the following may represent the mail
+ command:
+
+ MAIL Mail mail MaIl mAIl
+
+ This also applies to any symbols representing parameter values,
+ such as "TO" or "to" for the forward-path. Command codes and
+ the argument fields are separated by one or more spaces.
+ However, within the reverse-path and forward-path arguments
+ case is important. In particular, in some hosts the user
+ "smith" is different from the user "Smith".
+
+August 1982 _R_F_C_ _8_2_1
+Simple Mail Transfer Protocol
+
+ The argument field consists of a variable length character
+ string ending with the character sequence <CRLF>. The receiver
+ is to take no action until this sequence is received.
+
+ Square brackets denote an optional argument field. If the
+ option is not taken, the appropriate default is implied.
+
+_R_F_C_ _8_2_1 August 1982
+ Simple Mail Transfer Protocol
+
+ The following are the SMTP commands:
+
+ HELO <SP> <domain> <CRLF>
+
+ MAIL <SP> FROM:<reverse-path> <CRLF>
+
+ RCPT <SP> TO:<forward-path> <CRLF>
+
+ DATA <CRLF>
+
+ RSET <CRLF>
+
+ SEND <SP> FROM:<reverse-path> <CRLF>
+
+ SOML <SP> FROM:<reverse-path> <CRLF>
+
+ SAML <SP> FROM:<reverse-path> <CRLF>
+
+ VRFY <SP> <string> <CRLF>
+
+ EXPN <SP> <string> <CRLF>
+
+ HELP [<SP> <string>] <CRLF>
+
+ NOOP <CRLF>
+
+ QUIT <CRLF>
+
+ TURN <CRLF>
+
+August 1982 _R_F_C_ _8_2_1
+Simple Mail Transfer Protocol
+
+ The syntax of the above argument fields (using BNF notation
+ where applicable) is given below. The "..." notation indicates
+ that a field may be repeated one or more times.
+
+ <reverse-path> ::= <path>
+
+ <forward-path> ::= <path>
+
+ <path> ::= "<" [ <a-d-l> ":" ] <mailbox> ">"
+
+ <a-d-l> ::= <at-domain> | <at-domain> "," <a-d-l>
+
+ <at-domain> ::= "@" <domain>
+
+ <domain> ::= <element> | <element> "." <domain>
+
+ <element> ::= <name> | "#" <number> | "[" <dotnum> "]"
+
+ <mailbox> ::= <local-part> "@" <domain>
+
+ <local-part> ::= <dot-string> | <quoted-string>
+
+ <name> ::= <a> <ldh-str> <let-dig>
+
+ <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
+
+ <let-dig> ::= <a> | <d>
+
+ <let-dig-hyp> ::= <a> | <d> | "-"
+
+ <dot-string> ::= <string> | <string> "." <dot-string>
+
+ <string> ::= <char> | <char> <string>
+
+ <quoted-string> ::= """ <qtext> """
+
+ <qtext> ::= "\" <x> | "\" <x> <qtext> | <q> | <q> <qtext>
+
+ <char> ::= <c> | "\" <x>
+
+ <dotnum> ::= <snum> "." <snum> "." <snum> "." <snum>
+
+ <number> ::= <d> | <d> <number>
+
+ <CRLF> ::= <CR> <LF>
+
+_R_F_C_ _8_2_1 August 1982
+ Simple Mail Transfer Protocol
+
+ <CR> ::= the carriage return character (ASCII code 13)
+
+ <LF> ::= the line feed character (ASCII code 10)
+
+ <SP> ::= the space character (ASCII code 32)
+
+ <snum> ::= one, two, or three digits representing a decimal
+ integer value in the range 0 through 255
+
+ <a> ::= any one of the 52 alphabetic characters A through Z
+ in upper case and a through z in lower case
+
+ <c> ::= any one of the 128 ASCII characters, but not any
+ <special> or <SP>
+
+ <d> ::= any one of the ten digits 0 through 9
+
+ <q> ::= any one of the 128 ASCII characters except <CR>,
+ <LF>, quote ("), or backslash (\)
+
+ <x> ::= any one of the 128 ASCII characters (no exceptions)
+
+ <special> ::= "<" | ">" | "(" | ")" | "[" | "]" | "\" | "."
+ | "," | ";" | ":" | "@" """ | the control
+ characters (ASCII codes 0 through 31 inclusive and
+ 127)
+
+ Note that the backslash, "\", is a quote character, which is
+ used to indicate that the next character is to be used
+ literally (instead of its normal interpretation). For example,
+ "Joe\,Smith" could be used to indicate a single nine character
+ user field with comma being the fourth character of the field.
+
+ Hosts are generally known by names which are translated to
+ addresses in each host. Note that the name elements of domains
+ are the official names -- no use of nicknames or aliases is
+ allowed.
+
+ Sometimes a host is not known to the translation function and
+ communication is blocked. To bypass this barrier two numeric
+ forms are also allowed for host "names". One form is a decimal
+ integer prefixed by a pound sign, "#", which indicates the
+ number is the address of the host. Another form is four small
+ decimal integers separated by dots and enclosed by brackets,
+ e.g., "[123.255.37.2]", which indicates a 32-bit ARPA Internet
+ Address in four 8-bit fields.
+
+August 1982 _R_F_C_ _8_2_1
+Simple Mail Transfer Protocol
+
+ The time stamp line and the return path line are formally
+ defined as follows:
+
+ <return-path-line> ::= "Return-Path:" <SP><reverse-path><CRLF>
+
+ <time-stamp-line> ::= "Received:" <SP> <stamp> <CRLF>
+
+ <stamp> ::= <from-domain> <by-domain> <opt-info> ";"
+ <daytime>
+
+ <from-domain> ::= "FROM" <SP> <domain> <SP>
+
+ <by-domain> ::= "BY" <SP> <domain> <SP>
+
+ <opt-info> ::= [<via>] [<with>] [<id>] [<for>]
+
+ <via> ::= "VIA" <SP> <link> <SP>
+
+ <with> ::= "WITH" <SP> <protocol> <SP>
+
+ <id> ::= "ID" <SP> <string> <SP>
+
+ <for> ::= "FOR" <SP> <path> <SP>
+
+ <link> ::= The standard names for links are registered with
+ the Network Information Center.
+
+ <protocol> ::= The standard names for protocols are
+ registered with the Network Information Center.
+
+ <daytime> ::= <SP> <date> <SP> <time>
+
+ <date> ::= <dd> <SP> <mon> <SP> <yy>
+
+ <time> ::= <hh> ":" <mm> ":" <ss> <SP> <zone>
+
+ <dd> ::= the one or two decimal integer day of the month in
+ the range 1 to 31.
+
+ <mon> ::= "JAN" | "FEB" | "MAR" | "APR" | "MAY" | "JUN" |
+ "JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC"
+
+ <yy> ::= the two decimal integer year of the century in the
+ range 00 to 99.
+
+_R_F_C_ _8_2_1 August 1982
+ Simple Mail Transfer Protocol
+
+ <hh> ::= the two decimal integer hour of the day in the
+ range 00 to 24.
+
+ <mm> ::= the two decimal integer minute of the hour in the
+ range 00 to 59.
+
+ <ss> ::= the two decimal integer second of the minute in the
+ range 00 to 59.
+
+ <zone> ::= "UT" for Universal Time (the default) or other
+ time zone designator (as in [2]).
+
+ -------------------------------------------------------------
+
+ Return Path Example
+
+ Return-Path: <@CHARLIE.ARPA,@BAKER.ARPA:_J_O_E_@_A_B_L_E_._A_R_P_A>
+
+ Example 9
+
+ -------------------------------------------------------------
+
+ -------------------------------------------------------------
+
+ Time Stamp Line Example
+
+ Received: FROM ABC.ARPA BY XYZ.ARPA ; 22 OCT 81 09:23:59 PDT
+
+ Received: from ABC.ARPA by XYZ.ARPA via TELENET with X25
+ id M12345 for _S_m_i_t_h_@_P_D_Q_._A_R_P_A ; 22 OCT 81 09:23:59 PDT
+
+ Example 10
+
+ -------------------------------------------------------------
+
+August 1982 _R_F_C_ _8_2_1
+Simple Mail Transfer Protocol
+
+ 4.2. SMTP REPLIES
+
+ Replies to SMTP commands are devised to ensure the synchronization
+ of requests and actions in the process of mail transfer, and to
+ guarantee that the sender-SMTP always knows the state of the
+ receiver-SMTP. Every command must generate exactly one reply.
+
+ The details of the command-reply sequence are made explicit in
+ Section 5.3 on Sequencing and Section 5.4 State Diagrams.
+
+ An SMTP reply consists of a three digit number (transmitted as
+ three alphanumeric characters) followed by some text. The number
+ is intended for use by automata to determine what state to enter
+ next; the text is meant for the human user. It is intended that
+ the three digits contain enough encoded information that the
+ sender-SMTP need not examine the text and may either discard it or
+ pass it on to the user, as appropriate. In particular, the text
+ may be receiver-dependent and context dependent, so there are
+ likely to be varying texts for each reply code. A discussion of
+ the theory of reply codes is given in Appendix E. Formally, a
+ reply is defined to be the sequence: a three-digit code, <SP>,
+ one line of text, and <CRLF>, or a multiline reply (as defined in
+ Appendix E). Only the EXPN and HELP commands are expected to
+ result in multiline replies in normal circumstances, however
+ multiline replies are allowed for any command.
+
+_R_F_C_ _8_2_1 August 1982
+ Simple Mail Transfer Protocol
+
+ 4.2.1. REPLY CODES BY FUNCTION GROUPS
+
+ 500 Syntax error, command unrecognized
+ [This may include errors such as command line too long]
+ 501 Syntax error in parameters or arguments
+ 502 Command not implemented
+ 503 Bad sequence of commands
+ 504 Command parameter not implemented
+
+ 211 System status, or system help reply
+ 214 Help message
+ [Information on how to use the receiver or the meaning of a
+ particular non-standard command; this reply is useful only
+ to the human user]
+
+ 220 <domain> Service ready
+ 221 <domain> Service closing transmission channel
+ 421 <domain> Service not available,
+ closing transmission channel
+ [This may be a reply to any command if the service knows it
+ must shut down]
+
+ 250 Requested mail action okay, completed
+ 251 User not local; will forward to <forward-path>
+ 450 Requested mail action not taken: mailbox unavailable
+ [E.g., mailbox busy]
+ 550 Requested action not taken: mailbox unavailable
+ [E.g., mailbox not found, no access]
+ 451 Requested action aborted: error in processing
+ 551 User not local; please try <forward-path>
+ 452 Requested action not taken: insufficient system storage
+ 552 Requested mail action aborted: exceeded storage allocation
+ 553 Requested action not taken: mailbox name not allowed
+ [E.g., mailbox syntax incorrect]
+ 354 Start mail input; end with <CRLF>.<CRLF>
+ 554 Transaction failed
+
+August 1982 _R_F_C_ _8_2_1
+Simple Mail Transfer Protocol
+
+ 4.2.2. NUMERIC ORDER LIST OF REPLY CODES
+
+ 211 System status, or system help reply
+ 214 Help message
+ [Information on how to use the receiver or the meaning of a
+ particular non-standard command; this reply is useful only
+ to the human user]
+ 220 <domain> Service ready
+ 221 <domain> Service closing transmission channel
+ 250 Requested mail action okay, completed
+ 251 User not local; will forward to <forward-path>
+
+ 354 Start mail input; end with <CRLF>.<CRLF>
+
+ 421 <domain> Service not available,
+ closing transmission channel
+ [This may be a reply to any command if the service knows it
+ must shut down]
+ 450 Requested mail action not taken: mailbox unavailable
+ [E.g., mailbox busy]
+ 451 Requested action aborted: local error in processing
+ 452 Requested action not taken: insufficient system storage
+
+ 500 Syntax error, command unrecognized
+ [This may include errors such as command line too long]
+ 501 Syntax error in parameters or arguments
+ 502 Command not implemented
+ 503 Bad sequence of commands
+ 504 Command parameter not implemented
+ 550 Requested action not taken: mailbox unavailable
+ [E.g., mailbox not found, no access]
+ 551 User not local; please try <forward-path>
+ 552 Requested mail action aborted: exceeded storage allocation
+ 553 Requested action not taken: mailbox name not allowed
+ [E.g., mailbox syntax incorrect]
+ 554 Transaction failed
+
+_R_F_C_ _8_2_1 August 1982
+ Simple Mail Transfer Protocol
+
+ 4.3. SEQUENCING OF COMMANDS AND REPLIES
+
+ The communication between the sender and receiver is intended to
+ be an alternating dialogue, controlled by the sender. As such,
+ the sender issues a command and the receiver responds with a
+ reply. The sender must wait for this response before sending
+ further commands.
+
+ One important reply is the connection greeting. Normally, a
+ receiver will send a 220 "Service ready" reply when the connection
+ is completed. The sender should wait for this greeting message
+ before sending any commands.
+
+ Note: all the greeting type replies have the official name of
+ the server host as the first word following the reply code.
+
+ For example,
+
+ 220 <SP> USC-ISIF.ARPA <SP> Service ready <CRLF>
+
+ The table below lists alternative success and failure replies for
+ each command. These must be strictly adhered to; a receiver may
+ substitute text in the replies, but the meaning and action implied
+ by the code numbers and by the specific command reply sequence
+ cannot be altered.
+
+ COMMAND-REPLY SEQUENCES
+
+ Each command is listed with its possible replies. The prefixes
+ used before the possible replies are "P" for preliminary (not
+ used in SMTP), "I" for intermediate, "S" for success, "F" for
+ failure, and "E" for error. The 421 reply (service not
+ available, closing transmission channel) may be given to any
+ command if the SMTP-receiver knows it must shut down. This
+ listing forms the basis for the State Diagrams in Section 4.4.
+
+ CONNECTION ESTABLISHMENT
+ S: 220
+ F: 421
+ HELO
+ S: 250
+ E: 500, 501, 504, 421
+ MAIL
+ S: 250
+ F: 552, 451, 452
+ E: 500, 501, 421
+
+August 1982 _R_F_C_ _8_2_1
+Simple Mail Transfer Protocol
+
+ RCPT
+ S: 250, 251
+ F: 550, 551, 552, 553, 450, 451, 452
+ E: 500, 501, 503, 421
+ DATA
+ I: 354 -> data -> S: 250
+ F: 552, 554, 451, 452
+ F: 451, 554
+ E: 500, 501, 503, 421
+ RSET
+ S: 250
+ E: 500, 501, 504, 421
+ SEND
+ S: 250
+ F: 552, 451, 452
+ E: 500, 501, 502, 421
+ SOML
+ S: 250
+ F: 552, 451, 452
+ E: 500, 501, 502, 421
+ SAML
+ S: 250
+ F: 552, 451, 452
+ E: 500, 501, 502, 421
+ VRFY
+ S: 250, 251
+ F: 550, 551, 553
+ E: 500, 501, 502, 504, 421
+ EXPN
+ S: 250
+ F: 550
+ E: 500, 501, 502, 504, 421
+ HELP
+ S: 211, 214
+ E: 500, 501, 502, 504, 421
+ NOOP
+ S: 250
+ E: 500, 421
+ QUIT
+ S: 221
+ E: 500
+ TURN
+ S: 250
+ F: 502
+ E: 500, 503
+
+_R_F_C_ _8_2_1 August 1982
+ Simple Mail Transfer Protocol
+
+ 4.4. STATE DIAGRAMS
+
+ Following are state diagrams for a simple-minded SMTP
+ implementation. Only the first digit of the reply codes is used.
+ There is one state diagram for each group of SMTP commands. The
+ command groupings were determined by constructing a model for each
+ command and then collecting together the commands with
+ structurally identical models.
+
+ For each command there are three possible outcomes: "success"
+ (S), "failure" (F), and "error" (E). In the state diagrams below
+ we use the symbol B for "begin", and the symbol W for "wait for
+ reply".
+
+ First, the diagram that represents most of the SMTP commands:
+
+ 1,3 +---+
+ ----------->| E |
+ | +---+
+ |
+ +---+ cmd +---+ 2 +---+
+ | B |---------->| W |---------->| S |
+ +---+ +---+ +---+
+ |
+ | 4,5 +---+
+ ----------->| F |
+ +---+
+
+ This diagram models the commands:
+
+ HELO, MAIL, RCPT, RSET, SEND, SOML, SAML, VRFY, EXPN, HELP,
+ NOOP, QUIT, TURN.
+
+August 1982 _R_F_C_ _8_2_1
+Simple Mail Transfer Protocol
+
+ A more complex diagram models the DATA command:
+
+ +---+ DATA +---+ 1,2 +---+
+ | B |---------->| W |-------------------->| E |
+ +---+ +---+ ------------>+---+
+ 3| |4,5 |
+ | | |
+ -------------- ----- |
+ | | | +---+
+ | ---------- -------->| S |
+ | | | | +---+
+ | | ------------
+ | | | |
+ V 1,3| |2 |
+ +---+ data +---+ --------------->+---+
+ | |---------->| W | | F |
+ +---+ +---+-------------------->+---+
+ 4,5
+
+ Note that the "data" here is a series of lines sent from the
+ sender to the receiver with no response expected until the last
+ line is sent.
+
+_R_F_C_ _8_2_1 August 1982
+ Simple Mail Transfer Protocol
+
+ 4.5. DETAILS
+
+ 4.5.1. MINIMUM IMPLEMENTATION
+
+ In order to make SMTP workable, the following minimum
+ implementation is required for all receivers:
+
+ COMMANDS -- HELO
+ MAIL
+ RCPT
+ DATA
+ RSET
+ NOOP
+ QUIT
+
+ 4.5.2. TRANSPARENCY
+
+ Without some provision for data transparency the character
+ sequence "<CRLF>.<CRLF>" ends the mail text and cannot be sent
+ by the user. In general, users are not aware of such
+ "forbidden" sequences. To allow all user composed text to be
+ transmitted transparently the following procedures are used.
+
+ 1. Before sending a line of mail text the sender-SMTP checks
+ the first character of the line. If it is a period, one
+ additional period is inserted at the beginning of the line.
+
+ 2. When a line of mail text is received by the receiver-SMTP
+ it checks the line. If the line is composed of a single
+ period it is the end of mail. If the first character is a
+ period and there are other characters on the line, the first
+ character is deleted.
+
+ The mail data may contain any of the 128 ASCII characters. All
+ characters are to be delivered to the recipient's mailbox
+ including format effectors and other control characters. If
+ the transmission channel provides an 8-bit byte (octets) data
+ stream, the 7-bit ASCII codes are transmitted right justified
+ in the octets with the high order bits cleared to zero.
+
+ In some systems it may be necessary to transform the data as
+ it is received and stored. This may be necessary for hosts
+ that use a different character set than ASCII as their local
+ character set, or that store data in records rather than
+
+August 1982 _R_F_C_ _8_2_1
+Simple Mail Transfer Protocol
+
+ strings. If such transforms are necessary, they must be
+ reversible -- especially if such transforms are applied to
+ mail being relayed.
+
+ 4.5.3. SIZES
+
+ There are several objects that have required minimum maximum
+ sizes. That is, every implementation must be able to receive
+ objects of at least these sizes, but must not send objects
+ larger than these sizes.
+
+ ****************************************************
+ * *
+ * TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION *
+ * TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH *
+ * OF THESE OBJECTS SHOULD BE USED. *
+ * *
+ ****************************************************
+
+ user
+
+ The maximum total length of a user name is 64 characters.
+
+ domain
+
+ The maximum total length of a domain name or number is 64
+ characters.
+
+ path
+
+ The maximum total length of a reverse-path or
+ forward-path is 256 characters (including the punctuation
+ and element separators).
+
+ command line
+
+ The maximum total length of a command line including the
+ command word and the <CRLF> is 512 characters.
+
+ reply line
+
+ The maximum total length of a reply line including the
+ reply code and the <CRLF> is 512 characters.
+
+_R_F_C_ _8_2_1 August 1982
+ Simple Mail Transfer Protocol
+
+ text line
+
+ The maximum total length of a text line including the
+ <CRLF> is 1000 characters (but not counting the leading
+ dot duplicated for transparency).
+
+ recipients buffer
+
+ The maximum total number of recipients that must be
+ buffered is 100 recipients.
+
+ ****************************************************
+ * *
+ * TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION *
+ * TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH *
+ * OF THESE OBJECTS SHOULD BE USED. *
+ * *
+ ****************************************************
+
+ Errors due to exceeding these limits may be reported by using
+ the reply codes, for example:
+
+ 500 Line too long.
+
+ 501 Path too long
+
+ 552 Too many recipients.
+
+ 552 Too much mail data.
+
+August 1982 _R_F_C_ _8_2_1
+Simple Mail Transfer Protocol
+
+APPENDIX A
+
+ TCP Transport service
+
+ The Transmission Control Protocol [3] is used in the ARPA
+ Internet, and in any network following the US DoD standards for
+ internetwork protocols.
+
+ Connection Establishment
+
+ The SMTP transmission channel is a TCP connection established
+ between the sender process port U and the receiver process port
+ L. This single full duplex connection is used as the
+ transmission channel. This protocol is assigned the service
+ port 25 (31 octal), that is L=25.
+
+ Data Transfer
+
+ The TCP connection supports the transmission of 8-bit bytes.
+ The SMTP data is 7-bit ASCII characters. Each character is
+ transmitted as an 8-bit byte with the high-order bit cleared to
+ zero.
+
+_R_F_C_ _8_2_1 August 1982
+ Simple Mail Transfer Protocol
+
+APPENDIX B
+
+ NCP Transport service
+
+ The ARPANET Host-to-Host Protocol [4] (implemented by the Network
+ Control Program) may be used in the ARPANET.
+
+ Connection Establishment
+
+ The SMTP transmission channel is established via NCP between
+ the sender process socket U and receiver process socket L. The
+ Initial Connection Protocol [5] is followed resulting in a pair
+ of simplex connections. This pair of connections is used as
+ the transmission channel. This protocol is assigned the
+ contact socket 25 (31 octal), that is L=25.
+
+ Data Transfer
+
+ The NCP data connections are established in 8-bit byte mode.
+ The SMTP data is 7-bit ASCII characters. Each character is
+ transmitted as an 8-bit byte with the high-order bit cleared to
+ zero.
+
+August 1982 _R_F_C_ _8_2_1
+Simple Mail Transfer Protocol
+
+APPENDIX C
+
+ NITS
+
+ The Network Independent Transport Service [6] may be used.
+
+ Connection Establishment
+
+ The SMTP transmission channel is established via NITS between
+ the sender process and receiver process. The sender process
+ executes the CONNECT primitive, and the waiting receiver
+ process executes the ACCEPT primitive.
+
+ Data Transfer
+
+ The NITS connection supports the transmission of 8-bit bytes.
+ The SMTP data is 7-bit ASCII characters. Each character is
+ transmitted as an 8-bit byte with the high-order bit cleared to
+ zero.
+
+_R_F_C_ _8_2_1 August 1982
+ Simple Mail Transfer Protocol
+
+APPENDIX D
+
+ X.25 Transport service
+
+ It may be possible to use the X.25 service [7] as provided by the
+ Public Data Networks directly, however, it is suggested that a
+ reliable end-to-end protocol such as TCP be used on top of X.25
+ connections.
+
+August 1982 _R_F_C_ _8_2_1
+Simple Mail Transfer Protocol
+
+APPENDIX E
+
+ Theory of Reply Codes
+
+ The three digits of the reply each have a special significance.
+ The first digit denotes whether the response is good, bad or
+ incomplete. An unsophisticated sender-SMTP will be able to
+ determine its next action (proceed as planned, redo, retrench,
+ etc.) by simply examining this first digit. A sender-SMTP that
+ wants to know approximately what kind of error occurred (e.g.,
+ mail system error, command syntax error) may examine the second
+ digit, reserving the third digit for the finest gradation of
+ information.
+
+ There are five values for the first digit of the reply code:
+
+ 1yz Positive Preliminary reply
+
+ The command has been accepted, but the requested action
+ is being held in abeyance, pending confirmation of the
+ information in this reply. The sender-SMTP should send
+ another command specifying whether to continue or abort
+ the action.
+
+ [Note: SMTP does not have any commands that allow this
+ type of reply, and so does not have the continue or
+ abort commands.]
+
+ 2yz Positive Completion reply
+
+ The requested action has been successfully completed. A
+ new request may be initiated.
+
+ 3yz Positive Intermediate reply
+
+ The command has been accepted, but the requested action
+ is being held in abeyance, pending receipt of further
+ information. The sender-SMTP should send another command
+ specifying this information. This reply is used in
+ command sequence groups.
+
+ 4yz Transient Negative Completion reply
+
+ The command was not accepted and the requested action did
+ not occur. However, the error condition is temporary and
+ the action may be requested again. The sender should
+
+_R_F_C_ _8_2_1 August 1982
+ Simple Mail Transfer Protocol
+
+ return to the beginning of the command sequence (if any).
+ It is difficult to assign a meaning to "transient" when
+ two different sites (receiver- and sender- SMTPs) must
+ agree on the interpretation. Each reply in this category
+ might have a different time value, but the sender-SMTP is
+ encouraged to try again. A rule of thumb to determine if
+ a reply fits into the 4yz or the 5yz category (see below)
+ is that replies are 4yz if they can be repeated without
+ any change in command form or in properties of the sender
+ or receiver. (E.g., the command is repeated identically
+ and the receiver does not put up a new implementation.)
+
+ 5yz Permanent Negative Completion reply
+
+ The command was not accepted and the requested action did
+ not occur. The sender-SMTP is discouraged from repeating
+ the exact request (in the same sequence). Even some
+ "permanent" error conditions can be corrected, so the
+ human user may want to direct the sender-SMTP to
+ reinitiate the command sequence by direct action at some
+ point in the future (e.g., after the spelling has been
+ changed, or the user has altered the account status).
+
+ The second digit encodes responses in specific categories:
+
+ x0z Syntax -- These replies refer to syntax errors,
+ syntactically correct commands that don't fit any
+ functional category, and unimplemented or superfluous
+ commands.
+
+ x1z Information -- These are replies to requests for
+ information, such as status or help.
+
+ x2z Connections -- These are replies referring to the
+ transmission channel.
+
+ x3z Unspecified as yet.
+
+ x4z Unspecified as yet.
+
+ x5z Mail system -- These replies indicate the status of
+ the receiver mail system vis-a-vis the requested
+ transfer or other mail system action.
+
+ The third digit gives a finer gradation of meaning in each
+ category specified by the second digit. The list of replies
+
+August 1982 _R_F_C_ _8_2_1
+Simple Mail Transfer Protocol
+
+ illustrates this. Each reply text is recommended rather than
+ mandatory, and may even change according to the command with
+ which it is associated. On the other hand, the reply codes
+ must strictly follow the specifications in this section.
+ Receiver implementations should not invent new codes for
+ slightly different situations from the ones described here, but
+ rather adapt codes already defined.
+
+ For example, a command such as NOOP whose successful execution
+ does not offer the sender-SMTP any new information will return
+ a 250 reply. The response is 502 when the command requests an
+ unimplemented non-site-specific action. A refinement of that
+ is the 504 reply for a command that is implemented, but that
+ requests an unimplemented parameter.
+
+ The reply text may be longer than a single line; in these cases
+ the complete text must be marked so the sender-SMTP knows when it
+ can stop reading the reply. This requires a special format to
+ indicate a multiple line reply.
+
+ The format for multiline replies requires that every line,
+ except the last, begin with the reply code, followed
+ immediately by a hyphen, "-" (also known as minus), followed by
+ text. The last line will begin with the reply code, followed
+ immediately by <SP>, optionally some text, and <CRLF>.
+
+ For example:
+ 123-First line
+ 123-Second line
+ 123-234 text beginning with numbers
+ 123 The last line
+
+ In many cases the sender-SMTP then simply needs to search for
+ the reply code followed by <SP> at the beginning of a line, and
+ ignore all preceding lines. In a few cases, there is important
+ data for the sender in the reply "text". The sender will know
+ these cases from the current context.
+
+_R_F_C_ _8_2_1 August 1982
+ Simple Mail Transfer Protocol
+
+APPENDIX F
+
+ Scenarios
+
+ This section presents complete scenarios of several types of SMTP
+ sessions.
+
+ A Typical SMTP Transaction Scenario
+
+ This SMTP example shows mail sent by Smith at host USC-ISIF, to
+ Jones, Green, and Brown at host BBN-UNIX. Here we assume that
+ host USC-ISIF contacts host BBN-UNIX directly. The mail is
+ accepted for Jones and Brown. Green does not have a mailbox at
+ host BBN-UNIX.
+
+ -------------------------------------------------------------
+
+ R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready
+ S: HELO USC-ISIF.ARPA
+ R: 250 BBN-UNIX.ARPA
+
+ S: MAIL FROM:<_S_m_i_t_h_@_U_S_C_-_I_S_I_F_._A_R_P_A>
+ R: 250 OK
+
+ S: RCPT TO:<_J_o_n_e_s_@_B_B_N_-_U_N_I_X_._A_R_P_A>
+ R: 250 OK
+
+ S: RCPT TO:<_G_r_e_e_n_@_B_B_N_-_U_N_I_X_._A_R_P_A>
+ R: 550 No such user here
+
+ S: RCPT TO:<_B_r_o_w_n_@_B_B_N_-_U_N_I_X_._A_R_P_A>
+ R: 250 OK
+
+ S: DATA
+ R: 354 Start mail input; end with <CRLF>.<CRLF>
+ S: Blah blah blah...
+ S: ...etc. etc. etc.
+ S: .
+ R: 250 OK
+
+ S: QUIT
+ R: 221 BBN-UNIX.ARPA Service closing transmission channel
+
+ Scenario 1
+
+ -------------------------------------------------------------
+
+August 1982 _R_F_C_ _8_2_1
+Simple Mail Transfer Protocol
+
+ Aborted SMTP Transaction Scenario
+
+ -------------------------------------------------------------
+
+ R: 220 MIT-Multics.ARPA Simple Mail Transfer Service Ready
+ S: HELO ISI-VAXA.ARPA
+ R: 250 MIT-Multics.ARPA
+
+ S: MAIL FROM:<_S_m_i_t_h_@_I_S_I_-_V_A_X_A_._A_R_P_A>
+ R: 250 OK
+
+ S: RCPT TO:<_J_o_n_e_s_@_M_I_T_-_M_u_l_t_i_c_s_._A_R_P_A>
+ R: 250 OK
+
+ S: RCPT TO:<_G_r_e_e_n_@_M_I_T_-_M_u_l_t_i_c_s_._A_R_P_A>
+ R: 550 No such user here
+
+ S: RSET
+ R: 250 OK
+
+ S: QUIT
+ R: 221 MIT-Multics.ARPA Service closing transmission channel
+
+ Scenario 2
+
+ -------------------------------------------------------------
+
+_R_F_C_ _8_2_1 August 1982
+ Simple Mail Transfer Protocol
+
+ Relayed Mail Scenario
+
+ -------------------------------------------------------------
+
+ Step 1 -- Source Host to Relay Host
+
+ R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready
+ S: HELO MIT-AI.ARPA
+ R: 250 USC-ISIE.ARPA
+
+ S: MAIL FROM:<_J_Q_P_@_M_I_T_-_A_I_._A_R_P_A>
+ R: 250 OK
+
+ S: RCPT TO:<@USC-ISIE.ARPA:_J_o_n_e_s_@_B_B_N_-_V_A_X_._A_R_P_A>
+ R: 250 OK
+
+ S: DATA
+ R: 354 Start mail input; end with <CRLF>.<CRLF>
+ S: Date: 2 Nov 81 22:33:44
+ S: From: John Q. Public <_J_Q_P_@_M_I_T_-_A_I_._A_R_P_A>
+ S: Subject: The Next Meeting of the Board
+ S: To: _J_o_n_e_s_@_B_B_N_-_V_a_x_._A_R_P_A
+ S:
+ S: Bill:
+ S: The next meeting of the board of directors will be
+ S: on Tuesday.
+ S: John.
+ S: .
+ R: 250 OK
+
+ S: QUIT
+ R: 221 USC-ISIE.ARPA Service closing transmission channel
+
+August 1982 _R_F_C_ _8_2_1
+Simple Mail Transfer Protocol
+
+ Step 2 -- Relay Host to Destination Host
+
+ R: 220 BBN-VAX.ARPA Simple Mail Transfer Service Ready
+ S: HELO USC-ISIE.ARPA
+ R: 250 BBN-VAX.ARPA
+
+ S: MAIL FROM:<@USC-ISIE.ARPA:_J_Q_P_@_M_I_T_-_A_I_._A_R_P_A>
+ R: 250 OK
+
+ S: RCPT TO:<_J_o_n_e_s_@_B_B_N_-_V_A_X_._A_R_P_A>
+ R: 250 OK
+
+ S: DATA
+ R: 354 Start mail input; end with <CRLF>.<CRLF>
+ S: Received: from MIT-AI.ARPA by USC-ISIE.ARPA ;
+ 2 Nov 81 22:40:10 UT
+ S: Date: 2 Nov 81 22:33:44
+ S: From: John Q. Public <_J_Q_P_@_M_I_T_-_A_I_._A_R_P_A>
+ S: Subject: The Next Meeting of the Board
+ S: To: _J_o_n_e_s_@_B_B_N_-_V_a_x_._A_R_P_A
+ S:
+ S: Bill:
+ S: The next meeting of the board of directors will be
+ S: on Tuesday.
+ S: John.
+ S: .
+ R: 250 OK
+
+ S: QUIT
+ R: 221 USC-ISIE.ARPA Service closing transmission channel
+
+ Scenario 3
+
+ -------------------------------------------------------------
+
+_R_F_C_ _8_2_1 August 1982
+ Simple Mail Transfer Protocol
+
+ Verifying and Sending Scenario
+
+ -------------------------------------------------------------
+
+ R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready
+ S: HELO MIT-MC.ARPA
+ R: 250 SU-SCORE.ARPA
+
+ S: VRFY Crispin
+ R: 250 Mark Crispin <_A_d_m_i_n_._M_R_C_@_S_U_-_S_C_O_R_E_._A_R_P_A>
+
+ S: SEND FROM:<_E_A_K_@_M_I_T_-_M_C_._A_R_P_A>
+ R: 250 OK
+
+ S: RCPT TO:<_A_d_m_i_n_._M_R_C_@_S_U_-_S_C_O_R_E_._A_R_P_A>
+ R: 250 OK
+
+ S: DATA
+ R: 354 Start mail input; end with <CRLF>.<CRLF>
+ S: Blah blah blah...
+ S: ...etc. etc. etc.
+ S: .
+ R: 250 OK
+
+ S: QUIT
+ R: 221 SU-SCORE.ARPA Service closing transmission channel
+
+ Scenario 4
+
+ -------------------------------------------------------------
+
+August 1982 _R_F_C_ _8_2_1
+Simple Mail Transfer Protocol
+
+ Sending and Mailing Scenarios
+
+ First the user's name is verified, then an attempt is made to
+ send to the user's terminal. When that fails, the messages is
+ mailed to the user's mailbox.
+
+ -------------------------------------------------------------
+
+ R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready
+ S: HELO MIT-MC.ARPA
+ R: 250 SU-SCORE.ARPA
+
+ S: VRFY Crispin
+ R: 250 Mark Crispin <_A_d_m_i_n_._M_R_C_@_S_U_-_S_C_O_R_E_._A_R_P_A>
+
+ S: SEND FROM:<_E_A_K_@_M_I_T_-_M_C_._A_R_P_A>
+ R: 250 OK
+
+ S: RCPT TO:<_A_d_m_i_n_._M_R_C_@_S_U_-_S_C_O_R_E_._A_R_P_A>
+ R: 450 User not active now
+
+ S: RSET
+ R: 250 OK
+
+ S: MAIL FROM:<_E_A_K_@_M_I_T_-_M_C_._A_R_P_A>
+ R: 250 OK
+
+ S: RCPT TO:<_A_d_m_i_n_._M_R_C_@_S_U_-_S_C_O_R_E_._A_R_P_A>
+ R: 250 OK
+
+ S: DATA
+ R: 354 Start mail input; end with <CRLF>.<CRLF>
+ S: Blah blah blah...
+ S: ...etc. etc. etc.
+ S: .
+ R: 250 OK
+
+ S: QUIT
+ R: 221 SU-SCORE.ARPA Service closing transmission channel
+
+ Scenario 5
+
+ -------------------------------------------------------------
+
+_R_F_C_ _8_2_1 August 1982
+ Simple Mail Transfer Protocol
+
+ Doing the preceding scenario more efficiently.
+
+ -------------------------------------------------------------
+
+ R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready
+ S: HELO MIT-MC.ARPA
+ R: 250 SU-SCORE.ARPA
+
+ S: VRFY Crispin
+ R: 250 Mark Crispin <_A_d_m_i_n_._M_R_C_@_S_U_-_S_C_O_R_E_._A_R_P_A>
+
+ S: SOML FROM:<_E_A_K_@_M_I_T_-_M_C_._A_R_P_A>
+ R: 250 OK
+
+ S: RCPT TO:<_A_d_m_i_n_._M_R_C_@_S_U_-_S_C_O_R_E_._A_R_P_A>
+ R: 250 User not active now, so will do mail.
+
+ S: DATA
+ R: 354 Start mail input; end with <CRLF>.<CRLF>
+ S: Blah blah blah...
+ S: ...etc. etc. etc.
+ S: .
+ R: 250 OK
+
+ S: QUIT
+ R: 221 SU-SCORE.ARPA Service closing transmission channel
+
+ Scenario 6
+
+ -------------------------------------------------------------
+
+August 1982 _R_F_C_ _8_2_1
+Simple Mail Transfer Protocol
+
+ Mailing List Scenario
+
+ First each of two mailing lists are expanded in separate sessions
+ with different hosts. Then the message is sent to everyone that
+ appeared on either list (but no duplicates) via a relay host.
+
+ -------------------------------------------------------------
+
+ Step 1 -- Expanding the First List
+
+ R: 220 MIT-AI.ARPA Simple Mail Transfer Service Ready
+ S: HELO SU-SCORE.ARPA
+ R: 250 MIT-AI.ARPA
+
+ S: EXPN Example-People
+ R: 250-<_A_B_C_@_M_I_T_-_M_C_._A_R_P_A>
+ R: 250-Fred Fonebone <_F_o_n_e_b_o_n_e_@_U_S_C_-_I_S_I_Q_._A_R_P_A>
+ R: 250-Xenon Y. Zither <_X_Y_Z_@_M_I_T_-_A_I_._A_R_P_A>
+ R: 250-Quincy Smith <@USC-ISIF.ARPA:_Q_-_S_m_i_t_h_@_I_S_I_-_V_A_X_A_._A_R_P_A>
+ R: 250-<_j_o_e_@_f_o_o_-_u_n_i_x_._A_R_P_A>
+ R: 250 <_x_y_z_@_b_a_r_-_u_n_i_x_._A_R_P_A>
+
+ S: QUIT
+ R: 221 MIT-AI.ARPA Service closing transmission channel
+
+_R_F_C_ _8_2_1 August 1982
+ Simple Mail Transfer Protocol
+
+ Step 2 -- Expanding the Second List
+
+ R: 220 MIT-MC.ARPA Simple Mail Transfer Service Ready
+ S: HELO SU-SCORE.ARPA
+ R: 250 MIT-MC.ARPA
+
+ S: EXPN Interested-Parties
+ R: 250-Al Calico <_A_B_C_@_M_I_T_-_M_C_._A_R_P_A>
+ R: 250-<_X_Y_Z_@_M_I_T_-_A_I_._A_R_P_A>
+ R: 250-Quincy Smith <@USC-ISIF.ARPA:_Q_-_S_m_i_t_h_@_I_S_I_-_V_A_X_A_._A_R_P_A>
+ R: 250-<_f_r_e_d_@_B_B_N_-_U_N_I_X_._A_R_P_A>
+ R: 250 <_x_y_z_@_b_a_r_-_u_n_i_x_._A_R_P_A>
+
+ S: QUIT
+ R: 221 MIT-MC.ARPA Service closing transmission channel
+
+August 1982 _R_F_C_ _8_2_1
+Simple Mail Transfer Protocol
+
+ Step 3 -- Mailing to All via a Relay Host
+
+ R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready
+ S: HELO SU-SCORE.ARPA
+ R: 250 USC-ISIE.ARPA
+
+ S: MAIL FROM:<_A_c_c_o_u_n_t_._P_e_r_s_o_n_@_S_U_-_S_C_O_R_E_._A_R_P_A>
+ R: 250 OK
+ S: RCPT TO:<@USC-ISIE.ARPA:_A_B_C_@_M_I_T_-_M_C_._A_R_P_A>
+ R: 250 OK
+ S: RCPT TO:<@USC-ISIE.ARPA:_F_o_n_e_b_o_n_e_@_U_S_C_-_I_S_I_Q_A_._A_R_P_A>
+ R: 250 OK
+ S: RCPT TO:<@USC-ISIE.ARPA:_X_Y_Z_@_M_I_T_-_A_I_._A_R_P_A>
+ R: 250 OK
+ S: RCPT
+ TO:<@USC-ISIE.ARPA,@USC-ISIF.ARPA:_Q_-_S_m_i_t_h_@_I_S_I_-_V_A_X_A_._A_R_P_A>
+ R: 250 OK
+ S: RCPT TO:<@USC-ISIE.ARPA:_j_o_e_@_F_O_O_-_U_N_I_X_._A_R_P_A>
+ R: 250 OK
+ S: RCPT TO:<@USC-ISIE.ARPA:_x_y_z_@_B_A_R_-_U_N_I_X_._A_R_P_A>
+ R: 250 OK
+ S: RCPT TO:<@USC-ISIE.ARPA:_f_r_e_d_@_B_B_N_-_U_N_I_X_._A_R_P_A>
+ R: 250 OK
+
+ S: DATA
+ R: 354 Start mail input; end with <CRLF>.<CRLF>
+ S: Blah blah blah...
+ S: ...etc. etc. etc.
+ S: .
+ R: 250 OK
+
+ S: QUIT
+ R: 221 USC-ISIE.ARPA Service closing transmission channel
+
+ Scenario 7
+
+ -------------------------------------------------------------
+
+_R_F_C_ _8_2_1 August 1982
+ Simple Mail Transfer Protocol
+
+ Forwarding Scenarios
+
+ -------------------------------------------------------------
+
+ R: 220 USC-ISIF.ARPA Simple Mail Transfer Service Ready
+ S: HELO LBL-UNIX.ARPA
+ R: 250 USC-ISIF.ARPA
+
+ S: MAIL FROM:<_m_o_@_L_B_L_-_U_N_I_X_._A_R_P_A>
+ R: 250 OK
+
+ S: RCPT TO:<_f_r_e_d_@_U_S_C_-_I_S_I_F_._A_R_P_A>
+ R: 251 User not local; will forward to <_J_o_n_e_s_@_U_S_C_-_I_S_I_._A_R_P_A>
+
+ S: DATA
+ R: 354 Start mail input; end with <CRLF>.<CRLF>
+ S: Blah blah blah...
+ S: ...etc. etc. etc.
+ S: .
+ R: 250 OK
+
+ S: QUIT
+ R: 221 USC-ISIF.ARPA Service closing transmission channel
+
+ Scenario 8
+
+ -------------------------------------------------------------
+
+August 1982 _R_F_C_ _8_2_1
+Simple Mail Transfer Protocol
+
+ -------------------------------------------------------------
+
+ Step 1 -- Trying the Mailbox at the First Host
+
+ R: 220 USC-ISIF.ARPA Simple Mail Transfer Service Ready
+ S: HELO LBL-UNIX.ARPA
+ R: 250 USC-ISIF.ARPA
+
+ S: MAIL FROM:<_m_o_@_L_B_L_-_U_N_I_X_._A_R_P_A>
+ R: 250 OK
+
+ S: RCPT TO:<_f_r_e_d_@_U_S_C_-_I_S_I_F_._A_R_P_A>
+ R: 251 User not local; will forward to <_J_o_n_e_s_@_U_S_C_-_I_S_I_._A_R_P_A>
+
+ S: RSET
+ R: 250 OK
+
+ S: QUIT
+ R: 221 USC-ISIF.ARPA Service closing transmission channel
+
+ Step 2 -- Delivering the Mail at the Second Host
+
+ R: 220 USC-ISI.ARPA Simple Mail Transfer Service Ready
+ S: HELO LBL-UNIX.ARPA
+ R: 250 USC-ISI.ARPA
+
+ S: MAIL FROM:<_m_o_@_L_B_L_-_U_N_I_X_._A_R_P_A>
+ R: 250 OK
+
+ S: RCPT TO:<_J_o_n_e_s_@_U_S_C_-_I_S_I_._A_R_P_A>
+ R: OK
+
+ S: DATA
+ R: 354 Start mail input; end with <CRLF>.<CRLF>
+ S: Blah blah blah...
+ S: ...etc. etc. etc.
+ S: .
+ R: 250 OK
+
+ S: QUIT
+ R: 221 USC-ISI.ARPA Service closing transmission channel
+
+ Scenario 9
+
+ -------------------------------------------------------------
+
+_R_F_C_ _8_2_1 August 1982
+ Simple Mail Transfer Protocol
+
+ Too Many Recipients Scenario
+
+ -------------------------------------------------------------
+
+ R: 220 BERKELEY.ARPA Simple Mail Transfer Service Ready
+ S: HELO USC-ISIF.ARPA
+ R: 250 BERKELEY.ARPA
+
+ S: MAIL FROM:<_P_o_s_t_e_l_@_U_S_C_-_I_S_I_F_._A_R_P_A>
+ R: 250 OK
+
+ S: RCPT TO:<_f_a_b_r_y_@_B_E_R_K_E_L_E_Y_._A_R_P_A>
+ R: 250 OK
+
+ S: RCPT TO:<_e_r_i_c_@_B_E_R_K_E_L_E_Y_._A_R_P_A>
+ R: 552 Recipient storage full, try again in another transaction
+
+ S: DATA
+ R: 354 Start mail input; end with <CRLF>.<CRLF>
+ S: Blah blah blah...
+ S: ...etc. etc. etc.
+ S: .
+ R: 250 OK
+
+ S: MAIL FROM:<_P_o_s_t_e_l_@_U_S_C_-_I_S_I_F_._A_R_P_A>
+ R: 250 OK
+
+ S: RCPT TO:<_e_r_i_c_@_B_E_R_K_E_L_E_Y_._A_R_P_A>
+ R: 250 OK
+
+ S: DATA
+ R: 354 Start mail input; end with <CRLF>.<CRLF>
+ S: Blah blah blah...
+ S: ...etc. etc. etc.
+ S: .
+ R: 250 OK
+
+ S: QUIT
+ R: 221 BERKELEY.ARPA Service closing transmission channel
+
+ Scenario 10
+
+ -------------------------------------------------------------
+
+ Note that a real implementation must handle many recipients as
+ specified in Section 4.5.3.
+
+August 1982 _R_F_C_ _8_2_1
+Simple Mail Transfer Protocol
+
+GLOSSARY
+
+ ASCII
+
+ American Standard Code for Information Interchange [1].
+
+ command
+
+ A request for a mail service action sent by the sender-SMTP to the
+ receiver-SMTP.
+
+ domain
+
+ The hierarchially structured global character string address of a
+ host computer in the mail system.
+
+ end of mail data indication
+
+ A special sequence of characters that indicates the end of the
+ mail data. In particular, the five characters carriage return,
+ line feed, period, carriage return, line feed, in that order.
+
+ host
+
+ A computer in the internetwork environment on which mailboxes or
+ SMTP processes reside.
+
+ line
+
+ A a sequence of ASCII characters ending with a <CRLF>.
+
+ mail data
+
+ A sequence of ASCII characters of arbitrary length, which conforms
+ to the standard set in the Standard for the Format of ARPA
+ Internet Text Messages (_R_F_C_ _8_2_2 [2]).
+
+ mailbox
+
+ A character string (address) which identifies a user to whom mail
+ is to be sent. Mailbox normally consists of the host and user
+ specifications. The standard mailbox naming convention is defined
+ to be "user@domain". Additionally, the "container" in which mail
+ is stored.
+
+_R_F_C_ _8_2_1 August 1982
+ Simple Mail Transfer Protocol
+
+ receiver-SMTP process
+
+ A process which transfers mail in cooperation with a sender-SMTP
+ process. It waits for a connection to be established via the
+ transport service. It receives SMTP commands from the
+ sender-SMTP, sends replies, and performs the specified operations.
+
+ reply
+
+ A reply is an acknowledgment (positive or negative) sent from
+ receiver to sender via the transmission channel in response to a
+ command. The general form of a reply is a completion code
+ (including error codes) followed by a text string. The codes are
+ for use by programs and the text is usually intended for human
+ users.
+
+ sender-SMTP process
+
+ A process which transfers mail in cooperation with a receiver-SMTP
+ process. A local language may be used in the user interface
+ command/reply dialogue. The sender-SMTP initiates the transport
+ service connection. It initiates SMTP commands, receives replies,
+ and governs the transfer of mail.
+
+ session
+
+ The set of exchanges that occur while the transmission channel is
+ open.
+
+ transaction
+
+ The set of exchanges required for one message to be transmitted
+ for one or more recipients.
+
+ transmission channel
+
+ A full-duplex communication path between a sender-SMTP and a
+ receiver-SMTP for the exchange of commands, replies, and mail
+ text.
+
+ transport service
+
+ Any reliable stream-oriented data communication services. For
+ example, NCP, TCP, NITS.
+
+August 1982 _R_F_C_ _8_2_1
+Simple Mail Transfer Protocol
+
+ user
+
+ A human being (or a process on behalf of a human being) wishing to
+ obtain mail transfer service. In addition, a recipient of
+ computer mail.
+
+ word
+
+ A sequence of printing characters.
+
+ <CRLF>
+
+ The characters carriage return and line feed (in that order).
+
+ <SP>
+
+ The space character.
+
+_R_F_C_ _8_2_1 August 1982
+ Simple Mail Transfer Protocol
+
+REFERENCES
+
+ [1] ASCII
+
+ ASCII, "USA Code for Information Interchange", United States of
+ America Standards Institute, X3.4, 1968. Also in: Feinler, E.
+ and J. Postel, eds., "ARPANET Protocol Handbook", NIC 7104, for
+ the Defense Communications Agency by SRI International, Menlo
+ Park, California, Revised January 1978.
+
+ [2] _R_F_C_ _8_2_2
+
+ Crocker, D., "Standard for the Format of ARPA Internet Text
+ Messages," _R_F_C_ _8_2_2, Department of Electrical Engineering,
+ University of Delaware, August 1982.
+
+ [3] TCP
+
+ Postel, J., ed., "Transmission Control Protocol - DARPA Internet
+ Program Protocol Specification", _R_F_C_ _7_9_3, USC/Information Sciences
+ Institute, NTIS AD Number A111091, September 1981. Also in:
+ Feinler, E. and J. Postel, eds., "Internet Protocol Transition
+ Workbook", SRI International, Menlo Park, California, March 1982.
+
+ [4] NCP
+
+ McKenzie,A., "Host/Host Protocol for the ARPA Network", NIC 8246,
+ January 1972. Also in: Feinler, E. and J. Postel, eds., "ARPANET
+ Protocol Handbook", NIC 7104, for the Defense Communications
+ Agency by SRI International, Menlo Park, California, Revised
+ January 1978.
+
+ [5] Initial Connection Protocol
+
+ Postel, J., "Official Initial Connection Protocol", NIC 7101,
+ 11 June 1971. Also in: Feinler, E. and J. Postel, eds., "ARPANET
+ Protocol Handbook", NIC 7104, for the Defense Communications
+ Agency by SRI International, Menlo Park, California, Revised
+ January 1978.
+
+ [6] NITS
+
+ PSS/SG3, "A Network Independent Transport Service", Study Group 3,
+ The Post Office PSS Users Group, February 1980. Available from
+ the DCPU, National Physical Laboratory, Teddington, UK.
+
+August 1982 _R_F_C_ _8_2_1
+Simple Mail Transfer Protocol
+
+ [7] X.25
+
+ CCITT, "Recommendation X.25 - Interface Between Data Terminal
+ Equipment (DTE) and Data Circuit-terminating Equipment (DCE) for
+ Terminals Operating in the Packet Mode on Public Data Networks,"
+ CCITT Orange Book, Vol. VIII.2, International Telephone and
+ Telegraph Consultative Committee, Geneva, 1976.
+
+Comments about this RFC:
+ * _R_F_C_ _8_2_1_:_ _w_h_e_r_e_ _i_ _c_a_n_ _w_r_i_t_e_ _m_y_ _s_c_r_i_p_t_s by mahmood (1/31/2004)
+ * _R_F_C_ _8_2_1_:_ _A_ _r_o_n_a_l_d_ _r_ _d_a_v_i_s_ _o_n_ _p_a_r_o_l_e_ _h_a_s_ _h_a_c_k_e_d_ _i_n_t_o_ _m_y_ _a_c_c_o_u_n_t_._ _h_e_ _i_s_ _n_o_t
+ _s_u_p_p_o_s_s_e_d_ _t_o_._._. by lifeisunfair (12/20/2006)
+ * _R_F_C_ _8_2_1_:_ _I_ _a_m_ _u_n_a_b_l_e_ _t_o_ _s_e_n_d_ _o_u_t_ _e_-_m_a_i_l_s_._T_h_e_ _e_r_r_o_r_ _m_e_s_s_a_g_e_ _s_a_y_s_:_ _T_h_e
+ _m_e_s_s_a_g_e_ _c_o_u_l_d_ _n_o_t_ _b_e_._._. by nita (11/5/2004)
+ * _R_F_C_ _8_2_1_:_ _H_o_w_ _c_a_n_ _I_ _c_r_e_a_t_e_ _a_ _s_c_r_i_p_t_ _d_o_ _r_u_n_ _o_n_ _W_i_n_d_o_w_s_ _?_ _?_ _?_ _I_'_d_ _l_i_k_e_ _t_o
+ _u_s_e_ _a_ _s_c_r_i_p_t_._._. by Marcelo (11/8/2004)
+ * _R_F_C_ _8_2_1_:_ _h_o_w_ _s_m_t_p_ _w_o_r_k_s_ _i_n_ _e_x_c_h_a_n_g_e_ _s_y_t_e_m_? by saif (12/4/2005)
+ * _R_F_C_ _8_2_1_:_ _V_e_r_y_ _G_o_o_d_ _B_u_t_ _I_ _W_a_n_t_ _C_o_d_i_n_g_ _o_f_ _S_i_m_l_e_ _M_a_i_l_ _t_r_a_n_s_f_e_r_ _p_r_o_t_o_c_o_l by
+ Ankit Pahuja (3/23/2006)
+ * _R_F_C_ _8_2_1_:_ _T_h_i_s_ _R_F_C_ _i_s_ _o_b_s_o_l_e_t_e_d_ _b_y_ _R_F_C_2_8_2_1_._ _A_n_y_o_n_e_ _s_e_e_k_i_n_g_ _t_o_ _u_n_d_e_r_s_t_a_n_d
+ _m_o_d_e_r_n_ _S_M_T_P_ _o_r_._._. by William Cole (4/23/2005)
+ * _R_F_C_ _8_2_1_:_ _C_a_n_ _I_ _a_t_t_a_c_h_ _a_ _f_i_l_e_ _t_o_ _a_n_ _o_u_t_g_o_i_n_g_ _e_-_m_a_i_l_ _o_n_ _t_h_e_ _m_a_i_n_f_r_a_m_e_? by
+ dphill06 (5/23/2006)
+ * _R_F_C_ _8_2_1_:_ _I_ _w_a_n_t_ _t_o_ _g_e_t_ _t_h_e_ _i_n_f_o_r_m_a_t_i_o_n_ _o_f_ _u_t_l___s_m_t_p by eagle_hawk (6/2/
+ 2005)
+ * _R_F_C_ _8_2_1_:_ _I_ _a_m_ _a_ _M_A_C_ _u_s_e_r_ _w_h_o_ _w_a_s_ _p_r_o_v_i_d_e_d_ _a_n_ _s_m_p_t_ _c_a_p_a_b_i_l_i_t_y_ _w_h_i_c_h_ _I_ _c_a_n
+ _n_o_t_ _u_s_e_ _f_o_r_ _l_a_c_k_._._. by Larry Stolurow (6/22/2006)
+ * _R_F_C_ _8_2_1_:_ _A_l_w_a_y_s_ _a_ _g_o_o_d_ _r_e_a_d_!_I_ _i_m_p_l_e_m_e_n_t_ _S_M_T_P_ _o_v_e_r_ _V_B_6_ _W_i_n_s_o_c_k_._ _W_o_r_k_s
+ _g_r_e_a_t_,_ _r_e_f_e_r_ _t_o_._._. by python_kiss (11/3/2005)
+ * _R_F_C_ _8_2_1_:_ _v_e_r_y_ _s_i_m_p_l_e_ _t_o_ _c_o_n_f_i_g_u_r_e by dixson (3/26/2007)
+ * _R_F_C_ _8_2_1_:_ _R_F_C_ _8_2_1_ _d_o_e_s_ _n_o_t_ _c_o_m_m_e_n_t_ _o_n_ _t_h_e_ _v_a_l_i_d_i_t_y_ _o_f_ _t_r_a_i_l_i_n_g_ _d_o_t_s_ _f_o_r
+ _d_o_m_a_i_n_ _n_a_m_e_s_._ _I_t_._._. by Brett (12/22/2004)
+ * _R_F_C_ _8_2_1_:_ _W_h_a_t_ _i_s_ _R_F_C_ _f_o_r_m_a_t_?_H_o_ _i_t_ _i_s_ _u_s_e_d_? by siva (3/2/2004)
+ * _R_F_C_ _8_2_1_:_ _s_i_r_,_w_e_ _a_r_e_ _d_o_i_n_g_ _p_r_o_j_e_c_t_ _o_n_ _S_M_S_ _f_r_o_m_ _m_o_b_i_l_e_ _t_o_ _i_n_t_e_r_n_e_t_._S_o_ _f_o_r
+ _c_o_m_m_u_n_i_c_a_t_i_n_g_w_i_t_h_._._. by Krishna (5/9/2004)
+ * _R_F_C_ _8_2_1_:_ _H_i_!_ _V_e_r_y_ _n_i_c_e_ _s_i_t_e_!_ _T_h_a_n_k_s_ _y_o_u_ _v_e_r_y_ _m_u_c_h_!_ _m_8_8_C_X_f_G_F_N_X_H_O_k_S by
+ rzq9PUrVNv (1/21/2007)
+ * _R_F_C_ _8_2_1_:_ _i_ _n_e_e_t_ _s_l_e_e_p_ _p_f_f_f_f_f_f_ _w_a_t_ _i_ _n_e_e_ _t_e_ _d_o_e by goldface (9/24/2005)
+
+Previous: _R_F_C_ _0_8_2_0_ _-_ _A_s_s_i_g_n_e_d_ _n_u_m_b_e_r_s Next: _R_F_C_ _0_8_2_2_ _-_ _S_T_A_N_D_A_R_D_ _F_O_R_ _T_H_E
+ _F_O_R_M_A_T_ _O_F_ _A_R_P_A_ _I_N_T_E_R_N_E_T_ _T_E_X_T_ _M_E_S_S_A_G_E_S
+
+===============================================================================
+ [ _R_F_C_ _I_n_d_e_x | _R_F_C_ _S_e_a_r_c_h | _U_s_e_n_e_t_ _F_A_Q_s | _W_e_b_ _F_A_Q_s | _D_o_c_u_m_e_n_t_s | _C_i_t_i_e_s ]
+© 2008 FAQS.ORG. All rights reserved.
+
diff --git a/src/Makefile b/src/Makefile
@@ -0,0 +1,10 @@
+all:
+# gcc muxin.c -o muxin
+ gcc -Wall pop3.c -o dmc-pop3
+ gcc -Wall imap4.c -o dmc-imap4
+
+clean:
+ rm -f dmc-pop3 dmc-imap4
+
+loc:
+ sloccount .
diff --git a/src/dmc b/src/dmc
@@ -0,0 +1,10 @@
+#!/bin/sh
+#
+# Dynamic Mail Client
+#
+
+FIFO=fifo-session
+./dmc-pop3 $FIFO | nc localhost 110 | ./dmc-pop3 > $FIFO
+
+./dmc-pop3 | nc localhost 110 | ./dmc-pop3-post
+./dmc-imap4 | openssl s_client -host radare.org -port 993 | ./dmc-imap4
diff --git a/src/imap4.c b/src/imap4.c
@@ -0,0 +1,107 @@
+/* dmc :: Copyleft -- pancake (at) nopcode (dot) org */
+
+#include <stdio.h>
+#include <string.h>
+#include <stdlib.h>
+
+static char word[1024];
+static int ctr = 1;
+
+static char *getword() {
+ fscanf(stdin, "%127s", word);
+ if (feof(stdin))
+ *word = '\0';
+ return word;
+}
+
+static int waitreply() {
+ char *str;
+ int ret = -1;
+ fgets(word, sizeof(word), stdin);
+ if (atoi(word) != ctr-1)
+ fprintf(stderr, "Invalid sequence number received\n");
+ if ( (str = strchr(word, ' ')) ) {
+ if (!memcmp(str+1, "OK", 3))
+ ret = 1;
+ else if (!memcmp(str+1, "NO", 4))
+ ret = 0;
+ }
+ return ret; // 1 if true, 0 if false
+}
+
+#if 0
+LIST - list all folders
+LSUB - list all subscribed folders
+SUBSCRIBE - subcribe a folder
+CHECK - ???
+CLOSE - commit the delete stuff (maybe must be done after rm)
+EXPUNGE - permanent remove of deltec
+SEARCH - ...
+RECENT - show the number of recent messages
+#endif
+static int doword(char *word) {
+ int ret = 1;
+ if (*word == '\0' || !strcmp(word, "exit")) {
+ printf("%d LOGOUT\n", ctr++);
+ waitreply();
+ ret = 0;
+ } else
+ if (!strcmp(word, "help") || !strcmp(word, "?")) {
+ fprintf(stderr, "Use: ls lsdir cat head rm rmdir login exit mvdir\n");
+ } else
+ if (!strcmp(word, "ls")) {
+// TODO:
+ printf("LIST\n");
+ waitreply();
+ } else
+ if (!strcmp(word, "cd")) {
+ printf("%d SELECT %s\n", ctr++, getword());
+ waitreply();
+ } else
+ if (!strcmp(word, "search")) {
+ printf("%d SEARCH TEXT \"%s\"\n", ctr++, getword());
+ waitreply();
+ } else
+ if (!strcmp(word, "lsdir")) {
+ printf("%d LIST \"\" *\n", ctr++);
+ waitreply();
+ } else
+ if (!strcmp(word, "cat")) {
+ printf("%d FETCH %d ALL\n",
+ ctr++, atoi(getword()));
+ waitreply();
+ } else
+ if (!strcmp(word, "head")) {
+ printf("%d FETCH %d body[header]\n",
+ ctr++, atoi(getword()));
+ waitreply();
+ } else
+ if (!strcmp(word, "mvdir")) {
+ printf("%d RENAME %s %s\n",
+ ctr++, getword(), getword());
+ } else
+ if (!strcmp(word, "rm")) {
+// TODO:
+ printf("DELE %d\n", atoi(getword()));
+ waitreply();
+ } else
+ if (!strcmp(word, "rmdir")) {
+ printf("%d DELETE %d\n",
+ ctr++, atoi(getword()));
+ waitreply();
+ } else
+ if (!strcmp(word, "login")) {
+ printf("%d LOGIN %s %s\n",
+ ctr++, getword(), getword());
+ waitreply();
+ } else {
+ printf("%d NOOP\n", ctr++);
+ waitreply();
+ }
+ return ret;
+}
+
+int main() {
+ while(doword(getword()));
+ return 0;
+}
diff --git a/src/pop3.c b/src/pop3.c
@@ -0,0 +1,93 @@
+/* dmc :: Copyleft -- pancake (at) nopcode (dot) org */
+
+#include <stdio.h>
+#include <string.h>
+#include <signal.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <fcntl.h>
+
+
+static char word[1024];
+static char *fifo;
+static int ff;
+
+static char *getword() {
+ fscanf(stdin, "%255s", word);
+ if (feof(stdin))
+ *word = '\0';
+ return word;
+}
+
+static int waitreply() {
+ int ret = -1;
+ fflush(stdout);
+ fgets(word, sizeof(word), stdin);
+ if (!memcmp(word, "+OK", 3))
+ ret = 1;
+ else
+ if (!memcmp(word, "-ERR", 4))
+ ret = 0;
+ return ret; // 1 if true, 0 if false
+}
+
+static int doword(char *word) {
+ int ret = 1;
+ if (*word == '\0' || !strcmp(word, "exit")) {
+ printf("QUIT\n");
+ waitreply();
+ ret = 0;
+ } else
+ if (!strcmp(word, "help") || !strcmp(word, "?")) {
+ fprintf(stderr, "Use: ls cat head rm login exit\n");
+ } else
+ if (!strcmp(word, "ls")) {
+ printf("LIST\n");
+ waitreply();
+ } else
+ if (!strcmp(word, "cat")) {
+ printf("RETR %d\n", atoi(getword()));
+ waitreply();
+ } else
+ if (!strcmp(word, "head")) {
+ printf("TOP %d\n", atoi(getword()));
+ waitreply();
+ } else
+ if (!strcmp(word, "rm")) {
+ printf("DELE %d\n", atoi(getword()));
+ waitreply();
+ } else
+ if (!strcmp(word, "login")) {
+ printf("USER %s\n", getword());
+ printf("PASS %s\n", getword());
+ waitreply();
+ } else printf("NOOP\n");
+ return ret;
+}
+
+static void parseoutput(void) {
+ while(!feof(stdin)) {
+ sleep(1);
+ printf("TODO\n");
+ }
+}
+
+static void cleanup(int foo) {
+ close(ff);
+ unlink(fifo);
+ exit(0);
+}
+
+int main(int argc, char **argv) {
+ if (argc>1) {
+ signal(SIGINT, cleanup);
+ fifo = argv[1];
+ mkfifo(fifo, 0600);
+ ff = open(fifo, O_NONBLOCK|O_RDWR);
+ while(doword(getword()));
+ cleanup(0);
+ } else parseoutput();
+ return 0;
+}
