rfc3501.txt

广泛使用的邮件服务器！同时

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

   The state of a connection is only changed by successful commands
   which are documented as changing state.  A rejected command (BAD
   response) never changes the state of the connection or of the
   selected mailbox.  A failed command (NO response) generally does not
   change the state of the connection or of the selected mailbox; the
   exception being the SELECT and EXAMINE commands.



Crispin                     Standards Track                    [Page 23]

RFC 3501                         IMAPv4                       March 2003


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.

      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.

      Client and server implementations MUST implement the STARTTLS,
      LOGINDISABLED, and AUTH=PLAIN (described in [IMAP-TLS])
      capabilities.  See the Security Considerations section for
      important information.

      See the section entitled "Client Commands -
      Experimental/Expansion" for information about the form of site or
      implementation-specific capabilities.











Crispin                     Standards Track                    [Page 24]

RFC 3501                         IMAPv4                       March 2003


   Example:    C: abcd CAPABILITY
               S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI
               LOGINDISABLED
               S: abcd OK CAPABILITY completed
               C: efgh STARTTLS
               S: efgh OK STARTLS completed
               <TLS negotiation, further commands are under [TLS] layer>
               C: ijkl CAPABILITY
               S: * CAPABILITY IMAP4rev1 AUTH=GSSAPI AUTH=PLAIN
               S: ijkl 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 (this is the
      preferred method to do this).  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 25]

RFC 3501                         IMAPv4                       March 2003


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 - Not Authenticated State

   In the not authenticated state, the AUTHENTICATE or LOGIN command
   establishes authentication and enters the authenticated state.  The
   AUTHENTICATE command provides a general mechanism for a variety of
   authentication techniques, privacy protection, and integrity
   checking; whereas the LOGIN command uses a traditional user name and
   plaintext password pair and has no means of establishing privacy
   protection or integrity checking.

   The STARTTLS command is an alternate form of establishing session
   privacy protection and integrity checking, but does not establish
   authentication or enter the authenticated state.

   Server implementations MAY allow access to certain mailboxes without
   establishing authentication.  This can be done by means of the
   ANONYMOUS [SASL] authenticator described in [ANONYMOUS].  An older
   convention is a LOGIN command using the userid "anonymous"; in this
   case, a password is required although the server may choose to accept
   any password.  The restrictions placed on anonymous users are
   implementation-dependent.

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








Crispin                     Standards Track                    [Page 26]

RFC 3501                         IMAPv4                       March 2003


   In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
   the following commands are valid in the not authenticated state:
   STARTTLS, AUTHENTICATE and LOGIN.  See the Security Considerations
   section for important information about these commands.

6.2.1.  STARTTLS Command

   Arguments:  none

   Responses:  no specific response for this command

   Result:     OK - starttls completed, begin TLS negotiation
               BAD - command unknown or arguments invalid

      A [TLS] negotiation begins immediately after the CRLF at the end
      of the tagged OK response from the server.  Once a client issues a
      STARTTLS command, it MUST NOT issue further commands until a
      server response is seen and the [TLS] negotiation is complete.

      The server remains in the non-authenticated state, even if client
      credentials are supplied during the [TLS] negotiation.  This does
      not preclude an authentication mechanism such as EXTERNAL (defined
      in [SASL]) from using client identity determined by the [TLS]
      negotiation.

      Once [TLS] has been started, the client MUST discard cached
      information about server capabilities and SHOULD re-issue the
      CAPABILITY command.  This is necessary to protect against man-in-
      the-middle attacks which alter the capabilities list prior to
      STARTTLS.  The server MAY advertise different capabilities after
      STARTTLS.

   Example:    C: a001 CAPABILITY
               S: * CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED
               S: a001 OK CAPABILITY completed
               C: a002 STARTTLS
               S: a002 OK Begin TLS negotiation now
               <TLS negotiation, further commands are under [TLS] layer>
               C: a003 CAPABILITY
               S: * CAPABILITY IMAP4rev1 AUTH=PLAIN
               S: a003 OK CAPABILITY completed
               C: a004 LOGIN joe password
               S: a004 OK LOGIN completed








Crispin                     Standards Track                    [Page 27]

RFC 3501                         IMAPv4                       March 2003


6.2.2.  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 a [SASL] authentication
      mechanism 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 security layer 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 AUTHENTICATE command does not support the optional "initial
      response" feature of [SASL].  Section 5.1 of [SASL] specifies how
      to handle an authentication mechanism which uses an initial
      response.

      The service name specified by this protocol's profile of [SASL] is
      "imap".

      The authentication protocol exchange consists of a series of
      server challenges and client responses 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 response consists of a
      single line consisting of a BASE64 encoded string.  If the client
      wishes to cancel an authentication exchange, it issues a line
      consisting of a single "*".  If the server receives such a
      response, it MUST reject the AUTHENTICATE command by sending a
      tagged BAD response.

      If a security layer is negotiated through the [SASL]
      authentication exchange, it 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.

      While client and server implementations MUST implement the
      AUTHENTICATE command itself, it is not required to implement any
      authentication mechanisms other than the PLAIN mechanism described



Crispin                     Standards Track                    [Page 28]

RFC 3501                         IMAPv4                       March 2003


      in [IMAP-TLS].  Also, an authentication mechanism is not required
      to support any security layers.

           Note: a server implementation MUST implement a
           configuration in which it does NOT permit any plaintext
           password mechanisms, unless either the STARTTLS command
           has been negotiated or some other mechanism that
           protects the session from password snooping has been
           provided.  Server sites SHOULD NOT use any configuration
           which permits a plaintext password mechanism without
           such a protection mechanism against password snooping.
           Client and server implementations SHOULD implement
           additional [SASL] mechanisms that do not use plaintext
           passwords, such the GSSAPI mechanism described in [SASL]
           and/or the [DIGEST-MD5] mechanism.

      Servers and clients can support multiple authentication
      mechanisms.  The server SHOULD list its supported authentication
      mechanisms in the response to the CAP