send multiple commands without waiting if an ambiguity would result.
   If the server detects a possible ambiguity, it MUST execute commands
   to completion in the order given by the client.

   The most obvious example of ambiguity is when a command would affect
   the results of another command; for example, a FETCH of a message's
   flags and a STORE of that same message's flags.

   A non-obvious ambiguity occurs with commands that permit an untagged
   EXPUNGE response (commands other than FETCH, STORE, and SEARCH),
   since an untagged EXPUNGE response can invalidate sequence numbers in
   a subsequent command.  This is not a problem for FETCH, STORE, or
   SEARCH commands because servers are prohibited from sending EXPUNGE
   responses while any of those commands are in progress.  Therefore, if
   the client sends any command other than FETCH, STORE, or SEARCH, it
   MUST wait for a response before sending a command with message
   sequence numbers.

   For example, the following non-waiting command sequences are invalid:

      FETCH + NOOP + STORE
      STORE + COPY + FETCH
      COPY + COPY
      CHECK + FETCH

   The following are examples of valid non-waiting command sequences:

      FETCH + STORE + SEARCH + CHECK
      STORE + COPY + EXPUNGE

6.      Client Commands

   IMAP4rev1 commands are described in this section.  Commands are
   organized by the state in which the command is permitted.  Commands
   which are permitted in multiple states are listed in the minimum



Crispin                     Standards Track                    [Page 17]

RFC 2060                       IMAP4rev1                   December 1996


   permitted state (for example, commands valid in authenticated and
   selected state are listed in the authenticated state commands).

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

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

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

6.1.    Client Commands - Any State

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

6.1.1.  CAPABILITY Command

   Arguments:  none

   Responses:  REQUIRED untagged response: CAPABILITY

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

      The CAPABILITY command requests a listing of capabilities that the
      server supports.  The server MUST send a single untagged
      CAPABILITY response with "IMAP4rev1" as one of the listed
      capabilities before the (tagged) OK response.  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 connection.









Crispin                     Standards Track                    [Page 18]

RFC 2060                       IMAP4rev1                   December 1996


      A capability name which begins with "AUTH=" indicates that the
      server supports that particular authentication mechanism.  All
      such names are, by definition, part of this specification.  For
      example, the authorization capability for an experimental
      "blurdybloop" authenticator would be "AUTH=XBLURDYBLOOP" and not
      "XAUTH=BLURDYBLOOP" or "XAUTH=XBLURDYBLOOP".

      Other capability names refer to extensions, revisions, or
      amendments to this specification.  See the documentation of the
      CAPABILITY response for additional information.  No capabilities,
      beyond the base IMAP4rev1 set defined in this specification, are
      enabled without explicit client action to invoke the capability.

      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 IMAP4rev1 AUTH=KERBEROS_V4
               S: abcd OK CAPABILITY completed

6.1.2.  NOOP Command

   Arguments:  none

   Responses:  no specific responses for this command (but see below)

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

      The NOOP command always succeeds.  It does nothing.

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

   Example:    C: a002 NOOP
               S: a002 OK NOOP completed
                  . . .
               C: a047 NOOP
               S: * 22 EXPUNGE
               S: * 23 EXISTS
               S: * 3 RECENT
               S: * 14 FETCH (FLAGS (\Seen \Deleted))
               S: a047 OK NOOP completed




Crispin                     Standards Track                    [Page 19]

RFC 2060                       IMAP4rev1                   December 1996


6.1.3.  LOGOUT Command

   Arguments:  none

   Responses:  REQUIRED untagged response: BYE

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

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

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

6.2.    Client Commands - 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.












Crispin                     Standards Track                    [Page 20]

RFC 2060                       IMAP4rev1                   December 1996


6.2.1.  AUTHENTICATE Command

   Arguments:  authentication mechanism name

   Responses:  continuation data can be requested

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

      The AUTHENTICATE command indicates 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
      client.  It MAY also negotiate an OPTIONAL 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 issues 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 connection.  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.

      Authentication mechanisms are OPTIONAL.  Protection mechanisms are
      also OPTIONAL; an authentication mechanism MAY be implemented
      without any protection mechanism.  If an AUTHENTICATE command
      fails with a NO response, the client MAY try another



Crispin                     Standards Track                    [Page 21]

RFC 2060                       IMAP4rev1                   December 1996


      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 IMAP4rev1 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

   Responses:  no specific responses for this command

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

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

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

6.3.    Client Commands - Authenticated State