dmc

dynamic mail client
git clone git://git.suckless.org/dmc
Log | Files | Refs | README | LICENSE

imap-rfc3501.txt (216452B)


      1 
      2    [ _R_F_C_ _I_n_d_e_x | _R_F_C_ _S_e_a_r_c_h | _U_s_e_n_e_t_ _F_A_Q_s | _W_e_b_ _F_A_Q_s | _D_o_c_u_m_e_n_t_s | _C_i_t_i_e_s ]
      3                AAlltteerrnnaattee FFoorrmmaattss:: _r_f_c_3_5_0_1_._t_x_t | _r_f_c_3_5_0_1_._t_x_t_._p_d_f
      4      ******** RRFFCC 33550011 -- IINNTTEERRNNEETT MMEESSSSAAGGEE AACCCCEESSSS PPRROOTTOOCCOOLL -- VVEERRSSIIOONN 44rreevv11 ********
      5 ===============================================================================
      6     * SSeeaarrcchh tthhee AArrcchhiivveess  DDiissppllaayy RRFFCC bbyy nnuummbbeerr
      7     *     [q               [display   ]     [Display RFC By Number]
      8       ] [Search RFCs]
      9 ===============================================================================
     10 
     11    ************ RRFFCC33550011 -- IINNTTEERRNNEETT MMEESSSSAAGGEE AACCCCEESSSS PPRROOTTOOCCOOLL -- VVEERRSSIIOONN 44rreevv11 ************
     12 
     13 Network Working Group                                         M. Crispin
     14 Request for Comments: 3501                      University of Washington
     15 Obsoletes: 2060                                               March 2003
     16 Category: Standards Track
     17 
     18             INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1
     19 
     20 Status of this Memo
     21 
     22    This document specifies an Internet standards track protocol for the
     23    Internet community, and requests discussion and suggestions for
     24    improvements.  Please refer to the current edition of the "Internet
     25    Official Protocol Standards" (STD 1) for the standardization state
     26    and status of this protocol.  Distribution of this memo is unlimited.
     27 
     28 Copyright Notice
     29 
     30    Copyright (C) The Internet Society (2003).  All Rights Reserved.
     31 
     32 Abstract
     33 
     34    The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1)
     35    allows a client to access and manipulate electronic mail messages on
     36    a server.  IMAP4rev1 permits manipulation of mailboxes (remote
     37    message folders) in a way that is functionally equivalent to local
     38    folders.  IMAP4rev1 also provides the capability for an offline
     39    client to resynchronize with the server.
     40 
     41    IMAP4rev1 includes operations for creating, deleting, and renaming
     42    mailboxes, checking for new messages, permanently removing messages,
     43    setting and clearing flags, _R_F_C_ _2_8_2_2 and _R_F_C_ _2_0_4_5 parsing, searching,
     44    and selective fetching of message attributes, texts, and portions
     45    thereof.  Messages in IMAP4rev1 are accessed by the use of numbers.
     46    These numbers are either message sequence numbers or unique
     47    identifiers.
     48 
     49    IMAP4rev1 supports a single server.  A mechanism for accessing
     50    configuration information to support multiple IMAP4rev1 servers is
     51    discussed in _R_F_C_ _2_2_4_4.
     52 
     53    IMAP4rev1 does not specify a means of posting mail; this function is
     54    handled by a mail transfer protocol such as _R_F_C_ _2_8_2_1.
     55 
     56 Table of Contents
     57 
     58    IMAP4rev1 Protocol Specification ................................  4
     59    1.      How to Read This Document ...............................  4
     60    1.1.    Organization of This Document ...........................  4
     61    1.2.    Conventions Used in This Document .......................  4
     62    1.3.    Special Notes to Implementors ...........................  5
     63    2.      Protocol Overview .......................................  6
     64    2.1.    Link Level ..............................................  6
     65    2.2.    Commands and Responses ..................................  6
     66    2.2.1.  Client Protocol Sender and Server Protocol Receiver .....  6
     67    2.2.2.  Server Protocol Sender and Client Protocol Receiver .....  7
     68    2.3.    Message Attributes ......................................  8
     69    2.3.1.  Message Numbers .........................................  8
     70    2.3.1.1.        Unique Identifier (UID) Message Attribute .......  8
     71    2.3.1.2.        Message Sequence Number Message Attribute ....... 10
     72    2.3.2.  Flags Message Attribute ................................. 11
     73    2.3.3.  Internal Date Message Attribute ......................... 12
     74    2.3.4.  [_R_F_C_-_2_8_2_2] Size Message Attribute ....................... 12
     75    2.3.5.  Envelope Structure Message Attribute .................... 12
     76    2.3.6.  Body Structure Message Attribute ........................ 12
     77    2.4.    Message Texts ........................................... 13
     78    3.      State and Flow Diagram .................................. 13
     79    3.1.    Not Authenticated State ................................. 13
     80    3.2.    Authenticated State ..................................... 13
     81    3.3.    Selected State .......................................... 13
     82    3.4.    Logout State ............................................ 14
     83    4.      Data Formats ............................................ 16
     84    4.1.    Atom .................................................... 16
     85    4.2.    Number .................................................. 16
     86    4.3.    String .................................................. 16
     87    4.3.1.  8-bit and Binary Strings ................................ 17
     88    4.4.    Parenthesized List ...................................... 17
     89    4.5.    NIL ..................................................... 17
     90    5.      Operational Considerations .............................. 18
     91    5.1.    Mailbox Naming .......................................... 18
     92    5.1.1.  Mailbox Hierarchy Naming ................................ 19
     93    5.1.2.  Mailbox Namespace Naming Convention ..................... 19
     94    5.1.3.  Mailbox International Naming Convention ................. 19
     95    5.2.    Mailbox Size and Message Status Updates ................. 21
     96    5.3.    Response when no Command in Progress .................... 21
     97    5.4.    Autologout Timer ........................................ 22
     98    5.5.    Multiple Commands in Progress ........................... 22
     99    6.      Client Commands ........................................  23
    100    6.1.    Client Commands - Any State ............................  24
    101    6.1.1.  CAPABILITY Command .....................................  24
    102    6.1.2.  NOOP Command ...........................................  25
    103    6.1.3.  LOGOUT Command .........................................  26
    104 
    105    6.2.    Client Commands - Not Authenticated State ..............  26
    106    6.2.1.  STARTTLS Command .......................................  27
    107    6.2.2.  AUTHENTICATE Command ...................................  28
    108    6.2.3.  LOGIN Command ..........................................  30
    109    6.3.    Client Commands - Authenticated State ..................  31
    110    6.3.1.  SELECT Command .........................................  32
    111    6.3.2.  EXAMINE Command ........................................  34
    112    6.3.3.  CREATE Command .........................................  34
    113    6.3.4.  DELETE Command .........................................  35
    114    6.3.5.  RENAME Command .........................................  37
    115    6.3.6.  SUBSCRIBE Command ......................................  39
    116    6.3.7.  UNSUBSCRIBE Command ....................................  39
    117    6.3.8.  LIST Command ...........................................  40
    118    6.3.9.  LSUB Command ...........................................  43
    119    6.3.10. STATUS Command .........................................  44
    120    6.3.11. APPEND Command .........................................  46
    121    6.4.    Client Commands - Selected State .......................  47
    122    6.4.1.  CHECK Command ..........................................  47
    123    6.4.2.  CLOSE Command ..........................................  48
    124    6.4.3.  EXPUNGE Command ........................................  49
    125    6.4.4.  SEARCH Command .........................................  49
    126    6.4.5.  FETCH Command ..........................................  54
    127    6.4.6.  STORE Command ..........................................  58
    128    6.4.7.  COPY Command ...........................................  59
    129    6.4.8.  UID Command ............................................  60
    130    6.5.    Client Commands - Experimental/Expansion ...............  62
    131    6.5.1.  X<atom> Command ........................................  62
    132    7.      Server Responses .......................................  62
    133    7.1.    Server Responses - Status Responses ....................  63
    134    7.1.1.  OK Response ............................................  65
    135    7.1.2.  NO Response ............................................  66
    136    7.1.3.  BAD Response ...........................................  66
    137    7.1.4.  PREAUTH Response .......................................  67
    138    7.1.5.  BYE Response ...........................................  67
    139    7.2.    Server Responses - Server and Mailbox Status ...........  68
    140    7.2.1.  CAPABILITY Response ....................................  68
    141    7.2.2.  LIST Response ..........................................  69
    142    7.2.3.  LSUB Response ..........................................  70
    143    7.2.4   STATUS Response ........................................  70
    144    7.2.5.  SEARCH Response ........................................  71
    145    7.2.6.  FLAGS Response .........................................  71
    146    7.3.    Server Responses - Mailbox Size ........................  71
    147    7.3.1.  EXISTS Response ........................................  71
    148    7.3.2.  RECENT Response ........................................  72
    149    7.4.    Server Responses - Message Status ......................  72
    150    7.4.1.  EXPUNGE Response .......................................  72
    151    7.4.2.  FETCH Response .........................................  73
    152    7.5.    Server Responses - Command Continuation Request ........  79
    153 
    154    8.      Sample IMAP4rev1 connection ............................  80
    155    9.      Formal Syntax ..........................................  81
    156    10.     Author's Note ..........................................  92
    157    11.     Security Considerations ................................  92
    158    11.1.   STARTTLS Security Considerations .......................  92
    159    11.2.   Other Security Considerations ..........................  93
    160    12.     IANA Considerations ....................................  94
    161    Appendices .....................................................  95
    162    A.      References .............................................  95
    163    B.      Changes from _R_F_C_ _2_0_6_0 ..................................  97
    164    C.      Key Word Index ......................................... 103
    165    Author's Address ............................................... 107
    166    Full Copyright Statement ....................................... 108
    167 
    168 IMAP4rev1 Protocol Specification
    169 
    170 1.      How to Read This Document
    171 
    172 1.1.    Organization of This Document
    173 
    174    This document is written from the point of view of the implementor of
    175    an IMAP4rev1 client or server.  Beyond the protocol overview in
    176    section 2, it is not optimized for someone trying to understand the
    177    operation of the protocol.  The material in sections 3 through 5
    178    provides the general context and definitions with which IMAP4rev1
    179    operates.
    180 
    181    Sections 6, 7, and 9 describe the IMAP commands, responses, and
    182    syntax, respectively.  The relationships among these are such that it
    183    is almost impossible to understand any of them separately.  In
    184    particular, do not attempt to deduce command syntax from the command
    185    section alone; instead refer to the Formal Syntax section.
    186 
    187 1.2.    Conventions Used in This Document
    188 
    189    "Conventions" are basic principles or procedures.  Document
    190    conventions are noted in this section.
    191 
    192    In examples, "C:" and "S:" indicate lines sent by the client and
    193    server respectively.
    194 
    195    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    196    "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to
    197    be interpreted as described in [KEYWORDS].
    198 
    199    The word "can" (not "may") is used to refer to a possible
    200    circumstance or situation, as opposed to an optional facility of the
    201    protocol.
    202 
    203    "User" is used to refer to a human user, whereas "client" refers to
    204    the software being run by the user.
    205 
    206    "Connection" refers to the entire sequence of client/server
    207    interaction from the initial establishment of the network connection
    208    until its termination.
    209 
    210    "Session" refers to the sequence of client/server interaction from
    211    the time that a mailbox is selected (SELECT or EXAMINE command) until
    212    the time that selection ends (SELECT or EXAMINE of another mailbox,
    213    CLOSE command, or connection termination).
    214 
    215    Characters are 7-bit US-ASCII unless otherwise specified.  Other
    216    character sets are indicated using a "CHARSET", as described in
    217    [MIME-IMT] and defined in [CHARSET].  CHARSETs have important
    218    additional semantics in addition to defining character set; refer to
    219    these documents for more detail.
    220 
    221    There are several protocol conventions in IMAP.  These refer to
    222    aspects of the specification which are not strictly part of the IMAP
    223    protocol, but reflect generally-accepted practice.  Implementations
    224    need to be aware of these conventions, and avoid conflicts whether or
    225    not they implement the convention.  For example, "&" may not be used
    226    as a hierarchy delimiter since it conflicts with the Mailbox
    227    International Naming Convention, and other uses of "&" in mailbox
    228    names are impacted as well.
    229 
    230 1.3.    Special Notes to Implementors
    231 
    232    Implementors of the IMAP protocol are strongly encouraged to read the
    233    IMAP implementation recommendations document [IMAP-IMPLEMENTATION] in
    234    conjunction with this document, to help understand the intricacies of
    235    this protocol and how best to build an interoperable product.
    236 
    237    IMAP4rev1 is designed to be upwards compatible from the [IMAP2] and
    238    unpublished IMAP2bis protocols.  IMAP4rev1 is largely compatible with
    239    the IMAP4 protocol described in _R_F_C_ _1_7_3_0; the exception being in
    240    certain facilities added in _R_F_C_ _1_7_3_0 that proved problematic and were
    241    subsequently removed.  In the course of the evolution of IMAP4rev1,
    242    some aspects in the earlier protocols have become obsolete.  Obsolete
    243    commands, responses, and data formats which an IMAP4rev1
    244    implementation can encounter when used with an earlier implementation
    245    are described in [IMAP-OBSOLETE].
    246 
    247    Other compatibility issues with IMAP2bis, the most common variant of
    248    the earlier protocol, are discussed in [IMAP-COMPAT].  A full
    249    discussion of compatibility issues with rare (and presumed extinct)
    250 
    251    variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is
    252    primarily of historical interest.
    253 
    254    IMAP was originally developed for the older [_R_F_C_-_8_2_2] standard, and
    255    as a consequence several fetch items in IMAP incorporate "_R_F_C_8_2_2" in
    256    their name.  With the exception of _R_F_C_8_2_2.SIZE, there are more modern
    257    replacements; for example, the modern version of _R_F_C_8_2_2.HEADER is
    258    BODY.PEEK[HEADER].  In all cases, "_R_F_C_8_2_2" should be interpreted as a
    259    reference to the updated [_R_F_C_-_2_8_2_2] standard.
    260 
    261 2.      Protocol Overview
    262 
    263 2.1.    Link Level
    264 
    265    The IMAP4rev1 protocol assumes a reliable data stream such as that
    266    provided by TCP.  When TCP is used, an IMAP4rev1 server listens on
    267    port 143.
    268 
    269 2.2.    Commands and Responses
    270 
    271    An IMAP4rev1 connection consists of the establishment of a
    272    client/server network connection, an initial greeting from the
    273    server, and client/server interactions.  These client/server
    274    interactions consist of a client command, server data, and a server
    275    completion result response.
    276 
    277    All interactions transmitted by client and server are in the form of
    278    lines, that is, strings that end with a CRLF.  The protocol receiver
    279    of an IMAP4rev1 client or server is either reading a line, or is
    280    reading a sequence of octets with a known count followed by a line.
    281 
    282 2.2.1.  Client Protocol Sender and Server Protocol Receiver
    283 
    284    The client command begins an operation.  Each client command is
    285    prefixed with an identifier (typically a short alphanumeric string,
    286    e.g., A0001, A0002, etc.) called a "tag".  A different tag is
    287    generated by the client for each command.
    288 
    289    Clients MUST follow the syntax outlined in this specification
    290    strictly.  It is a syntax error to send a command with missing or
    291    extraneous spaces or arguments.
    292 
    293    There are two cases in which a line from the client does not
    294    represent a complete command.  In one case, a command argument is
    295    quoted with an octet count (see the description of literal in String
    296    under Data Formats); in the other case, the command arguments require
    297    server feedback (see the AUTHENTICATE command).  In either case, the
    298 
    299    server sends a command continuation request response if it is ready
    300    for the octets (if appropriate) and the remainder of the command.
    301    This response is prefixed with the token "+".
    302 
    303         Note: If instead, the server detected an error in the
    304         command, it sends a BAD completion response with a tag
    305         matching the command (as described below) to reject the
    306         command and prevent the client from sending any more of the
    307         command.
    308 
    309         It is also possible for the server to send a completion
    310         response for some other command (if multiple commands are
    311         in progress), or untagged data.  In either case, the
    312         command continuation request is still pending; the client
    313         takes the appropriate action for the response, and reads
    314         another response from the server.  In all cases, the client
    315         MUST send a complete command (including receiving all
    316         command continuation request responses and command
    317         continuations for the command) before initiating a new
    318         command.
    319 
    320    The protocol receiver of an IMAP4rev1 server reads a command line
    321    from the client, parses the command and its arguments, and transmits
    322    server data and a server command completion result response.
    323 
    324 2.2.2.  Server Protocol Sender and Client Protocol Receiver
    325 
    326    Data transmitted by the server to the client and status responses
    327    that do not indicate command completion are prefixed with the token
    328    "*", and are called untagged responses.
    329 
    330    Server data MAY be sent as a result of a client command, or MAY be
    331    sent unilaterally by the server.  There is no syntactic difference
    332    between server data that resulted from a specific command and server
    333    data that were sent unilaterally.
    334 
    335    The server completion result response indicates the success or
    336    failure of the operation.  It is tagged with the same tag as the
    337    client command which began the operation.  Thus, if more than one
    338    command is in progress, the tag in a server completion response
    339    identifies the command to which the response applies.  There are
    340    three possible server completion responses: OK (indicating success),
    341    NO (indicating failure), or BAD (indicating a protocol error such as
    342    unrecognized command or command syntax error).
    343 
    344    Servers SHOULD enforce the syntax outlined in this specification
    345    strictly.  Any client command with a protocol syntax error, including
    346    (but not limited to) missing or extraneous spaces or arguments,
    347 
    348    SHOULD be rejected, and the client given a BAD server completion
    349    response.
    350 
    351    The protocol receiver of an IMAP4rev1 client reads a response line
    352    from the server.  It then takes action on the response based upon the
    353    first token of the response, which can be a tag, a "*", or a "+".
    354 
    355    A client MUST be prepared to accept any server response at all times.
    356    This includes server data that was not requested.  Server data SHOULD
    357    be recorded, so that the client can reference its recorded copy
    358    rather than sending a command to the server to request the data.  In
    359    the case of certain server data, the data MUST be recorded.
    360 
    361    This topic is discussed in greater detail in the Server Responses
    362    section.
    363 
    364 2.3.    Message Attributes
    365 
    366    In addition to message text, each message has several attributes
    367    associated with it.  These attributes can be retrieved individually
    368    or in conjunction with other attributes or message texts.
    369 
    370 2.3.1.  Message Numbers
    371 
    372    Messages in IMAP4rev1 are accessed by one of two numbers; the unique
    373    identifier or the message sequence number.
    374 
    375 2.3.1.1.        Unique Identifier (UID) Message Attribute
    376 
    377    A 32-bit value assigned to each message, which when used with the
    378    unique identifier validity value (see below) forms a 64-bit value
    379    that MUST NOT refer to any other message in the mailbox or any
    380    subsequent mailbox with the same name forever.  Unique identifiers
    381    are assigned in a strictly ascending fashion in the mailbox; as each
    382    message is added to the mailbox it is assigned a higher UID than the
    383    message(s) which were added previously.  Unlike message sequence
    384    numbers, unique identifiers are not necessarily contiguous.
    385 
    386    The unique identifier of a message MUST NOT change during the
    387    session, and SHOULD NOT change between sessions.  Any change of
    388    unique identifiers between sessions MUST be detectable using the
    389    UIDVALIDITY mechanism discussed below.  Persistent unique identifiers
    390    are required for a client to resynchronize its state from a previous
    391    session with the server (e.g., disconnected or offline access
    392    clients); this is discussed further in [IMAP-DISC].
    393 
    394    Associated with every mailbox are two values which aid in unique
    395    identifier handling: the next unique identifier value and the unique
    396    identifier validity value.
    397 
    398    The next unique identifier value is the predicted value that will be
    399    assigned to a new message in the mailbox.  Unless the unique
    400    identifier validity also changes (see below), the next unique
    401    identifier value MUST have the following two characteristics.  First,
    402    the next unique identifier value MUST NOT change unless new messages
    403    are added to the mailbox; and second, the next unique identifier
    404    value MUST change whenever new messages are added to the mailbox,
    405    even if those new messages are subsequently expunged.
    406 
    407         Note: The next unique identifier value is intended to
    408         provide a means for a client to determine whether any
    409         messages have been delivered to the mailbox since the
    410         previous time it checked this value.  It is not intended to
    411         provide any guarantee that any message will have this
    412         unique identifier.  A client can only assume, at the time
    413         that it obtains the next unique identifier value, that
    414         messages arriving after that time will have a UID greater
    415         than or equal to that value.
    416 
    417    The unique identifier validity value is sent in a UIDVALIDITY
    418    response code in an OK untagged response at mailbox selection time.
    419    If unique identifiers from an earlier session fail to persist in this
    420    session, the unique identifier validity value MUST be greater than
    421    the one used in the earlier session.
    422 
    423         Note: Ideally, unique identifiers SHOULD persist at all
    424         times.  Although this specification recognizes that failure
    425         to persist can be unavoidable in certain server
    426         environments, it STRONGLY ENCOURAGES message store
    427         implementation techniques that avoid this problem.  For
    428         example:
    429 
    430          1) Unique identifiers MUST be strictly ascending in the
    431             mailbox at all times.  If the physical message store is
    432             re-ordered by a non-IMAP agent, this requires that the
    433             unique identifiers in the mailbox be regenerated, since
    434             the former unique identifiers are no longer strictly
    435             ascending as a result of the re-ordering.
    436 
    437          2) If the message store has no mechanism to store unique
    438             identifiers, it must regenerate unique identifiers at
    439             each session, and each session must have a unique
    440             UIDVALIDITY value.
    441 
    442          3) If the mailbox is deleted and a new mailbox with the
    443             same name is created at a later date, the server must
    444             either keep track of unique identifiers from the
    445             previous instance of the mailbox, or it must assign a
    446             new UIDVALIDITY value to the new instance of the
    447             mailbox.  A good UIDVALIDITY value to use in this case
    448             is a 32-bit representation of the creation date/time of
    449             the mailbox.  It is alright to use a constant such as
    450             1, but only if it guaranteed that unique identifiers
    451             will never be reused, even in the case of a mailbox
    452             being deleted (or renamed) and a new mailbox by the
    453             same name created at some future time.
    454 
    455          4) The combination of mailbox name, UIDVALIDITY, and UID
    456             must refer to a single immutable message on that server
    457             forever.  In particular, the internal date, [_R_F_C_-_2_8_2_2]
    458             size, envelope, body structure, and message texts
    459             (_R_F_C_8_2_2, _R_F_C_8_2_2.HEADER, _R_F_C_8_2_2.TEXT, and all BODY[...]
    460             fetch data items) must never change.  This does not
    461             include message numbers, nor does it include attributes
    462             that can be set by a STORE command (e.g., FLAGS).
    463 
    464 2.3.1.2.        Message Sequence Number Message Attribute
    465 
    466    A relative position from 1 to the number of messages in the mailbox.
    467    This position MUST be ordered by ascending unique identifier.  As
    468    each new message is added, it is assigned a message sequence number
    469    that is 1 higher than the number of messages in the mailbox before
    470    that new message was added.
    471 
    472    Message sequence numbers can be reassigned during the session.  For
    473    example, when a message is permanently removed (expunged) from the
    474    mailbox, the message sequence number for all subsequent messages is
    475    decremented.  The number of messages in the mailbox is also
    476    decremented.  Similarly, a new message can be assigned a message
    477    sequence number that was once held by some other message prior to an
    478    expunge.
    479 
    480    In addition to accessing messages by relative position in the
    481    mailbox, message sequence numbers can be used in mathematical
    482    calculations.  For example, if an untagged "11 EXISTS" is received,
    483    and previously an untagged "8 EXISTS" was received, three new
    484    messages have arrived with message sequence numbers of 9, 10, and 11.
    485    Another example, if message 287 in a 523 message mailbox has UID
    486    12345, there are exactly 286 messages which have lesser UIDs and 236
    487    messages which have greater UIDs.
    488 
    489 2.3.2.  Flags Message Attribute
    490 
    491    A list of zero or more named tokens associated with the message.  A
    492    flag is set by its addition to this list, and is cleared by its
    493    removal.  There are two types of flags in IMAP4rev1.  A flag of
    494    either type can be permanent or session-only.
    495 
    496    A system flag is a flag name that is pre-defined in this
    497    specification.  All system flags begin with "\".  Certain system
    498    flags (\Deleted and \Seen) have special semantics described
    499    elsewhere.  The currently-defined system flags are:
    500 
    501         \Seen
    502            Message has been read
    503 
    504         \Answered
    505            Message has been answered
    506 
    507         \Flagged
    508            Message is "flagged" for urgent/special attention
    509 
    510         \Deleted
    511            Message is "deleted" for removal by later EXPUNGE
    512 
    513         \Draft
    514            Message has not completed composition (marked as a draft).
    515 
    516         \Recent
    517            Message is "recently" arrived in this mailbox.  This session
    518            is the first session to have been notified about this
    519            message; if the session is read-write, subsequent sessions
    520            will not see \Recent set for this message.  This flag can not
    521            be altered by the client.
    522 
    523            If it is not possible to determine whether or not this
    524            session is the first session to be notified about a message,
    525            then that message SHOULD be considered recent.
    526 
    527            If multiple connections have the same mailbox selected
    528            simultaneously, it is undefined which of these connections
    529            will see newly-arrived messages with \Recent set and which
    530            will see it without \Recent set.
    531 
    532    A keyword is defined by the server implementation.  Keywords do not
    533    begin with "\".  Servers MAY permit the client to define new keywords
    534    in the mailbox (see the description of the PERMANENTFLAGS response
    535    code for more information).
    536 
    537    A flag can be permanent or session-only on a per-flag basis.
    538    Permanent flags are those which the client can add or remove from the
    539    message flags permanently; that is, concurrent and subsequent
    540    sessions will see any change in permanent flags.  Changes to session
    541    flags are valid only in that session.
    542 
    543         Note: The \Recent system flag is a special case of a
    544         session flag.  \Recent can not be used as an argument in a
    545         STORE or APPEND command, and thus can not be changed at
    546         all.
    547 
    548 2.3.3.  Internal Date Message Attribute
    549 
    550    The internal date and time of the message on the server.  This
    551    is not the date and time in the [_R_F_C_-_2_8_2_2] header, but rather a
    552    date and time which reflects when the message was received.  In
    553    the case of messages delivered via [SMTP], this SHOULD be the
    554    date and time of final delivery of the message as defined by
    555    [SMTP].  In the case of messages delivered by the IMAP4rev1 COPY
    556    command, this SHOULD be the internal date and time of the source
    557    message.  In the case of messages delivered by the IMAP4rev1
    558    APPEND command, this SHOULD be the date and time as specified in
    559    the APPEND command description.  All other cases are
    560    implementation defined.
    561 
    562 2.3.4.  [_R_F_C_-_2_8_2_2] Size Message Attribute
    563 
    564    The number of octets in the message, as expressed in [_R_F_C_-_2_8_2_2]
    565    format.
    566 
    567 2.3.5.  Envelope Structure Message Attribute
    568 
    569    A parsed representation of the [_R_F_C_-_2_8_2_2] header of the message.
    570    Note that the IMAP Envelope structure is not the same as an
    571    [SMTP] envelope.
    572 
    573 2.3.6.  Body Structure Message Attribute
    574 
    575    A parsed representation of the [MIME-IMB] body structure
    576    information of the message.
    577 
    578 2.4.    Message Texts
    579 
    580    In addition to being able to fetch the full [_R_F_C_-_2_8_2_2] text of a
    581    message, IMAP4rev1 permits the fetching of portions of the full
    582    message text.  Specifically, it is possible to fetch the
    583    [_R_F_C_-_2_8_2_2] message header, [_R_F_C_-_2_8_2_2] message body, a [MIME-IMB]
    584    body part, or a [MIME-IMB] header.
    585 
    586 3.      State and Flow Diagram
    587 
    588    Once the connection between client and server is established, an
    589    IMAP4rev1 connection is in one of four states.  The initial
    590    state is identified in the server greeting.  Most commands are
    591    only valid in certain states.  It is a protocol error for the
    592    client to attempt a command while the connection is in an
    593    inappropriate state, and the server will respond with a BAD or
    594    NO (depending upon server implementation) command completion
    595    result.
    596 
    597 3.1.    Not Authenticated State
    598 
    599    In the not authenticated state, the client MUST supply
    600    authentication credentials before most commands will be
    601    permitted.  This state is entered when a connection starts
    602    unless the connection has been pre-authenticated.
    603 
    604 3.2.    Authenticated State
    605 
    606    In the authenticated state, the client is authenticated and MUST
    607    select a mailbox to access before commands that affect messages
    608    will be permitted.  This state is entered when a
    609    pre-authenticated connection starts, when acceptable
    610    authentication credentials have been provided, after an error in
    611    selecting a mailbox, or after a successful CLOSE command.
    612 
    613 3.3.    Selected State
    614 
    615    In a selected state, a mailbox has been selected to access.
    616    This state is entered when a mailbox has been successfully
    617    selected.
    618 
    619 3.4.    Logout State
    620 
    621    In the logout state, the connection is being terminated.  This
    622    state can be entered as a result of a client request (via the
    623    LOGOUT command) or by unilateral action on the part of either
    624    the client or server.
    625 
    626    If the client requests the logout state, the server MUST send an
    627    untagged BYE response and a tagged OK response to the LOGOUT
    628    command before the server closes the connection; and the client
    629    MUST read the tagged OK response to the LOGOUT command before
    630    the client closes the connection.
    631 
    632    A server MUST NOT unilaterally close the connection without
    633    sending an untagged BYE response that contains the reason for
    634    having done so.  A client SHOULD NOT unilaterally close the
    635    connection, and instead SHOULD issue a LOGOUT command.  If the
    636    server detects that the client has unilaterally closed the
    637    connection, the server MAY omit the untagged BYE response and
    638    simply close its connection.
    639 
    640                    +----------------------+
    641                    |connection established|
    642                    +----------------------+
    643                               ||
    644                               \/
    645             +--------------------------------------+
    646             |          server greeting             |
    647             +--------------------------------------+
    648                       || (1)       || (2)        || (3)
    649                       \/           ||            ||
    650             +-----------------+    ||            ||
    651             |Not Authenticated|    ||            ||
    652             +-----------------+    ||            ||
    653              || (7)   || (4)       ||            ||
    654              ||       \/           \/            ||
    655              ||     +----------------+           ||
    656              ||     | Authenticated  |<=++       ||
    657              ||     +----------------+  ||       ||
    658              ||       || (7)   || (5)   || (6)   ||
    659              ||       ||       \/       ||       ||
    660              ||       ||    +--------+  ||       ||
    661              ||       ||    |Selected|==++       ||
    662              ||       ||    +--------+           ||
    663              ||       ||       || (7)            ||
    664              \/       \/       \/                \/
    665             +--------------------------------------+
    666             |               Logout                 |
    667             +--------------------------------------+
    668                               ||
    669                               \/
    670                 +-------------------------------+
    671                 |both sides close the connection|
    672                 +-------------------------------+
    673 
    674          (1) connection without pre-authentication (OK greeting)
    675          (2) pre-authenticated connection (PREAUTH greeting)
    676          (3) rejected connection (BYE greeting)
    677          (4) successful LOGIN or AUTHENTICATE command
    678          (5) successful SELECT or EXAMINE command
    679          (6) CLOSE command, or failed SELECT or EXAMINE command
    680          (7) LOGOUT command, server shutdown, or connection closed
    681 
    682 4.      Data Formats
    683 
    684    IMAP4rev1 uses textual commands and responses.  Data in
    685    IMAP4rev1 can be in one of several forms: atom, number, string,
    686    parenthesized list, or NIL.  Note that a particular data item
    687    may take more than one form; for example, a data item defined as
    688    using "astring" syntax may be either an atom or a string.
    689 
    690 4.1.    Atom
    691 
    692    An atom consists of one or more non-special characters.
    693 
    694 4.2.    Number
    695 
    696    A number consists of one or more digit characters, and
    697    represents a numeric value.
    698 
    699 4.3.    String
    700 
    701    A string is in one of two forms: either literal or quoted
    702    string.  The literal form is the general form of string.  The
    703    quoted string form is an alternative that avoids the overhead of
    704    processing a literal at the cost of limitations of characters
    705    which may be used.
    706 
    707    A literal is a sequence of zero or more octets (including CR and
    708    LF), prefix-quoted with an octet count in the form of an open
    709    brace ("{"), the number of octets, close brace ("}"), and CRLF.
    710    In the case of literals transmitted from server to client, the
    711    CRLF is immediately followed by the octet data.  In the case of
    712    literals transmitted from client to server, the client MUST wait
    713    to receive a command continuation request (described later in
    714    this document) before sending the octet data (and the remainder
    715    of the command).
    716 
    717    A quoted string is a sequence of zero or more 7-bit characters,
    718    excluding CR and LF, with double quote (<">) characters at each
    719    end.
    720 
    721    The empty string is represented as either "" (a quoted string
    722    with zero characters between double quotes) or as {0} followed
    723    by CRLF (a literal with an octet count of 0).
    724 
    725      Note: Even if the octet count is 0, a client transmitting a
    726      literal MUST wait to receive a command continuation request.
    727 
    728 4.3.1.  8-bit and Binary Strings
    729 
    730    8-bit textual and binary mail is supported through the use of a
    731    [MIME-IMB] content transfer encoding.  IMAP4rev1 implementations MAY
    732    transmit 8-bit or multi-octet characters in literals, but SHOULD do
    733    so only when the [CHARSET] is identified.
    734 
    735    Although a BINARY body encoding is defined, unencoded binary strings
    736    are not permitted.  A "binary string" is any string with NUL
    737    characters.  Implementations MUST encode binary data into a textual
    738    form, such as BASE64, before transmitting the data.  A string with an
    739    excessive amount of CTL characters MAY also be considered to be
    740    binary.
    741 
    742 4.4.    Parenthesized List
    743 
    744    Data structures are represented as a "parenthesized list"; a sequence
    745    of data items, delimited by space, and bounded at each end by
    746    parentheses.  A parenthesized list can contain other parenthesized
    747    lists, using multiple levels of parentheses to indicate nesting.
    748 
    749    The empty list is represented as () -- a parenthesized list with no
    750    members.
    751 
    752 4.5.    NIL
    753 
    754    The special form "NIL" represents the non-existence of a particular
    755    data item that is represented as a string or parenthesized list, as
    756    distinct from the empty string "" or the empty parenthesized list ().
    757 
    758         Note: NIL is never used for any data item which takes the
    759         form of an atom.  For example, a mailbox name of "NIL" is a
    760         mailbox named NIL as opposed to a non-existent mailbox
    761         name.  This is because mailbox uses "astring" syntax which
    762         is an atom or a string.  Conversely, an addr-name of NIL is
    763         a non-existent personal name, because addr-name uses
    764         "nstring" syntax which is NIL or a string, but never an
    765         atom.
    766 
    767 5.      Operational Considerations
    768 
    769    The following rules are listed here to ensure that all IMAP4rev1
    770    implementations interoperate properly.
    771 
    772 5.1.    Mailbox Naming
    773 
    774    Mailbox names are 7-bit.  Client implementations MUST NOT attempt to
    775    create 8-bit mailbox names, and SHOULD interpret any 8-bit mailbox
    776    names returned by LIST or LSUB as UTF-8.  Server implementations
    777    SHOULD prohibit the creation of 8-bit mailbox names, and SHOULD NOT
    778    return 8-bit mailbox names in LIST or LSUB.  See section 5.1.3 for
    779    more information on how to represent non-ASCII mailbox names.
    780 
    781         Note: 8-bit mailbox names were undefined in earlier
    782         versions of this protocol.  Some sites used a local 8-bit
    783         character set to represent non-ASCII mailbox names.  Such
    784         usage is not interoperable, and is now formally deprecated.
    785 
    786    The case-insensitive mailbox name INBOX is a special name reserved to
    787    mean "the primary mailbox for this user on this server".  The
    788    interpretation of all other names is implementation-dependent.
    789 
    790    In particular, this specification takes no position on case
    791    sensitivity in non-INBOX mailbox names.  Some server implementations
    792    are fully case-sensitive; others preserve case of a newly-created
    793    name but otherwise are case-insensitive; and yet others coerce names
    794    to a particular case.  Client implementations MUST interact with any
    795    of these.  If a server implementation interprets non-INBOX mailbox
    796    names as case-insensitive, it MUST treat names using the
    797    international naming convention specially as described in section
    798    5.1.3.
    799 
    800    There are certain client considerations when creating a new mailbox
    801    name:
    802 
    803    1)    Any character which is one of the atom-specials (see the Formal
    804          Syntax) will require that the mailbox name be represented as a
    805          quoted string or literal.
    806 
    807    2)    CTL and other non-graphic characters are difficult to represent
    808          in a user interface and are best avoided.
    809 
    810    3)    Although the list-wildcard characters ("%" and "*") are valid
    811          in a mailbox name, it is difficult to use such mailbox names
    812          with the LIST and LSUB commands due to the conflict with
    813          wildcard interpretation.
    814 
    815    4)    Usually, a character (determined by the server implementation)
    816          is reserved to delimit levels of hierarchy.
    817 
    818    5)    Two characters, "#" and "&", have meanings by convention, and
    819          should be avoided except when used in that convention.
    820 
    821 5.1.1.  Mailbox Hierarchy Naming
    822 
    823    If it is desired to export hierarchical mailbox names, mailbox names
    824    MUST be left-to-right hierarchical using a single character to
    825    separate levels of hierarchy.  The same hierarchy separator character
    826    is used for all levels of hierarchy within a single name.
    827 
    828 5.1.2.  Mailbox Namespace Naming Convention
    829 
    830    By convention, the first hierarchical element of any mailbox name
    831    which begins with "#" identifies the "namespace" of the remainder of
    832    the name.  This makes it possible to disambiguate between different
    833    types of mailbox stores, each of which have their own namespaces.
    834 
    835         For example, implementations which offer access to USENET
    836         newsgroups MAY use the "#news" namespace to partition the
    837         USENET newsgroup namespace from that of other mailboxes.
    838         Thus, the comp.mail.misc newsgroup would have a mailbox
    839         name of "#news.comp.mail.misc", and the name
    840         "comp.mail.misc" can refer to a different object (e.g., a
    841         user's private mailbox).
    842 
    843 5.1.3.  Mailbox International Naming Convention
    844 
    845    By convention, international mailbox names in IMAP4rev1 are specified
    846    using a modified version of the UTF-7 encoding described in [UTF-7].
    847    Modified UTF-7 may also be usable in servers that implement an
    848    earlier version of this protocol.
    849 
    850    In modified UTF-7, printable US-ASCII characters, except for "&",
    851    represent themselves; that is, characters with octet values 0x20-0x25
    852    and 0x27-0x7e.  The character "&" (0x26) is represented by the
    853    two-octet sequence "&-".
    854 
    855    All other characters (octet values 0x00-0x1f and 0x7f-0xff) are
    856    represented in modified BASE64, with a further modification from
    857    [UTF-7] that "," is used instead of "/".  Modified BASE64 MUST NOT be
    858    used to represent any printing US-ASCII character which can represent
    859    itself.
    860 
    861    "&" is used to shift to modified BASE64 and "-" to shift back to
    862    US-ASCII.  There is no implicit shift from BASE64 to US-ASCII, and
    863    null shifts ("-&" while in BASE64; note that "&-" while in US-ASCII
    864    means "&") are not permitted.  However, all names start in US-ASCII,
    865    and MUST end in US-ASCII; that is, a name that ends with a non-ASCII
    866    ISO-10646 character MUST end with a "-").
    867 
    868    The purpose of these modifications is to correct the following
    869    problems with UTF-7:
    870 
    871       1) UTF-7 uses the "+" character for shifting; this conflicts with
    872          the common use of "+" in mailbox names, in particular USENET
    873          newsgroup names.
    874 
    875       2) UTF-7's encoding is BASE64 which uses the "/" character; this
    876          conflicts with the use of "/" as a popular hierarchy delimiter.
    877 
    878       3) UTF-7 prohibits the unencoded usage of "\"; this conflicts with
    879          the use of "\" as a popular hierarchy delimiter.
    880 
    881       4) UTF-7 prohibits the unencoded usage of "~"; this conflicts with
    882          the use of "~" in some servers as a home directory indicator.
    883 
    884       5) UTF-7 permits multiple alternate forms to represent the same
    885          string; in particular, printable US-ASCII characters can be
    886          represented in encoded form.
    887 
    888       Although modified UTF-7 is a convention, it establishes certain
    889       requirements on server handling of any mailbox name with an
    890       embedded "&" character.  In particular, server implementations
    891       MUST preserve the exact form of the modified BASE64 portion of a
    892       modified UTF-7 name and treat that text as case-sensitive, even if
    893       names are otherwise case-insensitive or case-folded.
    894 
    895       Server implementations SHOULD verify that any mailbox name with an
    896       embedded "&" character, used as an argument to CREATE, is: in the
    897       correctly modified UTF-7 syntax, has no superfluous shifts, and
    898       has no encoding in modified BASE64 of any printing US-ASCII
    899       character which can represent itself.  However, client
    900       implementations MUST NOT depend upon the server doing this, and
    901       SHOULD NOT attempt to create a mailbox name with an embedded "&"
    902       character unless it complies with the modified UTF-7 syntax.
    903 
    904       Server implementations which export a mail store that does not
    905       follow the modified UTF-7 convention MUST convert to modified
    906       UTF-7 any mailbox name that contains either non-ASCII characters
    907       or the "&" character.
    908 
    909            For example, here is a mailbox name which mixes English,
    910            Chinese, and Japanese text:
    911            ~peter/mail/&U,BTFw-/&ZeVnLIqe-
    912 
    913            For example, the string "&Jjo!" is not a valid mailbox
    914            name because it does not contain a shift to US-ASCII
    915            before the "!".  The correct form is "&Jjo-!".  The
    916            string "&U,BTFw-&ZeVnLIqe-" is not permitted because it
    917            contains a superfluous shift.  The correct form is
    918            "&U,BTF2XlZyyKng-".
    919 
    920 5.2.    Mailbox Size and Message Status Updates
    921 
    922    At any time, a server can send data that the client did not request.
    923    Sometimes, such behavior is REQUIRED.  For example, agents other than
    924    the server MAY add messages to the mailbox (e.g., new message
    925    delivery), change the flags of the messages in the mailbox (e.g.,
    926    simultaneous access to the same mailbox by multiple agents), or even
    927    remove messages from the mailbox.  A server MUST send mailbox size
    928    updates automatically if a mailbox size change is observed during the
    929    processing of a command.  A server SHOULD send message flag updates
    930    automatically, without requiring the client to request such updates
    931    explicitly.
    932 
    933    Special rules exist for server notification of a client about the
    934    removal of messages to prevent synchronization errors; see the
    935    description of the EXPUNGE response for more detail.  In particular,
    936    it is NOT permitted to send an EXISTS response that would reduce the
    937    number of messages in the mailbox; only the EXPUNGE response can do
    938    this.
    939 
    940    Regardless of what implementation decisions a client makes on
    941    remembering data from the server, a client implementation MUST record
    942    mailbox size updates.  It MUST NOT assume that any command after the
    943    initial mailbox selection will return the size of the mailbox.
    944 
    945 5.3.    Response when no Command in Progress
    946 
    947    Server implementations are permitted to send an untagged response
    948    (except for EXPUNGE) while there is no command in progress.  Server
    949    implementations that send such responses MUST deal with flow control
    950    considerations.  Specifically, they MUST either (1) verify that the
    951    size of the data does not exceed the underlying transport's available
    952    window size, or (2) use non-blocking writes.
    953 
    954 5.4.    Autologout Timer
    955 
    956    If a server has an inactivity autologout timer, the duration of that
    957    timer MUST be at least 30 minutes.  The receipt of ANY command from
    958    the client during that interval SHOULD suffice to reset the
    959    autologout timer.
    960 
    961 5.5.    Multiple Commands in Progress
    962 
    963    The client MAY send another command without waiting for the
    964    completion result response of a command, subject to ambiguity rules
    965    (see below) and flow control constraints on the underlying data
    966    stream.  Similarly, a server MAY begin processing another command
    967    before processing the current command to completion, subject to
    968    ambiguity rules.  However, any command continuation request responses
    969    and command continuations MUST be negotiated before any subsequent
    970    command is initiated.
    971 
    972    The exception is if an ambiguity would result because of a command
    973    that would affect the results of other commands.  Clients MUST NOT
    974    send multiple commands without waiting if an ambiguity would result.
    975    If the server detects a possible ambiguity, it MUST execute commands
    976    to completion in the order given by the client.
    977 
    978    The most obvious example of ambiguity is when a command would affect
    979    the results of another command, e.g., a FETCH of a message's flags
    980    and a STORE of that same message's flags.
    981 
    982    A non-obvious ambiguity occurs with commands that permit an untagged
    983    EXPUNGE response (commands other than FETCH, STORE, and SEARCH),
    984    since an untagged EXPUNGE response can invalidate sequence numbers in
    985    a subsequent command.  This is not a problem for FETCH, STORE, or
    986    SEARCH commands because servers are prohibited from sending EXPUNGE
    987    responses while any of those commands are in progress.  Therefore, if
    988    the client sends any command other than FETCH, STORE, or SEARCH, it
    989    MUST wait for the completion result response before sending a command
    990    with message sequence numbers.
    991 
    992         Note: UID FETCH, UID STORE, and UID SEARCH are different
    993         commands from FETCH, STORE, and SEARCH.  If the client
    994         sends a UID command, it must wait for a completion result
    995         response before sending a command with message sequence
    996         numbers.
    997 
    998    For example, the following non-waiting command sequences are invalid:
    999 
   1000       FETCH + NOOP + STORE
   1001       STORE + COPY + FETCH
   1002       COPY + COPY
   1003       CHECK + FETCH
   1004 
   1005    The following are examples of valid non-waiting command sequences:
   1006 
   1007       FETCH + STORE + SEARCH + CHECK
   1008       STORE + COPY + EXPUNGE
   1009 
   1010       UID SEARCH + UID SEARCH may be valid or invalid as a non-waiting
   1011       command sequence, depending upon whether or not the second UID
   1012       SEARCH contains message sequence numbers.
   1013 
   1014 6.      Client Commands
   1015 
   1016    IMAP4rev1 commands are described in this section.  Commands are
   1017    organized by the state in which the command is permitted.  Commands
   1018    which are permitted in multiple states are listed in the minimum
   1019    permitted state (for example, commands valid in authenticated and
   1020    selected state are listed in the authenticated state commands).
   1021 
   1022    Command arguments, identified by "Arguments:" in the command
   1023    descriptions below, are described by function, not by syntax.  The
   1024    precise syntax of command arguments is described in the Formal Syntax
   1025    section.
   1026 
   1027    Some commands cause specific server responses to be returned; these
   1028    are identified by "Responses:" in the command descriptions below.
   1029    See the response descriptions in the Responses section for
   1030    information on these responses, and the Formal Syntax section for the
   1031    precise syntax of these responses.  It is possible for server data to
   1032    be transmitted as a result of any command.  Thus, commands that do
   1033    not specifically require server data specify "no specific responses
   1034    for this command" instead of "none".
   1035 
   1036    The "Result:" in the command description refers to the possible
   1037    tagged status responses to a command, and any special interpretation
   1038    of these status responses.
   1039 
   1040    The state of a connection is only changed by successful commands
   1041    which are documented as changing state.  A rejected command (BAD
   1042    response) never changes the state of the connection or of the
   1043    selected mailbox.  A failed command (NO response) generally does not
   1044    change the state of the connection or of the selected mailbox; the
   1045    exception being the SELECT and EXAMINE commands.
   1046 
   1047 6.1.    Client Commands - Any State
   1048 
   1049    The following commands are valid in any state: CAPABILITY, NOOP, and
   1050    LOGOUT.
   1051 
   1052 6.1.1.  CAPABILITY Command
   1053 
   1054    Arguments:  none
   1055 
   1056    Responses:  REQUIRED untagged response: CAPABILITY
   1057 
   1058    Result:     OK - capability completed
   1059                BAD - command unknown or arguments invalid
   1060 
   1061       The CAPABILITY command requests a listing of capabilities that the
   1062       server supports.  The server MUST send a single untagged
   1063       CAPABILITY response with "IMAP4rev1" as one of the listed
   1064       capabilities before the (tagged) OK response.
   1065 
   1066       A capability name which begins with "AUTH=" indicates that the
   1067       server supports that particular authentication mechanism.  All
   1068       such names are, by definition, part of this specification.  For
   1069       example, the authorization capability for an experimental
   1070       "blurdybloop" authenticator would be "AUTH=XBLURDYBLOOP" and not
   1071       "XAUTH=BLURDYBLOOP" or "XAUTH=XBLURDYBLOOP".
   1072 
   1073       Other capability names refer to extensions, revisions, or
   1074       amendments to this specification.  See the documentation of the
   1075       CAPABILITY response for additional information.  No capabilities,
   1076       beyond the base IMAP4rev1 set defined in this specification, are
   1077       enabled without explicit client action to invoke the capability.
   1078 
   1079       Client and server implementations MUST implement the STARTTLS,
   1080       LOGINDISABLED, and AUTH=PLAIN (described in [IMAP-TLS])
   1081       capabilities.  See the Security Considerations section for
   1082       important information.
   1083 
   1084       See the section entitled "Client Commands -
   1085       Experimental/Expansion" for information about the form of site or
   1086       implementation-specific capabilities.
   1087 
   1088    Example:    C: abcd CAPABILITY
   1089                S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI
   1090                LOGINDISABLED
   1091                S: abcd OK CAPABILITY completed
   1092                C: efgh STARTTLS
   1093                S: efgh OK STARTLS completed
   1094                <TLS negotiation, further commands are under [TLS] layer>
   1095                C: ijkl CAPABILITY
   1096                S: * CAPABILITY IMAP4rev1 AUTH=GSSAPI AUTH=PLAIN
   1097                S: ijkl OK CAPABILITY completed
   1098 
   1099 6.1.2.  NOOP Command
   1100 
   1101    Arguments:  none
   1102 
   1103    Responses:  no specific responses for this command (but see below)
   1104 
   1105    Result:     OK - noop completed
   1106                BAD - command unknown or arguments invalid
   1107 
   1108       The NOOP command always succeeds.  It does nothing.
   1109 
   1110       Since any command can return a status update as untagged data, the
   1111       NOOP command can be used as a periodic poll for new messages or
   1112       message status updates during a period of inactivity (this is the
   1113       preferred method to do this).  The NOOP command can also be used
   1114       to reset any inactivity autologout timer on the server.
   1115 
   1116    Example:    C: a002 NOOP
   1117                S: a002 OK NOOP completed
   1118                   . . .
   1119                C: a047 NOOP
   1120                S: * 22 EXPUNGE
   1121                S: * 23 EXISTS
   1122                S: * 3 RECENT
   1123                S: * 14 FETCH (FLAGS (\Seen \Deleted))
   1124                S: a047 OK NOOP completed
   1125 
   1126 6.1.3.  LOGOUT Command
   1127 
   1128    Arguments:  none
   1129 
   1130    Responses:  REQUIRED untagged response: BYE
   1131 
   1132    Result:     OK - logout completed
   1133                BAD - command unknown or arguments invalid
   1134 
   1135       The LOGOUT command informs the server that the client is done with
   1136       the connection.  The server MUST send a BYE untagged response
   1137       before the (tagged) OK response, and then close the network
   1138       connection.
   1139 
   1140    Example:    C: A023 LOGOUT
   1141                S: * BYE IMAP4rev1 Server logging out
   1142                S: A023 OK LOGOUT completed
   1143                (Server and client then close the connection)
   1144 
   1145 6.2.    Client Commands - Not Authenticated State
   1146 
   1147    In the not authenticated state, the AUTHENTICATE or LOGIN command
   1148    establishes authentication and enters the authenticated state.  The
   1149    AUTHENTICATE command provides a general mechanism for a variety of
   1150    authentication techniques, privacy protection, and integrity
   1151    checking; whereas the LOGIN command uses a traditional user name and
   1152    plaintext password pair and has no means of establishing privacy
   1153    protection or integrity checking.
   1154 
   1155    The STARTTLS command is an alternate form of establishing session
   1156    privacy protection and integrity checking, but does not establish
   1157    authentication or enter the authenticated state.
   1158 
   1159    Server implementations MAY allow access to certain mailboxes without
   1160    establishing authentication.  This can be done by means of the
   1161    ANONYMOUS [SASL] authenticator described in [ANONYMOUS].  An older
   1162    convention is a LOGIN command using the userid "anonymous"; in this
   1163    case, a password is required although the server may choose to accept
   1164    any password.  The restrictions placed on anonymous users are
   1165    implementation-dependent.
   1166 
   1167    Once authenticated (including as anonymous), it is not possible to
   1168    re-enter not authenticated state.
   1169 
   1170    In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
   1171    the following commands are valid in the not authenticated state:
   1172    STARTTLS, AUTHENTICATE and LOGIN.  See the Security Considerations
   1173    section for important information about these commands.
   1174 
   1175 6.2.1.  STARTTLS Command
   1176 
   1177    Arguments:  none
   1178 
   1179    Responses:  no specific response for this command
   1180 
   1181    Result:     OK - starttls completed, begin TLS negotiation
   1182                BAD - command unknown or arguments invalid
   1183 
   1184       A [TLS] negotiation begins immediately after the CRLF at the end
   1185       of the tagged OK response from the server.  Once a client issues a
   1186       STARTTLS command, it MUST NOT issue further commands until a
   1187       server response is seen and the [TLS] negotiation is complete.
   1188 
   1189       The server remains in the non-authenticated state, even if client
   1190       credentials are supplied during the [TLS] negotiation.  This does
   1191       not preclude an authentication mechanism such as EXTERNAL (defined
   1192       in [SASL]) from using client identity determined by the [TLS]
   1193       negotiation.
   1194 
   1195       Once [TLS] has been started, the client MUST discard cached
   1196       information about server capabilities and SHOULD re-issue the
   1197       CAPABILITY command.  This is necessary to protect against man-in-
   1198       the-middle attacks which alter the capabilities list prior to
   1199       STARTTLS.  The server MAY advertise different capabilities after
   1200       STARTTLS.
   1201 
   1202    Example:    C: a001 CAPABILITY
   1203                S: * CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED
   1204                S: a001 OK CAPABILITY completed
   1205                C: a002 STARTTLS
   1206                S: a002 OK Begin TLS negotiation now
   1207                <TLS negotiation, further commands are under [TLS] layer>
   1208                C: a003 CAPABILITY
   1209                S: * CAPABILITY IMAP4rev1 AUTH=PLAIN
   1210                S: a003 OK CAPABILITY completed
   1211                C: a004 LOGIN joe password
   1212                S: a004 OK LOGIN completed
   1213 
   1214 6.2.2.  AUTHENTICATE Command
   1215 
   1216    Arguments:  authentication mechanism name
   1217 
   1218    Responses:  continuation data can be requested
   1219 
   1220    Result:     OK - authenticate completed, now in authenticated state
   1221                NO - authenticate failure: unsupported authentication
   1222                     mechanism, credentials rejected
   1223                BAD - command unknown or arguments invalid,
   1224                     authentication exchange cancelled
   1225 
   1226       The AUTHENTICATE command indicates a [SASL] authentication
   1227       mechanism to the server.  If the server supports the requested
   1228       authentication mechanism, it performs an authentication protocol
   1229       exchange to authenticate and identify the client.  It MAY also
   1230       negotiate an OPTIONAL security layer for subsequent protocol
   1231       interactions.  If the requested authentication mechanism is not
   1232       supported, the server SHOULD reject the AUTHENTICATE command by
   1233       sending a tagged NO response.
   1234 
   1235       The AUTHENTICATE command does not support the optional "initial
   1236       response" feature of [SASL].  Section 5.1 of [SASL] specifies how
   1237       to handle an authentication mechanism which uses an initial
   1238       response.
   1239 
   1240       The service name specified by this protocol's profile of [SASL] is
   1241       "imap".
   1242 
   1243       The authentication protocol exchange consists of a series of
   1244       server challenges and client responses that are specific to the
   1245       authentication mechanism.  A server challenge consists of a
   1246       command continuation request response with the "+" token followed
   1247       by a BASE64 encoded string.  The client response consists of a
   1248       single line consisting of a BASE64 encoded string.  If the client
   1249       wishes to cancel an authentication exchange, it issues a line
   1250       consisting of a single "*".  If the server receives such a
   1251       response, it MUST reject the AUTHENTICATE command by sending a
   1252       tagged BAD response.
   1253 
   1254       If a security layer is negotiated through the [SASL]
   1255       authentication exchange, it takes effect immediately following the
   1256       CRLF that concludes the authentication exchange for the client,
   1257       and the CRLF of the tagged OK response for the server.
   1258 
   1259       While client and server implementations MUST implement the
   1260       AUTHENTICATE command itself, it is not required to implement any
   1261       authentication mechanisms other than the PLAIN mechanism described
   1262 
   1263       in [IMAP-TLS].  Also, an authentication mechanism is not required
   1264       to support any security layers.
   1265 
   1266            Note: a server implementation MUST implement a
   1267            configuration in which it does NOT permit any plaintext
   1268            password mechanisms, unless either the STARTTLS command
   1269            has been negotiated or some other mechanism that
   1270            protects the session from password snooping has been
   1271            provided.  Server sites SHOULD NOT use any configuration
   1272            which permits a plaintext password mechanism without
   1273            such a protection mechanism against password snooping.
   1274            Client and server implementations SHOULD implement
   1275            additional [SASL] mechanisms that do not use plaintext
   1276            passwords, such the GSSAPI mechanism described in [SASL]
   1277            and/or the [DIGEST-MD5] mechanism.
   1278 
   1279       Servers and clients can support multiple authentication
   1280       mechanisms.  The server SHOULD list its supported authentication
   1281       mechanisms in the response to the CAPABILITY command so that the
   1282       client knows which authentication mechanisms to use.
   1283 
   1284       A server MAY include a CAPABILITY response code in the tagged OK
   1285       response of a successful AUTHENTICATE command in order to send
   1286       capabilities automatically.  It is unnecessary for a client to
   1287       send a separate CAPABILITY command if it recognizes these
   1288       automatic capabilities.  This should only be done if a security
   1289       layer was not negotiated by the AUTHENTICATE command, because the
   1290       tagged OK response as part of an AUTHENTICATE command is not
   1291       protected by encryption/integrity checking.  [SASL] requires the
   1292       client to re-issue a CAPABILITY command in this case.
   1293 
   1294       If an AUTHENTICATE command fails with a NO response, the client
   1295       MAY try another authentication mechanism by issuing another
   1296       AUTHENTICATE command.  It MAY also attempt to authenticate by
   1297       using the LOGIN command (see section 6.2.3 for more detail).  In
   1298       other words, the client MAY request authentication types in
   1299       decreasing order of preference, with the LOGIN command as a last
   1300       resort.
   1301 
   1302       The authorization identity passed from the client to the server
   1303       during the authentication exchange is interpreted by the server as
   1304       the user name whose privileges the client is requesting.
   1305 
   1306    Example:    S: * OK IMAP4rev1 Server
   1307                C: A001 AUTHENTICATE GSSAPI
   1308                S: +
   1309                C: YIIB+wYJKoZIhvcSAQICAQBuggHqMIIB5qADAgEFoQMCAQ6iBw
   1310                   MFACAAAACjggEmYYIBIjCCAR6gAwIBBaESGxB1Lndhc2hpbmd0
   1311                   b24uZWR1oi0wK6ADAgEDoSQwIhsEaW1hcBsac2hpdmFtcy5jYW
   1312                   Mud2FzaGluZ3Rvbi5lZHWjgdMwgdCgAwIBAaEDAgEDooHDBIHA
   1313                   cS1GSa5b+fXnPZNmXB9SjL8Ollj2SKyb+3S0iXMljen/jNkpJX
   1314                   AleKTz6BQPzj8duz8EtoOuNfKgweViyn/9B9bccy1uuAE2HI0y
   1315                   C/PHXNNU9ZrBziJ8Lm0tTNc98kUpjXnHZhsMcz5Mx2GR6dGknb
   1316                   I0iaGcRerMUsWOuBmKKKRmVMMdR9T3EZdpqsBd7jZCNMWotjhi
   1317                   vd5zovQlFqQ2Wjc2+y46vKP/iXxWIuQJuDiisyXF0Y8+5GTpAL
   1318                   pHDc1/pIGmMIGjoAMCAQGigZsEgZg2on5mSuxoDHEA1w9bcW9n
   1319                   FdFxDKpdrQhVGVRDIzcCMCTzvUboqb5KjY1NJKJsfjRQiBYBdE
   1320                   NKfzK+g5DlV8nrw81uOcP8NOQCLR5XkoMHC0Dr/80ziQzbNqhx
   1321                   O6652Npft0LQwJvenwDI13YxpwOdMXzkWZN/XrEqOWp6GCgXTB
   1322                   vCyLWLlWnbaUkZdEYbKHBPjd8t/1x5Yg==
   1323                S: + YGgGCSqGSIb3EgECAgIAb1kwV6ADAgEFoQMCAQ+iSzBJoAMC
   1324                   AQGiQgRAtHTEuOP2BXb9sBYFR4SJlDZxmg39IxmRBOhXRKdDA0
   1325                   uHTCOT9Bq3OsUTXUlk0CsFLoa8j+gvGDlgHuqzWHPSQg==
   1326                C:
   1327                S: + YDMGCSqGSIb3EgECAgIBAAD/////6jcyG4GE3KkTzBeBiVHe
   1328                   ceP2CWY0SR0fAQAgAAQEBAQ=
   1329                C: YDMGCSqGSIb3EgECAgIBAAD/////3LQBHXTpFfZgrejpLlLImP
   1330                   wkhbfa2QteAQAgAG1yYwE=
   1331                S: A001 OK GSSAPI authentication successful
   1332 
   1333         Note: The line breaks within server challenges and client
   1334         responses are for editorial clarity and are not in real
   1335         authenticators.
   1336 
   1337 6.2.3.  LOGIN Command
   1338 
   1339    Arguments:  user name
   1340                password
   1341 
   1342    Responses:  no specific responses for this command
   1343 
   1344    Result:     OK - login completed, now in authenticated state
   1345                NO - login failure: user name or password rejected
   1346                BAD - command unknown or arguments invalid
   1347 
   1348       The LOGIN command identifies the client to the server and carries
   1349       the plaintext password authenticating this user.
   1350 
   1351       A server MAY include a CAPABILITY response code in the tagged OK
   1352       response to a successful LOGIN command in order to send
   1353       capabilities automatically.  It is unnecessary for a client to
   1354       send a separate CAPABILITY command if it recognizes these
   1355       automatic capabilities.
   1356 
   1357    Example:    C: a001 LOGIN SMITH SESAME
   1358                S: a001 OK LOGIN completed
   1359 
   1360         Note: Use of the LOGIN command over an insecure network
   1361         (such as the Internet) is a security risk, because anyone
   1362         monitoring network traffic can obtain plaintext passwords.
   1363         The LOGIN command SHOULD NOT be used except as a last
   1364         resort, and it is recommended that client implementations
   1365         have a means to disable any automatic use of the LOGIN
   1366         command.
   1367 
   1368         Unless either the STARTTLS command has been negotiated or
   1369         some other mechanism that protects the session from
   1370         password snooping has been provided, a server
   1371         implementation MUST implement a configuration in which it
   1372         advertises the LOGINDISABLED capability and does NOT permit
   1373         the LOGIN command.  Server sites SHOULD NOT use any
   1374         configuration which permits the LOGIN command without such
   1375         a protection mechanism against password snooping.  A client
   1376         implementation MUST NOT send a LOGIN command if the
   1377         LOGINDISABLED capability is advertised.
   1378 
   1379 6.3.    Client Commands - Authenticated State
   1380 
   1381    In the authenticated state, commands that manipulate mailboxes as
   1382    atomic entities are permitted.  Of these commands, the SELECT and
   1383    EXAMINE commands will select a mailbox for access and enter the
   1384    selected state.
   1385 
   1386    In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
   1387    the following commands are valid in the authenticated state: SELECT,
   1388    EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB,
   1389    STATUS, and APPEND.
   1390 
   1391 6.3.1.  SELECT Command
   1392 
   1393    Arguments:  mailbox name
   1394 
   1395    Responses:  REQUIRED untagged responses: FLAGS, EXISTS, RECENT
   1396                REQUIRED OK untagged responses:  UNSEEN,  PERMANENTFLAGS,
   1397                UIDNEXT, UIDVALIDITY
   1398 
   1399    Result:     OK - select completed, now in selected state
   1400                NO - select failure, now in authenticated state: no
   1401                     such mailbox, can't access mailbox
   1402                BAD - command unknown or arguments invalid
   1403 
   1404       The SELECT command selects a mailbox so that messages in the
   1405       mailbox can be accessed.  Before returning an OK to the client,
   1406       the server MUST send the following untagged data to the client.
   1407       Note that earlier versions of this protocol only required the
   1408       FLAGS, EXISTS, and RECENT untagged data; consequently, client
   1409       implementations SHOULD implement default behavior for missing data
   1410       as discussed with the individual item.
   1411 
   1412          FLAGS       Defined flags in the mailbox.  See the description
   1413                      of the FLAGS response for more detail.
   1414 
   1415          <n> EXISTS  The number of messages in the mailbox.  See the
   1416                      description of the EXISTS response for more detail.
   1417 
   1418          <n> RECENT  The number of messages with the \Recent flag set.
   1419                      See the description of the RECENT response for more
   1420                      detail.
   1421 
   1422          OK [UNSEEN <n>]
   1423                      The message sequence number of the first unseen
   1424                      message in the mailbox.  If this is missing, the
   1425                      client can not make any assumptions about the first
   1426                      unseen message in the mailbox, and needs to issue a
   1427                      SEARCH command if it wants to find it.
   1428 
   1429          OK [PERMANENTFLAGS (<list of flags>)]
   1430                      A list of message flags that the client can change
   1431                      permanently.  If this is missing, the client should
   1432                      assume that all flags can be changed permanently.
   1433 
   1434          OK [UIDNEXT <n>]
   1435                      The next unique identifier value.  Refer to section
   1436                      2.3.1.1 for more information.  If this is missing,
   1437                      the client can not make any assumptions about the
   1438                      next unique identifier value.
   1439 
   1440          OK [UIDVALIDITY <n>]
   1441                      The unique identifier validity value.  Refer to
   1442                      section 2.3.1.1 for more information.  If this is
   1443                      missing, the server does not support unique
   1444                      identifiers.
   1445 
   1446       Only one mailbox can be selected at a time in a connection;
   1447       simultaneous access to multiple mailboxes requires multiple
   1448       connections.  The SELECT command automatically deselects any
   1449       currently selected mailbox before attempting the new selection.
   1450       Consequently, if a mailbox is selected and a SELECT command that
   1451       fails is attempted, no mailbox is selected.
   1452 
   1453       If the client is permitted to modify the mailbox, the server
   1454       SHOULD prefix the text of the tagged OK response with the
   1455       "[READ-WRITE]" response code.
   1456 
   1457       If the client is not permitted to modify the mailbox but is
   1458       permitted read access, the mailbox is selected as read-only, and
   1459       the server MUST prefix the text of the tagged OK response to
   1460       SELECT with the "[READ-ONLY]" response code.  Read-only access
   1461       through SELECT differs from the EXAMINE command in that certain
   1462       read-only mailboxes MAY permit the change of permanent state on a
   1463       per-user (as opposed to global) basis.  Netnews messages marked in
   1464       a server-based .newsrc file are an example of such per-user
   1465       permanent state that can be modified with read-only mailboxes.
   1466 
   1467    Example:    C: A142 SELECT INBOX
   1468                S: * 172 EXISTS
   1469                S: * 1 RECENT
   1470                S: * OK [UNSEEN 12] Message 12 is first unseen
   1471                S: * OK [UIDVALIDITY 3857529045] UIDs valid
   1472                S: * OK [UIDNEXT 4392] Predicted next UID
   1473                S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
   1474                S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
   1475                S: A142 OK [READ-WRITE] SELECT completed
   1476 
   1477 6.3.2.  EXAMINE Command
   1478 
   1479    Arguments:  mailbox name
   1480 
   1481    Responses:  REQUIRED untagged responses: FLAGS, EXISTS, RECENT
   1482                REQUIRED OK untagged responses:  UNSEEN,  PERMANENTFLAGS,
   1483                UIDNEXT, UIDVALIDITY
   1484 
   1485    Result:     OK - examine completed, now in selected state
   1486                NO - examine failure, now in authenticated state: no
   1487                     such mailbox, can't access mailbox
   1488                BAD - command unknown or arguments invalid
   1489 
   1490       The EXAMINE command is identical to SELECT and returns the same
   1491       output; however, the selected mailbox is identified as read-only.
   1492       No changes to the permanent state of the mailbox, including
   1493       per-user state, are permitted; in particular, EXAMINE MUST NOT
   1494       cause messages to lose the \Recent flag.
   1495 
   1496       The text of the tagged OK response to the EXAMINE command MUST
   1497       begin with the "[READ-ONLY]" response code.
   1498 
   1499    Example:    C: A932 EXAMINE blurdybloop
   1500                S: * 17 EXISTS
   1501                S: * 2 RECENT
   1502                S: * OK [UNSEEN 8] Message 8 is first unseen
   1503                S: * OK [UIDVALIDITY 3857529045] UIDs valid
   1504                S: * OK [UIDNEXT 4392] Predicted next UID
   1505                S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
   1506                S: * OK [PERMANENTFLAGS ()] No permanent flags permitted
   1507                S: A932 OK [READ-ONLY] EXAMINE completed
   1508 
   1509 6.3.3.  CREATE Command
   1510 
   1511    Arguments:  mailbox name
   1512 
   1513    Responses:  no specific responses for this command
   1514 
   1515    Result:     OK - create completed
   1516                NO - create failure: can't create mailbox with that name
   1517                BAD - command unknown or arguments invalid
   1518 
   1519       The CREATE command creates a mailbox with the given name.  An OK
   1520       response is returned only if a new mailbox with that name has been
   1521       created.  It is an error to attempt to create INBOX or a mailbox
   1522       with a name that refers to an extant mailbox.  Any error in
   1523       creation will return a tagged NO response.
   1524 
   1525       If the mailbox name is suffixed with the server's hierarchy
   1526       separator character (as returned from the server by a LIST
   1527       command), this is a declaration that the client intends to create
   1528       mailbox names under this name in the hierarchy.  Server
   1529       implementations that do not require this declaration MUST ignore
   1530       the declaration.  In any case, the name created is without the
   1531       trailing hierarchy delimiter.
   1532 
   1533       If the server's hierarchy separator character appears elsewhere in
   1534       the name, the server SHOULD create any superior hierarchical names
   1535       that are needed for the CREATE command to be successfully
   1536       completed.  In other words, an attempt to create "foo/bar/zap" on
   1537       a server in which "/" is the hierarchy separator character SHOULD
   1538       create foo/ and foo/bar/ if they do not already exist.
   1539 
   1540       If a new mailbox is created with the same name as a mailbox which
   1541       was deleted, its unique identifiers MUST be greater than any
   1542       unique identifiers used in the previous incarnation of the mailbox
   1543       UNLESS the new incarnation has a different unique identifier
   1544       validity value.  See the description of the UID command for more
   1545       detail.
   1546 
   1547    Example:    C: A003 CREATE owatagusiam/
   1548                S: A003 OK CREATE completed
   1549                C: A004 CREATE owatagusiam/blurdybloop
   1550                S: A004 OK CREATE completed
   1551 
   1552         Note: The interpretation of this example depends on whether
   1553         "/" was returned as the hierarchy separator from LIST.  If
   1554         "/" is the hierarchy separator, a new level of hierarchy
   1555         named "owatagusiam" with a member called "blurdybloop" is
   1556         created.  Otherwise, two mailboxes at the same hierarchy
   1557         level are created.
   1558 
   1559 6.3.4.  DELETE Command
   1560 
   1561    Arguments:  mailbox name
   1562 
   1563    Responses:  no specific responses for this command
   1564 
   1565    Result:     OK - delete completed
   1566                NO - delete failure: can't delete mailbox with that name
   1567                BAD - command unknown or arguments invalid
   1568 
   1569       The DELETE command permanently removes the mailbox with the given
   1570       name.  A tagged OK response is returned only if the mailbox has
   1571       been deleted.  It is an error to attempt to delete INBOX or a
   1572       mailbox name that does not exist.
   1573 
   1574       The DELETE command MUST NOT remove inferior hierarchical names.
   1575       For example, if a mailbox "foo" has an inferior "foo.bar"
   1576       (assuming "." is the hierarchy delimiter character), removing
   1577       "foo" MUST NOT remove "foo.bar".  It is an error to attempt to
   1578       delete a name that has inferior hierarchical names and also has
   1579       the \Noselect mailbox name attribute (see the description of the
   1580       LIST response for more details).
   1581 
   1582       It is permitted to delete a name that has inferior hierarchical
   1583       names and does not have the \Noselect mailbox name attribute.  In
   1584       this case, all messages in that mailbox are removed, and the name
   1585       will acquire the \Noselect mailbox name attribute.
   1586 
   1587       The value of the highest-used unique identifier of the deleted
   1588       mailbox MUST be preserved so that a new mailbox created with the
   1589       same name will not reuse the identifiers of the former
   1590       incarnation, UNLESS the new incarnation has a different unique
   1591       identifier validity value.  See the description of the UID command
   1592       for more detail.
   1593 
   1594    Examples:   C: A682 LIST "" *
   1595                S: * LIST () "/" blurdybloop
   1596                S: * LIST (\Noselect) "/" foo
   1597                S: * LIST () "/" foo/bar
   1598                S: A682 OK LIST completed
   1599                C: A683 DELETE blurdybloop
   1600                S: A683 OK DELETE completed
   1601                C: A684 DELETE foo
   1602                S: A684 NO Name "foo" has inferior hierarchical names
   1603                C: A685 DELETE foo/bar
   1604                S: A685 OK DELETE Completed
   1605                C: A686 LIST "" *
   1606                S: * LIST (\Noselect) "/" foo
   1607                S: A686 OK LIST completed
   1608                C: A687 DELETE foo
   1609                S: A687 OK DELETE Completed
   1610 
   1611                C: A82 LIST "" *
   1612                S: * LIST () "." blurdybloop
   1613                S: * LIST () "." foo
   1614                S: * LIST () "." foo.bar
   1615                S: A82 OK LIST completed
   1616                C: A83 DELETE blurdybloop
   1617                S: A83 OK DELETE completed
   1618                C: A84 DELETE foo
   1619                S: A84 OK DELETE Completed
   1620                C: A85 LIST "" *
   1621                S: * LIST () "." foo.bar
   1622                S: A85 OK LIST completed
   1623                C: A86 LIST "" %
   1624                S: * LIST (\Noselect) "." foo
   1625                S: A86 OK LIST completed
   1626 
   1627 6.3.5.  RENAME Command
   1628 
   1629    Arguments:  existing mailbox name
   1630                new mailbox name
   1631 
   1632    Responses:  no specific responses for this command
   1633 
   1634    Result:     OK - rename completed
   1635                NO - rename failure: can't rename mailbox with that name,
   1636                     can't rename to mailbox with that name
   1637                BAD - command unknown or arguments invalid
   1638 
   1639       The RENAME command changes the name of a mailbox.  A tagged OK
   1640       response is returned only if the mailbox has been renamed.  It is
   1641       an error to attempt to rename from a mailbox name that does not
   1642       exist or to a mailbox name that already exists.  Any error in
   1643       renaming will return a tagged NO response.
   1644 
   1645       If the name has inferior hierarchical names, then the inferior
   1646       hierarchical names MUST also be renamed.  For example, a rename of
   1647       "foo" to "zap" will rename "foo/bar" (assuming "/" is the
   1648       hierarchy delimiter character) to "zap/bar".
   1649 
   1650       If the server's hierarchy separator character appears in the name,
   1651       the server SHOULD create any superior hierarchical names that are
   1652       needed for the RENAME command to complete successfully.  In other
   1653       words, an attempt to rename "foo/bar/zap" to baz/rag/zowie on a
   1654       server in which "/" is the hierarchy separator character SHOULD
   1655       create baz/ and baz/rag/ if they do not already exist.
   1656 
   1657       The value of the highest-used unique identifier of the old mailbox
   1658       name MUST be preserved so that a new mailbox created with the same
   1659       name will not reuse the identifiers of the former incarnation,
   1660       UNLESS the new incarnation has a different unique identifier
   1661       validity value.  See the description of the UID command for more
   1662       detail.
   1663 
   1664       Renaming INBOX is permitted, and has special behavior.  It moves
   1665       all messages in INBOX to a new mailbox with the given name,
   1666       leaving INBOX empty.  If the server implementation supports
   1667       inferior hierarchical names of INBOX, these are unaffected by a
   1668       rename of INBOX.
   1669 
   1670    Examples:   C: A682 LIST "" *
   1671                S: * LIST () "/" blurdybloop
   1672                S: * LIST (\Noselect) "/" foo
   1673                S: * LIST () "/" foo/bar
   1674                S: A682 OK LIST completed
   1675                C: A683 RENAME blurdybloop sarasoop
   1676                S: A683 OK RENAME completed
   1677                C: A684 RENAME foo zowie
   1678                S: A684 OK RENAME Completed
   1679                C: A685 LIST "" *
   1680                S: * LIST () "/" sarasoop
   1681                S: * LIST (\Noselect) "/" zowie
   1682                S: * LIST () "/" zowie/bar
   1683                S: A685 OK LIST completed
   1684 
   1685                C: Z432 LIST "" *
   1686                S: * LIST () "." INBOX
   1687                S: * LIST () "." INBOX.bar
   1688                S: Z432 OK LIST completed
   1689                C: Z433 RENAME INBOX old-mail
   1690                S: Z433 OK RENAME completed
   1691                C: Z434 LIST "" *
   1692                S: * LIST () "." INBOX
   1693                S: * LIST () "." INBOX.bar
   1694                S: * LIST () "." old-mail
   1695                S: Z434 OK LIST completed
   1696 
   1697 6.3.6.  SUBSCRIBE Command
   1698 
   1699    Arguments:  mailbox
   1700 
   1701    Responses:  no specific responses for this command
   1702 
   1703    Result:     OK - subscribe completed
   1704                NO - subscribe failure: can't subscribe to that name
   1705                BAD - command unknown or arguments invalid
   1706 
   1707       The SUBSCRIBE command adds the specified mailbox name to the
   1708       server's set of "active" or "subscribed" mailboxes as returned by
   1709       the LSUB command.  This command returns a tagged OK response only
   1710       if the subscription is successful.
   1711 
   1712       A server MAY validate the mailbox argument to SUBSCRIBE to verify
   1713       that it exists.  However, it MUST NOT unilaterally remove an
   1714       existing mailbox name from the subscription list even if a mailbox
   1715       by that name no longer exists.
   1716 
   1717            Note: This requirement is because a server site can
   1718            choose to routinely remove a mailbox with a well-known
   1719            name (e.g., "system-alerts") after its contents expire,
   1720            with the intention of recreating it when new contents
   1721            are appropriate.
   1722 
   1723    Example:    C: A002 SUBSCRIBE #news.comp.mail.mime
   1724                S: A002 OK SUBSCRIBE completed
   1725 
   1726 6.3.7.  UNSUBSCRIBE Command
   1727 
   1728    Arguments:  mailbox name
   1729 
   1730    Responses:  no specific responses for this command
   1731 
   1732    Result:     OK - unsubscribe completed
   1733                NO - unsubscribe failure: can't unsubscribe that name
   1734                BAD - command unknown or arguments invalid
   1735 
   1736       The UNSUBSCRIBE command removes the specified mailbox name from
   1737       the server's set of "active" or "subscribed" mailboxes as returned
   1738       by the LSUB command.  This command returns a tagged OK response
   1739       only if the unsubscription is successful.
   1740 
   1741    Example:    C: A002 UNSUBSCRIBE #news.comp.mail.mime
   1742                S: A002 OK UNSUBSCRIBE completed
   1743 
   1744 6.3.8.  LIST Command
   1745 
   1746    Arguments:  reference name
   1747                mailbox name with possible wildcards
   1748 
   1749    Responses:  untagged responses: LIST
   1750 
   1751    Result:     OK - list completed
   1752                NO - list failure: can't list that reference or name
   1753                BAD - command unknown or arguments invalid
   1754 
   1755       The LIST command returns a subset of names from the complete set
   1756       of all names available to the client.  Zero or more untagged LIST
   1757       replies are returned, containing the name attributes, hierarchy
   1758       delimiter, and name; see the description of the LIST reply for
   1759       more detail.
   1760 
   1761       The LIST command SHOULD return its data quickly, without undue
   1762       delay.  For example, it SHOULD NOT go to excess trouble to
   1763       calculate the \Marked or \Unmarked status or perform other
   1764       processing; if each name requires 1 second of processing, then a
   1765       list of 1200 names would take 20 minutes!
   1766 
   1767       An empty ("" string) reference name argument indicates that the
   1768       mailbox name is interpreted as by SELECT.  The returned mailbox
   1769       names MUST match the supplied mailbox name pattern.  A non-empty
   1770       reference name argument is the name of a mailbox or a level of
   1771       mailbox hierarchy, and indicates the context in which the mailbox
   1772       name is interpreted.
   1773 
   1774       An empty ("" string) mailbox name argument is a special request to
   1775       return the hierarchy delimiter and the root name of the name given
   1776       in the reference.  The value returned as the root MAY be the empty
   1777       string if the reference is non-rooted or is an empty string.  In
   1778       all cases, a hierarchy delimiter (or NIL if there is no hierarchy)
   1779       is returned.  This permits a client to get the hierarchy delimiter
   1780       (or find out that the mailbox names are flat) even when no
   1781       mailboxes by that name currently exist.
   1782 
   1783       The reference and mailbox name arguments are interpreted into a
   1784       canonical form that represents an unambiguous left-to-right
   1785       hierarchy.  The returned mailbox names will be in the interpreted
   1786       form.
   1787 
   1788            Note: The interpretation of the reference argument is
   1789            implementation-defined.  It depends upon whether the
   1790            server implementation has a concept of the "current
   1791            working directory" and leading "break out characters",
   1792            which override the current working directory.
   1793 
   1794            For example, on a server which exports a UNIX or NT
   1795            filesystem, the reference argument contains the current
   1796            working directory, and the mailbox name argument would
   1797            contain the name as interpreted in the current working
   1798            directory.
   1799 
   1800            If a server implementation has no concept of break out
   1801            characters, the canonical form is normally the reference
   1802            name appended with the mailbox name.  Note that if the
   1803            server implements the namespace convention (section
   1804            5.1.2), "#" is a break out character and must be treated
   1805            as such.
   1806 
   1807            If the reference argument is not a level of mailbox
   1808            hierarchy (that is, it is a \NoInferiors name), and/or
   1809            the reference argument does not end with the hierarchy
   1810            delimiter, it is implementation-dependent how this is
   1811            interpreted.  For example, a reference of "foo/bar" and
   1812            mailbox name of "rag/baz" could be interpreted as
   1813            "foo/bar/rag/baz", "foo/barrag/baz", or "foo/rag/baz".
   1814            A client SHOULD NOT use such a reference argument except
   1815            at the explicit request of the user.  A hierarchical
   1816            browser MUST NOT make any assumptions about server
   1817            interpretation of the reference unless the reference is
   1818            a level of mailbox hierarchy AND ends with the hierarchy
   1819            delimiter.
   1820 
   1821       Any part of the reference argument that is included in the
   1822       interpreted form SHOULD prefix the interpreted form.  It SHOULD
   1823       also be in the same form as the reference name argument.  This
   1824       rule permits the client to determine if the returned mailbox name
   1825       is in the context of the reference argument, or if something about
   1826       the mailbox argument overrode the reference argument.  Without
   1827       this rule, the client would have to have knowledge of the server's
   1828       naming semantics including what characters are "breakouts" that
   1829       override a naming context.
   1830 
   1831            For example, here are some examples of how references
   1832            and mailbox names might be interpreted on a UNIX-based
   1833            server:
   1834 
   1835                Reference     Mailbox Name  Interpretation
   1836                ------------  ------------  --------------
   1837                ~smith/Mail/  foo.*         ~smith/Mail/foo.*
   1838                archive/      %             archive/%
   1839                #news.        comp.mail.*   #news.comp.mail.*
   1840                ~smith/Mail/  /usr/doc/foo  /usr/doc/foo
   1841                archive/      ~fred/Mail/*  ~fred/Mail/*
   1842 
   1843            The first three examples demonstrate interpretations in
   1844            the context of the reference argument.  Note that
   1845            "~smith/Mail" SHOULD NOT be transformed into something
   1846            like "/u2/users/smith/Mail", or it would be impossible
   1847            for the client to determine that the interpretation was
   1848            in the context of the reference.
   1849 
   1850       The character "*" is a wildcard, and matches zero or more
   1851       characters at this position.  The character "%" is similar to "*",
   1852       but it does not match a hierarchy delimiter.  If the "%" wildcard
   1853       is the last character of a mailbox name argument, matching levels
   1854       of hierarchy are also returned.  If these levels of hierarchy are
   1855       not also selectable mailboxes, they are returned with the
   1856       \Noselect mailbox name attribute (see the description of the LIST
   1857       response for more details).
   1858 
   1859       Server implementations are permitted to "hide" otherwise
   1860       accessible mailboxes from the wildcard characters, by preventing
   1861       certain characters or names from matching a wildcard in certain
   1862       situations.  For example, a UNIX-based server might restrict the
   1863       interpretation of "*" so that an initial "/" character does not
   1864       match.
   1865 
   1866       The special name INBOX is included in the output from LIST, if
   1867       INBOX is supported by this server for this user and if the
   1868       uppercase string "INBOX" matches the interpreted reference and
   1869       mailbox name arguments with wildcards as described above.  The
   1870       criteria for omitting INBOX is whether SELECT INBOX will return
   1871       failure; it is not relevant whether the user's real INBOX resides
   1872       on this or some other server.
   1873 
   1874    Example:    C: A101 LIST "" ""
   1875                S: * LIST (\Noselect) "/" ""
   1876                S: A101 OK LIST Completed
   1877                C: A102 LIST #news.comp.mail.misc ""
   1878                S: * LIST (\Noselect) "." #news.
   1879                S: A102 OK LIST Completed
   1880                C: A103 LIST /usr/staff/jones ""
   1881                S: * LIST (\Noselect) "/" /
   1882                S: A103 OK LIST Completed
   1883                C: A202 LIST ~/Mail/ %
   1884                S: * LIST (\Noselect) "/" ~/Mail/foo
   1885                S: * LIST () "/" ~/Mail/meetings
   1886                S: A202 OK LIST completed
   1887 
   1888 6.3.9.  LSUB Command
   1889 
   1890    Arguments:  reference name
   1891                mailbox name with possible wildcards
   1892 
   1893    Responses:  untagged responses: LSUB
   1894 
   1895    Result:     OK - lsub completed
   1896                NO - lsub failure: can't list that reference or name
   1897                BAD - command unknown or arguments invalid
   1898 
   1899       The LSUB command returns a subset of names from the set of names
   1900       that the user has declared as being "active" or "subscribed".
   1901       Zero or more untagged LSUB replies are returned.  The arguments to
   1902       LSUB are in the same form as those for LIST.
   1903 
   1904       The returned untagged LSUB response MAY contain different mailbox
   1905       flags from a LIST untagged response.  If this should happen, the
   1906       flags in the untagged LIST are considered more authoritative.
   1907 
   1908       A special situation occurs when using LSUB with the % wildcard.
   1909       Consider what happens if "foo/bar" (with a hierarchy delimiter of
   1910       "/") is subscribed but "foo" is not.  A "%" wildcard to LSUB must
   1911       return foo, not foo/bar, in the LSUB response, and it MUST be
   1912       flagged with the \Noselect attribute.
   1913 
   1914       The server MUST NOT unilaterally remove an existing mailbox name
   1915       from the subscription list even if a mailbox by that name no
   1916       longer exists.
   1917 
   1918    Example:    C: A002 LSUB "#news." "comp.mail.*"
   1919                S: * LSUB () "." #news.comp.mail.mime
   1920                S: * LSUB () "." #news.comp.mail.misc
   1921                S: A002 OK LSUB completed
   1922                C: A003 LSUB "#news." "comp.%"
   1923                S: * LSUB (\NoSelect) "." #news.comp.mail
   1924                S: A003 OK LSUB completed
   1925 
   1926 6.3.10. STATUS Command
   1927 
   1928    Arguments:  mailbox name
   1929                status data item names
   1930 
   1931    Responses:  untagged responses: STATUS
   1932 
   1933    Result:     OK - status completed
   1934                NO - status failure: no status for that name
   1935                BAD - command unknown or arguments invalid
   1936 
   1937       The STATUS command requests the status of the indicated mailbox.
   1938       It does not change the currently selected mailbox, nor does it
   1939       affect the state of any messages in the queried mailbox (in
   1940       particular, STATUS MUST NOT cause messages to lose the \Recent
   1941       flag).
   1942 
   1943       The STATUS command provides an alternative to opening a second
   1944       IMAP4rev1 connection and doing an EXAMINE command on a mailbox to
   1945       query that mailbox's status without deselecting the current
   1946       mailbox in the first IMAP4rev1 connection.
   1947 
   1948       Unlike the LIST command, the STATUS command is not guaranteed to
   1949       be fast in its response.  Under certain circumstances, it can be
   1950       quite slow.  In some implementations, the server is obliged to
   1951       open the mailbox read-only internally to obtain certain status
   1952       information.  Also unlike the LIST command, the STATUS command
   1953       does not accept wildcards.
   1954 
   1955            Note: The STATUS command is intended to access the
   1956            status of mailboxes other than the currently selected
   1957            mailbox.  Because the STATUS command can cause the
   1958            mailbox to be opened internally, and because this
   1959            information is available by other means on the selected
   1960            mailbox, the STATUS command SHOULD NOT be used on the
   1961            currently selected mailbox.
   1962 
   1963            The STATUS command MUST NOT be used as a "check for new
   1964            messages in the selected mailbox" operation (refer to
   1965            sections 7, 7.3.1, and 7.3.2 for more information about
   1966            the proper method for new message checking).
   1967 
   1968            Because the STATUS command is not guaranteed to be fast
   1969            in its results, clients SHOULD NOT expect to be able to
   1970            issue many consecutive STATUS commands and obtain
   1971            reasonable performance.
   1972 
   1973       The currently defined status data items that can be requested are:
   1974 
   1975       MESSAGES
   1976          The number of messages in the mailbox.
   1977 
   1978       RECENT
   1979          The number of messages with the \Recent flag set.
   1980 
   1981       UIDNEXT
   1982          The next unique identifier value of the mailbox.  Refer to
   1983          section 2.3.1.1 for more information.
   1984 
   1985       UIDVALIDITY
   1986          The unique identifier validity value of the mailbox.  Refer to
   1987          section 2.3.1.1 for more information.
   1988 
   1989       UNSEEN
   1990          The number of messages which do not have the \Seen flag set.
   1991 
   1992    Example:    C: A042 STATUS blurdybloop (UIDNEXT MESSAGES)
   1993                S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
   1994                S: A042 OK STATUS completed
   1995 
   1996 6.3.11. APPEND Command
   1997 
   1998    Arguments:  mailbox name
   1999                OPTIONAL flag parenthesized list
   2000                OPTIONAL date/time string
   2001                message literal
   2002 
   2003    Responses:  no specific responses for this command
   2004 
   2005    Result:     OK - append completed
   2006                NO - append error: can't append to that mailbox, error
   2007                     in flags or date/time or message text
   2008                BAD - command unknown or arguments invalid
   2009 
   2010       The APPEND command appends the literal argument as a new message
   2011       to the end of the specified destination mailbox.  This argument
   2012       SHOULD be in the format of an [_R_F_C_-_2_8_2_2] message.  8-bit
   2013       characters are permitted in the message.  A server implementation
   2014       that is unable to preserve 8-bit data properly MUST be able to
   2015       reversibly convert 8-bit APPEND data to 7-bit using a [MIME-IMB]
   2016       content transfer encoding.
   2017 
   2018            Note: There MAY be exceptions, e.g., draft messages, in
   2019            which required [_R_F_C_-_2_8_2_2] header lines are omitted in
   2020            the message literal argument to APPEND.  The full
   2021            implications of doing so MUST be understood and
   2022            carefully weighed.
   2023 
   2024       If a flag parenthesized list is specified, the flags SHOULD be set
   2025       in the resulting message; otherwise, the flag list of the
   2026       resulting message is set to empty by default.  In either case, the
   2027       Recent flag is also set.
   2028 
   2029       If a date-time is specified, the internal date SHOULD be set in
   2030       the resulting message; otherwise, the internal date of the
   2031       resulting message is set to the current date and time by default.
   2032 
   2033       If the append is unsuccessful for any reason, the mailbox MUST be
   2034       restored to its state before the APPEND attempt; no partial
   2035       appending is permitted.
   2036 
   2037       If the destination mailbox does not exist, a server MUST return an
   2038       error, and MUST NOT automatically create the mailbox.  Unless it
   2039       is certain that the destination mailbox can not be created, the
   2040       server MUST send the response code "[TRYCREATE]" as the prefix of
   2041       the text of the tagged NO response.  This gives a hint to the
   2042       client that it can attempt a CREATE command and retry the APPEND
   2043       if the CREATE is successful.
   2044 
   2045       If the mailbox is currently selected, the normal new message
   2046       actions SHOULD occur.  Specifically, the server SHOULD notify the
   2047       client immediately via an untagged EXISTS response.  If the server
   2048       does not do so, the client MAY issue a NOOP command (or failing
   2049       that, a CHECK command) after one or more APPEND commands.
   2050 
   2051    Example:    C: A003 APPEND saved-messages (\Seen) {310}
   2052                S: + Ready for literal data
   2053                C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
   2054                C: From: Fred Foobar <_f_o_o_b_a_r_@_B_l_u_r_d_y_b_l_o_o_p_._C_O_M>
   2055                C: Subject: afternoon meeting
   2056                C: To: _m_o_o_c_h_@_o_w_a_t_a_g_u_._s_i_a_m_._e_d_u
   2057                C: Message-Id: <B27397-0100000@Blurdybloop.COM>
   2058                C: MIME-Version: 1.0
   2059                C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
   2060                C:
   2061                C: Hello Joe, do you think we can meet at 3:30 tomorrow?
   2062                C:
   2063                S: A003 OK APPEND completed
   2064 
   2065         Note: The APPEND command is not used for message delivery,
   2066         because it does not provide a mechanism to transfer [SMTP]
   2067         envelope information.
   2068 
   2069 6.4.    Client Commands - Selected State
   2070 
   2071    In the selected state, commands that manipulate messages in a mailbox
   2072    are permitted.
   2073 
   2074    In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
   2075    and the authenticated state commands (SELECT, EXAMINE, CREATE,
   2076    DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS, and
   2077    APPEND), the following commands are valid in the selected state:
   2078    CHECK, CLOSE, EXPUNGE, SEARCH, FETCH, STORE, COPY, and UID.
   2079 
   2080 6.4.1.  CHECK Command
   2081 
   2082    Arguments:  none
   2083 
   2084    Responses:  no specific responses for this command
   2085 
   2086    Result:     OK - check completed
   2087                BAD - command unknown or arguments invalid
   2088 
   2089       The CHECK command requests a checkpoint of the currently selected
   2090       mailbox.  A checkpoint refers to any implementation-dependent
   2091       housekeeping associated with the mailbox (e.g., resolving the
   2092       server's in-memory state of the mailbox with the state on its
   2093 
   2094       disk) that is not normally executed as part of each command.  A
   2095       checkpoint MAY take a non-instantaneous amount of real time to
   2096       complete.  If a server implementation has no such housekeeping
   2097       considerations, CHECK is equivalent to NOOP.
   2098 
   2099       There is no guarantee that an EXISTS untagged response will happen
   2100       as a result of CHECK.  NOOP, not CHECK, SHOULD be used for new
   2101       message polling.
   2102 
   2103    Example:    C: FXXZ CHECK
   2104                S: FXXZ OK CHECK Completed
   2105 
   2106 6.4.2.  CLOSE Command
   2107 
   2108    Arguments:  none
   2109 
   2110    Responses:  no specific responses for this command
   2111 
   2112    Result:     OK - close completed, now in authenticated state
   2113                BAD - command unknown or arguments invalid
   2114 
   2115       The CLOSE command permanently removes all messages that have the
   2116       \Deleted flag set from the currently selected mailbox, and returns
   2117       to the authenticated state from the selected state.  No untagged
   2118       EXPUNGE responses are sent.
   2119 
   2120       No messages are removed, and no error is given, if the mailbox is
   2121       selected by an EXAMINE command or is otherwise selected read-only.
   2122 
   2123       Even if a mailbox is selected, a SELECT, EXAMINE, or LOGOUT
   2124       command MAY be issued without previously issuing a CLOSE command.
   2125       The SELECT, EXAMINE, and LOGOUT commands implicitly close the
   2126       currently selected mailbox without doing an expunge.  However,
   2127       when many messages are deleted, a CLOSE-LOGOUT or CLOSE-SELECT
   2128       sequence is considerably faster than an EXPUNGE-LOGOUT or
   2129       EXPUNGE-SELECT because no untagged EXPUNGE responses (which the
   2130       client would probably ignore) are sent.
   2131 
   2132    Example:    C: A341 CLOSE
   2133                S: A341 OK CLOSE completed
   2134 
   2135 6.4.3.  EXPUNGE Command
   2136 
   2137    Arguments:  none
   2138 
   2139    Responses:  untagged responses: EXPUNGE
   2140 
   2141    Result:     OK - expunge completed
   2142                NO - expunge failure: can't expunge (e.g., permission
   2143                     denied)
   2144                BAD - command unknown or arguments invalid
   2145 
   2146       The EXPUNGE command permanently removes all messages that have the
   2147       \Deleted flag set from the currently selected mailbox.  Before
   2148       returning an OK to the client, an untagged EXPUNGE response is
   2149       sent for each message that is removed.
   2150 
   2151    Example:    C: A202 EXPUNGE
   2152                S: * 3 EXPUNGE
   2153                S: * 3 EXPUNGE
   2154                S: * 5 EXPUNGE
   2155                S: * 8 EXPUNGE
   2156                S: A202 OK EXPUNGE completed
   2157 
   2158         Note: In this example, messages 3, 4, 7, and 11 had the
   2159         \Deleted flag set.  See the description of the EXPUNGE
   2160         response for further explanation.
   2161 
   2162 6.4.4.  SEARCH Command
   2163 
   2164    Arguments:  OPTIONAL [CHARSET] specification
   2165                searching criteria (one or more)
   2166 
   2167    Responses:  REQUIRED untagged response: SEARCH
   2168 
   2169    Result:     OK - search completed
   2170                NO - search error: can't search that [CHARSET] or
   2171                     criteria
   2172                BAD - command unknown or arguments invalid
   2173 
   2174       The SEARCH command searches the mailbox for messages that match
   2175       the given searching criteria.  Searching criteria consist of one
   2176       or more search keys.  The untagged SEARCH response from the server
   2177       contains a listing of message sequence numbers corresponding to
   2178       those messages that match the searching criteria.
   2179 
   2180       When multiple keys are specified, the result is the intersection
   2181       (AND function) of all the messages that match those keys.  For
   2182       example, the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers
   2183       to all deleted messages from Smith that were placed in the mailbox
   2184       since February 1, 1994.  A search key can also be a parenthesized
   2185       list of one or more search keys (e.g., for use with the OR and NOT
   2186       keys).
   2187 
   2188       Server implementations MAY exclude [MIME-IMB] body parts with
   2189       terminal content media types other than TEXT and MESSAGE from
   2190       consideration in SEARCH matching.
   2191 
   2192       The OPTIONAL [CHARSET] specification consists of the word
   2193       "CHARSET" followed by a registered [CHARSET].  It indicates the
   2194       [CHARSET] of the strings that appear in the search criteria.
   2195       [MIME-IMB] content transfer encodings, and [MIME-HDRS] strings in
   2196       [_R_F_C_-_2_8_2_2]/[MIME-IMB] headers, MUST be decoded before comparing
   2197       text in a [CHARSET] other than US-ASCII.  US-ASCII MUST be
   2198       supported; other [CHARSET]s MAY be supported.
   2199 
   2200       If the server does not support the specified [CHARSET], it MUST
   2201       return a tagged NO response (not a BAD).  This response SHOULD
   2202       contain the BADCHARSET response code, which MAY list the
   2203       [CHARSET]s supported by the server.
   2204 
   2205       In all search keys that use strings, a message matches the key if
   2206       the string is a substring of the field.  The matching is
   2207       case-insensitive.
   2208 
   2209       The defined search keys are as follows.  Refer to the Formal
   2210       Syntax section for the precise syntactic definitions of the
   2211       arguments.
   2212 
   2213       <sequence set>
   2214          Messages with message sequence numbers corresponding to the
   2215          specified message sequence number set.
   2216 
   2217       ALL
   2218          All messages in the mailbox; the default initial key for
   2219          ANDing.
   2220 
   2221       ANSWERED
   2222          Messages with the \Answered flag set.
   2223 
   2224       BCC <string>
   2225          Messages that contain the specified string in the envelope
   2226          structure's BCC field.
   2227 
   2228       BEFORE <date>
   2229          Messages whose internal date (disregarding time and timezone)
   2230          is earlier than the specified date.
   2231 
   2232       BODY <string>
   2233          Messages that contain the specified string in the body of the
   2234          message.
   2235 
   2236       CC <string>
   2237          Messages that contain the specified string in the envelope
   2238          structure's CC field.
   2239 
   2240       DELETED
   2241          Messages with the \Deleted flag set.
   2242 
   2243       DRAFT
   2244          Messages with the \Draft flag set.
   2245 
   2246       FLAGGED
   2247          Messages with the \Flagged flag set.
   2248 
   2249       FROM <string>
   2250          Messages that contain the specified string in the envelope
   2251          structure's FROM field.
   2252 
   2253       HEADER <field-name> <string>
   2254          Messages that have a header with the specified field-name (as
   2255          defined in [_R_F_C_-_2_8_2_2]) and that contains the specified string
   2256          in the text of the header (what comes after the colon).  If the
   2257          string to search is zero-length, this matches all messages that
   2258          have a header line with the specified field-name regardless of
   2259          the contents.
   2260 
   2261       KEYWORD <flag>
   2262          Messages with the specified keyword flag set.
   2263 
   2264       LARGER <n>
   2265          Messages with an [_R_F_C_-_2_8_2_2] size larger than the specified
   2266          number of octets.
   2267 
   2268       NEW
   2269          Messages that have the \Recent flag set but not the \Seen flag.
   2270          This is functionally equivalent to "(RECENT UNSEEN)".
   2271 
   2272       NOT <search-key>
   2273          Messages that do not match the specified search key.
   2274 
   2275       OLD
   2276          Messages that do not have the \Recent flag set.  This is
   2277          functionally equivalent to "NOT RECENT" (as opposed to "NOT
   2278          NEW").
   2279 
   2280       ON <date>
   2281          Messages whose internal date (disregarding time and timezone)
   2282          is within the specified date.
   2283 
   2284       OR <search-key1> <search-key2>
   2285          Messages that match either search key.
   2286 
   2287       RECENT
   2288          Messages that have the \Recent flag set.
   2289 
   2290       SEEN
   2291          Messages that have the \Seen flag set.
   2292 
   2293       SENTBEFORE <date>
   2294          Messages whose [_R_F_C_-_2_8_2_2] Date: header (disregarding time and
   2295          timezone) is earlier than the specified date.
   2296 
   2297       SENTON <date>
   2298          Messages whose [_R_F_C_-_2_8_2_2] Date: header (disregarding time and
   2299          timezone) is within the specified date.
   2300 
   2301       SENTSINCE <date>
   2302          Messages whose [_R_F_C_-_2_8_2_2] Date: header (disregarding time and
   2303          timezone) is within or later than the specified date.
   2304 
   2305       SINCE <date>
   2306          Messages whose internal date (disregarding time and timezone)
   2307          is within or later than the specified date.
   2308 
   2309       SMALLER <n>
   2310          Messages with an [_R_F_C_-_2_8_2_2] size smaller than the specified
   2311          number of octets.
   2312 
   2313       SUBJECT <string>
   2314          Messages that contain the specified string in the envelope
   2315          structure's SUBJECT field.
   2316 
   2317       TEXT <string>
   2318          Messages that contain the specified string in the header or
   2319          body of the message.
   2320 
   2321       TO <string>
   2322          Messages that contain the specified string in the envelope
   2323          structure's TO field.
   2324 
   2325       UID <sequence set>
   2326          Messages with unique identifiers corresponding to the specified
   2327          unique identifier set.  Sequence set ranges are permitted.
   2328 
   2329       UNANSWERED
   2330          Messages that do not have the \Answered flag set.
   2331 
   2332       UNDELETED
   2333          Messages that do not have the \Deleted flag set.
   2334 
   2335       UNDRAFT
   2336          Messages that do not have the \Draft flag set.
   2337 
   2338       UNFLAGGED
   2339          Messages that do not have the \Flagged flag set.
   2340 
   2341       UNKEYWORD <flag>
   2342          Messages that do not have the specified keyword flag set.
   2343 
   2344       UNSEEN
   2345          Messages that do not have the \Seen flag set.
   2346 
   2347    Example:    C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith"
   2348                S: * SEARCH 2 84 882
   2349                S: A282 OK SEARCH completed
   2350                C: A283 SEARCH TEXT "string not in mailbox"
   2351                S: * SEARCH
   2352                S: A283 OK SEARCH completed
   2353                C: A284 SEARCH CHARSET UTF-8 TEXT {6}
   2354                C: XXXXXX
   2355                S: * SEARCH 43
   2356                S: A284 OK SEARCH completed
   2357 
   2358         Note: Since this document is restricted to 7-bit ASCII
   2359         text, it is not possible to show actual UTF-8 data.  The
   2360         "XXXXXX" is a placeholder for what would be 6 octets of
   2361         8-bit data in an actual transaction.
   2362 
   2363 6.4.5.  FETCH Command
   2364 
   2365    Arguments:  sequence set
   2366                message data item names or macro
   2367 
   2368    Responses:  untagged responses: FETCH
   2369 
   2370    Result:     OK - fetch completed
   2371                NO - fetch error: can't fetch that data
   2372                BAD - command unknown or arguments invalid
   2373 
   2374       The FETCH command retrieves data associated with a message in the
   2375       mailbox.  The data items to be fetched can be either a single atom
   2376       or a parenthesized list.
   2377 
   2378       Most data items, identified in the formal syntax under the
   2379       msg-att-static rule, are static and MUST NOT change for any
   2380       particular message.  Other data items, identified in the formal
   2381       syntax under the msg-att-dynamic rule, MAY change, either as a
   2382       result of a STORE command or due to external events.
   2383 
   2384            For example, if a client receives an ENVELOPE for a
   2385            message when it already knows the envelope, it can
   2386            safely ignore the newly transmitted envelope.
   2387 
   2388       There are three macros which specify commonly-used sets of data
   2389       items, and can be used instead of data items.  A macro must be
   2390       used by itself, and not in conjunction with other macros or data
   2391       items.
   2392 
   2393       ALL
   2394          Macro equivalent to: (FLAGS INTERNALDATE _R_F_C_8_2_2.SIZE ENVELOPE)
   2395 
   2396       FAST
   2397          Macro equivalent to: (FLAGS INTERNALDATE _R_F_C_8_2_2.SIZE)
   2398 
   2399       FULL
   2400          Macro equivalent to: (FLAGS INTERNALDATE _R_F_C_8_2_2.SIZE ENVELOPE
   2401          BODY)
   2402 
   2403       The currently defined data items that can be fetched are:
   2404 
   2405       BODY
   2406          Non-extensible form of BODYSTRUCTURE.
   2407 
   2408       BODY[<section>]<<partial>>
   2409          The text of a particular body section.  The section
   2410          specification is a set of zero or more part specifiers
   2411          delimited by periods.  A part specifier is either a part number
   2412          or one of the following: HEADER, HEADER.FIELDS,
   2413          HEADER.FIELDS.NOT, MIME, and TEXT.  An empty section
   2414          specification refers to the entire message, including the
   2415          header.
   2416 
   2417          Every message has at least one part number.  Non-[MIME-IMB]
   2418          messages, and non-multipart [MIME-IMB] messages with no
   2419          encapsulated message, only have a part 1.
   2420 
   2421          Multipart messages are assigned consecutive part numbers, as
   2422          they occur in the message.  If a particular part is of type
   2423          message or multipart, its parts MUST be indicated by a period
   2424          followed by the part number within that nested multipart part.
   2425 
   2426          A part of type MESSAGE/RFC822 also has nested part numbers,
   2427          referring to parts of the MESSAGE part's body.
   2428 
   2429          The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, and TEXT part
   2430          specifiers can be the sole part specifier or can be prefixed by
   2431          one or more numeric part specifiers, provided that the numeric
   2432          part specifier refers to a part of type MESSAGE/RFC822.  The
   2433          MIME part specifier MUST be prefixed by one or more numeric
   2434          part specifiers.
   2435 
   2436          The HEADER, HEADER.FIELDS, and HEADER.FIELDS.NOT part
   2437          specifiers refer to the [_R_F_C_-_2_8_2_2] header of the message or of
   2438          an encapsulated [MIME-IMT] MESSAGE/RFC822 message.
   2439          HEADER.FIELDS and HEADER.FIELDS.NOT are followed by a list of
   2440          field-name (as defined in [_R_F_C_-_2_8_2_2]) names, and return a
   2441 
   2442          subset of the header.  The subset returned by HEADER.FIELDS
   2443          contains only those header fields with a field-name that
   2444          matches one of the names in the list; similarly, the subset
   2445          returned by HEADER.FIELDS.NOT contains only the header fields
   2446          with a non-matching field-name.  The field-matching is
   2447          case-insensitive but otherwise exact.  Subsetting does not
   2448          exclude the [_R_F_C_-_2_8_2_2] delimiting blank line between the header
   2449          and the body; the blank line is included in all header fetches,
   2450          except in the case of a message which has no body and no blank
   2451          line.
   2452 
   2453          The MIME part specifier refers to the [MIME-IMB] header for
   2454          this part.
   2455 
   2456          The TEXT part specifier refers to the text body of the message,
   2457          omitting the [_R_F_C_-_2_8_2_2] header.
   2458 
   2459             Here is an example of a complex message with some of its
   2460             part specifiers:
   2461 
   2462        HEADER     ([_R_F_C_-_2_8_2_2] header of the message)
   2463        TEXT       ([_R_F_C_-_2_8_2_2] text body of the message) MULTIPART/MIXED
   2464        1          TEXT/PLAIN
   2465        2          APPLICATION/OCTET-STREAM
   2466        3          MESSAGE/RFC822
   2467        3.HEADER   ([_R_F_C_-_2_8_2_2] header of the message)
   2468        3.TEXT     ([_R_F_C_-_2_8_2_2] text body of the message) MULTIPART/MIXED
   2469        3.1        TEXT/PLAIN
   2470        3.2        APPLICATION/OCTET-STREAM
   2471        4          MULTIPART/MIXED
   2472        4.1        IMAGE/GIF
   2473        4.1.MIME   ([MIME-IMB] header for the IMAGE/GIF)
   2474        4.2        MESSAGE/RFC822
   2475        4.2.HEADER ([_R_F_C_-_2_8_2_2] header of the message)
   2476        4.2.TEXT   ([_R_F_C_-_2_8_2_2] text body of the message) MULTIPART/MIXED
   2477        4.2.1      TEXT/PLAIN
   2478        4.2.2      MULTIPART/ALTERNATIVE
   2479        4.2.2.1    TEXT/PLAIN
   2480        4.2.2.2    TEXT/RICHTEXT
   2481 
   2482          It is possible to fetch a substring of the designated text.
   2483          This is done by appending an open angle bracket ("<"), the
   2484          octet position of the first desired octet, a period, the
   2485          maximum number of octets desired, and a close angle bracket
   2486          (">") to the part specifier.  If the starting octet is beyond
   2487          the end of the text, an empty string is returned.
   2488 
   2489          Any partial fetch that attempts to read beyond the end of the
   2490          text is truncated as appropriate.  A partial fetch that starts
   2491          at octet 0 is returned as a partial fetch, even if this
   2492          truncation happened.
   2493 
   2494             Note: This means that BODY[]<0.2048> of a 1500-octet message
   2495             will return BODY[]<0> with a literal of size 1500, not
   2496             BODY[].
   2497 
   2498             Note: A substring fetch of a HEADER.FIELDS or
   2499             HEADER.FIELDS.NOT part specifier is calculated after
   2500             subsetting the header.
   2501 
   2502          The \Seen flag is implicitly set; if this causes the flags to
   2503          change, they SHOULD be included as part of the FETCH responses.
   2504 
   2505       BODY.PEEK[<section>]<<partial>>
   2506          An alternate form of BODY[<section>] that does not implicitly
   2507          set the \Seen flag.
   2508 
   2509       BODYSTRUCTURE
   2510          The [MIME-IMB] body structure of the message.  This is computed
   2511          by the server by parsing the [MIME-IMB] header fields in the
   2512          [_R_F_C_-_2_8_2_2] header and [MIME-IMB] headers.
   2513 
   2514       ENVELOPE
   2515          The envelope structure of the message.  This is computed by the
   2516          server by parsing the [_R_F_C_-_2_8_2_2] header into the component
   2517          parts, defaulting various fields as necessary.
   2518 
   2519       FLAGS
   2520          The flags that are set for this message.
   2521 
   2522       INTERNALDATE
   2523          The internal date of the message.
   2524 
   2525       _R_F_C_8_2_2
   2526          Functionally equivalent to BODY[], differing in the syntax of
   2527          the resulting untagged FETCH data (_R_F_C_8_2_2 is returned).
   2528 
   2529       _R_F_C_8_2_2.HEADER
   2530          Functionally equivalent to BODY.PEEK[HEADER], differing in the
   2531          syntax of the resulting untagged FETCH data (_R_F_C_8_2_2.HEADER is
   2532          returned).
   2533 
   2534       _R_F_C_8_2_2.SIZE
   2535          The [_R_F_C_-_2_8_2_2] size of the message.
   2536 
   2537       _R_F_C_8_2_2.TEXT
   2538          Functionally equivalent to BODY[TEXT], differing in the syntax
   2539          of the resulting untagged FETCH data (_R_F_C_8_2_2.TEXT is returned).
   2540 
   2541       UID
   2542          The unique identifier for the message.
   2543 
   2544    Example:    C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)])
   2545                S: * 2 FETCH ....
   2546                S: * 3 FETCH ....
   2547                S: * 4 FETCH ....
   2548                S: A654 OK FETCH completed
   2549 
   2550 6.4.6.  STORE Command
   2551 
   2552    Arguments:  sequence set
   2553                message data item name
   2554                value for message data item
   2555 
   2556    Responses:  untagged responses: FETCH
   2557 
   2558    Result:     OK - store completed
   2559                NO - store error: can't store that data
   2560                BAD - command unknown or arguments invalid
   2561 
   2562       The STORE command alters data associated with a message in the
   2563       mailbox.  Normally, STORE will return the updated value of the
   2564       data with an untagged FETCH response.  A suffix of ".SILENT" in
   2565       the data item name prevents the untagged FETCH, and the server
   2566       SHOULD assume that the client has determined the updated value
   2567       itself or does not care about the updated value.
   2568 
   2569            Note: Regardless of whether or not the ".SILENT" suffix
   2570            was used, the server SHOULD send an untagged FETCH
   2571            response if a change to a message's flags from an
   2572            external source is observed.  The intent is that the
   2573            status of the flags is determinate without a race
   2574            condition.
   2575 
   2576       The currently defined data items that can be stored are:
   2577 
   2578       FLAGS <flag list>
   2579          Replace the flags for the message (other than \Recent) with the
   2580          argument.  The new value of the flags is returned as if a FETCH
   2581          of those flags was done.
   2582 
   2583       FLAGS.SILENT <flag list>
   2584          Equivalent to FLAGS, but without returning a new value.
   2585 
   2586       +FLAGS <flag list>
   2587          Add the argument to the flags for the message.  The new value
   2588          of the flags is returned as if a FETCH of those flags was done.
   2589 
   2590       +FLAGS.SILENT <flag list>
   2591          Equivalent to +FLAGS, but without returning a new value.
   2592 
   2593       -FLAGS <flag list>
   2594          Remove the argument from the flags for the message.  The new
   2595          value of the flags is returned as if a FETCH of those flags was
   2596          done.
   2597 
   2598       -FLAGS.SILENT <flag list>
   2599          Equivalent to -FLAGS, but without returning a new value.
   2600 
   2601    Example:    C: A003 STORE 2:4 +FLAGS (\Deleted)
   2602                S: * 2 FETCH (FLAGS (\Deleted \Seen))
   2603                S: * 3 FETCH (FLAGS (\Deleted))
   2604                S: * 4 FETCH (FLAGS (\Deleted \Flagged \Seen))
   2605                S: A003 OK STORE completed
   2606 
   2607 6.4.7.  COPY Command
   2608 
   2609    Arguments:  sequence set
   2610                mailbox name
   2611 
   2612    Responses:  no specific responses for this command
   2613 
   2614    Result:     OK - copy completed
   2615                NO - copy error: can't copy those messages or to that
   2616                     name
   2617                BAD - command unknown or arguments invalid
   2618 
   2619       The COPY command copies the specified message(s) to the end of the
   2620       specified destination mailbox.  The flags and internal date of the
   2621       message(s) SHOULD be preserved, and the Recent flag SHOULD be set,
   2622       in the copy.
   2623 
   2624       If the destination mailbox does not exist, a server SHOULD return
   2625       an error.  It SHOULD NOT automatically create the mailbox.  Unless
   2626       it is certain that the destination mailbox can not be created, the
   2627       server MUST send the response code "[TRYCREATE]" as the prefix of
   2628       the text of the tagged NO response.  This gives a hint to the
   2629       client that it can attempt a CREATE command and retry the COPY if
   2630       the CREATE is successful.
   2631 
   2632       If the COPY command is unsuccessful for any reason, server
   2633       implementations MUST restore the destination mailbox to its state
   2634       before the COPY attempt.
   2635 
   2636    Example:    C: A003 COPY 2:4 MEETING
   2637                S: A003 OK COPY completed
   2638 
   2639 6.4.8.  UID Command
   2640 
   2641    Arguments:  command name
   2642                command arguments
   2643 
   2644    Responses:  untagged responses: FETCH, SEARCH
   2645 
   2646    Result:     OK - UID command completed
   2647                NO - UID command error
   2648                BAD - command unknown or arguments invalid
   2649 
   2650       The UID command has two forms.  In the first form, it takes as its
   2651       arguments a COPY, FETCH, or STORE command with arguments
   2652       appropriate for the associated command.  However, the numbers in
   2653       the sequence set argument are unique identifiers instead of
   2654       message sequence numbers.  Sequence set ranges are permitted, but
   2655       there is no guarantee that unique identifiers will be contiguous.
   2656 
   2657       A non-existent unique identifier is ignored without any error
   2658       message generated.  Thus, it is possible for a UID FETCH command
   2659       to return an OK without any data or a UID COPY or UID STORE to
   2660       return an OK without performing any operations.
   2661 
   2662       In the second form, the UID command takes a SEARCH command with
   2663       SEARCH command arguments.  The interpretation of the arguments is
   2664       the same as with SEARCH; however, the numbers returned in a SEARCH
   2665       response for a UID SEARCH command are unique identifiers instead
   2666 
   2667       of message sequence numbers.  For example, the command UID SEARCH
   2668       1:100 UID 443:557 returns the unique identifiers corresponding to
   2669       the intersection of two sequence sets, the message sequence number
   2670       range 1:100 and the UID range 443:557.
   2671 
   2672            Note: in the above example, the UID range 443:557
   2673            appears.  The same comment about a non-existent unique
   2674            identifier being ignored without any error message also
   2675            applies here.  Hence, even if neither UID 443 or 557
   2676            exist, this range is valid and would include an existing
   2677            UID 495.
   2678 
   2679            Also note that a UID range of 559:* always includes the
   2680            UID of the last message in the mailbox, even if 559 is
   2681            higher than any assigned UID value.  This is because the
   2682            contents of a range are independent of the order of the
   2683            range endpoints.  Thus, any UID range with * as one of
   2684            the endpoints indicates at least one message (the
   2685            message with the highest numbered UID), unless the
   2686            mailbox is empty.
   2687 
   2688       The number after the "*" in an untagged FETCH response is always a
   2689       message sequence number, not a unique identifier, even for a UID
   2690       command response.  However, server implementations MUST implicitly
   2691       include the UID message data item as part of any FETCH response
   2692       caused by a UID command, regardless of whether a UID was specified
   2693       as a message data item to the FETCH.
   2694 
   2695       Note: The rule about including the UID message data item as part
   2696       of a FETCH response primarily applies to the UID FETCH and UID
   2697       STORE commands, including a UID FETCH command that does not
   2698       include UID as a message data item.  Although it is unlikely that
   2699       the other UID commands will cause an untagged FETCH, this rule
   2700       applies to these commands as well.
   2701 
   2702    Example:    C: A999 UID FETCH 4827313:4828442 FLAGS
   2703                S: * 23 FETCH (FLAGS (\Seen) UID 4827313)
   2704                S: * 24 FETCH (FLAGS (\Seen) UID 4827943)
   2705                S: * 25 FETCH (FLAGS (\Seen) UID 4828442)
   2706                S: A999 OK UID FETCH completed
   2707 
   2708 6.5.    Client Commands - Experimental/Expansion
   2709 
   2710 6.5.1.  X<atom> Command
   2711 
   2712    Arguments:  implementation defined
   2713 
   2714    Responses:  implementation defined
   2715 
   2716    Result:     OK - command completed
   2717                NO - failure
   2718                BAD - command unknown or arguments invalid
   2719 
   2720       Any command prefixed with an X is an experimental command.
   2721       Commands which are not part of this specification, a standard or
   2722       standards-track revision of this specification, or an
   2723       IESG-approved experimental protocol, MUST use the X prefix.
   2724 
   2725       Any added untagged responses issued by an experimental command
   2726       MUST also be prefixed with an X.  Server implementations MUST NOT
   2727       send any such untagged responses, unless the client requested it
   2728       by issuing the associated experimental command.
   2729 
   2730    Example:    C: a441 CAPABILITY
   2731                S: * CAPABILITY IMAP4rev1 XPIG-LATIN
   2732                S: a441 OK CAPABILITY completed
   2733                C: A442 XPIG-LATIN
   2734                S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay
   2735                S: A442 OK XPIG-LATIN ompleted-cay
   2736 
   2737 7.      Server Responses
   2738 
   2739    Server responses are in three forms: status responses, server data,
   2740    and command continuation request.  The information contained in a
   2741    server response, identified by "Contents:" in the response
   2742    descriptions below, is described by function, not by syntax.  The
   2743    precise syntax of server responses is described in the Formal Syntax
   2744    section.
   2745 
   2746    The client MUST be prepared to accept any response at all times.
   2747 
   2748    Status responses can be tagged or untagged.  Tagged status responses
   2749    indicate the completion result (OK, NO, or BAD status) of a client
   2750    command, and have a tag matching the command.
   2751 
   2752    Some status responses, and all server data, are untagged.  An
   2753    untagged response is indicated by the token "*" instead of a tag.
   2754    Untagged status responses indicate server greeting, or server status
   2755 
   2756    that does not indicate the completion of a command (for example, an
   2757    impending system shutdown alert).  For historical reasons, untagged
   2758    server data responses are also called "unsolicited data", although
   2759    strictly speaking, only unilateral server data is truly
   2760    "unsolicited".
   2761 
   2762    Certain server data MUST be recorded by the client when it is
   2763    received; this is noted in the description of that data.  Such data
   2764    conveys critical information which affects the interpretation of all
   2765    subsequent commands and responses (e.g., updates reflecting the
   2766    creation or destruction of messages).
   2767 
   2768    Other server data SHOULD be recorded for later reference; if the
   2769    client does not need to record the data, or if recording the data has
   2770    no obvious purpose (e.g., a SEARCH response when no SEARCH command is
   2771    in progress), the data SHOULD be ignored.
   2772 
   2773    An example of unilateral untagged server data occurs when the IMAP
   2774    connection is in the selected state.  In the selected state, the
   2775    server checks the mailbox for new messages as part of command
   2776    execution.  Normally, this is part of the execution of every command;
   2777    hence, a NOOP command suffices to check for new messages.  If new
   2778    messages are found, the server sends untagged EXISTS and RECENT
   2779    responses reflecting the new size of the mailbox.  Server
   2780    implementations that offer multiple simultaneous access to the same
   2781    mailbox SHOULD also send appropriate unilateral untagged FETCH and
   2782    EXPUNGE responses if another agent changes the state of any message
   2783    flags or expunges any messages.
   2784 
   2785    Command continuation request responses use the token "+" instead of a
   2786    tag.  These responses are sent by the server to indicate acceptance
   2787    of an incomplete client command and readiness for the remainder of
   2788    the command.
   2789 
   2790 7.1.    Server Responses - Status Responses
   2791 
   2792    Status responses are OK, NO, BAD, PREAUTH and BYE.  OK, NO, and BAD
   2793    can be tagged or untagged.  PREAUTH and BYE are always untagged.
   2794 
   2795    Status responses MAY include an OPTIONAL "response code".  A response
   2796    code consists of data inside square brackets in the form of an atom,
   2797    possibly followed by a space and arguments.  The response code
   2798    contains additional information or status codes for client software
   2799    beyond the OK/NO/BAD condition, and are defined when there is a
   2800    specific action that a client can take based upon the additional
   2801    information.
   2802 
   2803    The currently defined response codes are:
   2804 
   2805       ALERT
   2806 
   2807          The human-readable text contains a special alert that MUST be
   2808          presented to the user in a fashion that calls the user's
   2809          attention to the message.
   2810 
   2811       BADCHARSET
   2812 
   2813          Optionally followed by a parenthesized list of charsets.  A
   2814          SEARCH failed because the given charset is not supported by
   2815          this implementation.  If the optional list of charsets is
   2816          given, this lists the charsets that are supported by this
   2817          implementation.
   2818 
   2819       CAPABILITY
   2820 
   2821          Followed by a list of capabilities.  This can appear in the
   2822          initial OK or PREAUTH response to transmit an initial
   2823          capabilities list.  This makes it unnecessary for a client to
   2824          send a separate CAPABILITY command if it recognizes this
   2825          response.
   2826 
   2827       PARSE
   2828 
   2829          The human-readable text represents an error in parsing the
   2830          [_R_F_C_-_2_8_2_2] header or [MIME-IMB] headers of a message in the
   2831          mailbox.
   2832 
   2833       PERMANENTFLAGS
   2834 
   2835          Followed by a parenthesized list of flags, indicates which of
   2836          the known flags the client can change permanently.  Any flags
   2837          that are in the FLAGS untagged response, but not the
   2838          PERMANENTFLAGS list, can not be set permanently.  If the client
   2839          attempts to STORE a flag that is not in the PERMANENTFLAGS
   2840          list, the server will either ignore the change or store the
   2841          state change for the remainder of the current session only.
   2842          The PERMANENTFLAGS list can also include the special flag \*,
   2843          which indicates that it is possible to create new keywords by
   2844          attempting to store those flags in the mailbox.
   2845 
   2846       READ-ONLY
   2847 
   2848          The mailbox is selected read-only, or its access while selected
   2849          has changed from read-write to read-only.
   2850 
   2851       READ-WRITE
   2852 
   2853          The mailbox is selected read-write, or its access while
   2854          selected has changed from read-only to read-write.
   2855 
   2856       TRYCREATE
   2857 
   2858          An APPEND or COPY attempt is failing because the target mailbox
   2859          does not exist (as opposed to some other reason).  This is a
   2860          hint to the client that the operation can succeed if the
   2861          mailbox is first created by the CREATE command.
   2862 
   2863       UIDNEXT
   2864 
   2865          Followed by a decimal number, indicates the next unique
   2866          identifier value.  Refer to section 2.3.1.1 for more
   2867          information.
   2868 
   2869       UIDVALIDITY
   2870 
   2871          Followed by a decimal number, indicates the unique identifier
   2872          validity value.  Refer to section 2.3.1.1 for more information.
   2873 
   2874       UNSEEN
   2875 
   2876          Followed by a decimal number, indicates the number of the first
   2877          message without the \Seen flag set.
   2878 
   2879       Additional response codes defined by particular client or server
   2880       implementations SHOULD be prefixed with an "X" until they are
   2881       added to a revision of this protocol.  Client implementations
   2882       SHOULD ignore response codes that they do not recognize.
   2883 
   2884 7.1.1.  OK Response
   2885 
   2886    Contents:   OPTIONAL response code
   2887                human-readable text
   2888 
   2889       The OK response indicates an information message from the server.
   2890       When tagged, it indicates successful completion of the associated
   2891       command.  The human-readable text MAY be presented to the user as
   2892       an information message.  The untagged form indicates an
   2893 
   2894       information-only message; the nature of the information MAY be
   2895       indicated by a response code.
   2896 
   2897       The untagged form is also used as one of three possible greetings
   2898       at connection startup.  It indicates that the connection is not
   2899       yet authenticated and that a LOGIN command is needed.
   2900 
   2901    Example:    S: * OK IMAP4rev1 server ready
   2902                C: A001 LOGIN fred blurdybloop
   2903                S: * OK [ALERT] System shutdown in 10 minutes
   2904                S: A001 OK LOGIN Completed
   2905 
   2906 7.1.2.  NO Response
   2907 
   2908    Contents:   OPTIONAL response code
   2909                human-readable text
   2910 
   2911       The NO response indicates an operational error message from the
   2912       server.  When tagged, it indicates unsuccessful completion of the
   2913       associated command.  The untagged form indicates a warning; the
   2914       command can still complete successfully.  The human-readable text
   2915       describes the condition.
   2916 
   2917    Example:    C: A222 COPY 1:2 owatagusiam
   2918                S: * NO Disk is 98% full, please delete unnecessary data
   2919                S: A222 OK COPY completed
   2920                C: A223 COPY 3:200 blurdybloop
   2921                S: * NO Disk is 98% full, please delete unnecessary data
   2922                S: * NO Disk is 99% full, please delete unnecessary data
   2923                S: A223 NO COPY failed: disk is full
   2924 
   2925 7.1.3.  BAD Response
   2926 
   2927    Contents:   OPTIONAL response code
   2928                human-readable text
   2929 
   2930       The BAD response indicates an error message from the server.  When
   2931       tagged, it reports a protocol-level error in the client's command;
   2932       the tag indicates the command that caused the error.  The untagged
   2933       form indicates a protocol-level error for which the associated
   2934       command can not be determined; it can also indicate an internal
   2935       server failure.  The human-readable text describes the condition.
   2936 
   2937    Example:    C: ...very long command line...
   2938                S: * BAD Command line too long
   2939                C: ...empty line...
   2940                S: * BAD Empty command line
   2941                C: A443 EXPUNGE
   2942                S: * BAD Disk crash, attempting salvage to a new disk!
   2943                S: * OK Salvage successful, no data lost
   2944                S: A443 OK Expunge completed
   2945 
   2946 7.1.4.  PREAUTH Response
   2947 
   2948    Contents:   OPTIONAL response code
   2949                human-readable text
   2950 
   2951       The PREAUTH response is always untagged, and is one of three
   2952       possible greetings at connection startup.  It indicates that the
   2953       connection has already been authenticated by external means; thus
   2954       no LOGIN command is needed.
   2955 
   2956    Example:    S: * PREAUTH IMAP4rev1 server logged in as Smith
   2957 
   2958 7.1.5.  BYE Response
   2959 
   2960    Contents:   OPTIONAL response code
   2961                human-readable text
   2962 
   2963       The BYE response is always untagged, and indicates that the server
   2964       is about to close the connection.  The human-readable text MAY be
   2965       displayed to the user in a status report by the client.  The BYE
   2966       response is sent under one of four conditions:
   2967 
   2968          1) as part of a normal logout sequence.  The server will close
   2969             the connection after sending the tagged OK response to the
   2970             LOGOUT command.
   2971 
   2972          2) as a panic shutdown announcement.  The server closes the
   2973             connection immediately.
   2974 
   2975          3) as an announcement of an inactivity autologout.  The server
   2976             closes the connection immediately.
   2977 
   2978          4) as one of three possible greetings at connection startup,
   2979             indicating that the server is not willing to accept a
   2980             connection from this client.  The server closes the
   2981             connection immediately.
   2982 
   2983       The difference between a BYE that occurs as part of a normal
   2984       LOGOUT sequence (the first case) and a BYE that occurs because of
   2985       a failure (the other three cases) is that the connection closes
   2986       immediately in the failure case.  In all cases the client SHOULD
   2987       continue to read response data from the server until the
   2988       connection is closed; this will ensure that any pending untagged
   2989       or completion responses are read and processed.
   2990 
   2991    Example:    S: * BYE Autologout; idle for too long
   2992 
   2993 7.2.    Server Responses - Server and Mailbox Status
   2994 
   2995    These responses are always untagged.  This is how server and mailbox
   2996    status data are transmitted from the server to the client.  Many of
   2997    these responses typically result from a command with the same name.
   2998 
   2999 7.2.1.  CAPABILITY Response
   3000 
   3001    Contents:   capability listing
   3002 
   3003       The CAPABILITY response occurs as a result of a CAPABILITY
   3004       command.  The capability listing contains a space-separated
   3005       listing of capability names that the server supports.  The
   3006       capability listing MUST include the atom "IMAP4rev1".
   3007 
   3008       In addition, client and server implementations MUST implement the
   3009       STARTTLS, LOGINDISABLED, and AUTH=PLAIN (described in [IMAP-TLS])
   3010       capabilities.  See the Security Considerations section for
   3011       important information.
   3012 
   3013       A capability name which begins with "AUTH=" indicates that the
   3014       server supports that particular authentication mechanism.
   3015 
   3016       The LOGINDISABLED capability indicates that the LOGIN command is
   3017       disabled, and that the server will respond with a tagged NO
   3018       response to any attempt to use the LOGIN command even if the user
   3019       name and password are valid.  An IMAP client MUST NOT issue the
   3020       LOGIN command if the server advertises the LOGINDISABLED
   3021       capability.
   3022 
   3023       Other capability names indicate that the server supports an
   3024       extension, revision, or amendment to the IMAP4rev1 protocol.
   3025       Server responses MUST conform to this document until the client
   3026       issues a command that uses the associated capability.
   3027 
   3028       Capability names MUST either begin with "X" or be standard or
   3029       standards-track IMAP4rev1 extensions, revisions, or amendments
   3030       registered with IANA.  A server MUST NOT offer unregistered or
   3031 
   3032       non-standard capability names, unless such names are prefixed with
   3033       an "X".
   3034 
   3035       Client implementations SHOULD NOT require any capability name
   3036       other than "IMAP4rev1", and MUST ignore any unknown capability
   3037       names.
   3038 
   3039       A server MAY send capabilities automatically, by using the
   3040       CAPABILITY response code in the initial PREAUTH or OK responses,
   3041       and by sending an updated CAPABILITY response code in the tagged
   3042       OK response as part of a successful authentication.  It is
   3043       unnecessary for a client to send a separate CAPABILITY command if
   3044       it recognizes these automatic capabilities.
   3045 
   3046    Example:    S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI XPIG-LATIN
   3047 
   3048 7.2.2.  LIST Response
   3049 
   3050    Contents:   name attributes
   3051                hierarchy delimiter
   3052                name
   3053 
   3054       The LIST response occurs as a result of a LIST command.  It
   3055       returns a single name that matches the LIST specification.  There
   3056       can be multiple LIST responses for a single LIST command.
   3057 
   3058       Four name attributes are defined:
   3059 
   3060       \Noinferiors
   3061          It is not possible for any child levels of hierarchy to exist
   3062          under this name; no child levels exist now and none can be
   3063          created in the future.
   3064 
   3065       \Noselect
   3066          It is not possible to use this name as a selectable mailbox.
   3067 
   3068       \Marked
   3069          The mailbox has been marked "interesting" by the server; the
   3070          mailbox probably contains messages that have been added since
   3071          the last time the mailbox was selected.
   3072 
   3073       \Unmarked
   3074          The mailbox does not contain any additional messages since the
   3075          last time the mailbox was selected.
   3076 
   3077       If it is not feasible for the server to determine whether or not
   3078       the mailbox is "interesting", or if the name is a \Noselect name,
   3079       the server SHOULD NOT send either \Marked or \Unmarked.
   3080 
   3081       The hierarchy delimiter is a character used to delimit levels of
   3082       hierarchy in a mailbox name.  A client can use it to create child
   3083       mailboxes, and to search higher or lower levels of naming
   3084       hierarchy.  All children of a top-level hierarchy node MUST use
   3085       the same separator character.  A NIL hierarchy delimiter means
   3086       that no hierarchy exists; the name is a "flat" name.
   3087 
   3088       The name represents an unambiguous left-to-right hierarchy, and
   3089       MUST be valid for use as a reference in LIST and LSUB commands.
   3090       Unless \Noselect is indicated, the name MUST also be valid as an
   3091       argument for commands, such as SELECT, that accept mailbox names.
   3092 
   3093    Example:    S: * LIST (\Noselect) "/" ~/Mail/foo
   3094 
   3095 7.2.3.  LSUB Response
   3096 
   3097    Contents:   name attributes
   3098                hierarchy delimiter
   3099                name
   3100 
   3101       The LSUB response occurs as a result of an LSUB command.  It
   3102       returns a single name that matches the LSUB specification.  There
   3103       can be multiple LSUB responses for a single LSUB command.  The
   3104       data is identical in format to the LIST response.
   3105 
   3106    Example:    S: * LSUB () "." #news.comp.mail.misc
   3107 
   3108 7.2.4   STATUS Response
   3109 
   3110    Contents:   name
   3111                status parenthesized list
   3112 
   3113       The STATUS response occurs as a result of an STATUS command.  It
   3114       returns the mailbox name that matches the STATUS specification and
   3115       the requested mailbox status information.
   3116 
   3117    Example:    S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
   3118 
   3119 7.2.5.  SEARCH Response
   3120 
   3121    Contents:   zero or more numbers
   3122 
   3123       The SEARCH response occurs as a result of a SEARCH or UID SEARCH
   3124       command.  The number(s) refer to those messages that match the
   3125       search criteria.  For SEARCH, these are message sequence numbers;
   3126       for UID SEARCH, these are unique identifiers.  Each number is
   3127       delimited by a space.
   3128 
   3129    Example:    S: * SEARCH 2 3 6
   3130 
   3131 7.2.6.  FLAGS Response
   3132 
   3133    Contents:   flag parenthesized list
   3134 
   3135       The FLAGS response occurs as a result of a SELECT or EXAMINE
   3136       command.  The flag parenthesized list identifies the flags (at a
   3137       minimum, the system-defined flags) that are applicable for this
   3138       mailbox.  Flags other than the system flags can also exist,
   3139       depending on server implementation.
   3140 
   3141       The update from the FLAGS response MUST be recorded by the client.
   3142 
   3143    Example:    S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
   3144 
   3145 7.3.    Server Responses - Mailbox Size
   3146 
   3147    These responses are always untagged.  This is how changes in the size
   3148    of the mailbox are transmitted from the server to the client.
   3149    Immediately following the "*" token is a number that represents a
   3150    message count.
   3151 
   3152 7.3.1.  EXISTS Response
   3153 
   3154    Contents:   none
   3155 
   3156       The EXISTS response reports the number of messages in the mailbox.
   3157       This response occurs as a result of a SELECT or EXAMINE command,
   3158       and if the size of the mailbox changes (e.g., new messages).
   3159 
   3160       The update from the EXISTS response MUST be recorded by the
   3161       client.
   3162 
   3163    Example:    S: * 23 EXISTS
   3164 
   3165 7.3.2.  RECENT Response
   3166 
   3167    Contents:   none
   3168 
   3169       The RECENT response reports the number of messages with the
   3170       \Recent flag set.  This response occurs as a result of a SELECT or
   3171       EXAMINE command, and if the size of the mailbox changes (e.g., new
   3172       messages).
   3173 
   3174            Note: It is not guaranteed that the message sequence
   3175            numbers of recent messages will be a contiguous range of
   3176            the highest n messages in the mailbox (where n is the
   3177            value reported by the RECENT response).  Examples of
   3178            situations in which this is not the case are: multiple
   3179            clients having the same mailbox open (the first session
   3180            to be notified will see it as recent, others will
   3181            probably see it as non-recent), and when the mailbox is
   3182            re-ordered by a non-IMAP agent.
   3183 
   3184            The only reliable way to identify recent messages is to
   3185            look at message flags to see which have the \Recent flag
   3186            set, or to do a SEARCH RECENT.
   3187 
   3188       The update from the RECENT response MUST be recorded by the
   3189       client.
   3190 
   3191    Example:    S: * 5 RECENT
   3192 
   3193 7.4.    Server Responses - Message Status
   3194 
   3195    These responses are always untagged.  This is how message data are
   3196    transmitted from the server to the client, often as a result of a
   3197    command with the same name.  Immediately following the "*" token is a
   3198    number that represents a message sequence number.
   3199 
   3200 7.4.1.  EXPUNGE Response
   3201 
   3202    Contents:   none
   3203 
   3204       The EXPUNGE response reports that the specified message sequence
   3205       number has been permanently removed from the mailbox.  The message
   3206       sequence number for each successive message in the mailbox is
   3207       immediately decremented by 1, and this decrement is reflected in
   3208       message sequence numbers in subsequent responses (including other
   3209       untagged EXPUNGE responses).
   3210 
   3211       The EXPUNGE response also decrements the number of messages in the
   3212       mailbox; it is not necessary to send an EXISTS response with the
   3213       new value.
   3214 
   3215       As a result of the immediate decrement rule, message sequence
   3216       numbers that appear in a set of successive EXPUNGE responses
   3217       depend upon whether the messages are removed starting from lower
   3218       numbers to higher numbers, or from higher numbers to lower
   3219       numbers.  For example, if the last 5 messages in a 9-message
   3220       mailbox are expunged, a "lower to higher" server will send five
   3221       untagged EXPUNGE responses for message sequence number 5, whereas
   3222       a "higher to lower server" will send successive untagged EXPUNGE
   3223       responses for message sequence numbers 9, 8, 7, 6, and 5.
   3224 
   3225       An EXPUNGE response MUST NOT be sent when no command is in
   3226       progress, nor while responding to a FETCH, STORE, or SEARCH
   3227       command.  This rule is necessary to prevent a loss of
   3228       synchronization of message sequence numbers between client and
   3229       server.  A command is not "in progress" until the complete command
   3230       has been received; in particular, a command is not "in progress"
   3231       during the negotiation of command continuation.
   3232 
   3233            Note: UID FETCH, UID STORE, and UID SEARCH are different
   3234            commands from FETCH, STORE, and SEARCH.  An EXPUNGE
   3235            response MAY be sent during a UID command.
   3236 
   3237       The update from the EXPUNGE response MUST be recorded by the
   3238       client.
   3239 
   3240    Example:    S: * 44 EXPUNGE
   3241 
   3242 7.4.2.  FETCH Response
   3243 
   3244    Contents:   message data
   3245 
   3246       The FETCH response returns data about a message to the client.
   3247       The data are pairs of data item names and their values in
   3248       parentheses.  This response occurs as the result of a FETCH or
   3249       STORE command, as well as by unilateral server decision (e.g.,
   3250       flag updates).
   3251 
   3252       The current data items are:
   3253 
   3254       BODY
   3255          A form of BODYSTRUCTURE without extension data.
   3256 
   3257       BODY[<section>]<<origin octet>>
   3258          A string expressing the body contents of the specified section.
   3259          The string SHOULD be interpreted by the client according to the
   3260          content transfer encoding, body type, and subtype.
   3261 
   3262          If the origin octet is specified, this string is a substring of
   3263          the entire body contents, starting at that origin octet.  This
   3264          means that BODY[]<0> MAY be truncated, but BODY[] is NEVER
   3265          truncated.
   3266 
   3267             Note: The origin octet facility MUST NOT be used by a server
   3268             in a FETCH response unless the client specifically requested
   3269             it by means of a FETCH of a BODY[<section>]<<partial>> data
   3270             item.
   3271 
   3272          8-bit textual data is permitted if a [CHARSET] identifier is
   3273          part of the body parameter parenthesized list for this section.
   3274          Note that headers (part specifiers HEADER or MIME, or the
   3275          header portion of a MESSAGE/RFC822 part), MUST be 7-bit; 8-bit
   3276          characters are not permitted in headers.  Note also that the
   3277          [_R_F_C_-_2_8_2_2] delimiting blank line between the header and the
   3278          body is not affected by header line subsetting; the blank line
   3279          is always included as part of header data, except in the case
   3280          of a message which has no body and no blank line.
   3281 
   3282          Non-textual data such as binary data MUST be transfer encoded
   3283          into a textual form, such as BASE64, prior to being sent to the
   3284          client.  To derive the original binary data, the client MUST
   3285          decode the transfer encoded string.
   3286 
   3287       BODYSTRUCTURE
   3288          A parenthesized list that describes the [MIME-IMB] body
   3289          structure of a message.  This is computed by the server by
   3290          parsing the [MIME-IMB] header fields, defaulting various fields
   3291          as necessary.
   3292 
   3293          For example, a simple text message of 48 lines and 2279 octets
   3294          can have a body structure of: ("TEXT" "PLAIN" ("CHARSET"
   3295          "US-ASCII") NIL NIL "7BIT" 2279 48)
   3296 
   3297          Multiple parts are indicated by parenthesis nesting.  Instead
   3298          of a body type as the first element of the parenthesized list,
   3299          there is a sequence of one or more nested body structures.  The
   3300          second element of the parenthesized list is the multipart
   3301          subtype (mixed, digest, parallel, alternative, etc.).
   3302 
   3303          For example, a two part message consisting of a text and a
   3304          BASE64-encoded text attachment can have a body structure of:
   3305          (("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152
   3306          23)("TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" "cc.diff")
   3307          "<_9_6_0_7_2_3_1_6_3_4_0_7_._2_0_1_1_7_h_@_c_a_c_._w_a_s_h_i_n_g_t_o_n_._e_d_u>" "Compiler diff"
   3308          "BASE64" 4554 73) "MIXED")
   3309 
   3310          Extension data follows the multipart subtype.  Extension data
   3311          is never returned with the BODY fetch, but can be returned with
   3312          a BODYSTRUCTURE fetch.  Extension data, if present, MUST be in
   3313          the defined order.  The extension data of a multipart body part
   3314          are in the following order:
   3315 
   3316          body parameter parenthesized list
   3317             A parenthesized list of attribute/value pairs [e.g., ("foo"
   3318             "bar" "baz" "rag") where "bar" is the value of "foo", and
   3319             "rag" is the value of "baz"] as defined in [MIME-IMB].
   3320 
   3321          body disposition
   3322             A parenthesized list, consisting of a disposition type
   3323             string, followed by a parenthesized list of disposition
   3324             attribute/value pairs as defined in [DISPOSITION].
   3325 
   3326          body language
   3327             A string or parenthesized list giving the body language
   3328             value as defined in [LANGUAGE-TAGS].
   3329 
   3330          body location
   3331             A string list giving the body content URI as defined in
   3332             [LOCATION].
   3333 
   3334          Any following extension data are not yet defined in this
   3335          version of the protocol.  Such extension data can consist of
   3336          zero or more NILs, strings, numbers, or potentially nested
   3337          parenthesized lists of such data.  Client implementations that
   3338          do a BODYSTRUCTURE fetch MUST be prepared to accept such
   3339          extension data.  Server implementations MUST NOT send such
   3340          extension data until it has been defined by a revision of this
   3341          protocol.
   3342 
   3343          The basic fields of a non-multipart body part are in the
   3344          following order:
   3345 
   3346          body type
   3347             A string giving the content media type name as defined in
   3348             [MIME-IMB].
   3349 
   3350          body subtype
   3351             A string giving the content subtype name as defined in
   3352             [MIME-IMB].
   3353 
   3354          body parameter parenthesized list
   3355             A parenthesized list of attribute/value pairs [e.g., ("foo"
   3356             "bar" "baz" "rag") where "bar" is the value of "foo" and
   3357             "rag" is the value of "baz"] as defined in [MIME-IMB].
   3358 
   3359          body id
   3360             A string giving the content id as defined in [MIME-IMB].
   3361 
   3362          body description
   3363             A string giving the content description as defined in
   3364             [MIME-IMB].
   3365 
   3366          body encoding
   3367             A string giving the content transfer encoding as defined in
   3368             [MIME-IMB].
   3369 
   3370          body size
   3371             A number giving the size of the body in octets.  Note that
   3372             this size is the size in its transfer encoding and not the
   3373             resulting size after any decoding.
   3374 
   3375          A body type of type MESSAGE and subtype _R_F_C_8_2_2 contains,
   3376          immediately after the basic fields, the envelope structure,
   3377          body structure, and size in text lines of the encapsulated
   3378          message.
   3379 
   3380          A body type of type TEXT contains, immediately after the basic
   3381          fields, the size of the body in text lines.  Note that this
   3382          size is the size in its content transfer encoding and not the
   3383          resulting size after any decoding.
   3384 
   3385          Extension data follows the basic fields and the type-specific
   3386          fields listed above.  Extension data is never returned with the
   3387          BODY fetch, but can be returned with a BODYSTRUCTURE fetch.
   3388          Extension data, if present, MUST be in the defined order.
   3389 
   3390          The extension data of a non-multipart body part are in the
   3391          following order:
   3392 
   3393          body MD5
   3394             A string giving the body MD5 value as defined in [MD5].
   3395 
   3396          body disposition
   3397             A parenthesized list with the same content and function as
   3398             the body disposition for a multipart body part.
   3399 
   3400          body language
   3401             A string or parenthesized list giving the body language
   3402             value as defined in [LANGUAGE-TAGS].
   3403 
   3404          body location
   3405             A string list giving the body content URI as defined in
   3406             [LOCATION].
   3407 
   3408          Any following extension data are not yet defined in this
   3409          version of the protocol, and would be as described above under
   3410          multipart extension data.
   3411 
   3412       ENVELOPE
   3413          A parenthesized list that describes the envelope structure of a
   3414          message.  This is computed by the server by parsing the
   3415          [_R_F_C_-_2_8_2_2] header into the component parts, defaulting various
   3416          fields as necessary.
   3417 
   3418          The fields of the envelope structure are in the following
   3419          order: date, subject, from, sender, reply-to, to, cc, bcc,
   3420          in-reply-to, and message-id.  The date, subject, in-reply-to,
   3421          and message-id fields are strings.  The from, sender, reply-to,
   3422          to, cc, and bcc fields are parenthesized lists of address
   3423          structures.
   3424 
   3425          An address structure is a parenthesized list that describes an
   3426          electronic mail address.  The fields of an address structure
   3427          are in the following order: personal name, [SMTP]
   3428          at-domain-list (source route), mailbox name, and host name.
   3429 
   3430          [_R_F_C_-_2_8_2_2] group syntax is indicated by a special form of
   3431          address structure in which the host name field is NIL.  If the
   3432          mailbox name field is also NIL, this is an end of group marker
   3433          (semi-colon in _R_F_C_ _8_2_2 syntax).  If the mailbox name field is
   3434          non-NIL, this is a start of group marker, and the mailbox name
   3435          field holds the group name phrase.
   3436 
   3437          If the Date, Subject, In-Reply-To, and Message-ID header lines
   3438          are absent in the [_R_F_C_-_2_8_2_2] header, the corresponding member
   3439          of the envelope is NIL; if these header lines are present but
   3440          empty the corresponding member of the envelope is the empty
   3441          string.
   3442 
   3443             Note: some servers may return a NIL envelope member in the
   3444             "present but empty" case.  Clients SHOULD treat NIL and
   3445             empty string as identical.
   3446 
   3447             Note: [_R_F_C_-_2_8_2_2] requires that all messages have a valid
   3448             Date header.  Therefore, the date member in the envelope can
   3449             not be NIL or the empty string.
   3450 
   3451             Note: [_R_F_C_-_2_8_2_2] requires that the In-Reply-To and
   3452             Message-ID headers, if present, have non-empty content.
   3453             Therefore, the in-reply-to and message-id members in the
   3454             envelope can not be the empty string.
   3455 
   3456          If the From, To, cc, and bcc header lines are absent in the
   3457          [_R_F_C_-_2_8_2_2] header, or are present but empty, the corresponding
   3458          member of the envelope is NIL.
   3459 
   3460          If the Sender or Reply-To lines are absent in the [_R_F_C_-_2_8_2_2]
   3461          header, or are present but empty, the server sets the
   3462          corresponding member of the envelope to be the same value as
   3463          the from member (the client is not expected to know to do
   3464          this).
   3465 
   3466             Note: [_R_F_C_-_2_8_2_2] requires that all messages have a valid
   3467             From header.  Therefore, the from, sender, and reply-to
   3468             members in the envelope can not be NIL.
   3469 
   3470       FLAGS
   3471          A parenthesized list of flags that are set for this message.
   3472 
   3473       INTERNALDATE
   3474          A string representing the internal date of the message.
   3475 
   3476       _R_F_C_8_2_2
   3477          Equivalent to BODY[].
   3478 
   3479       _R_F_C_8_2_2.HEADER
   3480          Equivalent to BODY[HEADER].  Note that this did not result in
   3481          \Seen being set, because _R_F_C_8_2_2.HEADER response data occurs as
   3482          a result of a FETCH of _R_F_C_8_2_2.HEADER.  BODY[HEADER] response
   3483          data occurs as a result of a FETCH of BODY[HEADER] (which sets
   3484          \Seen) or BODY.PEEK[HEADER] (which does not set \Seen).
   3485 
   3486       _R_F_C_8_2_2.SIZE
   3487          A number expressing the [_R_F_C_-_2_8_2_2] size of the message.
   3488 
   3489       _R_F_C_8_2_2.TEXT
   3490          Equivalent to BODY[TEXT].
   3491 
   3492       UID
   3493          A number expressing the unique identifier of the message.
   3494 
   3495    Example:    S: * 23 FETCH (FLAGS (\Seen) _R_F_C_8_2_2.SIZE 44827)
   3496 
   3497 7.5.    Server Responses - Command Continuation Request
   3498 
   3499    The command continuation request response is indicated by a "+" token
   3500    instead of a tag.  This form of response indicates that the server is
   3501    ready to accept the continuation of a command from the client.  The
   3502    remainder of this response is a line of text.
   3503 
   3504    This response is used in the AUTHENTICATE command to transmit server
   3505    data to the client, and request additional client data.  This
   3506    response is also used if an argument to any command is a literal.
   3507 
   3508    The client is not permitted to send the octets of the literal unless
   3509    the server indicates that it is expected.  This permits the server to
   3510    process commands and reject errors on a line-by-line basis.  The
   3511    remainder of the command, including the CRLF that terminates a
   3512    command, follows the octets of the literal.  If there are any
   3513    additional command arguments, the literal octets are followed by a
   3514    space and those arguments.
   3515 
   3516    Example:    C: A001 LOGIN {11}
   3517                S: + Ready for additional command text
   3518                C: FRED FOOBAR {7}
   3519                S: + Ready for additional command text
   3520                C: fat man
   3521                S: A001 OK LOGIN completed
   3522                C: A044 BLURDYBLOOP {102856}
   3523                S: A044 BAD No such command as "BLURDYBLOOP"
   3524 
   3525 8.      Sample IMAP4rev1 connection
   3526 
   3527    The following is a transcript of an IMAP4rev1 connection.  A long
   3528    line in this sample is broken for editorial clarity.
   3529 
   3530 S:   * OK IMAP4rev1 Service Ready
   3531 C:   a001 login mrc secret
   3532 S:   a001 OK LOGIN completed
   3533 C:   a002 select inbox
   3534 S:   * 18 EXISTS
   3535 S:   * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
   3536 S:   * 2 RECENT
   3537 S:   * OK [UNSEEN 17] Message 17 is the first unseen message
   3538 S:   * OK [UIDVALIDITY 3857529045] UIDs valid
   3539 S:   a002 OK [READ-WRITE] SELECT completed
   3540 C:   a003 fetch 12 full
   3541 S:   * 12 FETCH (FLAGS (\Seen) INTERNALDATE "17-Jul-1996 02:44:25 -0700"
   3542       _R_F_C_8_2_2.SIZE 4286 ENVELOPE ("Wed, 17 Jul 1996 02:23:25 -0700 (PDT)"
   3543       "IMAP4rev1 WG mtg summary and minutes"
   3544       (("Terry Gray" NIL "gray" "cac.washington.edu"))
   3545       (("Terry Gray" NIL "gray" "cac.washington.edu"))
   3546       (("Terry Gray" NIL "gray" "cac.washington.edu"))
   3547       ((NIL NIL "imap" "cac.washington.edu"))
   3548       ((NIL NIL "minutes" "CNRI.Reston.VA.US")
   3549       ("John Klensin" NIL "KLENSIN" "MIT.EDU")) NIL NIL
   3550       "<_B_2_7_3_9_7_-_0_1_0_0_0_0_0_@_c_a_c_._w_a_s_h_i_n_g_t_o_n_._e_d_u>")
   3551        BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028
   3552        92))
   3553 S:    a003 OK FETCH completed
   3554 C:    a004 fetch 12 body[header]
   3555 S:    * 12 FETCH (BODY[HEADER] {342}
   3556 S:    Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)
   3557 S:    From: Terry Gray <_g_r_a_y_@_c_a_c_._w_a_s_h_i_n_g_t_o_n_._e_d_u>
   3558 S:    Subject: IMAP4rev1 WG mtg summary and minutes
   3559 S:    To: _i_m_a_p_@_c_a_c_._w_a_s_h_i_n_g_t_o_n_._e_d_u
   3560 S:    cc: _m_i_n_u_t_e_s_@_C_N_R_I_._R_e_s_t_o_n_._V_A_._U_S, John Klensin <_K_L_E_N_S_I_N_@_M_I_T_._E_D_U>
   3561 S:    Message-Id: <B27397-0100000@cac.washington.edu>
   3562 S:    MIME-Version: 1.0
   3563 S:    Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
   3564 S:
   3565 S:    )
   3566 S:    a004 OK FETCH completed
   3567 C:    a005 store 12 +flags \deleted
   3568 S:    * 12 FETCH (FLAGS (\Seen \Deleted))
   3569 S:    a005 OK +FLAGS completed
   3570 C:    a006 logout
   3571 S:    * BYE IMAP4rev1 server terminating connection
   3572 S:    a006 OK LOGOUT completed
   3573 
   3574 9.      Formal Syntax
   3575 
   3576    The following syntax specification uses the Augmented Backus-Naur
   3577    Form (ABNF) notation as specified in [ABNF].
   3578 
   3579    In the case of alternative or optional rules in which a later rule
   3580    overlaps an earlier rule, the rule which is listed earlier MUST take
   3581    priority.  For example, "\Seen" when parsed as a flag is the \Seen
   3582    flag name and not a flag-extension, even though "\Seen" can be parsed
   3583    as a flag-extension.  Some, but not all, instances of this rule are
   3584    noted below.
   3585 
   3586         Note: [ABNF] rules MUST be followed strictly; in
   3587         particular:
   3588 
   3589         (1) Except as noted otherwise, all alphabetic characters
   3590         are case-insensitive.  The use of upper or lower case
   3591         characters to define token strings is for editorial clarity
   3592         only.  Implementations MUST accept these strings in a
   3593         case-insensitive fashion.
   3594 
   3595         (2) In all cases, SP refers to exactly one space.  It is
   3596         NOT permitted to substitute TAB, insert additional spaces,
   3597         or otherwise treat SP as being equivalent to LWSP.
   3598 
   3599         (3) The ASCII NUL character, %x00, MUST NOT be used at any
   3600         time.
   3601 
   3602 address         = "(" addr-name SP addr-adl SP addr-mailbox SP
   3603                   addr-host ")"
   3604 
   3605 addr-adl        = nstring
   3606                     ; Holds route from [_R_F_C_-_2_8_2_2] route-addr if
   3607                     ; non-NIL
   3608 
   3609 addr-host       = nstring
   3610                     ; NIL indicates [_R_F_C_-_2_8_2_2] group syntax.
   3611                     ; Otherwise, holds [_R_F_C_-_2_8_2_2] domain name
   3612 
   3613 addr-mailbox    = nstring
   3614                     ; NIL indicates end of [_R_F_C_-_2_8_2_2] group; if
   3615                     ; non-NIL and addr-host is NIL, holds
   3616                     ; [_R_F_C_-_2_8_2_2] group name.
   3617                     ; Otherwise, holds [_R_F_C_-_2_8_2_2] local-part
   3618                     ; after removing [_R_F_C_-_2_8_2_2] quoting
   3619 
   3620 addr-name       = nstring
   3621                     ; If non-NIL, holds phrase from [_R_F_C_-_2_8_2_2]
   3622                     ; mailbox after removing [_R_F_C_-_2_8_2_2] quoting
   3623 
   3624 append          = "APPEND" SP mailbox [SP flag-list] [SP date-time] SP
   3625                   literal
   3626 
   3627 astring         = 1*ASTRING-CHAR / string
   3628 
   3629 ASTRING-CHAR   = ATOM-CHAR / resp-specials
   3630 
   3631 atom            = 1*ATOM-CHAR
   3632 
   3633 ATOM-CHAR       = <any CHAR except atom-specials>
   3634 
   3635 atom-specials   = "(" / ")" / "{" / SP / CTL / list-wildcards /
   3636                   quoted-specials / resp-specials
   3637 
   3638 authenticate    = "AUTHENTICATE" SP auth-type *(CRLF base64)
   3639 
   3640 auth-type       = atom
   3641                     ; Defined by [SASL]
   3642 
   3643 base64          = *(4base64-char) [base64-terminal]
   3644 
   3645 base64-char     = ALPHA / DIGIT / "+" / "/"
   3646                     ; Case-sensitive
   3647 
   3648 base64-terminal = (2base64-char "==") / (3base64-char "=")
   3649 
   3650 body            = "(" (body-type-1part / body-type-mpart) ")"
   3651 
   3652 body-extension  = nstring / number /
   3653                    "(" body-extension *(SP body-extension) ")"
   3654                     ; Future expansion.  Client implementations
   3655                     ; MUST accept body-extension fields.  Server
   3656                     ; implementations MUST NOT generate
   3657                     ; body-extension fields except as defined by
   3658                     ; future standard or standards-track
   3659                     ; revisions of this specification.
   3660 
   3661 body-ext-1part  = body-fld-md5 [SP body-fld-dsp [SP body-fld-lang
   3662                   [SP body-fld-loc *(SP body-extension)]]]
   3663                     ; MUST NOT be returned on non-extensible
   3664                     ; "BODY" fetch
   3665 
   3666 body-ext-mpart  = body-fld-param [SP body-fld-dsp [SP body-fld-lang
   3667                   [SP body-fld-loc *(SP body-extension)]]]
   3668                     ; MUST NOT be returned on non-extensible
   3669                     ; "BODY" fetch
   3670 
   3671 body-fields     = body-fld-param SP body-fld-id SP body-fld-desc SP
   3672                   body-fld-enc SP body-fld-octets
   3673 
   3674 body-fld-desc   = nstring
   3675 
   3676 body-fld-dsp    = "(" string SP body-fld-param ")" / nil
   3677 
   3678 body-fld-enc    = (DQUOTE ("7BIT" / "8BIT" / "BINARY" / "BASE64"/
   3679                   "QUOTED-PRINTABLE") DQUOTE) / string
   3680 
   3681 body-fld-id     = nstring
   3682 
   3683 body-fld-lang   = nstring / "(" string *(SP string) ")"
   3684 
   3685 body-fld-loc    = nstring
   3686 
   3687 body-fld-lines  = number
   3688 
   3689 body-fld-md5    = nstring
   3690 
   3691 body-fld-octets = number
   3692 
   3693 body-fld-param  = "(" string SP string *(SP string SP string) ")" / nil
   3694 
   3695 body-type-1part = (body-type-basic / body-type-msg / body-type-text)
   3696                   [SP body-ext-1part]
   3697 
   3698 body-type-basic = media-basic SP body-fields
   3699                     ; MESSAGE subtype MUST NOT be "_R_F_C_8_2_2"
   3700 
   3701 body-type-mpart = 1*body SP media-subtype
   3702                   [SP body-ext-mpart]
   3703 
   3704 body-type-msg   = media-message SP body-fields SP envelope
   3705                   SP body SP body-fld-lines
   3706 
   3707 body-type-text  = media-text SP body-fields SP body-fld-lines
   3708 
   3709 capability      = ("AUTH=" auth-type) / atom
   3710                     ; New capabilities MUST begin with "X" or be
   3711                     ; registered with IANA as standard or
   3712                     ; standards-track
   3713 
   3714 capability-data = "CAPABILITY" *(SP capability) SP "IMAP4rev1"
   3715                   *(SP capability)
   3716                     ; Servers MUST implement the STARTTLS, AUTH=PLAIN,
   3717                     ; and LOGINDISABLED capabilities
   3718                     ; Servers which offer _R_F_C_ _1_7_3_0 compatibility MUST
   3719                     ; list "IMAP4" as the first capability.
   3720 
   3721 CHAR8           = %x01-ff
   3722                     ; any OCTET except NUL, %x00
   3723 
   3724 command         = tag SP (command-any / command-auth / command-nonauth /
   3725                   command-select) CRLF
   3726                     ; Modal based on state
   3727 
   3728 command-any     = "CAPABILITY" / "LOGOUT" / "NOOP" / x-command
   3729                     ; Valid in all states
   3730 
   3731 command-auth    = append / create / delete / examine / list / lsub /
   3732                   rename / select / status / subscribe / unsubscribe
   3733                     ; Valid only in Authenticated or Selected state
   3734 
   3735 command-nonauth = login / authenticate / "STARTTLS"
   3736                     ; Valid only when in Not Authenticated state
   3737 
   3738 command-select  = "CHECK" / "CLOSE" / "EXPUNGE" / copy / fetch / store /
   3739                   uid / search
   3740                     ; Valid only when in Selected state
   3741 
   3742 continue-req    = "+" SP (resp-text / base64) CRLF
   3743 
   3744 copy            = "COPY" SP sequence-set SP mailbox
   3745 
   3746 create          = "CREATE" SP mailbox
   3747                     ; Use of INBOX gives a NO error
   3748 
   3749 date            = date-text / DQUOTE date-text DQUOTE
   3750 
   3751 date-day        = 1*2DIGIT
   3752                     ; Day of month
   3753 
   3754 date-day-fixed  = (SP DIGIT) / 2DIGIT
   3755                     ; Fixed-format version of date-day
   3756 
   3757 date-month      = "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" /
   3758                   "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec"
   3759 
   3760 date-text       = date-day "-" date-month "-" date-year
   3761 
   3762 date-year       = 4DIGIT
   3763 
   3764 date-time       = DQUOTE date-day-fixed "-" date-month "-" date-year
   3765                   SP time SP zone DQUOTE
   3766 
   3767 delete          = "DELETE" SP mailbox
   3768                     ; Use of INBOX gives a NO error
   3769 
   3770 digit-nz        = %x31-39
   3771                     ; 1-9
   3772 
   3773 envelope        = "(" env-date SP env-subject SP env-from SP
   3774                   env-sender SP env-reply-to SP env-to SP env-cc SP
   3775                   env-bcc SP env-in-reply-to SP env-message-id ")"
   3776 
   3777 env-bcc         = "(" 1*address ")" / nil
   3778 
   3779 env-cc          = "(" 1*address ")" / nil
   3780 
   3781 env-date        = nstring
   3782 
   3783 env-from        = "(" 1*address ")" / nil
   3784 
   3785 env-in-reply-to = nstring
   3786 
   3787 env-message-id  = nstring
   3788 
   3789 env-reply-to    = "(" 1*address ")" / nil
   3790 
   3791 env-sender      = "(" 1*address ")" / nil
   3792 
   3793 env-subject     = nstring
   3794 
   3795 env-to          = "(" 1*address ")" / nil
   3796 
   3797 examine         = "EXAMINE" SP mailbox
   3798 
   3799 fetch           = "FETCH" SP sequence-set SP ("ALL" / "FULL" / "FAST" /
   3800                   fetch-att / "(" fetch-att *(SP fetch-att) ")")
   3801 
   3802 fetch-att       = "ENVELOPE" / "FLAGS" / "INTERNALDATE" /
   3803                   "_R_F_C_8_2_2" [".HEADER" / ".SIZE" / ".TEXT"] /
   3804                   "BODY" ["STRUCTURE"] / "UID" /
   3805                   "BODY" section ["<" number "." nz-number ">"] /
   3806                   "BODY.PEEK" section ["<" number "." nz-number ">"]
   3807 
   3808 flag            = "\Answered" / "\Flagged" / "\Deleted" /
   3809                   "\Seen" / "\Draft" / flag-keyword / flag-extension
   3810                     ; Does not include "\Recent"
   3811 
   3812 flag-extension  = "\" atom
   3813                     ; Future expansion.  Client implementations
   3814                     ; MUST accept flag-extension flags.  Server
   3815                     ; implementations MUST NOT generate
   3816                     ; flag-extension flags except as defined by
   3817                     ; future standard or standards-track
   3818                     ; revisions of this specification.
   3819 
   3820 flag-fetch      = flag / "\Recent"
   3821 
   3822 flag-keyword    = atom
   3823 
   3824 flag-list       = "(" [flag *(SP flag)] ")"
   3825 
   3826 flag-perm       = flag / "\*"
   3827 
   3828 greeting        = "*" SP (resp-cond-auth / resp-cond-bye) CRLF
   3829 
   3830 header-fld-name = astring
   3831 
   3832 header-list     = "(" header-fld-name *(SP header-fld-name) ")"
   3833 
   3834 list            = "LIST" SP mailbox SP list-mailbox
   3835 
   3836 list-mailbox    = 1*list-char / string
   3837 
   3838 list-char       = ATOM-CHAR / list-wildcards / resp-specials
   3839 
   3840 list-wildcards  = "%" / "*"
   3841 
   3842 literal         = "{" number "}" CRLF *CHAR8
   3843                     ; Number represents the number of CHAR8s
   3844 
   3845 login           = "LOGIN" SP userid SP password
   3846 
   3847 lsub            = "LSUB" SP mailbox SP list-mailbox
   3848 
   3849 mailbox         = "INBOX" / astring
   3850                     ; INBOX is case-insensitive.  All case variants of
   3851                     ; INBOX (e.g., "iNbOx") MUST be interpreted as INBOX
   3852                     ; not as an astring.  An astring which consists of
   3853                     ; the case-insensitive sequence "I" "N" "B" "O" "X"
   3854                     ; is considered to be INBOX and not an astring.
   3855                     ;  Refer to section 5.1 for further
   3856                     ; semantic details of mailbox names.
   3857 
   3858 mailbox-data    =  "FLAGS" SP flag-list / "LIST" SP mailbox-list /
   3859                    "LSUB" SP mailbox-list / "SEARCH" *(SP nz-number) /
   3860                    "STATUS" SP mailbox SP "(" [status-att-list] ")" /
   3861                    number SP "EXISTS" / number SP "RECENT"
   3862 
   3863 mailbox-list    = "(" [mbx-list-flags] ")" SP
   3864                    (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox
   3865 
   3866 mbx-list-flags  = *(mbx-list-oflag SP) mbx-list-sflag
   3867                   *(SP mbx-list-oflag) /
   3868                   mbx-list-oflag *(SP mbx-list-oflag)
   3869 
   3870 mbx-list-oflag  = "\Noinferiors" / flag-extension
   3871                     ; Other flags; multiple possible per LIST response
   3872 
   3873 mbx-list-sflag  = "\Noselect" / "\Marked" / "\Unmarked"
   3874                     ; Selectability flags; only one per LIST response
   3875 
   3876 media-basic     = ((DQUOTE ("APPLICATION" / "AUDIO" / "IMAGE" /
   3877                   "MESSAGE" / "VIDEO") DQUOTE) / string) SP
   3878                   media-subtype
   3879                     ; Defined in [MIME-IMT]
   3880 
   3881 media-message   = DQUOTE "MESSAGE" DQUOTE SP DQUOTE "_R_F_C_8_2_2" DQUOTE
   3882                     ; Defined in [MIME-IMT]
   3883 
   3884 media-subtype   = string
   3885                     ; Defined in [MIME-IMT]
   3886 
   3887 media-text      = DQUOTE "TEXT" DQUOTE SP media-subtype
   3888                     ; Defined in [MIME-IMT]
   3889 
   3890 message-data    = nz-number SP ("EXPUNGE" / ("FETCH" SP msg-att))
   3891 
   3892 msg-att         = "(" (msg-att-dynamic / msg-att-static)
   3893                    *(SP (msg-att-dynamic / msg-att-static)) ")"
   3894 
   3895 msg-att-dynamic = "FLAGS" SP "(" [flag-fetch *(SP flag-fetch)] ")"
   3896                     ; MAY change for a message
   3897 
   3898 msg-att-static  = "ENVELOPE" SP envelope / "INTERNALDATE" SP date-time /
   3899                   "_R_F_C_8_2_2" [".HEADER" / ".TEXT"] SP nstring /
   3900                   "_R_F_C_8_2_2.SIZE" SP number /
   3901                   "BODY" ["STRUCTURE"] SP body /
   3902                   "BODY" section ["<" number ">"] SP nstring /
   3903                   "UID" SP uniqueid
   3904                     ; MUST NOT change for a message
   3905 
   3906 nil             = "NIL"
   3907 
   3908 nstring         = string / nil
   3909 
   3910 number          = 1*DIGIT
   3911                     ; Unsigned 32-bit integer
   3912                     ; (0 <= n < 4,294,967,296)
   3913 
   3914 nz-number       = digit-nz *DIGIT
   3915                     ; Non-zero unsigned 32-bit integer
   3916                     ; (0 < n < 4,294,967,296)
   3917 
   3918 password        = astring
   3919 
   3920 quoted          = DQUOTE *QUOTED-CHAR DQUOTE
   3921 
   3922 QUOTED-CHAR     = <any TEXT-CHAR except quoted-specials> /
   3923                   "\" quoted-specials
   3924 
   3925 quoted-specials = DQUOTE / "\"
   3926 
   3927 rename          = "RENAME" SP mailbox SP mailbox
   3928                     ; Use of INBOX as a destination gives a NO error
   3929 
   3930 response        = *(continue-req / response-data) response-done
   3931 
   3932 response-data   = "*" SP (resp-cond-state / resp-cond-bye /
   3933                   mailbox-data / message-data / capability-data) CRLF
   3934 
   3935 response-done   = response-tagged / response-fatal
   3936 
   3937 response-fatal  = "*" SP resp-cond-bye CRLF
   3938                     ; Server closes connection immediately
   3939 
   3940 response-tagged = tag SP resp-cond-state CRLF
   3941 
   3942 resp-cond-auth  = ("OK" / "PREAUTH") SP resp-text
   3943                     ; Authentication condition
   3944 
   3945 resp-cond-bye   = "BYE" SP resp-text
   3946 
   3947 resp-cond-state = ("OK" / "NO" / "BAD") SP resp-text
   3948                     ; Status condition
   3949 
   3950 resp-specials   = "]"
   3951 
   3952 resp-text       = ["[" resp-text-code "]" SP] text
   3953 
   3954 resp-text-code  = "ALERT" /
   3955                   "BADCHARSET" [SP "(" astring *(SP astring) ")" ] /
   3956                   capability-data / "PARSE" /
   3957                   "PERMANENTFLAGS" SP "("
   3958                   [flag-perm *(SP flag-perm)] ")" /
   3959                   "READ-ONLY" / "READ-WRITE" / "TRYCREATE" /
   3960                   "UIDNEXT" SP nz-number / "UIDVALIDITY" SP nz-number /
   3961                   "UNSEEN" SP nz-number /
   3962                   atom [SP 1*<any TEXT-CHAR except "]">]
   3963 
   3964 search          = "SEARCH" [SP "CHARSET" SP astring] 1*(SP search-key)
   3965                     ; CHARSET argument to MUST be registered with IANA
   3966 
   3967 search-key      = "ALL" / "ANSWERED" / "BCC" SP astring /
   3968                   "BEFORE" SP date / "BODY" SP astring /
   3969                   "CC" SP astring / "DELETED" / "FLAGGED" /
   3970                   "FROM" SP astring / "KEYWORD" SP flag-keyword /
   3971                   "NEW" / "OLD" / "ON" SP date / "RECENT" / "SEEN" /
   3972                   "SINCE" SP date / "SUBJECT" SP astring /
   3973                   "TEXT" SP astring / "TO" SP astring /
   3974                   "UNANSWERED" / "UNDELETED" / "UNFLAGGED" /
   3975                   "UNKEYWORD" SP flag-keyword / "UNSEEN" /
   3976                     ; Above this line were in [IMAP2]
   3977                   "DRAFT" / "HEADER" SP header-fld-name SP astring /
   3978                   "LARGER" SP number / "NOT" SP search-key /
   3979                   "OR" SP search-key SP search-key /
   3980                   "SENTBEFORE" SP date / "SENTON" SP date /
   3981                   "SENTSINCE" SP date / "SMALLER" SP number /
   3982                   "UID" SP sequence-set / "UNDRAFT" / sequence-set /
   3983                   "(" search-key *(SP search-key) ")"
   3984 
   3985 section         = "[" [section-spec] "]"
   3986 
   3987 section-msgtext = "HEADER" / "HEADER.FIELDS" [".NOT"] SP header-list /
   3988                   "TEXT"
   3989                     ; top-level or MESSAGE/RFC822 part
   3990 
   3991 section-part    = nz-number *("." nz-number)
   3992                     ; body part nesting
   3993 
   3994 section-spec    = section-msgtext / (section-part ["." section-text])
   3995 
   3996 section-text    = section-msgtext / "MIME"
   3997                     ; text other than actual body part (headers, etc.)
   3998 
   3999 select          = "SELECT" SP mailbox
   4000 
   4001 seq-number      = nz-number / "*"
   4002                     ; message sequence number (COPY, FETCH, STORE
   4003                     ; commands) or unique identifier (UID COPY,
   4004                     ; UID FETCH, UID STORE commands).
   4005                     ; * represents the largest number in use.  In
   4006                     ; the case of message sequence numbers, it is
   4007                     ; the number of messages in a non-empty mailbox.
   4008                     ; In the case of unique identifiers, it is the
   4009                     ; unique identifier of the last message in the
   4010                     ; mailbox or, if the mailbox is empty, the
   4011                     ; mailbox's current UIDNEXT value.
   4012                     ; The server should respond with a tagged BAD
   4013                     ; response to a command that uses a message
   4014                     ; sequence number greater than the number of
   4015                     ; messages in the selected mailbox.  This
   4016                     ; includes "*" if the selected mailbox is empty.
   4017 
   4018 seq-range       = seq-number ":" seq-number
   4019                     ; two seq-number values and all values between
   4020                     ; these two regardless of order.
   4021                     ; Example: 2:4 and 4:2 are equivalent and indicate
   4022                     ; values 2, 3, and 4.
   4023                     ; Example: a unique identifier sequence range of
   4024                     ; 3291:* includes the UID of the last message in
   4025                     ; the mailbox, even if that value is less than 3291.
   4026 
   4027 sequence-set    = (seq-number / seq-range) *("," sequence-set)
   4028                     ; set of seq-number values, regardless of order.
   4029                     ; Servers MAY coalesce overlaps and/or execute the
   4030                     ; sequence in any order.
   4031                     ; Example: a message sequence number set of
   4032                     ; 2,4:7,9,12:* for a mailbox with 15 messages is
   4033                     ; equivalent to 2,4,5,6,7,9,12,13,14,15
   4034                     ; Example: a message sequence number set of *:4,5:7
   4035                     ; for a mailbox with 10 messages is equivalent to
   4036                     ; 10,9,8,7,6,5,4,5,6,7 and MAY be reordered and
   4037                     ; overlap coalesced to be 4,5,6,7,8,9,10.
   4038 
   4039 status          = "STATUS" SP mailbox SP
   4040                   "(" status-att *(SP status-att) ")"
   4041 
   4042 status-att      = "MESSAGES" / "RECENT" / "UIDNEXT" / "UIDVALIDITY" /
   4043                   "UNSEEN"
   4044 
   4045 status-att-list =  status-att SP number *(SP status-att SP number)
   4046 
   4047 store           = "STORE" SP sequence-set SP store-att-flags
   4048 
   4049 store-att-flags = (["+" / "-"] "FLAGS" [".SILENT"]) SP
   4050                   (flag-list / (flag *(SP flag)))
   4051 
   4052 string          = quoted / literal
   4053 
   4054 subscribe       = "SUBSCRIBE" SP mailbox
   4055 
   4056 tag             = 1*<any ASTRING-CHAR except "+">
   4057 
   4058 text            = 1*TEXT-CHAR
   4059 
   4060 TEXT-CHAR       = <any CHAR except CR and LF>
   4061 
   4062 time            = 2DIGIT ":" 2DIGIT ":" 2DIGIT
   4063                     ; Hours minutes seconds
   4064 
   4065 uid             = "UID" SP (copy / fetch / search / store)
   4066                     ; Unique identifiers used instead of message
   4067                     ; sequence numbers
   4068 
   4069 uniqueid        = nz-number
   4070                     ; Strictly ascending
   4071 
   4072 unsubscribe     = "UNSUBSCRIBE" SP mailbox
   4073 
   4074 userid          = astring
   4075 
   4076 x-command       = "X" atom <experimental command arguments>
   4077 
   4078 zone            = ("+" / "-") 4DIGIT
   4079                     ; Signed four-digit value of hhmm representing
   4080                     ; hours and minutes east of Greenwich (that is,
   4081                     ; the amount that the given time differs from
   4082                     ; Universal Time).  Subtracting the timezone
   4083                     ; from the given time will give the UT form.
   4084                     ; The Universal Time zone is "+0000".
   4085 
   4086 10.     Author's Note
   4087 
   4088    This document is a revision or rewrite of earlier documents, and
   4089    supercedes the protocol specification in those documents: _R_F_C_ _2_0_6_0,
   4090    _R_F_C_ _1_7_3_0, unpublished IMAP2bis.TXT document, _R_F_C_ _1_1_7_6, and _R_F_C_ _1_0_6_4.
   4091 
   4092 11.     Security Considerations
   4093 
   4094    IMAP4rev1 protocol transactions, including electronic mail data, are
   4095    sent in the clear over the network unless protection from snooping is
   4096    negotiated.  This can be accomplished either by the use of STARTTLS,
   4097    negotiated privacy protection in the AUTHENTICATE command, or some
   4098    other protection mechanism.
   4099 
   4100 11.1.   STARTTLS Security Considerations
   4101 
   4102    The specification of the STARTTLS command and LOGINDISABLED
   4103    capability in this document replaces that in [IMAP-TLS].  [IMAP-TLS]
   4104    remains normative for the PLAIN [SASL] authenticator.
   4105 
   4106    IMAP client and server implementations MUST implement the
   4107    TLS_RSA_WITH_RC4_128_MD5 [TLS] cipher suite, and SHOULD implement the
   4108    TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] cipher suite.  This is
   4109    important as it assures that any two compliant implementations can be
   4110    configured to interoperate.  All other cipher suites are OPTIONAL.
   4111    Note that this is a change from section 2.1 of [IMAP-TLS].
   4112 
   4113    During the [TLS] negotiation, the client MUST check its understanding
   4114    of the server hostname against the server's identity as presented in
   4115    the server Certificate message, in order to prevent man-in-the-middle
   4116    attacks.  If the match fails, the client SHOULD either ask for
   4117    explicit user confirmation, or terminate the connection and indicate
   4118    that the server's identity is suspect.  Matching is performed
   4119    according to these rules:
   4120 
   4121         The client MUST use the server hostname it used to open the
   4122         connection as the value to compare against the server name
   4123         as expressed in the server certificate.  The client MUST
   4124         NOT use any form of the server hostname derived from an
   4125         insecure remote source (e.g., insecure DNS lookup).  CNAME
   4126         canonicalization is not done.
   4127 
   4128         If a subjectAltName extension of type dNSName is present in
   4129         the certificate, it SHOULD be used as the source of the
   4130         server's identity.
   4131 
   4132         Matching is case-insensitive.
   4133 
   4134         A "*" wildcard character MAY be used as the left-most name
   4135         component in the certificate.  For example, *.example.com
   4136         would match a.example.com, foo.example.com, etc. but would
   4137         not match example.com.
   4138 
   4139         If the certificate contains multiple names (e.g., more than
   4140         one dNSName field), then a match with any one of the fields
   4141         is considered acceptable.
   4142 
   4143    Both the client and server MUST check the result of the STARTTLS
   4144    command and subsequent [TLS] negotiation to see whether acceptable
   4145    authentication or privacy was achieved.
   4146 
   4147 11.2.   Other Security Considerations
   4148 
   4149    A server error message for an AUTHENTICATE command which fails due to
   4150    invalid credentials SHOULD NOT detail why the credentials are
   4151    invalid.
   4152 
   4153    Use of the LOGIN command sends passwords in the clear.  This can be
   4154    avoided by using the AUTHENTICATE command with a [SASL] mechanism
   4155    that does not use plaintext passwords, by first negotiating
   4156    encryption via STARTTLS or some other protection mechanism.
   4157 
   4158    A server implementation MUST implement a configuration that, at the
   4159    time of authentication, requires:
   4160       (1) The STARTTLS command has been negotiated.
   4161    OR
   4162       (2) Some other mechanism that protects the session from password
   4163       snooping has been provided.
   4164    OR
   4165       (3) The following measures are in place:
   4166          (a) The LOGINDISABLED capability is advertised, and [SASL]
   4167          mechanisms (such as PLAIN) using plaintext passwords are NOT
   4168          advertised in the CAPABILITY list.
   4169       AND
   4170          (b) The LOGIN command returns an error even if the password is
   4171          correct.
   4172       AND
   4173          (c) The AUTHENTICATE command returns an error with all [SASL]
   4174          mechanisms that use plaintext passwords, even if the password
   4175          is correct.
   4176 
   4177    A server error message for a failing LOGIN command SHOULD NOT specify
   4178    that the user name, as opposed to the password, is invalid.
   4179 
   4180    A server SHOULD have mechanisms in place to limit or delay failed
   4181    AUTHENTICATE/LOGIN attempts.
   4182 
   4183    Additional security considerations are discussed in the section
   4184    discussing the AUTHENTICATE and LOGIN commands.
   4185 
   4186 12.     IANA Considerations
   4187 
   4188    IMAP4 capabilities are registered by publishing a standards track or
   4189    IESG approved experimental RFC.  The registry is currently located
   4190    at:
   4191 
   4192         _h_t_t_p_:_/_/_w_w_w_._i_a_n_a_._o_r_g_/_a_s_s_i_g_n_m_e_n_t_s_/_i_m_a_p_4_-_c_a_p_a_b_i_l_i_t_i_e_s
   4193 
   4194    As this specification revises the STARTTLS and LOGINDISABLED
   4195    extensions previously defined in [IMAP-TLS], the registry will be
   4196    updated accordingly.
   4197 
   4198 Appendices
   4199 
   4200 A.      Normative References
   4201 
   4202    The following documents contain definitions or specifications that
   4203    are necessary to understand this document properly:
   4204    [ABNF]                Crocker, D. and P. Overell, "Augmented BNF for
   4205                          Syntax Specifications: ABNF", _R_F_C_ _2_2_3_4,
   4206                          November 1997.
   4207 
   4208    [ANONYMOUS]           Newman, C., "Anonymous SASL Mechanism", RFC
   4209                          2245, November 1997.
   4210 
   4211    [CHARSET]             Freed, N. and J. Postel, "IANA Character Set
   4212                          Registration Procedures", _R_F_C_ _2_9_7_8, October
   4213                          2000.
   4214 
   4215    [DIGEST-MD5]          Leach, P. and C. Newman, "Using Digest
   4216                          Authentication as a SASL Mechanism", _R_F_C_ _2_8_3_1,
   4217                          May 2000.
   4218 
   4219    [DISPOSITION]         Troost, R., Dorner, S. and K. Moore,
   4220                          "Communicating Presentation Information in
   4221                          Internet Messages: The Content-Disposition
   4222                          Header", _R_F_C_ _2_1_8_3, August 1997.
   4223 
   4224    [IMAP-TLS]            Newman, C., "Using TLS with IMAP, POP3 and
   4225                          ACAP", _R_F_C_ _2_5_9_5, June 1999.
   4226 
   4227    [KEYWORDS]            Bradner, S., "Key words for use in RFCs to
   4228                          Indicate Requirement Levels", BCP 14, _R_F_C_ _2_1_1_9,
   4229                          March 1997.
   4230 
   4231    [LANGUAGE-TAGS]       Alvestrand, H., "Tags for the Identification of
   4232                          Languages", BCP 47, _R_F_C_ _3_0_6_6, January 2001.
   4233 
   4234    [LOCATION]            Palme, J., Hopmann, A. and N. Shelness, "MIME
   4235                          Encapsulation of Aggregate Documents, such as
   4236                          HTML (MHTML)", _R_F_C_ _2_5_5_7, March 1999.
   4237 
   4238    [MD5]                 Myers, J. and M. Rose, "The Content-MD5 Header
   4239                          Field", _R_F_C_ _1_8_6_4, October 1995.
   4240 
   4241    [MIME-HDRS]           Moore, K., "MIME (Multipurpose Internet Mail
   4242                          Extensions) Part Three: Message Header
   4243                          Extensions for Non-ASCII Text", _R_F_C_ _2_0_4_7,
   4244                          November 1996.
   4245 
   4246    [MIME-IMB]            Freed, N. and N. Borenstein, "MIME
   4247                          (Multipurpose Internet Mail Extensions) Part
   4248                          One: Format of Internet Message Bodies", RFC
   4249                          2045, November 1996.
   4250 
   4251    [MIME-IMT]            Freed, N. and N. Borenstein, "MIME
   4252                          (Multipurpose Internet Mail Extensions) Part
   4253                          Two: Media Types", _R_F_C_ _2_0_4_6, November 1996.
   4254 
   4255    [_R_F_C_-_2_8_2_2]            Resnick, P., "Internet Message Format", RFC
   4256                          2822, April 2001.
   4257 
   4258    [SASL]                Myers, J., "Simple Authentication and Security
   4259                          Layer (SASL)", _R_F_C_ _2_2_2_2, October 1997.
   4260 
   4261    [TLS]                 Dierks, T. and C. Allen, "The TLS Protocol
   4262                          Version 1.0", _R_F_C_ _2_2_4_6, January 1999.
   4263 
   4264    [UTF-7]               Goldsmith, D. and M. Davis, "UTF-7: A Mail-Safe
   4265                          Transformation Format of Unicode", _R_F_C_ _2_1_5_2,
   4266                          May 1997.
   4267 
   4268    The following documents describe quality-of-implementation issues
   4269    that should be carefully considered when implementing this protocol:
   4270 
   4271    [IMAP-IMPLEMENTATION] Leiba, B., "IMAP Implementation
   4272                          Recommendations", _R_F_C_ _2_6_8_3, September 1999.
   4273 
   4274    [IMAP-MULTIACCESS]    Gahrns, M., "IMAP4 Multi-Accessed Mailbox
   4275                          Practice", _R_F_C_ _2_1_8_0, July 1997.
   4276 
   4277 A.1     Informative References
   4278 
   4279    The following documents describe related protocols:
   4280 
   4281    [IMAP-DISC]           Austein, R., "Synchronization Operations for
   4282                          Disconnected IMAP4 Clients", Work in Progress.
   4283 
   4284    [IMAP-MODEL]          Crispin, M., "Distributed Electronic Mail
   4285                          Models in IMAP4", _R_F_C_ _1_7_3_3, December 1994.
   4286 
   4287    [ACAP]                Newman, C. and J. Myers, "ACAP -- Application
   4288                          Configuration Access Protocol", _R_F_C_ _2_2_4_4,
   4289                          November 1997.
   4290 
   4291    [SMTP]                Klensin, J., "Simple Mail Transfer Protocol",
   4292                          STD 10, _R_F_C_ _2_8_2_1, April 2001.
   4293 
   4294    The following documents are historical or describe historical aspects
   4295    of this protocol:
   4296 
   4297    [IMAP-COMPAT]         Crispin, M., "IMAP4 Compatibility with
   4298                          IMAP2bis", _R_F_C_ _2_0_6_1, December 1996.
   4299 
   4300    [IMAP-HISTORICAL]     Crispin, M., "IMAP4 Compatibility with IMAP2
   4301                          and IMAP2bis", _R_F_C_ _1_7_3_2, December 1994.
   4302 
   4303    [IMAP-OBSOLETE]       Crispin, M., "Internet Message Access Protocol
   4304                          - Obsolete Syntax", _R_F_C_ _2_0_6_2, December 1996.
   4305 
   4306    [IMAP2]               Crispin, M., "Interactive Mail Access Protocol
   4307                          - Version 2", _R_F_C_ _1_1_7_6, August 1990.
   4308 
   4309    [_R_F_C_-_8_2_2]             Crocker, D., "Standard for the Format of ARPA
   4310                          Internet Text Messages", STD 11, _R_F_C_ _8_2_2,
   4311                          August 1982.
   4312 
   4313    [_R_F_C_-_8_2_1]             Postel, J., "Simple Mail Transfer Protocol",
   4314                          STD 10, _R_F_C_ _8_2_1, August 1982.
   4315 
   4316 B.      Changes from _R_F_C_ _2_0_6_0
   4317 
   4318    1) Clarify description of unique identifiers and their semantics.
   4319 
   4320    2) Fix the SELECT description to clarify that UIDVALIDITY is required
   4321    in the SELECT and EXAMINE responses.
   4322 
   4323    3) Added an example of a failing search.
   4324 
   4325    4) Correct store-att-flags: "#flag" should be "1#flag".
   4326 
   4327    5) Made search and section rules clearer.
   4328 
   4329    6) Correct the STORE example.
   4330 
   4331    7) Correct "BASE645" misspelling.
   4332 
   4333    8) Remove extraneous close parenthesis in example of two-part message
   4334    with text and BASE64 attachment.
   4335 
   4336    9) Remove obsolete "MAILBOX" response from mailbox-data.
   4337 
   4338    10) A spurious "<" in the rule for mailbox-data was removed.
   4339 
   4340    11) Add CRLF to continue-req.
   4341 
   4342    12) Specifically exclude "]" from the atom in resp-text-code.
   4343 
   4344    13) Clarify that clients and servers should adhere strictly to the
   4345    protocol syntax.
   4346 
   4347    14) Emphasize in 5.2 that EXISTS can not be used to shrink a mailbox.
   4348 
   4349    15) Add NEWNAME to resp-text-code.
   4350 
   4351    16) Clarify that the empty string, not NIL, is used as arguments to
   4352    LIST.
   4353 
   4354    17) Clarify that NIL can be returned as a hierarchy delimiter for the
   4355    empty string mailbox name argument if the mailbox namespace is flat.
   4356 
   4357    18) Clarify that addr-mailbox and addr-name have _R_F_C_-_2_8_2_2 quoting
   4358    removed.
   4359 
   4360    19) Update UTF-7 reference.
   4361 
   4362    20) Fix example in 6.3.11.
   4363 
   4364    21) Clarify that non-existent UIDs are ignored.
   4365 
   4366    22) Update DISPOSITION reference.
   4367 
   4368    23) Expand state diagram.
   4369 
   4370    24) Clarify that partial fetch responses are only returned in
   4371    response to a partial fetch command.
   4372 
   4373    25) Add UIDNEXT response code.  Correct UIDVALIDITY definition
   4374    reference.
   4375 
   4376    26) Further clarification of "can" vs. "MAY".
   4377 
   4378    27) Reference _R_F_C_-_2_1_1_9.
   4379 
   4380    28) Clarify that superfluous shifts are not permitted in modified
   4381    UTF-7.
   4382 
   4383    29) Clarify that there are no implicit shifts in modified UTF-7.
   4384 
   4385    30) Clarify that "INBOX" in a mailbox name is always INBOX, even if
   4386    it is given as a string.
   4387 
   4388    31) Add missing open parenthesis in media-basic grammar rule.
   4389 
   4390    32) Correct attribute syntax in mailbox-data.
   4391 
   4392    33) Add UIDNEXT to EXAMINE responses.
   4393 
   4394    34) Clarify UNSEEN, PERMANENTFLAGS, UIDVALIDITY, and UIDNEXT
   4395    responses in SELECT and EXAMINE.  They are required now, but weren't
   4396    in older versions.
   4397 
   4398    35) Update references with RFC numbers.
   4399 
   4400    36) Flush text-mime2.
   4401 
   4402    37) Clarify that modified UTF-7 names must be case-sensitive and that
   4403    violating the convention should be avoided.
   4404 
   4405    38) Correct UID FETCH example.
   4406 
   4407    39) Clarify UID FETCH, UID STORE, and UID SEARCH vs. untagged EXPUNGE
   4408    responses.
   4409 
   4410    40) Clarify the use of the word "convention".
   4411 
   4412    41) Clarify that a command is not "in progress" until it has been
   4413    fully received (specifically, that a command is not "in progress"
   4414    during command continuation negotiation).
   4415 
   4416    42) Clarify envelope defaulting.
   4417 
   4418    43) Clarify that SP means one and only one space character.
   4419 
   4420    44) Forbid silly states in LIST response.
   4421 
   4422    45) Clarify that the ENVELOPE, INTERNALDATE, _R_F_C_8_2_2*, BODY*, and UID
   4423    for a message is static.
   4424 
   4425    46) Add BADCHARSET response code.
   4426 
   4427    47) Update formal syntax to [ABNF] conventions.
   4428 
   4429    48) Clarify trailing hierarchy delimiter in CREATE semantics.
   4430 
   4431    49) Clarify that the "blank line" is the [_R_F_C_-_2_8_2_2] delimiting blank
   4432    line.
   4433 
   4434    50) Clarify that RENAME should also create hierarchy as needed for
   4435    the command to complete.
   4436 
   4437    51) Fix body-ext-mpart to not require language if disposition
   4438    present.
   4439 
   4440    52) Clarify the _R_F_C_8_2_2.HEADER response.
   4441 
   4442    53) Correct missing space after charset astring in search.
   4443 
   4444    54) Correct missing quote for BADCHARSET in resp-text-code.
   4445 
   4446    55) Clarify that ALL, FAST, and FULL preclude any other data items
   4447    appearing.
   4448 
   4449    56) Clarify semantics of reference argument in LIST.
   4450 
   4451    57) Clarify that a null string for SEARCH HEADER X-FOO means any
   4452    message with a header line with a field-name of X-FOO regardless of
   4453    the text of the header.
   4454 
   4455    58) Specifically reserve 8-bit mailbox names for future use as UTF-8.
   4456 
   4457    59) It is not an error for the client to store a flag that is not in
   4458    the PERMANENTFLAGS list; however, the server will either ignore the
   4459    change or make the change in the session only.
   4460 
   4461    60) Correct/clarify the text regarding superfluous shifts.
   4462 
   4463    61) Correct typographic errors in the "Changes" section.
   4464 
   4465    62) Clarify that STATUS must not be used to check for new messages in
   4466    the selected mailbox
   4467 
   4468    63) Clarify LSUB behavior with "%" wildcard.
   4469 
   4470    64) Change AUTHORIZATION to AUTHENTICATE in section 7.5.
   4471 
   4472    65) Clarify description of multipart body type.
   4473 
   4474    66) Clarify that STORE FLAGS does not affect \Recent.
   4475 
   4476    67) Change "west" to "east" in description of timezone.
   4477 
   4478    68) Clarify that commands which break command pipelining must wait
   4479    for a completion result response.
   4480 
   4481    69) Clarify that EXAMINE does not affect \Recent.
   4482 
   4483    70) Make description of MIME structure consistent.
   4484 
   4485    71) Clarify that date searches disregard the time and timezone of the
   4486    INTERNALDATE or Date: header.  In other words, "ON 13-APR-2000" means
   4487    messages with an INTERNALDATE text which starts with "13-APR-2000",
   4488    even if timezone differential from the local timezone is sufficient
   4489    to move that INTERNALDATE into the previous or next day.
   4490 
   4491    72) Clarify that the header fetches don't add a blank line if one
   4492    isn't in the [_R_F_C_-_2_8_2_2] message.
   4493 
   4494    73) Clarify (in discussion of UIDs) that messages are immutable.
   4495 
   4496    74) Add an example of CHARSET searching.
   4497 
   4498    75) Clarify in SEARCH that keywords are a type of flag.
   4499 
   4500    76) Clarify the mandatory nature of the SELECT data responses.
   4501 
   4502    77) Add optional CAPABILITY response code in the initial OK or
   4503    PREAUTH.
   4504 
   4505    78) Add note that server can send an untagged CAPABILITY command as
   4506    part of the responses to AUTHENTICATE and LOGIN.
   4507 
   4508    79) Remove statement about it being unnecessary to issue a CAPABILITY
   4509    command more than once in a connection.  That statement is no longer
   4510    true.
   4511 
   4512    80) Clarify that untagged EXPUNGE decrements the number of messages
   4513    in the mailbox.
   4514 
   4515    81) Fix definition of "body" (concatenation has tighter binding than
   4516    alternation).
   4517 
   4518    82) Add a new "Special Notes to Implementors" section with reference
   4519    to [IMAP-IMPLEMENTATION].
   4520 
   4521    83) Clarify that an untagged CAPABILITY response to an AUTHENTICATE
   4522    command should only be done if a security layer was not negotiated.
   4523 
   4524    84) Change the definition of atom to exclude "]".  Update astring to
   4525    include "]" for compatibility with the past.  Remove resp-text-atom.
   4526 
   4527    85) Remove NEWNAME.  It can't work because mailbox names can be
   4528    literals and can include "]".  Functionality can be addressed via
   4529    referrals.
   4530 
   4531    86) Move modified UTF-7 rationale in order to have more logical
   4532    paragraph flow.
   4533 
   4534    87) Clarify UID uniqueness guarantees with the use of MUST.
   4535 
   4536    88) Note that clients should read response data until the connection
   4537    is closed instead of immediately closing on a BYE.
   4538 
   4539    89) Change _R_F_C_-_8_2_2 references to _R_F_C_-_2_8_2_2.
   4540 
   4541    90) Clarify that _R_F_C_-_2_8_2_2 should be followed instead of _R_F_C_-_8_2_2.
   4542 
   4543    91) Change recommendation of optional automatic capabilities in LOGIN
   4544    and AUTHENTICATE to use the CAPABILITY response code in the tagged
   4545    OK.  This is more interoperable than an unsolicited untagged
   4546    CAPABILITY response.
   4547 
   4548    92) STARTTLS and AUTH=PLAIN are mandatory to implement; add
   4549    recommendations for other [SASL] mechanisms.
   4550 
   4551    93) Clarify that a "connection" (as opposed to "server" or "command")
   4552    is in one of the four states.
   4553 
   4554    94) Clarify that a failed or rejected command does not change state.
   4555 
   4556    95) Split references between normative and informative.
   4557 
   4558    96) Discuss authentication failure issues in security section.
   4559 
   4560    97) Clarify that a data item is not necessarily of only one data
   4561    type.
   4562 
   4563    98) Clarify that sequence ranges are independent of order.
   4564 
   4565    99) Change an example to clarify that superfluous shifts in
   4566    Modified-UTF7 can not be fixed just by omitting the shift.  The
   4567    entire string must be recalculated.
   4568 
   4569    100) Change Envelope Structure definition since [_R_F_C_-_2_8_2_2] uses
   4570    "envelope" to refer to the [SMTP] envelope and not the envelope data
   4571    that appears in the [_R_F_C_-_2_8_2_2] header.
   4572 
   4573    101) Expand on _R_F_C_8_2_2.HEADER response data vs. BODY[HEADER].
   4574 
   4575    102) Clarify Logout state semantics, change ASCII art.
   4576 
   4577    103) Security changes to comply with IESG requirements.
   4578 
   4579    104) Add definition for body URI.
   4580 
   4581    105) Break sequence range definition into three rules, with rewritten
   4582    descriptions for each.
   4583 
   4584    106) Move STARTTLS and LOGINDISABLED here from [IMAP-TLS].
   4585 
   4586    107) Add IANA Considerations section.
   4587 
   4588    108) Clarify valid client assumptions for new message UIDs vs.
   4589    UIDNEXT.
   4590 
   4591    109) Clarify that changes to permanentflags affect concurrent
   4592    sessions as well as subsequent sessions.
   4593 
   4594    110) Clarify that authenticated state can be entered by the CLOSE
   4595    command.
   4596 
   4597    111) Emphasize that SELECT and EXAMINE are the exceptions to the rule
   4598    that a failing command does not change state.
   4599 
   4600    112) Clarify that newly-appended messages have the Recent flag set.
   4601 
   4602    113) Clarify that newly-copied messages SHOULD have the Recent flag
   4603    set.
   4604 
   4605    114) Clarify that UID commands always return the UID in FETCH
   4606    responses.
   4607 
   4608 C.      Key Word Index
   4609 
   4610        +FLAGS <flag list> (store command data item) ...............   59
   4611        +FLAGS.SILENT <flag list> (store command data item) ........   59
   4612        -FLAGS <flag list> (store command data item) ...............   59
   4613        -FLAGS.SILENT <flag list> (store command data item) ........   59
   4614        ALERT (response code) ......................................   64
   4615        ALL (fetch item) ...........................................   55
   4616        ALL (search key) ...........................................   50
   4617        ANSWERED (search key) ......................................   50
   4618        APPEND (command) ...........................................   45
   4619        AUTHENTICATE (command) .....................................   27
   4620        BAD (response) .............................................   66
   4621        BADCHARSET (response code) .................................   64
   4622        BCC <string> (search key) ..................................   51
   4623        BEFORE <date> (search key) .................................   51
   4624        BODY (fetch item) ..........................................   55
   4625        BODY (fetch result) ........................................   73
   4626        BODY <string> (search key) .................................   51
   4627 
   4628        BODY.PEEK[<section>]<<partial>> (fetch item) ...............   57
   4629        BODYSTRUCTURE (fetch item) .................................   57
   4630        BODYSTRUCTURE (fetch result) ...............................   74
   4631        BODY[<section>]<<origin octet>> (fetch result) .............   74
   4632        BODY[<section>]<<partial>> (fetch item) ....................   55
   4633        BYE (response) .............................................   67
   4634        Body Structure (message attribute) .........................   12
   4635        CAPABILITY (command) .......................................   24
   4636        CAPABILITY (response code) .................................   64
   4637        CAPABILITY (response) ......................................   68
   4638        CC <string> (search key) ...................................   51
   4639        CHECK (command) ............................................   47
   4640        CLOSE (command) ............................................   48
   4641        COPY (command) .............................................   59
   4642        CREATE (command) ...........................................   34
   4643        DELETE (command) ...........................................   35
   4644        DELETED (search key) .......................................   51
   4645        DRAFT (search key) .........................................   51
   4646        ENVELOPE (fetch item) ......................................   57
   4647        ENVELOPE (fetch result) ....................................   77
   4648        EXAMINE (command) ..........................................   33
   4649        EXISTS (response) ..........................................   71
   4650        EXPUNGE (command) ..........................................   48
   4651        EXPUNGE (response) .........................................   72
   4652        Envelope Structure (message attribute) .....................   12
   4653        FAST (fetch item) ..........................................   55
   4654        FETCH (command) ............................................   54
   4655        FETCH (response) ...........................................   73
   4656        FLAGGED (search key) .......................................   51
   4657        FLAGS (fetch item) .........................................   57
   4658        FLAGS (fetch result) .......................................   78
   4659        FLAGS (response) ...........................................   71
   4660        FLAGS <flag list> (store command data item) ................   59
   4661        FLAGS.SILENT <flag list> (store command data item) .........   59
   4662        FROM <string> (search key) .................................   51
   4663        FULL (fetch item) ..........................................   55
   4664        Flags (message attribute) ..................................   11
   4665        HEADER (part specifier) ....................................   55
   4666        HEADER <field-name> <string> (search key) ..................   51
   4667        HEADER.FIELDS <header-list> (part specifier) ...............   55
   4668        HEADER.FIELDS.NOT <header-list> (part specifier) ...........   55
   4669        INTERNALDATE (fetch item) ..................................   57
   4670        INTERNALDATE (fetch result) ................................   78
   4671        Internal Date (message attribute) ..........................   12
   4672        KEYWORD <flag> (search key) ................................   51
   4673        Keyword (type of flag) .....................................   11
   4674        LARGER <n> (search key) ....................................   51
   4675        LIST (command) .............................................   40
   4676 
   4677        LIST (response) ............................................   69
   4678        LOGIN (command) ............................................   30
   4679        LOGOUT (command) ...........................................   25
   4680        LSUB (command) .............................................   43
   4681        LSUB (response) ............................................   70
   4682        MAY (specification requirement term) .......................    4
   4683        MESSAGES (status item) .....................................   45
   4684        MIME (part specifier) ......................................   56
   4685        MUST (specification requirement term) ......................    4
   4686        MUST NOT (specification requirement term) ..................    4
   4687        Message Sequence Number (message attribute) ................   10
   4688        NEW (search key) ...........................................   51
   4689        NO (response) ..............................................   66
   4690        NOOP (command) .............................................   25
   4691        NOT <search-key> (search key) ..............................   52
   4692        OK (response) ..............................................   65
   4693        OLD (search key) ...........................................   52
   4694        ON <date> (search key) .....................................   52
   4695        OPTIONAL (specification requirement term) ..................    4
   4696        OR <search-key1> <search-key2> (search key) ................   52
   4697        PARSE (response code) ......................................   64
   4698        PERMANENTFLAGS (response code) .............................   64
   4699        PREAUTH (response) .........................................   67
   4700        Permanent Flag (class of flag) .............................   12
   4701        READ-ONLY (response code) ..................................   65
   4702        READ-WRITE (response code) .................................   65
   4703        RECENT (response) ..........................................   72
   4704        RECENT (search key) ........................................   52
   4705        RECENT (status item) .......................................   45
   4706        RENAME (command) ...........................................   37
   4707        REQUIRED (specification requirement term) ..................    4
   4708        _R_F_C_8_2_2 (fetch item) ........................................   57
   4709        _R_F_C_8_2_2 (fetch result) ......................................   78
   4710        _R_F_C_8_2_2.HEADER (fetch item) .................................   57
   4711        _R_F_C_8_2_2.HEADER (fetch result) ...............................   78
   4712        _R_F_C_8_2_2.SIZE (fetch item) ...................................   57
   4713        _R_F_C_8_2_2.SIZE (fetch result) .................................   78
   4714        _R_F_C_8_2_2.TEXT (fetch item) ...................................   58
   4715        _R_F_C_8_2_2.TEXT (fetch result) .................................   79
   4716        SEARCH (command) ...........................................   49
   4717        SEARCH (response) ..........................................   71
   4718        SEEN (search key) ..........................................   52
   4719        SELECT (command) ...........................................   31
   4720        SENTBEFORE <date> (search key) .............................   52
   4721        SENTON <date> (search key) .................................   52
   4722        SENTSINCE <date> (search key) ..............................   52
   4723        SHOULD (specification requirement term) ....................    4
   4724        SHOULD NOT (specification requirement term) ................    4
   4725 
   4726        SINCE <date> (search key) ..................................   52
   4727        SMALLER <n> (search key) ...................................   52
   4728        STARTTLS (command) .........................................   27
   4729        STATUS (command) ...........................................   44
   4730        STATUS (response) ..........................................   70
   4731        STORE (command) ............................................   58
   4732        SUBJECT <string> (search key) ..............................   53
   4733        SUBSCRIBE (command) ........................................   38
   4734        Session Flag (class of flag) ...............................   12
   4735        System Flag (type of flag) .................................   11
   4736        TEXT (part specifier) ......................................   56
   4737        TEXT <string> (search key) .................................   53
   4738        TO <string> (search key) ...................................   53
   4739        TRYCREATE (response code) ..................................   65
   4740        UID (command) ..............................................   60
   4741        UID (fetch item) ...........................................   58
   4742        UID (fetch result) .........................................   79
   4743        UID <sequence set> (search key) ............................   53
   4744        UIDNEXT (response code) ....................................   65
   4745        UIDNEXT (status item) ......................................   45
   4746        UIDVALIDITY (response code) ................................   65
   4747        UIDVALIDITY (status item) ..................................   45
   4748        UNANSWERED (search key) ....................................   53
   4749        UNDELETED (search key) .....................................   53
   4750        UNDRAFT (search key) .......................................   53
   4751        UNFLAGGED (search key) .....................................   53
   4752        UNKEYWORD <flag> (search key) ..............................   53
   4753        UNSEEN (response code) .....................................   65
   4754        UNSEEN (search key) ........................................   53
   4755        UNSEEN (status item) .......................................   45
   4756        UNSUBSCRIBE (command) ......................................   39
   4757        Unique Identifier (UID) (message attribute) ................    8
   4758        X<atom> (command) ..........................................   62
   4759        [_R_F_C_-_2_8_2_2] Size (message attribute) ........................   12
   4760        \Answered (system flag) ....................................   11
   4761        \Deleted (system flag) .....................................   11
   4762        \Draft (system flag) .......................................   11
   4763        \Flagged (system flag) .....................................   11
   4764        \Marked (mailbox name attribute) ...........................   69
   4765        \Noinferiors (mailbox name attribute) ......................   69
   4766        \Noselect (mailbox name attribute) .........................   69
   4767        \Recent (system flag) ......................................   11
   4768        \Seen (system flag) ........................................   11
   4769        \Unmarked (mailbox name attribute) .........................   69
   4770 
   4771 Author's Address
   4772 
   4773    Mark R. Crispin
   4774    Networks and Distributed Computing
   4775    University of Washington
   4776    4545 15th Avenue NE
   4777    Seattle, WA  98105-4527
   4778 
   4779    Phone: (206) 543-5762
   4780 
   4781    EMail: _M_R_C_@_C_A_C_._W_a_s_h_i_n_g_t_o_n_._E_D_U
   4782 
   4783 Full Copyright Statement
   4784 
   4785    Copyright (C) The Internet Society (2003).  All Rights Reserved.
   4786 
   4787    This document and translations of it may be copied and furnished to
   4788    others, and derivative works that comment on or otherwise explain it
   4789    or assist in its implementation may be prepared, copied, published
   4790    and distributed, in whole or in part, without restriction of any
   4791    kind, provided that the above copyright notice and this paragraph are
   4792    included on all such copies and derivative works.  However, this
   4793    document itself may not be modified in any way, such as by removing
   4794    the copyright notice or references to the Internet Society or other
   4795    Internet organizations, except as needed for the purpose of
   4796    developing Internet standards in which case the procedures for
   4797    copyrights defined in the Internet Standards process must be
   4798    followed, or as required to translate it into languages other than
   4799    English.
   4800 
   4801    The limited permissions granted above are perpetual and will not be
   4802    revoked by the Internet Society or its successors or assigns.  v This
   4803    document and the information contained herein is provided on an "AS
   4804    IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
   4805    FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
   4806    LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
   4807    NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
   4808    OR FITNESS FOR A PARTICULAR PURPOSE.
   4809 
   4810 Acknowledgement
   4811 
   4812    Funding for the RFC Editor function is currently provided by the
   4813    Internet Society.
   4814  
   4815 Comments about this RFC:
   4816     * _R_F_C_ _3_5_0_1_:_ _T_h_o_u_g_h_t_s_ _a_n_d_ _s_u_g_g_e_s_t_i_o_n_s_:_A_b_i_l_i_t_y_ _t_o_ _p_r_o_v_i_d_e_ _m_u_l_t_i_p_l_e
   4817       _c_o_n_n_e_c_t_i_o_n_s_ _t_o_ _t_h_e_ _s_a_m_e_._._. by Chinmay (10/27/2003)
   4818     * _R_F_C_ _3_5_0_1_:_ _T_h_e_ _s_e_r_v_e_r_ _s_h_o_u_l_d_ _b_e_ _a_b_l_e_ _t_o_ _a_s_s_i_g_n_ _"_t_e_m_p_o_r_a_r_y_ _c_r_e_d_e_n_t_i_a_l_s_"_,_ _s_o
   4819       _t_h_a_t_ _a_ _u_s_e_r_._._. by Fredrik Tolf (7/15/2004)
   4820     * _R_F_C_ _3_5_0_1_:_ _U_N_S_E_E_N_ _v_a_l_u_e_ _w_i_t_h_ _S_t_a_t_u_s_ _C_o_m_m_a_n_d_ _a_n_d_ _U_N_S_E_E_N_ _f_l_a_g_s_ _s_h_o_u_l_d_ _w_i_t_h
   4821       _d_i_f_f_e_r_e_n_t_ _n_a_m_e_. by Ravi Prakash Gupta (12/28/2004)
   4822 
   4823 Previous: _R_F_C_ _3_4_9_9_ _-_ _R_e_q_u_e_s_t_ _f_o_r              Next: _R_F_C_ _3_5_0_2_ _-_ _I_n_t_e_r_n_e_t_ _M_e_s_s_a_g_e
   4824 _C_o_m_m_e_n_t_s_ _S_u_m_m_a_r_y_ _R_F_C_ _N_u_m_b_e_r_s_ _3_4_0_0_-_3_4_9_9     _A_c_c_e_s_s_ _P_r_o_t_o_c_o_l_ _(_I_M_A_P_)_ _-_ _M_U_L_T_I_A_P_P_E_N_D
   4825                                                                       _E_x_t_e_n_s_i_o_n
   4826                                                                                
   4827 ===============================================================================
   4828    [ _R_F_C_ _I_n_d_e_x | _R_F_C_ _S_e_a_r_c_h | _U_s_e_n_e_t_ _F_A_Q_s | _W_e_b_ _F_A_Q_s | _D_o_c_u_m_e_n_t_s | _C_i_t_i_e_s ]
   4829 © 2008 FAQS.ORG. All rights reserved.
   4830