From 79e0c67734f987b6abff989c9d74254a4c34f747 Mon Sep 17 00:00:00 2001
From: Unknown <>
Date: Mon, 17 Mar 2003 18:27:45 +0000
Subject: [PATCH] add files for 2003-03-17T18:27:45Z

---
 docs/rfc/rfc3501.txt | 6052 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 6052 insertions(+)
 create mode 100644 docs/rfc/rfc3501.txt

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