rfc1730.txt
上传用户:horngjaan
上传日期:2009-12-12
资源大小:2882k
文件大小:153k
源码类别:

Email服务器

开发平台:

C#

  1. Network Working Group                                         M. Crispin
  2. Request for Comments: 1730                      University of Washington
  3. Category: Standards Track                                  December 1994
  4.               INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4
  5. Status of this Memo
  6.    This document specifies an Internet standards track protocol for the
  7.    Internet community, and requests discussion and suggestions for
  8.    improvements.  Please refer to the current edition of the "Internet
  9.    Official Protocol Standards" (STD 1) for the standardization state
  10.    and status of this protocol.  Distribution of this memo is unlimited.
  11. Abstract
  12.    The Internet Message Access Protocol, Version 4 (IMAP4) allows a
  13.    client to access and manipulate electronic mail messages on a server.
  14.    IMAP4 permits manipulation of remote message folders, called
  15.    "mailboxes", in a way that is functionally equivalent to local
  16.    mailboxes.  IMAP4 also provides the capability for an offline client
  17.    to resynchronize with the server (see also [IMAP-DISC]).
  18.    IMAP4 includes operations for creating, deleting, and renaming
  19.    mailboxes; checking for new messages; permanently removing messages;
  20.    setting and clearing flags; RFC 822 and MIME parsing; searching; and
  21.    selective fetching of message attributes, texts, and portions
  22.    thereof.  Messages in IMAP4 are accessed by the use of numbers.
  23.    These numbers are either message sequence numbers (relative position
  24.    from 1 to the number of messages in the mailbox) or unique
  25.    identifiers (immutable, strictly ascending values assigned to each
  26.    message, but which are not necessarily contiguous).
  27.    IMAP4 supports a single server.  A mechanism for supporting multiple
  28.    IMAP4 servers is discussed in [IMSP].
  29.    IMAP4 does not specify a means of posting mail; this function is
  30.    handled by a mail transfer protocol such as [SMTP].
  31.    IMAP4 is designed to be upwards compatible from the [IMAP2] protocol.
  32.    Compatibility issues are discussed in [IMAP-COMPAT].
  33. Crispin                                                         [Page i]
  34. RFC 1730                         IMAP4                     December 1994
  35. Table of Contents
  36. IMAP4 Protocol Specification ......................................    1
  37. 1.      Organization of this Document .............................    1
  38. 1.1.    How to Read This Document .................................    1
  39. 1.2.    Conventions Used in this Document .........................    1
  40. 2.      Protocol Overview .........................................    1
  41. 2.1.    Link Level ................................................    1
  42. 2.2.    Commands and Responses ....................................    1
  43. 2.2.1.  Client Protocol Sender and Server Protocol Receiver .......    2
  44. 2.2.2.  Server Protocol Sender and Client Protocol Receiver .......    2
  45. 3.      State and Flow Diagram ....................................    4
  46. 3.1.    Non-Authenticated State ...................................    4
  47. 3.2.    Authenticated State .......................................    4
  48. 3.3.    Selected State ............................................    4
  49. 3.4.    Logout State ..............................................    4
  50. 4.      Data Formats ..............................................    6
  51. 4.1.    Atom ......................................................    6
  52. 4.2.    Number ....................................................    6
  53. 4.3.    String ....................................................    6
  54. 4.3.1.  8-bit and Binary Strings ..................................    7
  55. 4.4.    Parenthesized List ........................................    7
  56. 4.5.    NIL .......................................................    7
  57. 5.      Operational Considerations ................................    8
  58. 5.1.    Mailbox Naming ............................................    8
  59. 5.2.    Mailbox Size and Message Status Updates ...................    8
  60. 5.3.    Response when no Command in Progress ......................    8
  61. 5.4.    Autologout Timer ..........................................    9
  62. 5.5.    Multiple Commands in Progress .............................    9
  63. 6.      Client Commands ...........................................   10
  64. 6.1.    Client Commands - Any State ...............................   10
  65. 6.1.1.  CAPABILITY Command ........................................   10
  66. 6.1.2.  NOOP Command ..............................................   11
  67. 6.1.3.  LOGOUT Command ............................................   11
  68. 6.2.    Client Commands - Non-Authenticated State .................   12
  69. 6.2.1.  AUTHENTICATE Command ......................................   12
  70. 6.2.2.  LOGIN Command .............................................   14
  71. 6.3.    Client Commands - Authenticated State .....................   14
  72. 6.3.1.  SELECT Command ............................................   15
  73. 6.3.2.  EXAMINE Command ...........................................   16
  74. 6.3.3.  CREATE Command ............................................   17
  75. 6.3.4.  DELETE Command ............................................   18
  76. 6.3.5.  RENAME Command ............................................   18
  77. Crispin                                                        [Page ii]
  78. RFC 1730                         IMAP4                     December 1994
  79. 6.3.6.  SUBSCRIBE Command .........................................   19
  80. 6.3.7.  UNSUBSCRIBE Command .......................................   19
  81. 6.3.8.  LIST Command ..............................................   20
  82. 6.3.9.  LSUB Command ..............................................   22
  83. 6.3.10. APPEND Command ............................................   22
  84. 6.4.    Client Commands - Selected State ..........................   23
  85. 6.4.1.  CHECK Command .............................................   23
  86. 6.4.2.  CLOSE Command .............................................   24
  87. 6.4.3.  EXPUNGE Command ...........................................   25
  88. 6.4.4.  SEARCH Command ............................................   25
  89. 6.4.5.  FETCH Command .............................................   29
  90. 6.4.6.  PARTIAL Command ...........................................   32
  91. 6.4.7.  STORE Command .............................................   33
  92. 6.4.8.  COPY Command ..............................................   34
  93. 6.4.9.  UID Command ...............................................   35
  94. 6.5.    Client Commands - Experimental/Expansion ..................   37
  95. 6.5.1.  X<atom> Command ...........................................   37
  96. 7.      Server Responses ..........................................   38
  97. 7.1.    Server Responses - Status Responses .......................   39
  98. 7.1.1.  OK Response ...............................................   40
  99. 7.1.2.  NO Response ...............................................   40
  100. 7.1.3.  BAD Response ..............................................   41
  101. 7.1.4.  PREAUTH Response ..........................................   41
  102. 7.1.5.  BYE Response ..............................................   41
  103. 7.2.    Server Responses - Server and Mailbox Status ..............   42
  104. 7.2.1.  CAPABILITY Response .......................................   42
  105. 7.2.2.  LIST Response .............................................   43
  106. 7.2.3.  LSUB Response .............................................   44
  107. 7.2.4.  SEARCH Response ...........................................   44
  108. 7.2.5.  FLAGS Response ............................................   44
  109. 7.3.    Server Responses - Message Status .........................   45
  110. 7.3.1.  EXISTS Response ...........................................   45
  111. 7.3.2.  RECENT Response ...........................................   45
  112. 7.3.3.  EXPUNGE Response ..........................................   45
  113. 7.3.4.  FETCH Response ............................................   46
  114. 7.3.5.  Obsolete Responses ........................................   51
  115. 7.4.    Server Responses - Command Continuation Request ...........   51
  116. 8.      Sample IMAP4 session ......................................   52
  117. 9.      Formal Syntax .............................................   53
  118. 10.     Author's Note .............................................   64
  119. 11.     Security Considerations ...................................   64
  120. 12.     Author's Address ..........................................   64
  121. Appendices ........................................................   65
  122. A.      Obsolete Commands .........................................   65
  123. A.6.3.OBS.1.    FIND ALL.MAILBOXES Command ........................   65
  124. A.6.3.OBS.2.    FIND MAILBOXES Command ............................   65
  125. A.6.3.OBS.3.    SUBSCRIBE MAILBOX Command .........................   66
  126. A.6.3.OBS.4.    UNSUBSCRIBE MAILBOX Command .......................   66
  127. Crispin                                                       [Page iii]
  128. RFC 1730                         IMAP4                     December 1994
  129. B.      Obsolete Responses ........................................   68
  130. B.7.2.OBS.1.    MAILBOX Response ..................................   68
  131. B.7.3.OBS.1.    COPY Response .....................................   68
  132. B.7.3.OBS.2.    STORE Response ....................................   69
  133. C.      References ................................................   70
  134. E.      IMAP4 Keyword Index .......................................   71
  135. Crispin                                                        [Page iv]
  136. RFC 1730                         IMAP4                     December 1994
  137. IMAP4 Protocol Specification
  138. 1.      Organization of this Document
  139. 1.1.    How to Read This Document
  140.    This document is written from the point of view of the implementor of
  141.    an IMAP4 client or server.  Beyond the protocol overview in section
  142.    2, it is not optimized for someone trying to understand the operation
  143.    of the protocol.  The material in sections 3 through 5 provides the
  144.    general context and definitions with which IMAP4 operates.
  145.    Sections 6, 7, and 9 describe the IMAP commands, responses, and
  146.    syntax, respectively.  The relationships among these are such that it
  147.    is almost impossible to understand any of them separately.  In
  148.    particular, one should not attempt to deduce command syntax from the
  149.    command section alone; one should instead refer to the formal syntax
  150.    section.
  151. 1.2.    Conventions Used in this Document
  152.    In examples, "C:" and "S:" indicate lines sent by the client and
  153.    server respectively.
  154. 2.      Protocol Overview
  155. 2.1.    Link Level
  156.    The IMAP4 protocol assumes a reliable data stream such as provided by
  157.    TCP.  When TCP is used, an IMAP4 server listens on port 143.
  158. 2.2.    Commands and Responses
  159.    An IMAP4 session consists of the establishment of a client/server
  160.    connection, an initial greeting from the server, and client/server
  161.    interactions.  These client/server interactions consist of a client
  162.    command, server data, and a server completion result response.
  163.    All interactions transmitted by client and server are in the form of
  164.    lines; that is, strings that end with a CRLF.  The protocol receiver
  165.    of an IMAP4 client or server is either reading a line, or is reading
  166.    a sequence of octets with a known count followed by a line.
  167. Crispin                                                         [Page 1]
  168. RFC 1730                         IMAP4                     December 1994
  169. 2.2.1.  Client Protocol Sender and Server Protocol Receiver
  170.    The client command begins an operation.  Each client command is
  171.    prefixed with a identifier (typically a short alphanumeric string,
  172.    e.g. A0001, A0002, etc.) called a "tag".  A different tag is
  173.    generated by the client for each command.
  174.    There are two cases in which a line from the client does not
  175.    represent a complete command.  In one case, a command argument is
  176.    quoted with an octet count (see the description of literal in String
  177.    under Data Formats); in the other case, the command arguments require
  178.    server feedback (see the AUTHENTICATE command).  In either case, the
  179.    server sends a command continuation request response if it is ready
  180.    for the octets (if appropriate) and the remainder of the command.
  181.    This response is prefixed with the token "+".
  182.         Note: If, instead, the server detected an error in the
  183.         command, it sends a BAD completion response with tag
  184.         matching the command (as described below) to reject the
  185.         command and prevent the client from sending any more of the
  186.         command.
  187.         It is also possible for the server to send a completion
  188.         response for some other command (if multiple commands are
  189.         in progress), or untagged data.  In either case, the
  190.         command continuation request is still pending; the client
  191.         takes the appropriate action for the response, and reads
  192.         another response from the server.
  193.    The protocol receiver of an IMAP4 server reads a command line from
  194.    the client, parses the command and its arguments, and transmits
  195.    server data and a server command completion result response.
  196. 2.2.2.  Server Protocol Sender and Client Protocol Receiver
  197.    Data transmitted by the server to the client and status responses
  198.    that do not indicate command completion are prefixed with the token
  199.    "*", and are called untagged responses.
  200.    Server data may be sent as a result of a client command, or may be
  201.    sent unilaterally by the server.  There is no syntactic difference
  202.    between server data that resulted from a specific command and server
  203.    data that were sent unilaterally.
  204.    The server completion result response indicates the success or
  205.    failure of the operation.  It is tagged with the same tag as the
  206.    client command which began the operation.  Thus, if more than one
  207. Crispin                                                         [Page 2]
  208. RFC 1730                         IMAP4                     December 1994
  209.    command is in progress, the tag in a server completion response
  210.    identifies the command to which the response applies.  There are
  211.    three possible server completion responses: OK (indicating success),
  212.    NO (indicating failure), or BAD (indicating protocol error such as
  213.    unrecognized command or command syntax error).
  214.    The protocol receiver of an IMAP4 client reads a response line from
  215.    the server.  It then takes action on the response based upon the
  216.    first token of the response, which may be a tag, a "*", or a "+".  As
  217.    described above.
  218.    A client MUST be prepared to accept any server response at all times.
  219.    This includes server data that it may not have requested.  Server
  220.    data SHOULD be recorded, so that the client can reference its
  221.    recorded copy rather than sending a command to the server to request
  222.    the data.  In the case of certain server data, recording the data is
  223.    mandatory.
  224.    This topic is discussed in greater detail in the Server Responses
  225.    section.
  226. Crispin                                                         [Page 3]
  227. RFC 1730                         IMAP4                     December 1994
  228. 3.      State and Flow Diagram
  229.    An IMAP4 server is in one of four states.  Most commands are valid in
  230.    only certain states.  It is a protocol error for the client to
  231.    attempt a command while the command is in an inappropriate state.  In
  232.    this case, a server will respond with a BAD or NO (depending upon
  233.    server implementation) command completion result.
  234. 3.1.    Non-Authenticated State
  235.    In non-authenticated state, the user must supply authentication
  236.    credentials before most commands will be permitted.  This state is
  237.    entered when a connection starts unless the connection has been
  238.    pre-authenticated.
  239. 3.2.    Authenticated State
  240.    In authenticated state, the user is authenticated and must select a
  241.    mailbox to access before commands that affect messages will be
  242.    permitted.  This state is entered when a pre-authenticated connection
  243.    starts, when acceptable authentication credentials have been
  244.    provided, or after an error in selecting a mailbox.
  245. 3.3.    Selected State
  246.    In selected state, a mailbox has been selected to access.  This state
  247.    is entered when a mailbox has been successfully selected.
  248. 3.4.    Logout State
  249.    In logout state, the session is being terminated, and the server will
  250.    close the connection.  This state can be entered as a result of a
  251.    client request or by unilateral server decision.
  252. Crispin                                                         [Page 4]
  253. RFC 1730                         IMAP4                     December 1994
  254.             +--------------------------------------+
  255.             |initial connection and server greeting|
  256.             +--------------------------------------+
  257.                       || (1)       || (2)        || (3)
  258.                       VV           ||            ||
  259.             +-----------------+    ||            ||
  260.             |non-authenticated|    ||            ||
  261.             +-----------------+    ||            ||
  262.              || (7)   || (4)       ||            ||
  263.              ||       VV           VV            ||
  264.              ||     +----------------+           ||
  265.              ||     | authenticated  |<=++       ||
  266.              ||     +----------------+  ||       ||
  267.              ||       || (7)   || (5)   || (6)   ||
  268.              ||       ||       VV       ||       ||
  269.              ||       ||    +--------+  ||       ||
  270.              ||       ||    |selected|==++       ||
  271.              ||       ||    +--------+           ||
  272.              ||       ||       || (7)            ||
  273.              VV       VV       VV                VV
  274.             +--------------------------------------+
  275.             |     logout and close connection      |
  276.             +--------------------------------------+
  277.          (1) connection without pre-authentication (OK greeting)
  278.          (2) pre-authenticated connection (PREAUTH greeting)
  279.          (3) rejected connection (BYE greeting)
  280.          (4) successful LOGIN or AUTHENTICATE command
  281.          (5) successful SELECT or EXAMINE command
  282.          (6) CLOSE command, or failed SELECT or EXAMINE command
  283.          (7) LOGOUT command, server shutdown, or connection closed
  284. Crispin                                                         [Page 5]
  285. RFC 1730                         IMAP4                     December 1994
  286. 4.      Data Formats
  287.    IMAP4 uses textual commands and responses.  Data in IMAP4 can be in
  288.    one of several forms: atom, number, string, parenthesized list, or
  289.    NIL.
  290. 4.1.    Atom
  291.    An atom consists of one or more non-special characters.
  292. 4.2.    Number
  293.    A number consists of one or more digit characters, and represents a
  294.    numeric value.
  295. 4.3.    String
  296.    A string is in one of two forms: literal and quoted string.  The
  297.    literal form is the general form of string.  The quoted string form
  298.    is an alternative that avoids the overhead of processing a literal at
  299.    the cost of restrictions of what may be in a quoted string.
  300.    A literal is a sequence of zero or more octets (including CR and LF),
  301.    prefix-quoted with an octet count in the form of an open brace ("{"),
  302.    the number of octets, close brace ("}"), and CRLF.  In the case of
  303.    literals transmitted from server to client, the CRLF is immediately
  304.    followed by the octet data.  In the case of literals transmitted from
  305.    client to server, the client must wait to receive a command
  306.    continuation request (described later in this document) before
  307.    sending the octet data (and the remainder of the command).
  308.    A quoted string is a sequence of zero or more 7-bit characters,
  309.    excluding CR and LF, with double quote (<">) characters at each end.
  310.    The empty string is respresented as either "" (a quoted string with
  311.    zero characters between double quotes) or as {0} followed by CRLF (a
  312.    literal with an octet count of 0).
  313.         Note: Even if the octet count is 0, a client transmitting a
  314.         literal must wait to receive a command continuation
  315.         request.
  316. Crispin                                                         [Page 6]
  317. RFC 1730                         IMAP4                     December 1994
  318. 4.3.1.  8-bit and Binary Strings
  319.    8-bit textual and binary mail is supported through the use of
  320.    [MIME-1] encoding.  IMAP4 implementations MAY transmit 8-bit or
  321.    multi-octet characters in literals, but should do so only when the
  322.    character set is identified.
  323.    Although a BINARY body encoding is defined, unencoded binary strings
  324.    are not permitted.  A "binary string" is any string with NUL
  325.    characters.  Implementations MUST encode binary data into a textual
  326.    form such as BASE64 before transmitting the data.  A string with an
  327.    excessive amount of CTL characters may also be considered to be
  328.    binary, although this is not required.
  329. 4.4.    Parenthesized List
  330.    Data structures are represented as a "parenthesized list"; a sequence
  331.    of data items, delimited by space, and bounded at each end by
  332.    parentheses.  A parenthesized list may itself contain other
  333.    parenthesized lists, using multiple levels of parentheses to indicate
  334.    nesting.
  335.    The empty list is represented as () -- a parenthesized list with no
  336.    members.
  337. 4.5.    NIL
  338.    The special atom "NIL" represents the non-existence of a particular
  339.    data item that is represented as a string or parenthesized list, as
  340.    distinct from the empty string "" or the empty parenthesized list ().
  341. Crispin                                                         [Page 7]
  342. RFC 1730                         IMAP4                     December 1994
  343. 5.      Operational Considerations
  344. 5.1.    Mailbox Naming
  345.    The interpretation of mailbox names is implementation-dependent.
  346.    However, the mailbox name INBOX is a special name reserved to mean
  347.    "the primary mailbox for this user on this server".  If it is desired
  348.    to export hierarchical mailbox names, mailbox names must be
  349.    left-to-right hierarchical using a single character to separate
  350.    levels of hierarchy.  The same hierarchy separator character is used
  351.    for all levels of hierarchy within a single name.
  352. 5.2.    Mailbox Size and Message Status Updates
  353.    At any time, a server can send data that the client did not request.
  354.    Sometimes, such behavior is required.  For example, agents other than
  355.    the server may add messages to the mailbox (e.g. new mail delivery),
  356.    change the flags of message in the mailbox (e.g. simultaneous access
  357.    to the same mailbox by multiple agents), or even remove messages from
  358.    the mailbox.  A server MUST send mailbox size updates automatically
  359.    if a mailbox size change is observed during the processing of a
  360.    command.  A server SHOULD send message flag updates automatically,
  361.    without requiring the client to request such updates explicitly.
  362.    Special rules exist for server notification of a client about the
  363.    removal of messages to prevent synchronization errors; see the
  364.    description of the EXPUNGE response for more details.
  365.    Regardless of what implementation decisions a client may take on
  366.    remembering data from the server, a client implementation MUST record
  367.    mailbox size updates.  It MUST NOT assume that any command after
  368.    initial mailbox selection will return the size of the mailbox.
  369. 5.3.    Response when no Command in Progress
  370.    Server implementations are permitted to send an untagged response
  371.    (except for EXPUNGE) while there is no command in progress.  Server
  372.    implementations that send such responses MUST deal with flow control
  373.    considerations.  Specifically, they must either (1) verify that the
  374.    size of the data does not exceed the underlying transport's available
  375.    window size, or (2) use non-blocking writes.
  376. Crispin                                                         [Page 8]
  377. RFC 1730                         IMAP4                     December 1994
  378. 5.4.    Autologout Timer
  379.    If a server has an inactivity autologout timer, that timer MUST be of
  380.    at least 30 minutes' duration.  The receipt of ANY command from the
  381.    client during that interval should suffice to reset the autologout
  382.    timer.
  383. 5.5.    Multiple Commands in Progress
  384.    The client is not required to wait for the completion result response
  385.    of a command before sending another command, subject to flow control
  386.    constraints on the underlying data stream.  Similarly, a server is
  387.    not required to process a command to completion before beginning
  388.    processing of the next command, unless an ambiguity would result
  389.    because of a command that would affect the results of other commands.
  390.    If there is such an ambiguity, the server executes commands to
  391.    completion in the order given by the client.
  392. Crispin                                                         [Page 9]
  393. RFC 1730                         IMAP4                     December 1994
  394. 6.      Client Commands
  395.    IMAP4 commands are described in this section.  Commands are organized
  396.    by the state in which the command is permitted.  Commands which are
  397.    permitted in multiple states are listed in the minimum permitted
  398.    state (for example, commands valid in authenticated and selected
  399.    state are listed in the authenticated state commands).
  400.    Command arguments, identified by "Arguments:" in the command
  401.    descriptions below, are described by function, not by syntax.  The
  402.    precise syntax of command arguments is described in the Formal Syntax
  403.    section.
  404.    Some commands cause specific server data to be returned; these are
  405.    identified by "Data:" in the command descriptions below.  See the
  406.    response descriptions in the Responses section for information on
  407.    these responses, and the Formal Syntax section for the precise syntax
  408.    of these responses.  It is possible for server data to be transmitted
  409.    as a result of any command; thus, commands that do not specifically
  410.    require server data specify "no specific data for this command"
  411.    instead of "none".
  412.    The "Result:" in the command description refers to the possible
  413.    tagged status responses to a command, and any special interpretation
  414.    of these status responses.
  415. 6.1.    Client Commands - Any State
  416.    The following commands are valid in any state: CAPABILITY, NOOP, and
  417.    LOGOUT.
  418. 6.1.1.  CAPABILITY Command
  419.    Arguments:  none
  420.    Data:       mandatory untagged response: CAPABILITY
  421.    Result:     OK - capability completed
  422.                BAD - command unknown or arguments invalid
  423.       The CAPABILITY command requests a listing of capabilities that the
  424.       server supports.  The server MUST send a single untagged
  425.       CAPABILITY response with "IMAP4" as the first listed capability
  426.       before the (tagged) OK response.  This listing of capabilities is
  427.       not dependent upon connection state or user.  It is therefore not
  428.       necessary to issue a CAPABILITY command more than once in a
  429.       session.
  430. Crispin                                                        [Page 10]
  431. RFC 1730                         IMAP4                     December 1994
  432.       Capability names other than "IMAP4" refer to extensions,
  433.       revisions, or amendments to this specification.  See the
  434.       documentation of the CAPABILITY response for additional
  435.       information.  No capabilities are enabled without explicit client
  436.       action to invoke the capability.  See the section entitled "Client
  437.       Commands - Experimental/Expansion" for information about the form
  438.       of site or implementation-specific capabilities.
  439.    Example:    C: abcd CAPABILITY
  440.                S: * CAPABILITY IMAP4
  441.                S: abcd OK CAPABILITY completed
  442. 6.1.2.  NOOP Command
  443.    Arguments:  none
  444.    Data:       no specific data for this command (but see below)
  445.    Result:     OK - noop completed
  446.                BAD - command unknown or arguments invalid
  447.       The NOOP command always succeeds.  It does nothing.
  448.       Since any command can return a status update as untagged data, the
  449.       NOOP command can be used as a periodic poll for new messages or
  450.       message status updates during a period of inactivity.  The NOOP
  451.       command can also be used to reset any inactivity autologout timer
  452.       on the server.
  453.    Example:    C: a002 NOOP
  454.                S: a002 OK NOOP completed
  455.                   . . .
  456.                C: a047 NOOP
  457.                S: * 22 EXPUNGE
  458.                S: * 23 EXISTS
  459.                S: * 3 RECENT
  460.                S: * 14 FETCH (FLAGS (Seen Deleted))
  461.                S: a047 OK NOOP completed
  462. Crispin                                                        [Page 11]
  463. RFC 1730                         IMAP4                     December 1994
  464. 6.1.3.  LOGOUT Command
  465.    Arguments:  none
  466.    Data:       mandatory untagged response: BYE
  467.    Result:     OK - logout completed
  468.                BAD - command unknown or arguments invalid
  469.       The LOGOUT command informs the server that the client is done with
  470.       the session.  The server must send a BYE untagged response before
  471.       the (tagged) OK response, and then close the network connection.
  472.    Example:    C: A023 LOGOUT
  473.                S: * BYE IMAP4 Server logging out
  474.                S: A023 OK LOGOUT completed
  475.                (Server and client then close the connection)
  476. 6.2.    Client Commands - Non-Authenticated State
  477.    In non-authenticated state, the AUTHENTICATE or LOGIN command
  478.    establishes authentication and enter authenticated state.  The
  479.    AUTHENTICATE command provides a general mechanism for a variety of
  480.    authentication techniques, whereas the LOGIN command uses the
  481.    traditional user name and plaintext password pair.
  482.    Server implementations may allow non-authenticated access to certain
  483.    mailboxes.  The convention is to use a LOGIN command with the userid
  484.    "anonymous".  A password is required.  It is implementation-dependent
  485.    what requirements, if any, are placed on the password and what access
  486.    restrictions are placed on anonymous users.
  487.    Once authenticated (including as anonymous), it is not possible to
  488.    re-enter non-authenticated state.
  489.    In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
  490.    the following commands are valid in non-authenticated state:
  491.    AUTHENTICATE and LOGIN.
  492. Crispin                                                        [Page 12]
  493. RFC 1730                         IMAP4                     December 1994
  494. 6.2.1.  AUTHENTICATE Command
  495.    Arguments:  authentication mechanism name
  496.    Data:       continuation data may be requested
  497.    Result:     OK - authenticate completed, now in authenticated state
  498.                NO - authenticate failure: unsupported authentication
  499.                     mechanism, credentials rejected
  500.                BAD - command unknown or arguments invalid,
  501.                     authentication exchange cancelled
  502.       The AUTHENTICATE command indicates an authentication mechanism,
  503.       such as described in [IMAP-AUTH], to the server.  If the server
  504.       supports the requested authentication mechanism, it performs an
  505.       authentication protocol exchange to authenticate and identify the
  506.       user.  Optionally, it also negotiates a protection mechanism for
  507.       subsequent protocol interactions.  If the requested authentication
  508.       mechanism is not supported, the server should reject the
  509.       AUTHENTICATE command by sending a tagged NO response.
  510.       The authentication protocol exchange consists of a series of
  511.       server challenges and client answers that are specific to the
  512.       authentication mechanism.  A server challenge consists of a
  513.       command continuation request response with the "+" token followed
  514.       by a BASE64 encoded string.  The client answer consists of a line
  515.       consisting of a BASE64 encoded string.  If the client wishes to
  516.       cancel an authentication exchange, it should issue a line with a
  517.       single "*".  If the server receives such an answer, it must reject
  518.       the AUTHENTICATE command by sending a tagged BAD response.
  519.       A protection mechanism provides integrity and privacy protection
  520.       to the protocol session.  If a protection mechanism is negotiated,
  521.       it is applied to all subsequent data sent over the connection.
  522.       The protection mechanism takes effect immediately following the
  523.       CRLF that concludes the authentication exchange for the client,
  524.       and the CRLF of the tagged OK response for the server.  Once the
  525.       protection mechanism is in effect, the stream of command and
  526.       response octets is processed into buffers of ciphertext.  Each
  527.       buffer is transferred over the connection as a stream of octets
  528.       prepended with a four octet field in network byte order that
  529.       represents the length of the following data.  The maximum
  530.       ciphertext buffer length is defined by the protection mechanism.
  531.       The server is not required to support any particular
  532.       authentication mechanism, nor are authentication mechanisms
  533.       required to support any protection mechanisms.  If an AUTHENTICATE
  534.       command fails with a NO response, the client may try another
  535. Crispin                                                        [Page 13]
  536. RFC 1730                         IMAP4                     December 1994
  537.       authentication mechanism by issuing another AUTHENTICATE command,
  538.       or may attempt to authenticate by using the LOGIN command.  In
  539.       other words, the client may request authentication types in
  540.       decreasing order of preference, with the LOGIN command as a last
  541.       resort.
  542.    Example:    S: * OK KerberosV4 IMAP4 Server
  543.                C: A001 AUTHENTICATE KERBEROS_V4
  544.                S: + AmFYig==
  545.                C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
  546.                   +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
  547.                   WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
  548.                S: + or//EoAADZI=
  549.                C: DiAF5A4gA+oOIALuBkAAmw==
  550.                S: A001 OK Kerberos V4 authentication successful
  551.         Note: the line breaks in the first client answer are for
  552.         editorial clarity and are not in real authenticators.
  553. 6.2.2.  LOGIN Command
  554.    Arguments:  user name
  555.                password
  556.    Data:       no specific data for this command
  557.    Result:     OK - login completed, now in authenticated state
  558.                NO - login failure: user name or password rejected
  559.                BAD - command unknown or arguments invalid
  560.       The LOGIN command identifies the user to the server and carries
  561.       the plaintext password authenticating this user.
  562.    Example:    C: a001 LOGIN SMITH SESAME
  563.                S: a001 OK LOGIN completed
  564. 6.3.    Client Commands - Authenticated State
  565.    In authenticated state, commands that manipulate mailboxes as atomic
  566.    entities are permitted.  Of these commands, the SELECT and EXAMINE
  567.    commands will select a mailbox for access and enter selected state.
  568. Crispin                                                        [Page 14]
  569. RFC 1730                         IMAP4                     December 1994
  570.    In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
  571.    the following commands are valid in authenticated state: SELECT,
  572.    EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB,
  573.    and APPEND.
  574. 6.3.1.  SELECT Command
  575.    Arguments:  mailbox name
  576.    Data:       mandatory untagged responses: FLAGS, EXISTS, RECENT
  577.                optional OK untagged responses: UNSEEN, PERMANENTFLAGS
  578.    Result:     OK - select completed, now in selected state
  579.                NO - select failure, now in authenticated state: no
  580.                     such mailbox, can't access mailbox
  581.                BAD - command unknown or arguments invalid
  582.       The SELECT command selects a  mailbox  so  that  messages  in  the
  583.       mailbox  can  be  accessed.  Before returning an OK to the client,
  584.       the server MUST send the following untagged data to the client:
  585.          FLAGS       Defined flags in the mailbox
  586.          <n> EXISTS  The number of messages in the mailbox
  587.          <n> RECENT  The number of messages added to the  mailbox  since
  588.                      the previous time this mailbox was read
  589.          OK [UIDVALIDITY <n>]
  590.                      The unique  identifier  validity  value.   See  the
  591.                      description of the UID command for more detail.
  592.       to define the initial state of the mailbox at the client.  If it
  593.       is not possible to determine the messages that were added since
  594.       the previous time a mailbox was read, then all messages SHOULD be
  595.       considered recent.
  596.       The server SHOULD also send an UNSEEN response code in an OK
  597.       untagged response, indicating the message sequence number of the
  598.       first unseen message in the mailbox.
  599.       If the client can not change the permanent state of one or more of
  600.       the flags listed in the FLAGS untagged response, the server SHOULD
  601.       send a PERMANENTFLAGS response code in an OK untagged response,
  602.       listing the flags that the client may change permanently.
  603.       Only one mailbox may be selected at a time in a session;
  604.       simultaneous access to multiple mailboxes requires multiple
  605. Crispin                                                        [Page 15]
  606. RFC 1730                         IMAP4                     December 1994
  607.       sessions.  The SELECT command automatically deselects any
  608.       currently selected mailbox before attempting the new selection.
  609.       Consequently, if a mailbox is selected and a SELECT command that
  610.       fails is attempted, no mailbox is selected.
  611.       If the user is permitted to modify the mailbox, the server SHOULD
  612.       prefix the text of the tagged OK response with the "[READ-WRITE]"
  613.       response code.
  614.       If the user is not permitted to modify the mailbox but is
  615.       permitted read access, the mailbox is selected as read-only, and
  616.       the server MUST prefix the text of the tagged OK response to
  617.       SELECT with the "[READ-ONLY]" response code.  Read-only access
  618.       through SELECT differs from the EXAMINE command in that certain
  619.       read-only mailboxes may permit the change of permanent state on a
  620.       per-user (as opposed to global) basis.  Netnews messages marked in
  621.       a user's .newsrc file are an example of such per-user permanent
  622.       state that can be modified with read-only mailboxes.
  623.    Example:    C: A142 SELECT INBOX
  624.                S: * 172 EXISTS
  625.                S: * 1 RECENT
  626.                S: * OK [UNSEEN 12] Message 12 is first unseen
  627.                S: * OK [UIDVALIDITY 3857529045] UIDs valid
  628.                S: * FLAGS (Answered Flagged Deleted Seen Draft)
  629.                S: * OK [PERMANENTFLAGS (Deleted Seen *)] Limited
  630.                S: A142 OK [READ-WRITE] SELECT completed
  631. 6.3.2.  EXAMINE Command
  632.    Arguments:  mailbox name
  633.    Data:       mandatory untagged responses: FLAGS, EXISTS, RECENT
  634.                optional OK untagged responses: UNSEEN, PERMANENTFLAGS
  635.    Result:     OK - examine completed, now in selected state
  636.                NO - examine failure, now in authenticated state: no
  637.                     such mailbox, can't access mailbox
  638.                BAD - command unknown or arguments invalid
  639.       The EXAMINE command is identical to SELECT and returns the same
  640.       output; however, the selected mailbox is identified as read-only.
  641.       No changes to the permanent state of the mailbox, including
  642.       per-user state, are permitted.
  643. Crispin                                                        [Page 16]
  644. RFC 1730                         IMAP4                     December 1994
  645.       The text of the tagged OK response to the EXAMINE command MUST
  646.       begin with the "[READ-ONLY]" response code.
  647.    Example:    C: A932 EXAMINE blurdybloop
  648.                S: * 17 EXISTS
  649.                S: * 2 RECENT
  650.                S: * OK [UNSEEN 8] Message 8 is first unseen
  651.                S: * OK [UIDVALIDITY 3857529045] UIDs valid
  652.                S: * FLAGS (Answered Flagged Deleted Seen Draft)
  653.                S: * OK [PERMANENTFLAGS ()] No permanent flags permitted
  654.                S: A932 OK [READ-ONLY] EXAMINE completed
  655. 6.3.3.  CREATE Command
  656.    Arguments:  mailbox name
  657.    Data:       no specific data for this command
  658.    Result:     OK - create completed
  659.                NO - create failure: can't create mailbox with that name
  660.                BAD - command unknown or arguments invalid
  661.       The CREATE command creates a mailbox with the given name.  An OK
  662.       response is returned only if a new mailbox with that name has been
  663.       created.  It is an error to attempt to create INBOX or a mailbox
  664.       with a name that refers to an extant mailbox.  Any error in
  665.       creation will return a tagged NO response.
  666.       If the mailbox name is suffixed with the server's hierarchy
  667.       separator character (as returned from the server by a LIST
  668.       command), this is a declaration that the client may, in the
  669.       future, create mailbox names under this name in the hierarchy.
  670.       Server implementations that do not require this declaration MUST
  671.       ignore it.
  672.       If a new mailbox is created with the same name as a mailbox which
  673.       was deleted, its unique identifiers MUST be greater than any
  674.       unique identifiers used in the previous incarnation of the mailbox
  675.       UNLESS the new incarnation has a different unique identifier
  676.       validity value.  See the description of the UID command for more
  677.       detail.
  678.    Example:    C: A003 CREATE owatagusiam/
  679.                S: A003 OK CREATE completed
  680.                C: A004 CREATE owatagusiam/blurdybloop
  681.                S: A004 OK CREATE completed
  682. Crispin                                                        [Page 17]
  683. RFC 1730                         IMAP4                     December 1994
  684.         Note: the interpretation of this example depends on whether
  685.         "/" was returned as the hierarchy separator from LIST.  If
  686.         "/" is the hierarchy separator, a new level of hierarchy
  687.         named "owatagusiam" with a member called "blurdybloop" is
  688.         created.  Otherwise, two mailboxes at the same hierarchy
  689.         level are created.
  690. 6.3.4.  DELETE Command
  691.    Arguments:  mailbox name
  692.    Data:       no specific data for this command
  693.    Result:     OK - delete completed
  694.                NO - delete failure: can't delete mailbox with that name
  695.                BAD - command unknown or arguments invalid
  696.       The DELETE command permanently removes the mailbox with the given
  697.       name.  A tagged OK response is returned only if the mailbox has
  698.       been deleted.  It is an error to attempt to delete INBOX or a
  699.       mailbox name that does not exist.  Any error in deletion will
  700.       return a tagged NO response.
  701.       The value of the highest-used unique indentifier of the deleted
  702.       mailbox MUST be preserved so that a new mailbox created with the
  703.       same name will not reuse the identifiers of the former
  704.       incarnation, UNLESS the new incarnation has a different unique
  705.       identifier validity value.  See the description of the UID command
  706.       for more detail.
  707.    Example:    C: A683 DELETE blurdybloop
  708.                S: A683 OK DELETE completed
  709. 6.3.5.  RENAME Command
  710.    Arguments:  existing mailbox name
  711.                new mailbox name
  712.    Data:       no specific data for this command
  713.    Result:     OK - rename completed
  714.                NO - rename failure: can't rename mailbox with that name,
  715.                     can't rename to mailbox with that name
  716.                BAD - command unknown or arguments invalid
  717. Crispin                                                        [Page 18]
  718. RFC 1730                         IMAP4                     December 1994
  719.       The RENAME command changes the name of a mailbox.  A tagged OK
  720.       response is returned only if the mailbox has been renamed.  It is
  721.       an error to attempt to rename from a mailbox name that does not
  722.       exist or to a mailbox name that already exists.  Any error in
  723.       renaming will return a tagged NO response.
  724.       Renaming INBOX is permitted; a new, empty INBOX is created in its
  725.       place.
  726.    Example:    C: Z4S9 RENAME blurdybloop owatagusiam
  727.                S: Z4S9 OK RENAME completed
  728. 6.3.6.  SUBSCRIBE Command
  729.    Arguments:  mailbox
  730.    Data:       no specific data for this command
  731.    Result:     OK - subscribe completed
  732.                NO - subscribe failure: can't subscribe to that name
  733.                BAD - command unknown or arguments invalid
  734.       The SUBSCRIBE command adds the specified mailbox name to the
  735.       server's set of "active" or "subscribed" mailboxes as returned by
  736.       the LSUB command.  This command returns a tagged OK response only
  737.       if the subscription is successful.
  738.    Example:    C: A002 SUBSCRIBE #news.comp.mail.mime
  739.                S: A002 OK SUBSCRIBE completed
  740. 6.3.7.  UNSUBSCRIBE Command
  741.    Arguments:  mailbox name
  742.    Data:       no specific data for this command
  743.    Result:     OK - unsubscribe completed
  744.                NO - unsubscribe failure: can't unsubscribe that name
  745.                BAD - command unknown or arguments invalid
  746.       The UNSUBSCRIBE command removes the specified mailbox name from
  747.       the server's set of "active" or "subscribed" mailboxes as returned
  748.       by the LSUB command.  This command returns a tagged OK response
  749.       only if the unsubscription is successful.
  750. Crispin                                                        [Page 19]
  751. RFC 1730                         IMAP4                     December 1994
  752.    Example:    C: A002 UNSUBSCRIBE #news.comp.mail.mime
  753.                S: A002 OK UNSUBSCRIBE completed
  754. 6.3.8.  LIST Command
  755.    Arguments:  reference name
  756.                mailbox name with possible wildcards
  757.    Data:       untagged responses: LIST
  758.    Result:     OK - list completed
  759.                NO - list failure: can't list that reference or name
  760.                BAD - command unknown or arguments invalid
  761.       The LIST command returns a subset of names from the complete set
  762.       of all names available to the user.  Zero or more untagged LIST
  763.       replies are returned, containing the name attributes, hierarchy
  764.       delimiter, and name; see the description of the LIST reply for
  765.       more detail.
  766.       An empty ("" string) reference name argument indicates that the
  767.       mailbox name is interpreted as by SELECT. The returned mailbox
  768.       names MUST match the supplied mailbox name pattern.  A non-empty
  769.       reference name argument is the name of a mailbox or a level of
  770.       mailbox hierarchy, and indicates a context in which the mailbox
  771.       name is interpreted in an implementation-defined manner.
  772.       The reference and mailbox name arguments are interpreted, in an
  773.       implementation-dependent fashion, into a canonical form that
  774.       represents an unambiguous left-to-right hierarchy.  The returned
  775.       mailbox names will be in the interpreted form.
  776.       Any part of the reference argument that is included in the
  777.       interpreted form SHOULD prefix the interpreted form.  It should
  778.       also be in the same form as the reference name argument.  This
  779.       rule permits the client to determine if the returned mailbox name
  780.       is in the context of the reference argument, or if something about
  781.       the mailbox argument overrode the reference argument.  Without
  782.       this rule, the client would have to have knowledge of the server's
  783.       naming semantics including what characters are "breakouts" that
  784.       override a naming context.
  785. Crispin                                                        [Page 20]
  786. RFC 1730                         IMAP4                     December 1994
  787.            For example, here are some examples of how references
  788.            and mailbox names might be interpreted on a UNIX-based
  789.            server:
  790.                Reference     Mailbox Name  Interpretation
  791.                ------------  ------------  --------------
  792.                ~smith/Mail/  foo.*         ~smith/Mail/foo.*
  793.                archive/      %             archive/%
  794.                #news.        comp.mail.*   #news.comp.mail.*
  795.                ~smith/Mail/  /usr/doc/foo  /usr/doc/foo
  796.                archive/      ~fred/Mail/*  ~fred/Mail/*
  797.            The first three examples demonstrate interpretations in
  798.            the context of the reference argument.  Note that
  799.            "~smith/Mail" should not be transformed into something
  800.            like "/u2/users/smith/Mail", or it would be impossible
  801.            for the client to determine that the interpretation was
  802.            in the context of the reference.
  803.       The character "*" is a wildcard, and matches zero or more
  804.       characters at this position.  The character "%" is similar to "*",
  805.       but it does not match a hierarchy delimiter.  If the "%" wildcard
  806.       is the last character of a mailbox name argument, matching levels
  807.       of hierarchy are also returned.  If these levels of hierarchy are
  808.       not also selectable mailboxes, they are returned with the
  809.       Noselect mailbox name attribute (see the description of the LIST
  810.       response for more detail).
  811.       Server implementations are permitted to "hide" otherwise
  812.       accessible mailboxes from the wildcard characters, by preventing
  813.       certain characters or names from matching a wildcard in certain
  814.       situations.  For example, a UNIX-based server might restrict the
  815.       interpretation of "*" so that an initial "/" character does not
  816.       match.
  817.       The special name INBOX is included in the output from LIST if it
  818.       matches the input arguments and INBOX is supported by this server
  819.       for this user.  The criteria for omitting INBOX is whether SELECT
  820.       INBOX will return failure; it is not relevant whether the user's
  821.       real INBOX resides on this or some other server.
  822.    Example:    C: A002 LIST "~/Mail/" "%"
  823.                S: * LIST (Noselect) "/" ~/Mail/foo
  824.                S: * LIST () "/" ~/Mail/meetings
  825.                S: A002 OK LIST completed
  826. Crispin                                                        [Page 21]
  827. RFC 1730                         IMAP4                     December 1994
  828. 6.3.9.  LSUB Command
  829.    Arguments:  reference name
  830.                mailbox name with possible wildcards
  831.    Data:       untagged responses: LSUB
  832.    Result:     OK - lsub completed
  833.                NO - lsub failure: can't list that reference or name
  834.                BAD - command unknown or arguments invalid
  835.       The LSUB command returns a subset of names from the set of names
  836.       that the user has declared as being "active" or "subscribed".
  837.       Zero or more untagged LSUB replies are returned.  The arguments to
  838.       LSUB are in the same form as those for LIST.
  839.    Example:    C: A002 LSUB "#news." "comp.mail.*"
  840.                S: * LSUB () "." #news.comp.mail.mime
  841.                S: * LSUB () "." #news.comp.mail.misc
  842.                S: A002 OK LSUB completed
  843. 6.3.10. APPEND Command
  844.    Arguments:  mailbox name
  845.                optional flag parenthesized list
  846.                optional date/time string
  847.                message literal
  848.    Data:       no specific data for this command
  849.    Result:     OK - append completed
  850.                NO - append error: can't append to that mailbox, error
  851.                     in flags or date/time or message text
  852.                BAD - command unknown or arguments invalid
  853.       The APPEND command appends the literal argument as a new message
  854.       in the specified destination mailbox.  This argument is in the
  855.       format of an [RFC-822] message.  8-bit characters are permitted in
  856.       the message.  A server implementation that is unable to preserve
  857.       8-bit data properly MUST be able to reversibly convert 8-bit
  858.       APPEND data to 7-bit using [MIME-1] encoding.
  859.       If a flag parenthesized list or date_time are specified, that data
  860.       SHOULD be set in the resulting message; otherwise, the defaults of
  861.       empty flags and the current date/time are used.
  862. Crispin                                                        [Page 22]
  863. RFC 1730                         IMAP4                     December 1994
  864.       If the append is unsuccessful for any reason, the mailbox MUST be
  865.       restored to its state before the APPEND attempt; no partial
  866.       appending is permitted.  If the mailbox is currently selected, the
  867.       normal new mail actions should occur.
  868.       If the destination mailbox does not exist, a server MUST return an
  869.       error, and MUST NOT automatically create the mailbox.  Unless it
  870.       is certain that the destination mailbox can not be created, the
  871.       server MUST send the response code "[TRYCREATE]" as the prefix of
  872.       the text of the tagged NO response.  This gives a hint to the
  873.       client that it can attempt a CREATE command and retry the APPEND
  874.       if the CREATE is successful.
  875.    Example:    C: A003 APPEND saved-messages (Seen) {310}
  876.                C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
  877.                C: From: Fred Foobar <foobar@Blurdybloop.COM>
  878.                C: Subject: afternoon meeting
  879.                C: To: mooch@owatagu.siam.edu
  880.                C: Message-Id: <B27397-0100000@Blurdybloop.COM>
  881.                C: MIME-Version: 1.0
  882.                C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
  883.                C:
  884.                C: Hello Joe, do you think we can meet at 3:30 tomorrow?
  885.                C:
  886.                S: A003 OK APPEND completed
  887.         Note: the APPEND command is not used for message delivery,
  888.         because it does not provide a mechanism to transfer [SMTP]
  889.         envelope information.
  890. 6.4.    Client Commands - Selected State
  891.    In selected state, commands that manipulate messages in a mailbox are
  892.    permitted.
  893.    In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
  894.    and the authenticated state commands (SELECT, EXAMINE, CREATE,
  895.    DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, FIND
  896.    ALL.MAILBOXES, FIND MAILBOXES, and APPEND), the following commands
  897.    are valid in the selected state: CHECK, CLOSE, EXPUNGE, SEARCH,
  898.    FETCH, PARTIAL, STORE, COPY, and UID.
  899. Crispin                                                        [Page 23]
  900. RFC 1730                         IMAP4                     December 1994
  901. 6.4.1.  CHECK Command
  902.    Arguments:  none
  903.    Data:       no specific data for this command
  904.    Result:     OK - check completed
  905.                BAD - command unknown or arguments invalid
  906.       The CHECK command requests a checkpoint of the currently selected
  907.       mailbox.  A checkpoint refers to any implementation-dependent
  908.       housekeeping associated with the mailbox (e.g. resolving the
  909.       server's in-memory state of the mailbox with the state on its
  910.       disk) that is not normally executed as part of each command.  A
  911.       checkpoint may take a non-instantaneous amount of real time to
  912.       complete.  If a server implementation has no such housekeeping
  913.       considerations, CHECK is equivalent to NOOP.
  914.       There is no guarantee that an EXISTS untagged response will happen
  915.       as a result of CHECK.  NOOP, not CHECK, should be used for new
  916.       mail polling.
  917.    Example:    C: FXXZ CHECK
  918.                S: FXXZ OK CHECK Completed
  919. 6.4.2.  CLOSE Command
  920.    Arguments:  none
  921.    Data:       no specific data for this command
  922.    Result:     OK - close completed, now in authenticated state
  923.                NO - close failure: no mailbox selected
  924.                BAD - command unknown or arguments invalid
  925.       The CLOSE command permanently removes from the currently selected
  926.       mailbox all messages that have the Deleted flag set, and returns
  927.       to authenticated state from selected state.  No untagged EXPUNGE
  928.       responses are sent.
  929.       No messages are removed, and no error is given, if the mailbox is
  930.       selected by an EXAMINE command or is otherwise selected read-only.
  931.       Even when a mailbox is selected, it is not required to send a
  932.       CLOSE command before a SELECT, EXAMINE, or LOGOUT command.  The
  933.       SELECT, EXAMINE, and LOGOUT commands implicitly close the
  934.       currently selected mailbox without doing an expunge.  However,
  935. Crispin                                                        [Page 24]
  936. RFC 1730                         IMAP4                     December 1994
  937.       when many messages are deleted, a CLOSE-LOGOUT or CLOSE-SELECT
  938.       sequence is considerably faster than an EXPUNGE-LOGOUT or
  939.       EXPUNGE-SELECT because no untagged EXPUNGE responses (which the
  940.       client would probably ignore) are sent.
  941.    Example:    C: A341 CLOSE
  942.                S: A341 OK CLOSE completed
  943. 6.4.3.  EXPUNGE Command
  944.    Arguments:  none
  945.    Data:       untagged responses: EXPUNGE
  946.    Result:     OK - expunge completed
  947.                NO - expunge failure: can't expunge (e.g. permission
  948.                     denied)
  949.                BAD - command unknown or arguments invalid
  950.       The EXPUNGE command permanently removes from the currently
  951.       selected mailbox all messages that have the Deleted flag set.
  952.       Before returning an OK to the client, an untagged EXPUNGE response
  953.       is sent for each message that is removed.
  954.    Example:    C: A202 EXPUNGE
  955.                S: * 3 EXPUNGE
  956.                S: * 3 EXPUNGE
  957.                S: * 5 EXPUNGE
  958.                S: * 8 EXPUNGE
  959.                S: A202 OK EXPUNGE completed
  960.         Note: in this example, messages 3, 4, 7, and 11 had the
  961.         Deleted flag set.  See the description of the EXPUNGE
  962.         response for further explanation.
  963. Crispin                                                        [Page 25]
  964. RFC 1730                         IMAP4                     December 1994
  965. 6.4.4.  SEARCH Command
  966.    Arguments:  optional character set specification
  967.                searching criteria (one or more)
  968.    Data:       mandatory untagged response: SEARCH
  969.    Result:     OK - search completed
  970.                NO - search error: can't search that character set or
  971.                     criteria
  972.                BAD - command unknown or arguments invalid
  973.       The SEARCH command searches the mailbox for messages that match
  974.       the given searching criteria.  Searching criteria consist of one
  975.       or more search keys.  The untagged SEARCH response from the server
  976.       contains a listing of message sequence numbers corresponding to
  977.       those messages that match the searching criteria.
  978.       When multiple keys are specified, the result is the intersection
  979.       (AND function) of all the messages that match those keys.  For
  980.       example, the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers
  981.       to all deleted messages from Smith that were placed in the mailbox
  982.       since February 1, 1994.  A search key may also be a parenthesized
  983.       list of one or more search keys (e.g. for use with the OR and NOT
  984.       keys).
  985.       Server implementations MAY exclude [MIME-1] body parts with
  986.       terminal content types other than TEXT and MESSAGE from
  987.       consideration in SEARCH matching.
  988.       The optional character set specification consists of the word
  989.       "CHARSET" followed by a registered MIME character set.  It
  990.       indicates the character set of the strings that appear in the
  991.       search criteria.  [MIME-2] strings that appear in RFC 822/MIME
  992.       message headers, and [MIME-1] content transfer encodings, MUST be
  993.       decoded before matching.  Except for US-ASCII, it is not required
  994.       that any particular character set be supported.  If the server
  995.       does not support the specified character set, it MUST return a
  996.       tagged NO response (not a BAD).
  997.       In all search keys that use strings, a message matches the key if
  998.       the string is a substring of the field.  The matching is
  999.       case-insensitive.
  1000. Crispin                                                        [Page 26]
  1001. RFC 1730                         IMAP4                     December 1994
  1002.       The defined search keys are as follows.  Refer to the Formal
  1003.       Syntax section for the precise syntactic definitions of the
  1004.       arguments.
  1005.       <message set>  Messages with message sequence numbers
  1006.                      corresponding to the specified message sequence
  1007.                      number set
  1008.       ALL            All messages in the mailbox; the default initial
  1009.                      key for ANDing.
  1010.       ANSWERED       Messages with the Answered flag set.
  1011.       BCC <string>   Messages that contain the specified string in the
  1012.                      envelope structure's BCC field.
  1013.       BEFORE <date>  Messages whose internal date is earlier than the
  1014.                      specified date.
  1015.       BODY <string>  Messages that contain the specified string in the
  1016.                      body of the message.
  1017.       CC <string>    Messages that contain the specified string in the
  1018.                      envelope structure's CC field.
  1019.       DELETED        Messages with the Deleted flag set.
  1020.       DRAFT          Messages with the Draft flag set.
  1021.       FLAGGED        Messages with the Flagged flag set.
  1022.       FROM <string>  Messages that contain the specified string in the
  1023.                      envelope structure's FROM field.
  1024.       HEADER <field-name> <string>
  1025.                      Messages that have a header with the specified
  1026.                      field-name (as defined in [RFC-822]) and that
  1027.                      contains the specified string in the [RFC-822]
  1028.                      field-body.
  1029.       KEYWORD <flag> Messages with the specified keyword set.
  1030.       LARGER <n>     Messages with an RFC822.SIZE larger than the
  1031.                      specified number of octets.
  1032.       NEW            Messages that have the Recent flag set but not the
  1033.                      Seen flag.  This is functionally equivalent to
  1034.                      "(RECENT UNSEEN)".
  1035. Crispin                                                        [Page 27]
  1036. RFC 1730                         IMAP4                     December 1994
  1037.       NOT <search-key>
  1038.                      Messages that do not match the specified search
  1039.                      key.
  1040.       OLD            Messages that do not have the Recent flag set.
  1041.                      This is functionally equivalent to "NOT RECENT" (as
  1042.                      opposed to "NOT NEW").
  1043.       ON <date>      Messages whose internal date is within the
  1044.                      specified date.
  1045.       OR <search-key1> <search-key2>
  1046.                      Messages that match either search key.
  1047.       RECENT         Messages that have the Recent flag set.
  1048.       SEEN           Messages that have the Seen flag set.
  1049.       SENTBEFORE <date>
  1050.                      Messages whose [RFC-822] Date: header is earlier
  1051.                      than the specified date.
  1052.       SENTON <date>  Messages whose [RFC-822] Date: header is within the
  1053.                      specified date.
  1054.       SENTSINCE <date>
  1055.                      Messages whose [RFC-822] Date: header is within or
  1056.                      later than the specified date.
  1057.       SINCE <date>   Messages whose internal date is within or later
  1058.                      than the specified date.
  1059.       SMALLER <n>    Messages with an RFC822.SIZE smaller than the
  1060.                      specified number of octets.
  1061.       SUBJECT <string>
  1062.                      Messages that contain the specified string in the
  1063.                      envelope structure's SUBJECT field.
  1064.       TEXT <string>  Messages that contain the specified string in the
  1065.                      header or body of the message.
  1066.       TO <string>    Messages that contain the specified string in the
  1067.                      envelope structure's TO field.
  1068.       UID <message set>
  1069.                      Messages with unique identifiers corresponding to
  1070.                      the specified unique identifier set.
  1071. Crispin                                                        [Page 28]
  1072. RFC 1730                         IMAP4                     December 1994
  1073.       UNANSWERED     Messages that do not have the Answered flag set.
  1074.       UNDELETED      Messages that do not have the Deleted flag set.
  1075.       UNDRAFT        Messages that do not have the Draft flag set.
  1076.       UNFLAGGED      Messages that do not have the Flagged flag set.
  1077.       UNKEYWORD <flag>
  1078.                      Messages that do not have the specified keyword
  1079.                      set.
  1080.       UNSEEN         Messages that do not have the Seen flag set.
  1081.    Example:    C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith"
  1082.                S: * SEARCH 2 84 882
  1083.                S: A282 OK SEARCH completed
  1084. 6.4.5.  FETCH Command
  1085.    Arguments:  message set
  1086.                message data item names
  1087.    Data:       untagged responses: FETCH
  1088.    Result:     OK - fetch completed
  1089.                NO - fetch error: can't fetch that data
  1090.                BAD - command unknown or arguments invalid
  1091.       The FETCH command retrieves data associated with a message in the
  1092.       mailbox.  The data items to be fetched may be either a single atom
  1093.       or a parenthesized list.  The currently defined data items that
  1094.       can be fetched are:
  1095.       ALL            Macro equivalent to: (FLAGS INTERNALDATE
  1096.                      RFC822.SIZE ENVELOPE)
  1097.       BODY           Non-extensible form of BODYSTRUCTURE.
  1098.       BODY[<section>]
  1099.                      The text of a particular body section.  The section
  1100.                      specification is a set of one or more part numbers
  1101.                      delimited by periods.
  1102.                      Single-part messages only have a part 1.
  1103. Crispin                                                        [Page 29]
  1104. RFC 1730                         IMAP4                     December 1994
  1105.                      Multipart messages are assigned consecutive part
  1106.                      numbers, as they occur in the message.  If a
  1107.                      particular part is of type message or multipart,
  1108.                      its parts must be indicated by a period followed by
  1109.                      the part number within that nested multipart part.
  1110.                      It is not permitted to fetch a multipart part
  1111.                      itself, only its individual members.
  1112.                      A part of type MESSAGE and subtype RFC822 also has
  1113.                      nested parts.  These are the parts of the MESSAGE
  1114.                      part's body.  Nested part 0 of a part of type
  1115.                      MESSAGE and subtype RFC822 is the [RFC-822] header
  1116.                      of the message.
  1117.                      Every message has at least one part.
  1118.                           Here is an example of a complex message
  1119.                           with its associated section
  1120.                           specifications:
  1121.                            0   ([RFC-822] header of the message)
  1122.                                MULTIPART/MIXED
  1123.                            1   TEXT/PLAIN
  1124.                            2   APPLICATION/OCTET-STREAM
  1125.                            3   MESSAGE/RFC822
  1126.                            3.0   ([RFC-822] header of the message)
  1127.                            3.1   TEXT/PLAIN
  1128.                            3.2   APPLICATION/OCTET-STREAM
  1129.                                  MULTIPART/MIXED
  1130.                            4.1   IMAGE/GIF
  1131.                            4.2   MESSAGE/RFC822
  1132.                            4.2.0   ([RFC-822] header of the message)
  1133.                            4.2.1   TEXT/PLAIN
  1134.                                    MULTIPART/ALTERNATIVE
  1135.                            4.2.2.1  TEXT/PLAIN
  1136.                            4.2.2.2  TEXT/RICHTEXT
  1137.                           Note that there is no section
  1138.                           specification for the Multi-part parts
  1139.                           (no section 4 or 4.2.2).
  1140.                      The Seen flag is implicitly set; if this causes
  1141.                      the flags to change they should be included as part
  1142.                      of the fetch responses.
  1143.       BODY.PEEK[<section>]
  1144.                      An alternate form of BODY[section] that does not
  1145.                      implicitly set the Seen flag.
  1146. Crispin                                                        [Page 30]
  1147. RFC 1730                         IMAP4                     December 1994
  1148.       BODYSTRUCTURE  The [MIME-1] body structure of the message.  This
  1149.                      is computed by the server by parsing the [MIME-1]
  1150.                      header lines.
  1151.       ENVELOPE       The envelope structure of the message.  This is
  1152.                      computed by the server by parsing the [RFC-822]
  1153.                      header into the component parts, defaulting various
  1154.                      fields as necessary.
  1155.       FAST           Macro equivalent to: (FLAGS INTERNALDATE
  1156.                      RFC822.SIZE)
  1157.       FLAGS          The flags that are set for this message.
  1158.       FULL           Macro equivalent to: (FLAGS INTERNALDATE
  1159.                      RFC822.SIZE ENVELOPE BODY)
  1160.       INTERNALDATE   The date and time of final delivery of the message
  1161.                      as defined by RFC 821.
  1162.       RFC822         The message in [RFC-822] format.  The Seen flag is
  1163.                      implicitly set; if this causes the flags to change
  1164.                      they should be included as part of the fetch
  1165.                      responses.  This is the concatenation of
  1166.                      RFC822.HEADER and RFC822.TEXT.
  1167.       RFC822.PEEK    An alternate form of RFC822 that does not
  1168.                      implicitly set the Seen flag.
  1169.       RFC822.HEADER  The [RFC-822] format header of the message as
  1170.                      stored on the server including the delimiting blank
  1171.                      line between the header and the body.
  1172.       RFC822.HEADER.LINES <header_list>
  1173.                      All header lines (including continuation lines) of
  1174.                      the [RFC-822] format header of the message with a
  1175.                      field-name (as defined in [RFC-822]) that matches
  1176.                      any of the strings in header_list.  The matching is
  1177.                      case-insensitive but otherwise exact.  The
  1178.                      delimiting blank line between the header and the
  1179.                      body is always included.
  1180. Crispin                                                        [Page 31]
  1181. RFC 1730                         IMAP4                     December 1994
  1182.       RFC822.HEADER.LINES.NOT <header_list>
  1183.                      All header lines (including continuation lines) of
  1184.                      the [RFC-822] format header of the message with a
  1185.                      field-name (as defined in [RFC-822]) that does not
  1186.                      match any of the strings in header_list.  The
  1187.                      matching is case-insensitive but otherwise exact.
  1188.                      The delimiting blank line between the header and
  1189.                      the body is always included.
  1190.       RFC822.SIZE    The number of octets in the message, as expressed
  1191.                      in [RFC-822] format.
  1192.       RFC822.TEXT    The text body of the message, omitting the
  1193.                      [RFC-822] header.  The Seen flag is implicitly
  1194.                      set; if this causes the flags to change they should
  1195.                      be included as part of the fetch responses.
  1196.       RFC822.TEXT.PEEK
  1197.                      An alternate form of RFC822.TEXT that does not
  1198.                      implicitly set the Seen flag.
  1199.       UID            The unique identifier for the message.
  1200.    Example:    C: A654 FETCH 2:4 (FLAGS RFC822.HEADER.LINES (DATE FROM))
  1201.                S: * 2 FETCH ....
  1202.                S: * 3 FETCH ....
  1203.                S: * 4 FETCH ....
  1204.                S: A003 OK FETCH completed
  1205. 6.4.6.  PARTIAL Command
  1206.    Arguments:  message sequence number
  1207.                message data item name
  1208.                position of first octet
  1209.                number of octets
  1210.    Data:       untagged responses: FETCH
  1211.    Result:     OK - partial completed
  1212.                NO - partial error: can't fetch that data
  1213.                BAD - command unknown or arguments invalid
  1214.       The PARTIAL command is equivalent to the associated FETCH command,
  1215.       with the added functionality that only the specified number of
  1216.       octets, beginning at the specified starting octet, are returned.
  1217.       Only a single message can be fetched at a time.  The first octet
  1218. Crispin                                                        [Page 32]
  1219. RFC 1730                         IMAP4                     December 1994
  1220.       of a message, and hence the minimum for the starting octet, is
  1221.       octet 1.
  1222.       The following FETCH items are valid data for PARTIAL: RFC822,
  1223.       RFC822.HEADER, RFC822.TEXT, BODY[section], as well as any .PEEK
  1224.       forms of these.
  1225.       Any partial fetch that attempts to read beyond the end of the text
  1226.       is truncated as appropriate.  If the starting octet is beyond the
  1227.       end of the text, an empty string is returned.
  1228.       The data are returned with the FETCH response.  There is no
  1229.       indication of the range of the partial data in this response.  It
  1230.       is not possible to stream multiple PARTIAL commands of the same
  1231.       data item without processing and synchronizing at each step, since
  1232.       streamed commands may be executed out of order.
  1233.       There is no requirement that partial fetches follow any sequence.
  1234.       For example, if a partial fetch of octets 1 through 10000 breaks
  1235.       in an awkward place for BASE64 decoding, it is permitted to
  1236.       continue with a partial fetch of 9987 through 19987, etc.
  1237.       The handling of the Seen flag is the same as in the associated
  1238.       FETCH command.
  1239.    Example:    C: A005 PARTIAL 4 RFC822 1 1024
  1240.                S: * 1 FETCH (RFC822 {1024}
  1241.                S: Return-Path: <gray@cac.washington.edu>
  1242.                S: ...
  1243.                S: .........  FLAGS (Seen))
  1244.                S: A005 OK PARTIAL completed
  1245. 6.4.7.  STORE Command
  1246.    Arguments:  message set
  1247.                message data item name
  1248.                value for message data item
  1249.    Data:       untagged responses: FETCH
  1250.    Result:     OK - store completed
  1251.                NO - store error: can't store that data
  1252.                BAD - command unknown or arguments invalid
  1253.       The STORE command alters data associated with a message in the
  1254.       mailbox.  Normally, STORE will return the updated value of the
  1255.       data with an untagged FETCH response.  A suffix of ".SILENT" in
  1256. Crispin                                                        [Page 33]
  1257. RFC 1730                         IMAP4                     December 1994
  1258.       the data item name prevents the untagged FETCH, and the server
  1259.       should assume that the client has determined the updated value
  1260.       itself or does not care about the updated value.
  1261.       The currently defined data items that can be stored are:
  1262.       FLAGS <flag list>
  1263.                      Replace the flags for the message with the
  1264.                      argument.  The new value of the flags are returned
  1265.                      as if a FETCH of those flags was done.
  1266.       FLAGS.SILENT <flag list>
  1267.                      Equivalent to FLAGS, but without returning a new
  1268.                      value.
  1269.       +FLAGS <flag list>
  1270.                      Add the argument to the flags for the message.  The
  1271.                      new value of the flags are returned as if a FETCH
  1272.                      of those flags was done.
  1273.       +FLAGS.SILENT <flag list>
  1274.                      Equivalent to +FLAGS, but without returning a new
  1275.                      value.
  1276.       -FLAGS <flag list>
  1277.                      Remove the argument from the flags for the message.
  1278.                      The new value of the flags are returned as if a
  1279.                      FETCH of those flags was done.
  1280.       -FLAGS.SILENT <flag list>
  1281.                      Equivalent to -FLAGS, but without returning a new
  1282.                      value.
  1283.    Example:    C: A003 STORE 2:4 +FLAGS (Deleted)
  1284.                S: * 2 FETCH FLAGS (Deleted Seen)
  1285.                S: * 3 FETCH FLAGS (Deleted)
  1286.                S: * 4 FETCH FLAGS (Deleted Flagged Seen)
  1287.                S: A003 OK STORE completed
  1288. Crispin                                                        [Page 34]
  1289. RFC 1730                         IMAP4                     December 1994
  1290. 6.4.8.  COPY Command
  1291.    Arguments:  message set
  1292.                mailbox name
  1293.    Data:       no specific data for this command
  1294.    Result:     OK - copy completed
  1295.                NO - copy error: can't copy those messages or to that
  1296.                     name
  1297.                BAD - command unknown or arguments invalid
  1298.       The COPY command copies the specified message(s) to the specified
  1299.       destination mailbox.  The flags and internal date of the
  1300.       message(s) SHOULD be preserved in the copy.
  1301.       If the destination mailbox does not exist, a server SHOULD return
  1302.       an error.  It SHOULD NOT automatically create the mailbox.  Unless
  1303.       it is certain that the destination mailbox can not be created, the
  1304.       server MUST send the response code "[TRYCREATE]" as the prefix of
  1305.       the text of the tagged NO response.  This gives a hint to the
  1306.       client that it can attempt a CREATE command and retry the COPY if
  1307.       the CREATE is successful.
  1308.       If the COPY command is unsuccessful for any reason, server
  1309.       implementations MUST restore the destination mailbox to its state