From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001
From: Thomas Voss <mail@thomasvoss.com>
Date: Wed, 27 Nov 2024 20:54:24 +0100
Subject: doc: Add RFC documents

---
 doc/rfc/rfc1730.txt | 4318 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 4318 insertions(+)
 create mode 100644 doc/rfc/rfc1730.txt

(limited to 'doc/rfc/rfc1730.txt')

diff --git a/doc/rfc/rfc1730.txt b/doc/rfc/rfc1730.txt
new file mode 100644
index 0000000..bf45da5
--- /dev/null
+++ b/doc/rfc/rfc1730.txt
@@ -0,0 +1,4318 @@
+
+
+
+
+
+
+Network Working Group                                         M. Crispin
+Request for Comments: 1730                      University of Washington
+Category: Standards Track                                  December 1994
+
+
+              INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4
+
+
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+
+Abstract
+
+   The Internet Message Access Protocol, Version 4 (IMAP4) allows a
+   client to access and manipulate electronic mail messages on a server.
+   IMAP4 permits manipulation of remote message folders, called
+   "mailboxes", in a way that is functionally equivalent to local
+   mailboxes.  IMAP4 also provides the capability for an offline client
+   to resynchronize with the server (see also [IMAP-DISC]).
+
+   IMAP4 includes operations for creating, deleting, and renaming
+   mailboxes; checking for new messages; permanently removing messages;
+   setting and clearing flags; RFC 822 and MIME parsing; searching; and
+   selective fetching of message attributes, texts, and portions
+   thereof.  Messages in IMAP4 are accessed by the use of numbers.
+   These numbers are either message sequence numbers (relative position
+   from 1 to the number of messages in the mailbox) or unique
+   identifiers (immutable, strictly ascending values assigned to each
+   message, but which are not necessarily contiguous).
+
+   IMAP4 supports a single server.  A mechanism for supporting multiple
+   IMAP4 servers is discussed in [IMSP].
+
+   IMAP4 does not specify a means of posting mail; this function is
+   handled by a mail transfer protocol such as [SMTP].
+
+   IMAP4 is designed to be upwards compatible from the [IMAP2] protocol.
+   Compatibility issues are discussed in [IMAP-COMPAT].
+
+
+
+
+
+
+Crispin                                                         [Page i]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+
+
+
+Table of Contents
+
+
+
+IMAP4 Protocol Specification ......................................    1
+1.      Organization of this Document .............................    1
+1.1.    How to Read This Document .................................    1
+1.2.    Conventions Used in this Document .........................    1
+2.      Protocol Overview .........................................    1
+2.1.    Link Level ................................................    1
+2.2.    Commands and Responses ....................................    1
+2.2.1.  Client Protocol Sender and Server Protocol Receiver .......    2
+2.2.2.  Server Protocol Sender and Client Protocol Receiver .......    2
+3.      State and Flow Diagram ....................................    4
+3.1.    Non-Authenticated State ...................................    4
+3.2.    Authenticated State .......................................    4
+3.3.    Selected State ............................................    4
+3.4.    Logout State ..............................................    4
+4.      Data Formats ..............................................    6
+4.1.    Atom ......................................................    6
+4.2.    Number ....................................................    6
+4.3.    String ....................................................    6
+4.3.1.  8-bit and Binary Strings ..................................    7
+4.4.    Parenthesized List ........................................    7
+4.5.    NIL .......................................................    7
+5.      Operational Considerations ................................    8
+5.1.    Mailbox Naming ............................................    8
+5.2.    Mailbox Size and Message Status Updates ...................    8
+5.3.    Response when no Command in Progress ......................    8
+5.4.    Autologout Timer ..........................................    9
+5.5.    Multiple Commands in Progress .............................    9
+6.      Client Commands ...........................................   10
+6.1.    Client Commands - Any State ...............................   10
+6.1.1.  CAPABILITY Command ........................................   10
+6.1.2.  NOOP Command ..............................................   11
+6.1.3.  LOGOUT Command ............................................   11
+6.2.    Client Commands - Non-Authenticated State .................   12
+6.2.1.  AUTHENTICATE Command ......................................   12
+6.2.2.  LOGIN Command .............................................   14
+6.3.    Client Commands - Authenticated State .....................   14
+6.3.1.  SELECT Command ............................................   15
+6.3.2.  EXAMINE Command ...........................................   16
+6.3.3.  CREATE Command ............................................   17
+6.3.4.  DELETE Command ............................................   18
+6.3.5.  RENAME Command ............................................   18
+
+
+
+Crispin                                                        [Page ii]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+6.3.6.  SUBSCRIBE Command .........................................   19
+6.3.7.  UNSUBSCRIBE Command .......................................   19
+6.3.8.  LIST Command ..............................................   20
+6.3.9.  LSUB Command ..............................................   22
+6.3.10. APPEND Command ............................................   22
+6.4.    Client Commands - Selected State ..........................   23
+6.4.1.  CHECK Command .............................................   23
+6.4.2.  CLOSE Command .............................................   24
+6.4.3.  EXPUNGE Command ...........................................   25
+6.4.4.  SEARCH Command ............................................   25
+6.4.5.  FETCH Command .............................................   29
+6.4.6.  PARTIAL Command ...........................................   32
+6.4.7.  STORE Command .............................................   33
+6.4.8.  COPY Command ..............................................   34
+6.4.9.  UID Command ...............................................   35
+6.5.    Client Commands - Experimental/Expansion ..................   37
+6.5.1.  X<atom> Command ...........................................   37
+7.      Server Responses ..........................................   38
+7.1.    Server Responses - Status Responses .......................   39
+7.1.1.  OK Response ...............................................   40
+7.1.2.  NO Response ...............................................   40
+7.1.3.  BAD Response ..............................................   41
+7.1.4.  PREAUTH Response ..........................................   41
+7.1.5.  BYE Response ..............................................   41
+7.2.    Server Responses - Server and Mailbox Status ..............   42
+7.2.1.  CAPABILITY Response .......................................   42
+7.2.2.  LIST Response .............................................   43
+7.2.3.  LSUB Response .............................................   44
+7.2.4.  SEARCH Response ...........................................   44
+7.2.5.  FLAGS Response ............................................   44
+7.3.    Server Responses - Message Status .........................   45
+7.3.1.  EXISTS Response ...........................................   45
+7.3.2.  RECENT Response ...........................................   45
+7.3.3.  EXPUNGE Response ..........................................   45
+7.3.4.  FETCH Response ............................................   46
+7.3.5.  Obsolete Responses ........................................   51
+7.4.    Server Responses - Command Continuation Request ...........   51
+8.      Sample IMAP4 session ......................................   52
+9.      Formal Syntax .............................................   53
+10.     Author's Note .............................................   64
+11.     Security Considerations ...................................   64
+12.     Author's Address ..........................................   64
+Appendices ........................................................   65
+A.      Obsolete Commands .........................................   65
+A.6.3.OBS.1.    FIND ALL.MAILBOXES Command ........................   65
+A.6.3.OBS.2.    FIND MAILBOXES Command ............................   65
+A.6.3.OBS.3.    SUBSCRIBE MAILBOX Command .........................   66
+A.6.3.OBS.4.    UNSUBSCRIBE MAILBOX Command .......................   66
+
+
+
+Crispin                                                       [Page iii]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+B.      Obsolete Responses ........................................   68
+B.7.2.OBS.1.    MAILBOX Response ..................................   68
+B.7.3.OBS.1.    COPY Response .....................................   68
+B.7.3.OBS.2.    STORE Response ....................................   69
+C.      References ................................................   70
+E.      IMAP4 Keyword Index .......................................   71
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                                                        [Page iv]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+IMAP4 Protocol Specification
+
+1.      Organization of this Document
+
+1.1.    How to Read This Document
+
+   This document is written from the point of view of the implementor of
+   an IMAP4 client or server.  Beyond the protocol overview in section
+   2, it is not optimized for someone trying to understand the operation
+   of the protocol.  The material in sections 3 through 5 provides the
+   general context and definitions with which IMAP4 operates.
+
+   Sections 6, 7, and 9 describe the IMAP commands, responses, and
+   syntax, respectively.  The relationships among these are such that it
+   is almost impossible to understand any of them separately.  In
+   particular, one should not attempt to deduce command syntax from the
+   command section alone; one should instead refer to the formal syntax
+   section.
+
+
+1.2.    Conventions Used in this Document
+
+   In examples, "C:" and "S:" indicate lines sent by the client and
+   server respectively.
+
+
+2.      Protocol Overview
+
+2.1.    Link Level
+
+   The IMAP4 protocol assumes a reliable data stream such as provided by
+   TCP.  When TCP is used, an IMAP4 server listens on port 143.
+
+
+2.2.    Commands and Responses
+
+   An IMAP4 session consists of the establishment of a client/server
+   connection, an initial greeting from the server, and client/server
+   interactions.  These client/server interactions consist of a client
+   command, server data, and a server completion result response.
+
+   All interactions transmitted by client and server are in the form of
+   lines; that is, strings that end with a CRLF.  The protocol receiver
+   of an IMAP4 client or server is either reading a line, or is reading
+   a sequence of octets with a known count followed by a line.
+
+
+
+
+
+
+Crispin                                                         [Page 1]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+2.2.1.  Client Protocol Sender and Server Protocol Receiver
+
+   The client command begins an operation.  Each client command is
+   prefixed with a identifier (typically a short alphanumeric string,
+   e.g. A0001, A0002, etc.) called a "tag".  A different tag is
+   generated by the client for each command.
+
+   There are two cases in which a line from the client does not
+   represent a complete command.  In one case, a command argument is
+   quoted with an octet count (see the description of literal in String
+   under Data Formats); in the other case, the command arguments require
+   server feedback (see the AUTHENTICATE command).  In either case, the
+   server sends a command continuation request response if it is ready
+   for the octets (if appropriate) and the remainder of the command.
+   This response is prefixed with the token "+".
+
+        Note: If, instead, the server detected an error in the
+        command, it sends a BAD completion response with tag
+        matching the command (as described below) to reject the
+        command and prevent the client from sending any more of the
+        command.
+
+        It is also possible for the server to send a completion
+        response for some other command (if multiple commands are
+        in progress), or untagged data.  In either case, the
+        command continuation request is still pending; the client
+        takes the appropriate action for the response, and reads
+        another response from the server.
+
+   The protocol receiver of an IMAP4 server reads a command line from
+   the client, parses the command and its arguments, and transmits
+   server data and a server command completion result response.
+
+
+2.2.2.  Server Protocol Sender and Client Protocol Receiver
+
+   Data transmitted by the server to the client and status responses
+   that do not indicate command completion are prefixed with the token
+   "*", and are called untagged responses.
+
+   Server data may be sent as a result of a client command, or may be
+   sent unilaterally by the server.  There is no syntactic difference
+   between server data that resulted from a specific command and server
+   data that were sent unilaterally.
+
+   The server completion result response indicates the success or
+   failure of the operation.  It is tagged with the same tag as the
+   client command which began the operation.  Thus, if more than one
+
+
+
+Crispin                                                         [Page 2]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+   command is in progress, the tag in a server completion response
+   identifies the command to which the response applies.  There are
+   three possible server completion responses: OK (indicating success),
+   NO (indicating failure), or BAD (indicating protocol error such as
+   unrecognized command or command syntax error).
+
+   The protocol receiver of an IMAP4 client reads a response line from
+   the server.  It then takes action on the response based upon the
+   first token of the response, which may be a tag, a "*", or a "+".  As
+   described above.
+
+   A client MUST be prepared to accept any server response at all times.
+   This includes server data that it may not have requested.  Server
+   data SHOULD be recorded, so that the client can reference its
+   recorded copy rather than sending a command to the server to request
+   the data.  In the case of certain server data, recording the data is
+   mandatory.
+
+   This topic is discussed in greater detail in the Server Responses
+   section.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                                                         [Page 3]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+3.      State and Flow Diagram
+
+   An IMAP4 server is in one of four states.  Most commands are valid in
+   only certain states.  It is a protocol error for the client to
+   attempt a command while the command is in an inappropriate state.  In
+   this case, a server will respond with a BAD or NO (depending upon
+   server implementation) command completion result.
+
+
+3.1.    Non-Authenticated State
+
+   In non-authenticated state, the user must supply authentication
+   credentials before most commands will be permitted.  This state is
+   entered when a connection starts unless the connection has been
+   pre-authenticated.
+
+
+3.2.    Authenticated State
+
+   In authenticated state, the user is authenticated and must select a
+   mailbox to access before commands that affect messages will be
+   permitted.  This state is entered when a pre-authenticated connection
+   starts, when acceptable authentication credentials have been
+   provided, or after an error in selecting a mailbox.
+
+
+3.3.    Selected State
+
+   In selected state, a mailbox has been selected to access.  This state
+   is entered when a mailbox has been successfully selected.
+
+
+3.4.    Logout State
+
+   In logout state, the session is being terminated, and the server will
+   close the connection.  This state can be entered as a result of a
+   client request or by unilateral server decision.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                                                         [Page 4]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+            +--------------------------------------+
+            |initial connection and server greeting|
+            +--------------------------------------+
+                      || (1)       || (2)        || (3)
+                      VV           ||            ||
+            +-----------------+    ||            ||
+            |non-authenticated|    ||            ||
+            +-----------------+    ||            ||
+             || (7)   || (4)       ||            ||
+             ||       VV           VV            ||
+             ||     +----------------+           ||
+             ||     | authenticated  |<=++       ||
+             ||     +----------------+  ||       ||
+             ||       || (7)   || (5)   || (6)   ||
+             ||       ||       VV       ||       ||
+             ||       ||    +--------+  ||       ||
+             ||       ||    |selected|==++       ||
+             ||       ||    +--------+           ||
+             ||       ||       || (7)            ||
+             VV       VV       VV                VV
+            +--------------------------------------+
+            |     logout and close connection      |
+            +--------------------------------------+
+
+         (1) connection without pre-authentication (OK greeting)
+         (2) pre-authenticated connection (PREAUTH greeting)
+         (3) rejected connection (BYE greeting)
+         (4) successful LOGIN or AUTHENTICATE command
+         (5) successful SELECT or EXAMINE command
+         (6) CLOSE command, or failed SELECT or EXAMINE command
+         (7) LOGOUT command, server shutdown, or connection closed
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                                                         [Page 5]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+4.      Data Formats
+
+   IMAP4 uses textual commands and responses.  Data in IMAP4 can be in
+   one of several forms: atom, number, string, parenthesized list, or
+   NIL.
+
+
+4.1.    Atom
+
+   An atom consists of one or more non-special characters.
+
+
+4.2.    Number
+
+   A number consists of one or more digit characters, and represents a
+   numeric value.
+
+
+4.3.    String
+
+   A string is in one of two forms: literal and quoted string.  The
+   literal form is the general form of string.  The quoted string form
+   is an alternative that avoids the overhead of processing a literal at
+   the cost of restrictions of what may be in a quoted string.
+
+   A literal is a sequence of zero or more octets (including CR and LF),
+   prefix-quoted with an octet count in the form of an open brace ("{"),
+   the number of octets, close brace ("}"), and CRLF.  In the case of
+   literals transmitted from server to client, the CRLF is immediately
+   followed by the octet data.  In the case of literals transmitted from
+   client to server, the client must wait to receive a command
+   continuation request (described later in this document) before
+   sending the octet data (and the remainder of the command).
+
+   A quoted string is a sequence of zero or more 7-bit characters,
+   excluding CR and LF, with double quote (<">) characters at each end.
+
+   The empty string is respresented as either "" (a quoted string with
+   zero characters between double quotes) or as {0} followed by CRLF (a
+   literal with an octet count of 0).
+
+        Note: Even if the octet count is 0, a client transmitting a
+        literal must wait to receive a command continuation
+        request.
+
+
+
+
+
+
+
+Crispin                                                         [Page 6]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+4.3.1.  8-bit and Binary Strings
+
+   8-bit textual and binary mail is supported through the use of
+   [MIME-1] encoding.  IMAP4 implementations MAY transmit 8-bit or
+   multi-octet characters in literals, but should do so only when the
+   character set is identified.
+
+   Although a BINARY body encoding is defined, unencoded binary strings
+   are not permitted.  A "binary string" is any string with NUL
+   characters.  Implementations MUST encode binary data into a textual
+   form such as BASE64 before transmitting the data.  A string with an
+   excessive amount of CTL characters may also be considered to be
+   binary, although this is not required.
+
+
+4.4.    Parenthesized List
+
+   Data structures are represented as a "parenthesized list"; a sequence
+   of data items, delimited by space, and bounded at each end by
+   parentheses.  A parenthesized list may itself contain other
+   parenthesized lists, using multiple levels of parentheses to indicate
+   nesting.
+
+   The empty list is represented as () -- a parenthesized list with no
+   members.
+
+
+4.5.    NIL
+
+   The special atom "NIL" represents the non-existence of a particular
+   data item that is represented as a string or parenthesized list, as
+   distinct from the empty string "" or the empty parenthesized list ().
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                                                         [Page 7]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+5.      Operational Considerations
+
+5.1.    Mailbox Naming
+
+   The interpretation of mailbox names is implementation-dependent.
+   However, the mailbox name INBOX is a special name reserved to mean
+   "the primary mailbox for this user on this server".  If it is desired
+   to export hierarchical mailbox names, mailbox names must be
+   left-to-right hierarchical using a single character to separate
+   levels of hierarchy.  The same hierarchy separator character is used
+   for all levels of hierarchy within a single name.
+
+5.2.    Mailbox Size and Message Status Updates
+
+   At any time, a server can send data that the client did not request.
+   Sometimes, such behavior is required.  For example, agents other than
+   the server may add messages to the mailbox (e.g. new mail delivery),
+   change the flags of message in the mailbox (e.g. simultaneous access
+   to the same mailbox by multiple agents), or even remove messages from
+   the mailbox.  A server MUST send mailbox size updates automatically
+   if a mailbox size change is observed during the processing of a
+   command.  A server SHOULD send message flag updates automatically,
+   without requiring the client to request such updates explicitly.
+   Special rules exist for server notification of a client about the
+   removal of messages to prevent synchronization errors; see the
+   description of the EXPUNGE response for more details.
+
+   Regardless of what implementation decisions a client may take on
+   remembering data from the server, a client implementation MUST record
+   mailbox size updates.  It MUST NOT assume that any command after
+   initial mailbox selection will return the size of the mailbox.
+
+
+5.3.    Response when no Command in Progress
+
+   Server implementations are permitted to send an untagged response
+   (except for EXPUNGE) while there is no command in progress.  Server
+   implementations that send such responses MUST deal with flow control
+   considerations.  Specifically, they must either (1) verify that the
+   size of the data does not exceed the underlying transport's available
+   window size, or (2) use non-blocking writes.
+
+
+
+
+
+
+
+
+
+
+Crispin                                                         [Page 8]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+5.4.    Autologout Timer
+
+   If a server has an inactivity autologout timer, that timer MUST be of
+   at least 30 minutes' duration.  The receipt of ANY command from the
+   client during that interval should suffice to reset the autologout
+   timer.
+
+
+5.5.    Multiple Commands in Progress
+
+   The client is not required to wait for the completion result response
+   of a command before sending another command, subject to flow control
+   constraints on the underlying data stream.  Similarly, a server is
+   not required to process a command to completion before beginning
+   processing of the next command, unless an ambiguity would result
+   because of a command that would affect the results of other commands.
+   If there is such an ambiguity, the server executes commands to
+   completion in the order given by the client.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                                                         [Page 9]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+6.      Client Commands
+
+   IMAP4 commands are described in this section.  Commands are organized
+   by the state in which the command is permitted.  Commands which are
+   permitted in multiple states are listed in the minimum permitted
+   state (for example, commands valid in authenticated and selected
+   state are listed in the authenticated state commands).
+
+   Command arguments, identified by "Arguments:" in the command
+   descriptions below, are described by function, not by syntax.  The
+   precise syntax of command arguments is described in the Formal Syntax
+   section.
+
+   Some commands cause specific server data to be returned; these are
+   identified by "Data:" in the command descriptions below.  See the
+   response descriptions in the Responses section for information on
+   these responses, and the Formal Syntax section for the precise syntax
+   of these responses.  It is possible for server data to be transmitted
+   as a result of any command; thus, commands that do not specifically
+   require server data specify "no specific data for this command"
+   instead of "none".
+
+   The "Result:" in the command description refers to the possible
+   tagged status responses to a command, and any special interpretation
+   of these status responses.
+
+
+6.1.    Client Commands - Any State
+
+   The following commands are valid in any state: CAPABILITY, NOOP, and
+   LOGOUT.
+
+6.1.1.  CAPABILITY Command
+
+   Arguments:  none
+
+   Data:       mandatory untagged response: CAPABILITY
+
+   Result:     OK - capability completed
+               BAD - command unknown or arguments invalid
+
+      The CAPABILITY command requests a listing of capabilities that the
+      server supports.  The server MUST send a single untagged
+      CAPABILITY response with "IMAP4" as the first listed capability
+      before the (tagged) OK response.  This listing of capabilities is
+      not dependent upon connection state or user.  It is therefore not
+      necessary to issue a CAPABILITY command more than once in a
+      session.
+
+
+
+Crispin                                                        [Page 10]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+      Capability names other than "IMAP4" refer to extensions,
+      revisions, or amendments to this specification.  See the
+      documentation of the CAPABILITY response for additional
+      information.  No capabilities are enabled without explicit client
+      action to invoke the capability.  See the section entitled "Client
+      Commands - Experimental/Expansion" for information about the form
+      of site or implementation-specific capabilities.
+
+   Example:    C: abcd CAPABILITY
+               S: * CAPABILITY IMAP4
+               S: abcd OK CAPABILITY completed
+
+
+6.1.2.  NOOP Command
+
+   Arguments:  none
+
+   Data:       no specific data for this command (but see below)
+
+   Result:     OK - noop completed
+               BAD - command unknown or arguments invalid
+
+      The NOOP command always succeeds.  It does nothing.
+
+      Since any command can return a status update as untagged data, the
+      NOOP command can be used as a periodic poll for new messages or
+      message status updates during a period of inactivity.  The NOOP
+      command can also be used to reset any inactivity autologout timer
+      on the server.
+
+   Example:    C: a002 NOOP
+               S: a002 OK NOOP completed
+                  . . .
+               C: a047 NOOP
+               S: * 22 EXPUNGE
+               S: * 23 EXISTS
+               S: * 3 RECENT
+               S: * 14 FETCH (FLAGS (\Seen \Deleted))
+               S: a047 OK NOOP completed
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                                                        [Page 11]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+6.1.3.  LOGOUT Command
+
+   Arguments:  none
+
+   Data:       mandatory untagged response: BYE
+
+   Result:     OK - logout completed
+               BAD - command unknown or arguments invalid
+
+      The LOGOUT command informs the server that the client is done with
+      the session.  The server must send a BYE untagged response before
+      the (tagged) OK response, and then close the network connection.
+
+   Example:    C: A023 LOGOUT
+               S: * BYE IMAP4 Server logging out
+               S: A023 OK LOGOUT completed
+               (Server and client then close the connection)
+
+
+
+6.2.    Client Commands - Non-Authenticated State
+
+   In non-authenticated state, the AUTHENTICATE or LOGIN command
+   establishes authentication and enter authenticated state.  The
+   AUTHENTICATE command provides a general mechanism for a variety of
+   authentication techniques, whereas the LOGIN command uses the
+   traditional user name and plaintext password pair.
+
+   Server implementations may allow non-authenticated access to certain
+   mailboxes.  The convention is to use a LOGIN command with the userid
+   "anonymous".  A password is required.  It is implementation-dependent
+   what requirements, if any, are placed on the password and what access
+   restrictions are placed on anonymous users.
+
+   Once authenticated (including as anonymous), it is not possible to
+   re-enter non-authenticated state.
+
+   In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
+   the following commands are valid in non-authenticated state:
+   AUTHENTICATE and LOGIN.
+
+
+
+
+
+
+
+
+
+
+
+Crispin                                                        [Page 12]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+6.2.1.  AUTHENTICATE Command
+
+   Arguments:  authentication mechanism name
+
+   Data:       continuation data may be requested
+
+   Result:     OK - authenticate completed, now in authenticated state
+               NO - authenticate failure: unsupported authentication
+                    mechanism, credentials rejected
+               BAD - command unknown or arguments invalid,
+                    authentication exchange cancelled
+
+      The AUTHENTICATE command indicates an authentication mechanism,
+      such as described in [IMAP-AUTH], to the server.  If the server
+      supports the requested authentication mechanism, it performs an
+      authentication protocol exchange to authenticate and identify the
+      user.  Optionally, it also negotiates a protection mechanism for
+      subsequent protocol interactions.  If the requested authentication
+      mechanism is not supported, the server should reject the
+      AUTHENTICATE command by sending a tagged NO response.
+
+      The authentication protocol exchange consists of a series of
+      server challenges and client answers that are specific to the
+      authentication mechanism.  A server challenge consists of a
+      command continuation request response with the "+" token followed
+      by a BASE64 encoded string.  The client answer consists of a line
+      consisting of a BASE64 encoded string.  If the client wishes to
+      cancel an authentication exchange, it should issue a line with a
+      single "*".  If the server receives such an answer, it must reject
+      the AUTHENTICATE command by sending a tagged BAD response.
+
+      A protection mechanism provides integrity and privacy protection
+      to the protocol session.  If a protection mechanism is negotiated,
+      it is applied to all subsequent data sent over the connection.
+      The protection mechanism takes effect immediately following the
+      CRLF that concludes the authentication exchange for the client,
+      and the CRLF of the tagged OK response for the server.  Once the
+      protection mechanism is in effect, the stream of command and
+      response octets is processed into buffers of ciphertext.  Each
+      buffer is transferred over the connection as a stream of octets
+      prepended with a four octet field in network byte order that
+      represents the length of the following data.  The maximum
+      ciphertext buffer length is defined by the protection mechanism.
+
+      The server is not required to support any particular
+      authentication mechanism, nor are authentication mechanisms
+      required to support any protection mechanisms.  If an AUTHENTICATE
+      command fails with a NO response, the client may try another
+
+
+
+Crispin                                                        [Page 13]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+      authentication mechanism by issuing another AUTHENTICATE command,
+      or may attempt to authenticate by using the LOGIN command.  In
+      other words, the client may request authentication types in
+      decreasing order of preference, with the LOGIN command as a last
+      resort.
+
+   Example:    S: * OK KerberosV4 IMAP4 Server
+               C: A001 AUTHENTICATE KERBEROS_V4
+               S: + AmFYig==
+               C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
+                  +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
+                  WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
+               S: + or//EoAADZI=
+               C: DiAF5A4gA+oOIALuBkAAmw==
+               S: A001 OK Kerberos V4 authentication successful
+
+        Note: the line breaks in the first client answer are for
+        editorial clarity and are not in real authenticators.
+
+
+6.2.2.  LOGIN Command
+
+   Arguments:  user name
+               password
+
+   Data:       no specific data for this command
+
+   Result:     OK - login completed, now in authenticated state
+               NO - login failure: user name or password rejected
+               BAD - command unknown or arguments invalid
+
+      The LOGIN command identifies the user to the server and carries
+      the plaintext password authenticating this user.
+
+   Example:    C: a001 LOGIN SMITH SESAME
+               S: a001 OK LOGIN completed
+
+
+
+6.3.    Client Commands - Authenticated State
+
+   In authenticated state, commands that manipulate mailboxes as atomic
+   entities are permitted.  Of these commands, the SELECT and EXAMINE
+   commands will select a mailbox for access and enter selected state.
+
+
+
+
+
+
+
+Crispin                                                        [Page 14]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+   In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
+   the following commands are valid in authenticated state: SELECT,
+   EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB,
+   and APPEND.
+
+6.3.1.  SELECT Command
+
+   Arguments:  mailbox name
+
+   Data:       mandatory untagged responses: FLAGS, EXISTS, RECENT
+               optional OK untagged responses: UNSEEN, PERMANENTFLAGS
+
+   Result:     OK - select completed, now in selected state
+               NO - select failure, now in authenticated state: no
+                    such mailbox, can't access mailbox
+               BAD - command unknown or arguments invalid
+
+      The SELECT command selects a  mailbox  so  that  messages  in  the
+      mailbox  can  be  accessed.  Before returning an OK to the client,
+      the server MUST send the following untagged data to the client:
+
+         FLAGS       Defined flags in the mailbox
+
+         <n> EXISTS  The number of messages in the mailbox
+
+         <n> RECENT  The number of messages added to the  mailbox  since
+                     the previous time this mailbox was read
+
+         OK [UIDVALIDITY <n>]
+                     The unique  identifier  validity  value.   See  the
+                     description of the UID command for more detail.
+
+      to define the initial state of the mailbox at the client.  If it
+      is not possible to determine the messages that were added since
+      the previous time a mailbox was read, then all messages SHOULD be
+      considered recent.
+
+      The server SHOULD also send an UNSEEN response code in an OK
+      untagged response, indicating the message sequence number of the
+      first unseen message in the mailbox.
+
+      If the client can not change the permanent state of one or more of
+      the flags listed in the FLAGS untagged response, the server SHOULD
+      send a PERMANENTFLAGS response code in an OK untagged response,
+      listing the flags that the client may change permanently.
+
+      Only one mailbox may be selected at a time in a session;
+      simultaneous access to multiple mailboxes requires multiple
+
+
+
+Crispin                                                        [Page 15]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+      sessions.  The SELECT command automatically deselects any
+      currently selected mailbox before attempting the new selection.
+      Consequently, if a mailbox is selected and a SELECT command that
+      fails is attempted, no mailbox is selected.
+
+      If the user is permitted to modify the mailbox, the server SHOULD
+      prefix the text of the tagged OK response with the "[READ-WRITE]"
+      response code.
+
+      If the user is not permitted to modify the mailbox but is
+      permitted read access, the mailbox is selected as read-only, and
+      the server MUST prefix the text of the tagged OK response to
+      SELECT with the "[READ-ONLY]" response code.  Read-only access
+      through SELECT differs from the EXAMINE command in that certain
+      read-only mailboxes may permit the change of permanent state on a
+      per-user (as opposed to global) basis.  Netnews messages marked in
+      a user's .newsrc file are an example of such per-user permanent
+      state that can be modified with read-only mailboxes.
+
+   Example:    C: A142 SELECT INBOX
+               S: * 172 EXISTS
+               S: * 1 RECENT
+               S: * OK [UNSEEN 12] Message 12 is first unseen
+               S: * OK [UIDVALIDITY 3857529045] UIDs valid
+               S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
+               S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
+               S: A142 OK [READ-WRITE] SELECT completed
+
+
+6.3.2.  EXAMINE Command
+
+   Arguments:  mailbox name
+
+   Data:       mandatory untagged responses: FLAGS, EXISTS, RECENT
+               optional OK untagged responses: UNSEEN, PERMANENTFLAGS
+
+   Result:     OK - examine completed, now in selected state
+               NO - examine failure, now in authenticated state: no
+                    such mailbox, can't access mailbox
+               BAD - command unknown or arguments invalid
+
+      The EXAMINE command is identical to SELECT and returns the same
+      output; however, the selected mailbox is identified as read-only.
+      No changes to the permanent state of the mailbox, including
+      per-user state, are permitted.
+
+
+
+
+
+
+Crispin                                                        [Page 16]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+      The text of the tagged OK response to the EXAMINE command MUST
+      begin with the "[READ-ONLY]" response code.
+
+   Example:    C: A932 EXAMINE blurdybloop
+               S: * 17 EXISTS
+               S: * 2 RECENT
+               S: * OK [UNSEEN 8] Message 8 is first unseen
+               S: * OK [UIDVALIDITY 3857529045] UIDs valid
+               S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
+               S: * OK [PERMANENTFLAGS ()] No permanent flags permitted
+               S: A932 OK [READ-ONLY] EXAMINE completed
+
+
+6.3.3.  CREATE Command
+
+   Arguments:  mailbox name
+
+   Data:       no specific data for this command
+
+   Result:     OK - create completed
+               NO - create failure: can't create mailbox with that name
+               BAD - command unknown or arguments invalid
+
+      The CREATE command creates a mailbox with the given name.  An OK
+      response is returned only if a new mailbox with that name has been
+      created.  It is an error to attempt to create INBOX or a mailbox
+      with a name that refers to an extant mailbox.  Any error in
+      creation will return a tagged NO response.
+
+      If the mailbox name is suffixed with the server's hierarchy
+      separator character (as returned from the server by a LIST
+      command), this is a declaration that the client may, in the
+      future, create mailbox names under this name in the hierarchy.
+      Server implementations that do not require this declaration MUST
+      ignore it.
+
+      If a new mailbox is created with the same name as a mailbox which
+      was deleted, its unique identifiers MUST be greater than any
+      unique identifiers used in the previous incarnation of the mailbox
+      UNLESS the new incarnation has a different unique identifier
+      validity value.  See the description of the UID command for more
+      detail.
+
+   Example:    C: A003 CREATE owatagusiam/
+               S: A003 OK CREATE completed
+               C: A004 CREATE owatagusiam/blurdybloop
+               S: A004 OK CREATE completed
+
+
+
+
+Crispin                                                        [Page 17]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+        Note: the interpretation of this example depends on whether
+        "/" was returned as the hierarchy separator from LIST.  If
+        "/" is the hierarchy separator, a new level of hierarchy
+        named "owatagusiam" with a member called "blurdybloop" is
+        created.  Otherwise, two mailboxes at the same hierarchy
+        level are created.
+
+
+6.3.4.  DELETE Command
+
+   Arguments:  mailbox name
+
+   Data:       no specific data for this command
+
+   Result:     OK - delete completed
+               NO - delete failure: can't delete mailbox with that name
+               BAD - command unknown or arguments invalid
+
+      The DELETE command permanently removes the mailbox with the given
+      name.  A tagged OK response is returned only if the mailbox has
+      been deleted.  It is an error to attempt to delete INBOX or a
+      mailbox name that does not exist.  Any error in deletion will
+      return a tagged NO response.
+
+      The value of the highest-used unique indentifier of the deleted
+      mailbox MUST be preserved so that a new mailbox created with the
+      same name will not reuse the identifiers of the former
+      incarnation, UNLESS the new incarnation has a different unique
+      identifier validity value.  See the description of the UID command
+      for more detail.
+
+   Example:    C: A683 DELETE blurdybloop
+               S: A683 OK DELETE completed
+
+
+6.3.5.  RENAME Command
+
+   Arguments:  existing mailbox name
+               new mailbox name
+
+   Data:       no specific data for this command
+
+   Result:     OK - rename completed
+               NO - rename failure: can't rename mailbox with that name,
+                    can't rename to mailbox with that name
+               BAD - command unknown or arguments invalid
+
+
+
+
+
+Crispin                                                        [Page 18]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+      The RENAME command changes the name of a mailbox.  A tagged OK
+      response is returned only if the mailbox has been renamed.  It is
+      an error to attempt to rename from a mailbox name that does not
+      exist or to a mailbox name that already exists.  Any error in
+      renaming will return a tagged NO response.
+
+      Renaming INBOX is permitted; a new, empty INBOX is created in its
+      place.
+
+   Example:    C: Z4S9 RENAME blurdybloop owatagusiam
+               S: Z4S9 OK RENAME completed
+
+
+6.3.6.  SUBSCRIBE Command
+
+   Arguments:  mailbox
+
+   Data:       no specific data for this command
+
+   Result:     OK - subscribe completed
+               NO - subscribe failure: can't subscribe to that name
+               BAD - command unknown or arguments invalid
+
+      The SUBSCRIBE command adds the specified mailbox name to the
+      server's set of "active" or "subscribed" mailboxes as returned by
+      the LSUB command.  This command returns a tagged OK response only
+      if the subscription is successful.
+
+   Example:    C: A002 SUBSCRIBE #news.comp.mail.mime
+               S: A002 OK SUBSCRIBE completed
+
+
+6.3.7.  UNSUBSCRIBE Command
+
+   Arguments:  mailbox name
+
+   Data:       no specific data for this command
+
+   Result:     OK - unsubscribe completed
+               NO - unsubscribe failure: can't unsubscribe that name
+               BAD - command unknown or arguments invalid
+
+      The UNSUBSCRIBE command removes the specified mailbox name from
+      the server's set of "active" or "subscribed" mailboxes as returned
+      by the LSUB command.  This command returns a tagged OK response
+      only if the unsubscription is successful.
+
+
+
+
+
+Crispin                                                        [Page 19]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+   Example:    C: A002 UNSUBSCRIBE #news.comp.mail.mime
+               S: A002 OK UNSUBSCRIBE completed
+
+
+6.3.8.  LIST Command
+
+   Arguments:  reference name
+               mailbox name with possible wildcards
+
+   Data:       untagged responses: LIST
+
+   Result:     OK - list completed
+               NO - list failure: can't list that reference or name
+               BAD - command unknown or arguments invalid
+
+      The LIST command returns a subset of names from the complete set
+      of all names available to the user.  Zero or more untagged LIST
+      replies are returned, containing the name attributes, hierarchy
+      delimiter, and name; see the description of the LIST reply for
+      more detail.
+
+      An empty ("" string) reference name argument indicates that the
+      mailbox name is interpreted as by SELECT. The returned mailbox
+      names MUST match the supplied mailbox name pattern.  A non-empty
+      reference name argument is the name of a mailbox or a level of
+      mailbox hierarchy, and indicates a context in which the mailbox
+      name is interpreted in an implementation-defined manner.
+
+      The reference and mailbox name arguments are interpreted, in an
+      implementation-dependent fashion, into a canonical form that
+      represents an unambiguous left-to-right hierarchy.  The returned
+      mailbox names will be in the interpreted form.
+
+      Any part of the reference argument that is included in the
+      interpreted form SHOULD prefix the interpreted form.  It should
+      also be in the same form as the reference name argument.  This
+      rule permits the client to determine if the returned mailbox name
+      is in the context of the reference argument, or if something about
+      the mailbox argument overrode the reference argument.  Without
+      this rule, the client would have to have knowledge of the server's
+      naming semantics including what characters are "breakouts" that
+      override a naming context.
+
+
+
+
+
+
+
+
+
+Crispin                                                        [Page 20]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+           For example, here are some examples of how references
+           and mailbox names might be interpreted on a UNIX-based
+           server:
+
+               Reference     Mailbox Name  Interpretation
+               ------------  ------------  --------------
+               ~smith/Mail/  foo.*         ~smith/Mail/foo.*
+               archive/      %             archive/%
+               #news.        comp.mail.*   #news.comp.mail.*
+               ~smith/Mail/  /usr/doc/foo  /usr/doc/foo
+               archive/      ~fred/Mail/*  ~fred/Mail/*
+
+           The first three examples demonstrate interpretations in
+           the context of the reference argument.  Note that
+           "~smith/Mail" should not be transformed into something
+           like "/u2/users/smith/Mail", or it would be impossible
+           for the client to determine that the interpretation was
+           in the context of the reference.
+
+      The character "*" is a wildcard, and matches zero or more
+      characters at this position.  The character "%" is similar to "*",
+      but it does not match a hierarchy delimiter.  If the "%" wildcard
+      is the last character of a mailbox name argument, matching levels
+      of hierarchy are also returned.  If these levels of hierarchy are
+      not also selectable mailboxes, they are returned with the
+      \Noselect mailbox name attribute (see the description of the LIST
+      response for more detail).
+
+      Server implementations are permitted to "hide" otherwise
+      accessible mailboxes from the wildcard characters, by preventing
+      certain characters or names from matching a wildcard in certain
+      situations.  For example, a UNIX-based server might restrict the
+      interpretation of "*" so that an initial "/" character does not
+      match.
+
+      The special name INBOX is included in the output from LIST if it
+      matches the input arguments and INBOX is supported by this server
+      for this user.  The criteria for omitting INBOX is whether SELECT
+      INBOX will return failure; it is not relevant whether the user's
+      real INBOX resides on this or some other server.
+
+   Example:    C: A002 LIST "~/Mail/" "%"
+               S: * LIST (\Noselect) "/" ~/Mail/foo
+               S: * LIST () "/" ~/Mail/meetings
+               S: A002 OK LIST completed
+
+
+
+
+
+
+Crispin                                                        [Page 21]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+6.3.9.  LSUB Command
+
+   Arguments:  reference name
+               mailbox name with possible wildcards
+
+   Data:       untagged responses: LSUB
+
+   Result:     OK - lsub completed
+               NO - lsub failure: can't list that reference or name
+               BAD - command unknown or arguments invalid
+
+      The LSUB command returns a subset of names from the set of names
+      that the user has declared as being "active" or "subscribed".
+      Zero or more untagged LSUB replies are returned.  The arguments to
+      LSUB are in the same form as those for LIST.
+
+   Example:    C: A002 LSUB "#news." "comp.mail.*"
+               S: * LSUB () "." #news.comp.mail.mime
+               S: * LSUB () "." #news.comp.mail.misc
+               S: A002 OK LSUB completed
+
+
+6.3.10. APPEND Command
+
+   Arguments:  mailbox name
+               optional flag parenthesized list
+               optional date/time string
+               message literal
+
+   Data:       no specific data for this command
+
+   Result:     OK - append completed
+               NO - append error: can't append to that mailbox, error
+                    in flags or date/time or message text
+               BAD - command unknown or arguments invalid
+
+      The APPEND command appends the literal argument as a new message
+      in the specified destination mailbox.  This argument is in the
+      format of an [RFC-822] message.  8-bit characters are permitted in
+      the message.  A server implementation that is unable to preserve
+      8-bit data properly MUST be able to reversibly convert 8-bit
+      APPEND data to 7-bit using [MIME-1] encoding.
+
+      If a flag parenthesized list or date_time are specified, that data
+      SHOULD be set in the resulting message; otherwise, the defaults of
+      empty flags and the current date/time are used.
+
+
+
+
+
+Crispin                                                        [Page 22]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+      If the append is unsuccessful for any reason, the mailbox MUST be
+      restored to its state before the APPEND attempt; no partial
+      appending is permitted.  If the mailbox is currently selected, the
+      normal new mail actions should occur.
+
+      If the destination mailbox does not exist, a server MUST return an
+      error, and MUST NOT automatically create the mailbox.  Unless it
+      is certain that the destination mailbox can not be created, the
+      server MUST send the response code "[TRYCREATE]" as the prefix of
+      the text of the tagged NO response.  This gives a hint to the
+      client that it can attempt a CREATE command and retry the APPEND
+      if the CREATE is successful.
+
+   Example:    C: A003 APPEND saved-messages (\Seen) {310}
+               C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
+               C: From: Fred Foobar <foobar@Blurdybloop.COM>
+               C: Subject: afternoon meeting
+               C: To: mooch@owatagu.siam.edu
+               C: Message-Id: <B27397-0100000@Blurdybloop.COM>
+               C: MIME-Version: 1.0
+               C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
+               C:
+               C: Hello Joe, do you think we can meet at 3:30 tomorrow?
+               C:
+               S: A003 OK APPEND completed
+
+        Note: the APPEND command is not used for message delivery,
+        because it does not provide a mechanism to transfer [SMTP]
+        envelope information.
+
+
+
+6.4.    Client Commands - Selected State
+
+   In selected state, commands that manipulate messages in a mailbox are
+   permitted.
+
+   In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
+   and the authenticated state commands (SELECT, EXAMINE, CREATE,
+   DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, FIND
+   ALL.MAILBOXES, FIND MAILBOXES, and APPEND), the following commands
+   are valid in the selected state: CHECK, CLOSE, EXPUNGE, SEARCH,
+   FETCH, PARTIAL, STORE, COPY, and UID.
+
+
+
+
+
+
+
+
+Crispin                                                        [Page 23]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+6.4.1.  CHECK Command
+
+   Arguments:  none
+
+   Data:       no specific data for this command
+
+   Result:     OK - check completed
+               BAD - command unknown or arguments invalid
+
+      The CHECK command requests a checkpoint of the currently selected
+      mailbox.  A checkpoint refers to any implementation-dependent
+      housekeeping associated with the mailbox (e.g. resolving the
+      server's in-memory state of the mailbox with the state on its
+      disk) that is not normally executed as part of each command.  A
+      checkpoint may take a non-instantaneous amount of real time to
+      complete.  If a server implementation has no such housekeeping
+      considerations, CHECK is equivalent to NOOP.
+
+      There is no guarantee that an EXISTS untagged response will happen
+      as a result of CHECK.  NOOP, not CHECK, should be used for new
+      mail polling.
+
+   Example:    C: FXXZ CHECK
+               S: FXXZ OK CHECK Completed
+
+
+6.4.2.  CLOSE Command
+
+   Arguments:  none
+
+   Data:       no specific data for this command
+
+   Result:     OK - close completed, now in authenticated state
+               NO - close failure: no mailbox selected
+               BAD - command unknown or arguments invalid
+
+      The CLOSE command permanently removes from the currently selected
+      mailbox all messages that have the \Deleted flag set, and returns
+      to authenticated state from selected state.  No untagged EXPUNGE
+      responses are sent.
+
+      No messages are removed, and no error is given, if the mailbox is
+      selected by an EXAMINE command or is otherwise selected read-only.
+
+      Even when a mailbox is selected, it is not required to send a
+      CLOSE command before a SELECT, EXAMINE, or LOGOUT command.  The
+      SELECT, EXAMINE, and LOGOUT commands implicitly close the
+      currently selected mailbox without doing an expunge.  However,
+
+
+
+Crispin                                                        [Page 24]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+      when many messages are deleted, a CLOSE-LOGOUT or CLOSE-SELECT
+      sequence is considerably faster than an EXPUNGE-LOGOUT or
+      EXPUNGE-SELECT because no untagged EXPUNGE responses (which the
+      client would probably ignore) are sent.
+
+   Example:    C: A341 CLOSE
+               S: A341 OK CLOSE completed
+
+
+6.4.3.  EXPUNGE Command
+
+   Arguments:  none
+
+   Data:       untagged responses: EXPUNGE
+
+   Result:     OK - expunge completed
+               NO - expunge failure: can't expunge (e.g. permission
+                    denied)
+               BAD - command unknown or arguments invalid
+
+      The EXPUNGE command permanently removes from the currently
+      selected mailbox all messages that have the \Deleted flag set.
+      Before returning an OK to the client, an untagged EXPUNGE response
+      is sent for each message that is removed.
+
+   Example:    C: A202 EXPUNGE
+               S: * 3 EXPUNGE
+               S: * 3 EXPUNGE
+               S: * 5 EXPUNGE
+               S: * 8 EXPUNGE
+               S: A202 OK EXPUNGE completed
+
+        Note: in this example, messages 3, 4, 7, and 11 had the
+        \Deleted flag set.  See the description of the EXPUNGE
+        response for further explanation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                                                        [Page 25]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+6.4.4.  SEARCH Command
+
+   Arguments:  optional character set specification
+               searching criteria (one or more)
+
+   Data:       mandatory untagged response: SEARCH
+
+   Result:     OK - search completed
+               NO - search error: can't search that character set or
+                    criteria
+               BAD - command unknown or arguments invalid
+
+      The SEARCH command searches the mailbox for messages that match
+      the given searching criteria.  Searching criteria consist of one
+      or more search keys.  The untagged SEARCH response from the server
+      contains a listing of message sequence numbers corresponding to
+      those messages that match the searching criteria.
+
+      When multiple keys are specified, the result is the intersection
+      (AND function) of all the messages that match those keys.  For
+      example, the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers
+      to all deleted messages from Smith that were placed in the mailbox
+      since February 1, 1994.  A search key may also be a parenthesized
+      list of one or more search keys (e.g. for use with the OR and NOT
+      keys).
+
+      Server implementations MAY exclude [MIME-1] body parts with
+      terminal content types other than TEXT and MESSAGE from
+      consideration in SEARCH matching.
+
+      The optional character set specification consists of the word
+      "CHARSET" followed by a registered MIME character set.  It
+      indicates the character set of the strings that appear in the
+      search criteria.  [MIME-2] strings that appear in RFC 822/MIME
+      message headers, and [MIME-1] content transfer encodings, MUST be
+      decoded before matching.  Except for US-ASCII, it is not required
+      that any particular character set be supported.  If the server
+      does not support the specified character set, it MUST return a
+      tagged NO response (not a BAD).
+
+      In all search keys that use strings, a message matches the key if
+      the string is a substring of the field.  The matching is
+      case-insensitive.
+
+
+
+
+
+
+
+
+Crispin                                                        [Page 26]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+      The defined search keys are as follows.  Refer to the Formal
+      Syntax section for the precise syntactic definitions of the
+      arguments.
+
+      <message set>  Messages with message sequence numbers
+                     corresponding to the specified message sequence
+                     number set
+
+      ALL            All messages in the mailbox; the default initial
+                     key for ANDing.
+
+      ANSWERED       Messages with the \Answered flag set.
+
+      BCC <string>   Messages that contain the specified string in the
+                     envelope structure's BCC field.
+
+      BEFORE <date>  Messages whose internal date is earlier than the
+                     specified date.
+
+      BODY <string>  Messages that contain the specified string in the
+                     body of the message.
+
+      CC <string>    Messages that contain the specified string in the
+                     envelope structure's CC field.
+
+      DELETED        Messages with the \Deleted flag set.
+
+      DRAFT          Messages with the \Draft flag set.
+
+      FLAGGED        Messages with the \Flagged flag set.
+
+      FROM <string>  Messages that contain the specified string in the
+                     envelope structure's FROM field.
+
+      HEADER <field-name> <string>
+                     Messages that have a header with the specified
+                     field-name (as defined in [RFC-822]) and that
+                     contains the specified string in the [RFC-822]
+                     field-body.
+
+      KEYWORD <flag> Messages with the specified keyword set.
+
+      LARGER <n>     Messages with an RFC822.SIZE larger than the
+                     specified number of octets.
+
+      NEW            Messages that have the \Recent flag set but not the
+                     \Seen flag.  This is functionally equivalent to
+                     "(RECENT UNSEEN)".
+
+
+
+Crispin                                                        [Page 27]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+      NOT <search-key>
+                     Messages that do not match the specified search
+                     key.
+
+      OLD            Messages that do not have the \Recent flag set.
+                     This is functionally equivalent to "NOT RECENT" (as
+                     opposed to "NOT NEW").
+
+      ON <date>      Messages whose internal date is within the
+                     specified date.
+
+      OR <search-key1> <search-key2>
+                     Messages that match either search key.
+
+      RECENT         Messages that have the \Recent flag set.
+
+      SEEN           Messages that have the \Seen flag set.
+
+      SENTBEFORE <date>
+                     Messages whose [RFC-822] Date: header is earlier
+                     than the specified date.
+
+      SENTON <date>  Messages whose [RFC-822] Date: header is within the
+                     specified date.
+
+      SENTSINCE <date>
+                     Messages whose [RFC-822] Date: header is within or
+                     later than the specified date.
+
+      SINCE <date>   Messages whose internal date is within or later
+                     than the specified date.
+
+      SMALLER <n>    Messages with an RFC822.SIZE smaller than the
+                     specified number of octets.
+
+      SUBJECT <string>
+                     Messages that contain the specified string in the
+                     envelope structure's SUBJECT field.
+
+      TEXT <string>  Messages that contain the specified string in the
+                     header or body of the message.
+
+      TO <string>    Messages that contain the specified string in the
+                     envelope structure's TO field.
+
+      UID <message set>
+                     Messages with unique identifiers corresponding to
+                     the specified unique identifier set.
+
+
+
+Crispin                                                        [Page 28]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+      UNANSWERED     Messages that do not have the \Answered flag set.
+
+      UNDELETED      Messages that do not have the \Deleted flag set.
+
+      UNDRAFT        Messages that do not have the \Draft flag set.
+
+      UNFLAGGED      Messages that do not have the \Flagged flag set.
+
+      UNKEYWORD <flag>
+                     Messages that do not have the specified keyword
+                     set.
+
+      UNSEEN         Messages that do not have the \Seen flag set.
+
+
+   Example:    C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith"
+               S: * SEARCH 2 84 882
+               S: A282 OK SEARCH completed
+
+
+6.4.5.  FETCH Command
+
+   Arguments:  message set
+               message data item names
+
+   Data:       untagged responses: FETCH
+
+   Result:     OK - fetch completed
+               NO - fetch error: can't fetch that data
+               BAD - command unknown or arguments invalid
+
+      The FETCH command retrieves data associated with a message in the
+      mailbox.  The data items to be fetched may be either a single atom
+      or a parenthesized list.  The currently defined data items that
+      can be fetched are:
+
+      ALL            Macro equivalent to: (FLAGS INTERNALDATE
+                     RFC822.SIZE ENVELOPE)
+
+      BODY           Non-extensible form of BODYSTRUCTURE.
+
+      BODY[<section>]
+                     The text of a particular body section.  The section
+                     specification is a set of one or more part numbers
+                     delimited by periods.
+
+                     Single-part messages only have a part 1.
+
+
+
+
+Crispin                                                        [Page 29]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+                     Multipart messages are assigned consecutive part
+                     numbers, as they occur in the message.  If a
+                     particular part is of type message or multipart,
+                     its parts must be indicated by a period followed by
+                     the part number within that nested multipart part.
+                     It is not permitted to fetch a multipart part
+                     itself, only its individual members.
+
+                     A part of type MESSAGE and subtype RFC822 also has
+                     nested parts.  These are the parts of the MESSAGE
+                     part's body.  Nested part 0 of a part of type
+                     MESSAGE and subtype RFC822 is the [RFC-822] header
+                     of the message.
+
+                     Every message has at least one part.
+
+                          Here is an example of a complex message
+                          with its associated section
+                          specifications:
+
+                           0   ([RFC-822] header of the message)
+                               MULTIPART/MIXED
+                           1   TEXT/PLAIN
+                           2   APPLICATION/OCTET-STREAM
+                           3   MESSAGE/RFC822
+                           3.0   ([RFC-822] header of the message)
+                           3.1   TEXT/PLAIN
+                           3.2   APPLICATION/OCTET-STREAM
+                                 MULTIPART/MIXED
+                           4.1   IMAGE/GIF
+                           4.2   MESSAGE/RFC822
+                           4.2.0   ([RFC-822] header of the message)
+                           4.2.1   TEXT/PLAIN
+                                   MULTIPART/ALTERNATIVE
+                           4.2.2.1  TEXT/PLAIN
+                           4.2.2.2  TEXT/RICHTEXT
+
+                          Note that there is no section
+                          specification for the Multi-part parts
+                          (no section 4 or 4.2.2).
+
+                     The \Seen flag is implicitly set; if this causes
+                     the flags to change they should be included as part
+                     of the fetch responses.
+
+      BODY.PEEK[<section>]
+                     An alternate form of BODY[section] that does not
+                     implicitly set the \Seen flag.
+
+
+
+Crispin                                                        [Page 30]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+      BODYSTRUCTURE  The [MIME-1] body structure of the message.  This
+                     is computed by the server by parsing the [MIME-1]
+                     header lines.
+
+      ENVELOPE       The envelope structure of the message.  This is
+                     computed by the server by parsing the [RFC-822]
+                     header into the component parts, defaulting various
+                     fields as necessary.
+
+      FAST           Macro equivalent to: (FLAGS INTERNALDATE
+                     RFC822.SIZE)
+
+      FLAGS          The flags that are set for this message.
+
+      FULL           Macro equivalent to: (FLAGS INTERNALDATE
+                     RFC822.SIZE ENVELOPE BODY)
+
+      INTERNALDATE   The date and time of final delivery of the message
+                     as defined by RFC 821.
+
+      RFC822         The message in [RFC-822] format.  The \Seen flag is
+                     implicitly set; if this causes the flags to change
+                     they should be included as part of the fetch
+                     responses.  This is the concatenation of
+                     RFC822.HEADER and RFC822.TEXT.
+
+      RFC822.PEEK    An alternate form of RFC822 that does not
+                     implicitly set the \Seen flag.
+
+      RFC822.HEADER  The [RFC-822] format header of the message as
+                     stored on the server including the delimiting blank
+                     line between the header and the body.
+
+      RFC822.HEADER.LINES <header_list>
+                     All header lines (including continuation lines) of
+                     the [RFC-822] format header of the message with a
+                     field-name (as defined in [RFC-822]) that matches
+                     any of the strings in header_list.  The matching is
+                     case-insensitive but otherwise exact.  The
+                     delimiting blank line between the header and the
+                     body is always included.
+
+
+
+
+
+
+
+
+
+
+Crispin                                                        [Page 31]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+      RFC822.HEADER.LINES.NOT <header_list>
+                     All header lines (including continuation lines) of
+                     the [RFC-822] format header of the message with a
+                     field-name (as defined in [RFC-822]) that does not
+                     match any of the strings in header_list.  The
+                     matching is case-insensitive but otherwise exact.
+                     The delimiting blank line between the header and
+                     the body is always included.
+
+      RFC822.SIZE    The number of octets in the message, as expressed
+                     in [RFC-822] format.
+
+      RFC822.TEXT    The text body of the message, omitting the
+                     [RFC-822] header.  The \Seen flag is implicitly
+                     set; if this causes the flags to change they should
+                     be included as part of the fetch responses.
+
+      RFC822.TEXT.PEEK
+                     An alternate form of RFC822.TEXT that does not
+                     implicitly set the \Seen flag.
+
+      UID            The unique identifier for the message.
+
+
+   Example:    C: A654 FETCH 2:4 (FLAGS RFC822.HEADER.LINES (DATE FROM))
+               S: * 2 FETCH ....
+               S: * 3 FETCH ....
+               S: * 4 FETCH ....
+               S: A003 OK FETCH completed
+
+
+6.4.6.  PARTIAL Command
+
+   Arguments:  message sequence number
+               message data item name
+               position of first octet
+               number of octets
+
+   Data:       untagged responses: FETCH
+
+   Result:     OK - partial completed
+               NO - partial error: can't fetch that data
+               BAD - command unknown or arguments invalid
+
+      The PARTIAL command is equivalent to the associated FETCH command,
+      with the added functionality that only the specified number of
+      octets, beginning at the specified starting octet, are returned.
+      Only a single message can be fetched at a time.  The first octet
+
+
+
+Crispin                                                        [Page 32]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+      of a message, and hence the minimum for the starting octet, is
+      octet 1.
+
+      The following FETCH items are valid data for PARTIAL: RFC822,
+      RFC822.HEADER, RFC822.TEXT, BODY[section], as well as any .PEEK
+      forms of these.
+
+      Any partial fetch that attempts to read beyond the end of the text
+      is truncated as appropriate.  If the starting octet is beyond the
+      end of the text, an empty string is returned.
+
+      The data are returned with the FETCH response.  There is no
+      indication of the range of the partial data in this response.  It
+      is not possible to stream multiple PARTIAL commands of the same
+      data item without processing and synchronizing at each step, since
+      streamed commands may be executed out of order.
+
+      There is no requirement that partial fetches follow any sequence.
+      For example, if a partial fetch of octets 1 through 10000 breaks
+      in an awkward place for BASE64 decoding, it is permitted to
+      continue with a partial fetch of 9987 through 19987, etc.
+
+      The handling of the \Seen flag is the same as in the associated
+      FETCH command.
+
+   Example:    C: A005 PARTIAL 4 RFC822 1 1024
+               S: * 1 FETCH (RFC822 {1024}
+               S: Return-Path: <gray@cac.washington.edu>
+               S: ...
+               S: .........  FLAGS (\Seen))
+               S: A005 OK PARTIAL completed
+
+
+6.4.7.  STORE Command
+
+   Arguments:  message set
+               message data item name
+               value for message data item
+
+   Data:       untagged responses: FETCH
+
+   Result:     OK - store completed
+               NO - store error: can't store that data
+               BAD - command unknown or arguments invalid
+
+      The STORE command alters data associated with a message in the
+      mailbox.  Normally, STORE will return the updated value of the
+      data with an untagged FETCH response.  A suffix of ".SILENT" in
+
+
+
+Crispin                                                        [Page 33]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+      the data item name prevents the untagged FETCH, and the server
+      should assume that the client has determined the updated value
+      itself or does not care about the updated value.
+
+      The currently defined data items that can be stored are:
+
+      FLAGS <flag list>
+                     Replace the flags for the message with the
+                     argument.  The new value of the flags are returned
+                     as if a FETCH of those flags was done.
+
+      FLAGS.SILENT <flag list>
+                     Equivalent to FLAGS, but without returning a new
+                     value.
+
+      +FLAGS <flag list>
+                     Add the argument to the flags for the message.  The
+                     new value of the flags are returned as if a FETCH
+                     of those flags was done.
+
+      +FLAGS.SILENT <flag list>
+                     Equivalent to +FLAGS, but without returning a new
+                     value.
+
+      -FLAGS <flag list>
+                     Remove the argument from the flags for the message.
+                     The new value of the flags are returned as if a
+                     FETCH of those flags was done.
+
+      -FLAGS.SILENT <flag list>
+                     Equivalent to -FLAGS, but without returning a new
+                     value.
+
+
+   Example:    C: A003 STORE 2:4 +FLAGS (\Deleted)
+               S: * 2 FETCH FLAGS (\Deleted \Seen)
+               S: * 3 FETCH FLAGS (\Deleted)
+               S: * 4 FETCH FLAGS (\Deleted \Flagged \Seen)
+               S: A003 OK STORE completed
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                                                        [Page 34]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+6.4.8.  COPY Command
+
+   Arguments:  message set
+               mailbox name
+
+   Data:       no specific data for this command
+
+   Result:     OK - copy completed
+               NO - copy error: can't copy those messages or to that
+                    name
+               BAD - command unknown or arguments invalid
+
+      The COPY command copies the specified message(s) to the specified
+      destination mailbox.  The flags and internal date of the
+      message(s) SHOULD be preserved in the copy.
+
+      If the destination mailbox does not exist, a server SHOULD return
+      an error.  It SHOULD NOT automatically create the mailbox.  Unless
+      it is certain that the destination mailbox can not be created, the
+      server MUST send the response code "[TRYCREATE]" as the prefix of
+      the text of the tagged NO response.  This gives a hint to the
+      client that it can attempt a CREATE command and retry the COPY if
+      the CREATE is successful.
+
+      If the COPY command is unsuccessful for any reason, server
+      implementations MUST restore the destination mailbox to its state
+      before the COPY attempt.
+
+   Example:    C: A003 COPY 2:4 MEETING
+               S: A003 OK COPY completed
+
+
+6.4.9.  UID Command
+
+   Arguments:  command name
+               command arguments
+
+   Data:       untagged responses: FETCH, SEARCH
+
+   Result:     OK - UID command completed
+               NO - UID command error
+               BAD - command unknown or arguments invalid
+
+      The UID command has two forms.  In the first form, it takes as its
+      arguments a COPY, FETCH, or STORE command with arguments
+      appropriate for the associated command.  However, the numbers in
+      the message set argument are unique identifiers instead of message
+      sequence numbers.
+
+
+
+Crispin                                                        [Page 35]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+      In the second form, the UID command takes a SEARCH command with
+      SEARCH command arguments.  The interpretation of the arguments is
+      the same as with SEARCH; however, the numbers returned in a SEARCH
+      response for a UID SEARCH command are unique identifiers instead
+      of message sequence numbers.  For example, the command UID SEARCH
+      1:100 UID 443:557 returns the unique identifiers corresponding to
+      the intersection of the message sequence number set 1:100 and the
+      UID set 443:557.
+
+      A unique identifier of a message is a number, and is guaranteed
+      not to refer to any other message in the mailbox.  Unique
+      identifiers are assigned in a strictly ascending fashion for each
+      message added to the mailbox.  Unlike message sequence numbers,
+      unique identifiers persist across sessions.  This permits a client
+      to resynchronize its state from a previous session with the server
+      (e.g.  disconnected or offline access clients); this is discussed
+      further in [IMAP-DISC].
+
+      Associated with every mailbox is a unique identifier validity
+      value, which is sent in an UIDVALIDITY response code in an OK
+      untagged response at message selection time.  If unique
+      identifiers from an earlier session fail to persist to this
+      session, the unique identifier validity value MUST be greater than
+      in the earlier session.
+
+           Note: An example of a good value to use for the unique
+           identifier validity value would be a 32-bit
+           representation of the creation date/time of the mailbox.
+           It is alright to use a constant such as 1, but only if
+           it guaranteed that unique identifers will never be
+           reused, even in the case of a mailbox being deleted and
+           a new mailbox by the same name created at some future
+           time.
+
+
+      Message set ranges are permitted; however, there is no guarantee
+      that unique identifiers be contiguous.  A non-existent unique
+      identifier within a message set range is ignored without any error
+      message generated.
+
+      The number after the "*" in an untagged FETCH response is always a
+      message sequence number, not a unique identifier, even for a UID
+      command response.  However, server implementations MUST implicitly
+      include the UID message data item as part of any FETCH response
+      caused by a UID command, regardless of whether UID was specified
+      as a message data item to the FETCH.
+
+
+
+
+
+Crispin                                                        [Page 36]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+   Example:    C: A003 UID FETCH 4827313:4828442 FLAGS
+               S: * 23 FETCH (FLAGS (\Seen) UID 4827313)
+               S: * 24 FETCH (FLAGS (\Seen) UID 4827943)
+               S: * 25 FETCH (FLAGS (\Seen) UID 4828442)
+               S: A999 UID FETCH completed
+
+
+
+6.5.    Client Commands - Experimental/Expansion
+
+
+6.5.1.  X<atom> Command
+
+   Arguments:  implementation defined
+
+   Data:       implementation defined
+
+   Result:     OK - command completed
+               NO - failure
+               BAD - command unknown or arguments invalid
+
+      Any command prefixed with an X is an experimental command.
+      Commands which are not part of this specification, or a standard
+      or standards-track revision of this specification, MUST use the X
+      prefix.
+
+      Any added untagged responses issued by an experimental command
+      MUST also be prefixed with an X.  Server implementations MUST NOT
+      send any such untagged responses, unless the client requested it
+      by issuing the associated experimental command.
+
+   Example:    C: a441 CAPABILITY
+               S: * CAPABILITY IMAP4 XPIG-LATIN
+               S: a441 OK CAPABILITY completed
+               C: A442 XPIG-LATIN
+               S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay
+               S: A442 OK XPIG-LATIN ompleted-cay
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                                                        [Page 37]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+7.      Server Responses
+
+   Server responses are in three forms: status responses, server data,
+   and command continuation request.
+
+   Server response data, identified by "Data:" in the response
+   descriptions below, are described by function, not by syntax.  The
+   precise syntax of server response data is described in the Formal
+   Syntax section.
+
+   The client MUST be prepared to accept any response at all times.
+
+   Status responses that are tagged indicate the completion result of a
+   client command, and have a tag matching the command.
+
+   Some status responses, and all server data, are untagged.  An
+   untagged response is indicated by the token "*" instead of a tag.
+   Untagged status responses indicate server greeting, or server status
+   that does not indicate the completion of a command.  For historical
+   reasons, untagged server data responses are also called "unsolicited
+   data", although strictly speaking only unilateral server data is
+   truly "unsolicited".
+
+   Certain server data MUST be recorded by the client when it is
+   received; this is noted in the description of that data.  Such data
+   conveys critical information which affects the interpretation of all
+   subsequent commands and responses (e.g. updates reflecting the
+   creation or destruction of messags).
+
+   Other server data SHOULD be recorded for later reference; if the
+   client does not need to record the data, or if recording the data has
+   no obvious purpose (e.g. a SEARCH response when no SEARCH command is
+   in progress), the data SHOULD be ignored.
+
+   An example of unilateral untagged responses occurs when the IMAP
+   connection is in selected state.  In selected state, the server
+   checks the mailbox for new messages as part of the execution of each
+   command.  If new messages are found, the server sends untagged EXISTS
+   and RECENT responses reflecting the new size of the mailbox.  Server
+   implementations that offer multiple simultaneous access to the same
+   mailbox should also send appropriate unilateral untagged FETCH and
+   EXPUNGE responses if another agent changes the state of any message
+   flags or expunges any messages.
+
+   Command continuation request responses use the token "+" instead of a
+   tag.  These responses are sent by the server to indicate acceptance
+   of an incomplete client command and readiness for the remainder of
+   the command.
+
+
+
+Crispin                                                        [Page 38]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+7.1.    Server Responses - Status Responses
+
+   Status responses may include an optional response code.  A response
+   code consists of data inside square brackets in the form of an atom,
+   possibly followed by a space and arguments.  The response code
+   contains additional information or status codes for client software
+   beyond the OK/NO/BAD condition, and are defined when there is a
+   specific action that a client can take based upon the additional
+   information.
+
+   The currently defined response codes are:
+
+      ALERT          The human-readable text contains a special alert
+                     that MUST be presented to the user in a fashion
+                     that calls the user's attention to the message.
+
+      PARSE          The human-readable text represents an error in
+                     parsing the [RFC-822] or [MIME-1] headers of a
+                     message in the mailbox.
+
+      PERMANENTFLAGS Followed by a parenthesized list of flags,
+                     indicates which of the known flags that the client
+                     may change permanently.  Any flags that are in the
+                     FLAGS untagged response, but not the PERMANENTFLAGS
+                     list, can not be set permanently.  If the client
+                     attempts to STORE a flag that is not in the
+                     PERMANENTFLAGS list, the server will either reject
+                     it with a NO reply or store the state for the
+                     remainder of the current session only.  The
+                     PERMANENTFLAGS list may also include the special
+                     flag \*, which indicates that it is possible to
+                     create new keywords by attempting to store those
+                     flags in the mailbox.
+
+      READ-ONLY      The mailbox is selected read-only, or its access
+                     while selected has changed from read-write to
+                     read-only.
+
+      READ-WRITE     The mailbox is selected read-write, or its access
+                     while selected has changed from read-only to
+                     read-write.
+
+      TRYCREATE      An APPEND or COPY attempt is failing because the
+                     target mailbox does not exist (as opposed to some
+                     other reason).  This is a hint to the client that
+                     the operation may succeed if the mailbox is first
+                     created by the CREATE command.
+
+
+
+
+Crispin                                                        [Page 39]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+      UIDVALIDITY    Followed by a decimal number, indicates the unique
+                     identifier validity value.  See the description of
+                     the UID command for more detail.
+
+      UNSEEN         Followed by a decimal number, indicates the number
+                     of the first message without the \Seen flag set.
+
+      Additional response codes defined by particular client or server
+      implementations should be prefixed with an "X" until they are
+      added to a revision of this protocol.  Client implementations
+      should ignore response codes that they do not recognize.
+
+
+7.1.1.  OK Response
+
+   Data:       optional response code
+               human-readable text
+
+      The OK response indicates an information message from the server.
+      When tagged, it indicates successful completion of the associated
+      command.  The human-readable text may be presented to the user as
+      an information message.  The untagged form indicates an
+      information-only message; the nature of the information may be
+      indicated by a response code.
+
+      The untagged form is also used as one of three possible greetings
+      at session startup.  It indicates that the session is not yet
+      authenticated and that a LOGIN command is needed.
+
+   Example:    S: * OK IMAP4 server ready
+               C: A001 LOGIN fred blurdybloop
+               S: * OK [ALERT] System shutdown in 10 minutes
+               S: A001 OK LOGIN Completed
+
+
+7.1.2.  NO Response
+
+   Data:       optional response code
+               human-readable text
+
+      The NO response indicates an operational error message from the
+      server.  When tagged, it indicates unsuccessful completion of the
+      associated command.  The untagged form indicates a warning; the
+      command may still complete successfully.  The human-readable text
+      describes the condition.
+
+
+
+
+
+
+Crispin                                                        [Page 40]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+   Example:    C: A222 COPY 1:2 owatagusiam
+               S: * NO Disk is 98% full, please delete unnecessary data
+               S: A222 OK COPY completed
+               C: A222 COPY 3:200 blurdybloop
+               S: * NO Disk is 98% full, please delete unnecessary data
+               S: * NO Disk is 99% full, please delete unnecessary data
+               S: A222 NO COPY failed: disk is full
+
+
+7.1.3.  BAD Response
+
+   Data:       optional response code
+               human-readable text
+
+      The BAD response indicates an error message from the server.  When
+      tagged, it reports a protocol-level error in the client's command;
+      the tag indicates the command that caused the error.  The untagged
+      form indicates a protocol-level error for which the associated
+      command can not be determined; it may also indicate an internal
+      server failure.  The human-readable text describes the condition.
+
+   Example:    C: ...very long command line...
+               S: * BAD Command line too long
+               C: ...empty line...
+               S: * BAD Empty command line
+               C: A443 EXPUNGE
+               S: * BAD Disk crash, attempting salvage to a new disk!
+               S: * OK Salvage successful, no data lost
+               S: A443 OK Expunge completed
+
+
+7.1.4.  PREAUTH Response
+
+   Data:       optional response code
+               human-readable text
+
+      The PREAUTH response is always untagged, and is one of three
+      possible greetings at session startup.  It indicates that the
+      session has already been authenticated by external means and thus
+      no LOGIN command is needed.
+
+   Example:    S: * PREAUTH IMAP4 server ready and logged in as Smith
+
+
+
+
+
+
+
+
+
+Crispin                                                        [Page 41]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+7.1.5.  BYE Response
+
+   Data:       optional response code
+               human-readable text
+
+      The BYE response is always untagged, and indicates that the server
+      is about to close the connection.  The human-readable text may be
+      displayed to the user in a status report by the client.  The BYE
+      response may be sent as part of a normal logout sequence, or as a
+      panic shutdown announcement by the server.  It is also used by
+      some server implementations as an announcement of an inactivity
+      autologout.
+
+      This response is also used as one of three possible greetings at
+      session startup.  It indicates that the server is not willing to
+      accept a session from this client.
+
+   Example:    S: * BYE Autologout; idle for too long
+
+
+
+7.2.    Server Responses - Server and Mailbox Status
+
+   These responses are always untagged.  This is how server data are
+   transmitted from the server to the client, often as a result of a
+   command with the same name.
+
+7.2.1.  CAPABILITY Response
+
+   Data:       capability listing
+
+      The CAPABILITY response occurs as a result of a CAPABILITY
+      command.  The capability listing contains a space-separated
+      listing of capability names that the server supports.  The first
+      name in the capability listing MUST be the atom "IMAP4".
+
+      A capability name other than IMAP4 indicates that the server
+      supports an extension, revision, or amendment to the IMAP4
+      protocol.  Server responses MUST conform to this document until
+      the client issues a command that uses the associated capability.
+
+      Capability names MUST either begin with "X" or be standard or
+      standards-track IMAP4 extensions, revisions, or amendments
+      registered with IANA.  A server MUST NOT offer unregistered or
+      non-standard capability names, unless such names are prefixed with
+      an "X".
+
+
+
+
+
+Crispin                                                        [Page 42]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+      Client implementations SHOULD NOT require any capability name
+      other than "IMAP4", and MUST ignore any unknown capability names.
+
+   Example:    S: * CAPABILITY IMAP4 XPIG-LATIN
+
+
+7.2.2.  LIST Response
+
+   Data:       name attributes
+               hierarchy delimiter
+               name
+
+      The LIST response occurs as a result of a LIST command.  It
+      returns a single name that matches the LIST specification.  There
+      may be multiple LIST responses for a single LIST command.
+
+      Four name attributes are defined:
+
+      \Noinferiors   It is not possible for any child levels of
+                     hierarchy to exist under this name; no child levels
+                     exist now and none can be created in the future.
+
+      \Noselect      It is not possible to use this name as a selectable
+                     mailbox.
+
+      \Marked        The mailbox has been marked "interesting" by the
+                     server; the mailbox probably contains messages that
+                     have been added since the last time the mailbox was
+                     selected.
+
+      \Unmarked      The mailbox does not contain any additional
+                     messages since the last time the mailbox was
+                     selected.
+
+      If it is not feasible for the server to determine whether the
+      mailbox is "interesting" or not, or if the name is a \Noselect
+      name, the server should not send either \Marked or \Unmarked.
+
+      The hierarchy delimiter is a character used to delimit levels of
+      hierarchy in a mailbox name.  A client may use it to create child
+      mailboxes, and to search higher or lower levels of naming
+      hierarchy.  All children of a top-level hierarchy node must use
+      the same separator character.  A NIL hierarchy delimiter means
+      that no hierarchy exists; the name is a "flat" name.
+
+
+
+
+
+
+
+Crispin                                                        [Page 43]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+      The name represents an unambiguous left-to-right hierarchy, and
+      MUST be valid for use as a reference in LIST and LSUB commands.
+      Unless \Noselect is indicated, the name must also be valid as an
+      argument for commands, such as SELECT, that accept mailbox names.
+
+   Example:    S: * LIST (\Noselect) "/" ~/Mail/foo
+
+
+7.2.3.  LSUB Response
+
+   Data:       name attributes
+               hierarchy delimiter
+               name
+
+      The LSUB response occurs as a result of an LSUB command.  It
+      returns a single name that matches the LSUB specification.  There
+      may be multiple LSUB responses for a single LSUB command.  The
+      data is identical in format to the LIST response.
+
+   Example:    S: * LSUB () "." #news.comp.mail.misc
+
+
+7.2.4.  SEARCH Response
+
+   Data:       zero or more numbers
+
+      The SEARCH response occurs as a result of a SEARCH or UID SEARCH
+      command.  The number(s) refer to those messages that match the
+      search criteria.  For SEARCH, these are message sequence numbers;
+      for UID SEARCH, these are unique identifiers.  Each number is
+      delimited by a space.
+
+   Example:    S: * SEARCH 2 3 6
+
+
+7.2.5.  FLAGS Response
+
+   Data:       flag parenthesized list
+
+      The FLAGS response occurs as a result of a SELECT or EXAMINE
+      command.  The flag parenthesized list identifies the flags (at a
+      minimum, the system-defined flags) that are applicable for this
+      mailbox.  Flags other than the system flags may also exist,
+      depending on server implementation.
+
+      The update from the FLAGS response MUST be recorded by the client.
+
+   Example:    S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
+
+
+
+Crispin                                                        [Page 44]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+7.3.    Server Responses - Message Status
+
+   These responses are always untagged.  This is how message data are
+   transmitted from the server to the client, often as a result of a
+   command with the same name.  Immediately following the "*" token is a
+   number that represents either a message sequence number or a message
+   count.
+
+7.3.1.  EXISTS Response
+
+   Data:       none
+
+      The EXISTS response reports the number of messages in the mailbox.
+      This response occurs as a result of a SELECT or EXAMINE command,
+      and if the size of the mailbox changes (e.g. new mail).
+
+      The update from the EXISTS response MUST be recorded by the
+      client.
+
+   Example:    S: * 23 EXISTS
+
+
+7.3.2.  RECENT Response
+
+   Data:       none
+
+      The RECENT response reports the number of messages that have
+      arrived since the previous time a SELECT command was done on this
+      mailbox.  This response occurs as a result of a SELECT or EXAMINE
+      command, and if the size of the mailbox changes (e.g. new mail).
+
+      The update from the RECENT response MUST be recorded by the
+      client.
+
+   Example:    S: * 5 RECENT
+
+
+7.3.3.  EXPUNGE Response
+
+   Data:       none
+
+      The EXPUNGE response reports that the specified message sequence
+      number has been permanently removed from the mailbox.  The message
+      sequence number for each successive message in the mailbox is
+      immediately decremented by 1, and this decrement is reflected in
+      message sequence numbers in subsequent responses (including other
+      untagged EXPUNGE responses).
+
+
+
+
+Crispin                                                        [Page 45]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+      As a result of the immediate decrement rule, message sequence
+      numbers that appear in a set of successive EXPUNGE responses
+      depend upon whether the messages are removed starting from lower
+      numbers to higher numbers, or from higher numbers to lower
+      numbers.  For example, if the last 5 messages in a 9-message
+      mailbox are expunged; a "lower to higher" server will send five
+      untagged EXPUNGE responses for message sequence number 5, whereas
+      a "higher to lower server" will send successive untagged EXPUNGE
+      responses for message sequence numbers 9, 8, 7, 6, and 5.
+
+      An EXPUNGE response MUST NOT be sent when no command is in
+      progress; nor while responding to a FETCH, STORE, or SEARCH
+      command.  This rule is necessary to prevent a loss of
+      synchronization of message sequence numbers between client and
+      server.
+
+      The update from the EXPUNGE response MUST be recorded by the
+      client.
+
+   Example:    S: * 44 EXPUNGE
+
+
+7.3.4.  FETCH Response
+
+   Data:       message data
+
+      The FETCH response returns data about a message to the client.
+      The data are pairs of data item names and their values in
+      parentheses.  This response occurs as the result of a FETCH or
+      STORE command, as well as by unilateral server decision (e.g. flag
+      updates).
+
+      The current data items are:
+
+      BODY           A form of BODYSTRUCTURE without extension data.
+
+      BODY[section]  A string expressing the body contents of the
+                     specified section.  The string should be
+                     interpreted by the client according to the content
+                     transfer encoding, body type, and subtype.
+
+                     8-bit textual data is permitted if a character set
+                     identifier is part of the body parameter
+                     parenthesized list for this section.
+
+                     Non-textual data such as binary data must be
+                     transfer encoded into a textual form such as BASE64
+                     prior to being sent to the client.  To derive the
+
+
+
+Crispin                                                        [Page 46]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+                     original binary data, the client must decode the
+                     transfer encoded string.
+
+      BODYSTRUCTURE  A parenthesized list that describes the body
+                     structure of a message.  This is computed by the
+                     server by parsing the [RFC-822] header and body
+                     into the component parts, defaulting various fields
+                     as necessary.
+
+                     Multiple parts are indicated by parenthesis
+                     nesting.  Instead of a body type as the first
+                     element of the parenthesized list there is a nested
+                     body.  The second element of the parenthesized list
+                     is the multipart subtype (mixed, digest, parallel,
+                     alternative, etc.).
+
+                     Extension data follows the multipart subtype.
+                     Extension data is never returned with the BODY
+                     fetch, but may be returned with a BODYSTRUCTURE
+                     fetch.  Extension data, if present, must be in the
+                     defined order.
+
+                     The extension data of a multipart body part are in
+                     the following order:
+
+                     body parameter parenthesized list
+                        A parenthesized list of attribute/value pairs
+                        [e.g. (foo bar baz rag) where "bar" is the value
+                        of "foo" and "rag" is the value of "baz"] as
+                        defined in [MIME-1].
+
+                     Any following extension data are not yet defined in
+                     this version of the protocol.  Such extension data
+                     may consist of zero or more NILs, strings, numbers,
+                     or potentially nested parenthesized lists of such
+                     data.  Client implementations that do a
+                     BODYSTRUCTURE fetch MUST be prepared to accept such
+                     extension data.  Server implementations MUST NOT
+                     send such extension data until it has been defined
+                     by a revision of this protocol.
+
+                     The basic fields of a non-multipart body part are
+                     in the following order:
+
+                     body type
+                        A string giving the content type name as defined
+                        in [MIME-1].
+
+
+
+
+Crispin                                                        [Page 47]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+                     body subtype
+                        A string giving the content subtype name as
+                        defined in [MIME-1].
+
+                     body parameter parenthesized list
+                        A parenthesized list of attribute/value pairs
+                        [e.g. (foo bar baz rag) where "bar" is the value
+                        of "foo" and "rag" is the value of "baz"] as
+                        defined in [MIME-1].
+
+                     body id
+                        A string giving the content id as defined in
+                        [MIME-1].
+
+                     body description
+                        A string giving the content description as
+                        defined in [MIME-1].
+
+                     body encoding
+                        A string giving the content transfer encoding as
+                        defined in [MIME-1].
+
+                     body size
+                        A number giving the size of the body in octets.
+                        Note that this size is the size in its transfer
+                        encoding and not the resulting size after any
+                        decoding.
+
+                     A body type of type MESSAGE and subtype RFC822
+                     contains, immediately after the basic fields, the
+                     envelope structure, body structure, and size in
+                     text lines of the encapsulated message.
+
+                     A body type of type TEXT contains, immediately
+                     after the basic fields, the size of the body in
+                     text lines.  Note that this size is the size in its
+                     transfer encoding and not the resulting size after
+                     any decoding.
+
+                     Extension data follows the basic fields and the
+                     type-specific fields listed above.  Extension data
+                     is never returned with the BODY fetch, but may be
+                     returned with a BODYSTRUCTURE fetch.  Extension
+                     data, if present, must be in the defined order.
+
+                     The extension data of a non-multipart body part are
+                     in the following order:
+
+
+
+
+Crispin                                                        [Page 48]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+                     body MD5
+                        A string giving the content MD5 value as defined
+                        in [MIME-1].
+
+                     Any following extension data are not yet defined in
+                     this version of the protocol, and would be as
+                     described above under multipart extension data.
+
+      ENVELOPE       A parenthesized list that describes the envelope
+                     structure of a message.  This is computed by the
+                     server by parsing the [RFC-822] header into the
+                     component parts, defaulting various fields as
+                     necessary.
+
+                     The fields of the envelope structure are in the
+                     following order: date, subject, from, sender,
+                     reply-to, to, cc, bcc, in-reply-to, and message-id.
+                     The date, subject, in-reply-to, and message-id
+                     fields are strings.  The from, sender, reply-to,
+                     to, cc, and bcc fields are parenthesized lists of
+                     address structures.
+
+                     An address structure is a parenthesized list that
+                     describes an electronic mail address.  The fields
+                     of an address structure are in the following order:
+                     personal name, [SMTP] at-domain-list (source
+                     route), mailbox name, and host name.
+
+                     [RFC-822] group syntax is indicated by a special
+                     form of address structure in which the host name
+                     field is NIL.  If the mailbox name field is also
+                     NIL, this is an end of group marker (semi-colon in
+                     RFC 822 syntax).  If the mailbox name field is
+                     non-NIL, this is a start of group marker, and the
+                     mailbox name field holds the group name phrase.
+
+                     Any field of an envelope or address structure that
+                     is not applicable is presented as NIL.  Note that
+                     the server must default the reply-to and sender
+                     fields from the from field; a client is not
+                     expected to know to do this.
+
+
+
+
+
+
+
+
+
+
+Crispin                                                        [Page 49]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+      FLAGS          A parenthesized list of flags that are set for this
+                     message.  This may include keywords as well as the
+                     following system flags:
+
+                     \Seen       Message has been read
+
+                     \Answered   Message has been answered
+
+                     \Flagged    Message is "flagged" for urgent/special
+                                 attention
+
+                     \Deleted    Message is "deleted" for removal by
+                                 later EXPUNGE
+
+                     \Draft      Message has not completed composition
+                                 (marked as a draft).
+
+                     as well as the following special flag, which may be
+                     fetched but not stored:
+
+                     \Recent     Message has arrived since the previous
+                                 time this mailbox was selected.
+
+      INTERNALDATE   A string containing the date and time of final
+                     delivery of the message as defined by [SMTP].
+
+      RFC822         A string expressing the message in [RFC-822]
+                     format.  The header portion of the message must be
+                     7-bit.  8-bit characters are permitted only in the
+                     non-header portion of the message only if there are
+                     [MIME-1] data in the message that identify the
+                     character set of the message.
+
+      RFC822.HEADER  A string expressing the [RFC-822] format header of
+                     the message, including the delimiting blank line
+                     between the header and the body.  The entire string
+                     must be 7-bit; 8-bit characters are not permitted
+                     in headers.  RFC822.HEADER is used to return data
+                     for the RFC822.HEADER, RFC822.HEADER.LINES, and
+                     RFC822.HEADER.LINES.NOT FETCH data items.  Note
+                     that a blank line is always included regardless of
+                     header line restrictions.
+
+      RFC822.SIZE    A number expressing the number of octets in the
+                     message in [RFC-822] format.
+
+
+
+
+
+
+Crispin                                                        [Page 50]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+      RFC822.TEXT    A string expressing the text body of the message,
+                     omitting the [RFC-822] header.  8-bit characters
+                     are permitted only if there are [MIME-1] data in
+                     the message that identify the character set of the
+                     message.
+
+      UID            A number expressing the unique identifier of the
+                     message.
+
+
+   Example:    S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827)
+
+
+7.3.5.  Obsolete Responses
+
+   In addition to the responses listed in here, client implementations
+   MUST accept and implement the obsolete responses described in
+   Appendix B.
+
+
+
+7.4.    Server Responses - Command Continuation Request
+
+   The command completion request response is indicated by a "+" token
+   instead of a tag.  This form of response indicates that the server is
+   ready to accept the continuation of a command from the client.  The
+   remainder of this response is a line of text.
+
+   This response is used in the AUTHORIZATION command to transmit server
+   data to the client, and request additional client data.  This
+   response is also used if an argument to any command is a literal.
+
+   The client is not permitted to send the octets of the literal unless
+   the server indicates that it expects it.  This permits the server to
+   process commands and reject errors on a line-by-line basis.  The
+   remainder of the command, including the CRLF that terminates a
+   command, follows the octets of the literal.  If there are any
+   additional command arguments the literal octets are followed by a
+   space and those arguments.
+
+   Example:    C: A001 LOGIN {11}
+               S: + Ready for additional command text
+               C: FRED FOOBAR {7}
+               S: + Ready for additional command text
+               C: fat man
+               S: A001 OK LOGIN completed
+               C: A044 BLURDYBLOOP {102856}
+               S: A044 BAD No such command as "BLURDYBLOOP"
+
+
+
+Crispin                                                        [Page 51]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+8.      Sample IMAP4 session
+
+   The following is a transcript of an IMAP4 session.  A long line in
+   this sample is broken for editorial clarity.
+
+   S:   * OK IMAP4 Service Ready
+   C:   a001 login mrc secret
+   S:   a001 OK LOGIN completed
+   C:   a002 select inbox
+   S:   * 18 EXISTS
+   S:   * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
+   S:   * 2 RECENT
+   S:   * OK [UNSEEN 17] Message 17 is the first unseen message
+   S:   * OK [UIDVALIDITY 3857529045] UIDs valid
+   S:   a002 OK [READ-WRITE] SELECT completed
+   C:   a003 fetch 12 full
+   S:   * 12 FETCH (FLAGS (\Seen) INTERNALDATE "14-Jul-1993 02:44:25 -0700"
+         RFC822.SIZE 4282 ENVELOPE ("Wed, 14 Jul 1993 02:23:25 -0700 (PDT)"
+         "IMAP4 WG mtg summary and minutes"
+         (("Terry Gray" NIL "gray" "cac.washington.edu"))
+         (("Terry Gray" NIL "gray" "cac.washington.edu"))
+         (("Terry Gray" NIL "gray" "cac.washington.edu"))
+         ((NIL NIL "imap" "cac.washington.edu"))
+         ((NIL NIL "minutes" "CNRI.Reston.VA.US")
+         ("John Klensin" NIL "KLENSIN" "INFOODS.MIT.EDU")) NIL NIL
+         "<B27397-0100000@cac.washington.edu>")
+          BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028 92))
+   S:    a003 OK FETCH completed
+   C:    a004 fetch 12 rfc822.header
+   S:    * 12 FETCH (RFC822.HEADER {346}
+   S:    Date: Wed, 14 Jul 1993 02:23:25 -0700 (PDT)
+   S:    From: Terry Gray <gray@cac.washington.edu>
+   S:    Subject: IMAP4 WG mtg summary and minutes
+   S:    To: imap@cac.washington.edu
+   S:    cc: minutes@CNRI.Reston.VA.US, John Klensin <KLENSIN@INFOODS.MIT.EDU>
+   S:    Message-Id: <B27397-0100000@cac.washington.edu>
+   S:    MIME-Version: 1.0
+   S:    Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
+   S:
+   S:    )
+   S:    a004 OK FETCH completed
+   C:    a005 store 12 +flags \deleted
+   S:    * 12 FETCH (FLAGS (\Seen \Deleted))
+   S:    a005 OK +FLAGS completed
+   C:    a006 logout
+   S:    * BYE IMAP4 server terminating connection
+   S:    a006 OK LOGOUT completed
+
+
+
+
+Crispin                                                        [Page 52]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+9.      Formal Syntax
+
+   The following syntax specification uses the augmented Backus-Naur
+   Form (BNF) notation as specified in [RFC-822] with one exception; the
+   delimiter used with the "#" construct is a single space (SPACE) and
+   not a comma.
+
+   Except as noted otherwise, all alphabetic characters are
+   case-insensitive.  The use of upper or lower case characters to
+   define token strings is for editorial clarity only.  Implementations
+   MUST accept these strings in a case-insensitive fashion.
+
+   Syntax marked as obsolete may be encountered with implementations
+   written for an earlier version of this protocol (e.g. IMAP2).  New
+   implementations SHOULD accept obsolete syntax as input, but MUST NOT
+   otherwise use such syntax.
+
+   address         ::= "(" addr_name SPACE addr_adl SPACE addr_mailbox
+                       SPACE addr_host ")"
+
+   addr_adl        ::= nstring
+
+   addr_host       ::= nstring
+                       ;; NIL indicates [RFC-822] group syntax
+
+   addr_mailbox    ::= nstring
+                       ;; NIL indicates end of [RFC-822] group; if
+                       ;; non-NIL and addr_host is NIL, holds
+                       ;; [RFC-822] group name
+
+   addr_name       ::= nstring
+
+   alpha           ::= "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" /
+                       "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" /
+                       "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" /
+                       "Y" / "Z" /
+                       "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" /
+                       "i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" /
+                       "q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" /
+                       "y" / "z" /
+                       ;; Case-sensitive
+
+   append          ::= "APPEND" SPACE mailbox [SPACE flag_list]
+                       [SPACE date_time] SPACE literal
+
+   astring         ::= atom / string
+
+
+
+
+
+Crispin                                                        [Page 53]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+   atom            ::= 1*ATOM_CHAR
+
+   ATOM_CHAR       ::= <any CHAR except atom_specials>
+
+   atom_specials   ::= "(" / ")" / "{" / SPACE / CTLs / list_wildcards /
+                       quoted_specials
+
+   authenticate    ::= "AUTHENTICATE" SPACE auth_type *(CRLF base64)
+
+   auth_type       ::= atom
+
+   base64          ::= *(4base64_char) [base64_terminal]
+
+   base64_char     ::= alpha / digit / "+" / "/"
+
+   base64_terminal ::= (2base64_char "==") / (3base64_char "=")
+
+   body            ::= "(" body_type_1part / body_type_mpart ")"
+
+   body_extension  ::= nstring / number / "(" 1#body_extension ")"
+                       ;; Future expansion.  Client implementations
+                       ;; MUST accept body_extension fields.  Server
+                       ;; implementations MUST NOT generate
+                       ;; body_extension fields except as defined by
+                       ;; future standard or standards-track
+                       ;; revisions of this specification.
+
+   body_ext_1part  ::= body_fld_md5 [SPACE 1#body_extension]
+                       ;; MUST NOT be returned on non-extensible
+                       ;; "BODY" fetch
+
+   body_ext_mpart  ::= body_fld_param [SPACE 1#body_extension]]
+                       ;; MUST NOT be returned on non-extensible
+                       ;; "BODY" fetch
+
+   body_fields     ::= body_fld_param SPACE body_fld_id SPACE
+                       body_fld_desc SPACE body_fld_enc SPACE
+                       body_fld_octets
+
+   body_fld_desc   ::= nstring
+
+   body_fld_enc    ::= (<"> ("7BIT" / "8BIT" / "BINARY" / "BASE64"/
+                       "QUOTED-PRINTABLE") <">) / string
+
+   body_fld_id     ::= nstring
+
+   body_fld_lines  ::= number
+
+
+
+
+Crispin                                                        [Page 54]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+   body_fld_md5    ::= nstring
+
+   body_fld_octets ::= number
+
+   body_fld_param  ::= "(" 1#(string string) ")" / nil
+
+   body_fld_subtyp ::= string
+
+   body_type_1part ::= (body_type_basic / body_type_msg / body_type_text)
+                       [SPACE body_ext_1part]
+
+   body_type_basic ::= (<"> ("APPLICATION" / "AUDIO" / "IMAGE" /
+                       "MESSAGE" / "VIDEO") <">) / string) SPACE
+                       body_fld_subtyp SPACE body_fields
+                       ;; MESSAGE subtype MUST NOT be "RFC822"
+
+   body_type_mpart ::= 1*body SPACE body_fld_subtyp
+                       [SPACE body_ext_mpart]
+
+   body_type_msg   ::= <"> "MESSAGE" <"> SPACE <"> "RFC822" <"> SPACE
+                       body_fields SPACE envelope SPACE body SPACE
+                       body_fld_lines
+
+   body_type_text  ::= <"> "TEXT" <"> SPACE body_fld_subtyp SPACE
+                        body_fields SPACE body_fld_lines
+
+   capability      ::= atom
+                       ;; Must begin with "X" or be registered with
+                       ;; IANA as standard or standards-track
+
+   capability_data ::= "CAPABILITY" SPACE "IMAP4" [SPACE 1#capability]
+
+   CHAR            ::= <any 7-bit US-ASCII character except NUL,
+                        0x01 - 0x7f>
+
+   CHAR8           ::= <any 8-bit octet except NUL, 0x01 - 0xff>
+
+   command         ::= tag SPACE (command_any / command_auth /
+                       command_nonauth / command_select) CRLF
+                       ;; Modal based on state
+
+   command_any     ::= "CAPABILITY" / "LOGOUT" / "NOOP" / x_command
+                       ;; Valid in all states
+
+   command_auth    ::= append / create / delete / examine / find / list /
+                       lsub / rename / select / subscribe / unsubscribe /
+                       ;; Valid only in Authenticated or Selected state
+
+
+
+
+Crispin                                                        [Page 55]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+   command_nonauth ::= login / authenticate
+                       ;; Valid only when in Non-Authenticated state
+
+   command_select  ::= "CHECK" / "CLOSE" / "EXPUNGE" /
+                        copy / fetch / partial / store / uid / search
+                       ;; Valid only when in Selected state
+
+   continue_req    ::= "+" SPACE (resp_text / base64)
+
+   copy            ::= "COPY" SPACE set SPACE mailbox
+
+   CR              ::= <ASCII CR, carriage return, 0x0C>
+
+   create          ::= "CREATE" SPACE mailbox
+                       ;; Use of INBOX gives a NO error
+
+   CRLF            ::= CR LF
+
+   CTL             ::= <any ASCII control character and DEL,
+                        0x00 - 0x1f, 0x7f>
+
+   date            ::= date_text / <"> date_text <">
+
+   date_day        ::= 1*2digit
+                       ;; Day of month
+
+   date_day_fixed  ::= (SPACE digit) / 2digit
+                       ;; Fixed-format version of date_day
+
+   date_month      ::= "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" /
+                       "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec"
+
+   date_text       ::= date_day "-" date_month "-" (date_year /
+                       date_year_old)
+
+   date_year       ::= 4digit
+
+   date_year_old   ::= 2digit
+                       ;; OBSOLETE, (year - 1900)
+
+   date_time       ::= <"> (date_time_new / date_time_old) <">
+
+   date_time_new   ::= date_day_fixed "-" date_month "-" date_year
+                       SPACE time SPACE zone
+
+   date_time_old   ::= date_day_fixed "-" date_month "-" date_year_old
+                       SPACE time "-" zone_old
+                       ;; OBSOLETE
+
+
+
+Crispin                                                        [Page 56]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+   delete          ::= "DELETE" SPACE mailbox
+                       ;; Use of INBOX gives a NO error
+
+   digit           ::= "0" / digit_nz
+
+   digit_nz        ::= "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" /
+                       "9"
+
+   envelope        ::= "(" env_date SPACE env_subject SPACE env_from
+                       SPACE env_sender SPACE env_reply-to SPACE env_to
+                       SPACE env_cc SPACE env_bcc SPACE env_in-reply-to
+                       SPACE env_message-id ")"
+
+   env_bcc         ::= "(" 1*address ")" / nil
+
+   env_cc          ::= "(" 1*address ")" / nil
+
+   env_date        ::= nstring
+
+   env_from        ::= "(" 1*address ")" / nil
+
+   env_in-reply-to ::= nstring
+
+   env_message-id  ::= nstring
+
+   env_reply-to    ::= "(" 1*address ")" / nil
+
+   env_sender      ::= "(" 1*address ")" / nil
+
+   env_subject     ::= nstring
+
+   env_to          ::= "(" 1*address ")" / nil
+
+   examine         ::= "EXAMINE" SPACE mailbox
+
+   fetch           ::= "FETCH" SPACE set SPACE ("ALL" / "FULL" /
+                       "FAST" / fetch_att / "(" 1#fetch_att ")")
+
+   fetch_att       ::= "BODY" / "BODYSTRUCTURE" /
+                       "BODY" [".PEEK"] "[" section "]" / "ENVELOPE" /
+                       "FLAGS" / "INTERNALDATE" / "UID" /
+                       "RFC822" (([".TEXT"] [".PEEK"]) / ".SIZE" /
+                       (".HEADER" [".LINES" [".NOT"] SPACE header_list])
+
+   find            ::= "FIND" SPACE ["ALL."] "MAILBOXES" SPACE
+                       list_mailbox
+                       ;; OBSOLETE
+
+
+
+
+Crispin                                                        [Page 57]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+   flag            ::= "\Answered" / "\Flagged" / "\Deleted" /
+                       "\Seen" / "\Draft" / flag_keyword  /
+                       flag_extension
+
+   flag_extension  ::= "\" atom
+                       ;; Future expansion.  Client implementations
+                       ;; MUST accept flag_extension flags.  Server
+                       ;; implementations MUST NOT generate
+                       ;; flag_extension flags except as defined by
+                       ;; future standard or standards-track
+                       ;; revisions of this specification.
+
+   flag_keyword    ::= atom
+
+   flag_list       ::= "(" #flag ")"
+
+   greeting        ::= "*" SPACE (resp_cond_auth / resp_cond_bye) CRLF
+
+   header_line     ::= astring
+
+   header_list     ::= "(" 1#header_line ")"
+
+   LF              ::= <ASCII LF, line feed, 0x0A>
+
+   list            ::= "LIST" SPACE mailbox SPACE list_mailbox
+
+   list_mailbox    ::= 1*(ATOM_CHAR / list_wildcards) / string
+
+   list_wildcards  ::= "%" / "*"
+
+   literal         ::= "{" number "}" CRLF *CHAR8
+                       ;; Number represents the number of CHAR8 octets
+
+   login           ::= "LOGIN" SPACE userid SPACE password
+
+   lsub            ::= "LSUB" SPACE mailbox SPACE list_mailbox
+
+   mailbox         ::= "INBOX" / astring
+                       ;; INBOX is case-insensitive; other names may be
+                       ;; case-sensitive depending on implementation.
+
+   mailbox_data    ::=  "FLAGS" SPACE flag_list /
+                        "LIST" SPACE mailbox_list /
+                        "LSUB" SPACE mailbox_list /
+                        "MAILBOX" SPACE text /
+                        "SEARCH" [SPACE 1#nz_number] /
+                        number SPACE "EXISTS" / number SPACE "RECENT"
+
+
+
+
+Crispin                                                        [Page 58]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+   mailbox_list    ::= "(" #("\Marked" / "\Noinferiors" /
+                       "\Noselect" / "\Unmarked" / flag_extension) ")"
+                       SPACE (<"> QUOTED_CHAR <"> / nil) SPACE mailbox
+
+   message_data    ::= nz_number SPACE ("EXPUNGE" /
+                       ("FETCH" SPACE msg_fetch) / msg_obsolete)
+
+   msg_fetch       ::= "(" 1#("BODY" SPACE body /
+                       "BODYSTRUCTURE" SPACE body /
+                       "BODY[" section "]" SPACE nstring /
+                       "ENVELOPE" SPACE envelope /
+                       "FLAGS" SPACE "(" #(flag / "\Recent") ")" /
+                       "INTERNALDATE" SPACE date_time /
+                       "RFC822" [".HEADER" / ".TEXT"] SPACE nstring /
+                       "RFC822.SIZE" SPACE number /
+                       "UID" SPACE uniqueid) ")"
+
+   msg_obsolete    ::= "COPY" / ("STORE" SPACE msg_fetch)
+                       ;; OBSOLETE untagged data responses
+
+   nil             ::= "NIL"
+
+   nstring         ::= string / nil
+
+   number          ::= 1*digit
+                       ;; Unsigned 32-bit integer
+                       ;; (0 <= n < 4,294,967,296)
+
+   nz_number       ::= digit_nz *digit
+                       ;; Non-zero unsigned 32-bit integer
+                       ;; (0 < n < 4,294,967,296)
+
+   partial         ::= "PARTIAL" SPACE nz_number SPACE
+                       ("BODY" [".PEEK"] "[" section "]" /
+                       "RFC822" (([".TEXT"] [".PEEK"]) / ".HEADER")
+                       SPACE number SPACE number
+
+   password        ::= astring
+
+   quoted          ::= <"> *QUOTED_CHAR <">
+
+   QUOTED_CHAR     ::= <any TEXT_CHAR except quoted_specials> /
+                       "\" quoted_specials
+
+   quoted_specials ::= <"> / "\"
+
+   rename          ::= "RENAME" SPACE mailbox SPACE mailbox
+                       ;; Use of INBOX as a destination gives a NO error
+
+
+
+Crispin                                                        [Page 59]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+   response        ::= *response_data response_done
+
+   response_data   ::= "*" SPACE (resp_cond_state / resp_cond_bye /
+                       mailbox_data / message_data / capability_data)
+                       CRLF
+
+   response_done   ::= response_tagged / response_fatal
+
+   response_fatal  ::= "*" SPACE resp_cond_bye CRLF
+
+   response_tagged ::= tag SPACE resp_cond_state CRLF
+
+   resp_cond_auth  ::= ("OK" / "PREAUTH") SPACE resp_text
+                       ;; Authentication condition
+
+   resp_cond_bye   ::= "BYE" SPACE resp_text
+                       ;; Server will disconnect condition
+
+   resp_cond_state ::= ("OK" / "NO" / "BAD") SPACE resp_text
+                       ;; Status condition
+
+   resp_text       ::= ["[" resp_text_code "]" SPACE] (text_mime2 / text)
+
+   resp_text_code  ::= "ALERT" / "PARSE" /
+                       "PERMANENTFLAGS" SPACE "(" #(flag / "\*") ")" /
+                       "READ-ONLY" / "READ-WRITE" / "TRYCREATE" /
+                       "UIDVALIDITY" SPACE nz_number /
+                       "UNSEEN" SPACE nz_number /
+                       atom [SPACE 1*<any TEXT_CHAR except "]">]
+
+   search          ::= "SEARCH" SPACE ["CHARSET" SPACE astring SPACE]
+                       search_criteria
+                       ;; Character set must be registered with IANA
+                       ;; as a MIME character set
+
+   search_criteria ::= 1#search_key
+
+   search_key      ::= search_new / search_old
+
+   search_new      ::= "DRAFT" /
+                       "HEADER" SPACE header_line SPACE astring /
+                       "LARGER" SPACE number / "NOT" SPACE search_key /
+                       "OR" SPACE search_key SPACE search_key /
+                       "SENTBEFORE" SPACE date / "SENTON" SPACE date /
+                       "SENTSINCE" SPACE date / "SMALLER" SPACE number /
+                       "UID" SPACE set / "UNDRAFT" / set /
+                       "(" search_criteria ")"
+                       ;; New in IMAP4
+
+
+
+Crispin                                                        [Page 60]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+   search_old      ::= "ALL" / "ANSWERED" / "BCC" SPACE astring /
+                       "BEFORE" SPACE date / "BODY" SPACE astring /
+                       "CC" SPACE astring / "DELETED" / "FLAGGED" /
+                       "FROM" SPACE astring /
+                       "KEYWORD" SPACE flag_keyword / "NEW" / "OLD" /
+                       "ON" SPACE date / "RECENT" / "SEEN" /
+                       "SINCE" SPACE date / "SUBJECT" SPACE astring /
+                       "TEXT" SPACE astring / "TO" SPACE astring /
+                       "UNANSWERED" / "UNDELETED" / "UNFLAGGED" /
+                       "UNKEYWORD" SPACE flag_keyword / "UNSEEN"
+                       ;; Defined in [IMAP2]
+
+   section         ::= "0" / nz_number ["." section]
+
+   select          ::= "SELECT" SPACE mailbox
+
+   sequence_num    ::= nz_number / "*"
+                       ;; * is the largest number in use.  For message
+                       ;; sequence numbers, it is the number of messages
+                       ;; in the mailbox.  For unique identifiers, it is
+                       ;; the unique identifier of the last message in
+                       ;; the mailbox.
+
+   set             ::= sequence_num / (sequence_num ":" sequence_num) /
+                       (set "," set)
+                       ;; Identifies a set of messages.  For message
+                       ;; sequence numbers, these are consecutive
+                       ;; numbers from 1 to the number of messages in
+                       ;; the mailbox
+                       ;; Comma delimits individual numbers, colon
+                       ;; delimits between two numbers inclusive.
+                       ;; Example: 2,4:7,9,12:* is 2,4,5,6,7,9,12,13,
+                       ;; 14,15 for a mailbox with 15 messages.
+
+   SPACE           ::= <ASCII SP, space, 0x20>
+
+   store           ::= "STORE" SPACE set SPACE store_att_flags
+
+   store_att_flags ::= (["+" / "-"] "FLAGS" [".SILENT"]) SPACE
+                       (flag_list / #flag)
+
+   string          ::= quoted / literal
+
+   subscribe       ::= ("SUBSCRIBE" SPACE mailbox) / subscribe_obs
+
+   subscribe_obs   ::= "SUBSCRIBE" SPACE "MAILBOX" SPACE mailbox
+                       ;;OBSOLETE
+
+
+
+
+Crispin                                                        [Page 61]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+   tag             ::= 1*<any ATOM_CHAR except "+">
+
+   text            ::= 1*TEXT_CHAR
+
+   text_mime2       ::= "=?" <charset> "?" <encoding> "?"
+                        <encoded-text> "?="
+                        ;; Syntax defined in [MIME-2]
+
+   TEXT_CHAR       ::= <any CHAR except CR and LF>
+
+   time            ::= 2digit ":" 2digit ":" 2digit
+                       ;; Hours minutes seconds
+
+   uid             ::= "UID" SPACE (copy / fetch / search / store)
+                       ;; Unique identifiers used instead of message
+                       ;; sequence numbers
+
+   uniqueid        ::= nz_number
+                       ;; Strictly ascending
+
+   unsubscribe     ::= ("UNSUBSCRIBE" SPACE mailbox) / unsubscribe_obs
+
+   unsubscribe_obs ::= "UNSUBSCRIBE" SPACE "MAILBOX" SPACE mailbox
+                       ;;OBSOLETE
+
+   userid          ::= astring
+
+   x_command       ::= "X" atom <experimental command arguments>
+
+   zone            ::= ("+" / "-") 4digit
+                       ;; Signed four-digit value of hhmm representing
+                       ;; hours and minutes west of Greenwich (that is,
+                       ;; (the amount that the given time differs from
+                       ;; Universal Time).  Subtracting the timezone
+                       ;; from the given time will give the UT form.
+                       ;; The Universal Time zone is "+0000".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                                                        [Page 62]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+   zone_old        ::= "UT" / "GMT" / "Z" /                ;; +0000
+                       "AST" / "EDT" /                     ;; -0400
+                       "EST" / "CDT" /                     ;; -0500
+                       "CST" / "MDT" /                     ;; -0600
+                       "MST" / "PDT" /                     ;; -0700
+                       "PST" / "YDT" /                     ;; -0800
+                       "YST" / "HDT" /                     ;; -0900
+                       "HST" / "BDT" /                     ;; -1000
+                       "BST" /                             ;; -1100
+                       "A" / "B" / "C" / "D" / "E" / "F" / ;; +1 to +6
+                       "G" / "H" / "I" / "K" / "L" / "M" / ;; +7 to +12
+                       "N" / "O" / "P" / "Q" / "R" / "S" / ;; -1 to -6
+                       "T" / "U" / "V" / "W" / "X" / "Y"   ;; -7 to -12
+                       ;; OBSOLETE
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                                                        [Page 63]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+10.     Author's Note
+
+   This document is a revision or rewrite of earlier documents, and
+   supercedes the protocol specification in those documents: IMAP4
+   Internet drafts, the IMAP2bis Internet drafts, unpublished
+   IMAP2bis.TXT document, RFC 1176, and RFC 1064.
+
+
+11.     Security Considerations
+
+   IMAP4 protocol transactions, including electronic mail data, are sent
+   in the clear over the network unless the optional privacy protection
+   is negotiated in the AUTHENTICATE command.
+
+   A server error message for an AUTHENTICATE command which fails due to
+   invalid credentials should not detail why the credentials are
+   invalid.
+
+   Use of the LOGIN command sends passwords in the clear.  This can be
+   avoided by using the AUTHENTICATE command instead.
+
+   A server error message for a failing LOGIN command should not specify
+   that the user name, as opposed to the password, is invalid.
+
+   Additional security considerations are discussed in the section
+   discussing the AUTHENTICATE and LOGIN commands.
+
+
+12.     Author's Address
+
+   Mark R. Crispin
+   Networks and Distributed Computing, JE-30
+   University of Washington
+   Seattle, WA  98195
+
+   Phone: (206) 543-5762
+
+   EMail: MRC@CAC.Washington.EDU
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                                                        [Page 64]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+Appendices
+
+A.      Obsolete Commands
+
+   The following commands are OBSOLETE.  It is NOT required to support
+   any of these commands in new server implementations.  These commands
+   are documented here for the benefit of implementors who may wish to
+   support them for compatibility with old client implementations.
+
+   The section headings of these commands are intended to correspond
+   with where they would be located in the main document if they were
+   not obsoleted.
+
+
+A.6.3.OBS.1.    FIND ALL.MAILBOXES Command
+
+   Arguments:  mailbox name with possible wildcards
+
+   Data:       untagged responses: MAILBOX
+
+   Result:     OK - find completed
+               NO - find failure: can't list that name
+               BAD - command unknown or arguments invalid
+
+      The FIND ALL.MAILBOXES command returns a subset of names from the
+      complete set of all names available to the user.  It returns zero
+      or more untagged MAILBOX replies.  The mailbox argument to FIND
+      ALL.MAILBOXES is similar to that for LIST with an empty reference,
+      except that the characters "%" and "?" match a single character.
+
+   Example:    C: A002 FIND ALL.MAILBOXES *
+               S: * MAILBOX blurdybloop
+               S: * MAILBOX INBOX
+               S: A002 OK FIND ALL.MAILBOXES completed
+
+
+A.6.3.OBS.2.    FIND MAILBOXES Command
+
+   Arguments:  mailbox name with possible wildcards
+
+   Data:       untagged responses: MAILBOX
+
+   Result:     OK - find completed
+               NO - find failure: can't list that name
+               BAD - command unknown or arguments invalid
+
+      The FIND MAILBOXES command returns a subset of names from the set
+      of names that the user has declared as being "active" or
+
+
+
+Crispin                                                        [Page 65]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+      "subscribed".  It returns zero or more untagged MAILBOX replies.
+      The mailbox argument to FIND MAILBOXES is similar to that for LSUB
+      with an empty reference, except that the characters "%" and "?"
+      match a single character.
+
+   Example:    C: A002 FIND MAILBOXES *
+               S: * MAILBOX blurdybloop
+               S: * MAILBOX INBOX
+               S: A002 OK FIND MAILBOXES completed
+
+
+A.6.3.OBS.3.    SUBSCRIBE MAILBOX Command
+
+   Arguments:  mailbox name
+
+   Data:       no specific data for this command
+
+   Result:     OK - subscribe completed
+               NO - subscribe failure: can't subscribe to that name
+               BAD - command unknown or arguments invalid
+
+      The SUBSCRIBE MAILBOX command is identical in effect to the
+      SUBSCRIBE command.  A server which implements this command must be
+      able to distinguish between a SUBSCRIBE MAILBOX command and a
+      SUBSCRIBE command with a mailbox name argument of "MAILBOX".
+
+   Example:    C: A002 SUBSCRIBE MAILBOX #news.comp.mail.mime
+               S: A002 OK SUBSCRIBE MAILBOX to #news.comp.mail.mime
+               completed
+               C: A003 SUBSCRIBE MAILBOX
+               S: A003 OK SUBSCRIBE to MAILBOX completed
+
+
+A.6.3.OBS.4.    UNSUBSCRIBE MAILBOX Command
+
+   Arguments:  mailbox name
+
+   Data:       no specific data for this command
+
+   Result:     OK - unsubscribe completed
+               NO - unsubscribe failure: can't unsubscribe that name
+               BAD - command unknown or arguments invalid
+
+      The UNSUBSCRIBE MAILBOX command is identical in effect to the
+      UNSUBSCRIBE command.  A server which implements this command must
+      be able to distinguish between a UNSUBSCRIBE MAILBOX command and
+      an UNSUBSCRIBE command with a mailbox name argument of "MAILBOX".
+
+
+
+
+Crispin                                                        [Page 66]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+   Example:    C: A002 UNSUBSCRIBE MAILBOX #news.comp.mail.mime
+               S: A002 OK UNSUBSCRIBE MAILBOX from #news.comp.mail.mime
+               completed
+               C: A003 UNSUBSCRIBE MAILBOX
+               S: A003 OK UNSUBSCRIBE from MAILBOX completed
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                                                        [Page 67]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+B.      Obsolete Responses
+
+   The following responses are OBSOLETE.  Except as noted below, these
+   responses MUST NOT be transmitted by new server implementations.
+
+   The section headings of these responses are intended to correspond
+   with where they would be located in the main document if they were
+   not obsoleted.
+
+
+B.7.2.OBS.1.    MAILBOX Response
+
+   Data:       name
+
+      The MAILBOX response MUST NOT be transmitted by server
+      implementations except in response to the obsolete FIND MAILBOXES
+      and FIND ALL.MAILBOXES commands.  Client implementations that do
+      not use these commands MAY ignore this response.  It is documented
+      here for the benefit of implementors who may wish to support it
+      for compatibility with old client implementations.
+
+      This response occurs as a result of the FIND MAILBOXES and FIND
+      ALL.MAILBOXES commands.  It returns a single name that matches the
+      FIND specification.  There are no attributes or hierarchy
+      delimiter.
+
+   Example:    S: * MAILBOX blurdybloop
+
+
+B.7.3.OBS.1.    COPY Response
+
+   Data:       none
+
+      The COPY response MUST NOT be transmitted by new server
+      implementations.  Client implementations MUST ignore the COPY
+      response.  It is documented here for the benefit of client
+      implementors who may encounter this response from old server
+      implementations.
+
+      In some experimental versions of this protocol, this response was
+      returned in response to a COPY command to indicate on a
+      per-message basis that the message was copied successfully.
+
+   Example:    S: * 44 COPY
+
+
+
+
+
+
+
+Crispin                                                        [Page 68]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+B.7.3.OBS.2.    STORE Response
+
+   Data:       message data
+
+      The STORE response MUST NOT be transmitted by new server
+      implementations.  Client implementations MUST treat the STORE
+      response as equivalent to the FETCH response.  It is documented
+      here for the benefit of client implementors who may encounter this
+      response from old server implementations.
+
+      In some experimental versions of this protocol, this response was
+      returned instead of FETCH in response to a STORE command to report
+      the new value of the flags.
+
+   Example:    S: * 69 STORE (FLAGS (\Deleted))
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                                                        [Page 69]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+C.      References
+
+
+   [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731.
+   Carnegie-Mellon University, December 1994.
+
+   [IMAP-COMPAT] Crispin, M. "IMAP4 Compatibility with IMAP2 and
+   IMAP2bis", RFC 1732, University of Washington, December 1994.
+
+   [IMAP-DISC] Austein, R. "Synchronization Operations for Disconnected
+   IMAP4 Clients", Work in Progress.
+
+   [IMAP-MODEL] Crispin, M. "Distributed Electronic Mail Models in
+   IMAP4", RFC 1733, University of Washington, December 1994.
+
+   [IMAP-NAMING] Crispin, M. "Mailbox Naming Convention in IMAP4", Work
+   in Progress.
+
+   [IMAP2] Crispin, M., "Interactive Mail Access Protocol - Version 2",
+   RFC 1176, University of Washington, August 1990.
+
+   [IMSP] Myers, J. "IMSP -- Internet Message Support Protocol", Work in
+   Progress.
+
+   [MIME-1] Borenstein, N., and Freed, N., "MIME (Multipurpose Internet
+   Mail Extensions) Part One: Mechanisms for Specifying and Describing
+   the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft,
+   September 1993.
+
+   [MIME-2] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
+   Part Two: Message Header Extensions for Non-ASCII Text", RFC 1522,
+   University of Tennessee, September 1993.
+
+   [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
+   Messages", STD 11, RFC 822, University of Delaware, August 1982.
+
+   [SMTP] Postel, Jonathan B. "Simple Mail Transfer Protocol", STD 10,
+   RFC 821, USC/Information Sciences Institute, August 1982.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                                                        [Page 70]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+E.      IMAP4 Keyword Index
+
+
+       +FLAGS <flag list> (store command data item) ...............   34
+       +FLAGS.SILENT <flag list> (store command data item) ........   34
+       -FLAGS <flag list> (store command data item) ...............   34
+       -FLAGS.SILENT <flag list> (store command data item) ........   34
+       ALERT (response code) ......................................   39
+       ALL (fetch item) ...........................................   29
+       ALL (search key) ...........................................   27
+       ANSWERED (search key) ......................................   27
+       APPEND (command) ...........................................   22
+       AUTHENTICATE (command) .....................................   12
+       BAD (response) .............................................   41
+       BCC <string> (search key) ..................................   27
+       BEFORE <date> (search key) .................................   27
+       BODY (fetch item) ..........................................   29
+       BODY (fetch result) ........................................   46
+       BODY <string> (search key) .................................   27
+       BODY.PEEK[<section>] (fetch item) ..........................   30
+       BODYSTRUCTURE (fetch item) .................................   31
+       BODYSTRUCTURE (fetch result) ...............................   47
+       BODY[<section>] (fetch item) ...............................   29
+       BODY[section] (fetch result) ...............................   46
+       BYE (response) .............................................   41
+       CAPABILITY (command) .......................................   10
+       CAPABILITY (response) ......................................   42
+       CC <string> (search key) ...................................   27
+       CHECK (command) ............................................   23
+       CLOSE (command) ............................................   24
+       COPY (command) .............................................   34
+       COPY (response) ............................................   68
+       CREATE (command) ...........................................   17
+       DELETE (command) ...........................................   18
+       DELETED (search key) .......................................   27
+       DRAFT (search key) .........................................   27
+       ENVELOPE (fetch item) ......................................   31
+       ENVELOPE (fetch result) ....................................   49
+       EXAMINE (command) ..........................................   16
+       EXISTS (response) ..........................................   45
+       EXPUNGE (command) ..........................................   25
+       EXPUNGE (response) .........................................   45
+       FAST (fetch item) ..........................................   31
+       FETCH (command) ............................................   29
+       FETCH (response) ...........................................   46
+       FIND ALL.MAILBOXES (command) ...............................   65
+       FIND MAILBOXES (command) ...................................   65
+       FLAGGED (search key) .......................................   27
+       FLAGS (fetch item) .........................................   31
+
+
+
+Crispin                                                        [Page 71]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+
+       FLAGS (fetch result) .......................................   50
+       FLAGS (response) ...........................................   44
+       FLAGS <flag list> (store command data item) ................   34
+       FLAGS.SILENT <flag list> (store command data item) .........   34
+       FROM <string> (search key) .................................   27
+       FULL (fetch item) ..........................................   31
+       HEADER <field-name> <string> (search key) ..................   27
+       INTERNALDATE (fetch item) ..................................   31
+       INTERNALDATE (fetch result) ................................   50
+       KEYWORD <flag> (search key) ................................   27
+       LARGER <n> (search key) ....................................   27
+       LIST (command) .............................................   20
+       LIST (response) ............................................   43
+       LOGIN (command) ............................................   14
+       LOGOUT (command) ...........................................   11
+       LSUB (command) .............................................   22
+       LSUB (response) ............................................   44
+       MAILBOX (response) .........................................   68
+       NEW (search key) ...........................................   27
+       NO (response) ..............................................   40
+       NOOP (command) .............................................   11
+       NOT <search-key> (search key) ..............................   28
+       OK (response) ..............................................   40
+       OLD (search key) ...........................................   28
+       ON <date> (search key) .....................................   28
+       OR <search-key1> <search-key2> (search key) ................   28
+       PARSE (response code) ......................................   39
+       PARTIAL (command) ..........................................   32
+       PERMANENTFLAGS (response code) .............................   39
+       PREAUTH (response) .........................................   41
+       READ-ONLY (response code) ..................................   39
+       READ-WRITE (response code) .................................   39
+       RECENT (response) ..........................................   45
+       RECENT (search key) ........................................   28
+       RENAME (command) ...........................................   18
+       RFC822 (fetch item) ........................................   31
+       RFC822 (fetch result) ......................................   50
+       RFC822.HEADER (fetch item) .................................   31
+       RFC822.HEADER (fetch result) ...............................   50
+       RFC822.HEADER.LINES <header_list> (fetch item) .............   31
+       RFC822.HEADER.LINES.NOT <header_list> (fetch item) .........   32
+       RFC822.PEEK (fetch item) ...................................   31
+       RFC822.SIZE (fetch item) ...................................   32
+       RFC822.SIZE (fetch result) .................................   50
+       RFC822.TEXT (fetch item) ...................................   32
+       RFC822.TEXT (fetch result) .................................   51
+       RFC822.TEXT.PEEK (fetch item) ..............................   32
+       SEARCH (command) ...........................................   25
+
+
+
+Crispin                                                        [Page 72]
+
+RFC 1730                         IMAP4                     December 1994
+
+
+
+       SEARCH (response) ..........................................   44
+       SEEN (search key) ..........................................   28
+       SELECT (command) ...........................................   15
+       SENTBEFORE <date> (search key) .............................   28
+       SENTON <date> (search key) .................................   28
+       SENTSINCE <date> (search key) ..............................   28
+       SINCE <date> (search key) ..................................   28
+       SMALLER <n> (search key) ...................................   28
+       STORE (command) ............................................   33
+       STORE (response) ...........................................   69
+       SUBJECT <string> (search key) ..............................   28
+       SUBSCRIBE (command) ........................................   19
+       SUBSCRIBE MAILBOX (command) ................................   66
+       TEXT <string> (search key) .................................   28
+       TO <string> (search key) ...................................   28
+       TRYCREATE (response code) ..................................   39
+       UID (command) ..............................................   35
+       UID (fetch item) ...........................................   32
+       UID (fetch result) .........................................   51
+       UID <message set> (search key) .............................   28
+       UIDVALIDITY (response code) ................................   40
+       UNANSWERED (search key) ....................................   29
+       UNDELETED (search key) .....................................   29
+       UNDRAFT (search key) .......................................   29
+       UNFLAGGED (search key) .....................................   29
+       UNKEYWORD <flag> (search key) ..............................   29
+       UNSEEN (response code) .....................................   40
+       UNSEEN (search key) ........................................   29
+       UNSUBSCRIBE (command) ......................................   19
+       UNSUBSCRIBE MAILBOX (command) ..............................   66
+       X<atom> (command) ..........................................   37
+       \Answered (system flag) ....................................   50
+       \Deleted (system flag) .....................................   50
+       \Draft (system flag) .......................................   50
+       \Flagged (system flag) .....................................   50
+       \Marked (mailbox name attribute) ...........................   43
+       \Noinferiors (mailbox name attribute) ......................   43
+       \Noselect (mailbox name attribute) .........................   43
+       \Recent (system flag) ......................................   50
+       \Seen (system flag) ........................................   50
+       \Unmarked (mailbox name attribute) .........................   43
+
+
+
+
+
+
+
+
+
+
+Crispin                                                        [Page 73]
+
-- 
cgit v1.2.3