1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/docs/rfc/rfc3501.txt	Mon Sep 14 15:17:45 2009 +0900
     1.3 @@ -0,0 +1,6052 @@
     1.4 +
     1.5 +
     1.6 +
     1.7 +
     1.8 +
     1.9 +
    1.10 +Network Working Group                                         M. Crispin
    1.11 +Request for Comments: 3501                      University of Washington
    1.12 +Obsoletes: 2060                                               March 2003
    1.13 +Category: Standards Track
    1.14 +
    1.15 +
    1.16 +            INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1
    1.17 +
    1.18 +Status of this Memo
    1.19 +
    1.20 +   This document specifies an Internet standards track protocol for the
    1.21 +   Internet community, and requests discussion and suggestions for
    1.22 +   improvements.  Please refer to the current edition of the "Internet
    1.23 +   Official Protocol Standards" (STD 1) for the standardization state
    1.24 +   and status of this protocol.  Distribution of this memo is unlimited.
    1.25 +
    1.26 +Copyright Notice
    1.27 +
    1.28 +   Copyright (C) The Internet Society (2003).  All Rights Reserved.
    1.29 +
    1.30 +Abstract
    1.31 +
    1.32 +   The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1)
    1.33 +   allows a client to access and manipulate electronic mail messages on
    1.34 +   a server.  IMAP4rev1 permits manipulation of mailboxes (remote
    1.35 +   message folders) in a way that is functionally equivalent to local
    1.36 +   folders.  IMAP4rev1 also provides the capability for an offline
    1.37 +   client to resynchronize with the server.
    1.38 +
    1.39 +   IMAP4rev1 includes operations for creating, deleting, and renaming
    1.40 +   mailboxes, checking for new messages, permanently removing messages,
    1.41 +   setting and clearing flags, RFC 2822 and RFC 2045 parsing, searching,
    1.42 +   and selective fetching of message attributes, texts, and portions
    1.43 +   thereof.  Messages in IMAP4rev1 are accessed by the use of numbers.
    1.44 +   These numbers are either message sequence numbers or unique
    1.45 +   identifiers.
    1.46 +
    1.47 +   IMAP4rev1 supports a single server.  A mechanism for accessing
    1.48 +   configuration information to support multiple IMAP4rev1 servers is
    1.49 +   discussed in RFC 2244.
    1.50 +
    1.51 +   IMAP4rev1 does not specify a means of posting mail; this function is
    1.52 +   handled by a mail transfer protocol such as RFC 2821.
    1.53 +
    1.54 +
    1.55 +
    1.56 +
    1.57 +
    1.58 +
    1.59 +
    1.60 +
    1.61 +Crispin                     Standards Track                     [Page 1]
    1.62 +
    1.63 +RFC 3501                         IMAPv4                       March 2003
    1.64 +
    1.65 +
    1.66 +Table of Contents
    1.67 +
    1.68 +   IMAP4rev1 Protocol Specification ................................  4
    1.69 +   1.      How to Read This Document ...............................  4
    1.70 +   1.1.    Organization of This Document ...........................  4
    1.71 +   1.2.    Conventions Used in This Document .......................  4
    1.72 +   1.3.    Special Notes to Implementors ...........................  5
    1.73 +   2.      Protocol Overview .......................................  6
    1.74 +   2.1.    Link Level ..............................................  6
    1.75 +   2.2.    Commands and Responses ..................................  6
    1.76 +   2.2.1.  Client Protocol Sender and Server Protocol Receiver .....  6
    1.77 +   2.2.2.  Server Protocol Sender and Client Protocol Receiver .....  7
    1.78 +   2.3.    Message Attributes ......................................  8
    1.79 +   2.3.1.  Message Numbers .........................................  8
    1.80 +   2.3.1.1.        Unique Identifier (UID) Message Attribute .......  8
    1.81 +   2.3.1.2.        Message Sequence Number Message Attribute ....... 10
    1.82 +   2.3.2.  Flags Message Attribute ................................. 11
    1.83 +   2.3.3.  Internal Date Message Attribute ......................... 12
    1.84 +   2.3.4.  [RFC-2822] Size Message Attribute ....................... 12
    1.85 +   2.3.5.  Envelope Structure Message Attribute .................... 12
    1.86 +   2.3.6.  Body Structure Message Attribute ........................ 12
    1.87 +   2.4.    Message Texts ........................................... 13
    1.88 +   3.      State and Flow Diagram .................................. 13
    1.89 +   3.1.    Not Authenticated State ................................. 13
    1.90 +   3.2.    Authenticated State ..................................... 13
    1.91 +   3.3.    Selected State .......................................... 13
    1.92 +   3.4.    Logout State ............................................ 14
    1.93 +   4.      Data Formats ............................................ 16
    1.94 +   4.1.    Atom .................................................... 16
    1.95 +   4.2.    Number .................................................. 16
    1.96 +   4.3.    String .................................................. 16
    1.97 +   4.3.1.  8-bit and Binary Strings ................................ 17
    1.98 +   4.4.    Parenthesized List ...................................... 17
    1.99 +   4.5.    NIL ..................................................... 17
   1.100 +   5.      Operational Considerations .............................. 18
   1.101 +   5.1.    Mailbox Naming .......................................... 18
   1.102 +   5.1.1.  Mailbox Hierarchy Naming ................................ 19
   1.103 +   5.1.2.  Mailbox Namespace Naming Convention ..................... 19
   1.104 +   5.1.3.  Mailbox International Naming Convention ................. 19
   1.105 +   5.2.    Mailbox Size and Message Status Updates ................. 21
   1.106 +   5.3.    Response when no Command in Progress .................... 21
   1.107 +   5.4.    Autologout Timer ........................................ 22
   1.108 +   5.5.    Multiple Commands in Progress ........................... 22
   1.109 +   6.      Client Commands ........................................  23
   1.110 +   6.1.    Client Commands - Any State ............................  24
   1.111 +   6.1.1.  CAPABILITY Command .....................................  24
   1.112 +   6.1.2.  NOOP Command ...........................................  25
   1.113 +   6.1.3.  LOGOUT Command .........................................  26
   1.114 +
   1.115 +
   1.116 +
   1.117 +Crispin                     Standards Track                     [Page 2]
   1.118 +
   1.119 +RFC 3501                         IMAPv4                       March 2003
   1.120 +
   1.121 +
   1.122 +   6.2.    Client Commands - Not Authenticated State ..............  26
   1.123 +   6.2.1.  STARTTLS Command .......................................  27
   1.124 +   6.2.2.  AUTHENTICATE Command ...................................  28
   1.125 +   6.2.3.  LOGIN Command ..........................................  30
   1.126 +   6.3.    Client Commands - Authenticated State ..................  31
   1.127 +   6.3.1.  SELECT Command .........................................  32
   1.128 +   6.3.2.  EXAMINE Command ........................................  34
   1.129 +   6.3.3.  CREATE Command .........................................  34
   1.130 +   6.3.4.  DELETE Command .........................................  35
   1.131 +   6.3.5.  RENAME Command .........................................  37
   1.132 +   6.3.6.  SUBSCRIBE Command ......................................  39
   1.133 +   6.3.7.  UNSUBSCRIBE Command ....................................  39
   1.134 +   6.3.8.  LIST Command ...........................................  40
   1.135 +   6.3.9.  LSUB Command ...........................................  43
   1.136 +   6.3.10. STATUS Command .........................................  44
   1.137 +   6.3.11. APPEND Command .........................................  46
   1.138 +   6.4.    Client Commands - Selected State .......................  47
   1.139 +   6.4.1.  CHECK Command ..........................................  47
   1.140 +   6.4.2.  CLOSE Command ..........................................  48
   1.141 +   6.4.3.  EXPUNGE Command ........................................  49
   1.142 +   6.4.4.  SEARCH Command .........................................  49
   1.143 +   6.4.5.  FETCH Command ..........................................  54
   1.144 +   6.4.6.  STORE Command ..........................................  58
   1.145 +   6.4.7.  COPY Command ...........................................  59
   1.146 +   6.4.8.  UID Command ............................................  60
   1.147 +   6.5.    Client Commands - Experimental/Expansion ...............  62
   1.148 +   6.5.1.  X<atom> Command ........................................  62
   1.149 +   7.      Server Responses .......................................  62
   1.150 +   7.1.    Server Responses - Status Responses ....................  63
   1.151 +   7.1.1.  OK Response ............................................  65
   1.152 +   7.1.2.  NO Response ............................................  66
   1.153 +   7.1.3.  BAD Response ...........................................  66
   1.154 +   7.1.4.  PREAUTH Response .......................................  67
   1.155 +   7.1.5.  BYE Response ...........................................  67
   1.156 +   7.2.    Server Responses - Server and Mailbox Status ...........  68
   1.157 +   7.2.1.  CAPABILITY Response ....................................  68
   1.158 +   7.2.2.  LIST Response ..........................................  69
   1.159 +   7.2.3.  LSUB Response ..........................................  70
   1.160 +   7.2.4   STATUS Response ........................................  70
   1.161 +   7.2.5.  SEARCH Response ........................................  71
   1.162 +   7.2.6.  FLAGS Response .........................................  71
   1.163 +   7.3.    Server Responses - Mailbox Size ........................  71
   1.164 +   7.3.1.  EXISTS Response ........................................  71
   1.165 +   7.3.2.  RECENT Response ........................................  72
   1.166 +   7.4.    Server Responses - Message Status ......................  72
   1.167 +   7.4.1.  EXPUNGE Response .......................................  72
   1.168 +   7.4.2.  FETCH Response .........................................  73
   1.169 +   7.5.    Server Responses - Command Continuation Request ........  79
   1.170 +
   1.171 +
   1.172 +
   1.173 +Crispin                     Standards Track                     [Page 3]
   1.174 +
   1.175 +RFC 3501                         IMAPv4                       March 2003
   1.176 +
   1.177 +
   1.178 +   8.      Sample IMAP4rev1 connection ............................  80
   1.179 +   9.      Formal Syntax ..........................................  81
   1.180 +   10.     Author's Note ..........................................  92
   1.181 +   11.     Security Considerations ................................  92
   1.182 +   11.1.   STARTTLS Security Considerations .......................  92
   1.183 +   11.2.   Other Security Considerations ..........................  93
   1.184 +   12.     IANA Considerations ....................................  94
   1.185 +   Appendices .....................................................  95
   1.186 +   A.      References .............................................  95
   1.187 +   B.      Changes from RFC 2060 ..................................  97
   1.188 +   C.      Key Word Index ......................................... 103
   1.189 +   Author's Address ............................................... 107
   1.190 +   Full Copyright Statement ....................................... 108
   1.191 +
   1.192 +IMAP4rev1 Protocol Specification
   1.193 +
   1.194 +1.      How to Read This Document
   1.195 +
   1.196 +1.1.    Organization of This Document
   1.197 +
   1.198 +   This document is written from the point of view of the implementor of
   1.199 +   an IMAP4rev1 client or server.  Beyond the protocol overview in
   1.200 +   section 2, it is not optimized for someone trying to understand the
   1.201 +   operation of the protocol.  The material in sections 3 through 5
   1.202 +   provides the general context and definitions with which IMAP4rev1
   1.203 +   operates.
   1.204 +
   1.205 +   Sections 6, 7, and 9 describe the IMAP commands, responses, and
   1.206 +   syntax, respectively.  The relationships among these are such that it
   1.207 +   is almost impossible to understand any of them separately.  In
   1.208 +   particular, do not attempt to deduce command syntax from the command
   1.209 +   section alone; instead refer to the Formal Syntax section.
   1.210 +
   1.211 +1.2.    Conventions Used in This Document
   1.212 +
   1.213 +   "Conventions" are basic principles or procedures.  Document
   1.214 +   conventions are noted in this section.
   1.215 +
   1.216 +   In examples, "C:" and "S:" indicate lines sent by the client and
   1.217 +   server respectively.
   1.218 +
   1.219 +   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   1.220 +   "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to
   1.221 +   be interpreted as described in [KEYWORDS].
   1.222 +
   1.223 +   The word "can" (not "may") is used to refer to a possible
   1.224 +   circumstance or situation, as opposed to an optional facility of the
   1.225 +   protocol.
   1.226 +
   1.227 +
   1.228 +
   1.229 +Crispin                     Standards Track                     [Page 4]
   1.230 +
   1.231 +RFC 3501                         IMAPv4                       March 2003
   1.232 +
   1.233 +
   1.234 +   "User" is used to refer to a human user, whereas "client" refers to
   1.235 +   the software being run by the user.
   1.236 +
   1.237 +   "Connection" refers to the entire sequence of client/server
   1.238 +   interaction from the initial establishment of the network connection
   1.239 +   until its termination.
   1.240 +
   1.241 +   "Session" refers to the sequence of client/server interaction from
   1.242 +   the time that a mailbox is selected (SELECT or EXAMINE command) until
   1.243 +   the time that selection ends (SELECT or EXAMINE of another mailbox,
   1.244 +   CLOSE command, or connection termination).
   1.245 +
   1.246 +   Characters are 7-bit US-ASCII unless otherwise specified.  Other
   1.247 +   character sets are indicated using a "CHARSET", as described in
   1.248 +   [MIME-IMT] and defined in [CHARSET].  CHARSETs have important
   1.249 +   additional semantics in addition to defining character set; refer to
   1.250 +   these documents for more detail.
   1.251 +
   1.252 +   There are several protocol conventions in IMAP.  These refer to
   1.253 +   aspects of the specification which are not strictly part of the IMAP
   1.254 +   protocol, but reflect generally-accepted practice.  Implementations
   1.255 +   need to be aware of these conventions, and avoid conflicts whether or
   1.256 +   not they implement the convention.  For example, "&" may not be used
   1.257 +   as a hierarchy delimiter since it conflicts with the Mailbox
   1.258 +   International Naming Convention, and other uses of "&" in mailbox
   1.259 +   names are impacted as well.
   1.260 +
   1.261 +1.3.    Special Notes to Implementors
   1.262 +
   1.263 +   Implementors of the IMAP protocol are strongly encouraged to read the
   1.264 +   IMAP implementation recommendations document [IMAP-IMPLEMENTATION] in
   1.265 +   conjunction with this document, to help understand the intricacies of
   1.266 +   this protocol and how best to build an interoperable product.
   1.267 +
   1.268 +   IMAP4rev1 is designed to be upwards compatible from the [IMAP2] and
   1.269 +   unpublished IMAP2bis protocols.  IMAP4rev1 is largely compatible with
   1.270 +   the IMAP4 protocol described in RFC 1730; the exception being in
   1.271 +   certain facilities added in RFC 1730 that proved problematic and were
   1.272 +   subsequently removed.  In the course of the evolution of IMAP4rev1,
   1.273 +   some aspects in the earlier protocols have become obsolete.  Obsolete
   1.274 +   commands, responses, and data formats which an IMAP4rev1
   1.275 +   implementation can encounter when used with an earlier implementation
   1.276 +   are described in [IMAP-OBSOLETE].
   1.277 +
   1.278 +   Other compatibility issues with IMAP2bis, the most common variant of
   1.279 +   the earlier protocol, are discussed in [IMAP-COMPAT].  A full
   1.280 +   discussion of compatibility issues with rare (and presumed extinct)
   1.281 +
   1.282 +
   1.283 +
   1.284 +
   1.285 +Crispin                     Standards Track                     [Page 5]
   1.286 +
   1.287 +RFC 3501                         IMAPv4                       March 2003
   1.288 +
   1.289 +
   1.290 +   variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is
   1.291 +   primarily of historical interest.
   1.292 +
   1.293 +   IMAP was originally developed for the older [RFC-822] standard, and
   1.294 +   as a consequence several fetch items in IMAP incorporate "RFC822" in
   1.295 +   their name.  With the exception of RFC822.SIZE, there are more modern
   1.296 +   replacements; for example, the modern version of RFC822.HEADER is
   1.297 +   BODY.PEEK[HEADER].  In all cases, "RFC822" should be interpreted as a
   1.298 +   reference to the updated [RFC-2822] standard.
   1.299 +
   1.300 +2.      Protocol Overview
   1.301 +
   1.302 +2.1.    Link Level
   1.303 +
   1.304 +   The IMAP4rev1 protocol assumes a reliable data stream such as that
   1.305 +   provided by TCP.  When TCP is used, an IMAP4rev1 server listens on
   1.306 +   port 143.
   1.307 +
   1.308 +2.2.    Commands and Responses
   1.309 +
   1.310 +   An IMAP4rev1 connection consists of the establishment of a
   1.311 +   client/server network connection, an initial greeting from the
   1.312 +   server, and client/server interactions.  These client/server
   1.313 +   interactions consist of a client command, server data, and a server
   1.314 +   completion result response.
   1.315 +
   1.316 +   All interactions transmitted by client and server are in the form of
   1.317 +   lines, that is, strings that end with a CRLF.  The protocol receiver
   1.318 +   of an IMAP4rev1 client or server is either reading a line, or is
   1.319 +   reading a sequence of octets with a known count followed by a line.
   1.320 +
   1.321 +2.2.1.  Client Protocol Sender and Server Protocol Receiver
   1.322 +
   1.323 +   The client command begins an operation.  Each client command is
   1.324 +   prefixed with an identifier (typically a short alphanumeric string,
   1.325 +   e.g., A0001, A0002, etc.) called a "tag".  A different tag is
   1.326 +   generated by the client for each command.
   1.327 +
   1.328 +   Clients MUST follow the syntax outlined in this specification
   1.329 +   strictly.  It is a syntax error to send a command with missing or
   1.330 +   extraneous spaces or arguments.
   1.331 +
   1.332 +   There are two cases in which a line from the client does not
   1.333 +   represent a complete command.  In one case, a command argument is
   1.334 +   quoted with an octet count (see the description of literal in String
   1.335 +   under Data Formats); in the other case, the command arguments require
   1.336 +   server feedback (see the AUTHENTICATE command).  In either case, the
   1.337 +
   1.338 +
   1.339 +
   1.340 +
   1.341 +Crispin                     Standards Track                     [Page 6]
   1.342 +
   1.343 +RFC 3501                         IMAPv4                       March 2003
   1.344 +
   1.345 +
   1.346 +   server sends a command continuation request response if it is ready
   1.347 +   for the octets (if appropriate) and the remainder of the command.
   1.348 +   This response is prefixed with the token "+".
   1.349 +
   1.350 +        Note: If instead, the server detected an error in the
   1.351 +        command, it sends a BAD completion response with a tag
   1.352 +        matching the command (as described below) to reject the
   1.353 +        command and prevent the client from sending any more of the
   1.354 +        command.
   1.355 +
   1.356 +        It is also possible for the server to send a completion
   1.357 +        response for some other command (if multiple commands are
   1.358 +        in progress), or untagged data.  In either case, the
   1.359 +        command continuation request is still pending; the client
   1.360 +        takes the appropriate action for the response, and reads
   1.361 +        another response from the server.  In all cases, the client
   1.362 +        MUST send a complete command (including receiving all
   1.363 +        command continuation request responses and command
   1.364 +        continuations for the command) before initiating a new
   1.365 +        command.
   1.366 +
   1.367 +   The protocol receiver of an IMAP4rev1 server reads a command line
   1.368 +   from the client, parses the command and its arguments, and transmits
   1.369 +   server data and a server command completion result response.
   1.370 +
   1.371 +2.2.2.  Server Protocol Sender and Client Protocol Receiver
   1.372 +
   1.373 +   Data transmitted by the server to the client and status responses
   1.374 +   that do not indicate command completion are prefixed with the token
   1.375 +   "*", and are called untagged responses.
   1.376 +
   1.377 +   Server data MAY be sent as a result of a client command, or MAY be
   1.378 +   sent unilaterally by the server.  There is no syntactic difference
   1.379 +   between server data that resulted from a specific command and server
   1.380 +   data that were sent unilaterally.
   1.381 +
   1.382 +   The server completion result response indicates the success or
   1.383 +   failure of the operation.  It is tagged with the same tag as the
   1.384 +   client command which began the operation.  Thus, if more than one
   1.385 +   command is in progress, the tag in a server completion response
   1.386 +   identifies the command to which the response applies.  There are
   1.387 +   three possible server completion responses: OK (indicating success),
   1.388 +   NO (indicating failure), or BAD (indicating a protocol error such as
   1.389 +   unrecognized command or command syntax error).
   1.390 +
   1.391 +   Servers SHOULD enforce the syntax outlined in this specification
   1.392 +   strictly.  Any client command with a protocol syntax error, including
   1.393 +   (but not limited to) missing or extraneous spaces or arguments,
   1.394 +
   1.395 +
   1.396 +
   1.397 +Crispin                     Standards Track                     [Page 7]
   1.398 +
   1.399 +RFC 3501                         IMAPv4                       March 2003
   1.400 +
   1.401 +
   1.402 +   SHOULD be rejected, and the client given a BAD server completion
   1.403 +   response.
   1.404 +
   1.405 +   The protocol receiver of an IMAP4rev1 client reads a response line
   1.406 +   from the server.  It then takes action on the response based upon the
   1.407 +   first token of the response, which can be a tag, a "*", or a "+".
   1.408 +
   1.409 +   A client MUST be prepared to accept any server response at all times.
   1.410 +   This includes server data that was not requested.  Server data SHOULD
   1.411 +   be recorded, so that the client can reference its recorded copy
   1.412 +   rather than sending a command to the server to request the data.  In
   1.413 +   the case of certain server data, the data MUST be recorded.
   1.414 +
   1.415 +   This topic is discussed in greater detail in the Server Responses
   1.416 +   section.
   1.417 +
   1.418 +2.3.    Message Attributes
   1.419 +
   1.420 +   In addition to message text, each message has several attributes
   1.421 +   associated with it.  These attributes can be retrieved individually
   1.422 +   or in conjunction with other attributes or message texts.
   1.423 +
   1.424 +2.3.1.  Message Numbers
   1.425 +
   1.426 +   Messages in IMAP4rev1 are accessed by one of two numbers; the unique
   1.427 +   identifier or the message sequence number.
   1.428 +
   1.429 +
   1.430 +2.3.1.1.        Unique Identifier (UID) Message Attribute
   1.431 +
   1.432 +   A 32-bit value assigned to each message, which when used with the
   1.433 +   unique identifier validity value (see below) forms a 64-bit value
   1.434 +   that MUST NOT refer to any other message in the mailbox or any
   1.435 +   subsequent mailbox with the same name forever.  Unique identifiers
   1.436 +   are assigned in a strictly ascending fashion in the mailbox; as each
   1.437 +   message is added to the mailbox it is assigned a higher UID than the
   1.438 +   message(s) which were added previously.  Unlike message sequence
   1.439 +   numbers, unique identifiers are not necessarily contiguous.
   1.440 +
   1.441 +   The unique identifier of a message MUST NOT change during the
   1.442 +   session, and SHOULD NOT change between sessions.  Any change of
   1.443 +   unique identifiers between sessions MUST be detectable using the
   1.444 +   UIDVALIDITY mechanism discussed below.  Persistent unique identifiers
   1.445 +   are required for a client to resynchronize its state from a previous
   1.446 +   session with the server (e.g., disconnected or offline access
   1.447 +   clients); this is discussed further in [IMAP-DISC].
   1.448 +
   1.449 +
   1.450 +
   1.451 +
   1.452 +
   1.453 +Crispin                     Standards Track                     [Page 8]
   1.454 +
   1.455 +RFC 3501                         IMAPv4                       March 2003
   1.456 +
   1.457 +
   1.458 +   Associated with every mailbox are two values which aid in unique
   1.459 +   identifier handling: the next unique identifier value and the unique
   1.460 +   identifier validity value.
   1.461 +
   1.462 +   The next unique identifier value is the predicted value that will be
   1.463 +   assigned to a new message in the mailbox.  Unless the unique
   1.464 +   identifier validity also changes (see below), the next unique
   1.465 +   identifier value MUST have the following two characteristics.  First,
   1.466 +   the next unique identifier value MUST NOT change unless new messages
   1.467 +   are added to the mailbox; and second, the next unique identifier
   1.468 +   value MUST change whenever new messages are added to the mailbox,
   1.469 +   even if those new messages are subsequently expunged.
   1.470 +
   1.471 +        Note: The next unique identifier value is intended to
   1.472 +        provide a means for a client to determine whether any
   1.473 +        messages have been delivered to the mailbox since the
   1.474 +        previous time it checked this value.  It is not intended to
   1.475 +        provide any guarantee that any message will have this
   1.476 +        unique identifier.  A client can only assume, at the time
   1.477 +        that it obtains the next unique identifier value, that
   1.478 +        messages arriving after that time will have a UID greater
   1.479 +        than or equal to that value.
   1.480 +
   1.481 +   The unique identifier validity value is sent in a UIDVALIDITY
   1.482 +   response code in an OK untagged response at mailbox selection time.
   1.483 +   If unique identifiers from an earlier session fail to persist in this
   1.484 +   session, the unique identifier validity value MUST be greater than
   1.485 +   the one used in the earlier session.
   1.486 +
   1.487 +        Note: Ideally, unique identifiers SHOULD persist at all
   1.488 +        times.  Although this specification recognizes that failure
   1.489 +        to persist can be unavoidable in certain server
   1.490 +        environments, it STRONGLY ENCOURAGES message store
   1.491 +        implementation techniques that avoid this problem.  For
   1.492 +        example:
   1.493 +
   1.494 +         1) Unique identifiers MUST be strictly ascending in the
   1.495 +            mailbox at all times.  If the physical message store is
   1.496 +            re-ordered by a non-IMAP agent, this requires that the
   1.497 +            unique identifiers in the mailbox be regenerated, since
   1.498 +            the former unique identifiers are no longer strictly
   1.499 +            ascending as a result of the re-ordering.
   1.500 +
   1.501 +         2) If the message store has no mechanism to store unique
   1.502 +            identifiers, it must regenerate unique identifiers at
   1.503 +            each session, and each session must have a unique
   1.504 +            UIDVALIDITY value.
   1.505 +
   1.506 +
   1.507 +
   1.508 +
   1.509 +Crispin                     Standards Track                     [Page 9]
   1.510 +
   1.511 +RFC 3501                         IMAPv4                       March 2003
   1.512 +
   1.513 +
   1.514 +         3) If the mailbox is deleted and a new mailbox with the
   1.515 +            same name is created at a later date, the server must
   1.516 +            either keep track of unique identifiers from the
   1.517 +            previous instance of the mailbox, or it must assign a
   1.518 +            new UIDVALIDITY value to the new instance of the
   1.519 +            mailbox.  A good UIDVALIDITY value to use in this case
   1.520 +            is a 32-bit representation of the creation date/time of
   1.521 +            the mailbox.  It is alright to use a constant such as
   1.522 +            1, but only if it guaranteed that unique identifiers
   1.523 +            will never be reused, even in the case of a mailbox
   1.524 +            being deleted (or renamed) and a new mailbox by the
   1.525 +            same name created at some future time.
   1.526 +
   1.527 +         4) The combination of mailbox name, UIDVALIDITY, and UID
   1.528 +            must refer to a single immutable message on that server
   1.529 +            forever.  In particular, the internal date, [RFC-2822]
   1.530 +            size, envelope, body structure, and message texts
   1.531 +            (RFC822, RFC822.HEADER, RFC822.TEXT, and all BODY[...]
   1.532 +            fetch data items) must never change.  This does not
   1.533 +            include message numbers, nor does it include attributes
   1.534 +            that can be set by a STORE command (e.g., FLAGS).
   1.535 +
   1.536 +
   1.537 +2.3.1.2.        Message Sequence Number Message Attribute
   1.538 +
   1.539 +   A relative position from 1 to the number of messages in the mailbox.
   1.540 +   This position MUST be ordered by ascending unique identifier.  As
   1.541 +   each new message is added, it is assigned a message sequence number
   1.542 +   that is 1 higher than the number of messages in the mailbox before
   1.543 +   that new message was added.
   1.544 +
   1.545 +   Message sequence numbers can be reassigned during the session.  For
   1.546 +   example, when a message is permanently removed (expunged) from the
   1.547 +   mailbox, the message sequence number for all subsequent messages is
   1.548 +   decremented.  The number of messages in the mailbox is also
   1.549 +   decremented.  Similarly, a new message can be assigned a message
   1.550 +   sequence number that was once held by some other message prior to an
   1.551 +   expunge.
   1.552 +
   1.553 +   In addition to accessing messages by relative position in the
   1.554 +   mailbox, message sequence numbers can be used in mathematical
   1.555 +   calculations.  For example, if an untagged "11 EXISTS" is received,
   1.556 +   and previously an untagged "8 EXISTS" was received, three new
   1.557 +   messages have arrived with message sequence numbers of 9, 10, and 11.
   1.558 +   Another example, if message 287 in a 523 message mailbox has UID
   1.559 +   12345, there are exactly 286 messages which have lesser UIDs and 236
   1.560 +   messages which have greater UIDs.
   1.561 +
   1.562 +
   1.563 +
   1.564 +
   1.565 +Crispin                     Standards Track                    [Page 10]
   1.566 +
   1.567 +RFC 3501                         IMAPv4                       March 2003
   1.568 +
   1.569 +
   1.570 +2.3.2.  Flags Message Attribute
   1.571 +
   1.572 +   A list of zero or more named tokens associated with the message.  A
   1.573 +   flag is set by its addition to this list, and is cleared by its
   1.574 +   removal.  There are two types of flags in IMAP4rev1.  A flag of
   1.575 +   either type can be permanent or session-only.
   1.576 +
   1.577 +   A system flag is a flag name that is pre-defined in this
   1.578 +   specification.  All system flags begin with "\".  Certain system
   1.579 +   flags (\Deleted and \Seen) have special semantics described
   1.580 +   elsewhere.  The currently-defined system flags are:
   1.581 +
   1.582 +        \Seen
   1.583 +           Message has been read
   1.584 +
   1.585 +        \Answered
   1.586 +           Message has been answered
   1.587 +
   1.588 +        \Flagged
   1.589 +           Message is "flagged" for urgent/special attention
   1.590 +
   1.591 +        \Deleted
   1.592 +           Message is "deleted" for removal by later EXPUNGE
   1.593 +
   1.594 +        \Draft
   1.595 +           Message has not completed composition (marked as a draft).
   1.596 +
   1.597 +        \Recent
   1.598 +           Message is "recently" arrived in this mailbox.  This session
   1.599 +           is the first session to have been notified about this
   1.600 +           message; if the session is read-write, subsequent sessions
   1.601 +           will not see \Recent set for this message.  This flag can not
   1.602 +           be altered by the client.
   1.603 +
   1.604 +           If it is not possible to determine whether or not this
   1.605 +           session is the first session to be notified about a message,
   1.606 +           then that message SHOULD be considered recent.
   1.607 +
   1.608 +           If multiple connections have the same mailbox selected
   1.609 +           simultaneously, it is undefined which of these connections
   1.610 +           will see newly-arrived messages with \Recent set and which
   1.611 +           will see it without \Recent set.
   1.612 +
   1.613 +   A keyword is defined by the server implementation.  Keywords do not
   1.614 +   begin with "\".  Servers MAY permit the client to define new keywords
   1.615 +   in the mailbox (see the description of the PERMANENTFLAGS response
   1.616 +   code for more information).
   1.617 +
   1.618 +
   1.619 +
   1.620 +
   1.621 +Crispin                     Standards Track                    [Page 11]
   1.622 +
   1.623 +RFC 3501                         IMAPv4                       March 2003
   1.624 +
   1.625 +
   1.626 +   A flag can be permanent or session-only on a per-flag basis.
   1.627 +   Permanent flags are those which the client can add or remove from the
   1.628 +   message flags permanently; that is, concurrent and subsequent
   1.629 +   sessions will see any change in permanent flags.  Changes to session
   1.630 +   flags are valid only in that session.
   1.631 +
   1.632 +        Note: The \Recent system flag is a special case of a
   1.633 +        session flag.  \Recent can not be used as an argument in a
   1.634 +        STORE or APPEND command, and thus can not be changed at
   1.635 +        all.
   1.636 +
   1.637 +2.3.3.  Internal Date Message Attribute
   1.638 +
   1.639 +   The internal date and time of the message on the server.  This
   1.640 +   is not the date and time in the [RFC-2822] header, but rather a
   1.641 +   date and time which reflects when the message was received.  In
   1.642 +   the case of messages delivered via [SMTP], this SHOULD be the
   1.643 +   date and time of final delivery of the message as defined by
   1.644 +   [SMTP].  In the case of messages delivered by the IMAP4rev1 COPY
   1.645 +   command, this SHOULD be the internal date and time of the source
   1.646 +   message.  In the case of messages delivered by the IMAP4rev1
   1.647 +   APPEND command, this SHOULD be the date and time as specified in
   1.648 +   the APPEND command description.  All other cases are
   1.649 +   implementation defined.
   1.650 +
   1.651 +2.3.4.  [RFC-2822] Size Message Attribute
   1.652 +
   1.653 +   The number of octets in the message, as expressed in [RFC-2822]
   1.654 +   format.
   1.655 +
   1.656 +2.3.5.  Envelope Structure Message Attribute
   1.657 +
   1.658 +   A parsed representation of the [RFC-2822] header of the message.
   1.659 +   Note that the IMAP Envelope structure is not the same as an
   1.660 +   [SMTP] envelope.
   1.661 +
   1.662 +2.3.6.  Body Structure Message Attribute
   1.663 +
   1.664 +   A parsed representation of the [MIME-IMB] body structure
   1.665 +   information of the message.
   1.666 +
   1.667 +
   1.668 +
   1.669 +
   1.670 +
   1.671 +
   1.672 +
   1.673 +
   1.674 +
   1.675 +
   1.676 +
   1.677 +Crispin                     Standards Track                    [Page 12]
   1.678 +
   1.679 +RFC 3501                         IMAPv4                       March 2003
   1.680 +
   1.681 +
   1.682 +2.4.    Message Texts
   1.683 +
   1.684 +   In addition to being able to fetch the full [RFC-2822] text of a
   1.685 +   message, IMAP4rev1 permits the fetching of portions of the full
   1.686 +   message text.  Specifically, it is possible to fetch the
   1.687 +   [RFC-2822] message header, [RFC-2822] message body, a [MIME-IMB]
   1.688 +   body part, or a [MIME-IMB] header.
   1.689 +
   1.690 +3.      State and Flow Diagram
   1.691 +
   1.692 +   Once the connection between client and server is established, an
   1.693 +   IMAP4rev1 connection is in one of four states.  The initial
   1.694 +   state is identified in the server greeting.  Most commands are
   1.695 +   only valid in certain states.  It is a protocol error for the
   1.696 +   client to attempt a command while the connection is in an
   1.697 +   inappropriate state, and the server will respond with a BAD or
   1.698 +   NO (depending upon server implementation) command completion
   1.699 +   result.
   1.700 +
   1.701 +3.1.    Not Authenticated State
   1.702 +
   1.703 +   In the not authenticated state, the client MUST supply
   1.704 +   authentication credentials before most commands will be
   1.705 +   permitted.  This state is entered when a connection starts
   1.706 +   unless the connection has been pre-authenticated.
   1.707 +
   1.708 +3.2.    Authenticated State
   1.709 +
   1.710 +   In the authenticated state, the client is authenticated and MUST
   1.711 +   select a mailbox to access before commands that affect messages
   1.712 +   will be permitted.  This state is entered when a
   1.713 +   pre-authenticated connection starts, when acceptable
   1.714 +   authentication credentials have been provided, after an error in
   1.715 +   selecting a mailbox, or after a successful CLOSE command.
   1.716 +
   1.717 +3.3.    Selected State
   1.718 +
   1.719 +   In a selected state, a mailbox has been selected to access.
   1.720 +   This state is entered when a mailbox has been successfully
   1.721 +   selected.
   1.722 +
   1.723 +
   1.724 +
   1.725 +
   1.726 +
   1.727 +
   1.728 +
   1.729 +
   1.730 +
   1.731 +
   1.732 +
   1.733 +Crispin                     Standards Track                    [Page 13]
   1.734 +
   1.735 +RFC 3501                         IMAPv4                       March 2003
   1.736 +
   1.737 +
   1.738 +3.4.    Logout State
   1.739 +
   1.740 +   In the logout state, the connection is being terminated.  This
   1.741 +   state can be entered as a result of a client request (via the
   1.742 +   LOGOUT command) or by unilateral action on the part of either
   1.743 +   the client or server.
   1.744 +
   1.745 +   If the client requests the logout state, the server MUST send an
   1.746 +   untagged BYE response and a tagged OK response to the LOGOUT
   1.747 +   command before the server closes the connection; and the client
   1.748 +   MUST read the tagged OK response to the LOGOUT command before
   1.749 +   the client closes the connection.
   1.750 +
   1.751 +   A server MUST NOT unilaterally close the connection without
   1.752 +   sending an untagged BYE response that contains the reason for
   1.753 +   having done so.  A client SHOULD NOT unilaterally close the
   1.754 +   connection, and instead SHOULD issue a LOGOUT command.  If the
   1.755 +   server detects that the client has unilaterally closed the
   1.756 +   connection, the server MAY omit the untagged BYE response and
   1.757 +   simply close its connection.
   1.758 +
   1.759 +
   1.760 +
   1.761 +
   1.762 +
   1.763 +
   1.764 +
   1.765 +
   1.766 +
   1.767 +
   1.768 +
   1.769 +
   1.770 +
   1.771 +
   1.772 +
   1.773 +
   1.774 +
   1.775 +
   1.776 +
   1.777 +
   1.778 +
   1.779 +
   1.780 +
   1.781 +
   1.782 +
   1.783 +
   1.784 +
   1.785 +
   1.786 +
   1.787 +
   1.788 +
   1.789 +Crispin                     Standards Track                    [Page 14]
   1.790 +
   1.791 +RFC 3501                         IMAPv4                       March 2003
   1.792 +
   1.793 +
   1.794 +                   +----------------------+
   1.795 +                   |connection established|
   1.796 +                   +----------------------+
   1.797 +                              ||
   1.798 +                              \/
   1.799 +            +--------------------------------------+
   1.800 +            |          server greeting             |
   1.801 +            +--------------------------------------+
   1.802 +                      || (1)       || (2)        || (3)
   1.803 +                      \/           ||            ||
   1.804 +            +-----------------+    ||            ||
   1.805 +            |Not Authenticated|    ||            ||
   1.806 +            +-----------------+    ||            ||
   1.807 +             || (7)   || (4)       ||            ||
   1.808 +             ||       \/           \/            ||
   1.809 +             ||     +----------------+           ||
   1.810 +             ||     | Authenticated  |<=++       ||
   1.811 +             ||     +----------------+  ||       ||
   1.812 +             ||       || (7)   || (5)   || (6)   ||
   1.813 +             ||       ||       \/       ||       ||
   1.814 +             ||       ||    +--------+  ||       ||
   1.815 +             ||       ||    |Selected|==++       ||
   1.816 +             ||       ||    +--------+           ||
   1.817 +             ||       ||       || (7)            ||
   1.818 +             \/       \/       \/                \/
   1.819 +            +--------------------------------------+
   1.820 +            |               Logout                 |
   1.821 +            +--------------------------------------+
   1.822 +                              ||
   1.823 +                              \/
   1.824 +                +-------------------------------+
   1.825 +                |both sides close the connection|
   1.826 +                +-------------------------------+
   1.827 +
   1.828 +         (1) connection without pre-authentication (OK greeting)
   1.829 +         (2) pre-authenticated connection (PREAUTH greeting)
   1.830 +         (3) rejected connection (BYE greeting)
   1.831 +         (4) successful LOGIN or AUTHENTICATE command
   1.832 +         (5) successful SELECT or EXAMINE command
   1.833 +         (6) CLOSE command, or failed SELECT or EXAMINE command
   1.834 +         (7) LOGOUT command, server shutdown, or connection closed
   1.835 +
   1.836 +
   1.837 +
   1.838 +
   1.839 +
   1.840 +
   1.841 +
   1.842 +
   1.843 +
   1.844 +
   1.845 +Crispin                     Standards Track                    [Page 15]
   1.846 +
   1.847 +RFC 3501                         IMAPv4                       March 2003
   1.848 +
   1.849 +
   1.850 +4.      Data Formats
   1.851 +
   1.852 +   IMAP4rev1 uses textual commands and responses.  Data in
   1.853 +   IMAP4rev1 can be in one of several forms: atom, number, string,
   1.854 +   parenthesized list, or NIL.  Note that a particular data item
   1.855 +   may take more than one form; for example, a data item defined as
   1.856 +   using "astring" syntax may be either an atom or a string.
   1.857 +
   1.858 +4.1.    Atom
   1.859 +
   1.860 +   An atom consists of one or more non-special characters.
   1.861 +
   1.862 +4.2.    Number
   1.863 +
   1.864 +   A number consists of one or more digit characters, and
   1.865 +   represents a numeric value.
   1.866 +
   1.867 +4.3.    String
   1.868 +
   1.869 +   A string is in one of two forms: either literal or quoted
   1.870 +   string.  The literal form is the general form of string.  The
   1.871 +   quoted string form is an alternative that avoids the overhead of
   1.872 +   processing a literal at the cost of limitations of characters
   1.873 +   which may be used.
   1.874 +
   1.875 +   A literal is a sequence of zero or more octets (including CR and
   1.876 +   LF), prefix-quoted with an octet count in the form of an open
   1.877 +   brace ("{"), the number of octets, close brace ("}"), and CRLF.
   1.878 +   In the case of literals transmitted from server to client, the
   1.879 +   CRLF is immediately followed by the octet data.  In the case of
   1.880 +   literals transmitted from client to server, the client MUST wait
   1.881 +   to receive a command continuation request (described later in
   1.882 +   this document) before sending the octet data (and the remainder
   1.883 +   of the command).
   1.884 +
   1.885 +   A quoted string is a sequence of zero or more 7-bit characters,
   1.886 +   excluding CR and LF, with double quote (<">) characters at each
   1.887 +   end.
   1.888 +
   1.889 +   The empty string is represented as either "" (a quoted string
   1.890 +   with zero characters between double quotes) or as {0} followed
   1.891 +   by CRLF (a literal with an octet count of 0).
   1.892 +
   1.893 +     Note: Even if the octet count is 0, a client transmitting a
   1.894 +     literal MUST wait to receive a command continuation request.
   1.895 +
   1.896 +
   1.897 +
   1.898 +
   1.899 +
   1.900 +
   1.901 +Crispin                     Standards Track                    [Page 16]
   1.902 +
   1.903 +RFC 3501                         IMAPv4                       March 2003
   1.904 +
   1.905 +
   1.906 +4.3.1.  8-bit and Binary Strings
   1.907 +
   1.908 +   8-bit textual and binary mail is supported through the use of a
   1.909 +   [MIME-IMB] content transfer encoding.  IMAP4rev1 implementations MAY
   1.910 +   transmit 8-bit or multi-octet characters in literals, but SHOULD do
   1.911 +   so only when the [CHARSET] is identified.
   1.912 +
   1.913 +   Although a BINARY body encoding is defined, unencoded binary strings
   1.914 +   are not permitted.  A "binary string" is any string with NUL
   1.915 +   characters.  Implementations MUST encode binary data into a textual
   1.916 +   form, such as BASE64, before transmitting the data.  A string with an
   1.917 +   excessive amount of CTL characters MAY also be considered to be
   1.918 +   binary.
   1.919 +
   1.920 +4.4.    Parenthesized List
   1.921 +
   1.922 +   Data structures are represented as a "parenthesized list"; a sequence
   1.923 +   of data items, delimited by space, and bounded at each end by
   1.924 +   parentheses.  A parenthesized list can contain other parenthesized
   1.925 +   lists, using multiple levels of parentheses to indicate nesting.
   1.926 +
   1.927 +   The empty list is represented as () -- a parenthesized list with no
   1.928 +   members.
   1.929 +
   1.930 +4.5.    NIL
   1.931 +
   1.932 +   The special form "NIL" represents the non-existence of a particular
   1.933 +   data item that is represented as a string or parenthesized list, as
   1.934 +   distinct from the empty string "" or the empty parenthesized list ().
   1.935 +
   1.936 +        Note: NIL is never used for any data item which takes the
   1.937 +        form of an atom.  For example, a mailbox name of "NIL" is a
   1.938 +        mailbox named NIL as opposed to a non-existent mailbox
   1.939 +        name.  This is because mailbox uses "astring" syntax which
   1.940 +        is an atom or a string.  Conversely, an addr-name of NIL is
   1.941 +        a non-existent personal name, because addr-name uses
   1.942 +        "nstring" syntax which is NIL or a string, but never an
   1.943 +        atom.
   1.944 +
   1.945 +
   1.946 +
   1.947 +
   1.948 +
   1.949 +
   1.950 +
   1.951 +
   1.952 +
   1.953 +
   1.954 +
   1.955 +
   1.956 +
   1.957 +Crispin                     Standards Track                    [Page 17]
   1.958 +
   1.959 +RFC 3501                         IMAPv4                       March 2003
   1.960 +
   1.961 +
   1.962 +5.      Operational Considerations
   1.963 +
   1.964 +   The following rules are listed here to ensure that all IMAP4rev1
   1.965 +   implementations interoperate properly.
   1.966 +
   1.967 +5.1.    Mailbox Naming
   1.968 +
   1.969 +   Mailbox names are 7-bit.  Client implementations MUST NOT attempt to
   1.970 +   create 8-bit mailbox names, and SHOULD interpret any 8-bit mailbox
   1.971 +   names returned by LIST or LSUB as UTF-8.  Server implementations
   1.972 +   SHOULD prohibit the creation of 8-bit mailbox names, and SHOULD NOT
   1.973 +   return 8-bit mailbox names in LIST or LSUB.  See section 5.1.3 for
   1.974 +   more information on how to represent non-ASCII mailbox names.
   1.975 +
   1.976 +        Note: 8-bit mailbox names were undefined in earlier
   1.977 +        versions of this protocol.  Some sites used a local 8-bit
   1.978 +        character set to represent non-ASCII mailbox names.  Such
   1.979 +        usage is not interoperable, and is now formally deprecated.
   1.980 +
   1.981 +   The case-insensitive mailbox name INBOX is a special name reserved to
   1.982 +   mean "the primary mailbox for this user on this server".  The
   1.983 +   interpretation of all other names is implementation-dependent.
   1.984 +
   1.985 +   In particular, this specification takes no position on case
   1.986 +   sensitivity in non-INBOX mailbox names.  Some server implementations
   1.987 +   are fully case-sensitive; others preserve case of a newly-created
   1.988 +   name but otherwise are case-insensitive; and yet others coerce names
   1.989 +   to a particular case.  Client implementations MUST interact with any
   1.990 +   of these.  If a server implementation interprets non-INBOX mailbox
   1.991 +   names as case-insensitive, it MUST treat names using the
   1.992 +   international naming convention specially as described in section
   1.993 +   5.1.3.
   1.994 +
   1.995 +   There are certain client considerations when creating a new mailbox
   1.996 +   name:
   1.997 +
   1.998 +   1)    Any character which is one of the atom-specials (see the Formal
   1.999 +         Syntax) will require that the mailbox name be represented as a
  1.1000 +         quoted string or literal.
  1.1001 +
  1.1002 +   2)    CTL and other non-graphic characters are difficult to represent
  1.1003 +         in a user interface and are best avoided.
  1.1004 +
  1.1005 +   3)    Although the list-wildcard characters ("%" and "*") are valid
  1.1006 +         in a mailbox name, it is difficult to use such mailbox names
  1.1007 +         with the LIST and LSUB commands due to the conflict with
  1.1008 +         wildcard interpretation.
  1.1009 +
  1.1010 +
  1.1011 +
  1.1012 +
  1.1013 +Crispin                     Standards Track                    [Page 18]
  1.1014 +
  1.1015 +RFC 3501                         IMAPv4                       March 2003
  1.1016 +
  1.1017 +
  1.1018 +   4)    Usually, a character (determined by the server implementation)
  1.1019 +         is reserved to delimit levels of hierarchy.
  1.1020 +
  1.1021 +   5)    Two characters, "#" and "&", have meanings by convention, and
  1.1022 +         should be avoided except when used in that convention.
  1.1023 +
  1.1024 +5.1.1.  Mailbox Hierarchy Naming
  1.1025 +
  1.1026 +   If it is desired to export hierarchical mailbox names, mailbox names
  1.1027 +   MUST be left-to-right hierarchical using a single character to
  1.1028 +   separate levels of hierarchy.  The same hierarchy separator character
  1.1029 +   is used for all levels of hierarchy within a single name.
  1.1030 +
  1.1031 +5.1.2.  Mailbox Namespace Naming Convention
  1.1032 +
  1.1033 +   By convention, the first hierarchical element of any mailbox name
  1.1034 +   which begins with "#" identifies the "namespace" of the remainder of
  1.1035 +   the name.  This makes it possible to disambiguate between different
  1.1036 +   types of mailbox stores, each of which have their own namespaces.
  1.1037 +
  1.1038 +        For example, implementations which offer access to USENET
  1.1039 +        newsgroups MAY use the "#news" namespace to partition the
  1.1040 +        USENET newsgroup namespace from that of other mailboxes.
  1.1041 +        Thus, the comp.mail.misc newsgroup would have a mailbox
  1.1042 +        name of "#news.comp.mail.misc", and the name
  1.1043 +        "comp.mail.misc" can refer to a different object (e.g., a
  1.1044 +        user's private mailbox).
  1.1045 +
  1.1046 +5.1.3.  Mailbox International Naming Convention
  1.1047 +
  1.1048 +   By convention, international mailbox names in IMAP4rev1 are specified
  1.1049 +   using a modified version of the UTF-7 encoding described in [UTF-7].
  1.1050 +   Modified UTF-7 may also be usable in servers that implement an
  1.1051 +   earlier version of this protocol.
  1.1052 +
  1.1053 +   In modified UTF-7, printable US-ASCII characters, except for "&",
  1.1054 +   represent themselves; that is, characters with octet values 0x20-0x25
  1.1055 +   and 0x27-0x7e.  The character "&" (0x26) is represented by the
  1.1056 +   two-octet sequence "&-".
  1.1057 +
  1.1058 +   All other characters (octet values 0x00-0x1f and 0x7f-0xff) are
  1.1059 +   represented in modified BASE64, with a further modification from
  1.1060 +   [UTF-7] that "," is used instead of "/".  Modified BASE64 MUST NOT be
  1.1061 +   used to represent any printing US-ASCII character which can represent
  1.1062 +   itself.
  1.1063 +
  1.1064 +
  1.1065 +
  1.1066 +
  1.1067 +
  1.1068 +
  1.1069 +Crispin                     Standards Track                    [Page 19]
  1.1070 +
  1.1071 +RFC 3501                         IMAPv4                       March 2003
  1.1072 +
  1.1073 +
  1.1074 +   "&" is used to shift to modified BASE64 and "-" to shift back to
  1.1075 +   US-ASCII.  There is no implicit shift from BASE64 to US-ASCII, and
  1.1076 +   null shifts ("-&" while in BASE64; note that "&-" while in US-ASCII
  1.1077 +   means "&") are not permitted.  However, all names start in US-ASCII,
  1.1078 +   and MUST end in US-ASCII; that is, a name that ends with a non-ASCII
  1.1079 +   ISO-10646 character MUST end with a "-").
  1.1080 +
  1.1081 +   The purpose of these modifications is to correct the following
  1.1082 +   problems with UTF-7:
  1.1083 +
  1.1084 +      1) UTF-7 uses the "+" character for shifting; this conflicts with
  1.1085 +         the common use of "+" in mailbox names, in particular USENET
  1.1086 +         newsgroup names.
  1.1087 +
  1.1088 +      2) UTF-7's encoding is BASE64 which uses the "/" character; this
  1.1089 +         conflicts with the use of "/" as a popular hierarchy delimiter.
  1.1090 +
  1.1091 +      3) UTF-7 prohibits the unencoded usage of "\"; this conflicts with
  1.1092 +         the use of "\" as a popular hierarchy delimiter.
  1.1093 +
  1.1094 +      4) UTF-7 prohibits the unencoded usage of "~"; this conflicts with
  1.1095 +         the use of "~" in some servers as a home directory indicator.
  1.1096 +
  1.1097 +      5) UTF-7 permits multiple alternate forms to represent the same
  1.1098 +         string; in particular, printable US-ASCII characters can be
  1.1099 +         represented in encoded form.
  1.1100 +
  1.1101 +      Although modified UTF-7 is a convention, it establishes certain
  1.1102 +      requirements on server handling of any mailbox name with an
  1.1103 +      embedded "&" character.  In particular, server implementations
  1.1104 +      MUST preserve the exact form of the modified BASE64 portion of a
  1.1105 +      modified UTF-7 name and treat that text as case-sensitive, even if
  1.1106 +      names are otherwise case-insensitive or case-folded.
  1.1107 +
  1.1108 +      Server implementations SHOULD verify that any mailbox name with an
  1.1109 +      embedded "&" character, used as an argument to CREATE, is: in the
  1.1110 +      correctly modified UTF-7 syntax, has no superfluous shifts, and
  1.1111 +      has no encoding in modified BASE64 of any printing US-ASCII
  1.1112 +      character which can represent itself.  However, client
  1.1113 +      implementations MUST NOT depend upon the server doing this, and
  1.1114 +      SHOULD NOT attempt to create a mailbox name with an embedded "&"
  1.1115 +      character unless it complies with the modified UTF-7 syntax.
  1.1116 +
  1.1117 +      Server implementations which export a mail store that does not
  1.1118 +      follow the modified UTF-7 convention MUST convert to modified
  1.1119 +      UTF-7 any mailbox name that contains either non-ASCII characters
  1.1120 +      or the "&" character.
  1.1121 +
  1.1122 +
  1.1123 +
  1.1124 +
  1.1125 +Crispin                     Standards Track                    [Page 20]
  1.1126 +
  1.1127 +RFC 3501                         IMAPv4                       March 2003
  1.1128 +
  1.1129 +
  1.1130 +           For example, here is a mailbox name which mixes English,
  1.1131 +           Chinese, and Japanese text:
  1.1132 +           ~peter/mail/&U,BTFw-/&ZeVnLIqe-
  1.1133 +
  1.1134 +           For example, the string "&Jjo!" is not a valid mailbox
  1.1135 +           name because it does not contain a shift to US-ASCII
  1.1136 +           before the "!".  The correct form is "&Jjo-!".  The
  1.1137 +           string "&U,BTFw-&ZeVnLIqe-" is not permitted because it
  1.1138 +           contains a superfluous shift.  The correct form is
  1.1139 +           "&U,BTF2XlZyyKng-".
  1.1140 +
  1.1141 +5.2.    Mailbox Size and Message Status Updates
  1.1142 +
  1.1143 +   At any time, a server can send data that the client did not request.
  1.1144 +   Sometimes, such behavior is REQUIRED.  For example, agents other than
  1.1145 +   the server MAY add messages to the mailbox (e.g., new message
  1.1146 +   delivery), change the flags of the messages in the mailbox (e.g.,
  1.1147 +   simultaneous access to the same mailbox by multiple agents), or even
  1.1148 +   remove messages from the mailbox.  A server MUST send mailbox size
  1.1149 +   updates automatically if a mailbox size change is observed during the
  1.1150 +   processing of a command.  A server SHOULD send message flag updates
  1.1151 +   automatically, without requiring the client to request such updates
  1.1152 +   explicitly.
  1.1153 +
  1.1154 +   Special rules exist for server notification of a client about the
  1.1155 +   removal of messages to prevent synchronization errors; see the
  1.1156 +   description of the EXPUNGE response for more detail.  In particular,
  1.1157 +   it is NOT permitted to send an EXISTS response that would reduce the
  1.1158 +   number of messages in the mailbox; only the EXPUNGE response can do
  1.1159 +   this.
  1.1160 +
  1.1161 +   Regardless of what implementation decisions a client makes on
  1.1162 +   remembering data from the server, a client implementation MUST record
  1.1163 +   mailbox size updates.  It MUST NOT assume that any command after the
  1.1164 +   initial mailbox selection will return the size of the mailbox.
  1.1165 +
  1.1166 +5.3.    Response when no Command in Progress
  1.1167 +
  1.1168 +   Server implementations are permitted to send an untagged response
  1.1169 +   (except for EXPUNGE) while there is no command in progress.  Server
  1.1170 +   implementations that send such responses MUST deal with flow control
  1.1171 +   considerations.  Specifically, they MUST either (1) verify that the
  1.1172 +   size of the data does not exceed the underlying transport's available
  1.1173 +   window size, or (2) use non-blocking writes.
  1.1174 +
  1.1175 +
  1.1176 +
  1.1177 +
  1.1178 +
  1.1179 +
  1.1180 +
  1.1181 +Crispin                     Standards Track                    [Page 21]
  1.1182 +
  1.1183 +RFC 3501                         IMAPv4                       March 2003
  1.1184 +
  1.1185 +
  1.1186 +5.4.    Autologout Timer
  1.1187 +
  1.1188 +   If a server has an inactivity autologout timer, the duration of that
  1.1189 +   timer MUST be at least 30 minutes.  The receipt of ANY command from
  1.1190 +   the client during that interval SHOULD suffice to reset the
  1.1191 +   autologout timer.
  1.1192 +
  1.1193 +5.5.    Multiple Commands in Progress
  1.1194 +
  1.1195 +   The client MAY send another command without waiting for the
  1.1196 +   completion result response of a command, subject to ambiguity rules
  1.1197 +   (see below) and flow control constraints on the underlying data
  1.1198 +   stream.  Similarly, a server MAY begin processing another command
  1.1199 +   before processing the current command to completion, subject to
  1.1200 +   ambiguity rules.  However, any command continuation request responses
  1.1201 +   and command continuations MUST be negotiated before any subsequent
  1.1202 +   command is initiated.
  1.1203 +
  1.1204 +   The exception is if an ambiguity would result because of a command
  1.1205 +   that would affect the results of other commands.  Clients MUST NOT
  1.1206 +   send multiple commands without waiting if an ambiguity would result.
  1.1207 +   If the server detects a possible ambiguity, it MUST execute commands
  1.1208 +   to completion in the order given by the client.
  1.1209 +
  1.1210 +   The most obvious example of ambiguity is when a command would affect
  1.1211 +   the results of another command, e.g., a FETCH of a message's flags
  1.1212 +   and a STORE of that same message's flags.
  1.1213 +
  1.1214 +   A non-obvious ambiguity occurs with commands that permit an untagged
  1.1215 +   EXPUNGE response (commands other than FETCH, STORE, and SEARCH),
  1.1216 +   since an untagged EXPUNGE response can invalidate sequence numbers in
  1.1217 +   a subsequent command.  This is not a problem for FETCH, STORE, or
  1.1218 +   SEARCH commands because servers are prohibited from sending EXPUNGE
  1.1219 +   responses while any of those commands are in progress.  Therefore, if
  1.1220 +   the client sends any command other than FETCH, STORE, or SEARCH, it
  1.1221 +   MUST wait for the completion result response before sending a command
  1.1222 +   with message sequence numbers.
  1.1223 +
  1.1224 +        Note: UID FETCH, UID STORE, and UID SEARCH are different
  1.1225 +        commands from FETCH, STORE, and SEARCH.  If the client
  1.1226 +        sends a UID command, it must wait for a completion result
  1.1227 +        response before sending a command with message sequence
  1.1228 +        numbers.
  1.1229 +
  1.1230 +
  1.1231 +
  1.1232 +
  1.1233 +
  1.1234 +
  1.1235 +
  1.1236 +
  1.1237 +Crispin                     Standards Track                    [Page 22]
  1.1238 +
  1.1239 +RFC 3501                         IMAPv4                       March 2003
  1.1240 +
  1.1241 +
  1.1242 +   For example, the following non-waiting command sequences are invalid:
  1.1243 +
  1.1244 +      FETCH + NOOP + STORE
  1.1245 +      STORE + COPY + FETCH
  1.1246 +      COPY + COPY
  1.1247 +      CHECK + FETCH
  1.1248 +
  1.1249 +   The following are examples of valid non-waiting command sequences:
  1.1250 +
  1.1251 +      FETCH + STORE + SEARCH + CHECK
  1.1252 +      STORE + COPY + EXPUNGE
  1.1253 +
  1.1254 +      UID SEARCH + UID SEARCH may be valid or invalid as a non-waiting
  1.1255 +      command sequence, depending upon whether or not the second UID
  1.1256 +      SEARCH contains message sequence numbers.
  1.1257 +
  1.1258 +6.      Client Commands
  1.1259 +
  1.1260 +   IMAP4rev1 commands are described in this section.  Commands are
  1.1261 +   organized by the state in which the command is permitted.  Commands
  1.1262 +   which are permitted in multiple states are listed in the minimum
  1.1263 +   permitted state (for example, commands valid in authenticated and
  1.1264 +   selected state are listed in the authenticated state commands).
  1.1265 +
  1.1266 +   Command arguments, identified by "Arguments:" in the command
  1.1267 +   descriptions below, are described by function, not by syntax.  The
  1.1268 +   precise syntax of command arguments is described in the Formal Syntax
  1.1269 +   section.
  1.1270 +
  1.1271 +   Some commands cause specific server responses to be returned; these
  1.1272 +   are identified by "Responses:" in the command descriptions below.
  1.1273 +   See the response descriptions in the Responses section for
  1.1274 +   information on these responses, and the Formal Syntax section for the
  1.1275 +   precise syntax of these responses.  It is possible for server data to
  1.1276 +   be transmitted as a result of any command.  Thus, commands that do
  1.1277 +   not specifically require server data specify "no specific responses
  1.1278 +   for this command" instead of "none".
  1.1279 +
  1.1280 +   The "Result:" in the command description refers to the possible
  1.1281 +   tagged status responses to a command, and any special interpretation
  1.1282 +   of these status responses.
  1.1283 +
  1.1284 +   The state of a connection is only changed by successful commands
  1.1285 +   which are documented as changing state.  A rejected command (BAD
  1.1286 +   response) never changes the state of the connection or of the
  1.1287 +   selected mailbox.  A failed command (NO response) generally does not
  1.1288 +   change the state of the connection or of the selected mailbox; the
  1.1289 +   exception being the SELECT and EXAMINE commands.
  1.1290 +
  1.1291 +
  1.1292 +
  1.1293 +Crispin                     Standards Track                    [Page 23]
  1.1294 +
  1.1295 +RFC 3501                         IMAPv4                       March 2003
  1.1296 +
  1.1297 +
  1.1298 +6.1.    Client Commands - Any State
  1.1299 +
  1.1300 +   The following commands are valid in any state: CAPABILITY, NOOP, and
  1.1301 +   LOGOUT.
  1.1302 +
  1.1303 +6.1.1.  CAPABILITY Command
  1.1304 +
  1.1305 +   Arguments:  none
  1.1306 +
  1.1307 +   Responses:  REQUIRED untagged response: CAPABILITY
  1.1308 +
  1.1309 +   Result:     OK - capability completed
  1.1310 +               BAD - command unknown or arguments invalid
  1.1311 +
  1.1312 +      The CAPABILITY command requests a listing of capabilities that the
  1.1313 +      server supports.  The server MUST send a single untagged
  1.1314 +      CAPABILITY response with "IMAP4rev1" as one of the listed
  1.1315 +      capabilities before the (tagged) OK response.
  1.1316 +
  1.1317 +      A capability name which begins with "AUTH=" indicates that the
  1.1318 +      server supports that particular authentication mechanism.  All
  1.1319 +      such names are, by definition, part of this specification.  For
  1.1320 +      example, the authorization capability for an experimental
  1.1321 +      "blurdybloop" authenticator would be "AUTH=XBLURDYBLOOP" and not
  1.1322 +      "XAUTH=BLURDYBLOOP" or "XAUTH=XBLURDYBLOOP".
  1.1323 +
  1.1324 +      Other capability names refer to extensions, revisions, or
  1.1325 +      amendments to this specification.  See the documentation of the
  1.1326 +      CAPABILITY response for additional information.  No capabilities,
  1.1327 +      beyond the base IMAP4rev1 set defined in this specification, are
  1.1328 +      enabled without explicit client action to invoke the capability.
  1.1329 +
  1.1330 +      Client and server implementations MUST implement the STARTTLS,
  1.1331 +      LOGINDISABLED, and AUTH=PLAIN (described in [IMAP-TLS])
  1.1332 +      capabilities.  See the Security Considerations section for
  1.1333 +      important information.
  1.1334 +
  1.1335 +      See the section entitled "Client Commands -
  1.1336 +      Experimental/Expansion" for information about the form of site or
  1.1337 +      implementation-specific capabilities.
  1.1338 +
  1.1339 +
  1.1340 +
  1.1341 +
  1.1342 +
  1.1343 +
  1.1344 +
  1.1345 +
  1.1346 +
  1.1347 +
  1.1348 +
  1.1349 +Crispin                     Standards Track                    [Page 24]
  1.1350 +
  1.1351 +RFC 3501                         IMAPv4                       March 2003
  1.1352 +
  1.1353 +
  1.1354 +   Example:    C: abcd CAPABILITY
  1.1355 +               S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI
  1.1356 +               LOGINDISABLED
  1.1357 +               S: abcd OK CAPABILITY completed
  1.1358 +               C: efgh STARTTLS
  1.1359 +               S: efgh OK STARTLS completed
  1.1360 +               <TLS negotiation, further commands are under [TLS] layer>
  1.1361 +               C: ijkl CAPABILITY
  1.1362 +               S: * CAPABILITY IMAP4rev1 AUTH=GSSAPI AUTH=PLAIN
  1.1363 +               S: ijkl OK CAPABILITY completed
  1.1364 +
  1.1365 +
  1.1366 +6.1.2.  NOOP Command
  1.1367 +
  1.1368 +   Arguments:  none
  1.1369 +
  1.1370 +   Responses:  no specific responses for this command (but see below)
  1.1371 +
  1.1372 +   Result:     OK - noop completed
  1.1373 +               BAD - command unknown or arguments invalid
  1.1374 +
  1.1375 +      The NOOP command always succeeds.  It does nothing.
  1.1376 +
  1.1377 +      Since any command can return a status update as untagged data, the
  1.1378 +      NOOP command can be used as a periodic poll for new messages or
  1.1379 +      message status updates during a period of inactivity (this is the
  1.1380 +      preferred method to do this).  The NOOP command can also be used
  1.1381 +      to reset any inactivity autologout timer on the server.
  1.1382 +
  1.1383 +   Example:    C: a002 NOOP
  1.1384 +               S: a002 OK NOOP completed
  1.1385 +                  . . .
  1.1386 +               C: a047 NOOP
  1.1387 +               S: * 22 EXPUNGE
  1.1388 +               S: * 23 EXISTS
  1.1389 +               S: * 3 RECENT
  1.1390 +               S: * 14 FETCH (FLAGS (\Seen \Deleted))
  1.1391 +               S: a047 OK NOOP completed
  1.1392 +
  1.1393 +
  1.1394 +
  1.1395 +
  1.1396 +
  1.1397 +
  1.1398 +
  1.1399 +
  1.1400 +
  1.1401 +
  1.1402 +
  1.1403 +
  1.1404 +
  1.1405 +Crispin                     Standards Track                    [Page 25]
  1.1406 +
  1.1407 +RFC 3501                         IMAPv4                       March 2003
  1.1408 +
  1.1409 +
  1.1410 +6.1.3.  LOGOUT Command
  1.1411 +
  1.1412 +   Arguments:  none
  1.1413 +
  1.1414 +   Responses:  REQUIRED untagged response: BYE
  1.1415 +
  1.1416 +   Result:     OK - logout completed
  1.1417 +               BAD - command unknown or arguments invalid
  1.1418 +
  1.1419 +      The LOGOUT command informs the server that the client is done with
  1.1420 +      the connection.  The server MUST send a BYE untagged response
  1.1421 +      before the (tagged) OK response, and then close the network
  1.1422 +      connection.
  1.1423 +
  1.1424 +   Example:    C: A023 LOGOUT
  1.1425 +               S: * BYE IMAP4rev1 Server logging out
  1.1426 +               S: A023 OK LOGOUT completed
  1.1427 +               (Server and client then close the connection)
  1.1428 +
  1.1429 +6.2.    Client Commands - Not Authenticated State
  1.1430 +
  1.1431 +   In the not authenticated state, the AUTHENTICATE or LOGIN command
  1.1432 +   establishes authentication and enters the authenticated state.  The
  1.1433 +   AUTHENTICATE command provides a general mechanism for a variety of
  1.1434 +   authentication techniques, privacy protection, and integrity
  1.1435 +   checking; whereas the LOGIN command uses a traditional user name and
  1.1436 +   plaintext password pair and has no means of establishing privacy
  1.1437 +   protection or integrity checking.
  1.1438 +
  1.1439 +   The STARTTLS command is an alternate form of establishing session
  1.1440 +   privacy protection and integrity checking, but does not establish
  1.1441 +   authentication or enter the authenticated state.
  1.1442 +
  1.1443 +   Server implementations MAY allow access to certain mailboxes without
  1.1444 +   establishing authentication.  This can be done by means of the
  1.1445 +   ANONYMOUS [SASL] authenticator described in [ANONYMOUS].  An older
  1.1446 +   convention is a LOGIN command using the userid "anonymous"; in this
  1.1447 +   case, a password is required although the server may choose to accept
  1.1448 +   any password.  The restrictions placed on anonymous users are
  1.1449 +   implementation-dependent.
  1.1450 +
  1.1451 +   Once authenticated (including as anonymous), it is not possible to
  1.1452 +   re-enter not authenticated state.
  1.1453 +
  1.1454 +
  1.1455 +
  1.1456 +
  1.1457 +
  1.1458 +
  1.1459 +
  1.1460 +
  1.1461 +Crispin                     Standards Track                    [Page 26]
  1.1462 +
  1.1463 +RFC 3501                         IMAPv4                       March 2003
  1.1464 +
  1.1465 +
  1.1466 +   In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
  1.1467 +   the following commands are valid in the not authenticated state:
  1.1468 +   STARTTLS, AUTHENTICATE and LOGIN.  See the Security Considerations
  1.1469 +   section for important information about these commands.
  1.1470 +
  1.1471 +6.2.1.  STARTTLS Command
  1.1472 +
  1.1473 +   Arguments:  none
  1.1474 +
  1.1475 +   Responses:  no specific response for this command
  1.1476 +
  1.1477 +   Result:     OK - starttls completed, begin TLS negotiation
  1.1478 +               BAD - command unknown or arguments invalid
  1.1479 +
  1.1480 +      A [TLS] negotiation begins immediately after the CRLF at the end
  1.1481 +      of the tagged OK response from the server.  Once a client issues a
  1.1482 +      STARTTLS command, it MUST NOT issue further commands until a
  1.1483 +      server response is seen and the [TLS] negotiation is complete.
  1.1484 +
  1.1485 +      The server remains in the non-authenticated state, even if client
  1.1486 +      credentials are supplied during the [TLS] negotiation.  This does
  1.1487 +      not preclude an authentication mechanism such as EXTERNAL (defined
  1.1488 +      in [SASL]) from using client identity determined by the [TLS]
  1.1489 +      negotiation.
  1.1490 +
  1.1491 +      Once [TLS] has been started, the client MUST discard cached
  1.1492 +      information about server capabilities and SHOULD re-issue the
  1.1493 +      CAPABILITY command.  This is necessary to protect against man-in-
  1.1494 +      the-middle attacks which alter the capabilities list prior to
  1.1495 +      STARTTLS.  The server MAY advertise different capabilities after
  1.1496 +      STARTTLS.
  1.1497 +
  1.1498 +   Example:    C: a001 CAPABILITY
  1.1499 +               S: * CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED
  1.1500 +               S: a001 OK CAPABILITY completed
  1.1501 +               C: a002 STARTTLS
  1.1502 +               S: a002 OK Begin TLS negotiation now
  1.1503 +               <TLS negotiation, further commands are under [TLS] layer>
  1.1504 +               C: a003 CAPABILITY
  1.1505 +               S: * CAPABILITY IMAP4rev1 AUTH=PLAIN
  1.1506 +               S: a003 OK CAPABILITY completed
  1.1507 +               C: a004 LOGIN joe password
  1.1508 +               S: a004 OK LOGIN completed
  1.1509 +
  1.1510 +
  1.1511 +
  1.1512 +
  1.1513 +
  1.1514 +
  1.1515 +
  1.1516 +
  1.1517 +Crispin                     Standards Track                    [Page 27]
  1.1518 +
  1.1519 +RFC 3501                         IMAPv4                       March 2003
  1.1520 +
  1.1521 +
  1.1522 +6.2.2.  AUTHENTICATE Command
  1.1523 +
  1.1524 +   Arguments:  authentication mechanism name
  1.1525 +
  1.1526 +   Responses:  continuation data can be requested
  1.1527 +
  1.1528 +   Result:     OK - authenticate completed, now in authenticated state
  1.1529 +               NO - authenticate failure: unsupported authentication
  1.1530 +                    mechanism, credentials rejected
  1.1531 +               BAD - command unknown or arguments invalid,
  1.1532 +                    authentication exchange cancelled
  1.1533 +
  1.1534 +      The AUTHENTICATE command indicates a [SASL] authentication
  1.1535 +      mechanism to the server.  If the server supports the requested
  1.1536 +      authentication mechanism, it performs an authentication protocol
  1.1537 +      exchange to authenticate and identify the client.  It MAY also
  1.1538 +      negotiate an OPTIONAL security layer for subsequent protocol
  1.1539 +      interactions.  If the requested authentication mechanism is not
  1.1540 +      supported, the server SHOULD reject the AUTHENTICATE command by
  1.1541 +      sending a tagged NO response.
  1.1542 +
  1.1543 +      The AUTHENTICATE command does not support the optional "initial
  1.1544 +      response" feature of [SASL].  Section 5.1 of [SASL] specifies how
  1.1545 +      to handle an authentication mechanism which uses an initial
  1.1546 +      response.
  1.1547 +
  1.1548 +      The service name specified by this protocol's profile of [SASL] is
  1.1549 +      "imap".
  1.1550 +
  1.1551 +      The authentication protocol exchange consists of a series of
  1.1552 +      server challenges and client responses that are specific to the
  1.1553 +      authentication mechanism.  A server challenge consists of a
  1.1554 +      command continuation request response with the "+" token followed
  1.1555 +      by a BASE64 encoded string.  The client response consists of a
  1.1556 +      single line consisting of a BASE64 encoded string.  If the client
  1.1557 +      wishes to cancel an authentication exchange, it issues a line
  1.1558 +      consisting of a single "*".  If the server receives such a
  1.1559 +      response, it MUST reject the AUTHENTICATE command by sending a
  1.1560 +      tagged BAD response.
  1.1561 +
  1.1562 +      If a security layer is negotiated through the [SASL]
  1.1563 +      authentication exchange, it takes effect immediately following the
  1.1564 +      CRLF that concludes the authentication exchange for the client,
  1.1565 +      and the CRLF of the tagged OK response for the server.
  1.1566 +
  1.1567 +      While client and server implementations MUST implement the
  1.1568 +      AUTHENTICATE command itself, it is not required to implement any
  1.1569 +      authentication mechanisms other than the PLAIN mechanism described
  1.1570 +
  1.1571 +
  1.1572 +
  1.1573 +Crispin                     Standards Track                    [Page 28]
  1.1574 +
  1.1575 +RFC 3501                         IMAPv4                       March 2003
  1.1576 +
  1.1577 +
  1.1578 +      in [IMAP-TLS].  Also, an authentication mechanism is not required
  1.1579 +      to support any security layers.
  1.1580 +
  1.1581 +           Note: a server implementation MUST implement a
  1.1582 +           configuration in which it does NOT permit any plaintext
  1.1583 +           password mechanisms, unless either the STARTTLS command
  1.1584 +           has been negotiated or some other mechanism that
  1.1585 +           protects the session from password snooping has been
  1.1586 +           provided.  Server sites SHOULD NOT use any configuration
  1.1587 +           which permits a plaintext password mechanism without
  1.1588 +           such a protection mechanism against password snooping.
  1.1589 +           Client and server implementations SHOULD implement
  1.1590 +           additional [SASL] mechanisms that do not use plaintext
  1.1591 +           passwords, such the GSSAPI mechanism described in [SASL]
  1.1592 +           and/or the [DIGEST-MD5] mechanism.
  1.1593 +
  1.1594 +      Servers and clients can support multiple authentication
  1.1595 +      mechanisms.  The server SHOULD list its supported authentication
  1.1596 +      mechanisms in the response to the CAPABILITY command so that the
  1.1597 +      client knows which authentication mechanisms to use.
  1.1598 +
  1.1599 +      A server MAY include a CAPABILITY response code in the tagged OK
  1.1600 +      response of a successful AUTHENTICATE command in order to send
  1.1601 +      capabilities automatically.  It is unnecessary for a client to
  1.1602 +      send a separate CAPABILITY command if it recognizes these
  1.1603 +      automatic capabilities.  This should only be done if a security
  1.1604 +      layer was not negotiated by the AUTHENTICATE command, because the
  1.1605 +      tagged OK response as part of an AUTHENTICATE command is not
  1.1606 +      protected by encryption/integrity checking.  [SASL] requires the
  1.1607 +      client to re-issue a CAPABILITY command in this case.
  1.1608 +
  1.1609 +      If an AUTHENTICATE command fails with a NO response, the client
  1.1610 +      MAY try another authentication mechanism by issuing another
  1.1611 +      AUTHENTICATE command.  It MAY also attempt to authenticate by
  1.1612 +      using the LOGIN command (see section 6.2.3 for more detail).  In
  1.1613 +      other words, the client MAY request authentication types in
  1.1614 +      decreasing order of preference, with the LOGIN command as a last
  1.1615 +      resort.
  1.1616 +
  1.1617 +      The authorization identity passed from the client to the server
  1.1618 +      during the authentication exchange is interpreted by the server as
  1.1619 +      the user name whose privileges the client is requesting.
  1.1620 +
  1.1621 +
  1.1622 +
  1.1623 +
  1.1624 +
  1.1625 +
  1.1626 +
  1.1627 +
  1.1628 +
  1.1629 +Crispin                     Standards Track                    [Page 29]
  1.1630 +
  1.1631 +RFC 3501                         IMAPv4                       March 2003
  1.1632 +
  1.1633 +
  1.1634 +   Example:    S: * OK IMAP4rev1 Server
  1.1635 +               C: A001 AUTHENTICATE GSSAPI
  1.1636 +               S: +
  1.1637 +               C: YIIB+wYJKoZIhvcSAQICAQBuggHqMIIB5qADAgEFoQMCAQ6iBw
  1.1638 +                  MFACAAAACjggEmYYIBIjCCAR6gAwIBBaESGxB1Lndhc2hpbmd0
  1.1639 +                  b24uZWR1oi0wK6ADAgEDoSQwIhsEaW1hcBsac2hpdmFtcy5jYW
  1.1640 +                  Mud2FzaGluZ3Rvbi5lZHWjgdMwgdCgAwIBAaEDAgEDooHDBIHA
  1.1641 +                  cS1GSa5b+fXnPZNmXB9SjL8Ollj2SKyb+3S0iXMljen/jNkpJX
  1.1642 +                  AleKTz6BQPzj8duz8EtoOuNfKgweViyn/9B9bccy1uuAE2HI0y
  1.1643 +                  C/PHXNNU9ZrBziJ8Lm0tTNc98kUpjXnHZhsMcz5Mx2GR6dGknb
  1.1644 +                  I0iaGcRerMUsWOuBmKKKRmVMMdR9T3EZdpqsBd7jZCNMWotjhi
  1.1645 +                  vd5zovQlFqQ2Wjc2+y46vKP/iXxWIuQJuDiisyXF0Y8+5GTpAL
  1.1646 +                  pHDc1/pIGmMIGjoAMCAQGigZsEgZg2on5mSuxoDHEA1w9bcW9n
  1.1647 +                  FdFxDKpdrQhVGVRDIzcCMCTzvUboqb5KjY1NJKJsfjRQiBYBdE
  1.1648 +                  NKfzK+g5DlV8nrw81uOcP8NOQCLR5XkoMHC0Dr/80ziQzbNqhx
  1.1649 +                  O6652Npft0LQwJvenwDI13YxpwOdMXzkWZN/XrEqOWp6GCgXTB
  1.1650 +                  vCyLWLlWnbaUkZdEYbKHBPjd8t/1x5Yg==
  1.1651 +               S: + YGgGCSqGSIb3EgECAgIAb1kwV6ADAgEFoQMCAQ+iSzBJoAMC
  1.1652 +                  AQGiQgRAtHTEuOP2BXb9sBYFR4SJlDZxmg39IxmRBOhXRKdDA0
  1.1653 +                  uHTCOT9Bq3OsUTXUlk0CsFLoa8j+gvGDlgHuqzWHPSQg==
  1.1654 +               C:
  1.1655 +               S: + YDMGCSqGSIb3EgECAgIBAAD/////6jcyG4GE3KkTzBeBiVHe
  1.1656 +                  ceP2CWY0SR0fAQAgAAQEBAQ=
  1.1657 +               C: YDMGCSqGSIb3EgECAgIBAAD/////3LQBHXTpFfZgrejpLlLImP
  1.1658 +                  wkhbfa2QteAQAgAG1yYwE=
  1.1659 +               S: A001 OK GSSAPI authentication successful
  1.1660 +
  1.1661 +        Note: The line breaks within server challenges and client
  1.1662 +        responses are for editorial clarity and are not in real
  1.1663 +        authenticators.
  1.1664 +
  1.1665 +
  1.1666 +6.2.3.  LOGIN Command
  1.1667 +
  1.1668 +   Arguments:  user name
  1.1669 +               password
  1.1670 +
  1.1671 +   Responses:  no specific responses for this command
  1.1672 +
  1.1673 +   Result:     OK - login completed, now in authenticated state
  1.1674 +               NO - login failure: user name or password rejected
  1.1675 +               BAD - command unknown or arguments invalid
  1.1676 +
  1.1677 +      The LOGIN command identifies the client to the server and carries
  1.1678 +      the plaintext password authenticating this user.
  1.1679 +
  1.1680 +
  1.1681 +
  1.1682 +
  1.1683 +
  1.1684 +
  1.1685 +Crispin                     Standards Track                    [Page 30]
  1.1686 +
  1.1687 +RFC 3501                         IMAPv4                       March 2003
  1.1688 +
  1.1689 +
  1.1690 +      A server MAY include a CAPABILITY response code in the tagged OK
  1.1691 +      response to a successful LOGIN command in order to send
  1.1692 +      capabilities automatically.  It is unnecessary for a client to
  1.1693 +      send a separate CAPABILITY command if it recognizes these
  1.1694 +      automatic capabilities.
  1.1695 +
  1.1696 +   Example:    C: a001 LOGIN SMITH SESAME
  1.1697 +               S: a001 OK LOGIN completed
  1.1698 +
  1.1699 +        Note: Use of the LOGIN command over an insecure network
  1.1700 +        (such as the Internet) is a security risk, because anyone
  1.1701 +        monitoring network traffic can obtain plaintext passwords.
  1.1702 +        The LOGIN command SHOULD NOT be used except as a last
  1.1703 +        resort, and it is recommended that client implementations
  1.1704 +        have a means to disable any automatic use of the LOGIN
  1.1705 +        command.
  1.1706 +
  1.1707 +        Unless either the STARTTLS command has been negotiated or
  1.1708 +        some other mechanism that protects the session from
  1.1709 +        password snooping has been provided, a server
  1.1710 +        implementation MUST implement a configuration in which it
  1.1711 +        advertises the LOGINDISABLED capability and does NOT permit
  1.1712 +        the LOGIN command.  Server sites SHOULD NOT use any
  1.1713 +        configuration which permits the LOGIN command without such
  1.1714 +        a protection mechanism against password snooping.  A client
  1.1715 +        implementation MUST NOT send a LOGIN command if the
  1.1716 +        LOGINDISABLED capability is advertised.
  1.1717 +
  1.1718 +6.3.    Client Commands - Authenticated State
  1.1719 +
  1.1720 +   In the authenticated state, commands that manipulate mailboxes as
  1.1721 +   atomic entities are permitted.  Of these commands, the SELECT and
  1.1722 +   EXAMINE commands will select a mailbox for access and enter the
  1.1723 +   selected state.
  1.1724 +
  1.1725 +   In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
  1.1726 +   the following commands are valid in the authenticated state: SELECT,
  1.1727 +   EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB,
  1.1728 +   STATUS, and APPEND.
  1.1729 +
  1.1730 +
  1.1731 +
  1.1732 +
  1.1733 +
  1.1734 +
  1.1735 +
  1.1736 +
  1.1737 +
  1.1738 +
  1.1739 +
  1.1740 +
  1.1741 +Crispin                     Standards Track                    [Page 31]
  1.1742 +
  1.1743 +RFC 3501                         IMAPv4                       March 2003
  1.1744 +
  1.1745 +
  1.1746 +6.3.1.  SELECT Command
  1.1747 +
  1.1748 +   Arguments:  mailbox name
  1.1749 +
  1.1750 +   Responses:  REQUIRED untagged responses: FLAGS, EXISTS, RECENT
  1.1751 +               REQUIRED OK untagged responses:  UNSEEN,  PERMANENTFLAGS,
  1.1752 +               UIDNEXT, UIDVALIDITY
  1.1753 +
  1.1754 +   Result:     OK - select completed, now in selected state
  1.1755 +               NO - select failure, now in authenticated state: no
  1.1756 +                    such mailbox, can't access mailbox
  1.1757 +               BAD - command unknown or arguments invalid
  1.1758 +
  1.1759 +      The SELECT command selects a mailbox so that messages in the
  1.1760 +      mailbox can be accessed.  Before returning an OK to the client,
  1.1761 +      the server MUST send the following untagged data to the client.
  1.1762 +      Note that earlier versions of this protocol only required the
  1.1763 +      FLAGS, EXISTS, and RECENT untagged data; consequently, client
  1.1764 +      implementations SHOULD implement default behavior for missing data
  1.1765 +      as discussed with the individual item.
  1.1766 +
  1.1767 +         FLAGS       Defined flags in the mailbox.  See the description
  1.1768 +                     of the FLAGS response for more detail.
  1.1769 +
  1.1770 +         <n> EXISTS  The number of messages in the mailbox.  See the
  1.1771 +                     description of the EXISTS response for more detail.
  1.1772 +
  1.1773 +         <n> RECENT  The number of messages with the \Recent flag set.
  1.1774 +                     See the description of the RECENT response for more
  1.1775 +                     detail.
  1.1776 +
  1.1777 +         OK [UNSEEN <n>]
  1.1778 +                     The message sequence number of the first unseen
  1.1779 +                     message in the mailbox.  If this is missing, the
  1.1780 +                     client can not make any assumptions about the first
  1.1781 +                     unseen message in the mailbox, and needs to issue a
  1.1782 +                     SEARCH command if it wants to find it.
  1.1783 +
  1.1784 +         OK [PERMANENTFLAGS (<list of flags>)]
  1.1785 +                     A list of message flags that the client can change
  1.1786 +                     permanently.  If this is missing, the client should
  1.1787 +                     assume that all flags can be changed permanently.
  1.1788 +
  1.1789 +         OK [UIDNEXT <n>]
  1.1790 +                     The next unique identifier value.  Refer to section
  1.1791 +                     2.3.1.1 for more information.  If this is missing,
  1.1792 +                     the client can not make any assumptions about the
  1.1793 +                     next unique identifier value.
  1.1794 +
  1.1795 +
  1.1796 +
  1.1797 +Crispin                     Standards Track                    [Page 32]
  1.1798 +
  1.1799 +RFC 3501                         IMAPv4                       March 2003
  1.1800 +
  1.1801 +
  1.1802 +         OK [UIDVALIDITY <n>]
  1.1803 +                     The unique identifier validity value.  Refer to
  1.1804 +                     section 2.3.1.1 for more information.  If this is
  1.1805 +                     missing, the server does not support unique
  1.1806 +                     identifiers.
  1.1807 +
  1.1808 +      Only one mailbox can be selected at a time in a connection;
  1.1809 +      simultaneous access to multiple mailboxes requires multiple
  1.1810 +      connections.  The SELECT command automatically deselects any
  1.1811 +      currently selected mailbox before attempting the new selection.
  1.1812 +      Consequently, if a mailbox is selected and a SELECT command that
  1.1813 +      fails is attempted, no mailbox is selected.
  1.1814 +
  1.1815 +      If the client is permitted to modify the mailbox, the server
  1.1816 +      SHOULD prefix the text of the tagged OK response with the
  1.1817 +      "[READ-WRITE]" response code.
  1.1818 +
  1.1819 +      If the client is not permitted to modify the mailbox but is
  1.1820 +      permitted read access, the mailbox is selected as read-only, and
  1.1821 +      the server MUST prefix the text of the tagged OK response to
  1.1822 +      SELECT with the "[READ-ONLY]" response code.  Read-only access
  1.1823 +      through SELECT differs from the EXAMINE command in that certain
  1.1824 +      read-only mailboxes MAY permit the change of permanent state on a
  1.1825 +      per-user (as opposed to global) basis.  Netnews messages marked in
  1.1826 +      a server-based .newsrc file are an example of such per-user
  1.1827 +      permanent state that can be modified with read-only mailboxes.
  1.1828 +
  1.1829 +   Example:    C: A142 SELECT INBOX
  1.1830 +               S: * 172 EXISTS
  1.1831 +               S: * 1 RECENT
  1.1832 +               S: * OK [UNSEEN 12] Message 12 is first unseen
  1.1833 +               S: * OK [UIDVALIDITY 3857529045] UIDs valid
  1.1834 +               S: * OK [UIDNEXT 4392] Predicted next UID
  1.1835 +               S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
  1.1836 +               S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
  1.1837 +               S: A142 OK [READ-WRITE] SELECT completed
  1.1838 +
  1.1839 +
  1.1840 +
  1.1841 +
  1.1842 +
  1.1843 +
  1.1844 +
  1.1845 +
  1.1846 +
  1.1847 +
  1.1848 +
  1.1849 +
  1.1850 +
  1.1851 +
  1.1852 +
  1.1853 +Crispin                     Standards Track                    [Page 33]
  1.1854 +
  1.1855 +RFC 3501                         IMAPv4                       March 2003
  1.1856 +
  1.1857 +
  1.1858 +6.3.2.  EXAMINE Command
  1.1859 +
  1.1860 +   Arguments:  mailbox name
  1.1861 +
  1.1862 +   Responses:  REQUIRED untagged responses: FLAGS, EXISTS, RECENT
  1.1863 +               REQUIRED OK untagged responses:  UNSEEN,  PERMANENTFLAGS,
  1.1864 +               UIDNEXT, UIDVALIDITY
  1.1865 +
  1.1866 +   Result:     OK - examine completed, now in selected state
  1.1867 +               NO - examine failure, now in authenticated state: no
  1.1868 +                    such mailbox, can't access mailbox
  1.1869 +               BAD - command unknown or arguments invalid
  1.1870 +
  1.1871 +      The EXAMINE command is identical to SELECT and returns the same
  1.1872 +      output; however, the selected mailbox is identified as read-only.
  1.1873 +      No changes to the permanent state of the mailbox, including
  1.1874 +      per-user state, are permitted; in particular, EXAMINE MUST NOT
  1.1875 +      cause messages to lose the \Recent flag.
  1.1876 +
  1.1877 +      The text of the tagged OK response to the EXAMINE command MUST
  1.1878 +      begin with the "[READ-ONLY]" response code.
  1.1879 +
  1.1880 +   Example:    C: A932 EXAMINE blurdybloop
  1.1881 +               S: * 17 EXISTS
  1.1882 +               S: * 2 RECENT
  1.1883 +               S: * OK [UNSEEN 8] Message 8 is first unseen
  1.1884 +               S: * OK [UIDVALIDITY 3857529045] UIDs valid
  1.1885 +               S: * OK [UIDNEXT 4392] Predicted next UID
  1.1886 +               S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
  1.1887 +               S: * OK [PERMANENTFLAGS ()] No permanent flags permitted
  1.1888 +               S: A932 OK [READ-ONLY] EXAMINE completed
  1.1889 +
  1.1890 +
  1.1891 +6.3.3.  CREATE Command
  1.1892 +
  1.1893 +   Arguments:  mailbox name
  1.1894 +
  1.1895 +   Responses:  no specific responses for this command
  1.1896 +
  1.1897 +   Result:     OK - create completed
  1.1898 +               NO - create failure: can't create mailbox with that name
  1.1899 +               BAD - command unknown or arguments invalid
  1.1900 +
  1.1901 +      The CREATE command creates a mailbox with the given name.  An OK
  1.1902 +      response is returned only if a new mailbox with that name has been
  1.1903 +      created.  It is an error to attempt to create INBOX or a mailbox
  1.1904 +      with a name that refers to an extant mailbox.  Any error in
  1.1905 +      creation will return a tagged NO response.
  1.1906 +
  1.1907 +
  1.1908 +
  1.1909 +Crispin                     Standards Track                    [Page 34]
  1.1910 +
  1.1911 +RFC 3501                         IMAPv4                       March 2003
  1.1912 +
  1.1913 +
  1.1914 +      If the mailbox name is suffixed with the server's hierarchy
  1.1915 +      separator character (as returned from the server by a LIST
  1.1916 +      command), this is a declaration that the client intends to create
  1.1917 +      mailbox names under this name in the hierarchy.  Server
  1.1918 +      implementations that do not require this declaration MUST ignore
  1.1919 +      the declaration.  In any case, the name created is without the
  1.1920 +      trailing hierarchy delimiter.
  1.1921 +
  1.1922 +      If the server's hierarchy separator character appears elsewhere in
  1.1923 +      the name, the server SHOULD create any superior hierarchical names
  1.1924 +      that are needed for the CREATE command to be successfully
  1.1925 +      completed.  In other words, an attempt to create "foo/bar/zap" on
  1.1926 +      a server in which "/" is the hierarchy separator character SHOULD
  1.1927 +      create foo/ and foo/bar/ if they do not already exist.
  1.1928 +
  1.1929 +      If a new mailbox is created with the same name as a mailbox which
  1.1930 +      was deleted, its unique identifiers MUST be greater than any
  1.1931 +      unique identifiers used in the previous incarnation of the mailbox
  1.1932 +      UNLESS the new incarnation has a different unique identifier
  1.1933 +      validity value.  See the description of the UID command for more
  1.1934 +      detail.
  1.1935 +
  1.1936 +   Example:    C: A003 CREATE owatagusiam/
  1.1937 +               S: A003 OK CREATE completed
  1.1938 +               C: A004 CREATE owatagusiam/blurdybloop
  1.1939 +               S: A004 OK CREATE completed
  1.1940 +
  1.1941 +        Note: The interpretation of this example depends on whether
  1.1942 +        "/" was returned as the hierarchy separator from LIST.  If
  1.1943 +        "/" is the hierarchy separator, a new level of hierarchy
  1.1944 +        named "owatagusiam" with a member called "blurdybloop" is
  1.1945 +        created.  Otherwise, two mailboxes at the same hierarchy
  1.1946 +        level are created.
  1.1947 +
  1.1948 +
  1.1949 +6.3.4.  DELETE Command
  1.1950 +
  1.1951 +   Arguments:  mailbox name
  1.1952 +
  1.1953 +   Responses:  no specific responses for this command
  1.1954 +
  1.1955 +   Result:     OK - delete completed
  1.1956 +               NO - delete failure: can't delete mailbox with that name
  1.1957 +               BAD - command unknown or arguments invalid
  1.1958 +
  1.1959 +
  1.1960 +
  1.1961 +
  1.1962 +
  1.1963 +
  1.1964 +
  1.1965 +Crispin                     Standards Track                    [Page 35]
  1.1966 +
  1.1967 +RFC 3501                         IMAPv4                       March 2003
  1.1968 +
  1.1969 +
  1.1970 +      The DELETE command permanently removes the mailbox with the given
  1.1971 +      name.  A tagged OK response is returned only if the mailbox has
  1.1972 +      been deleted.  It is an error to attempt to delete INBOX or a
  1.1973 +      mailbox name that does not exist.
  1.1974 +
  1.1975 +      The DELETE command MUST NOT remove inferior hierarchical names.
  1.1976 +      For example, if a mailbox "foo" has an inferior "foo.bar"
  1.1977 +      (assuming "." is the hierarchy delimiter character), removing
  1.1978 +      "foo" MUST NOT remove "foo.bar".  It is an error to attempt to
  1.1979 +      delete a name that has inferior hierarchical names and also has
  1.1980 +      the \Noselect mailbox name attribute (see the description of the
  1.1981 +      LIST response for more details).
  1.1982 +
  1.1983 +      It is permitted to delete a name that has inferior hierarchical
  1.1984 +      names and does not have the \Noselect mailbox name attribute.  In
  1.1985 +      this case, all messages in that mailbox are removed, and the name
  1.1986 +      will acquire the \Noselect mailbox name attribute.
  1.1987 +
  1.1988 +      The value of the highest-used unique identifier of the deleted
  1.1989 +      mailbox MUST be preserved so that a new mailbox created with the
  1.1990 +      same name will not reuse the identifiers of the former
  1.1991 +      incarnation, UNLESS the new incarnation has a different unique
  1.1992 +      identifier validity value.  See the description of the UID command
  1.1993 +      for more detail.
  1.1994 +
  1.1995 +   Examples:   C: A682 LIST "" *
  1.1996 +               S: * LIST () "/" blurdybloop
  1.1997 +               S: * LIST (\Noselect) "/" foo
  1.1998 +               S: * LIST () "/" foo/bar
  1.1999 +               S: A682 OK LIST completed
  1.2000 +               C: A683 DELETE blurdybloop
  1.2001 +               S: A683 OK DELETE completed
  1.2002 +               C: A684 DELETE foo
  1.2003 +               S: A684 NO Name "foo" has inferior hierarchical names
  1.2004 +               C: A685 DELETE foo/bar
  1.2005 +               S: A685 OK DELETE Completed
  1.2006 +               C: A686 LIST "" *
  1.2007 +               S: * LIST (\Noselect) "/" foo
  1.2008 +               S: A686 OK LIST completed
  1.2009 +               C: A687 DELETE foo
  1.2010 +               S: A687 OK DELETE Completed
  1.2011 +
  1.2012 +
  1.2013 +
  1.2014 +
  1.2015 +
  1.2016 +
  1.2017 +
  1.2018 +
  1.2019 +
  1.2020 +
  1.2021 +Crispin                     Standards Track                    [Page 36]
  1.2022 +
  1.2023 +RFC 3501                         IMAPv4                       March 2003
  1.2024 +
  1.2025 +
  1.2026 +               C: A82 LIST "" *
  1.2027 +               S: * LIST () "." blurdybloop
  1.2028 +               S: * LIST () "." foo
  1.2029 +               S: * LIST () "." foo.bar
  1.2030 +               S: A82 OK LIST completed
  1.2031 +               C: A83 DELETE blurdybloop
  1.2032 +               S: A83 OK DELETE completed
  1.2033 +               C: A84 DELETE foo
  1.2034 +               S: A84 OK DELETE Completed
  1.2035 +               C: A85 LIST "" *
  1.2036 +               S: * LIST () "." foo.bar
  1.2037 +               S: A85 OK LIST completed
  1.2038 +               C: A86 LIST "" %
  1.2039 +               S: * LIST (\Noselect) "." foo
  1.2040 +               S: A86 OK LIST completed
  1.2041 +
  1.2042 +
  1.2043 +6.3.5.  RENAME Command
  1.2044 +
  1.2045 +   Arguments:  existing mailbox name
  1.2046 +               new mailbox name
  1.2047 +
  1.2048 +   Responses:  no specific responses for this command
  1.2049 +
  1.2050 +   Result:     OK - rename completed
  1.2051 +               NO - rename failure: can't rename mailbox with that name,
  1.2052 +                    can't rename to mailbox with that name
  1.2053 +               BAD - command unknown or arguments invalid
  1.2054 +
  1.2055 +      The RENAME command changes the name of a mailbox.  A tagged OK
  1.2056 +      response is returned only if the mailbox has been renamed.  It is
  1.2057 +      an error to attempt to rename from a mailbox name that does not
  1.2058 +      exist or to a mailbox name that already exists.  Any error in
  1.2059 +      renaming will return a tagged NO response.
  1.2060 +
  1.2061 +      If the name has inferior hierarchical names, then the inferior
  1.2062 +      hierarchical names MUST also be renamed.  For example, a rename of
  1.2063 +      "foo" to "zap" will rename "foo/bar" (assuming "/" is the
  1.2064 +      hierarchy delimiter character) to "zap/bar".
  1.2065 +
  1.2066 +      If the server's hierarchy separator character appears in the name,
  1.2067 +      the server SHOULD create any superior hierarchical names that are
  1.2068 +      needed for the RENAME command to complete successfully.  In other
  1.2069 +      words, an attempt to rename "foo/bar/zap" to baz/rag/zowie on a
  1.2070 +      server in which "/" is the hierarchy separator character SHOULD
  1.2071 +      create baz/ and baz/rag/ if they do not already exist.
  1.2072 +
  1.2073 +
  1.2074 +
  1.2075 +
  1.2076 +
  1.2077 +Crispin                     Standards Track                    [Page 37]
  1.2078 +
  1.2079 +RFC 3501                         IMAPv4                       March 2003
  1.2080 +
  1.2081 +
  1.2082 +      The value of the highest-used unique identifier of the old mailbox
  1.2083 +      name MUST be preserved so that a new mailbox created with the same
  1.2084 +      name will not reuse the identifiers of the former incarnation,
  1.2085 +      UNLESS the new incarnation has a different unique identifier
  1.2086 +      validity value.  See the description of the UID command for more
  1.2087 +      detail.
  1.2088 +
  1.2089 +      Renaming INBOX is permitted, and has special behavior.  It moves
  1.2090 +      all messages in INBOX to a new mailbox with the given name,
  1.2091 +      leaving INBOX empty.  If the server implementation supports
  1.2092 +      inferior hierarchical names of INBOX, these are unaffected by a
  1.2093 +      rename of INBOX.
  1.2094 +
  1.2095 +   Examples:   C: A682 LIST "" *
  1.2096 +               S: * LIST () "/" blurdybloop
  1.2097 +               S: * LIST (\Noselect) "/" foo
  1.2098 +               S: * LIST () "/" foo/bar
  1.2099 +               S: A682 OK LIST completed
  1.2100 +               C: A683 RENAME blurdybloop sarasoop
  1.2101 +               S: A683 OK RENAME completed
  1.2102 +               C: A684 RENAME foo zowie
  1.2103 +               S: A684 OK RENAME Completed
  1.2104 +               C: A685 LIST "" *
  1.2105 +               S: * LIST () "/" sarasoop
  1.2106 +               S: * LIST (\Noselect) "/" zowie
  1.2107 +               S: * LIST () "/" zowie/bar
  1.2108 +               S: A685 OK LIST completed
  1.2109 +
  1.2110 +               C: Z432 LIST "" *
  1.2111 +               S: * LIST () "." INBOX
  1.2112 +               S: * LIST () "." INBOX.bar
  1.2113 +               S: Z432 OK LIST completed
  1.2114 +               C: Z433 RENAME INBOX old-mail
  1.2115 +               S: Z433 OK RENAME completed
  1.2116 +               C: Z434 LIST "" *
  1.2117 +               S: * LIST () "." INBOX
  1.2118 +               S: * LIST () "." INBOX.bar
  1.2119 +               S: * LIST () "." old-mail
  1.2120 +               S: Z434 OK LIST completed
  1.2121 +
  1.2122 +
  1.2123 +
  1.2124 +
  1.2125 +
  1.2126 +
  1.2127 +
  1.2128 +
  1.2129 +
  1.2130 +
  1.2131 +
  1.2132 +
  1.2133 +Crispin                     Standards Track                    [Page 38]
  1.2134 +
  1.2135 +RFC 3501                         IMAPv4                       March 2003
  1.2136 +
  1.2137 +
  1.2138 +6.3.6.  SUBSCRIBE Command
  1.2139 +
  1.2140 +   Arguments:  mailbox
  1.2141 +
  1.2142 +   Responses:  no specific responses for this command
  1.2143 +
  1.2144 +   Result:     OK - subscribe completed
  1.2145 +               NO - subscribe failure: can't subscribe to that name
  1.2146 +               BAD - command unknown or arguments invalid
  1.2147 +
  1.2148 +      The SUBSCRIBE command adds the specified mailbox name to the
  1.2149 +      server's set of "active" or "subscribed" mailboxes as returned by
  1.2150 +      the LSUB command.  This command returns a tagged OK response only
  1.2151 +      if the subscription is successful.
  1.2152 +
  1.2153 +      A server MAY validate the mailbox argument to SUBSCRIBE to verify
  1.2154 +      that it exists.  However, it MUST NOT unilaterally remove an
  1.2155 +      existing mailbox name from the subscription list even if a mailbox
  1.2156 +      by that name no longer exists.
  1.2157 +
  1.2158 +           Note: This requirement is because a server site can
  1.2159 +           choose to routinely remove a mailbox with a well-known
  1.2160 +           name (e.g., "system-alerts") after its contents expire,
  1.2161 +           with the intention of recreating it when new contents
  1.2162 +           are appropriate.
  1.2163 +
  1.2164 +
  1.2165 +   Example:    C: A002 SUBSCRIBE #news.comp.mail.mime
  1.2166 +               S: A002 OK SUBSCRIBE completed
  1.2167 +
  1.2168 +
  1.2169 +6.3.7.  UNSUBSCRIBE Command
  1.2170 +
  1.2171 +   Arguments:  mailbox name
  1.2172 +
  1.2173 +   Responses:  no specific responses for this command
  1.2174 +
  1.2175 +   Result:     OK - unsubscribe completed
  1.2176 +               NO - unsubscribe failure: can't unsubscribe that name
  1.2177 +               BAD - command unknown or arguments invalid
  1.2178 +
  1.2179 +      The UNSUBSCRIBE command removes the specified mailbox name from
  1.2180 +      the server's set of "active" or "subscribed" mailboxes as returned
  1.2181 +      by the LSUB command.  This command returns a tagged OK response
  1.2182 +      only if the unsubscription is successful.
  1.2183 +
  1.2184 +   Example:    C: A002 UNSUBSCRIBE #news.comp.mail.mime
  1.2185 +               S: A002 OK UNSUBSCRIBE completed
  1.2186 +
  1.2187 +
  1.2188 +
  1.2189 +Crispin                     Standards Track                    [Page 39]
  1.2190 +
  1.2191 +RFC 3501                         IMAPv4                       March 2003
  1.2192 +
  1.2193 +
  1.2194 +6.3.8.  LIST Command
  1.2195 +
  1.2196 +   Arguments:  reference name
  1.2197 +               mailbox name with possible wildcards
  1.2198 +
  1.2199 +   Responses:  untagged responses: LIST
  1.2200 +
  1.2201 +   Result:     OK - list completed
  1.2202 +               NO - list failure: can't list that reference or name
  1.2203 +               BAD - command unknown or arguments invalid
  1.2204 +
  1.2205 +      The LIST command returns a subset of names from the complete set
  1.2206 +      of all names available to the client.  Zero or more untagged LIST
  1.2207 +      replies are returned, containing the name attributes, hierarchy
  1.2208 +      delimiter, and name; see the description of the LIST reply for
  1.2209 +      more detail.
  1.2210 +
  1.2211 +      The LIST command SHOULD return its data quickly, without undue
  1.2212 +      delay.  For example, it SHOULD NOT go to excess trouble to
  1.2213 +      calculate the \Marked or \Unmarked status or perform other
  1.2214 +      processing; if each name requires 1 second of processing, then a
  1.2215 +      list of 1200 names would take 20 minutes!
  1.2216 +
  1.2217 +      An empty ("" string) reference name argument indicates that the
  1.2218 +      mailbox name is interpreted as by SELECT.  The returned mailbox
  1.2219 +      names MUST match the supplied mailbox name pattern.  A non-empty
  1.2220 +      reference name argument is the name of a mailbox or a level of
  1.2221 +      mailbox hierarchy, and indicates the context in which the mailbox
  1.2222 +      name is interpreted.
  1.2223 +
  1.2224 +      An empty ("" string) mailbox name argument is a special request to
  1.2225 +      return the hierarchy delimiter and the root name of the name given
  1.2226 +      in the reference.  The value returned as the root MAY be the empty
  1.2227 +      string if the reference is non-rooted or is an empty string.  In
  1.2228 +      all cases, a hierarchy delimiter (or NIL if there is no hierarchy)
  1.2229 +      is returned.  This permits a client to get the hierarchy delimiter
  1.2230 +      (or find out that the mailbox names are flat) even when no
  1.2231 +      mailboxes by that name currently exist.
  1.2232 +
  1.2233 +      The reference and mailbox name arguments are interpreted into a
  1.2234 +      canonical form that represents an unambiguous left-to-right
  1.2235 +      hierarchy.  The returned mailbox names will be in the interpreted
  1.2236 +      form.
  1.2237 +
  1.2238 +
  1.2239 +
  1.2240 +
  1.2241 +
  1.2242 +
  1.2243 +
  1.2244 +
  1.2245 +Crispin                     Standards Track                    [Page 40]
  1.2246 +
  1.2247 +RFC 3501                         IMAPv4                       March 2003
  1.2248 +
  1.2249 +
  1.2250 +           Note: The interpretation of the reference argument is
  1.2251 +           implementation-defined.  It depends upon whether the
  1.2252 +           server implementation has a concept of the "current
  1.2253 +           working directory" and leading "break out characters",
  1.2254 +           which override the current working directory.
  1.2255 +
  1.2256 +           For example, on a server which exports a UNIX or NT
  1.2257 +           filesystem, the reference argument contains the current
  1.2258 +           working directory, and the mailbox name argument would
  1.2259 +           contain the name as interpreted in the current working
  1.2260 +           directory.
  1.2261 +
  1.2262 +           If a server implementation has no concept of break out
  1.2263 +           characters, the canonical form is normally the reference
  1.2264 +           name appended with the mailbox name.  Note that if the
  1.2265 +           server implements the namespace convention (section
  1.2266 +           5.1.2), "#" is a break out character and must be treated
  1.2267 +           as such.
  1.2268 +
  1.2269 +           If the reference argument is not a level of mailbox
  1.2270 +           hierarchy (that is, it is a \NoInferiors name), and/or
  1.2271 +           the reference argument does not end with the hierarchy
  1.2272 +           delimiter, it is implementation-dependent how this is
  1.2273 +           interpreted.  For example, a reference of "foo/bar" and
  1.2274 +           mailbox name of "rag/baz" could be interpreted as
  1.2275 +           "foo/bar/rag/baz", "foo/barrag/baz", or "foo/rag/baz".
  1.2276 +           A client SHOULD NOT use such a reference argument except
  1.2277 +           at the explicit request of the user.  A hierarchical
  1.2278 +           browser MUST NOT make any assumptions about server
  1.2279 +           interpretation of the reference unless the reference is
  1.2280 +           a level of mailbox hierarchy AND ends with the hierarchy
  1.2281 +           delimiter.
  1.2282 +
  1.2283 +      Any part of the reference argument that is included in the
  1.2284 +      interpreted form SHOULD prefix the interpreted form.  It SHOULD
  1.2285 +      also be in the same form as the reference name argument.  This
  1.2286 +      rule permits the client to determine if the returned mailbox name
  1.2287 +      is in the context of the reference argument, or if something about
  1.2288 +      the mailbox argument overrode the reference argument.  Without
  1.2289 +      this rule, the client would have to have knowledge of the server's
  1.2290 +      naming semantics including what characters are "breakouts" that
  1.2291 +      override a naming context.
  1.2292 +
  1.2293 +
  1.2294 +
  1.2295 +
  1.2296 +
  1.2297 +
  1.2298 +
  1.2299 +
  1.2300 +
  1.2301 +Crispin                     Standards Track                    [Page 41]
  1.2302 +
  1.2303 +RFC 3501                         IMAPv4                       March 2003
  1.2304 +
  1.2305 +
  1.2306 +           For example, here are some examples of how references
  1.2307 +           and mailbox names might be interpreted on a UNIX-based
  1.2308 +           server:
  1.2309 +
  1.2310 +               Reference     Mailbox Name  Interpretation
  1.2311 +               ------------  ------------  --------------
  1.2312 +               ~smith/Mail/  foo.*         ~smith/Mail/foo.*
  1.2313 +               archive/      %             archive/%
  1.2314 +               #news.        comp.mail.*   #news.comp.mail.*
  1.2315 +               ~smith/Mail/  /usr/doc/foo  /usr/doc/foo
  1.2316 +               archive/      ~fred/Mail/*  ~fred/Mail/*
  1.2317 +
  1.2318 +           The first three examples demonstrate interpretations in
  1.2319 +           the context of the reference argument.  Note that
  1.2320 +           "~smith/Mail" SHOULD NOT be transformed into something
  1.2321 +           like "/u2/users/smith/Mail", or it would be impossible
  1.2322 +           for the client to determine that the interpretation was
  1.2323 +           in the context of the reference.
  1.2324 +
  1.2325 +      The character "*" is a wildcard, and matches zero or more
  1.2326 +      characters at this position.  The character "%" is similar to "*",
  1.2327 +      but it does not match a hierarchy delimiter.  If the "%" wildcard
  1.2328 +      is the last character of a mailbox name argument, matching levels
  1.2329 +      of hierarchy are also returned.  If these levels of hierarchy are
  1.2330 +      not also selectable mailboxes, they are returned with the
  1.2331 +      \Noselect mailbox name attribute (see the description of the LIST
  1.2332 +      response for more details).
  1.2333 +
  1.2334 +      Server implementations are permitted to "hide" otherwise
  1.2335 +      accessible mailboxes from the wildcard characters, by preventing
  1.2336 +      certain characters or names from matching a wildcard in certain
  1.2337 +      situations.  For example, a UNIX-based server might restrict the
  1.2338 +      interpretation of "*" so that an initial "/" character does not
  1.2339 +      match.
  1.2340 +
  1.2341 +      The special name INBOX is included in the output from LIST, if
  1.2342 +      INBOX is supported by this server for this user and if the
  1.2343 +      uppercase string "INBOX" matches the interpreted reference and
  1.2344 +      mailbox name arguments with wildcards as described above.  The
  1.2345 +      criteria for omitting INBOX is whether SELECT INBOX will return
  1.2346 +      failure; it is not relevant whether the user's real INBOX resides
  1.2347 +      on this or some other server.
  1.2348 +
  1.2349 +
  1.2350 +
  1.2351 +
  1.2352 +
  1.2353 +
  1.2354 +
  1.2355 +
  1.2356 +
  1.2357 +Crispin                     Standards Track                    [Page 42]
  1.2358 +
  1.2359 +RFC 3501                         IMAPv4                       March 2003
  1.2360 +
  1.2361 +
  1.2362 +   Example:    C: A101 LIST "" ""
  1.2363 +               S: * LIST (\Noselect) "/" ""
  1.2364 +               S: A101 OK LIST Completed
  1.2365 +               C: A102 LIST #news.comp.mail.misc ""
  1.2366 +               S: * LIST (\Noselect) "." #news.
  1.2367 +               S: A102 OK LIST Completed
  1.2368 +               C: A103 LIST /usr/staff/jones ""
  1.2369 +               S: * LIST (\Noselect) "/" /
  1.2370 +               S: A103 OK LIST Completed
  1.2371 +               C: A202 LIST ~/Mail/ %
  1.2372 +               S: * LIST (\Noselect) "/" ~/Mail/foo
  1.2373 +               S: * LIST () "/" ~/Mail/meetings
  1.2374 +               S: A202 OK LIST completed
  1.2375 +
  1.2376 +
  1.2377 +6.3.9.  LSUB Command
  1.2378 +
  1.2379 +   Arguments:  reference name
  1.2380 +               mailbox name with possible wildcards
  1.2381 +
  1.2382 +   Responses:  untagged responses: LSUB
  1.2383 +
  1.2384 +   Result:     OK - lsub completed
  1.2385 +               NO - lsub failure: can't list that reference or name
  1.2386 +               BAD - command unknown or arguments invalid
  1.2387 +
  1.2388 +      The LSUB command returns a subset of names from the set of names
  1.2389 +      that the user has declared as being "active" or "subscribed".
  1.2390 +      Zero or more untagged LSUB replies are returned.  The arguments to
  1.2391 +      LSUB are in the same form as those for LIST.
  1.2392 +
  1.2393 +      The returned untagged LSUB response MAY contain different mailbox
  1.2394 +      flags from a LIST untagged response.  If this should happen, the
  1.2395 +      flags in the untagged LIST are considered more authoritative.
  1.2396 +
  1.2397 +      A special situation occurs when using LSUB with the % wildcard.
  1.2398 +      Consider what happens if "foo/bar" (with a hierarchy delimiter of
  1.2399 +      "/") is subscribed but "foo" is not.  A "%" wildcard to LSUB must
  1.2400 +      return foo, not foo/bar, in the LSUB response, and it MUST be
  1.2401 +      flagged with the \Noselect attribute.
  1.2402 +
  1.2403 +      The server MUST NOT unilaterally remove an existing mailbox name
  1.2404 +      from the subscription list even if a mailbox by that name no
  1.2405 +      longer exists.
  1.2406 +
  1.2407 +
  1.2408 +
  1.2409 +
  1.2410 +
  1.2411 +
  1.2412 +
  1.2413 +Crispin                     Standards Track                    [Page 43]
  1.2414 +
  1.2415 +RFC 3501                         IMAPv4                       March 2003
  1.2416 +
  1.2417 +
  1.2418 +   Example:    C: A002 LSUB "#news." "comp.mail.*"
  1.2419 +               S: * LSUB () "." #news.comp.mail.mime
  1.2420 +               S: * LSUB () "." #news.comp.mail.misc
  1.2421 +               S: A002 OK LSUB completed
  1.2422 +               C: A003 LSUB "#news." "comp.%"
  1.2423 +               S: * LSUB (\NoSelect) "." #news.comp.mail
  1.2424 +               S: A003 OK LSUB completed
  1.2425 +
  1.2426 +
  1.2427 +6.3.10. STATUS Command
  1.2428 +
  1.2429 +   Arguments:  mailbox name
  1.2430 +               status data item names
  1.2431 +
  1.2432 +   Responses:  untagged responses: STATUS
  1.2433 +
  1.2434 +   Result:     OK - status completed
  1.2435 +               NO - status failure: no status for that name
  1.2436 +               BAD - command unknown or arguments invalid
  1.2437 +
  1.2438 +      The STATUS command requests the status of the indicated mailbox.
  1.2439 +      It does not change the currently selected mailbox, nor does it
  1.2440 +      affect the state of any messages in the queried mailbox (in
  1.2441 +      particular, STATUS MUST NOT cause messages to lose the \Recent
  1.2442 +      flag).
  1.2443 +
  1.2444 +      The STATUS command provides an alternative to opening a second
  1.2445 +      IMAP4rev1 connection and doing an EXAMINE command on a mailbox to
  1.2446 +      query that mailbox's status without deselecting the current
  1.2447 +      mailbox in the first IMAP4rev1 connection.
  1.2448 +
  1.2449 +      Unlike the LIST command, the STATUS command is not guaranteed to
  1.2450 +      be fast in its response.  Under certain circumstances, it can be
  1.2451 +      quite slow.  In some implementations, the server is obliged to
  1.2452 +      open the mailbox read-only internally to obtain certain status
  1.2453 +      information.  Also unlike the LIST command, the STATUS command
  1.2454 +      does not accept wildcards.
  1.2455 +
  1.2456 +           Note: The STATUS command is intended to access the
  1.2457 +           status of mailboxes other than the currently selected
  1.2458 +           mailbox.  Because the STATUS command can cause the
  1.2459 +           mailbox to be opened internally, and because this
  1.2460 +           information is available by other means on the selected
  1.2461 +           mailbox, the STATUS command SHOULD NOT be used on the
  1.2462 +           currently selected mailbox.
  1.2463 +
  1.2464 +
  1.2465 +
  1.2466 +
  1.2467 +
  1.2468 +
  1.2469 +Crispin                     Standards Track                    [Page 44]
  1.2470 +
  1.2471 +RFC 3501                         IMAPv4                       March 2003
  1.2472 +
  1.2473 +
  1.2474 +           The STATUS command MUST NOT be used as a "check for new
  1.2475 +           messages in the selected mailbox" operation (refer to
  1.2476 +           sections 7, 7.3.1, and 7.3.2 for more information about
  1.2477 +           the proper method for new message checking).
  1.2478 +
  1.2479 +           Because the STATUS command is not guaranteed to be fast
  1.2480 +           in its results, clients SHOULD NOT expect to be able to
  1.2481 +           issue many consecutive STATUS commands and obtain
  1.2482 +           reasonable performance.
  1.2483 +
  1.2484 +      The currently defined status data items that can be requested are:
  1.2485 +
  1.2486 +      MESSAGES
  1.2487 +         The number of messages in the mailbox.
  1.2488 +
  1.2489 +      RECENT
  1.2490 +         The number of messages with the \Recent flag set.
  1.2491 +
  1.2492 +      UIDNEXT
  1.2493 +         The next unique identifier value of the mailbox.  Refer to
  1.2494 +         section 2.3.1.1 for more information.
  1.2495 +
  1.2496 +      UIDVALIDITY
  1.2497 +         The unique identifier validity value of the mailbox.  Refer to
  1.2498 +         section 2.3.1.1 for more information.
  1.2499 +
  1.2500 +      UNSEEN
  1.2501 +         The number of messages which do not have the \Seen flag set.
  1.2502 +
  1.2503 +
  1.2504 +   Example:    C: A042 STATUS blurdybloop (UIDNEXT MESSAGES)
  1.2505 +               S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
  1.2506 +               S: A042 OK STATUS completed
  1.2507 +
  1.2508 +
  1.2509 +
  1.2510 +
  1.2511 +
  1.2512 +
  1.2513 +
  1.2514 +
  1.2515 +
  1.2516 +
  1.2517 +
  1.2518 +
  1.2519 +
  1.2520 +
  1.2521 +
  1.2522 +
  1.2523 +
  1.2524 +
  1.2525 +Crispin                     Standards Track                    [Page 45]
  1.2526 +
  1.2527 +RFC 3501                         IMAPv4                       March 2003
  1.2528 +
  1.2529 +
  1.2530 +6.3.11. APPEND Command
  1.2531 +
  1.2532 +   Arguments:  mailbox name
  1.2533 +               OPTIONAL flag parenthesized list
  1.2534 +               OPTIONAL date/time string
  1.2535 +               message literal
  1.2536 +
  1.2537 +   Responses:  no specific responses for this command
  1.2538 +
  1.2539 +   Result:     OK - append completed
  1.2540 +               NO - append error: can't append to that mailbox, error
  1.2541 +                    in flags or date/time or message text
  1.2542 +               BAD - command unknown or arguments invalid
  1.2543 +
  1.2544 +      The APPEND command appends the literal argument as a new message
  1.2545 +      to the end of the specified destination mailbox.  This argument
  1.2546 +      SHOULD be in the format of an [RFC-2822] message.  8-bit
  1.2547 +      characters are permitted in the message.  A server implementation
  1.2548 +      that is unable to preserve 8-bit data properly MUST be able to
  1.2549 +      reversibly convert 8-bit APPEND data to 7-bit using a [MIME-IMB]
  1.2550 +      content transfer encoding.
  1.2551 +
  1.2552 +           Note: There MAY be exceptions, e.g., draft messages, in
  1.2553 +           which required [RFC-2822] header lines are omitted in
  1.2554 +           the message literal argument to APPEND.  The full
  1.2555 +           implications of doing so MUST be understood and
  1.2556 +           carefully weighed.
  1.2557 +
  1.2558 +      If a flag parenthesized list is specified, the flags SHOULD be set
  1.2559 +      in the resulting message; otherwise, the flag list of the
  1.2560 +      resulting message is set to empty by default.  In either case, the
  1.2561 +      Recent flag is also set.
  1.2562 +
  1.2563 +      If a date-time is specified, the internal date SHOULD be set in
  1.2564 +      the resulting message; otherwise, the internal date of the
  1.2565 +      resulting message is set to the current date and time by default.
  1.2566 +
  1.2567 +      If the append is unsuccessful for any reason, the mailbox MUST be
  1.2568 +      restored to its state before the APPEND attempt; no partial
  1.2569 +      appending is permitted.
  1.2570 +
  1.2571 +      If the destination mailbox does not exist, a server MUST return an
  1.2572 +      error, and MUST NOT automatically create the mailbox.  Unless it
  1.2573 +      is certain that the destination mailbox can not be created, the
  1.2574 +      server MUST send the response code "[TRYCREATE]" as the prefix of
  1.2575 +      the text of the tagged NO response.  This gives a hint to the
  1.2576 +      client that it can attempt a CREATE command and retry the APPEND
  1.2577 +      if the CREATE is successful.
  1.2578 +
  1.2579 +
  1.2580 +
  1.2581 +Crispin                     Standards Track                    [Page 46]
  1.2582 +
  1.2583 +RFC 3501                         IMAPv4                       March 2003
  1.2584 +
  1.2585 +
  1.2586 +      If the mailbox is currently selected, the normal new message
  1.2587 +      actions SHOULD occur.  Specifically, the server SHOULD notify the
  1.2588 +      client immediately via an untagged EXISTS response.  If the server
  1.2589 +      does not do so, the client MAY issue a NOOP command (or failing
  1.2590 +      that, a CHECK command) after one or more APPEND commands.
  1.2591 +
  1.2592 +   Example:    C: A003 APPEND saved-messages (\Seen) {310}
  1.2593 +               S: + Ready for literal data
  1.2594 +               C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
  1.2595 +               C: From: Fred Foobar <foobar@Blurdybloop.COM>
  1.2596 +               C: Subject: afternoon meeting
  1.2597 +               C: To: mooch@owatagu.siam.edu
  1.2598 +               C: Message-Id: <B27397-0100000@Blurdybloop.COM>
  1.2599 +               C: MIME-Version: 1.0
  1.2600 +               C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
  1.2601 +               C:
  1.2602 +               C: Hello Joe, do you think we can meet at 3:30 tomorrow?
  1.2603 +               C:
  1.2604 +               S: A003 OK APPEND completed
  1.2605 +
  1.2606 +        Note: The APPEND command is not used for message delivery,
  1.2607 +        because it does not provide a mechanism to transfer [SMTP]
  1.2608 +        envelope information.
  1.2609 +
  1.2610 +6.4.    Client Commands - Selected State
  1.2611 +
  1.2612 +   In the selected state, commands that manipulate messages in a mailbox
  1.2613 +   are permitted.
  1.2614 +
  1.2615 +   In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
  1.2616 +   and the authenticated state commands (SELECT, EXAMINE, CREATE,
  1.2617 +   DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS, and
  1.2618 +   APPEND), the following commands are valid in the selected state:
  1.2619 +   CHECK, CLOSE, EXPUNGE, SEARCH, FETCH, STORE, COPY, and UID.
  1.2620 +
  1.2621 +6.4.1.  CHECK Command
  1.2622 +
  1.2623 +   Arguments:  none
  1.2624 +
  1.2625 +   Responses:  no specific responses for this command
  1.2626 +
  1.2627 +   Result:     OK - check completed
  1.2628 +               BAD - command unknown or arguments invalid
  1.2629 +
  1.2630 +      The CHECK command requests a checkpoint of the currently selected
  1.2631 +      mailbox.  A checkpoint refers to any implementation-dependent
  1.2632 +      housekeeping associated with the mailbox (e.g., resolving the
  1.2633 +      server's in-memory state of the mailbox with the state on its
  1.2634 +
  1.2635 +
  1.2636 +
  1.2637 +Crispin                     Standards Track                    [Page 47]
  1.2638 +
  1.2639 +RFC 3501                         IMAPv4                       March 2003
  1.2640 +
  1.2641 +
  1.2642 +      disk) that is not normally executed as part of each command.  A
  1.2643 +      checkpoint MAY take a non-instantaneous amount of real time to
  1.2644 +      complete.  If a server implementation has no such housekeeping
  1.2645 +      considerations, CHECK is equivalent to NOOP.
  1.2646 +
  1.2647 +      There is no guarantee that an EXISTS untagged response will happen
  1.2648 +      as a result of CHECK.  NOOP, not CHECK, SHOULD be used for new
  1.2649 +      message polling.
  1.2650 +
  1.2651 +   Example:    C: FXXZ CHECK
  1.2652 +               S: FXXZ OK CHECK Completed
  1.2653 +
  1.2654 +
  1.2655 +6.4.2.  CLOSE Command
  1.2656 +
  1.2657 +   Arguments:  none
  1.2658 +
  1.2659 +   Responses:  no specific responses for this command
  1.2660 +
  1.2661 +   Result:     OK - close completed, now in authenticated state
  1.2662 +               BAD - command unknown or arguments invalid
  1.2663 +
  1.2664 +      The CLOSE command permanently removes all messages that have the
  1.2665 +      \Deleted flag set from the currently selected mailbox, and returns
  1.2666 +      to the authenticated state from the selected state.  No untagged
  1.2667 +      EXPUNGE responses are sent.
  1.2668 +
  1.2669 +      No messages are removed, and no error is given, if the mailbox is
  1.2670 +      selected by an EXAMINE command or is otherwise selected read-only.
  1.2671 +
  1.2672 +      Even if a mailbox is selected, a SELECT, EXAMINE, or LOGOUT
  1.2673 +      command MAY be issued without previously issuing a CLOSE command.
  1.2674 +      The SELECT, EXAMINE, and LOGOUT commands implicitly close the
  1.2675 +      currently selected mailbox without doing an expunge.  However,
  1.2676 +      when many messages are deleted, a CLOSE-LOGOUT or CLOSE-SELECT
  1.2677 +      sequence is considerably faster than an EXPUNGE-LOGOUT or
  1.2678 +      EXPUNGE-SELECT because no untagged EXPUNGE responses (which the
  1.2679 +      client would probably ignore) are sent.
  1.2680 +
  1.2681 +   Example:    C: A341 CLOSE
  1.2682 +               S: A341 OK CLOSE completed
  1.2683 +
  1.2684 +
  1.2685 +
  1.2686 +
  1.2687 +
  1.2688 +
  1.2689 +
  1.2690 +
  1.2691 +
  1.2692 +
  1.2693 +Crispin                     Standards Track                    [Page 48]
  1.2694 +
  1.2695 +RFC 3501                         IMAPv4                       March 2003
  1.2696 +
  1.2697 +
  1.2698 +6.4.3.  EXPUNGE Command
  1.2699 +
  1.2700 +   Arguments:  none
  1.2701 +
  1.2702 +   Responses:  untagged responses: EXPUNGE
  1.2703 +
  1.2704 +   Result:     OK - expunge completed
  1.2705 +               NO - expunge failure: can't expunge (e.g., permission
  1.2706 +                    denied)
  1.2707 +               BAD - command unknown or arguments invalid
  1.2708 +
  1.2709 +      The EXPUNGE command permanently removes all messages that have the
  1.2710 +      \Deleted flag set from the currently selected mailbox.  Before
  1.2711 +      returning an OK to the client, an untagged EXPUNGE response is
  1.2712 +      sent for each message that is removed.
  1.2713 +
  1.2714 +   Example:    C: A202 EXPUNGE
  1.2715 +               S: * 3 EXPUNGE
  1.2716 +               S: * 3 EXPUNGE
  1.2717 +               S: * 5 EXPUNGE
  1.2718 +               S: * 8 EXPUNGE
  1.2719 +               S: A202 OK EXPUNGE completed
  1.2720 +
  1.2721 +        Note: In this example, messages 3, 4, 7, and 11 had the
  1.2722 +        \Deleted flag set.  See the description of the EXPUNGE
  1.2723 +        response for further explanation.
  1.2724 +
  1.2725 +
  1.2726 +6.4.4.  SEARCH Command
  1.2727 +
  1.2728 +   Arguments:  OPTIONAL [CHARSET] specification
  1.2729 +               searching criteria (one or more)
  1.2730 +
  1.2731 +   Responses:  REQUIRED untagged response: SEARCH
  1.2732 +
  1.2733 +   Result:     OK - search completed
  1.2734 +               NO - search error: can't search that [CHARSET] or
  1.2735 +                    criteria
  1.2736 +               BAD - command unknown or arguments invalid
  1.2737 +
  1.2738 +      The SEARCH command searches the mailbox for messages that match
  1.2739 +      the given searching criteria.  Searching criteria consist of one
  1.2740 +      or more search keys.  The untagged SEARCH response from the server
  1.2741 +      contains a listing of message sequence numbers corresponding to
  1.2742 +      those messages that match the searching criteria.
  1.2743 +
  1.2744 +
  1.2745 +
  1.2746 +
  1.2747 +
  1.2748 +
  1.2749 +Crispin                     Standards Track                    [Page 49]
  1.2750 +
  1.2751 +RFC 3501                         IMAPv4                       March 2003
  1.2752 +
  1.2753 +
  1.2754 +      When multiple keys are specified, the result is the intersection
  1.2755 +      (AND function) of all the messages that match those keys.  For
  1.2756 +      example, the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers
  1.2757 +      to all deleted messages from Smith that were placed in the mailbox
  1.2758 +      since February 1, 1994.  A search key can also be a parenthesized
  1.2759 +      list of one or more search keys (e.g., for use with the OR and NOT
  1.2760 +      keys).
  1.2761 +
  1.2762 +      Server implementations MAY exclude [MIME-IMB] body parts with
  1.2763 +      terminal content media types other than TEXT and MESSAGE from
  1.2764 +      consideration in SEARCH matching.
  1.2765 +
  1.2766 +      The OPTIONAL [CHARSET] specification consists of the word
  1.2767 +      "CHARSET" followed by a registered [CHARSET].  It indicates the
  1.2768 +      [CHARSET] of the strings that appear in the search criteria.
  1.2769 +      [MIME-IMB] content transfer encodings, and [MIME-HDRS] strings in
  1.2770 +      [RFC-2822]/[MIME-IMB] headers, MUST be decoded before comparing
  1.2771 +      text in a [CHARSET] other than US-ASCII.  US-ASCII MUST be
  1.2772 +      supported; other [CHARSET]s MAY be supported.
  1.2773 +
  1.2774 +      If the server does not support the specified [CHARSET], it MUST
  1.2775 +      return a tagged NO response (not a BAD).  This response SHOULD
  1.2776 +      contain the BADCHARSET response code, which MAY list the
  1.2777 +      [CHARSET]s supported by the server.
  1.2778 +
  1.2779 +      In all search keys that use strings, a message matches the key if
  1.2780 +      the string is a substring of the field.  The matching is
  1.2781 +      case-insensitive.
  1.2782 +
  1.2783 +      The defined search keys are as follows.  Refer to the Formal
  1.2784 +      Syntax section for the precise syntactic definitions of the
  1.2785 +      arguments.
  1.2786 +
  1.2787 +      <sequence set>
  1.2788 +         Messages with message sequence numbers corresponding to the
  1.2789 +         specified message sequence number set.
  1.2790 +
  1.2791 +      ALL
  1.2792 +         All messages in the mailbox; the default initial key for
  1.2793 +         ANDing.
  1.2794 +
  1.2795 +      ANSWERED
  1.2796 +         Messages with the \Answered flag set.
  1.2797 +
  1.2798 +
  1.2799 +
  1.2800 +
  1.2801 +
  1.2802 +
  1.2803 +
  1.2804 +
  1.2805 +Crispin                     Standards Track                    [Page 50]
  1.2806 +
  1.2807 +RFC 3501                         IMAPv4                       March 2003
  1.2808 +
  1.2809 +
  1.2810 +      BCC <string>
  1.2811 +         Messages that contain the specified string in the envelope
  1.2812 +         structure's BCC field.
  1.2813 +
  1.2814 +      BEFORE <date>
  1.2815 +         Messages whose internal date (disregarding time and timezone)
  1.2816 +         is earlier than the specified date.
  1.2817 +
  1.2818 +      BODY <string>
  1.2819 +         Messages that contain the specified string in the body of the
  1.2820 +         message.
  1.2821 +
  1.2822 +      CC <string>
  1.2823 +         Messages that contain the specified string in the envelope
  1.2824 +         structure's CC field.
  1.2825 +
  1.2826 +      DELETED
  1.2827 +         Messages with the \Deleted flag set.
  1.2828 +
  1.2829 +      DRAFT
  1.2830 +         Messages with the \Draft flag set.
  1.2831 +
  1.2832 +      FLAGGED
  1.2833 +         Messages with the \Flagged flag set.
  1.2834 +
  1.2835 +      FROM <string>
  1.2836 +         Messages that contain the specified string in the envelope
  1.2837 +         structure's FROM field.
  1.2838 +
  1.2839 +      HEADER <field-name> <string>
  1.2840 +         Messages that have a header with the specified field-name (as
  1.2841 +         defined in [RFC-2822]) and that contains the specified string
  1.2842 +         in the text of the header (what comes after the colon).  If the
  1.2843 +         string to search is zero-length, this matches all messages that
  1.2844 +         have a header line with the specified field-name regardless of
  1.2845 +         the contents.
  1.2846 +
  1.2847 +      KEYWORD <flag>
  1.2848 +         Messages with the specified keyword flag set.
  1.2849 +
  1.2850 +      LARGER <n>
  1.2851 +         Messages with an [RFC-2822] size larger than the specified
  1.2852 +         number of octets.
  1.2853 +
  1.2854 +      NEW
  1.2855 +         Messages that have the \Recent flag set but not the \Seen flag.
  1.2856 +         This is functionally equivalent to "(RECENT UNSEEN)".
  1.2857 +
  1.2858 +
  1.2859 +
  1.2860 +
  1.2861 +Crispin                     Standards Track                    [Page 51]
  1.2862 +
  1.2863 +RFC 3501                         IMAPv4                       March 2003
  1.2864 +
  1.2865 +
  1.2866 +      NOT <search-key>
  1.2867 +         Messages that do not match the specified search key.
  1.2868 +
  1.2869 +      OLD
  1.2870 +         Messages that do not have the \Recent flag set.  This is
  1.2871 +         functionally equivalent to "NOT RECENT" (as opposed to "NOT
  1.2872 +         NEW").
  1.2873 +
  1.2874 +      ON <date>
  1.2875 +         Messages whose internal date (disregarding time and timezone)
  1.2876 +         is within the specified date.
  1.2877 +
  1.2878 +      OR <search-key1> <search-key2>
  1.2879 +         Messages that match either search key.
  1.2880 +
  1.2881 +      RECENT
  1.2882 +         Messages that have the \Recent flag set.
  1.2883 +
  1.2884 +      SEEN
  1.2885 +         Messages that have the \Seen flag set.
  1.2886 +
  1.2887 +      SENTBEFORE <date>
  1.2888 +         Messages whose [RFC-2822] Date: header (disregarding time and
  1.2889 +         timezone) is earlier than the specified date.
  1.2890 +
  1.2891 +      SENTON <date>
  1.2892 +         Messages whose [RFC-2822] Date: header (disregarding time and
  1.2893 +         timezone) is within the specified date.
  1.2894 +
  1.2895 +      SENTSINCE <date>
  1.2896 +         Messages whose [RFC-2822] Date: header (disregarding time and
  1.2897 +         timezone) is within or later than the specified date.
  1.2898 +
  1.2899 +      SINCE <date>
  1.2900 +         Messages whose internal date (disregarding time and timezone)
  1.2901 +         is within or later than the specified date.
  1.2902 +
  1.2903 +      SMALLER <n>
  1.2904 +         Messages with an [RFC-2822] size smaller than the specified
  1.2905 +         number of octets.
  1.2906 +
  1.2907 +
  1.2908 +
  1.2909 +
  1.2910 +
  1.2911 +
  1.2912 +
  1.2913 +
  1.2914 +
  1.2915 +
  1.2916 +
  1.2917 +Crispin                     Standards Track                    [Page 52]
  1.2918 +
  1.2919 +RFC 3501                         IMAPv4                       March 2003
  1.2920 +
  1.2921 +
  1.2922 +      SUBJECT <string>
  1.2923 +         Messages that contain the specified string in the envelope
  1.2924 +         structure's SUBJECT field.
  1.2925 +
  1.2926 +      TEXT <string>
  1.2927 +         Messages that contain the specified string in the header or
  1.2928 +         body of the message.
  1.2929 +
  1.2930 +      TO <string>
  1.2931 +         Messages that contain the specified string in the envelope
  1.2932 +         structure's TO field.
  1.2933 +
  1.2934 +      UID <sequence set>
  1.2935 +         Messages with unique identifiers corresponding to the specified
  1.2936 +         unique identifier set.  Sequence set ranges are permitted.
  1.2937 +
  1.2938 +      UNANSWERED
  1.2939 +         Messages that do not have the \Answered flag set.
  1.2940 +
  1.2941 +      UNDELETED
  1.2942 +         Messages that do not have the \Deleted flag set.
  1.2943 +
  1.2944 +      UNDRAFT
  1.2945 +         Messages that do not have the \Draft flag set.
  1.2946 +
  1.2947 +      UNFLAGGED
  1.2948 +         Messages that do not have the \Flagged flag set.
  1.2949 +
  1.2950 +      UNKEYWORD <flag>
  1.2951 +         Messages that do not have the specified keyword flag set.
  1.2952 +
  1.2953 +      UNSEEN
  1.2954 +         Messages that do not have the \Seen flag set.
  1.2955 +
  1.2956 +
  1.2957 +
  1.2958 +
  1.2959 +
  1.2960 +
  1.2961 +
  1.2962 +
  1.2963 +
  1.2964 +
  1.2965 +
  1.2966 +
  1.2967 +
  1.2968 +
  1.2969 +
  1.2970 +
  1.2971 +
  1.2972 +
  1.2973 +Crispin                     Standards Track                    [Page 53]
  1.2974 +
  1.2975 +RFC 3501                         IMAPv4                       March 2003
  1.2976 +
  1.2977 +
  1.2978 +   Example:    C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith"
  1.2979 +               S: * SEARCH 2 84 882
  1.2980 +               S: A282 OK SEARCH completed
  1.2981 +               C: A283 SEARCH TEXT "string not in mailbox"
  1.2982 +               S: * SEARCH
  1.2983 +               S: A283 OK SEARCH completed
  1.2984 +               C: A284 SEARCH CHARSET UTF-8 TEXT {6}
  1.2985 +               C: XXXXXX
  1.2986 +               S: * SEARCH 43
  1.2987 +               S: A284 OK SEARCH completed
  1.2988 +
  1.2989 +        Note: Since this document is restricted to 7-bit ASCII
  1.2990 +        text, it is not possible to show actual UTF-8 data.  The
  1.2991 +        "XXXXXX" is a placeholder for what would be 6 octets of
  1.2992 +        8-bit data in an actual transaction.
  1.2993 +
  1.2994 +
  1.2995 +6.4.5.  FETCH Command
  1.2996 +
  1.2997 +   Arguments:  sequence set
  1.2998 +               message data item names or macro
  1.2999 +
  1.3000 +   Responses:  untagged responses: FETCH
  1.3001 +
  1.3002 +   Result:     OK - fetch completed
  1.3003 +               NO - fetch error: can't fetch that data
  1.3004 +               BAD - command unknown or arguments invalid
  1.3005 +
  1.3006 +      The FETCH command retrieves data associated with a message in the
  1.3007 +      mailbox.  The data items to be fetched can be either a single atom
  1.3008 +      or a parenthesized list.
  1.3009 +
  1.3010 +      Most data items, identified in the formal syntax under the
  1.3011 +      msg-att-static rule, are static and MUST NOT change for any
  1.3012 +      particular message.  Other data items, identified in the formal
  1.3013 +      syntax under the msg-att-dynamic rule, MAY change, either as a
  1.3014 +      result of a STORE command or due to external events.
  1.3015 +
  1.3016 +           For example, if a client receives an ENVELOPE for a
  1.3017 +           message when it already knows the envelope, it can
  1.3018 +           safely ignore the newly transmitted envelope.
  1.3019 +
  1.3020 +      There are three macros which specify commonly-used sets of data
  1.3021 +      items, and can be used instead of data items.  A macro must be
  1.3022 +      used by itself, and not in conjunction with other macros or data
  1.3023 +      items.
  1.3024 +
  1.3025 +
  1.3026 +
  1.3027 +
  1.3028 +
  1.3029 +Crispin                     Standards Track                    [Page 54]
  1.3030 +
  1.3031 +RFC 3501                         IMAPv4                       March 2003
  1.3032 +
  1.3033 +
  1.3034 +      ALL
  1.3035 +         Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)
  1.3036 +
  1.3037 +      FAST
  1.3038 +         Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE)
  1.3039 +
  1.3040 +      FULL
  1.3041 +         Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE
  1.3042 +         BODY)
  1.3043 +
  1.3044 +      The currently defined data items that can be fetched are:
  1.3045 +
  1.3046 +      BODY
  1.3047 +         Non-extensible form of BODYSTRUCTURE.
  1.3048 +
  1.3049 +      BODY[<section>]<<partial>>
  1.3050 +         The text of a particular body section.  The section
  1.3051 +         specification is a set of zero or more part specifiers
  1.3052 +         delimited by periods.  A part specifier is either a part number
  1.3053 +         or one of the following: HEADER, HEADER.FIELDS,
  1.3054 +         HEADER.FIELDS.NOT, MIME, and TEXT.  An empty section
  1.3055 +         specification refers to the entire message, including the
  1.3056 +         header.
  1.3057 +
  1.3058 +         Every message has at least one part number.  Non-[MIME-IMB]
  1.3059 +         messages, and non-multipart [MIME-IMB] messages with no
  1.3060 +         encapsulated message, only have a part 1.
  1.3061 +
  1.3062 +         Multipart messages are assigned consecutive part numbers, as
  1.3063 +         they occur in the message.  If a particular part is of type
  1.3064 +         message or multipart, its parts MUST be indicated by a period
  1.3065 +         followed by the part number within that nested multipart part.
  1.3066 +
  1.3067 +         A part of type MESSAGE/RFC822 also has nested part numbers,
  1.3068 +         referring to parts of the MESSAGE part's body.
  1.3069 +
  1.3070 +         The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, and TEXT part
  1.3071 +         specifiers can be the sole part specifier or can be prefixed by
  1.3072 +         one or more numeric part specifiers, provided that the numeric
  1.3073 +         part specifier refers to a part of type MESSAGE/RFC822.  The
  1.3074 +         MIME part specifier MUST be prefixed by one or more numeric
  1.3075 +         part specifiers.
  1.3076 +
  1.3077 +         The HEADER, HEADER.FIELDS, and HEADER.FIELDS.NOT part
  1.3078 +         specifiers refer to the [RFC-2822] header of the message or of
  1.3079 +         an encapsulated [MIME-IMT] MESSAGE/RFC822 message.
  1.3080 +         HEADER.FIELDS and HEADER.FIELDS.NOT are followed by a list of
  1.3081 +         field-name (as defined in [RFC-2822]) names, and return a
  1.3082 +
  1.3083 +
  1.3084 +
  1.3085 +Crispin                     Standards Track                    [Page 55]
  1.3086 +
  1.3087 +RFC 3501                         IMAPv4                       March 2003
  1.3088 +
  1.3089 +
  1.3090 +         subset of the header.  The subset returned by HEADER.FIELDS
  1.3091 +         contains only those header fields with a field-name that
  1.3092 +         matches one of the names in the list; similarly, the subset
  1.3093 +         returned by HEADER.FIELDS.NOT contains only the header fields
  1.3094 +         with a non-matching field-name.  The field-matching is
  1.3095 +         case-insensitive but otherwise exact.  Subsetting does not
  1.3096 +         exclude the [RFC-2822] delimiting blank line between the header
  1.3097 +         and the body; the blank line is included in all header fetches,
  1.3098 +         except in the case of a message which has no body and no blank
  1.3099 +         line.
  1.3100 +
  1.3101 +         The MIME part specifier refers to the [MIME-IMB] header for
  1.3102 +         this part.
  1.3103 +
  1.3104 +         The TEXT part specifier refers to the text body of the message,
  1.3105 +         omitting the [RFC-2822] header.
  1.3106 +
  1.3107 +            Here is an example of a complex message with some of its
  1.3108 +            part specifiers:
  1.3109 +
  1.3110 +       HEADER     ([RFC-2822] header of the message)
  1.3111 +       TEXT       ([RFC-2822] text body of the message) MULTIPART/MIXED
  1.3112 +       1          TEXT/PLAIN
  1.3113 +       2          APPLICATION/OCTET-STREAM
  1.3114 +       3          MESSAGE/RFC822
  1.3115 +       3.HEADER   ([RFC-2822] header of the message)
  1.3116 +       3.TEXT     ([RFC-2822] text body of the message) MULTIPART/MIXED
  1.3117 +       3.1        TEXT/PLAIN
  1.3118 +       3.2        APPLICATION/OCTET-STREAM
  1.3119 +       4          MULTIPART/MIXED
  1.3120 +       4.1        IMAGE/GIF
  1.3121 +       4.1.MIME   ([MIME-IMB] header for the IMAGE/GIF)
  1.3122 +       4.2        MESSAGE/RFC822
  1.3123 +       4.2.HEADER ([RFC-2822] header of the message)
  1.3124 +       4.2.TEXT   ([RFC-2822] text body of the message) MULTIPART/MIXED
  1.3125 +       4.2.1      TEXT/PLAIN
  1.3126 +       4.2.2      MULTIPART/ALTERNATIVE
  1.3127 +       4.2.2.1    TEXT/PLAIN
  1.3128 +       4.2.2.2    TEXT/RICHTEXT
  1.3129 +
  1.3130 +
  1.3131 +         It is possible to fetch a substring of the designated text.
  1.3132 +         This is done by appending an open angle bracket ("<"), the
  1.3133 +         octet position of the first desired octet, a period, the
  1.3134 +         maximum number of octets desired, and a close angle bracket
  1.3135 +         (">") to the part specifier.  If the starting octet is beyond
  1.3136 +         the end of the text, an empty string is returned.
  1.3137 +
  1.3138 +
  1.3139 +
  1.3140 +
  1.3141 +Crispin                     Standards Track                    [Page 56]
  1.3142 +
  1.3143 +RFC 3501                         IMAPv4                       March 2003
  1.3144 +
  1.3145 +
  1.3146 +         Any partial fetch that attempts to read beyond the end of the
  1.3147 +         text is truncated as appropriate.  A partial fetch that starts
  1.3148 +         at octet 0 is returned as a partial fetch, even if this
  1.3149 +         truncation happened.
  1.3150 +
  1.3151 +            Note: This means that BODY[]<0.2048> of a 1500-octet message
  1.3152 +            will return BODY[]<0> with a literal of size 1500, not
  1.3153 +            BODY[].
  1.3154 +
  1.3155 +            Note: A substring fetch of a HEADER.FIELDS or
  1.3156 +            HEADER.FIELDS.NOT part specifier is calculated after
  1.3157 +            subsetting the header.
  1.3158 +
  1.3159 +         The \Seen flag is implicitly set; if this causes the flags to
  1.3160 +         change, they SHOULD be included as part of the FETCH responses.
  1.3161 +
  1.3162 +      BODY.PEEK[<section>]<<partial>>
  1.3163 +         An alternate form of BODY[<section>] that does not implicitly
  1.3164 +         set the \Seen flag.
  1.3165 +
  1.3166 +      BODYSTRUCTURE
  1.3167 +         The [MIME-IMB] body structure of the message.  This is computed
  1.3168 +         by the server by parsing the [MIME-IMB] header fields in the
  1.3169 +         [RFC-2822] header and [MIME-IMB] headers.
  1.3170 +
  1.3171 +      ENVELOPE
  1.3172 +         The envelope structure of the message.  This is computed by the
  1.3173 +         server by parsing the [RFC-2822] header into the component
  1.3174 +         parts, defaulting various fields as necessary.
  1.3175 +
  1.3176 +      FLAGS
  1.3177 +         The flags that are set for this message.
  1.3178 +
  1.3179 +      INTERNALDATE
  1.3180 +         The internal date of the message.
  1.3181 +
  1.3182 +      RFC822
  1.3183 +         Functionally equivalent to BODY[], differing in the syntax of
  1.3184 +         the resulting untagged FETCH data (RFC822 is returned).
  1.3185 +
  1.3186 +      RFC822.HEADER
  1.3187 +         Functionally equivalent to BODY.PEEK[HEADER], differing in the
  1.3188 +         syntax of the resulting untagged FETCH data (RFC822.HEADER is
  1.3189 +         returned).
  1.3190 +
  1.3191 +      RFC822.SIZE
  1.3192 +         The [RFC-2822] size of the message.
  1.3193 +
  1.3194 +
  1.3195 +
  1.3196 +
  1.3197 +Crispin                     Standards Track                    [Page 57]
  1.3198 +
  1.3199 +RFC 3501                         IMAPv4                       March 2003
  1.3200 +
  1.3201 +
  1.3202 +      RFC822.TEXT
  1.3203 +         Functionally equivalent to BODY[TEXT], differing in the syntax
  1.3204 +         of the resulting untagged FETCH data (RFC822.TEXT is returned).
  1.3205 +
  1.3206 +      UID
  1.3207 +         The unique identifier for the message.
  1.3208 +
  1.3209 +
  1.3210 +   Example:    C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)])
  1.3211 +               S: * 2 FETCH ....
  1.3212 +               S: * 3 FETCH ....
  1.3213 +               S: * 4 FETCH ....
  1.3214 +               S: A654 OK FETCH completed
  1.3215 +
  1.3216 +
  1.3217 +6.4.6.  STORE Command
  1.3218 +
  1.3219 +   Arguments:  sequence set
  1.3220 +               message data item name
  1.3221 +               value for message data item
  1.3222 +
  1.3223 +   Responses:  untagged responses: FETCH
  1.3224 +
  1.3225 +   Result:     OK - store completed
  1.3226 +               NO - store error: can't store that data
  1.3227 +               BAD - command unknown or arguments invalid
  1.3228 +
  1.3229 +      The STORE command alters data associated with a message in the
  1.3230 +      mailbox.  Normally, STORE will return the updated value of the
  1.3231 +      data with an untagged FETCH response.  A suffix of ".SILENT" in
  1.3232 +      the data item name prevents the untagged FETCH, and the server
  1.3233 +      SHOULD assume that the client has determined the updated value
  1.3234 +      itself or does not care about the updated value.
  1.3235 +
  1.3236 +           Note: Regardless of whether or not the ".SILENT" suffix
  1.3237 +           was used, the server SHOULD send an untagged FETCH
  1.3238 +           response if a change to a message's flags from an
  1.3239 +           external source is observed.  The intent is that the
  1.3240 +           status of the flags is determinate without a race
  1.3241 +           condition.
  1.3242 +
  1.3243 +
  1.3244 +
  1.3245 +
  1.3246 +
  1.3247 +
  1.3248 +
  1.3249 +
  1.3250 +
  1.3251 +
  1.3252 +
  1.3253 +Crispin                     Standards Track                    [Page 58]
  1.3254 +
  1.3255 +RFC 3501                         IMAPv4                       March 2003
  1.3256 +
  1.3257 +
  1.3258 +      The currently defined data items that can be stored are:
  1.3259 +
  1.3260 +      FLAGS <flag list>
  1.3261 +         Replace the flags for the message (other than \Recent) with the
  1.3262 +         argument.  The new value of the flags is returned as if a FETCH
  1.3263 +         of those flags was done.
  1.3264 +
  1.3265 +      FLAGS.SILENT <flag list>
  1.3266 +         Equivalent to FLAGS, but without returning a new value.
  1.3267 +
  1.3268 +      +FLAGS <flag list>
  1.3269 +         Add the argument to the flags for the message.  The new value
  1.3270 +         of the flags is returned as if a FETCH of those flags was done.
  1.3271 +
  1.3272 +      +FLAGS.SILENT <flag list>
  1.3273 +         Equivalent to +FLAGS, but without returning a new value.
  1.3274 +
  1.3275 +      -FLAGS <flag list>
  1.3276 +         Remove the argument from the flags for the message.  The new
  1.3277 +         value of the flags is returned as if a FETCH of those flags was
  1.3278 +         done.
  1.3279 +
  1.3280 +      -FLAGS.SILENT <flag list>
  1.3281 +         Equivalent to -FLAGS, but without returning a new value.
  1.3282 +
  1.3283 +
  1.3284 +   Example:    C: A003 STORE 2:4 +FLAGS (\Deleted)
  1.3285 +               S: * 2 FETCH (FLAGS (\Deleted \Seen))
  1.3286 +               S: * 3 FETCH (FLAGS (\Deleted))
  1.3287 +               S: * 4 FETCH (FLAGS (\Deleted \Flagged \Seen))
  1.3288 +               S: A003 OK STORE completed
  1.3289 +
  1.3290 +
  1.3291 +6.4.7.  COPY Command
  1.3292 +
  1.3293 +   Arguments:  sequence set
  1.3294 +               mailbox name
  1.3295 +
  1.3296 +   Responses:  no specific responses for this command
  1.3297 +
  1.3298 +   Result:     OK - copy completed
  1.3299 +               NO - copy error: can't copy those messages or to that
  1.3300 +                    name
  1.3301 +               BAD - command unknown or arguments invalid
  1.3302 +
  1.3303 +
  1.3304 +
  1.3305 +
  1.3306 +
  1.3307 +
  1.3308 +
  1.3309 +Crispin                     Standards Track                    [Page 59]
  1.3310 +
  1.3311 +RFC 3501                         IMAPv4                       March 2003
  1.3312 +
  1.3313 +
  1.3314 +      The COPY command copies the specified message(s) to the end of the
  1.3315 +      specified destination mailbox.  The flags and internal date of the
  1.3316 +      message(s) SHOULD be preserved, and the Recent flag SHOULD be set,
  1.3317 +      in the copy.
  1.3318 +
  1.3319 +      If the destination mailbox does not exist, a server SHOULD return
  1.3320 +      an error.  It SHOULD NOT automatically create the mailbox.  Unless
  1.3321 +      it is certain that the destination mailbox can not be created, the
  1.3322 +      server MUST send the response code "[TRYCREATE]" as the prefix of
  1.3323 +      the text of the tagged NO response.  This gives a hint to the
  1.3324 +      client that it can attempt a CREATE command and retry the COPY if
  1.3325 +      the CREATE is successful.
  1.3326 +
  1.3327 +      If the COPY command is unsuccessful for any reason, server
  1.3328 +      implementations MUST restore the destination mailbox to its state
  1.3329 +      before the COPY attempt.
  1.3330 +
  1.3331 +   Example:    C: A003 COPY 2:4 MEETING
  1.3332 +               S: A003 OK COPY completed
  1.3333 +
  1.3334 +
  1.3335 +6.4.8.  UID Command
  1.3336 +
  1.3337 +   Arguments:  command name
  1.3338 +               command arguments
  1.3339 +
  1.3340 +   Responses:  untagged responses: FETCH, SEARCH
  1.3341 +
  1.3342 +   Result:     OK - UID command completed
  1.3343 +               NO - UID command error
  1.3344 +               BAD - command unknown or arguments invalid
  1.3345 +
  1.3346 +      The UID command has two forms.  In the first form, it takes as its
  1.3347 +      arguments a COPY, FETCH, or STORE command with arguments
  1.3348 +      appropriate for the associated command.  However, the numbers in
  1.3349 +      the sequence set argument are unique identifiers instead of
  1.3350 +      message sequence numbers.  Sequence set ranges are permitted, but
  1.3351 +      there is no guarantee that unique identifiers will be contiguous.
  1.3352 +
  1.3353 +      A non-existent unique identifier is ignored without any error
  1.3354 +      message generated.  Thus, it is possible for a UID FETCH command
  1.3355 +      to return an OK without any data or a UID COPY or UID STORE to
  1.3356 +      return an OK without performing any operations.
  1.3357 +
  1.3358 +      In the second form, the UID command takes a SEARCH command with
  1.3359 +      SEARCH command arguments.  The interpretation of the arguments is
  1.3360 +      the same as with SEARCH; however, the numbers returned in a SEARCH
  1.3361 +      response for a UID SEARCH command are unique identifiers instead
  1.3362 +
  1.3363 +
  1.3364 +
  1.3365 +Crispin                     Standards Track                    [Page 60]
  1.3366 +
  1.3367 +RFC 3501                         IMAPv4                       March 2003
  1.3368 +
  1.3369 +
  1.3370 +      of message sequence numbers.  For example, the command UID SEARCH
  1.3371 +      1:100 UID 443:557 returns the unique identifiers corresponding to
  1.3372 +      the intersection of two sequence sets, the message sequence number
  1.3373 +      range 1:100 and the UID range 443:557.
  1.3374 +
  1.3375 +           Note: in the above example, the UID range 443:557
  1.3376 +           appears.  The same comment about a non-existent unique
  1.3377 +           identifier being ignored without any error message also
  1.3378 +           applies here.  Hence, even if neither UID 443 or 557
  1.3379 +           exist, this range is valid and would include an existing
  1.3380 +           UID 495.
  1.3381 +
  1.3382 +           Also note that a UID range of 559:* always includes the
  1.3383 +           UID of the last message in the mailbox, even if 559 is
  1.3384 +           higher than any assigned UID value.  This is because the
  1.3385 +           contents of a range are independent of the order of the
  1.3386 +           range endpoints.  Thus, any UID range with * as one of
  1.3387 +           the endpoints indicates at least one message (the
  1.3388 +           message with the highest numbered UID), unless the
  1.3389 +           mailbox is empty.
  1.3390 +
  1.3391 +      The number after the "*" in an untagged FETCH response is always a
  1.3392 +      message sequence number, not a unique identifier, even for a UID
  1.3393 +      command response.  However, server implementations MUST implicitly
  1.3394 +      include the UID message data item as part of any FETCH response
  1.3395 +      caused by a UID command, regardless of whether a UID was specified
  1.3396 +      as a message data item to the FETCH.
  1.3397 +
  1.3398 +
  1.3399 +      Note: The rule about including the UID message data item as part
  1.3400 +      of a FETCH response primarily applies to the UID FETCH and UID
  1.3401 +      STORE commands, including a UID FETCH command that does not
  1.3402 +      include UID as a message data item.  Although it is unlikely that
  1.3403 +      the other UID commands will cause an untagged FETCH, this rule
  1.3404 +      applies to these commands as well.
  1.3405 +
  1.3406 +   Example:    C: A999 UID FETCH 4827313:4828442 FLAGS
  1.3407 +               S: * 23 FETCH (FLAGS (\Seen) UID 4827313)
  1.3408 +               S: * 24 FETCH (FLAGS (\Seen) UID 4827943)
  1.3409 +               S: * 25 FETCH (FLAGS (\Seen) UID 4828442)
  1.3410 +               S: A999 OK UID FETCH completed
  1.3411 +
  1.3412 +
  1.3413 +
  1.3414 +
  1.3415 +
  1.3416 +
  1.3417 +
  1.3418 +
  1.3419 +
  1.3420 +
  1.3421 +Crispin                     Standards Track                    [Page 61]
  1.3422 +
  1.3423 +RFC 3501                         IMAPv4                       March 2003
  1.3424 +
  1.3425 +
  1.3426 +6.5.    Client Commands - Experimental/Expansion
  1.3427 +
  1.3428 +
  1.3429 +6.5.1.  X<atom> Command
  1.3430 +
  1.3431 +   Arguments:  implementation defined
  1.3432 +
  1.3433 +   Responses:  implementation defined
  1.3434 +
  1.3435 +   Result:     OK - command completed
  1.3436 +               NO - failure
  1.3437 +               BAD - command unknown or arguments invalid
  1.3438 +
  1.3439 +      Any command prefixed with an X is an experimental command.
  1.3440 +      Commands which are not part of this specification, a standard or
  1.3441 +      standards-track revision of this specification, or an
  1.3442 +      IESG-approved experimental protocol, MUST use the X prefix.
  1.3443 +
  1.3444 +      Any added untagged responses issued by an experimental command
  1.3445 +      MUST also be prefixed with an X.  Server implementations MUST NOT
  1.3446 +      send any such untagged responses, unless the client requested it
  1.3447 +      by issuing the associated experimental command.
  1.3448 +
  1.3449 +   Example:    C: a441 CAPABILITY
  1.3450 +               S: * CAPABILITY IMAP4rev1 XPIG-LATIN
  1.3451 +               S: a441 OK CAPABILITY completed
  1.3452 +               C: A442 XPIG-LATIN
  1.3453 +               S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay
  1.3454 +               S: A442 OK XPIG-LATIN ompleted-cay
  1.3455 +
  1.3456 +7.      Server Responses
  1.3457 +
  1.3458 +   Server responses are in three forms: status responses, server data,
  1.3459 +   and command continuation request.  The information contained in a
  1.3460 +   server response, identified by "Contents:" in the response
  1.3461 +   descriptions below, is described by function, not by syntax.  The
  1.3462 +   precise syntax of server responses is described in the Formal Syntax
  1.3463 +   section.
  1.3464 +
  1.3465 +   The client MUST be prepared to accept any response at all times.
  1.3466 +
  1.3467 +   Status responses can be tagged or untagged.  Tagged status responses
  1.3468 +   indicate the completion result (OK, NO, or BAD status) of a client
  1.3469 +   command, and have a tag matching the command.
  1.3470 +
  1.3471 +   Some status responses, and all server data, are untagged.  An
  1.3472 +   untagged response is indicated by the token "*" instead of a tag.
  1.3473 +   Untagged status responses indicate server greeting, or server status
  1.3474 +
  1.3475 +
  1.3476 +
  1.3477 +Crispin                     Standards Track                    [Page 62]
  1.3478 +
  1.3479 +RFC 3501                         IMAPv4                       March 2003
  1.3480 +
  1.3481 +
  1.3482 +   that does not indicate the completion of a command (for example, an
  1.3483 +   impending system shutdown alert).  For historical reasons, untagged
  1.3484 +   server data responses are also called "unsolicited data", although
  1.3485 +   strictly speaking, only unilateral server data is truly
  1.3486 +   "unsolicited".
  1.3487 +
  1.3488 +   Certain server data MUST be recorded by the client when it is
  1.3489 +   received; this is noted in the description of that data.  Such data
  1.3490 +   conveys critical information which affects the interpretation of all
  1.3491 +   subsequent commands and responses (e.g., updates reflecting the
  1.3492 +   creation or destruction of messages).
  1.3493 +
  1.3494 +   Other server data SHOULD be recorded for later reference; if the
  1.3495 +   client does not need to record the data, or if recording the data has
  1.3496 +   no obvious purpose (e.g., a SEARCH response when no SEARCH command is
  1.3497 +   in progress), the data SHOULD be ignored.
  1.3498 +
  1.3499 +   An example of unilateral untagged server data occurs when the IMAP
  1.3500 +   connection is in the selected state.  In the selected state, the
  1.3501 +   server checks the mailbox for new messages as part of command
  1.3502 +   execution.  Normally, this is part of the execution of every command;
  1.3503 +   hence, a NOOP command suffices to check for new messages.  If new
  1.3504 +   messages are found, the server sends untagged EXISTS and RECENT
  1.3505 +   responses reflecting the new size of the mailbox.  Server
  1.3506 +   implementations that offer multiple simultaneous access to the same
  1.3507 +   mailbox SHOULD also send appropriate unilateral untagged FETCH and
  1.3508 +   EXPUNGE responses if another agent changes the state of any message
  1.3509 +   flags or expunges any messages.
  1.3510 +
  1.3511 +   Command continuation request responses use the token "+" instead of a
  1.3512 +   tag.  These responses are sent by the server to indicate acceptance
  1.3513 +   of an incomplete client command and readiness for the remainder of
  1.3514 +   the command.
  1.3515 +
  1.3516 +7.1.    Server Responses - Status Responses
  1.3517 +
  1.3518 +   Status responses are OK, NO, BAD, PREAUTH and BYE.  OK, NO, and BAD
  1.3519 +   can be tagged or untagged.  PREAUTH and BYE are always untagged.
  1.3520 +
  1.3521 +   Status responses MAY include an OPTIONAL "response code".  A response
  1.3522 +   code consists of data inside square brackets in the form of an atom,
  1.3523 +   possibly followed by a space and arguments.  The response code
  1.3524 +   contains additional information or status codes for client software
  1.3525 +   beyond the OK/NO/BAD condition, and are defined when there is a
  1.3526 +   specific action that a client can take based upon the additional
  1.3527 +   information.
  1.3528 +
  1.3529 +
  1.3530 +
  1.3531 +
  1.3532 +
  1.3533 +Crispin                     Standards Track                    [Page 63]
  1.3534 +
  1.3535 +RFC 3501                         IMAPv4                       March 2003
  1.3536 +
  1.3537 +
  1.3538 +   The currently defined response codes are:
  1.3539 +
  1.3540 +      ALERT
  1.3541 +
  1.3542 +         The human-readable text contains a special alert that MUST be
  1.3543 +         presented to the user in a fashion that calls the user's
  1.3544 +         attention to the message.
  1.3545 +
  1.3546 +      BADCHARSET
  1.3547 +
  1.3548 +         Optionally followed by a parenthesized list of charsets.  A
  1.3549 +         SEARCH failed because the given charset is not supported by
  1.3550 +         this implementation.  If the optional list of charsets is
  1.3551 +         given, this lists the charsets that are supported by this
  1.3552 +         implementation.
  1.3553 +
  1.3554 +      CAPABILITY
  1.3555 +
  1.3556 +         Followed by a list of capabilities.  This can appear in the
  1.3557 +         initial OK or PREAUTH response to transmit an initial
  1.3558 +         capabilities list.  This makes it unnecessary for a client to
  1.3559 +         send a separate CAPABILITY command if it recognizes this
  1.3560 +         response.
  1.3561 +
  1.3562 +      PARSE
  1.3563 +
  1.3564 +         The human-readable text represents an error in parsing the
  1.3565 +         [RFC-2822] header or [MIME-IMB] headers of a message in the
  1.3566 +         mailbox.
  1.3567 +
  1.3568 +      PERMANENTFLAGS
  1.3569 +
  1.3570 +         Followed by a parenthesized list of flags, indicates which of
  1.3571 +         the known flags the client can change permanently.  Any flags
  1.3572 +         that are in the FLAGS untagged response, but not the
  1.3573 +         PERMANENTFLAGS list, can not be set permanently.  If the client
  1.3574 +         attempts to STORE a flag that is not in the PERMANENTFLAGS
  1.3575 +         list, the server will either ignore the change or store the
  1.3576 +         state change for the remainder of the current session only.
  1.3577 +         The PERMANENTFLAGS list can also include the special flag \*,
  1.3578 +         which indicates that it is possible to create new keywords by
  1.3579 +         attempting to store those flags in the mailbox.
  1.3580 +
  1.3581 +
  1.3582 +
  1.3583 +
  1.3584 +
  1.3585 +
  1.3586 +
  1.3587 +
  1.3588 +
  1.3589 +Crispin                     Standards Track                    [Page 64]
  1.3590 +
  1.3591 +RFC 3501                         IMAPv4                       March 2003
  1.3592 +
  1.3593 +
  1.3594 +      READ-ONLY
  1.3595 +
  1.3596 +         The mailbox is selected read-only, or its access while selected
  1.3597 +         has changed from read-write to read-only.
  1.3598 +
  1.3599 +      READ-WRITE
  1.3600 +
  1.3601 +         The mailbox is selected read-write, or its access while
  1.3602 +         selected has changed from read-only to read-write.
  1.3603 +
  1.3604 +      TRYCREATE
  1.3605 +
  1.3606 +         An APPEND or COPY attempt is failing because the target mailbox
  1.3607 +         does not exist (as opposed to some other reason).  This is a
  1.3608 +         hint to the client that the operation can succeed if the
  1.3609 +         mailbox is first created by the CREATE command.
  1.3610 +
  1.3611 +      UIDNEXT
  1.3612 +
  1.3613 +         Followed by a decimal number, indicates the next unique
  1.3614 +         identifier value.  Refer to section 2.3.1.1 for more
  1.3615 +         information.
  1.3616 +
  1.3617 +      UIDVALIDITY
  1.3618 +
  1.3619 +         Followed by a decimal number, indicates the unique identifier
  1.3620 +         validity value.  Refer to section 2.3.1.1 for more information.
  1.3621 +
  1.3622 +      UNSEEN
  1.3623 +
  1.3624 +         Followed by a decimal number, indicates the number of the first
  1.3625 +         message without the \Seen flag set.
  1.3626 +
  1.3627 +      Additional response codes defined by particular client or server
  1.3628 +      implementations SHOULD be prefixed with an "X" until they are
  1.3629 +      added to a revision of this protocol.  Client implementations
  1.3630 +      SHOULD ignore response codes that they do not recognize.
  1.3631 +
  1.3632 +7.1.1.  OK Response
  1.3633 +
  1.3634 +   Contents:   OPTIONAL response code
  1.3635 +               human-readable text
  1.3636 +
  1.3637 +      The OK response indicates an information message from the server.
  1.3638 +      When tagged, it indicates successful completion of the associated
  1.3639 +      command.  The human-readable text MAY be presented to the user as
  1.3640 +      an information message.  The untagged form indicates an
  1.3641 +
  1.3642 +
  1.3643 +
  1.3644 +
  1.3645 +Crispin                     Standards Track                    [Page 65]
  1.3646 +
  1.3647 +RFC 3501                         IMAPv4                       March 2003
  1.3648 +
  1.3649 +
  1.3650 +      information-only message; the nature of the information MAY be
  1.3651 +      indicated by a response code.
  1.3652 +
  1.3653 +      The untagged form is also used as one of three possible greetings
  1.3654 +      at connection startup.  It indicates that the connection is not
  1.3655 +      yet authenticated and that a LOGIN command is needed.
  1.3656 +
  1.3657 +   Example:    S: * OK IMAP4rev1 server ready
  1.3658 +               C: A001 LOGIN fred blurdybloop
  1.3659 +               S: * OK [ALERT] System shutdown in 10 minutes
  1.3660 +               S: A001 OK LOGIN Completed
  1.3661 +
  1.3662 +
  1.3663 +7.1.2.  NO Response
  1.3664 +
  1.3665 +   Contents:   OPTIONAL response code
  1.3666 +               human-readable text
  1.3667 +
  1.3668 +      The NO response indicates an operational error message from the
  1.3669 +      server.  When tagged, it indicates unsuccessful completion of the
  1.3670 +      associated command.  The untagged form indicates a warning; the
  1.3671 +      command can still complete successfully.  The human-readable text
  1.3672 +      describes the condition.
  1.3673 +
  1.3674 +   Example:    C: A222 COPY 1:2 owatagusiam
  1.3675 +               S: * NO Disk is 98% full, please delete unnecessary data
  1.3676 +               S: A222 OK COPY completed
  1.3677 +               C: A223 COPY 3:200 blurdybloop
  1.3678 +               S: * NO Disk is 98% full, please delete unnecessary data
  1.3679 +               S: * NO Disk is 99% full, please delete unnecessary data
  1.3680 +               S: A223 NO COPY failed: disk is full
  1.3681 +
  1.3682 +
  1.3683 +7.1.3.  BAD Response
  1.3684 +
  1.3685 +   Contents:   OPTIONAL response code
  1.3686 +               human-readable text
  1.3687 +
  1.3688 +      The BAD response indicates an error message from the server.  When
  1.3689 +      tagged, it reports a protocol-level error in the client's command;
  1.3690 +      the tag indicates the command that caused the error.  The untagged
  1.3691 +      form indicates a protocol-level error for which the associated
  1.3692 +      command can not be determined; it can also indicate an internal
  1.3693 +      server failure.  The human-readable text describes the condition.
  1.3694 +
  1.3695 +
  1.3696 +
  1.3697 +
  1.3698 +
  1.3699 +
  1.3700 +
  1.3701 +Crispin                     Standards Track                    [Page 66]
  1.3702 +
  1.3703 +RFC 3501                         IMAPv4                       March 2003
  1.3704 +
  1.3705 +
  1.3706 +   Example:    C: ...very long command line...
  1.3707 +               S: * BAD Command line too long
  1.3708 +               C: ...empty line...
  1.3709 +               S: * BAD Empty command line
  1.3710 +               C: A443 EXPUNGE
  1.3711 +               S: * BAD Disk crash, attempting salvage to a new disk!
  1.3712 +               S: * OK Salvage successful, no data lost
  1.3713 +               S: A443 OK Expunge completed
  1.3714 +
  1.3715 +
  1.3716 +7.1.4.  PREAUTH Response
  1.3717 +
  1.3718 +   Contents:   OPTIONAL response code
  1.3719 +               human-readable text
  1.3720 +
  1.3721 +      The PREAUTH response is always untagged, and is one of three
  1.3722 +      possible greetings at connection startup.  It indicates that the
  1.3723 +      connection has already been authenticated by external means; thus
  1.3724 +      no LOGIN command is needed.
  1.3725 +
  1.3726 +   Example:    S: * PREAUTH IMAP4rev1 server logged in as Smith
  1.3727 +
  1.3728 +
  1.3729 +7.1.5.  BYE Response
  1.3730 +
  1.3731 +   Contents:   OPTIONAL response code
  1.3732 +               human-readable text
  1.3733 +
  1.3734 +      The BYE response is always untagged, and indicates that the server
  1.3735 +      is about to close the connection.  The human-readable text MAY be
  1.3736 +      displayed to the user in a status report by the client.  The BYE
  1.3737 +      response is sent under one of four conditions:
  1.3738 +
  1.3739 +         1) as part of a normal logout sequence.  The server will close
  1.3740 +            the connection after sending the tagged OK response to the
  1.3741 +            LOGOUT command.
  1.3742 +
  1.3743 +         2) as a panic shutdown announcement.  The server closes the
  1.3744 +            connection immediately.
  1.3745 +
  1.3746 +         3) as an announcement of an inactivity autologout.  The server
  1.3747 +            closes the connection immediately.
  1.3748 +
  1.3749 +         4) as one of three possible greetings at connection startup,
  1.3750 +            indicating that the server is not willing to accept a
  1.3751 +            connection from this client.  The server closes the
  1.3752 +            connection immediately.
  1.3753 +
  1.3754 +
  1.3755 +
  1.3756 +
  1.3757 +Crispin                     Standards Track                    [Page 67]
  1.3758 +
  1.3759 +RFC 3501                         IMAPv4                       March 2003
  1.3760 +
  1.3761 +
  1.3762 +      The difference between a BYE that occurs as part of a normal
  1.3763 +      LOGOUT sequence (the first case) and a BYE that occurs because of
  1.3764 +      a failure (the other three cases) is that the connection closes
  1.3765 +      immediately in the failure case.  In all cases the client SHOULD
  1.3766 +      continue to read response data from the server until the
  1.3767 +      connection is closed; this will ensure that any pending untagged
  1.3768 +      or completion responses are read and processed.
  1.3769 +
  1.3770 +   Example:    S: * BYE Autologout; idle for too long
  1.3771 +
  1.3772 +7.2.    Server Responses - Server and Mailbox Status
  1.3773 +
  1.3774 +   These responses are always untagged.  This is how server and mailbox
  1.3775 +   status data are transmitted from the server to the client.  Many of
  1.3776 +   these responses typically result from a command with the same name.
  1.3777 +
  1.3778 +7.2.1.  CAPABILITY Response
  1.3779 +
  1.3780 +   Contents:   capability listing
  1.3781 +
  1.3782 +      The CAPABILITY response occurs as a result of a CAPABILITY
  1.3783 +      command.  The capability listing contains a space-separated
  1.3784 +      listing of capability names that the server supports.  The
  1.3785 +      capability listing MUST include the atom "IMAP4rev1".
  1.3786 +
  1.3787 +      In addition, client and server implementations MUST implement the
  1.3788 +      STARTTLS, LOGINDISABLED, and AUTH=PLAIN (described in [IMAP-TLS])
  1.3789 +      capabilities.  See the Security Considerations section for
  1.3790 +      important information.
  1.3791 +
  1.3792 +      A capability name which begins with "AUTH=" indicates that the
  1.3793 +      server supports that particular authentication mechanism.
  1.3794 +
  1.3795 +      The LOGINDISABLED capability indicates that the LOGIN command is
  1.3796 +      disabled, and that the server will respond with a tagged NO
  1.3797 +      response to any attempt to use the LOGIN command even if the user
  1.3798 +      name and password are valid.  An IMAP client MUST NOT issue the
  1.3799 +      LOGIN command if the server advertises the LOGINDISABLED
  1.3800 +      capability.
  1.3801 +
  1.3802 +      Other capability names indicate that the server supports an
  1.3803 +      extension, revision, or amendment to the IMAP4rev1 protocol.
  1.3804 +      Server responses MUST conform to this document until the client
  1.3805 +      issues a command that uses the associated capability.
  1.3806 +
  1.3807 +      Capability names MUST either begin with "X" or be standard or
  1.3808 +      standards-track IMAP4rev1 extensions, revisions, or amendments
  1.3809 +      registered with IANA.  A server MUST NOT offer unregistered or
  1.3810 +
  1.3811 +
  1.3812 +
  1.3813 +Crispin                     Standards Track                    [Page 68]
  1.3814 +
  1.3815 +RFC 3501                         IMAPv4                       March 2003
  1.3816 +
  1.3817 +
  1.3818 +      non-standard capability names, unless such names are prefixed with
  1.3819 +      an "X".
  1.3820 +
  1.3821 +      Client implementations SHOULD NOT require any capability name
  1.3822 +      other than "IMAP4rev1", and MUST ignore any unknown capability
  1.3823 +      names.
  1.3824 +
  1.3825 +      A server MAY send capabilities automatically, by using the
  1.3826 +      CAPABILITY response code in the initial PREAUTH or OK responses,
  1.3827 +      and by sending an updated CAPABILITY response code in the tagged
  1.3828 +      OK response as part of a successful authentication.  It is
  1.3829 +      unnecessary for a client to send a separate CAPABILITY command if
  1.3830 +      it recognizes these automatic capabilities.
  1.3831 +
  1.3832 +   Example:    S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI XPIG-LATIN
  1.3833 +
  1.3834 +
  1.3835 +7.2.2.  LIST Response
  1.3836 +
  1.3837 +   Contents:   name attributes
  1.3838 +               hierarchy delimiter
  1.3839 +               name
  1.3840 +
  1.3841 +      The LIST response occurs as a result of a LIST command.  It
  1.3842 +      returns a single name that matches the LIST specification.  There
  1.3843 +      can be multiple LIST responses for a single LIST command.
  1.3844 +
  1.3845 +      Four name attributes are defined:
  1.3846 +
  1.3847 +      \Noinferiors
  1.3848 +         It is not possible for any child levels of hierarchy to exist
  1.3849 +         under this name; no child levels exist now and none can be
  1.3850 +         created in the future.
  1.3851 +
  1.3852 +      \Noselect
  1.3853 +         It is not possible to use this name as a selectable mailbox.
  1.3854 +
  1.3855 +      \Marked
  1.3856 +         The mailbox has been marked "interesting" by the server; the
  1.3857 +         mailbox probably contains messages that have been added since
  1.3858 +         the last time the mailbox was selected.
  1.3859 +
  1.3860 +      \Unmarked
  1.3861 +         The mailbox does not contain any additional messages since the
  1.3862 +         last time the mailbox was selected.
  1.3863 +
  1.3864 +
  1.3865 +
  1.3866 +
  1.3867 +
  1.3868 +
  1.3869 +Crispin                     Standards Track                    [Page 69]
  1.3870 +
  1.3871 +RFC 3501                         IMAPv4                       March 2003
  1.3872 +
  1.3873 +
  1.3874 +      If it is not feasible for the server to determine whether or not
  1.3875 +      the mailbox is "interesting", or if the name is a \Noselect name,
  1.3876 +      the server SHOULD NOT send either \Marked or \Unmarked.
  1.3877 +
  1.3878 +      The hierarchy delimiter is a character used to delimit levels of
  1.3879 +      hierarchy in a mailbox name.  A client can use it to create child
  1.3880 +      mailboxes, and to search higher or lower levels of naming
  1.3881 +      hierarchy.  All children of a top-level hierarchy node MUST use
  1.3882 +      the same separator character.  A NIL hierarchy delimiter means
  1.3883 +      that no hierarchy exists; the name is a "flat" name.
  1.3884 +
  1.3885 +      The name represents an unambiguous left-to-right hierarchy, and
  1.3886 +      MUST be valid for use as a reference in LIST and LSUB commands.
  1.3887 +      Unless \Noselect is indicated, the name MUST also be valid as an
  1.3888 +      argument for commands, such as SELECT, that accept mailbox names.
  1.3889 +
  1.3890 +   Example:    S: * LIST (\Noselect) "/" ~/Mail/foo
  1.3891 +
  1.3892 +
  1.3893 +7.2.3.  LSUB Response
  1.3894 +
  1.3895 +   Contents:   name attributes
  1.3896 +               hierarchy delimiter
  1.3897 +               name
  1.3898 +
  1.3899 +      The LSUB response occurs as a result of an LSUB command.  It
  1.3900 +      returns a single name that matches the LSUB specification.  There
  1.3901 +      can be multiple LSUB responses for a single LSUB command.  The
  1.3902 +      data is identical in format to the LIST response.
  1.3903 +
  1.3904 +   Example:    S: * LSUB () "." #news.comp.mail.misc
  1.3905 +
  1.3906 +
  1.3907 +7.2.4   STATUS Response
  1.3908 +
  1.3909 +   Contents:   name
  1.3910 +               status parenthesized list
  1.3911 +
  1.3912 +      The STATUS response occurs as a result of an STATUS command.  It
  1.3913 +      returns the mailbox name that matches the STATUS specification and
  1.3914 +      the requested mailbox status information.
  1.3915 +
  1.3916 +   Example:    S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
  1.3917 +
  1.3918 +
  1.3919 +
  1.3920 +
  1.3921 +
  1.3922 +
  1.3923 +
  1.3924 +
  1.3925 +Crispin                     Standards Track                    [Page 70]
  1.3926 +
  1.3927 +RFC 3501                         IMAPv4                       March 2003
  1.3928 +
  1.3929 +
  1.3930 +7.2.5.  SEARCH Response
  1.3931 +
  1.3932 +   Contents:   zero or more numbers
  1.3933 +
  1.3934 +      The SEARCH response occurs as a result of a SEARCH or UID SEARCH
  1.3935 +      command.  The number(s) refer to those messages that match the
  1.3936 +      search criteria.  For SEARCH, these are message sequence numbers;
  1.3937 +      for UID SEARCH, these are unique identifiers.  Each number is
  1.3938 +      delimited by a space.
  1.3939 +
  1.3940 +   Example:    S: * SEARCH 2 3 6
  1.3941 +
  1.3942 +
  1.3943 +7.2.6.  FLAGS Response
  1.3944 +
  1.3945 +   Contents:   flag parenthesized list
  1.3946 +
  1.3947 +      The FLAGS response occurs as a result of a SELECT or EXAMINE
  1.3948 +      command.  The flag parenthesized list identifies the flags (at a
  1.3949 +      minimum, the system-defined flags) that are applicable for this
  1.3950 +      mailbox.  Flags other than the system flags can also exist,
  1.3951 +      depending on server implementation.
  1.3952 +
  1.3953 +      The update from the FLAGS response MUST be recorded by the client.
  1.3954 +
  1.3955 +   Example:    S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
  1.3956 +
  1.3957 +
  1.3958 +7.3.    Server Responses - Mailbox Size
  1.3959 +
  1.3960 +   These responses are always untagged.  This is how changes in the size
  1.3961 +   of the mailbox are transmitted from the server to the client.
  1.3962 +   Immediately following the "*" token is a number that represents a
  1.3963 +   message count.
  1.3964 +
  1.3965 +7.3.1.  EXISTS Response
  1.3966 +
  1.3967 +   Contents:   none
  1.3968 +
  1.3969 +      The EXISTS response reports the number of messages in the mailbox.
  1.3970 +      This response occurs as a result of a SELECT or EXAMINE command,
  1.3971 +      and if the size of the mailbox changes (e.g., new messages).
  1.3972 +
  1.3973 +      The update from the EXISTS response MUST be recorded by the
  1.3974 +      client.
  1.3975 +
  1.3976 +   Example:    S: * 23 EXISTS
  1.3977 +
  1.3978 +
  1.3979 +
  1.3980 +
  1.3981 +Crispin                     Standards Track                    [Page 71]
  1.3982 +
  1.3983 +RFC 3501                         IMAPv4                       March 2003
  1.3984 +
  1.3985 +
  1.3986 +7.3.2.  RECENT Response
  1.3987 +
  1.3988 +   Contents:   none
  1.3989 +
  1.3990 +      The RECENT response reports the number of messages with the
  1.3991 +      \Recent flag set.  This response occurs as a result of a SELECT or
  1.3992 +      EXAMINE command, and if the size of the mailbox changes (e.g., new
  1.3993 +      messages).
  1.3994 +
  1.3995 +           Note: It is not guaranteed that the message sequence
  1.3996 +           numbers of recent messages will be a contiguous range of
  1.3997 +           the highest n messages in the mailbox (where n is the
  1.3998 +           value reported by the RECENT response).  Examples of
  1.3999 +           situations in which this is not the case are: multiple
  1.4000 +           clients having the same mailbox open (the first session
  1.4001 +           to be notified will see it as recent, others will
  1.4002 +           probably see it as non-recent), and when the mailbox is
  1.4003 +           re-ordered by a non-IMAP agent.
  1.4004 +
  1.4005 +           The only reliable way to identify recent messages is to
  1.4006 +           look at message flags to see which have the \Recent flag
  1.4007 +           set, or to do a SEARCH RECENT.
  1.4008 +
  1.4009 +      The update from the RECENT response MUST be recorded by the
  1.4010 +      client.
  1.4011 +
  1.4012 +   Example:    S: * 5 RECENT
  1.4013 +
  1.4014 +
  1.4015 +7.4.    Server Responses - Message Status
  1.4016 +
  1.4017 +   These responses are always untagged.  This is how message data are
  1.4018 +   transmitted from the server to the client, often as a result of a
  1.4019 +   command with the same name.  Immediately following the "*" token is a
  1.4020 +   number that represents a message sequence number.
  1.4021 +
  1.4022 +7.4.1.  EXPUNGE Response
  1.4023 +
  1.4024 +   Contents:   none
  1.4025 +
  1.4026 +      The EXPUNGE response reports that the specified message sequence
  1.4027 +      number has been permanently removed from the mailbox.  The message
  1.4028 +      sequence number for each successive message in the mailbox is
  1.4029 +      immediately decremented by 1, and this decrement is reflected in
  1.4030 +      message sequence numbers in subsequent responses (including other
  1.4031 +      untagged EXPUNGE responses).
  1.4032 +
  1.4033 +
  1.4034 +
  1.4035 +
  1.4036 +
  1.4037 +Crispin                     Standards Track                    [Page 72]
  1.4038 +
  1.4039 +RFC 3501                         IMAPv4                       March 2003
  1.4040 +
  1.4041 +
  1.4042 +      The EXPUNGE response also decrements the number of messages in the
  1.4043 +      mailbox; it is not necessary to send an EXISTS response with the
  1.4044 +      new value.
  1.4045 +
  1.4046 +      As a result of the immediate decrement rule, message sequence
  1.4047 +      numbers that appear in a set of successive EXPUNGE responses
  1.4048 +      depend upon whether the messages are removed starting from lower
  1.4049 +      numbers to higher numbers, or from higher numbers to lower
  1.4050 +      numbers.  For example, if the last 5 messages in a 9-message
  1.4051 +      mailbox are expunged, a "lower to higher" server will send five
  1.4052 +      untagged EXPUNGE responses for message sequence number 5, whereas
  1.4053 +      a "higher to lower server" will send successive untagged EXPUNGE
  1.4054 +      responses for message sequence numbers 9, 8, 7, 6, and 5.
  1.4055 +
  1.4056 +      An EXPUNGE response MUST NOT be sent when no command is in
  1.4057 +      progress, nor while responding to a FETCH, STORE, or SEARCH
  1.4058 +      command.  This rule is necessary to prevent a loss of
  1.4059 +      synchronization of message sequence numbers between client and
  1.4060 +      server.  A command is not "in progress" until the complete command
  1.4061 +      has been received; in particular, a command is not "in progress"
  1.4062 +      during the negotiation of command continuation.
  1.4063 +
  1.4064 +           Note: UID FETCH, UID STORE, and UID SEARCH are different
  1.4065 +           commands from FETCH, STORE, and SEARCH.  An EXPUNGE
  1.4066 +           response MAY be sent during a UID command.
  1.4067 +
  1.4068 +      The update from the EXPUNGE response MUST be recorded by the
  1.4069 +      client.
  1.4070 +
  1.4071 +   Example:    S: * 44 EXPUNGE
  1.4072 +
  1.4073 +
  1.4074 +7.4.2.  FETCH Response
  1.4075 +
  1.4076 +   Contents:   message data
  1.4077 +
  1.4078 +      The FETCH response returns data about a message to the client.
  1.4079 +      The data are pairs of data item names and their values in
  1.4080 +      parentheses.  This response occurs as the result of a FETCH or
  1.4081 +      STORE command, as well as by unilateral server decision (e.g.,
  1.4082 +      flag updates).
  1.4083 +
  1.4084 +      The current data items are:
  1.4085 +
  1.4086 +      BODY
  1.4087 +         A form of BODYSTRUCTURE without extension data.
  1.4088 +
  1.4089 +
  1.4090 +
  1.4091 +
  1.4092 +
  1.4093 +Crispin                     Standards Track                    [Page 73]
  1.4094 +
  1.4095 +RFC 3501                         IMAPv4                       March 2003
  1.4096 +
  1.4097 +
  1.4098 +      BODY[<section>]<<origin octet>>
  1.4099 +         A string expressing the body contents of the specified section.
  1.4100 +         The string SHOULD be interpreted by the client according to the
  1.4101 +         content transfer encoding, body type, and subtype.
  1.4102 +
  1.4103 +         If the origin octet is specified, this string is a substring of
  1.4104 +         the entire body contents, starting at that origin octet.  This
  1.4105 +         means that BODY[]<0> MAY be truncated, but BODY[] is NEVER
  1.4106 +         truncated.
  1.4107 +
  1.4108 +            Note: The origin octet facility MUST NOT be used by a server
  1.4109 +            in a FETCH response unless the client specifically requested
  1.4110 +            it by means of a FETCH of a BODY[<section>]<<partial>> data
  1.4111 +            item.
  1.4112 +
  1.4113 +         8-bit textual data is permitted if a [CHARSET] identifier is
  1.4114 +         part of the body parameter parenthesized list for this section.
  1.4115 +         Note that headers (part specifiers HEADER or MIME, or the
  1.4116 +         header portion of a MESSAGE/RFC822 part), MUST be 7-bit; 8-bit
  1.4117 +         characters are not permitted in headers.  Note also that the
  1.4118 +         [RFC-2822] delimiting blank line between the header and the
  1.4119 +         body is not affected by header line subsetting; the blank line
  1.4120 +         is always included as part of header data, except in the case
  1.4121 +         of a message which has no body and no blank line.
  1.4122 +
  1.4123 +         Non-textual data such as binary data MUST be transfer encoded
  1.4124 +         into a textual form, such as BASE64, prior to being sent to the
  1.4125 +         client.  To derive the original binary data, the client MUST
  1.4126 +         decode the transfer encoded string.
  1.4127 +
  1.4128 +      BODYSTRUCTURE
  1.4129 +         A parenthesized list that describes the [MIME-IMB] body
  1.4130 +         structure of a message.  This is computed by the server by
  1.4131 +         parsing the [MIME-IMB] header fields, defaulting various fields
  1.4132 +         as necessary.
  1.4133 +
  1.4134 +         For example, a simple text message of 48 lines and 2279 octets
  1.4135 +         can have a body structure of: ("TEXT" "PLAIN" ("CHARSET"
  1.4136 +         "US-ASCII") NIL NIL "7BIT" 2279 48)
  1.4137 +
  1.4138 +         Multiple parts are indicated by parenthesis nesting.  Instead
  1.4139 +         of a body type as the first element of the parenthesized list,
  1.4140 +         there is a sequence of one or more nested body structures.  The
  1.4141 +         second element of the parenthesized list is the multipart
  1.4142 +         subtype (mixed, digest, parallel, alternative, etc.).
  1.4143 +
  1.4144 +
  1.4145 +
  1.4146 +
  1.4147 +
  1.4148 +
  1.4149 +Crispin                     Standards Track                    [Page 74]
  1.4150 +
  1.4151 +RFC 3501                         IMAPv4                       March 2003
  1.4152 +
  1.4153 +
  1.4154 +         For example, a two part message consisting of a text and a
  1.4155 +         BASE64-encoded text attachment can have a body structure of:
  1.4156 +         (("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152
  1.4157 +         23)("TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" "cc.diff")
  1.4158 +         "<960723163407.20117h@cac.washington.edu>" "Compiler diff"
  1.4159 +         "BASE64" 4554 73) "MIXED")
  1.4160 +
  1.4161 +         Extension data follows the multipart subtype.  Extension data
  1.4162 +         is never returned with the BODY fetch, but can be returned with
  1.4163 +         a BODYSTRUCTURE fetch.  Extension data, if present, MUST be in
  1.4164 +         the defined order.  The extension data of a multipart body part
  1.4165 +         are in the following order:
  1.4166 +
  1.4167 +         body parameter parenthesized list
  1.4168 +            A parenthesized list of attribute/value pairs [e.g., ("foo"
  1.4169 +            "bar" "baz" "rag") where "bar" is the value of "foo", and
  1.4170 +            "rag" is the value of "baz"] as defined in [MIME-IMB].
  1.4171 +
  1.4172 +         body disposition
  1.4173 +            A parenthesized list, consisting of a disposition type
  1.4174 +            string, followed by a parenthesized list of disposition
  1.4175 +            attribute/value pairs as defined in [DISPOSITION].
  1.4176 +
  1.4177 +         body language
  1.4178 +            A string or parenthesized list giving the body language
  1.4179 +            value as defined in [LANGUAGE-TAGS].
  1.4180 +
  1.4181 +         body location
  1.4182 +            A string list giving the body content URI as defined in
  1.4183 +            [LOCATION].
  1.4184 +
  1.4185 +         Any following extension data are not yet defined in this
  1.4186 +         version of the protocol.  Such extension data can consist of
  1.4187 +         zero or more NILs, strings, numbers, or potentially nested
  1.4188 +         parenthesized lists of such data.  Client implementations that
  1.4189 +         do a BODYSTRUCTURE fetch MUST be prepared to accept such
  1.4190 +         extension data.  Server implementations MUST NOT send such
  1.4191 +         extension data until it has been defined by a revision of this
  1.4192 +         protocol.
  1.4193 +
  1.4194 +         The basic fields of a non-multipart body part are in the
  1.4195 +         following order:
  1.4196 +
  1.4197 +         body type
  1.4198 +            A string giving the content media type name as defined in
  1.4199 +            [MIME-IMB].
  1.4200 +
  1.4201 +
  1.4202 +
  1.4203 +
  1.4204 +
  1.4205 +Crispin                     Standards Track                    [Page 75]
  1.4206 +
  1.4207 +RFC 3501                         IMAPv4                       March 2003
  1.4208 +
  1.4209 +
  1.4210 +         body subtype
  1.4211 +            A string giving the content subtype name as defined in
  1.4212 +            [MIME-IMB].
  1.4213 +
  1.4214 +         body parameter parenthesized list
  1.4215 +            A parenthesized list of attribute/value pairs [e.g., ("foo"
  1.4216 +            "bar" "baz" "rag") where "bar" is the value of "foo" and
  1.4217 +            "rag" is the value of "baz"] as defined in [MIME-IMB].
  1.4218 +
  1.4219 +         body id
  1.4220 +            A string giving the content id as defined in [MIME-IMB].
  1.4221 +
  1.4222 +         body description
  1.4223 +            A string giving the content description as defined in
  1.4224 +            [MIME-IMB].
  1.4225 +
  1.4226 +         body encoding
  1.4227 +            A string giving the content transfer encoding as defined in
  1.4228 +            [MIME-IMB].
  1.4229 +
  1.4230 +         body size
  1.4231 +            A number giving the size of the body in octets.  Note that
  1.4232 +            this size is the size in its transfer encoding and not the
  1.4233 +            resulting size after any decoding.
  1.4234 +
  1.4235 +         A body type of type MESSAGE and subtype RFC822 contains,
  1.4236 +         immediately after the basic fields, the envelope structure,
  1.4237 +         body structure, and size in text lines of the encapsulated
  1.4238 +         message.
  1.4239 +
  1.4240 +         A body type of type TEXT contains, immediately after the basic
  1.4241 +         fields, the size of the body in text lines.  Note that this
  1.4242 +         size is the size in its content transfer encoding and not the
  1.4243 +         resulting size after any decoding.
  1.4244 +
  1.4245 +         Extension data follows the basic fields and the type-specific
  1.4246 +         fields listed above.  Extension data is never returned with the
  1.4247 +         BODY fetch, but can be returned with a BODYSTRUCTURE fetch.
  1.4248 +         Extension data, if present, MUST be in the defined order.
  1.4249 +
  1.4250 +         The extension data of a non-multipart body part are in the
  1.4251 +         following order:
  1.4252 +
  1.4253 +         body MD5
  1.4254 +            A string giving the body MD5 value as defined in [MD5].
  1.4255 +
  1.4256 +
  1.4257 +
  1.4258 +
  1.4259 +
  1.4260 +
  1.4261 +Crispin                     Standards Track                    [Page 76]
  1.4262 +
  1.4263 +RFC 3501                         IMAPv4                       March 2003
  1.4264 +
  1.4265 +
  1.4266 +         body disposition
  1.4267 +            A parenthesized list with the same content and function as
  1.4268 +            the body disposition for a multipart body part.
  1.4269 +
  1.4270 +         body language
  1.4271 +            A string or parenthesized list giving the body language
  1.4272 +            value as defined in [LANGUAGE-TAGS].
  1.4273 +
  1.4274 +         body location
  1.4275 +            A string list giving the body content URI as defined in
  1.4276 +            [LOCATION].
  1.4277 +
  1.4278 +         Any following extension data are not yet defined in this
  1.4279 +         version of the protocol, and would be as described above under
  1.4280 +         multipart extension data.
  1.4281 +
  1.4282 +      ENVELOPE
  1.4283 +         A parenthesized list that describes the envelope structure of a
  1.4284 +         message.  This is computed by the server by parsing the
  1.4285 +         [RFC-2822] header into the component parts, defaulting various
  1.4286 +         fields as necessary.
  1.4287 +
  1.4288 +         The fields of the envelope structure are in the following
  1.4289 +         order: date, subject, from, sender, reply-to, to, cc, bcc,
  1.4290 +         in-reply-to, and message-id.  The date, subject, in-reply-to,
  1.4291 +         and message-id fields are strings.  The from, sender, reply-to,
  1.4292 +         to, cc, and bcc fields are parenthesized lists of address
  1.4293 +         structures.
  1.4294 +
  1.4295 +         An address structure is a parenthesized list that describes an
  1.4296 +         electronic mail address.  The fields of an address structure
  1.4297 +         are in the following order: personal name, [SMTP]
  1.4298 +         at-domain-list (source route), mailbox name, and host name.
  1.4299 +
  1.4300 +         [RFC-2822] group syntax is indicated by a special form of
  1.4301 +         address structure in which the host name field is NIL.  If the
  1.4302 +         mailbox name field is also NIL, this is an end of group marker
  1.4303 +         (semi-colon in RFC 822 syntax).  If the mailbox name field is
  1.4304 +         non-NIL, this is a start of group marker, and the mailbox name
  1.4305 +         field holds the group name phrase.
  1.4306 +
  1.4307 +         If the Date, Subject, In-Reply-To, and Message-ID header lines
  1.4308 +         are absent in the [RFC-2822] header, the corresponding member
  1.4309 +         of the envelope is NIL; if these header lines are present but
  1.4310 +         empty the corresponding member of the envelope is the empty
  1.4311 +         string.
  1.4312 +
  1.4313 +
  1.4314 +
  1.4315 +
  1.4316 +
  1.4317 +Crispin                     Standards Track                    [Page 77]
  1.4318 +
  1.4319 +RFC 3501                         IMAPv4                       March 2003
  1.4320 +
  1.4321 +
  1.4322 +            Note: some servers may return a NIL envelope member in the
  1.4323 +            "present but empty" case.  Clients SHOULD treat NIL and
  1.4324 +            empty string as identical.
  1.4325 +
  1.4326 +            Note: [RFC-2822] requires that all messages have a valid
  1.4327 +            Date header.  Therefore, the date member in the envelope can
  1.4328 +            not be NIL or the empty string.
  1.4329 +
  1.4330 +            Note: [RFC-2822] requires that the In-Reply-To and
  1.4331 +            Message-ID headers, if present, have non-empty content.
  1.4332 +            Therefore, the in-reply-to and message-id members in the
  1.4333 +            envelope can not be the empty string.
  1.4334 +
  1.4335 +         If the From, To, cc, and bcc header lines are absent in the
  1.4336 +         [RFC-2822] header, or are present but empty, the corresponding
  1.4337 +         member of the envelope is NIL.
  1.4338 +
  1.4339 +         If the Sender or Reply-To lines are absent in the [RFC-2822]
  1.4340 +         header, or are present but empty, the server sets the
  1.4341 +         corresponding member of the envelope to be the same value as
  1.4342 +         the from member (the client is not expected to know to do
  1.4343 +         this).
  1.4344 +
  1.4345 +            Note: [RFC-2822] requires that all messages have a valid
  1.4346 +            From header.  Therefore, the from, sender, and reply-to
  1.4347 +            members in the envelope can not be NIL.
  1.4348 +
  1.4349 +      FLAGS
  1.4350 +         A parenthesized list of flags that are set for this message.
  1.4351 +
  1.4352 +      INTERNALDATE
  1.4353 +         A string representing the internal date of the message.
  1.4354 +
  1.4355 +      RFC822
  1.4356 +         Equivalent to BODY[].
  1.4357 +
  1.4358 +      RFC822.HEADER
  1.4359 +         Equivalent to BODY[HEADER].  Note that this did not result in
  1.4360 +         \Seen being set, because RFC822.HEADER response data occurs as
  1.4361 +         a result of a FETCH of RFC822.HEADER.  BODY[HEADER] response
  1.4362 +         data occurs as a result of a FETCH of BODY[HEADER] (which sets
  1.4363 +         \Seen) or BODY.PEEK[HEADER] (which does not set \Seen).
  1.4364 +
  1.4365 +      RFC822.SIZE
  1.4366 +         A number expressing the [RFC-2822] size of the message.
  1.4367 +
  1.4368 +
  1.4369 +
  1.4370 +
  1.4371 +
  1.4372 +
  1.4373 +Crispin                     Standards Track                    [Page 78]
  1.4374 +
  1.4375 +RFC 3501                         IMAPv4                       March 2003
  1.4376 +
  1.4377 +
  1.4378 +      RFC822.TEXT
  1.4379 +         Equivalent to BODY[TEXT].
  1.4380 +
  1.4381 +      UID
  1.4382 +         A number expressing the unique identifier of the message.
  1.4383 +
  1.4384 +
  1.4385 +   Example:    S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827)
  1.4386 +
  1.4387 +
  1.4388 +7.5.    Server Responses - Command Continuation Request
  1.4389 +
  1.4390 +   The command continuation request response is indicated by a "+" token
  1.4391 +   instead of a tag.  This form of response indicates that the server is
  1.4392 +   ready to accept the continuation of a command from the client.  The
  1.4393 +   remainder of this response is a line of text.
  1.4394 +
  1.4395 +   This response is used in the AUTHENTICATE command to transmit server
  1.4396 +   data to the client, and request additional client data.  This
  1.4397 +   response is also used if an argument to any command is a literal.
  1.4398 +
  1.4399 +   The client is not permitted to send the octets of the literal unless
  1.4400 +   the server indicates that it is expected.  This permits the server to
  1.4401 +   process commands and reject errors on a line-by-line basis.  The
  1.4402 +   remainder of the command, including the CRLF that terminates a
  1.4403 +   command, follows the octets of the literal.  If there are any
  1.4404 +   additional command arguments, the literal octets are followed by a
  1.4405 +   space and those arguments.
  1.4406 +
  1.4407 +   Example:    C: A001 LOGIN {11}
  1.4408 +               S: + Ready for additional command text
  1.4409 +               C: FRED FOOBAR {7}
  1.4410 +               S: + Ready for additional command text
  1.4411 +               C: fat man
  1.4412 +               S: A001 OK LOGIN completed
  1.4413 +               C: A044 BLURDYBLOOP {102856}
  1.4414 +               S: A044 BAD No such command as "BLURDYBLOOP"
  1.4415 +
  1.4416 +
  1.4417 +
  1.4418 +
  1.4419 +
  1.4420 +
  1.4421 +
  1.4422 +
  1.4423 +
  1.4424 +
  1.4425 +
  1.4426 +
  1.4427 +
  1.4428 +
  1.4429 +Crispin                     Standards Track                    [Page 79]
  1.4430 +
  1.4431 +RFC 3501                         IMAPv4                       March 2003
  1.4432 +
  1.4433 +
  1.4434 +8.      Sample IMAP4rev1 connection
  1.4435 +
  1.4436 +   The following is a transcript of an IMAP4rev1 connection.  A long
  1.4437 +   line in this sample is broken for editorial clarity.
  1.4438 +
  1.4439 +S:   * OK IMAP4rev1 Service Ready
  1.4440 +C:   a001 login mrc secret
  1.4441 +S:   a001 OK LOGIN completed
  1.4442 +C:   a002 select inbox
  1.4443 +S:   * 18 EXISTS
  1.4444 +S:   * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
  1.4445 +S:   * 2 RECENT
  1.4446 +S:   * OK [UNSEEN 17] Message 17 is the first unseen message
  1.4447 +S:   * OK [UIDVALIDITY 3857529045] UIDs valid
  1.4448 +S:   a002 OK [READ-WRITE] SELECT completed
  1.4449 +C:   a003 fetch 12 full
  1.4450 +S:   * 12 FETCH (FLAGS (\Seen) INTERNALDATE "17-Jul-1996 02:44:25 -0700"
  1.4451 +      RFC822.SIZE 4286 ENVELOPE ("Wed, 17 Jul 1996 02:23:25 -0700 (PDT)"
  1.4452 +      "IMAP4rev1 WG mtg summary and minutes"
  1.4453 +      (("Terry Gray" NIL "gray" "cac.washington.edu"))
  1.4454 +      (("Terry Gray" NIL "gray" "cac.washington.edu"))
  1.4455 +      (("Terry Gray" NIL "gray" "cac.washington.edu"))
  1.4456 +      ((NIL NIL "imap" "cac.washington.edu"))
  1.4457 +      ((NIL NIL "minutes" "CNRI.Reston.VA.US")
  1.4458 +      ("John Klensin" NIL "KLENSIN" "MIT.EDU")) NIL NIL
  1.4459 +      "<B27397-0100000@cac.washington.edu>")
  1.4460 +       BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028
  1.4461 +       92))
  1.4462 +S:    a003 OK FETCH completed
  1.4463 +C:    a004 fetch 12 body[header]
  1.4464 +S:    * 12 FETCH (BODY[HEADER] {342}
  1.4465 +S:    Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)
  1.4466 +S:    From: Terry Gray <gray@cac.washington.edu>
  1.4467 +S:    Subject: IMAP4rev1 WG mtg summary and minutes
  1.4468 +S:    To: imap@cac.washington.edu
  1.4469 +S:    cc: minutes@CNRI.Reston.VA.US, John Klensin <KLENSIN@MIT.EDU>
  1.4470 +S:    Message-Id: <B27397-0100000@cac.washington.edu>
  1.4471 +S:    MIME-Version: 1.0
  1.4472 +S:    Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
  1.4473 +S:
  1.4474 +S:    )
  1.4475 +S:    a004 OK FETCH completed
  1.4476 +C:    a005 store 12 +flags \deleted
  1.4477 +S:    * 12 FETCH (FLAGS (\Seen \Deleted))
  1.4478 +S:    a005 OK +FLAGS completed
  1.4479 +C:    a006 logout
  1.4480 +S:    * BYE IMAP4rev1 server terminating connection
  1.4481 +S:    a006 OK LOGOUT completed
  1.4482 +
  1.4483 +
  1.4484 +
  1.4485 +Crispin                     Standards Track                    [Page 80]
  1.4486 +
  1.4487 +RFC 3501                         IMAPv4                       March 2003
  1.4488 +
  1.4489 +
  1.4490 +9.      Formal Syntax
  1.4491 +
  1.4492 +   The following syntax specification uses the Augmented Backus-Naur
  1.4493 +   Form (ABNF) notation as specified in [ABNF].
  1.4494 +
  1.4495 +   In the case of alternative or optional rules in which a later rule
  1.4496 +   overlaps an earlier rule, the rule which is listed earlier MUST take
  1.4497 +   priority.  For example, "\Seen" when parsed as a flag is the \Seen
  1.4498 +   flag name and not a flag-extension, even though "\Seen" can be parsed
  1.4499 +   as a flag-extension.  Some, but not all, instances of this rule are
  1.4500 +   noted below.
  1.4501 +
  1.4502 +        Note: [ABNF] rules MUST be followed strictly; in
  1.4503 +        particular:
  1.4504 +
  1.4505 +        (1) Except as noted otherwise, all alphabetic characters
  1.4506 +        are case-insensitive.  The use of upper or lower case
  1.4507 +        characters to define token strings is for editorial clarity
  1.4508 +        only.  Implementations MUST accept these strings in a
  1.4509 +        case-insensitive fashion.
  1.4510 +
  1.4511 +        (2) In all cases, SP refers to exactly one space.  It is
  1.4512 +        NOT permitted to substitute TAB, insert additional spaces,
  1.4513 +        or otherwise treat SP as being equivalent to LWSP.
  1.4514 +
  1.4515 +        (3) The ASCII NUL character, %x00, MUST NOT be used at any
  1.4516 +        time.
  1.4517 +
  1.4518 +address         = "(" addr-name SP addr-adl SP addr-mailbox SP
  1.4519 +                  addr-host ")"
  1.4520 +
  1.4521 +addr-adl        = nstring
  1.4522 +                    ; Holds route from [RFC-2822] route-addr if
  1.4523 +                    ; non-NIL
  1.4524 +
  1.4525 +addr-host       = nstring
  1.4526 +                    ; NIL indicates [RFC-2822] group syntax.
  1.4527 +                    ; Otherwise, holds [RFC-2822] domain name
  1.4528 +
  1.4529 +addr-mailbox    = nstring
  1.4530 +                    ; NIL indicates end of [RFC-2822] group; if
  1.4531 +                    ; non-NIL and addr-host is NIL, holds
  1.4532 +                    ; [RFC-2822] group name.
  1.4533 +                    ; Otherwise, holds [RFC-2822] local-part
  1.4534 +                    ; after removing [RFC-2822] quoting
  1.4535 +
  1.4536 +
  1.4537 +
  1.4538 +
  1.4539 +
  1.4540 +
  1.4541 +Crispin                     Standards Track                    [Page 81]
  1.4542 +
  1.4543 +RFC 3501                         IMAPv4                       March 2003
  1.4544 +
  1.4545 +
  1.4546 +addr-name       = nstring
  1.4547 +                    ; If non-NIL, holds phrase from [RFC-2822]
  1.4548 +                    ; mailbox after removing [RFC-2822] quoting
  1.4549 +
  1.4550 +append          = "APPEND" SP mailbox [SP flag-list] [SP date-time] SP
  1.4551 +                  literal
  1.4552 +
  1.4553 +astring         = 1*ASTRING-CHAR / string
  1.4554 +
  1.4555 +ASTRING-CHAR   = ATOM-CHAR / resp-specials
  1.4556 +
  1.4557 +atom            = 1*ATOM-CHAR
  1.4558 +
  1.4559 +ATOM-CHAR       = <any CHAR except atom-specials>
  1.4560 +
  1.4561 +atom-specials   = "(" / ")" / "{" / SP / CTL / list-wildcards /
  1.4562 +                  quoted-specials / resp-specials
  1.4563 +
  1.4564 +authenticate    = "AUTHENTICATE" SP auth-type *(CRLF base64)
  1.4565 +
  1.4566 +auth-type       = atom
  1.4567 +                    ; Defined by [SASL]
  1.4568 +
  1.4569 +base64          = *(4base64-char) [base64-terminal]
  1.4570 +
  1.4571 +base64-char     = ALPHA / DIGIT / "+" / "/"
  1.4572 +                    ; Case-sensitive
  1.4573 +
  1.4574 +base64-terminal = (2base64-char "==") / (3base64-char "=")
  1.4575 +
  1.4576 +body            = "(" (body-type-1part / body-type-mpart) ")"
  1.4577 +
  1.4578 +body-extension  = nstring / number /
  1.4579 +                   "(" body-extension *(SP body-extension) ")"
  1.4580 +                    ; Future expansion.  Client implementations
  1.4581 +                    ; MUST accept body-extension fields.  Server
  1.4582 +                    ; implementations MUST NOT generate
  1.4583 +                    ; body-extension fields except as defined by
  1.4584 +                    ; future standard or standards-track
  1.4585 +                    ; revisions of this specification.
  1.4586 +
  1.4587 +body-ext-1part  = body-fld-md5 [SP body-fld-dsp [SP body-fld-lang
  1.4588 +                  [SP body-fld-loc *(SP body-extension)]]]
  1.4589 +                    ; MUST NOT be returned on non-extensible
  1.4590 +                    ; "BODY" fetch
  1.4591 +
  1.4592 +
  1.4593 +
  1.4594 +
  1.4595 +
  1.4596 +
  1.4597 +Crispin                     Standards Track                    [Page 82]
  1.4598 +
  1.4599 +RFC 3501                         IMAPv4                       March 2003
  1.4600 +
  1.4601 +
  1.4602 +body-ext-mpart  = body-fld-param [SP body-fld-dsp [SP body-fld-lang
  1.4603 +                  [SP body-fld-loc *(SP body-extension)]]]
  1.4604 +                    ; MUST NOT be returned on non-extensible
  1.4605 +                    ; "BODY" fetch
  1.4606 +
  1.4607 +body-fields     = body-fld-param SP body-fld-id SP body-fld-desc SP
  1.4608 +                  body-fld-enc SP body-fld-octets
  1.4609 +
  1.4610 +body-fld-desc   = nstring
  1.4611 +
  1.4612 +body-fld-dsp    = "(" string SP body-fld-param ")" / nil
  1.4613 +
  1.4614 +body-fld-enc    = (DQUOTE ("7BIT" / "8BIT" / "BINARY" / "BASE64"/
  1.4615 +                  "QUOTED-PRINTABLE") DQUOTE) / string
  1.4616 +
  1.4617 +body-fld-id     = nstring
  1.4618 +
  1.4619 +body-fld-lang   = nstring / "(" string *(SP string) ")"
  1.4620 +
  1.4621 +body-fld-loc    = nstring
  1.4622 +
  1.4623 +body-fld-lines  = number
  1.4624 +
  1.4625 +body-fld-md5    = nstring
  1.4626 +
  1.4627 +body-fld-octets = number
  1.4628 +
  1.4629 +body-fld-param  = "(" string SP string *(SP string SP string) ")" / nil
  1.4630 +
  1.4631 +body-type-1part = (body-type-basic / body-type-msg / body-type-text)
  1.4632 +                  [SP body-ext-1part]
  1.4633 +
  1.4634 +body-type-basic = media-basic SP body-fields
  1.4635 +                    ; MESSAGE subtype MUST NOT be "RFC822"
  1.4636 +
  1.4637 +body-type-mpart = 1*body SP media-subtype
  1.4638 +                  [SP body-ext-mpart]
  1.4639 +
  1.4640 +body-type-msg   = media-message SP body-fields SP envelope
  1.4641 +                  SP body SP body-fld-lines
  1.4642 +
  1.4643 +body-type-text  = media-text SP body-fields SP body-fld-lines
  1.4644 +
  1.4645 +capability      = ("AUTH=" auth-type) / atom
  1.4646 +                    ; New capabilities MUST begin with "X" or be
  1.4647 +                    ; registered with IANA as standard or
  1.4648 +                    ; standards-track
  1.4649 +
  1.4650 +
  1.4651 +
  1.4652 +
  1.4653 +Crispin                     Standards Track                    [Page 83]
  1.4654 +
  1.4655 +RFC 3501                         IMAPv4                       March 2003
  1.4656 +
  1.4657 +
  1.4658 +capability-data = "CAPABILITY" *(SP capability) SP "IMAP4rev1"
  1.4659 +                  *(SP capability)
  1.4660 +                    ; Servers MUST implement the STARTTLS, AUTH=PLAIN,
  1.4661 +                    ; and LOGINDISABLED capabilities
  1.4662 +                    ; Servers which offer RFC 1730 compatibility MUST
  1.4663 +                    ; list "IMAP4" as the first capability.
  1.4664 +
  1.4665 +CHAR8           = %x01-ff
  1.4666 +                    ; any OCTET except NUL, %x00
  1.4667 +
  1.4668 +command         = tag SP (command-any / command-auth / command-nonauth /
  1.4669 +                  command-select) CRLF
  1.4670 +                    ; Modal based on state
  1.4671 +
  1.4672 +command-any     = "CAPABILITY" / "LOGOUT" / "NOOP" / x-command
  1.4673 +                    ; Valid in all states
  1.4674 +
  1.4675 +command-auth    = append / create / delete / examine / list / lsub /
  1.4676 +                  rename / select / status / subscribe / unsubscribe
  1.4677 +                    ; Valid only in Authenticated or Selected state
  1.4678 +
  1.4679 +command-nonauth = login / authenticate / "STARTTLS"
  1.4680 +                    ; Valid only when in Not Authenticated state
  1.4681 +
  1.4682 +command-select  = "CHECK" / "CLOSE" / "EXPUNGE" / copy / fetch / store /
  1.4683 +                  uid / search
  1.4684 +                    ; Valid only when in Selected state
  1.4685 +
  1.4686 +continue-req    = "+" SP (resp-text / base64) CRLF
  1.4687 +
  1.4688 +copy            = "COPY" SP sequence-set SP mailbox
  1.4689 +
  1.4690 +create          = "CREATE" SP mailbox
  1.4691 +                    ; Use of INBOX gives a NO error
  1.4692 +
  1.4693 +date            = date-text / DQUOTE date-text DQUOTE
  1.4694 +
  1.4695 +date-day        = 1*2DIGIT
  1.4696 +                    ; Day of month
  1.4697 +
  1.4698 +date-day-fixed  = (SP DIGIT) / 2DIGIT
  1.4699 +                    ; Fixed-format version of date-day
  1.4700 +
  1.4701 +date-month      = "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" /
  1.4702 +                  "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec"
  1.4703 +
  1.4704 +date-text       = date-day "-" date-month "-" date-year
  1.4705 +
  1.4706 +
  1.4707 +
  1.4708 +
  1.4709 +Crispin                     Standards Track                    [Page 84]
  1.4710 +
  1.4711 +RFC 3501                         IMAPv4                       March 2003
  1.4712 +
  1.4713 +
  1.4714 +date-year       = 4DIGIT
  1.4715 +
  1.4716 +date-time       = DQUOTE date-day-fixed "-" date-month "-" date-year
  1.4717 +                  SP time SP zone DQUOTE
  1.4718 +
  1.4719 +delete          = "DELETE" SP mailbox
  1.4720 +                    ; Use of INBOX gives a NO error
  1.4721 +
  1.4722 +digit-nz        = %x31-39
  1.4723 +                    ; 1-9
  1.4724 +
  1.4725 +envelope        = "(" env-date SP env-subject SP env-from SP
  1.4726 +                  env-sender SP env-reply-to SP env-to SP env-cc SP
  1.4727 +                  env-bcc SP env-in-reply-to SP env-message-id ")"
  1.4728 +
  1.4729 +env-bcc         = "(" 1*address ")" / nil
  1.4730 +
  1.4731 +env-cc          = "(" 1*address ")" / nil
  1.4732 +
  1.4733 +env-date        = nstring
  1.4734 +
  1.4735 +env-from        = "(" 1*address ")" / nil
  1.4736 +
  1.4737 +env-in-reply-to = nstring
  1.4738 +
  1.4739 +env-message-id  = nstring
  1.4740 +
  1.4741 +env-reply-to    = "(" 1*address ")" / nil
  1.4742 +
  1.4743 +env-sender      = "(" 1*address ")" / nil
  1.4744 +
  1.4745 +env-subject     = nstring
  1.4746 +
  1.4747 +env-to          = "(" 1*address ")" / nil
  1.4748 +
  1.4749 +examine         = "EXAMINE" SP mailbox
  1.4750 +
  1.4751 +fetch           = "FETCH" SP sequence-set SP ("ALL" / "FULL" / "FAST" /
  1.4752 +                  fetch-att / "(" fetch-att *(SP fetch-att) ")")
  1.4753 +
  1.4754 +fetch-att       = "ENVELOPE" / "FLAGS" / "INTERNALDATE" /
  1.4755 +                  "RFC822" [".HEADER" / ".SIZE" / ".TEXT"] /
  1.4756 +                  "BODY" ["STRUCTURE"] / "UID" /
  1.4757 +                  "BODY" section ["<" number "." nz-number ">"] /
  1.4758 +                  "BODY.PEEK" section ["<" number "." nz-number ">"]
  1.4759 +
  1.4760 +
  1.4761 +
  1.4762 +
  1.4763 +
  1.4764 +
  1.4765 +Crispin                     Standards Track                    [Page 85]
  1.4766 +
  1.4767 +RFC 3501                         IMAPv4                       March 2003
  1.4768 +
  1.4769 +
  1.4770 +flag            = "\Answered" / "\Flagged" / "\Deleted" /
  1.4771 +                  "\Seen" / "\Draft" / flag-keyword / flag-extension
  1.4772 +                    ; Does not include "\Recent"
  1.4773 +
  1.4774 +flag-extension  = "\" atom
  1.4775 +                    ; Future expansion.  Client implementations
  1.4776 +                    ; MUST accept flag-extension flags.  Server
  1.4777 +                    ; implementations MUST NOT generate
  1.4778 +                    ; flag-extension flags except as defined by
  1.4779 +                    ; future standard or standards-track
  1.4780 +                    ; revisions of this specification.
  1.4781 +
  1.4782 +flag-fetch      = flag / "\Recent"
  1.4783 +
  1.4784 +flag-keyword    = atom
  1.4785 +
  1.4786 +flag-list       = "(" [flag *(SP flag)] ")"
  1.4787 +
  1.4788 +flag-perm       = flag / "\*"
  1.4789 +
  1.4790 +greeting        = "*" SP (resp-cond-auth / resp-cond-bye) CRLF
  1.4791 +
  1.4792 +header-fld-name = astring
  1.4793 +
  1.4794 +header-list     = "(" header-fld-name *(SP header-fld-name) ")"
  1.4795 +
  1.4796 +list            = "LIST" SP mailbox SP list-mailbox
  1.4797 +
  1.4798 +list-mailbox    = 1*list-char / string
  1.4799 +
  1.4800 +list-char       = ATOM-CHAR / list-wildcards / resp-specials
  1.4801 +
  1.4802 +list-wildcards  = "%" / "*"
  1.4803 +
  1.4804 +literal         = "{" number "}" CRLF *CHAR8
  1.4805 +                    ; Number represents the number of CHAR8s
  1.4806 +
  1.4807 +login           = "LOGIN" SP userid SP password
  1.4808 +
  1.4809 +lsub            = "LSUB" SP mailbox SP list-mailbox
  1.4810 +
  1.4811 +
  1.4812 +
  1.4813 +
  1.4814 +
  1.4815 +
  1.4816 +
  1.4817 +
  1.4818 +
  1.4819 +
  1.4820 +
  1.4821 +Crispin                     Standards Track                    [Page 86]
  1.4822 +
  1.4823 +RFC 3501                         IMAPv4                       March 2003
  1.4824 +
  1.4825 +
  1.4826 +mailbox         = "INBOX" / astring
  1.4827 +                    ; INBOX is case-insensitive.  All case variants of
  1.4828 +                    ; INBOX (e.g., "iNbOx") MUST be interpreted as INBOX
  1.4829 +                    ; not as an astring.  An astring which consists of
  1.4830 +                    ; the case-insensitive sequence "I" "N" "B" "O" "X"
  1.4831 +                    ; is considered to be INBOX and not an astring.
  1.4832 +                    ;  Refer to section 5.1 for further
  1.4833 +                    ; semantic details of mailbox names.
  1.4834 +
  1.4835 +mailbox-data    =  "FLAGS" SP flag-list / "LIST" SP mailbox-list /
  1.4836 +                   "LSUB" SP mailbox-list / "SEARCH" *(SP nz-number) /
  1.4837 +                   "STATUS" SP mailbox SP "(" [status-att-list] ")" /
  1.4838 +                   number SP "EXISTS" / number SP "RECENT"
  1.4839 +
  1.4840 +mailbox-list    = "(" [mbx-list-flags] ")" SP
  1.4841 +                   (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox
  1.4842 +
  1.4843 +mbx-list-flags  = *(mbx-list-oflag SP) mbx-list-sflag
  1.4844 +                  *(SP mbx-list-oflag) /
  1.4845 +                  mbx-list-oflag *(SP mbx-list-oflag)
  1.4846 +
  1.4847 +mbx-list-oflag  = "\Noinferiors" / flag-extension
  1.4848 +                    ; Other flags; multiple possible per LIST response
  1.4849 +
  1.4850 +mbx-list-sflag  = "\Noselect" / "\Marked" / "\Unmarked"
  1.4851 +                    ; Selectability flags; only one per LIST response
  1.4852 +
  1.4853 +media-basic     = ((DQUOTE ("APPLICATION" / "AUDIO" / "IMAGE" /
  1.4854 +                  "MESSAGE" / "VIDEO") DQUOTE) / string) SP
  1.4855 +                  media-subtype
  1.4856 +                    ; Defined in [MIME-IMT]
  1.4857 +
  1.4858 +media-message   = DQUOTE "MESSAGE" DQUOTE SP DQUOTE "RFC822" DQUOTE
  1.4859 +                    ; Defined in [MIME-IMT]
  1.4860 +
  1.4861 +media-subtype   = string
  1.4862 +                    ; Defined in [MIME-IMT]
  1.4863 +
  1.4864 +media-text      = DQUOTE "TEXT" DQUOTE SP media-subtype
  1.4865 +                    ; Defined in [MIME-IMT]
  1.4866 +
  1.4867 +message-data    = nz-number SP ("EXPUNGE" / ("FETCH" SP msg-att))
  1.4868 +
  1.4869 +msg-att         = "(" (msg-att-dynamic / msg-att-static)
  1.4870 +                   *(SP (msg-att-dynamic / msg-att-static)) ")"
  1.4871 +
  1.4872 +msg-att-dynamic = "FLAGS" SP "(" [flag-fetch *(SP flag-fetch)] ")"
  1.4873 +                    ; MAY change for a message
  1.4874 +
  1.4875 +
  1.4876 +
  1.4877 +Crispin                     Standards Track                    [Page 87]
  1.4878 +
  1.4879 +RFC 3501                         IMAPv4                       March 2003
  1.4880 +
  1.4881 +
  1.4882 +msg-att-static  = "ENVELOPE" SP envelope / "INTERNALDATE" SP date-time /
  1.4883 +                  "RFC822" [".HEADER" / ".TEXT"] SP nstring /
  1.4884 +                  "RFC822.SIZE" SP number /
  1.4885 +                  "BODY" ["STRUCTURE"] SP body /
  1.4886 +                  "BODY" section ["<" number ">"] SP nstring /
  1.4887 +                  "UID" SP uniqueid
  1.4888 +                    ; MUST NOT change for a message
  1.4889 +
  1.4890 +nil             = "NIL"
  1.4891 +
  1.4892 +nstring         = string / nil
  1.4893 +
  1.4894 +number          = 1*DIGIT
  1.4895 +                    ; Unsigned 32-bit integer
  1.4896 +                    ; (0 <= n < 4,294,967,296)
  1.4897 +
  1.4898 +nz-number       = digit-nz *DIGIT
  1.4899 +                    ; Non-zero unsigned 32-bit integer
  1.4900 +                    ; (0 < n < 4,294,967,296)
  1.4901 +
  1.4902 +password        = astring
  1.4903 +
  1.4904 +quoted          = DQUOTE *QUOTED-CHAR DQUOTE
  1.4905 +
  1.4906 +QUOTED-CHAR     = <any TEXT-CHAR except quoted-specials> /
  1.4907 +                  "\" quoted-specials
  1.4908 +
  1.4909 +quoted-specials = DQUOTE / "\"
  1.4910 +
  1.4911 +rename          = "RENAME" SP mailbox SP mailbox
  1.4912 +                    ; Use of INBOX as a destination gives a NO error
  1.4913 +
  1.4914 +response        = *(continue-req / response-data) response-done
  1.4915 +
  1.4916 +response-data   = "*" SP (resp-cond-state / resp-cond-bye /
  1.4917 +                  mailbox-data / message-data / capability-data) CRLF
  1.4918 +
  1.4919 +response-done   = response-tagged / response-fatal
  1.4920 +
  1.4921 +response-fatal  = "*" SP resp-cond-bye CRLF
  1.4922 +                    ; Server closes connection immediately
  1.4923 +
  1.4924 +response-tagged = tag SP resp-cond-state CRLF
  1.4925 +
  1.4926 +resp-cond-auth  = ("OK" / "PREAUTH") SP resp-text
  1.4927 +                    ; Authentication condition
  1.4928 +
  1.4929 +
  1.4930 +
  1.4931 +
  1.4932 +
  1.4933 +Crispin                     Standards Track                    [Page 88]
  1.4934 +
  1.4935 +RFC 3501                         IMAPv4                       March 2003
  1.4936 +
  1.4937 +
  1.4938 +resp-cond-bye   = "BYE" SP resp-text
  1.4939 +
  1.4940 +resp-cond-state = ("OK" / "NO" / "BAD") SP resp-text
  1.4941 +                    ; Status condition
  1.4942 +
  1.4943 +resp-specials   = "]"
  1.4944 +
  1.4945 +resp-text       = ["[" resp-text-code "]" SP] text
  1.4946 +
  1.4947 +resp-text-code  = "ALERT" /
  1.4948 +                  "BADCHARSET" [SP "(" astring *(SP astring) ")" ] /
  1.4949 +                  capability-data / "PARSE" /
  1.4950 +                  "PERMANENTFLAGS" SP "("
  1.4951 +                  [flag-perm *(SP flag-perm)] ")" /
  1.4952 +                  "READ-ONLY" / "READ-WRITE" / "TRYCREATE" /
  1.4953 +                  "UIDNEXT" SP nz-number / "UIDVALIDITY" SP nz-number /
  1.4954 +                  "UNSEEN" SP nz-number /
  1.4955 +                  atom [SP 1*<any TEXT-CHAR except "]">]
  1.4956 +
  1.4957 +search          = "SEARCH" [SP "CHARSET" SP astring] 1*(SP search-key)
  1.4958 +                    ; CHARSET argument to MUST be registered with IANA
  1.4959 +
  1.4960 +search-key      = "ALL" / "ANSWERED" / "BCC" SP astring /
  1.4961 +                  "BEFORE" SP date / "BODY" SP astring /
  1.4962 +                  "CC" SP astring / "DELETED" / "FLAGGED" /
  1.4963 +                  "FROM" SP astring / "KEYWORD" SP flag-keyword /
  1.4964 +                  "NEW" / "OLD" / "ON" SP date / "RECENT" / "SEEN" /
  1.4965 +                  "SINCE" SP date / "SUBJECT" SP astring /
  1.4966 +                  "TEXT" SP astring / "TO" SP astring /
  1.4967 +                  "UNANSWERED" / "UNDELETED" / "UNFLAGGED" /
  1.4968 +                  "UNKEYWORD" SP flag-keyword / "UNSEEN" /
  1.4969 +                    ; Above this line were in [IMAP2]
  1.4970 +                  "DRAFT" / "HEADER" SP header-fld-name SP astring /
  1.4971 +                  "LARGER" SP number / "NOT" SP search-key /
  1.4972 +                  "OR" SP search-key SP search-key /
  1.4973 +                  "SENTBEFORE" SP date / "SENTON" SP date /
  1.4974 +                  "SENTSINCE" SP date / "SMALLER" SP number /
  1.4975 +                  "UID" SP sequence-set / "UNDRAFT" / sequence-set /
  1.4976 +                  "(" search-key *(SP search-key) ")"
  1.4977 +
  1.4978 +section         = "[" [section-spec] "]"
  1.4979 +
  1.4980 +section-msgtext = "HEADER" / "HEADER.FIELDS" [".NOT"] SP header-list /
  1.4981 +                  "TEXT"
  1.4982 +                    ; top-level or MESSAGE/RFC822 part
  1.4983 +
  1.4984 +section-part    = nz-number *("." nz-number)
  1.4985 +                    ; body part nesting
  1.4986 +
  1.4987 +
  1.4988 +
  1.4989 +Crispin                     Standards Track                    [Page 89]
  1.4990 +
  1.4991 +RFC 3501                         IMAPv4                       March 2003
  1.4992 +
  1.4993 +
  1.4994 +section-spec    = section-msgtext / (section-part ["." section-text])
  1.4995 +
  1.4996 +section-text    = section-msgtext / "MIME"
  1.4997 +                    ; text other than actual body part (headers, etc.)
  1.4998 +
  1.4999 +select          = "SELECT" SP mailbox
  1.5000 +
  1.5001 +seq-number      = nz-number / "*"
  1.5002 +                    ; message sequence number (COPY, FETCH, STORE
  1.5003 +                    ; commands) or unique identifier (UID COPY,
  1.5004 +                    ; UID FETCH, UID STORE commands).
  1.5005 +                    ; * represents the largest number in use.  In
  1.5006 +                    ; the case of message sequence numbers, it is
  1.5007 +                    ; the number of messages in a non-empty mailbox.
  1.5008 +                    ; In the case of unique identifiers, it is the
  1.5009 +                    ; unique identifier of the last message in the
  1.5010 +                    ; mailbox or, if the mailbox is empty, the
  1.5011 +                    ; mailbox's current UIDNEXT value.
  1.5012 +                    ; The server should respond with a tagged BAD
  1.5013 +                    ; response to a command that uses a message
  1.5014 +                    ; sequence number greater than the number of
  1.5015 +                    ; messages in the selected mailbox.  This
  1.5016 +                    ; includes "*" if the selected mailbox is empty.
  1.5017 +
  1.5018 +seq-range       = seq-number ":" seq-number
  1.5019 +                    ; two seq-number values and all values between
  1.5020 +                    ; these two regardless of order.
  1.5021 +                    ; Example: 2:4 and 4:2 are equivalent and indicate
  1.5022 +                    ; values 2, 3, and 4.
  1.5023 +                    ; Example: a unique identifer sequence range of
  1.5024 +                    ; 3291:* includes the UID of the last message in
  1.5025 +                    ; the mailbox, even if that value is less than 3291.
  1.5026 +
  1.5027 +sequence-set    = (seq-number / seq-range) *("," sequence-set)
  1.5028 +                    ; set of seq-number values, regardless of order.
  1.5029 +                    ; Servers MAY coalesce overlaps and/or execute the
  1.5030 +                    ; sequence in any order.
  1.5031 +                    ; Example: a message sequence number set of
  1.5032 +                    ; 2,4:7,9,12:* for a mailbox with 15 messages is
  1.5033 +                    ; equivalent to 2,4,5,6,7,9,12,13,14,15
  1.5034 +                    ; Example: a message sequence number set of *:4,5:7
  1.5035 +                    ; for a mailbox with 10 messages is equivalent to
  1.5036 +                    ; 10,9,8,7,6,5,4,5,6,7 and MAY be reordered and
  1.5037 +                    ; overlap coalesced to be 4,5,6,7,8,9,10.
  1.5038 +
  1.5039 +status          = "STATUS" SP mailbox SP
  1.5040 +                  "(" status-att *(SP status-att) ")"
  1.5041 +
  1.5042 +
  1.5043 +
  1.5044 +
  1.5045 +Crispin                     Standards Track                    [Page 90]
  1.5046 +
  1.5047 +RFC 3501                         IMAPv4                       March 2003
  1.5048 +
  1.5049 +
  1.5050 +status-att      = "MESSAGES" / "RECENT" / "UIDNEXT" / "UIDVALIDITY" /
  1.5051 +                  "UNSEEN"
  1.5052 +
  1.5053 +status-att-list =  status-att SP number *(SP status-att SP number)
  1.5054 +
  1.5055 +store           = "STORE" SP sequence-set SP store-att-flags
  1.5056 +
  1.5057 +store-att-flags = (["+" / "-"] "FLAGS" [".SILENT"]) SP
  1.5058 +                  (flag-list / (flag *(SP flag)))
  1.5059 +
  1.5060 +string          = quoted / literal
  1.5061 +
  1.5062 +subscribe       = "SUBSCRIBE" SP mailbox
  1.5063 +
  1.5064 +tag             = 1*<any ASTRING-CHAR except "+">
  1.5065 +
  1.5066 +text            = 1*TEXT-CHAR
  1.5067 +
  1.5068 +TEXT-CHAR       = <any CHAR except CR and LF>
  1.5069 +
  1.5070 +time            = 2DIGIT ":" 2DIGIT ":" 2DIGIT
  1.5071 +                    ; Hours minutes seconds
  1.5072 +
  1.5073 +uid             = "UID" SP (copy / fetch / search / store)
  1.5074 +                    ; Unique identifiers used instead of message
  1.5075 +                    ; sequence numbers
  1.5076 +
  1.5077 +uniqueid        = nz-number
  1.5078 +                    ; Strictly ascending
  1.5079 +
  1.5080 +unsubscribe     = "UNSUBSCRIBE" SP mailbox
  1.5081 +
  1.5082 +userid          = astring
  1.5083 +
  1.5084 +x-command       = "X" atom <experimental command arguments>
  1.5085 +
  1.5086 +zone            = ("+" / "-") 4DIGIT
  1.5087 +                    ; Signed four-digit value of hhmm representing
  1.5088 +                    ; hours and minutes east of Greenwich (that is,
  1.5089 +                    ; the amount that the given time differs from
  1.5090 +                    ; Universal Time).  Subtracting the timezone
  1.5091 +                    ; from the given time will give the UT form.
  1.5092 +                    ; The Universal Time zone is "+0000".
  1.5093 +
  1.5094 +
  1.5095 +
  1.5096 +
  1.5097 +
  1.5098 +
  1.5099 +
  1.5100 +
  1.5101 +Crispin                     Standards Track                    [Page 91]
  1.5102 +
  1.5103 +RFC 3501                         IMAPv4                       March 2003
  1.5104 +
  1.5105 +
  1.5106 +10.     Author's Note
  1.5107 +
  1.5108 +   This document is a revision or rewrite of earlier documents, and
  1.5109 +   supercedes the protocol specification in those documents: RFC 2060,
  1.5110 +   RFC 1730, unpublished IMAP2bis.TXT document, RFC 1176, and RFC 1064.
  1.5111 +
  1.5112 +11.     Security Considerations
  1.5113 +
  1.5114 +   IMAP4rev1 protocol transactions, including electronic mail data, are
  1.5115 +   sent in the clear over the network unless protection from snooping is
  1.5116 +   negotiated.  This can be accomplished either by the use of STARTTLS,
  1.5117 +   negotiated privacy protection in the AUTHENTICATE command, or some
  1.5118 +   other protection mechanism.
  1.5119 +
  1.5120 +11.1.   STARTTLS Security Considerations
  1.5121 +
  1.5122 +   The specification of the STARTTLS command and LOGINDISABLED
  1.5123 +   capability in this document replaces that in [IMAP-TLS].  [IMAP-TLS]
  1.5124 +   remains normative for the PLAIN [SASL] authenticator.
  1.5125 +
  1.5126 +   IMAP client and server implementations MUST implement the
  1.5127 +   TLS_RSA_WITH_RC4_128_MD5 [TLS] cipher suite, and SHOULD implement the
  1.5128 +   TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] cipher suite.  This is
  1.5129 +   important as it assures that any two compliant implementations can be
  1.5130 +   configured to interoperate.  All other cipher suites are OPTIONAL.
  1.5131 +   Note that this is a change from section 2.1 of [IMAP-TLS].
  1.5132 +
  1.5133 +   During the [TLS] negotiation, the client MUST check its understanding
  1.5134 +   of the server hostname against the server's identity as presented in
  1.5135 +   the server Certificate message, in order to prevent man-in-the-middle
  1.5136 +   attacks.  If the match fails, the client SHOULD either ask for
  1.5137 +   explicit user confirmation, or terminate the connection and indicate
  1.5138 +   that the server's identity is suspect.  Matching is performed
  1.5139 +   according to these rules:
  1.5140 +
  1.5141 +        The client MUST use the server hostname it used to open the
  1.5142 +        connection as the value to compare against the server name
  1.5143 +        as expressed in the server certificate.  The client MUST
  1.5144 +        NOT use any form of the server hostname derived from an
  1.5145 +        insecure remote source (e.g., insecure DNS lookup).  CNAME
  1.5146 +        canonicalization is not done.
  1.5147 +
  1.5148 +        If a subjectAltName extension of type dNSName is present in
  1.5149 +        the certificate, it SHOULD be used as the source of the
  1.5150 +        server's identity.
  1.5151 +
  1.5152 +        Matching is case-insensitive.
  1.5153 +
  1.5154 +
  1.5155 +
  1.5156 +
  1.5157 +Crispin                     Standards Track                    [Page 92]
  1.5158 +
  1.5159 +RFC 3501                         IMAPv4                       March 2003
  1.5160 +
  1.5161 +
  1.5162 +        A "*" wildcard character MAY be used as the left-most name
  1.5163 +        component in the certificate.  For example, *.example.com
  1.5164 +        would match a.example.com, foo.example.com, etc. but would
  1.5165 +        not match example.com.
  1.5166 +
  1.5167 +        If the certificate contains multiple names (e.g., more than
  1.5168 +        one dNSName field), then a match with any one of the fields
  1.5169 +        is considered acceptable.
  1.5170 +
  1.5171 +   Both the client and server MUST check the result of the STARTTLS
  1.5172 +   command and subsequent [TLS] negotiation to see whether acceptable
  1.5173 +   authentication or privacy was achieved.
  1.5174 +
  1.5175 +11.2.   Other Security Considerations
  1.5176 +
  1.5177 +   A server error message for an AUTHENTICATE command which fails due to
  1.5178 +   invalid credentials SHOULD NOT detail why the credentials are
  1.5179 +   invalid.
  1.5180 +
  1.5181 +   Use of the LOGIN command sends passwords in the clear.  This can be
  1.5182 +   avoided by using the AUTHENTICATE command with a [SASL] mechanism
  1.5183 +   that does not use plaintext passwords, by first negotiating
  1.5184 +   encryption via STARTTLS or some other protection mechanism.
  1.5185 +
  1.5186 +   A server implementation MUST implement a configuration that, at the
  1.5187 +   time of authentication, requires:
  1.5188 +      (1) The STARTTLS command has been negotiated.
  1.5189 +   OR
  1.5190 +      (2) Some other mechanism that protects the session from password
  1.5191 +      snooping has been provided.
  1.5192 +   OR
  1.5193 +      (3) The following measures are in place:
  1.5194 +         (a) The LOGINDISABLED capability is advertised, and [SASL]
  1.5195 +         mechanisms (such as PLAIN) using plaintext passwords are NOT
  1.5196 +         advertised in the CAPABILITY list.
  1.5197 +      AND
  1.5198 +         (b) The LOGIN command returns an error even if the password is
  1.5199 +         correct.
  1.5200 +      AND
  1.5201 +         (c) The AUTHENTICATE command returns an error with all [SASL]
  1.5202 +         mechanisms that use plaintext passwords, even if the password
  1.5203 +         is correct.
  1.5204 +
  1.5205 +   A server error message for a failing LOGIN command SHOULD NOT specify
  1.5206 +   that the user name, as opposed to the password, is invalid.
  1.5207 +
  1.5208 +   A server SHOULD have mechanisms in place to limit or delay failed
  1.5209 +   AUTHENTICATE/LOGIN attempts.
  1.5210 +
  1.5211 +
  1.5212 +
  1.5213 +Crispin                     Standards Track                    [Page 93]
  1.5214 +
  1.5215 +RFC 3501                         IMAPv4                       March 2003
  1.5216 +
  1.5217 +
  1.5218 +   Additional security considerations are discussed in the section
  1.5219 +   discussing the AUTHENTICATE and LOGIN commands.
  1.5220 +
  1.5221 +12.     IANA Considerations
  1.5222 +
  1.5223 +   IMAP4 capabilities are registered by publishing a standards track or
  1.5224 +   IESG approved experimental RFC.  The registry is currently located
  1.5225 +   at:
  1.5226 +
  1.5227 +        http://www.iana.org/assignments/imap4-capabilities
  1.5228 +
  1.5229 +   As this specification revises the STARTTLS and LOGINDISABLED
  1.5230 +   extensions previously defined in [IMAP-TLS], the registry will be
  1.5231 +   updated accordingly.
  1.5232 +
  1.5233 +
  1.5234 +
  1.5235 +
  1.5236 +
  1.5237 +
  1.5238 +
  1.5239 +
  1.5240 +
  1.5241 +
  1.5242 +
  1.5243 +
  1.5244 +
  1.5245 +
  1.5246 +
  1.5247 +
  1.5248 +
  1.5249 +
  1.5250 +
  1.5251 +
  1.5252 +
  1.5253 +
  1.5254 +
  1.5255 +
  1.5256 +
  1.5257 +
  1.5258 +
  1.5259 +
  1.5260 +
  1.5261 +
  1.5262 +
  1.5263 +
  1.5264 +
  1.5265 +
  1.5266 +
  1.5267 +
  1.5268 +
  1.5269 +Crispin                     Standards Track                    [Page 94]
  1.5270 +
  1.5271 +RFC 3501                         IMAPv4                       March 2003
  1.5272 +
  1.5273 +
  1.5274 +Appendices
  1.5275 +
  1.5276 +A.      Normative References
  1.5277 +
  1.5278 +   The following documents contain definitions or specifications that
  1.5279 +   are necessary to understand this document properly:
  1.5280 +   [ABNF]                Crocker, D. and P. Overell, "Augmented BNF for
  1.5281 +                         Syntax Specifications: ABNF", RFC 2234,
  1.5282 +                         November 1997.
  1.5283 +
  1.5284 +   [ANONYMOUS]           Newman, C., "Anonymous SASL Mechanism", RFC
  1.5285 +                         2245, November 1997.
  1.5286 +
  1.5287 +   [CHARSET]             Freed, N. and J. Postel, "IANA Character Set
  1.5288 +                         Registration Procedures", RFC 2978, October
  1.5289 +                         2000.
  1.5290 +
  1.5291 +   [DIGEST-MD5]          Leach, P. and C. Newman, "Using Digest
  1.5292 +                         Authentication as a SASL Mechanism", RFC 2831,
  1.5293 +                         May 2000.
  1.5294 +
  1.5295 +   [DISPOSITION]         Troost, R., Dorner, S. and K. Moore,
  1.5296 +                         "Communicating Presentation Information in
  1.5297 +                         Internet Messages: The Content-Disposition
  1.5298 +                         Header", RFC 2183, August 1997.
  1.5299 +
  1.5300 +   [IMAP-TLS]            Newman, C., "Using TLS with IMAP, POP3 and
  1.5301 +                         ACAP", RFC 2595, June 1999.
  1.5302 +
  1.5303 +   [KEYWORDS]            Bradner, S., "Key words for use in RFCs to
  1.5304 +                         Indicate Requirement Levels", BCP 14, RFC 2119,
  1.5305 +                         March 1997.
  1.5306 +
  1.5307 +   [LANGUAGE-TAGS]       Alvestrand, H., "Tags for the Identification of
  1.5308 +                         Languages", BCP 47, RFC 3066, January 2001.
  1.5309 +
  1.5310 +   [LOCATION]            Palme, J., Hopmann, A. and N. Shelness, "MIME
  1.5311 +                         Encapsulation of Aggregate Documents, such as
  1.5312 +                         HTML (MHTML)", RFC 2557, March 1999.
  1.5313 +
  1.5314 +   [MD5]                 Myers, J. and M. Rose, "The Content-MD5 Header
  1.5315 +                         Field", RFC 1864, October 1995.
  1.5316 +
  1.5317 +
  1.5318 +
  1.5319 +
  1.5320 +
  1.5321 +
  1.5322 +
  1.5323 +
  1.5324 +
  1.5325 +Crispin                     Standards Track                    [Page 95]
  1.5326 +
  1.5327 +RFC 3501                         IMAPv4                       March 2003
  1.5328 +
  1.5329 +
  1.5330 +   [MIME-HDRS]           Moore, K., "MIME (Multipurpose Internet Mail
  1.5331 +                         Extensions) Part Three: Message Header
  1.5332 +                         Extensions for Non-ASCII Text", RFC 2047,
  1.5333 +                         November 1996.
  1.5334 +
  1.5335 +   [MIME-IMB]            Freed, N. and N. Borenstein, "MIME
  1.5336 +                         (Multipurpose Internet Mail Extensions) Part
  1.5337 +                         One: Format of Internet Message Bodies", RFC
  1.5338 +                         2045, November 1996.
  1.5339 +
  1.5340 +   [MIME-IMT]            Freed, N. and N. Borenstein, "MIME
  1.5341 +                         (Multipurpose Internet Mail Extensions) Part
  1.5342 +                         Two: Media Types", RFC 2046, November 1996.
  1.5343 +
  1.5344 +   [RFC-2822]            Resnick, P., "Internet Message Format", RFC
  1.5345 +                         2822, April 2001.
  1.5346 +
  1.5347 +   [SASL]                Myers, J., "Simple Authentication and Security
  1.5348 +                         Layer (SASL)", RFC 2222, October 1997.
  1.5349 +
  1.5350 +   [TLS]                 Dierks, T. and C. Allen, "The TLS Protocol
  1.5351 +                         Version 1.0", RFC 2246, January 1999.
  1.5352 +
  1.5353 +   [UTF-7]               Goldsmith, D. and M. Davis, "UTF-7: A Mail-Safe
  1.5354 +                         Transformation Format of Unicode", RFC 2152,
  1.5355 +                         May 1997.
  1.5356 +
  1.5357 +   The following documents describe quality-of-implementation issues
  1.5358 +   that should be carefully considered when implementing this protocol:
  1.5359 +
  1.5360 +   [IMAP-IMPLEMENTATION] Leiba, B., "IMAP Implementation
  1.5361 +                         Recommendations", RFC 2683, September 1999.
  1.5362 +
  1.5363 +   [IMAP-MULTIACCESS]    Gahrns, M., "IMAP4 Multi-Accessed Mailbox
  1.5364 +                         Practice", RFC 2180, July 1997.
  1.5365 +
  1.5366 +A.1     Informative References
  1.5367 +
  1.5368 +   The following documents describe related protocols:
  1.5369 +
  1.5370 +   [IMAP-DISC]           Austein, R., "Synchronization Operations for
  1.5371 +                         Disconnected IMAP4 Clients", Work in Progress.
  1.5372 +
  1.5373 +   [IMAP-MODEL]          Crispin, M., "Distributed Electronic Mail
  1.5374 +                         Models in IMAP4", RFC 1733, December 1994.
  1.5375 +
  1.5376 +
  1.5377 +
  1.5378 +
  1.5379 +
  1.5380 +
  1.5381 +Crispin                     Standards Track                    [Page 96]
  1.5382 +
  1.5383 +RFC 3501                         IMAPv4                       March 2003
  1.5384 +
  1.5385 +
  1.5386 +   [ACAP]                Newman, C. and J. Myers, "ACAP -- Application
  1.5387 +                         Configuration Access Protocol", RFC 2244,
  1.5388 +                         November 1997.
  1.5389 +
  1.5390 +   [SMTP]                Klensin, J., "Simple Mail Transfer Protocol",
  1.5391 +                         STD 10, RFC 2821, April 2001.
  1.5392 +
  1.5393 +   The following documents are historical or describe historical aspects
  1.5394 +   of this protocol:
  1.5395 +
  1.5396 +   [IMAP-COMPAT]         Crispin, M., "IMAP4 Compatibility with
  1.5397 +                         IMAP2bis", RFC 2061, December 1996.
  1.5398 +
  1.5399 +   [IMAP-HISTORICAL]     Crispin, M., "IMAP4 Compatibility with IMAP2
  1.5400 +                         and IMAP2bis", RFC 1732, December 1994.
  1.5401 +
  1.5402 +   [IMAP-OBSOLETE]       Crispin, M., "Internet Message Access Protocol
  1.5403 +                         - Obsolete Syntax", RFC 2062, December 1996.
  1.5404 +
  1.5405 +   [IMAP2]               Crispin, M., "Interactive Mail Access Protocol
  1.5406 +                         - Version 2", RFC 1176, August 1990.
  1.5407 +
  1.5408 +   [RFC-822]             Crocker, D., "Standard for the Format of ARPA
  1.5409 +                         Internet Text Messages", STD 11, RFC 822,
  1.5410 +                         August 1982.
  1.5411 +
  1.5412 +   [RFC-821]             Postel, J., "Simple Mail Transfer Protocol",
  1.5413 +                         STD 10, RFC 821, August 1982.
  1.5414 +
  1.5415 +B.      Changes from RFC 2060
  1.5416 +
  1.5417 +   1) Clarify description of unique identifiers and their semantics.
  1.5418 +
  1.5419 +   2) Fix the SELECT description to clarify that UIDVALIDITY is required
  1.5420 +   in the SELECT and EXAMINE responses.
  1.5421 +
  1.5422 +   3) Added an example of a failing search.
  1.5423 +
  1.5424 +   4) Correct store-att-flags: "#flag" should be "1#flag".
  1.5425 +
  1.5426 +   5) Made search and section rules clearer.
  1.5427 +
  1.5428 +   6) Correct the STORE example.
  1.5429 +
  1.5430 +   7) Correct "BASE645" misspelling.
  1.5431 +
  1.5432 +   8) Remove extraneous close parenthesis in example of two-part message
  1.5433 +   with text and BASE64 attachment.
  1.5434 +
  1.5435 +
  1.5436 +
  1.5437 +Crispin                     Standards Track                    [Page 97]
  1.5438 +
  1.5439 +RFC 3501                         IMAPv4                       March 2003
  1.5440 +
  1.5441 +
  1.5442 +   9) Remove obsolete "MAILBOX" response from mailbox-data.
  1.5443 +
  1.5444 +   10) A spurious "<" in the rule for mailbox-data was removed.
  1.5445 +
  1.5446 +   11) Add CRLF to continue-req.
  1.5447 +
  1.5448 +   12) Specifically exclude "]" from the atom in resp-text-code.
  1.5449 +
  1.5450 +   13) Clarify that clients and servers should adhere strictly to the
  1.5451 +   protocol syntax.
  1.5452 +
  1.5453 +   14) Emphasize in 5.2 that EXISTS can not be used to shrink a mailbox.
  1.5454 +
  1.5455 +   15) Add NEWNAME to resp-text-code.
  1.5456 +
  1.5457 +   16) Clarify that the empty string, not NIL, is used as arguments to
  1.5458 +   LIST.
  1.5459 +
  1.5460 +   17) Clarify that NIL can be returned as a hierarchy delimiter for the
  1.5461 +   empty string mailbox name argument if the mailbox namespace is flat.
  1.5462 +
  1.5463 +   18) Clarify that addr-mailbox and addr-name have RFC-2822 quoting
  1.5464 +   removed.
  1.5465 +
  1.5466 +   19) Update UTF-7 reference.
  1.5467 +
  1.5468 +   20) Fix example in 6.3.11.
  1.5469 +
  1.5470 +   21) Clarify that non-existent UIDs are ignored.
  1.5471 +
  1.5472 +   22) Update DISPOSITION reference.
  1.5473 +
  1.5474 +   23) Expand state diagram.
  1.5475 +
  1.5476 +   24) Clarify that partial fetch responses are only returned in
  1.5477 +   response to a partial fetch command.
  1.5478 +
  1.5479 +   25) Add UIDNEXT response code.  Correct UIDVALIDITY definition
  1.5480 +   reference.
  1.5481 +
  1.5482 +   26) Further clarification of "can" vs. "MAY".
  1.5483 +
  1.5484 +   27) Reference RFC-2119.
  1.5485 +
  1.5486 +   28) Clarify that superfluous shifts are not permitted in modified
  1.5487 +   UTF-7.
  1.5488 +
  1.5489 +   29) Clarify that there are no implicit shifts in modified UTF-7.
  1.5490 +
  1.5491 +
  1.5492 +
  1.5493 +Crispin                     Standards Track                    [Page 98]
  1.5494 +
  1.5495 +RFC 3501                         IMAPv4                       March 2003
  1.5496 +
  1.5497 +
  1.5498 +   30) Clarify that "INBOX" in a mailbox name is always INBOX, even if
  1.5499 +   it is given as a string.
  1.5500 +
  1.5501 +   31) Add missing open parenthesis in media-basic grammar rule.
  1.5502 +
  1.5503 +   32) Correct attribute syntax in mailbox-data.
  1.5504 +
  1.5505 +   33) Add UIDNEXT to EXAMINE responses.
  1.5506 +
  1.5507 +   34) Clarify UNSEEN, PERMANENTFLAGS, UIDVALIDITY, and UIDNEXT
  1.5508 +   responses in SELECT and EXAMINE.  They are required now, but weren't
  1.5509 +   in older versions.
  1.5510 +
  1.5511 +   35) Update references with RFC numbers.
  1.5512 +
  1.5513 +   36) Flush text-mime2.
  1.5514 +
  1.5515 +   37) Clarify that modified UTF-7 names must be case-sensitive and that
  1.5516 +   violating the convention should be avoided.
  1.5517 +
  1.5518 +   38) Correct UID FETCH example.
  1.5519 +
  1.5520 +   39) Clarify UID FETCH, UID STORE, and UID SEARCH vs. untagged EXPUNGE
  1.5521 +   responses.
  1.5522 +
  1.5523 +   40) Clarify the use of the word "convention".
  1.5524 +
  1.5525 +   41) Clarify that a command is not "in progress" until it has been
  1.5526 +   fully received (specifically, that a command is not "in progress"
  1.5527 +   during command continuation negotiation).
  1.5528 +
  1.5529 +   42) Clarify envelope defaulting.
  1.5530 +
  1.5531 +   43) Clarify that SP means one and only one space character.
  1.5532 +
  1.5533 +   44) Forbid silly states in LIST response.
  1.5534 +
  1.5535 +   45) Clarify that the ENVELOPE, INTERNALDATE, RFC822*, BODY*, and UID
  1.5536 +   for a message is static.
  1.5537 +
  1.5538 +   46) Add BADCHARSET response code.
  1.5539 +
  1.5540 +   47) Update formal syntax to [ABNF] conventions.
  1.5541 +
  1.5542 +   48) Clarify trailing hierarchy delimiter in CREATE semantics.
  1.5543 +
  1.5544 +   49) Clarify that the "blank line" is the [RFC-2822] delimiting blank
  1.5545 +   line.
  1.5546 +
  1.5547 +
  1.5548 +
  1.5549 +Crispin                     Standards Track                    [Page 99]
  1.5550 +
  1.5551 +RFC 3501                         IMAPv4                       March 2003
  1.5552 +
  1.5553 +
  1.5554 +   50) Clarify that RENAME should also create hierarchy as needed for
  1.5555 +   the command to complete.
  1.5556 +
  1.5557 +   51) Fix body-ext-mpart to not require language if disposition
  1.5558 +   present.
  1.5559 +
  1.5560 +   52) Clarify the RFC822.HEADER response.
  1.5561 +
  1.5562 +   53) Correct missing space after charset astring in search.
  1.5563 +
  1.5564 +   54) Correct missing quote for BADCHARSET in resp-text-code.
  1.5565 +
  1.5566 +   55) Clarify that ALL, FAST, and FULL preclude any other data items
  1.5567 +   appearing.
  1.5568 +
  1.5569 +   56) Clarify semantics of reference argument in LIST.
  1.5570 +
  1.5571 +   57) Clarify that a null string for SEARCH HEADER X-FOO means any
  1.5572 +   message with a header line with a field-name of X-FOO regardless of
  1.5573 +   the text of the header.
  1.5574 +
  1.5575 +   58) Specifically reserve 8-bit mailbox names for future use as UTF-8.
  1.5576 +
  1.5577 +   59) It is not an error for the client to store a flag that is not in
  1.5578 +   the PERMANENTFLAGS list; however, the server will either ignore the
  1.5579 +   change or make the change in the session only.
  1.5580 +
  1.5581 +   60) Correct/clarify the text regarding superfluous shifts.
  1.5582 +
  1.5583 +   61) Correct typographic errors in the "Changes" section.
  1.5584 +
  1.5585 +   62) Clarify that STATUS must not be used to check for new messages in
  1.5586 +   the selected mailbox
  1.5587 +
  1.5588 +   63) Clarify LSUB behavior with "%" wildcard.
  1.5589 +
  1.5590 +   64) Change AUTHORIZATION to AUTHENTICATE in section 7.5.
  1.5591 +
  1.5592 +   65) Clarify description of multipart body type.
  1.5593 +
  1.5594 +   66) Clarify that STORE FLAGS does not affect \Recent.
  1.5595 +
  1.5596 +   67) Change "west" to "east" in description of timezone.
  1.5597 +
  1.5598 +   68) Clarify that commands which break command pipelining must wait
  1.5599 +   for a completion result response.
  1.5600 +
  1.5601 +   69) Clarify that EXAMINE does not affect \Recent.
  1.5602 +
  1.5603 +
  1.5604 +
  1.5605 +Crispin                     Standards Track                   [Page 100]
  1.5606 +
  1.5607 +RFC 3501                         IMAPv4                       March 2003
  1.5608 +
  1.5609 +
  1.5610 +   70) Make description of MIME structure consistent.
  1.5611 +
  1.5612 +   71) Clarify that date searches disregard the time and timezone of the
  1.5613 +   INTERNALDATE or Date: header.  In other words, "ON 13-APR-2000" means
  1.5614 +   messages with an INTERNALDATE text which starts with "13-APR-2000",
  1.5615 +   even if timezone differential from the local timezone is sufficient
  1.5616 +   to move that INTERNALDATE into the previous or next day.
  1.5617 +
  1.5618 +   72) Clarify that the header fetches don't add a blank line if one
  1.5619 +   isn't in the [RFC-2822] message.
  1.5620 +
  1.5621 +   73) Clarify (in discussion of UIDs) that messages are immutable.
  1.5622 +
  1.5623 +   74) Add an example of CHARSET searching.
  1.5624 +
  1.5625 +   75) Clarify in SEARCH that keywords are a type of flag.
  1.5626 +
  1.5627 +   76) Clarify the mandatory nature of the SELECT data responses.
  1.5628 +
  1.5629 +   77) Add optional CAPABILITY response code in the initial OK or
  1.5630 +   PREAUTH.
  1.5631 +
  1.5632 +   78) Add note that server can send an untagged CAPABILITY command as
  1.5633 +   part of the responses to AUTHENTICATE and LOGIN.
  1.5634 +
  1.5635 +   79) Remove statement about it being unnecessary to issue a CAPABILITY
  1.5636 +   command more than once in a connection.  That statement is no longer
  1.5637 +   true.
  1.5638 +
  1.5639 +   80) Clarify that untagged EXPUNGE decrements the number of messages
  1.5640 +   in the mailbox.
  1.5641 +
  1.5642 +   81) Fix definition of "body" (concatenation has tighter binding than
  1.5643 +   alternation).
  1.5644 +
  1.5645 +   82) Add a new "Special Notes to Implementors" section with reference
  1.5646 +   to [IMAP-IMPLEMENTATION].
  1.5647 +
  1.5648 +   83) Clarify that an untagged CAPABILITY response to an AUTHENTICATE
  1.5649 +   command should only be done if a security layer was not negotiated.
  1.5650 +
  1.5651 +   84) Change the definition of atom to exclude "]".  Update astring to
  1.5652 +   include "]" for compatiblity with the past.  Remove resp-text-atom.
  1.5653 +
  1.5654 +   85) Remove NEWNAME.  It can't work because mailbox names can be
  1.5655 +   literals and can include "]".  Functionality can be addressed via
  1.5656 +   referrals.
  1.5657 +
  1.5658 +
  1.5659 +
  1.5660 +
  1.5661 +Crispin                     Standards Track                   [Page 101]
  1.5662 +
  1.5663 +RFC 3501                         IMAPv4                       March 2003
  1.5664 +
  1.5665 +
  1.5666 +   86) Move modified UTF-7 rationale in order to have more logical
  1.5667 +   paragraph flow.
  1.5668 +
  1.5669 +   87) Clarify UID uniqueness guarantees with the use of MUST.
  1.5670 +
  1.5671 +   88) Note that clients should read response data until the connection
  1.5672 +   is closed instead of immediately closing on a BYE.
  1.5673 +
  1.5674 +   89) Change RFC-822 references to RFC-2822.
  1.5675 +
  1.5676 +   90) Clarify that RFC-2822 should be followed instead of RFC-822.
  1.5677 +
  1.5678 +   91) Change recommendation of optional automatic capabilities in LOGIN
  1.5679 +   and AUTHENTICATE to use the CAPABILITY response code in the tagged
  1.5680 +   OK.  This is more interoperable than an unsolicited untagged
  1.5681 +   CAPABILITY response.
  1.5682 +
  1.5683 +   92) STARTTLS and AUTH=PLAIN are mandatory to implement; add
  1.5684 +   recommendations for other [SASL] mechanisms.
  1.5685 +
  1.5686 +   93) Clarify that a "connection" (as opposed to "server" or "command")
  1.5687 +   is in one of the four states.
  1.5688 +
  1.5689 +   94) Clarify that a failed or rejected command does not change state.
  1.5690 +
  1.5691 +   95) Split references between normative and informative.
  1.5692 +
  1.5693 +   96) Discuss authentication failure issues in security section.
  1.5694 +
  1.5695 +   97) Clarify that a data item is not necessarily of only one data
  1.5696 +   type.
  1.5697 +
  1.5698 +   98) Clarify that sequence ranges are independent of order.
  1.5699 +
  1.5700 +   99) Change an example to clarify that superfluous shifts in
  1.5701 +   Modified-UTF7 can not be fixed just by omitting the shift.  The
  1.5702 +   entire string must be recalculated.
  1.5703 +
  1.5704 +   100) Change Envelope Structure definition since [RFC-2822] uses
  1.5705 +   "envelope" to refer to the [SMTP] envelope and not the envelope data
  1.5706 +   that appears in the [RFC-2822] header.
  1.5707 +
  1.5708 +   101) Expand on RFC822.HEADER response data vs. BODY[HEADER].
  1.5709 +
  1.5710 +   102) Clarify Logout state semantics, change ASCII art.
  1.5711 +
  1.5712 +   103) Security changes to comply with IESG requirements.
  1.5713 +
  1.5714 +
  1.5715 +
  1.5716 +
  1.5717 +Crispin                     Standards Track                   [Page 102]
  1.5718 +
  1.5719 +RFC 3501                         IMAPv4                       March 2003
  1.5720 +
  1.5721 +
  1.5722 +   104) Add definition for body URI.
  1.5723 +
  1.5724 +   105) Break sequence range definition into three rules, with rewritten
  1.5725 +   descriptions for each.
  1.5726 +
  1.5727 +   106) Move STARTTLS and LOGINDISABLED here from [IMAP-TLS].
  1.5728 +
  1.5729 +   107) Add IANA Considerations section.
  1.5730 +
  1.5731 +   108) Clarify valid client assumptions for new message UIDs vs.
  1.5732 +   UIDNEXT.
  1.5733 +
  1.5734 +   109) Clarify that changes to permanentflags affect concurrent
  1.5735 +   sessions as well as subsequent sessions.
  1.5736 +
  1.5737 +   110) Clarify that authenticated state can be entered by the CLOSE
  1.5738 +   command.
  1.5739 +
  1.5740 +   111) Emphasize that SELECT and EXAMINE are the exceptions to the rule
  1.5741 +   that a failing command does not change state.
  1.5742 +
  1.5743 +   112) Clarify that newly-appended messages have the Recent flag set.
  1.5744 +
  1.5745 +   113) Clarify that newly-copied messages SHOULD have the Recent flag
  1.5746 +   set.
  1.5747 +
  1.5748 +   114) Clarify that UID commands always return the UID in FETCH
  1.5749 +   responses.
  1.5750 +
  1.5751 +C.      Key Word Index
  1.5752 +
  1.5753 +       +FLAGS <flag list> (store command data item) ...............   59
  1.5754 +       +FLAGS.SILENT <flag list> (store command data item) ........   59
  1.5755 +       -FLAGS <flag list> (store command data item) ...............   59
  1.5756 +       -FLAGS.SILENT <flag list> (store command data item) ........   59
  1.5757 +       ALERT (response code) ......................................   64
  1.5758 +       ALL (fetch item) ...........................................   55
  1.5759 +       ALL (search key) ...........................................   50
  1.5760 +       ANSWERED (search key) ......................................   50
  1.5761 +       APPEND (command) ...........................................   45
  1.5762 +       AUTHENTICATE (command) .....................................   27
  1.5763 +       BAD (response) .............................................   66
  1.5764 +       BADCHARSET (response code) .................................   64
  1.5765 +       BCC <string> (search key) ..................................   51
  1.5766 +       BEFORE <date> (search key) .................................   51
  1.5767 +       BODY (fetch item) ..........................................   55
  1.5768 +       BODY (fetch result) ........................................   73
  1.5769 +       BODY <string> (search key) .................................   51
  1.5770 +
  1.5771 +
  1.5772 +
  1.5773 +Crispin                     Standards Track                   [Page 103]
  1.5774 +
  1.5775 +RFC 3501                         IMAPv4                       March 2003
  1.5776 +
  1.5777 +
  1.5778 +       BODY.PEEK[<section>]<<partial>> (fetch item) ...............   57
  1.5779 +       BODYSTRUCTURE (fetch item) .................................   57
  1.5780 +       BODYSTRUCTURE (fetch result) ...............................   74
  1.5781 +       BODY[<section>]<<origin octet>> (fetch result) .............   74
  1.5782 +       BODY[<section>]<<partial>> (fetch item) ....................   55
  1.5783 +       BYE (response) .............................................   67
  1.5784 +       Body Structure (message attribute) .........................   12
  1.5785 +       CAPABILITY (command) .......................................   24
  1.5786 +       CAPABILITY (response code) .................................   64
  1.5787 +       CAPABILITY (response) ......................................   68
  1.5788 +       CC <string> (search key) ...................................   51
  1.5789 +       CHECK (command) ............................................   47
  1.5790 +       CLOSE (command) ............................................   48
  1.5791 +       COPY (command) .............................................   59
  1.5792 +       CREATE (command) ...........................................   34
  1.5793 +       DELETE (command) ...........................................   35
  1.5794 +       DELETED (search key) .......................................   51
  1.5795 +       DRAFT (search key) .........................................   51
  1.5796 +       ENVELOPE (fetch item) ......................................   57
  1.5797 +       ENVELOPE (fetch result) ....................................   77
  1.5798 +       EXAMINE (command) ..........................................   33
  1.5799 +       EXISTS (response) ..........................................   71
  1.5800 +       EXPUNGE (command) ..........................................   48
  1.5801 +       EXPUNGE (response) .........................................   72
  1.5802 +       Envelope Structure (message attribute) .....................   12
  1.5803 +       FAST (fetch item) ..........................................   55
  1.5804 +       FETCH (command) ............................................   54
  1.5805 +       FETCH (response) ...........................................   73
  1.5806 +       FLAGGED (search key) .......................................   51
  1.5807 +       FLAGS (fetch item) .........................................   57
  1.5808 +       FLAGS (fetch result) .......................................   78
  1.5809 +       FLAGS (response) ...........................................   71
  1.5810 +       FLAGS <flag list> (store command data item) ................   59
  1.5811 +       FLAGS.SILENT <flag list> (store command data item) .........   59
  1.5812 +       FROM <string> (search key) .................................   51
  1.5813 +       FULL (fetch item) ..........................................   55
  1.5814 +       Flags (message attribute) ..................................   11
  1.5815 +       HEADER (part specifier) ....................................   55
  1.5816 +       HEADER <field-name> <string> (search key) ..................   51
  1.5817 +       HEADER.FIELDS <header-list> (part specifier) ...............   55
  1.5818 +       HEADER.FIELDS.NOT <header-list> (part specifier) ...........   55
  1.5819 +       INTERNALDATE (fetch item) ..................................   57
  1.5820 +       INTERNALDATE (fetch result) ................................   78
  1.5821 +       Internal Date (message attribute) ..........................   12
  1.5822 +       KEYWORD <flag> (search key) ................................   51
  1.5823 +       Keyword (type of flag) .....................................   11
  1.5824 +       LARGER <n> (search key) ....................................   51
  1.5825 +       LIST (command) .............................................   40
  1.5826 +
  1.5827 +
  1.5828 +
  1.5829 +Crispin                     Standards Track                   [Page 104]
  1.5830 +
  1.5831 +RFC 3501                         IMAPv4                       March 2003
  1.5832 +
  1.5833 +
  1.5834 +       LIST (response) ............................................   69
  1.5835 +       LOGIN (command) ............................................   30
  1.5836 +       LOGOUT (command) ...........................................   25
  1.5837 +       LSUB (command) .............................................   43
  1.5838 +       LSUB (response) ............................................   70
  1.5839 +       MAY (specification requirement term) .......................    4
  1.5840 +       MESSAGES (status item) .....................................   45
  1.5841 +       MIME (part specifier) ......................................   56
  1.5842 +       MUST (specification requirement term) ......................    4
  1.5843 +       MUST NOT (specification requirement term) ..................    4
  1.5844 +       Message Sequence Number (message attribute) ................   10
  1.5845 +       NEW (search key) ...........................................   51
  1.5846 +       NO (response) ..............................................   66
  1.5847 +       NOOP (command) .............................................   25
  1.5848 +       NOT <search-key> (search key) ..............................   52
  1.5849 +       OK (response) ..............................................   65
  1.5850 +       OLD (search key) ...........................................   52
  1.5851 +       ON <date> (search key) .....................................   52
  1.5852 +       OPTIONAL (specification requirement term) ..................    4
  1.5853 +       OR <search-key1> <search-key2> (search key) ................   52
  1.5854 +       PARSE (response code) ......................................   64
  1.5855 +       PERMANENTFLAGS (response code) .............................   64
  1.5856 +       PREAUTH (response) .........................................   67
  1.5857 +       Permanent Flag (class of flag) .............................   12
  1.5858 +       READ-ONLY (response code) ..................................   65
  1.5859 +       READ-WRITE (response code) .................................   65
  1.5860 +       RECENT (response) ..........................................   72
  1.5861 +       RECENT (search key) ........................................   52
  1.5862 +       RECENT (status item) .......................................   45
  1.5863 +       RENAME (command) ...........................................   37
  1.5864 +       REQUIRED (specification requirement term) ..................    4
  1.5865 +       RFC822 (fetch item) ........................................   57
  1.5866 +       RFC822 (fetch result) ......................................   78
  1.5867 +       RFC822.HEADER (fetch item) .................................   57
  1.5868 +       RFC822.HEADER (fetch result) ...............................   78
  1.5869 +       RFC822.SIZE (fetch item) ...................................   57
  1.5870 +       RFC822.SIZE (fetch result) .................................   78
  1.5871 +       RFC822.TEXT (fetch item) ...................................   58
  1.5872 +       RFC822.TEXT (fetch result) .................................   79
  1.5873 +       SEARCH (command) ...........................................   49
  1.5874 +       SEARCH (response) ..........................................   71
  1.5875 +       SEEN (search key) ..........................................   52
  1.5876 +       SELECT (command) ...........................................   31
  1.5877 +       SENTBEFORE <date> (search key) .............................   52
  1.5878 +       SENTON <date> (search key) .................................   52
  1.5879 +       SENTSINCE <date> (search key) ..............................   52
  1.5880 +       SHOULD (specification requirement term) ....................    4
  1.5881 +       SHOULD NOT (specification requirement term) ................    4
  1.5882 +
  1.5883 +
  1.5884 +
  1.5885 +Crispin                     Standards Track                   [Page 105]
  1.5886 +
  1.5887 +RFC 3501                         IMAPv4                       March 2003
  1.5888 +
  1.5889 +
  1.5890 +       SINCE <date> (search key) ..................................   52
  1.5891 +       SMALLER <n> (search key) ...................................   52
  1.5892 +       STARTTLS (command) .........................................   27
  1.5893 +       STATUS (command) ...........................................   44
  1.5894 +       STATUS (response) ..........................................   70
  1.5895 +       STORE (command) ............................................   58
  1.5896 +       SUBJECT <string> (search key) ..............................   53
  1.5897 +       SUBSCRIBE (command) ........................................   38
  1.5898 +       Session Flag (class of flag) ...............................   12
  1.5899 +       System Flag (type of flag) .................................   11
  1.5900 +       TEXT (part specifier) ......................................   56
  1.5901 +       TEXT <string> (search key) .................................   53
  1.5902 +       TO <string> (search key) ...................................   53
  1.5903 +       TRYCREATE (response code) ..................................   65
  1.5904 +       UID (command) ..............................................   60
  1.5905 +       UID (fetch item) ...........................................   58
  1.5906 +       UID (fetch result) .........................................   79
  1.5907 +       UID <sequence set> (search key) ............................   53
  1.5908 +       UIDNEXT (response code) ....................................   65
  1.5909 +       UIDNEXT (status item) ......................................   45
  1.5910 +       UIDVALIDITY (response code) ................................   65
  1.5911 +       UIDVALIDITY (status item) ..................................   45
  1.5912 +       UNANSWERED (search key) ....................................   53
  1.5913 +       UNDELETED (search key) .....................................   53
  1.5914 +       UNDRAFT (search key) .......................................   53
  1.5915 +       UNFLAGGED (search key) .....................................   53
  1.5916 +       UNKEYWORD <flag> (search key) ..............................   53
  1.5917 +       UNSEEN (response code) .....................................   65
  1.5918 +       UNSEEN (search key) ........................................   53
  1.5919 +       UNSEEN (status item) .......................................   45
  1.5920 +       UNSUBSCRIBE (command) ......................................   39
  1.5921 +       Unique Identifier (UID) (message attribute) ................    8
  1.5922 +       X<atom> (command) ..........................................   62
  1.5923 +       [RFC-2822] Size (message attribute) ........................   12
  1.5924 +       \Answered (system flag) ....................................   11
  1.5925 +       \Deleted (system flag) .....................................   11
  1.5926 +       \Draft (system flag) .......................................   11
  1.5927 +       \Flagged (system flag) .....................................   11
  1.5928 +       \Marked (mailbox name attribute) ...........................   69
  1.5929 +       \Noinferiors (mailbox name attribute) ......................   69
  1.5930 +       \Noselect (mailbox name attribute) .........................   69
  1.5931 +       \Recent (system flag) ......................................   11
  1.5932 +       \Seen (system flag) ........................................   11
  1.5933 +       \Unmarked (mailbox name attribute) .........................   69
  1.5934 +
  1.5935 +
  1.5936 +
  1.5937 +
  1.5938 +
  1.5939 +
  1.5940 +
  1.5941 +Crispin                     Standards Track                   [Page 106]
  1.5942 +
  1.5943 +RFC 3501                         IMAPv4                       March 2003
  1.5944 +
  1.5945 +
  1.5946 +Author's Address
  1.5947 +
  1.5948 +   Mark R. Crispin
  1.5949 +   Networks and Distributed Computing
  1.5950 +   University of Washington
  1.5951 +   4545 15th Avenue NE
  1.5952 +   Seattle, WA  98105-4527
  1.5953 +
  1.5954 +   Phone: (206) 543-5762
  1.5955 +
  1.5956 +   EMail: MRC@CAC.Washington.EDU
  1.5957 +
  1.5958 +
  1.5959 +
  1.5960 +
  1.5961 +
  1.5962 +
  1.5963 +
  1.5964 +
  1.5965 +
  1.5966 +
  1.5967 +
  1.5968 +
  1.5969 +
  1.5970 +
  1.5971 +
  1.5972 +
  1.5973 +
  1.5974 +
  1.5975 +
  1.5976 +
  1.5977 +
  1.5978 +
  1.5979 +
  1.5980 +
  1.5981 +
  1.5982 +
  1.5983 +
  1.5984 +
  1.5985 +
  1.5986 +
  1.5987 +
  1.5988 +
  1.5989 +
  1.5990 +
  1.5991 +
  1.5992 +
  1.5993 +
  1.5994 +
  1.5995 +
  1.5996 +
  1.5997 +Crispin                     Standards Track                   [Page 107]
  1.5998 +
  1.5999 +RFC 3501                         IMAPv4                       March 2003
  1.6000 +
  1.6001 +
  1.6002 +Full Copyright Statement
  1.6003 +
  1.6004 +   Copyright (C) The Internet Society (2003).  All Rights Reserved.
  1.6005 +
  1.6006 +   This document and translations of it may be copied and furnished to
  1.6007 +   others, and derivative works that comment on or otherwise explain it
  1.6008 +   or assist in its implementation may be prepared, copied, published
  1.6009 +   and distributed, in whole or in part, without restriction of any
  1.6010 +   kind, provided that the above copyright notice and this paragraph are
  1.6011 +   included on all such copies and derivative works.  However, this
  1.6012 +   document itself may not be modified in any way, such as by removing
  1.6013 +   the copyright notice or references to the Internet Society or other
  1.6014 +   Internet organizations, except as needed for the purpose of
  1.6015 +   developing Internet standards in which case the procedures for
  1.6016 +   copyrights defined in the Internet Standards process must be
  1.6017 +   followed, or as required to translate it into languages other than
  1.6018 +   English.
  1.6019 +
  1.6020 +   The limited permissions granted above are perpetual and will not be
  1.6021 +   revoked by the Internet Society or its successors or assigns.  v This
  1.6022 +   document and the information contained herein is provided on an "AS
  1.6023 +   IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
  1.6024 +   FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
  1.6025 +   LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
  1.6026 +   NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
  1.6027 +   OR FITNESS FOR A PARTICULAR PURPOSE.
  1.6028 +
  1.6029 +Acknowledgement
  1.6030 +
  1.6031 +   Funding for the RFC Editor function is currently provided by the
  1.6032 +   Internet Society.
  1.6033 +
  1.6034 +
  1.6035 +
  1.6036 +
  1.6037 +
  1.6038 +
  1.6039 +
  1.6040 +
  1.6041 +
  1.6042 +
  1.6043 +
  1.6044 +
  1.6045 +
  1.6046 +
  1.6047 +
  1.6048 +
  1.6049 +
  1.6050 +
  1.6051 +
  1.6052 +
  1.6053 +Crispin                     Standards Track                   [Page 108]
  1.6054 +
  1.6055 +