rfc2060_imap.txt

邮件编码格式说明。

   provided, or after an error in selecting a mailbox.






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


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

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

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.



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


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 limitations of characters that can be used 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 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.

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.









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


   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 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 ().

5.      Operational Considerations

5.1.    Mailbox Naming

   The interpretation of mailbox names is implementation-dependent.
   However, the case-insensitive mailbox name INBOX is a special name
   reserved to mean "the primary mailbox for this user on this server".

5.1.1.  Mailbox Hierarchy Naming

   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.1.2.  Mailbox Namespace Naming Convention

   By convention, the first hierarchical element of any mailbox name
   which begins with "#" identifies the "namespace" of the remainder of
   the name.  This makes it possible to disambiguate between different
   types of mailbox stores, each of which have their own namespaces.







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


      For example, implementations which offer access to USENET
      newsgroups MAY use the "#news" namespace to partition the USENET
      newsgroup namespace from that of other mailboxes.  Thus, the
      comp.mail.misc newsgroup would have an mailbox name of
      "#news.comp.mail.misc", and the name "comp.mail.misc" could refer
      to a different object (e.g. a user's private mailbox).

5.1.3.  Mailbox International Naming Convention

   By convention, international mailbox names are specified using a
   modified version of the UTF-7 encoding described in [UTF-7].  The
   purpose of these modifications is to correct the following problems
   with UTF-7:

      1) UTF-7 uses the "+" character for shifting; this conflicts with
         the common use of "+" in mailbox names, in particular USENET
         newsgroup names.

      2) UTF-7's encoding is BASE64 which uses the "/" character; this
         conflicts with the use of "/" as a popular hierarchy delimiter.

      3) UTF-7 prohibits the unencoded usage of "\"; this conflicts with
         the use of "\" as a popular hierarchy delimiter.

      4) UTF-7 prohibits the unencoded usage of "~"; this conflicts with
         the use of "~" in some servers as a home directory indicator.

      5) UTF-7 permits multiple alternate forms to represent the same
         string; in particular, printable US-ASCII chararacters can be
         represented in encoded form.

   In modified UTF-7, printable US-ASCII characters except for "&"
   represent themselves; that is, characters with octet values 0x20-0x25
   and 0x27-0x7e.  The character "&" (0x26) is represented by the two-
   octet sequence "&-".

   All other characters (octet values 0x00-0x1f, 0x7f-0xff, and all
   Unicode 16-bit octets) are represented in modified BASE64, with a
   further modification from [UTF-7] that "," is used instead of "/".
   Modified BASE64 MUST NOT be used to represent any printing US-ASCII
   character which can represent itself.

   "&" is used to shift to modified BASE64 and "-" to shift back to US-
   ASCII.  All names start in US-ASCII, and MUST end in US-ASCII (that
   is, a name that ends with a Unicode 16-bit octet MUST end with a "-
   ").





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


      For example, here is a mailbox name which mixes English, Japanese,
      and Chinese text: ~peter/mail/&ZeVnLIqe-/&U,BTFw-

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

   Regardless of what implementation decisions a client makes 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.

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.













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


5.5.    Multiple Commands in Progress

   The client MAY send another command without waiting for the
   completion result response of a command, subject to ambiguity rules
   (see below) and flow control constraints on the underlying data
   stream.  Similarly, a server MAY begin processing another command
   before processing the current command to completion, subject to
   ambiguity rules.  However, any command continuation request responses
   and command continuations MUST be negotiated before any subsequent
   command is initiated.

   The exception is if an ambiguity would result because of a command
   that would affect the results of other commands.  Clients MUST NOT