Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 1730

Internet Message Access Protocol - Version 4

Pages: 77
Obsoleted by:  20602061
Part 1 of 3 – Pages 1 to 27
None   None   Next

ToP   noToC   RFC1730 - Page 1
Network Working Group                                         M. Crispin
Request for Comments: 1730                      University of Washington
Category: Standards Track                                  December 1994


              INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4



Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.


Abstract

   The Internet Message Access Protocol, Version 4 (IMAP4) allows a
   client to access and manipulate electronic mail messages on a server.
   IMAP4 permits manipulation of remote message folders, called
   "mailboxes", in a way that is functionally equivalent to local
   mailboxes.  IMAP4 also provides the capability for an offline client
   to resynchronize with the server (see also [IMAP-DISC]).

   IMAP4 includes operations for creating, deleting, and renaming
   mailboxes; checking for new messages; permanently removing messages;
   setting and clearing flags; RFC 822 and MIME parsing; searching; and
   selective fetching of message attributes, texts, and portions
   thereof.  Messages in IMAP4 are accessed by the use of numbers.
   These numbers are either message sequence numbers (relative position
   from 1 to the number of messages in the mailbox) or unique
   identifiers (immutable, strictly ascending values assigned to each
   message, but which are not necessarily contiguous).

   IMAP4 supports a single server.  A mechanism for supporting multiple
   IMAP4 servers is discussed in [IMSP].

   IMAP4 does not specify a means of posting mail; this function is
   handled by a mail transfer protocol such as [SMTP].

   IMAP4 is designed to be upwards compatible from the [IMAP2] protocol.
   Compatibility issues are discussed in [IMAP-COMPAT].
ToP   noToC   RFC1730 - Page 2
Table of Contents



 IMAP4 Protocol Specification ......................................    1
 1.      Organization of this Document .............................    1
 1.1.    How to Read This Document .................................    1
 1.2.    Conventions Used in this Document .........................    1
 2.      Protocol Overview .........................................    1
 2.1.    Link Level ................................................    1
 2.2.    Commands and Responses ....................................    1
 2.2.1.  Client Protocol Sender and Server Protocol Receiver .......    2
 2.2.2.  Server Protocol Sender and Client Protocol Receiver .......    2
 3.      State and Flow Diagram ....................................    4
 3.1.    Non-Authenticated State ...................................    4
 3.2.    Authenticated State .......................................    4
 3.3.    Selected State ............................................    4
 3.4.    Logout State ..............................................    4
 4.      Data Formats ..............................................    6
 4.1.    Atom ......................................................    6
 4.2.    Number ....................................................    6
 4.3.    String ....................................................    6
 4.3.1.  8-bit and Binary Strings ..................................    7
 4.4.    Parenthesized List ........................................    7
 4.5.    NIL .......................................................    7
 5.      Operational Considerations ................................    8
 5.1.    Mailbox Naming ............................................    8
 5.2.    Mailbox Size and Message Status Updates ...................    8
 5.3.    Response when no Command in Progress ......................    8
 5.4.    Autologout Timer ..........................................    9
 5.5.    Multiple Commands in Progress .............................    9
 6.      Client Commands ...........................................   10
 6.1.    Client Commands - Any State ...............................   10
 6.1.1.  CAPABILITY Command ........................................   10
 6.1.2.  NOOP Command ..............................................   11
 6.1.3.  LOGOUT Command ............................................   11
 6.2.    Client Commands - Non-Authenticated State .................   12
 6.2.1.  AUTHENTICATE Command ......................................   12
 6.2.2.  LOGIN Command .............................................   14
 6.3.    Client Commands - Authenticated State .....................   14
 6.3.1.  SELECT Command ............................................   15
 6.3.2.  EXAMINE Command ...........................................   16
 6.3.3.  CREATE Command ............................................   17
 6.3.4.  DELETE Command ............................................   18
 6.3.5.  RENAME Command ............................................   18
ToP   noToC   RFC1730 - Page 3
 6.3.6.  SUBSCRIBE Command .........................................   19
 6.3.7.  UNSUBSCRIBE Command .......................................   19
 6.3.8.  LIST Command ..............................................   20
 6.3.9.  LSUB Command ..............................................   22
 6.3.10. APPEND Command ............................................   22
 6.4.    Client Commands - Selected State ..........................   23
 6.4.1.  CHECK Command .............................................   23
 6.4.2.  CLOSE Command .............................................   24
 6.4.3.  EXPUNGE Command ...........................................   25
 6.4.4.  SEARCH Command ............................................   25
 6.4.5.  FETCH Command .............................................   29
 6.4.6.  PARTIAL Command ...........................................   32
 6.4.7.  STORE Command .............................................   33
 6.4.8.  COPY Command ..............................................   34
 6.4.9.  UID Command ...............................................   35
 6.5.    Client Commands - Experimental/Expansion ..................   37
 6.5.1.  X<atom> Command ...........................................   37
 7.      Server Responses ..........................................   38
 7.1.    Server Responses - Status Responses .......................   39
 7.1.1.  OK Response ...............................................   40
 7.1.2.  NO Response ...............................................   40
 7.1.3.  BAD Response ..............................................   41
 7.1.4.  PREAUTH Response ..........................................   41
 7.1.5.  BYE Response ..............................................   41
 7.2.    Server Responses - Server and Mailbox Status ..............   42
 7.2.1.  CAPABILITY Response .......................................   42
 7.2.2.  LIST Response .............................................   43
 7.2.3.  LSUB Response .............................................   44
 7.2.4.  SEARCH Response ...........................................   44
 7.2.5.  FLAGS Response ............................................   44
 7.3.    Server Responses - Message Status .........................   45
 7.3.1.  EXISTS Response ...........................................   45
 7.3.2.  RECENT Response ...........................................   45
 7.3.3.  EXPUNGE Response ..........................................   45
 7.3.4.  FETCH Response ............................................   46
 7.3.5.  Obsolete Responses ........................................   51
 7.4.    Server Responses - Command Continuation Request ...........   51
 8.      Sample IMAP4 session ......................................   52
 9.      Formal Syntax .............................................   53
 10.     Author's Note .............................................   64
 11.     Security Considerations ...................................   64
 12.     Author's Address ..........................................   64
 Appendices ........................................................   65
 A.      Obsolete Commands .........................................   65
 A.6.3.OBS.1.    FIND ALL.MAILBOXES Command ........................   65
 A.6.3.OBS.2.    FIND MAILBOXES Command ............................   65
 A.6.3.OBS.3.    SUBSCRIBE MAILBOX Command .........................   66
 A.6.3.OBS.4.    UNSUBSCRIBE MAILBOX Command .......................   66
ToP   noToC   RFC1730 - Page 4
 B.      Obsolete Responses ........................................   68
 B.7.2.OBS.1.    MAILBOX Response ..................................   68
 B.7.3.OBS.1.    COPY Response .....................................   68
 B.7.3.OBS.2.    STORE Response ....................................   69
 C.      References ................................................   70
 E.      IMAP4 Keyword Index .......................................   71
ToP   noToC   RFC1730 - Page 5
IMAP4 Protocol Specification

1.      Organization of this Document

1.1.    How to Read This Document

   This document is written from the point of view of the implementor of
   an IMAP4 client or server.  Beyond the protocol overview in section
   2, it is not optimized for someone trying to understand the operation
   of the protocol.  The material in sections 3 through 5 provides the
   general context and definitions with which IMAP4 operates.

   Sections 6, 7, and 9 describe the IMAP commands, responses, and
   syntax, respectively.  The relationships among these are such that it
   is almost impossible to understand any of them separately.  In
   particular, one should not attempt to deduce command syntax from the
   command section alone; one should instead refer to the formal syntax
   section.


1.2.    Conventions Used in this Document

   In examples, "C:" and "S:" indicate lines sent by the client and
   server respectively.


2.      Protocol Overview

2.1.    Link Level

   The IMAP4 protocol assumes a reliable data stream such as provided by
   TCP.  When TCP is used, an IMAP4 server listens on port 143.


2.2.    Commands and Responses

   An IMAP4 session consists of the establishment of a client/server
   connection, an initial greeting from the server, and client/server
   interactions.  These client/server interactions consist of a client
   command, server data, and a server completion result response.

   All interactions transmitted by client and server are in the form of
   lines; that is, strings that end with a CRLF.  The protocol receiver
   of an IMAP4 client or server is either reading a line, or is reading
   a sequence of octets with a known count followed by a line.
ToP   noToC   RFC1730 - Page 6
2.2.1.  Client Protocol Sender and Server Protocol Receiver

   The client command begins an operation.  Each client command is
   prefixed with a identifier (typically a short alphanumeric string,
   e.g. A0001, A0002, etc.) called a "tag".  A different tag is
   generated by the client for each command.

   There are two cases in which a line from the client does not
   represent a complete command.  In one case, a command argument is
   quoted with an octet count (see the description of literal in String
   under Data Formats); in the other case, the command arguments require
   server feedback (see the AUTHENTICATE command).  In either case, the
   server sends a command continuation request response if it is ready
   for the octets (if appropriate) and the remainder of the command.
   This response is prefixed with the token "+".

        Note: If, instead, the server detected an error in the
        command, it sends a BAD completion response with tag
        matching the command (as described below) to reject the
        command and prevent the client from sending any more of the
        command.

        It is also possible for the server to send a completion
        response for some other command (if multiple commands are
        in progress), or untagged data.  In either case, the
        command continuation request is still pending; the client
        takes the appropriate action for the response, and reads
        another response from the server.

   The protocol receiver of an IMAP4 server reads a command line from
   the client, parses the command and its arguments, and transmits
   server data and a server command completion result response.


2.2.2.  Server Protocol Sender and Client Protocol Receiver

   Data transmitted by the server to the client and status responses
   that do not indicate command completion are prefixed with the token
   "*", and are called untagged responses.

   Server data may be sent as a result of a client command, or may be
   sent unilaterally by the server.  There is no syntactic difference
   between server data that resulted from a specific command and server
   data that were sent unilaterally.

   The server completion result response indicates the success or
   failure of the operation.  It is tagged with the same tag as the
   client command which began the operation.  Thus, if more than one
ToP   noToC   RFC1730 - Page 7
   command is in progress, the tag in a server completion response
   identifies the command to which the response applies.  There are
   three possible server completion responses: OK (indicating success),
   NO (indicating failure), or BAD (indicating protocol error such as
   unrecognized command or command syntax error).

   The protocol receiver of an IMAP4 client reads a response line from
   the server.  It then takes action on the response based upon the
   first token of the response, which may be a tag, a "*", or a "+".  As
   described above.

   A client MUST be prepared to accept any server response at all times.
   This includes server data that it may not have requested.  Server
   data SHOULD be recorded, so that the client can reference its
   recorded copy rather than sending a command to the server to request
   the data.  In the case of certain server data, recording the data is
   mandatory.

   This topic is discussed in greater detail in the Server Responses
   section.
ToP   noToC   RFC1730 - Page 8
3.      State and Flow Diagram

   An IMAP4 server is in one of four states.  Most commands are valid in
   only certain states.  It is a protocol error for the client to
   attempt a command while the command is in an inappropriate state.  In
   this case, a server will respond with a BAD or NO (depending upon
   server implementation) command completion result.


3.1.    Non-Authenticated State

   In non-authenticated state, the user must supply authentication
   credentials before most commands will be permitted.  This state is
   entered when a connection starts unless the connection has been
   pre-authenticated.


3.2.    Authenticated State

   In authenticated state, the user is authenticated and must select a
   mailbox to access before commands that affect messages will be
   permitted.  This state is entered when a pre-authenticated connection
   starts, when acceptable authentication credentials have been
   provided, or after an error in selecting a mailbox.


3.3.    Selected State

   In selected state, a mailbox has been selected to access.  This state
   is entered when a mailbox has been successfully selected.


3.4.    Logout State

   In logout state, the session is being terminated, and the server will
   close the connection.  This state can be entered as a result of a
   client request or by unilateral server decision.
ToP   noToC   RFC1730 - Page 9
            +--------------------------------------+
            |initial connection and server greeting|
            +--------------------------------------+
                      || (1)       || (2)        || (3)
                      VV           ||            ||
            +-----------------+    ||            ||
            |non-authenticated|    ||            ||
            +-----------------+    ||            ||
             || (7)   || (4)       ||            ||
             ||       VV           VV            ||
             ||     +----------------+           ||
             ||     | authenticated  |<=++       ||
             ||     +----------------+  ||       ||
             ||       || (7)   || (5)   || (6)   ||
             ||       ||       VV       ||       ||
             ||       ||    +--------+  ||       ||
             ||       ||    |selected|==++       ||
             ||       ||    +--------+           ||
             ||       ||       || (7)            ||
             VV       VV       VV                VV
            +--------------------------------------+
            |     logout and close connection      |
            +--------------------------------------+

         (1) connection without pre-authentication (OK greeting)
         (2) pre-authenticated connection (PREAUTH greeting)
         (3) rejected connection (BYE greeting)
         (4) successful LOGIN or AUTHENTICATE command
         (5) successful SELECT or EXAMINE command
         (6) CLOSE command, or failed SELECT or EXAMINE command
         (7) LOGOUT command, server shutdown, or connection closed
ToP   noToC   RFC1730 - Page 10
4.      Data Formats

   IMAP4 uses textual commands and responses.  Data in IMAP4 can be in
   one of several forms: atom, number, string, parenthesized list, or
   NIL.


4.1.    Atom

   An atom consists of one or more non-special characters.


4.2.    Number

   A number consists of one or more digit characters, and represents a
   numeric value.


4.3.    String

   A string is in one of two forms: literal and quoted string.  The
   literal form is the general form of string.  The quoted string form
   is an alternative that avoids the overhead of processing a literal at
   the cost of restrictions of what may be in a quoted string.

   A literal is a sequence of zero or more octets (including CR and LF),
   prefix-quoted with an octet count in the form of an open brace ("{"),
   the number of octets, close brace ("}"), and CRLF.  In the case of
   literals transmitted from server to client, the CRLF is immediately
   followed by the octet data.  In the case of literals transmitted from
   client to server, the client must wait to receive a command
   continuation request (described later in this document) before
   sending the octet data (and the remainder of the command).

   A quoted string is a sequence of zero or more 7-bit characters,
   excluding CR and LF, with double quote (<">) characters at each end.

   The empty string is respresented as either "" (a quoted string with
   zero characters between double quotes) or as {0} followed by CRLF (a
   literal with an octet count of 0).

        Note: Even if the octet count is 0, a client transmitting a
        literal must wait to receive a command continuation
        request.
ToP   noToC   RFC1730 - Page 11
4.3.1.  8-bit and Binary Strings

   8-bit textual and binary mail is supported through the use of
   [MIME-1] encoding.  IMAP4 implementations MAY transmit 8-bit or
   multi-octet characters in literals, but should do so only when the
   character set is identified.

   Although a BINARY body encoding is defined, unencoded binary strings
   are not permitted.  A "binary string" is any string with NUL
   characters.  Implementations MUST encode binary data into a textual
   form such as BASE64 before transmitting the data.  A string with an
   excessive amount of CTL characters may also be considered to be
   binary, although this is not required.


4.4.    Parenthesized List

   Data structures are represented as a "parenthesized list"; a sequence
   of data items, delimited by space, and bounded at each end by
   parentheses.  A parenthesized list may itself contain other
   parenthesized lists, using multiple levels of parentheses to indicate
   nesting.

   The empty list is represented as () -- a parenthesized list with no
   members.


4.5.    NIL

   The special atom "NIL" represents the non-existence of a particular
   data item that is represented as a string or parenthesized list, as
   distinct from the empty string "" or the empty parenthesized list ().
ToP   noToC   RFC1730 - Page 12
5.      Operational Considerations

5.1.    Mailbox Naming

   The interpretation of mailbox names is implementation-dependent.
   However, the mailbox name INBOX is a special name reserved to mean
   "the primary mailbox for this user on this server".  If it is desired
   to export hierarchical mailbox names, mailbox names must be
   left-to-right hierarchical using a single character to separate
   levels of hierarchy.  The same hierarchy separator character is used
   for all levels of hierarchy within a single name.

5.2.    Mailbox Size and Message Status Updates

   At any time, a server can send data that the client did not request.
   Sometimes, such behavior is required.  For example, agents other than
   the server may add messages to the mailbox (e.g. new mail delivery),
   change the flags of message in the mailbox (e.g. simultaneous access
   to the same mailbox by multiple agents), or even remove messages from
   the mailbox.  A server MUST send mailbox size updates automatically
   if a mailbox size change is observed during the processing of a
   command.  A server SHOULD send message flag updates automatically,
   without requiring the client to request such updates explicitly.
   Special rules exist for server notification of a client about the
   removal of messages to prevent synchronization errors; see the
   description of the EXPUNGE response for more details.

   Regardless of what implementation decisions a client may take on
   remembering data from the server, a client implementation MUST record
   mailbox size updates.  It MUST NOT assume that any command after
   initial mailbox selection will return the size of the mailbox.


5.3.    Response when no Command in Progress

   Server implementations are permitted to send an untagged response
   (except for EXPUNGE) while there is no command in progress.  Server
   implementations that send such responses MUST deal with flow control
   considerations.  Specifically, they must either (1) verify that the
   size of the data does not exceed the underlying transport's available
   window size, or (2) use non-blocking writes.
ToP   noToC   RFC1730 - Page 13
5.4.    Autologout Timer

   If a server has an inactivity autologout timer, that timer MUST be of
   at least 30 minutes' duration.  The receipt of ANY command from the
   client during that interval should suffice to reset the autologout
   timer.


5.5.    Multiple Commands in Progress

   The client is not required to wait for the completion result response
   of a command before sending another command, subject to flow control
   constraints on the underlying data stream.  Similarly, a server is
   not required to process a command to completion before beginning
   processing of the next command, unless an ambiguity would result
   because of a command that would affect the results of other commands.
   If there is such an ambiguity, the server executes commands to
   completion in the order given by the client.
ToP   noToC   RFC1730 - Page 14
6.      Client Commands

   IMAP4 commands are described in this section.  Commands are organized
   by the state in which the command is permitted.  Commands which are
   permitted in multiple states are listed in the minimum permitted
   state (for example, commands valid in authenticated and selected
   state are listed in the authenticated state commands).

   Command arguments, identified by "Arguments:" in the command
   descriptions below, are described by function, not by syntax.  The
   precise syntax of command arguments is described in the Formal Syntax
   section.

   Some commands cause specific server data to be returned; these are
   identified by "Data:" in the command descriptions below.  See the
   response descriptions in the Responses section for information on
   these responses, and the Formal Syntax section for the precise syntax
   of these responses.  It is possible for server data to be transmitted
   as a result of any command; thus, commands that do not specifically
   require server data specify "no specific data for this command"
   instead of "none".

   The "Result:" in the command description refers to the possible
   tagged status responses to a command, and any special interpretation
   of these status responses.


6.1.    Client Commands - Any State

   The following commands are valid in any state: CAPABILITY, NOOP, and
   LOGOUT.

6.1.1.  CAPABILITY Command

   Arguments:  none

   Data:       mandatory untagged response: CAPABILITY

   Result:     OK - capability completed
               BAD - command unknown or arguments invalid

      The CAPABILITY command requests a listing of capabilities that the
      server supports.  The server MUST send a single untagged
      CAPABILITY response with "IMAP4" as the first listed capability
      before the (tagged) OK response.  This listing of capabilities is
      not dependent upon connection state or user.  It is therefore not
      necessary to issue a CAPABILITY command more than once in a
      session.
ToP   noToC   RFC1730 - Page 15
      Capability names other than "IMAP4" refer to extensions,
      revisions, or amendments to this specification.  See the
      documentation of the CAPABILITY response for additional
      information.  No capabilities are enabled without explicit client
      action to invoke the capability.  See the section entitled "Client
      Commands - Experimental/Expansion" for information about the form
      of site or implementation-specific capabilities.

   Example:    C: abcd CAPABILITY
               S: * CAPABILITY IMAP4
               S: abcd OK CAPABILITY completed


6.1.2.  NOOP Command

   Arguments:  none

   Data:       no specific data for this command (but see below)

   Result:     OK - noop completed
               BAD - command unknown or arguments invalid

      The NOOP command always succeeds.  It does nothing.

      Since any command can return a status update as untagged data, the
      NOOP command can be used as a periodic poll for new messages or
      message status updates during a period of inactivity.  The NOOP
      command can also be used to reset any inactivity autologout timer
      on the server.

   Example:    C: a002 NOOP
               S: a002 OK NOOP completed
                  . . .
               C: a047 NOOP
               S: * 22 EXPUNGE
               S: * 23 EXISTS
               S: * 3 RECENT
               S: * 14 FETCH (FLAGS (\Seen \Deleted))
               S: a047 OK NOOP completed
ToP   noToC   RFC1730 - Page 16
6.1.3.  LOGOUT Command

   Arguments:  none

   Data:       mandatory untagged response: BYE

   Result:     OK - logout completed
               BAD - command unknown or arguments invalid

      The LOGOUT command informs the server that the client is done with
      the session.  The server must send a BYE untagged response before
      the (tagged) OK response, and then close the network connection.

   Example:    C: A023 LOGOUT
               S: * BYE IMAP4 Server logging out
               S: A023 OK LOGOUT completed
               (Server and client then close the connection)



6.2.    Client Commands - Non-Authenticated State

   In non-authenticated state, the AUTHENTICATE or LOGIN command
   establishes authentication and enter authenticated state.  The
   AUTHENTICATE command provides a general mechanism for a variety of
   authentication techniques, whereas the LOGIN command uses the
   traditional user name and plaintext password pair.

   Server implementations may allow non-authenticated access to certain
   mailboxes.  The convention is to use a LOGIN command with the userid
   "anonymous".  A password is required.  It is implementation-dependent
   what requirements, if any, are placed on the password and what access
   restrictions are placed on anonymous users.

   Once authenticated (including as anonymous), it is not possible to
   re-enter non-authenticated state.

   In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
   the following commands are valid in non-authenticated state:
   AUTHENTICATE and LOGIN.
ToP   noToC   RFC1730 - Page 17
6.2.1.  AUTHENTICATE Command

   Arguments:  authentication mechanism name

   Data:       continuation data may be requested

   Result:     OK - authenticate completed, now in authenticated state
               NO - authenticate failure: unsupported authentication
                    mechanism, credentials rejected
               BAD - command unknown or arguments invalid,
                    authentication exchange cancelled

      The AUTHENTICATE command indicates an authentication mechanism,
      such as described in [IMAP-AUTH], to the server.  If the server
      supports the requested authentication mechanism, it performs an
      authentication protocol exchange to authenticate and identify the
      user.  Optionally, it also negotiates a protection mechanism for
      subsequent protocol interactions.  If the requested authentication
      mechanism is not supported, the server should reject the
      AUTHENTICATE command by sending a tagged NO response.

      The authentication protocol exchange consists of a series of
      server challenges and client answers that are specific to the
      authentication mechanism.  A server challenge consists of a
      command continuation request response with the "+" token followed
      by a BASE64 encoded string.  The client answer consists of a line
      consisting of a BASE64 encoded string.  If the client wishes to
      cancel an authentication exchange, it should issue a line with a
      single "*".  If the server receives such an answer, it must reject
      the AUTHENTICATE command by sending a tagged BAD response.

      A protection mechanism provides integrity and privacy protection
      to the protocol session.  If a protection mechanism is negotiated,
      it is applied to all subsequent data sent over the connection.
      The protection mechanism takes effect immediately following the
      CRLF that concludes the authentication exchange for the client,
      and the CRLF of the tagged OK response for the server.  Once the
      protection mechanism is in effect, the stream of command and
      response octets is processed into buffers of ciphertext.  Each
      buffer is transferred over the connection as a stream of octets
      prepended with a four octet field in network byte order that
      represents the length of the following data.  The maximum
      ciphertext buffer length is defined by the protection mechanism.

      The server is not required to support any particular
      authentication mechanism, nor are authentication mechanisms
      required to support any protection mechanisms.  If an AUTHENTICATE
      command fails with a NO response, the client may try another
ToP   noToC   RFC1730 - Page 18
      authentication mechanism by issuing another AUTHENTICATE command,
      or may attempt to authenticate by using the LOGIN command.  In
      other words, the client may request authentication types in
      decreasing order of preference, with the LOGIN command as a last
      resort.

   Example:    S: * OK KerberosV4 IMAP4 Server
               C: A001 AUTHENTICATE KERBEROS_V4
               S: + AmFYig==
               C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
                  +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
                  WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
               S: + or//EoAADZI=
               C: DiAF5A4gA+oOIALuBkAAmw==
               S: A001 OK Kerberos V4 authentication successful

        Note: the line breaks in the first client answer are for
        editorial clarity and are not in real authenticators.


6.2.2.  LOGIN Command

   Arguments:  user name
               password

   Data:       no specific data for this command

   Result:     OK - login completed, now in authenticated state
               NO - login failure: user name or password rejected
               BAD - command unknown or arguments invalid

      The LOGIN command identifies the user to the server and carries
      the plaintext password authenticating this user.

   Example:    C: a001 LOGIN SMITH SESAME
               S: a001 OK LOGIN completed



6.3.    Client Commands - Authenticated State

   In authenticated state, commands that manipulate mailboxes as atomic
   entities are permitted.  Of these commands, the SELECT and EXAMINE
   commands will select a mailbox for access and enter selected state.
ToP   noToC   RFC1730 - Page 19
   In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
   the following commands are valid in authenticated state: SELECT,
   EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB,
   and APPEND.

6.3.1.  SELECT Command

   Arguments:  mailbox name

   Data:       mandatory untagged responses: FLAGS, EXISTS, RECENT
               optional OK untagged responses: UNSEEN, PERMANENTFLAGS

   Result:     OK - select completed, now in selected state
               NO - select failure, now in authenticated state: no
                    such mailbox, can't access mailbox
               BAD - command unknown or arguments invalid

      The SELECT command selects a  mailbox  so  that  messages  in  the
      mailbox  can  be  accessed.  Before returning an OK to the client,
      the server MUST send the following untagged data to the client:

         FLAGS       Defined flags in the mailbox

         <n> EXISTS  The number of messages in the mailbox

         <n> RECENT  The number of messages added to the  mailbox  since
                     the previous time this mailbox was read

         OK [UIDVALIDITY <n>]
                     The unique  identifier  validity  value.   See  the
                     description of the UID command for more detail.

      to define the initial state of the mailbox at the client.  If it
      is not possible to determine the messages that were added since
      the previous time a mailbox was read, then all messages SHOULD be
      considered recent.

      The server SHOULD also send an UNSEEN response code in an OK
      untagged response, indicating the message sequence number of the
      first unseen message in the mailbox.

      If the client can not change the permanent state of one or more of
      the flags listed in the FLAGS untagged response, the server SHOULD
      send a PERMANENTFLAGS response code in an OK untagged response,
      listing the flags that the client may change permanently.

      Only one mailbox may be selected at a time in a session;
      simultaneous access to multiple mailboxes requires multiple
ToP   noToC   RFC1730 - Page 20
      sessions.  The SELECT command automatically deselects any
      currently selected mailbox before attempting the new selection.
      Consequently, if a mailbox is selected and a SELECT command that
      fails is attempted, no mailbox is selected.

      If the user is permitted to modify the mailbox, the server SHOULD
      prefix the text of the tagged OK response with the "[READ-WRITE]"
      response code.

      If the user is not permitted to modify the mailbox but is
      permitted read access, the mailbox is selected as read-only, and
      the server MUST prefix the text of the tagged OK response to
      SELECT with the "[READ-ONLY]" response code.  Read-only access
      through SELECT differs from the EXAMINE command in that certain
      read-only mailboxes may permit the change of permanent state on a
      per-user (as opposed to global) basis.  Netnews messages marked in
      a user's .newsrc file are an example of such per-user permanent
      state that can be modified with read-only mailboxes.

   Example:    C: A142 SELECT INBOX
               S: * 172 EXISTS
               S: * 1 RECENT
               S: * OK [UNSEEN 12] Message 12 is first unseen
               S: * OK [UIDVALIDITY 3857529045] UIDs valid
               S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
               S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
               S: A142 OK [READ-WRITE] SELECT completed


6.3.2.  EXAMINE Command

   Arguments:  mailbox name

   Data:       mandatory untagged responses: FLAGS, EXISTS, RECENT
               optional OK untagged responses: UNSEEN, PERMANENTFLAGS

   Result:     OK - examine completed, now in selected state
               NO - examine failure, now in authenticated state: no
                    such mailbox, can't access mailbox
               BAD - command unknown or arguments invalid

      The EXAMINE command is identical to SELECT and returns the same
      output; however, the selected mailbox is identified as read-only.
      No changes to the permanent state of the mailbox, including
      per-user state, are permitted.
ToP   noToC   RFC1730 - Page 21
      The text of the tagged OK response to the EXAMINE command MUST
      begin with the "[READ-ONLY]" response code.

   Example:    C: A932 EXAMINE blurdybloop
               S: * 17 EXISTS
               S: * 2 RECENT
               S: * OK [UNSEEN 8] Message 8 is first unseen
               S: * OK [UIDVALIDITY 3857529045] UIDs valid
               S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
               S: * OK [PERMANENTFLAGS ()] No permanent flags permitted
               S: A932 OK [READ-ONLY] EXAMINE completed


6.3.3.  CREATE Command

   Arguments:  mailbox name

   Data:       no specific data for this command

   Result:     OK - create completed
               NO - create failure: can't create mailbox with that name
               BAD - command unknown or arguments invalid

      The CREATE command creates a mailbox with the given name.  An OK
      response is returned only if a new mailbox with that name has been
      created.  It is an error to attempt to create INBOX or a mailbox
      with a name that refers to an extant mailbox.  Any error in
      creation will return a tagged NO response.

      If the mailbox name is suffixed with the server's hierarchy
      separator character (as returned from the server by a LIST
      command), this is a declaration that the client may, in the
      future, create mailbox names under this name in the hierarchy.
      Server implementations that do not require this declaration MUST
      ignore it.

      If a new mailbox is created with the same name as a mailbox which
      was deleted, its unique identifiers MUST be greater than any
      unique identifiers used in the previous incarnation of the mailbox
      UNLESS the new incarnation has a different unique identifier
      validity value.  See the description of the UID command for more
      detail.

   Example:    C: A003 CREATE owatagusiam/
               S: A003 OK CREATE completed
               C: A004 CREATE owatagusiam/blurdybloop
               S: A004 OK CREATE completed
ToP   noToC   RFC1730 - Page 22
        Note: the interpretation of this example depends on whether
        "/" was returned as the hierarchy separator from LIST.  If
        "/" is the hierarchy separator, a new level of hierarchy
        named "owatagusiam" with a member called "blurdybloop" is
        created.  Otherwise, two mailboxes at the same hierarchy
        level are created.


6.3.4.  DELETE Command

   Arguments:  mailbox name

   Data:       no specific data for this command

   Result:     OK - delete completed
               NO - delete failure: can't delete mailbox with that name
               BAD - command unknown or arguments invalid

      The DELETE command permanently removes the mailbox with the given
      name.  A tagged OK response is returned only if the mailbox has
      been deleted.  It is an error to attempt to delete INBOX or a
      mailbox name that does not exist.  Any error in deletion will
      return a tagged NO response.

      The value of the highest-used unique indentifier of the deleted
      mailbox MUST be preserved so that a new mailbox created with the
      same name will not reuse the identifiers of the former
      incarnation, UNLESS the new incarnation has a different unique
      identifier validity value.  See the description of the UID command
      for more detail.

   Example:    C: A683 DELETE blurdybloop
               S: A683 OK DELETE completed


6.3.5.  RENAME Command

   Arguments:  existing mailbox name
               new mailbox name

   Data:       no specific data for this command

   Result:     OK - rename completed
               NO - rename failure: can't rename mailbox with that name,
                    can't rename to mailbox with that name
               BAD - command unknown or arguments invalid
ToP   noToC   RFC1730 - Page 23
      The RENAME command changes the name of a mailbox.  A tagged OK
      response is returned only if the mailbox has been renamed.  It is
      an error to attempt to rename from a mailbox name that does not
      exist or to a mailbox name that already exists.  Any error in
      renaming will return a tagged NO response.

      Renaming INBOX is permitted; a new, empty INBOX is created in its
      place.

   Example:    C: Z4S9 RENAME blurdybloop owatagusiam
               S: Z4S9 OK RENAME completed


6.3.6.  SUBSCRIBE Command

   Arguments:  mailbox

   Data:       no specific data for this command

   Result:     OK - subscribe completed
               NO - subscribe failure: can't subscribe to that name
               BAD - command unknown or arguments invalid

      The SUBSCRIBE command adds the specified mailbox name to the
      server's set of "active" or "subscribed" mailboxes as returned by
      the LSUB command.  This command returns a tagged OK response only
      if the subscription is successful.

   Example:    C: A002 SUBSCRIBE #news.comp.mail.mime
               S: A002 OK SUBSCRIBE completed


6.3.7.  UNSUBSCRIBE Command

   Arguments:  mailbox name

   Data:       no specific data for this command

   Result:     OK - unsubscribe completed
               NO - unsubscribe failure: can't unsubscribe that name
               BAD - command unknown or arguments invalid

      The UNSUBSCRIBE command removes the specified mailbox name from
      the server's set of "active" or "subscribed" mailboxes as returned
      by the LSUB command.  This command returns a tagged OK response
      only if the unsubscription is successful.
ToP   noToC   RFC1730 - Page 24
   Example:    C: A002 UNSUBSCRIBE #news.comp.mail.mime
               S: A002 OK UNSUBSCRIBE completed


6.3.8.  LIST Command

   Arguments:  reference name
               mailbox name with possible wildcards

   Data:       untagged responses: LIST

   Result:     OK - list completed
               NO - list failure: can't list that reference or name
               BAD - command unknown or arguments invalid

      The LIST command returns a subset of names from the complete set
      of all names available to the user.  Zero or more untagged LIST
      replies are returned, containing the name attributes, hierarchy
      delimiter, and name; see the description of the LIST reply for
      more detail.

      An empty ("" string) reference name argument indicates that the
      mailbox name is interpreted as by SELECT. The returned mailbox
      names MUST match the supplied mailbox name pattern.  A non-empty
      reference name argument is the name of a mailbox or a level of
      mailbox hierarchy, and indicates a context in which the mailbox
      name is interpreted in an implementation-defined manner.

      The reference and mailbox name arguments are interpreted, in an
      implementation-dependent fashion, into a canonical form that
      represents an unambiguous left-to-right hierarchy.  The returned
      mailbox names will be in the interpreted form.

      Any part of the reference argument that is included in the
      interpreted form SHOULD prefix the interpreted form.  It should
      also be in the same form as the reference name argument.  This
      rule permits the client to determine if the returned mailbox name
      is in the context of the reference argument, or if something about
      the mailbox argument overrode the reference argument.  Without
      this rule, the client would have to have knowledge of the server's
      naming semantics including what characters are "breakouts" that
      override a naming context.
ToP   noToC   RFC1730 - Page 25
           For example, here are some examples of how references
           and mailbox names might be interpreted on a UNIX-based
           server:

               Reference     Mailbox Name  Interpretation
               ------------  ------------  --------------
               ~smith/Mail/  foo.*         ~smith/Mail/foo.*
               archive/      %             archive/%
               #news.        comp.mail.*   #news.comp.mail.*
               ~smith/Mail/  /usr/doc/foo  /usr/doc/foo
               archive/      ~fred/Mail/*  ~fred/Mail/*

           The first three examples demonstrate interpretations in
           the context of the reference argument.  Note that
           "~smith/Mail" should not be transformed into something
           like "/u2/users/smith/Mail", or it would be impossible
           for the client to determine that the interpretation was
           in the context of the reference.

      The character "*" is a wildcard, and matches zero or more
      characters at this position.  The character "%" is similar to "*",
      but it does not match a hierarchy delimiter.  If the "%" wildcard
      is the last character of a mailbox name argument, matching levels
      of hierarchy are also returned.  If these levels of hierarchy are
      not also selectable mailboxes, they are returned with the
      \Noselect mailbox name attribute (see the description of the LIST
      response for more detail).

      Server implementations are permitted to "hide" otherwise
      accessible mailboxes from the wildcard characters, by preventing
      certain characters or names from matching a wildcard in certain
      situations.  For example, a UNIX-based server might restrict the
      interpretation of "*" so that an initial "/" character does not
      match.

      The special name INBOX is included in the output from LIST if it
      matches the input arguments and INBOX is supported by this server
      for this user.  The criteria for omitting INBOX is whether SELECT
      INBOX will return failure; it is not relevant whether the user's
      real INBOX resides on this or some other server.

   Example:    C: A002 LIST "~/Mail/" "%"
               S: * LIST (\Noselect) "/" ~/Mail/foo
               S: * LIST () "/" ~/Mail/meetings
               S: A002 OK LIST completed
ToP   noToC   RFC1730 - Page 26
6.3.9.  LSUB Command

   Arguments:  reference name
               mailbox name with possible wildcards

   Data:       untagged responses: LSUB

   Result:     OK - lsub completed
               NO - lsub failure: can't list that reference or name
               BAD - command unknown or arguments invalid

      The LSUB command returns a subset of names from the set of names
      that the user has declared as being "active" or "subscribed".
      Zero or more untagged LSUB replies are returned.  The arguments to
      LSUB are in the same form as those for LIST.

   Example:    C: A002 LSUB "#news." "comp.mail.*"
               S: * LSUB () "." #news.comp.mail.mime
               S: * LSUB () "." #news.comp.mail.misc
               S: A002 OK LSUB completed


6.3.10. APPEND Command

   Arguments:  mailbox name
               optional flag parenthesized list
               optional date/time string
               message literal

   Data:       no specific data for this command

   Result:     OK - append completed
               NO - append error: can't append to that mailbox, error
                    in flags or date/time or message text
               BAD - command unknown or arguments invalid

      The APPEND command appends the literal argument as a new message
      in the specified destination mailbox.  This argument is in the
      format of an [RFC-822] message.  8-bit characters are permitted in
      the message.  A server implementation that is unable to preserve
      8-bit data properly MUST be able to reversibly convert 8-bit
      APPEND data to 7-bit using [MIME-1] encoding.

      If a flag parenthesized list or date_time are specified, that data
      SHOULD be set in the resulting message; otherwise, the defaults of
      empty flags and the current date/time are used.
ToP   noToC   RFC1730 - Page 27
      If the append is unsuccessful for any reason, the mailbox MUST be
      restored to its state before the APPEND attempt; no partial
      appending is permitted.  If the mailbox is currently selected, the
      normal new mail actions should occur.

      If the destination mailbox does not exist, a server MUST return an
      error, and MUST NOT automatically create the mailbox.  Unless it
      is certain that the destination mailbox can not be created, the
      server MUST send the response code "[TRYCREATE]" as the prefix of
      the text of the tagged NO response.  This gives a hint to the
      client that it can attempt a CREATE command and retry the APPEND
      if the CREATE is successful.

   Example:    C: A003 APPEND saved-messages (\Seen) {310}
               C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
               C: From: Fred Foobar <foobar@Blurdybloop.COM>
               C: Subject: afternoon meeting
               C: To: mooch@owatagu.siam.edu
               C: Message-Id: <B27397-0100000@Blurdybloop.COM>
               C: MIME-Version: 1.0
               C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
               C:
               C: Hello Joe, do you think we can meet at 3:30 tomorrow?
               C:
               S: A003 OK APPEND completed

        Note: the APPEND command is not used for message delivery,
        because it does not provide a mechanism to transfer [SMTP]
        envelope information.





(page 27 continued on part 2)

Next Section