rfc3501.txt

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

   the case of messages delivered via [SMTP], this SHOULD be the
   date and time of final delivery of the message as defined by
   [SMTP].  In the case of messages delivered by the IMAP4rev1 COPY
   command, this SHOULD be the internal date and time of the source
   message.  In the case of messages delivered by the IMAP4rev1
   APPEND command, this SHOULD be the date and time as specified in
   the APPEND command description.  All other cases are
   implementation defined.

2.3.4.  [RFC-2822] Size Message Attribute

   The number of octets in the message, as expressed in [RFC-2822]
   format.

2.3.5.  Envelope Structure Message Attribute

   A parsed representation of the [RFC-2822] header of the message.
   Note that the IMAP Envelope structure is not the same as an
   [SMTP] envelope.

2.3.6.  Body Structure Message Attribute

   A parsed representation of the [MIME-IMB] body structure
   information of the message.











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


2.4.    Message Texts

   In addition to being able to fetch the full [RFC-2822] text of a
   message, IMAP4rev1 permits the fetching of portions of the full
   message text.  Specifically, it is possible to fetch the
   [RFC-2822] message header, [RFC-2822] message body, a [MIME-IMB]
   body part, or a [MIME-IMB] header.

3.      State and Flow Diagram

   Once the connection between client and server is established, an
   IMAP4rev1 connection is in one of four states.  The initial
   state is identified in the server greeting.  Most commands are
   only valid in certain states.  It is a protocol error for the
   client to attempt a command while the connection is in an
   inappropriate state, and the server will respond with a BAD or
   NO (depending upon server implementation) command completion
   result.

3.1.    Not Authenticated State

   In the not authenticated state, the client 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 the authenticated state, the client 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, after an error in
   selecting a mailbox, or after a successful CLOSE command.

3.3.    Selected State

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











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


3.4.    Logout State

   In the logout state, the connection is being terminated.  This
   state can be entered as a result of a client request (via the
   LOGOUT command) or by unilateral action on the part of either
   the client or server.

   If the client requests the logout state, the server MUST send an
   untagged BYE response and a tagged OK response to the LOGOUT
   command before the server closes the connection; and the client
   MUST read the tagged OK response to the LOGOUT command before
   the client closes the connection.

   A server MUST NOT unilaterally close the connection without
   sending an untagged BYE response that contains the reason for
   having done so.  A client SHOULD NOT unilaterally close the
   connection, and instead SHOULD issue a LOGOUT command.  If the
   server detects that the client has unilaterally closed the
   connection, the server MAY omit the untagged BYE response and
   simply close its connection.































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


                   +----------------------+
                   |connection established|
                   +----------------------+
                              ||
                              \/
            +--------------------------------------+
            |          server greeting             |
            +--------------------------------------+
                      || (1)       || (2)        || (3)
                      \/           ||            ||
            +-----------------+    ||            ||
            |Not Authenticated|    ||            ||
            +-----------------+    ||            ||
             || (7)   || (4)       ||            ||
             ||       \/           \/            ||
             ||     +----------------+           ||
             ||     | Authenticated  |<=++       ||
             ||     +----------------+  ||       ||
             ||       || (7)   || (5)   || (6)   ||
             ||       ||       \/       ||       ||
             ||       ||    +--------+  ||       ||
             ||       ||    |Selected|==++       ||
             ||       ||    +--------+           ||
             ||       ||       || (7)            ||
             \/       \/       \/                \/
            +--------------------------------------+
            |               Logout                 |
            +--------------------------------------+
                              ||
                              \/
                +-------------------------------+
                |both sides close the 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










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


4.      Data Formats

   IMAP4rev1 uses textual commands and responses.  Data in
   IMAP4rev1 can be in one of several forms: atom, number, string,
   parenthesized list, or NIL.  Note that a particular data item
   may take more than one form; for example, a data item defined as
   using "astring" syntax may be either an atom or a string.

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: either literal or 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 limitations of characters
   which may be used.

   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 represented 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.






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


4.3.1.  8-bit and Binary Strings

   8-bit textual and binary mail is supported through the use of a
   [MIME-IMB] content transfer encoding.  IMAP4rev1 implementations MAY
   transmit 8-bit or multi-octet characters in literals, but SHOULD do
   so only when the [CHARSET] 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.

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 can 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 form "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 ().

        Note: NIL is never used for any data item which takes the
        form of an atom.  For example, a mailbox name of "NIL" is a
        mailbox named NIL as opposed to a non-existent mailbox
        name.  This is because mailbox uses "astring" syntax which
        is an atom or a string.  Conversely, an addr-name of NIL is
        a non-existent personal name, because addr-name uses
        "nstring" syntax which is NIL or a string, but never an
        atom.













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