rfc2683.txt

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

       S: * FLAGS (\Answered \Flagged \Deleted \Draft \Seen)
       S: * OK [UIDVALIDITY 824708485] UID validity status
       S: * OK [UNSEEN 9921] First unseen message
       S: 003 OK [READ-WRITE] SELECT completed
       C: 004 FETCH 9921:* ALL
       ... etc...

   If the server does not return an OK [UNSEEN] response, the client may
   use SEARCH UNSEEN to obtain that value.





Leiba                        Informational                      [Page 6]

RFC 2683          IMAP4 Implementation Recommendations    September 1999


   This mechanism is good as a default presentation method, but only
   works well if the default message order is acceptable.  A client may
   want to present various sort orders to the user (by subject, by date
   sent, by sender, and so on) and in that case (lacking a SORT
   extension on the server side) the client WILL have to retrieve all
   message descriptors.  A client that provides this service should not
   do it by default and should inform the user of the costs of choosing
   this option for large mailboxes.

3.2.1.3.  Fetching a Large Body Part

   The issue here is similar to the one for a list of messages.  In the
   BODYSTRUCTURE response the client knows the size, in bytes, of the
   body part it plans to fetch.  Suppose this is a 70 MB video clip. The
   client can use partial fetches to retrieve the body part in pieces,
   avoiding the problem of an uninterruptible 70 MB literal coming back
   from the server:

       C: 022 FETCH 3 BODY[1]<0.20000>
       S: * 3 FETCH (FLAGS(\Seen) BODY[1]<0> {20000}
       S: ...data...)
       S: 022 OK done
       C: 023 FETCH 3 BODY[1]<20001.20000>
       S: * 3 FETCH (BODY[1]<20001> {20000}
       S: ...data...)
       S: 023 OK done
       C: 024 FETCH 3 BODY[1]<40001.20000>
       ...etc...

3.2.1.4.  BODYSTRUCTURE vs. Entire Messages

   Because FETCH BODYSTRUCTURE is necessary in order to determine the
   number of body parts, and, thus, whether a message has "attachments",
   clients often use FETCH FULL as their normal method of populating the
   user's view of a mailbox.  The benefit is that the client can display
   a paperclip icon or some such indication along with the normal
   message summary.  However, this comes at a significant cost with some
   server configurations.  The parsing needed to generate the FETCH
   BODYSTRUCTURE response may be time-consuming compared with that
   needed for FETCH ENVELOPE.  The client developer should consider this
   issue when deciding whether the ability to add a paperclip icon is
   worth the tradeoff in performance, especially with large mailboxes.

   Some clients, rather than using FETCH BODYSTRUCTURE, use FETCH BODY[]
   (or the equivalent FETCH RFC822) to retrieve the entire message.
   They then do the MIME parsing in the client.  This may give the
   client slightly more flexibility in some areas (access, for instance,
   to header fields that aren't returned in the BODYSTRUCTURE and



Leiba                        Informational                      [Page 7]

RFC 2683          IMAP4 Implementation Recommendations    September 1999


   ENVELOPE responses), but it can cause severe performance problems by
   forcing the transfer of all body parts when the user might only want
   to see some of them - a user logged on by modem and reading a small
   text message with a large ZIP file attached may prefer to read the
   text only and save the ZIP file for later.  Therefore, a client
   should not normally retrieve entire messages and should retrieve
   message body parts selectively.

3.2.1.5.  Long Command Lines

   A client can wind up building a very long command line in an effort to
   try to be efficient about requesting information from a server.  This
   can typically happen when a client builds a message set from selected
   messages and doesn't recognise that contiguous blocks of messages may
   be group in a range.  Suppose a user selects all 10,000 messages in a
   large mailbox and then unselects message 287.  The client could build
   that message set as "1:286,288:10000", but a client that doesn't
   handle that might try to enumerate each message individually and build
   "1,2,3,4, [and so on] ,9999,10000".  Adding that to the fetch command
   results in a command line that's almost 49,000 octets long, and,
   clearly, one can construct a command line that's even longer.

   A client should limit the length of the command lines it generates to
   approximately 1000 octets (including all quoted strings but not
   including literals).  If the client is unable to group things into
   ranges so that the command line is within that length, it should
   split the request into multiple commands.  The client should use
   literals instead of long quoted strings, in order to keep the command
   length down.

   For its part, a server should allow for a command line of at least
   8000 octets.  This provides plenty of leeway for accepting reasonable
   length commands from clients.  The server should send a BAD response
   to a command that does not end within the server's maximum accepted
   command length.

3.2.2. Subscriptions

   The client isn't the only entity that can get flooded: the end user,
   too, may need some flood control.  The IMAP4 protocol provides such
   control in the form of subscriptions.  Most servers support the
   SUBSCRIBE, UNSUBSCRIBE, and LSUB commands, and many users choose to
   narrow down a large list of available mailboxes by subscribing to the
   ones that they usually want to see.  Clients, with this in mind,
   should give the user a way to see only subscribed mailboxes.  A
   client that never uses the LSUB command takes a significant usability
   feature away from the user.  Of course, the client would not want to
   hide the LIST command completely; the user needs to have a way to



Leiba                        Informational                      [Page 8]

RFC 2683          IMAP4 Implementation Recommendations    September 1999


   choose between LIST and LSUB.  The usual way to do this is to provide
   a setting like "show which mailboxes?:  [] all  [] subscribed only".

3.2.3. Searching

   IMAP SEARCH commands can become particularly troublesome (that is,
   slow) on mailboxes containing a large number of messages.  So let's
   put a few things in perspective in that regard.

   The flag searches should be fast.  The flag searches (ALL, [UN]SEEN,
   [UN]ANSWERED, [UN]DELETED, [UN]DRAFT, [UN]FLAGGED, NEW, OLD, RECENT)
   are known to be used by clients for the client's own use (for
   instance, some clients use "SEARCH UNSEEN" to find unseen mail and
   "SEARCH DELETED" to warn the user before expunging messages).

   Other searches, particularly the text searches (HEADER, TEXT, BODY)
   are initiated by the user, rather than by the client itself, and
   somewhat slower performance can be tolerated, since the user is aware
   that the search is being done (and is probably aware that it might be
   time-consuming).  A smart server might use dynamic indexing to speed
   commonly used text searches.

   The client may allow other commands to be sent to the server while a
   SEARCH is in progress, but at the time of this writing there is
   little or no server support for parallel processing of multiple
   commands in the same session (and see "Multiple Accesses of the Same
   Mailbox" above for a description of the dangers of trying to work
   around this by doing your SEARCH in another session).

   Another word about text searches: some servers, built on database
   back-ends with indexed search capabilities, may return search results
   that do not match the IMAP spec's "case-insensitive substring"
   requirements.  While these servers are in violation of the protocol,
   there is little harm in the violation as long as the search results
   are used only in response to a user's request.  Still, developers of
   such servers should be aware that they ARE violating the protocol,
   should think carefully about that behaviour, and must be certain that
   their servers respond accurately to the flag searches for the reasons
   outlined above.

   In addition, servers should support CHARSET UTF-8 [UTF-8] in
   searches.









Leiba                        Informational                      [Page 9]

RFC 2683          IMAP4 Implementation Recommendations    September 1999


3.3    Avoiding Invalid Requests

   IMAP4 provides ways for a server to tell a client in advance what is
   and isn't permitted in some circumstances.  Clients should use these
   features to avoid sending requests that a well designed client would
   know to be invalid.  This section explains this in more detail.

3.3.1. The CAPABILITY Command

   All IMAP4 clients should use the CAPABILITY command to determine what
   version of IMAP and what optional features a server supports.  The
   client should not send IMAP4rev1 commands and arguments to a server
   that does not advertize IMAP4rev1 in its CAPABILITY response.
   Similarly, the client should not send IMAP4 commands that no longer
   exist in IMAP4rev1 to a server that does not advertize IMAP4 in its
   CAPABILITY response.  An IMAP4rev1 server is NOT required to support
   obsolete IMAP4 or IMAP2bis commands (though some do; do not let this
   fact lull you into thinking that it's valid to send such commands to
   an IMAP4rev1 server).

   A client should not send commands to probe for the existance of
   certain extensions.  All standard and standards-track extensions
   include CAPABILITY tokens indicating their presense.  All private and
   experimental extensions should do the same, and clients that take
   advantage of them should use the CAPABILITY response to determine
   whether they may be used or not.

3.3.2. Don't Do What the Server Says You Can't

   In many cases, the server, in response to a command, will tell the
   client something about what can and can't be done with a particular
   mailbox.  The client should pay attention to this information and
   should not try to do things that it's been told it can't do.

   Examples:

   *  Do not try to SELECT a mailbox that has the \Noselect flag set.
   *  Do not try to CREATE a sub-mailbox in a mailbox that has the
      \Noinferiors flag set.
   *  Do not respond to a failing COPY or APPEND command by trying to
      CREATE the target mailbox if the server does not respond with a
      [TRYCREATE] response code.
   *  Do not try to expunge a mailbox that has been selected with the
      [READ-ONLY] response code.







Leiba                        Informational                     [Page 10]

RFC 2683          IMAP4 Implementation Recommendations    September 1999


3.4.   Miscellaneous Protocol Considerations

   We describe here a number of important protocol-related issues, the
   misunderstanding of which has caused significant interoperability
   problems in IMAP4 implementations.  One general item is that every
   implementer should be certain to take note of and to understand
   section 2.2.2 and the preamble to section 7 of the IMAP4rev1 spec
   [RFC-2060].

3.4.1. Well Formed Protocol

   We cannot stress enough the importance of adhering strictly to the
   protocol grammar.  The specification of the protocol is quite rigid;
   do not assume that you can insert blank space for "readability" if
   none is called for.  Keep in mind that there are parsers out there
   that will crash if there are protocol errors.  There are clients that
   will report every parser burp to the user.  And in any case,
   information that cannot be parsed is information that is lost.  Be
   careful in your protocol generation.  And see "A Word About Testing",
   below.

   In particular, note that the string in the INTERNALDATE response is
   NOT an RFC-822 date string - that is, it is not in the same format as
   the first string in the ENVELOPE response.  Since most clients will,
   in fact, accept an RFC-822 date string in the INTERNALDATE response,
   it's easy to miss this in your interoperability testing.  But it will
   cause a problem with some client, so be sure to generate the correct
   string for this field.

3.4.2. Special Characters

   Certain characters, currently the double-quote and the backslash, may
   not be sent as-is inside a quoted string.  These characters must be
   preceded by the escape character if they are in a quoted string, or
   else the string must be sent as a literal.  Both clients and servers
   must handle this, both on output (they must send these characters
   properly) and on input (they must be able to receive escaped
   characters in quoted strings).  Example:

       C: 001 LIST "" %
       S: * LIST () "" INBOX
       S: * LIST () "\\" TEST
       S: * LIST () "\\" {12}
       S: "My" mailbox
       S: 001 OK done
       C: 002 LIST "" "\"My\" mailbox\\%"
       S: * LIST () "\\" {17}
       S: "My" mailbox\Junk



Leiba                        Informational                     [Page 11]

RFC 2683          IMAP4 Implementation Recommendations    September 1999


       S: 002 OK done

   Note that in the example the server sent the hierarchy delimiter as
   an escaped character in the quoted string and sent the mailbox name
   containing imbedded double-quotes as a literal.  The client used only
   quoted strings, escaping both the backslash and the double-quote
   characters.

   The CR and LF characters may be sent ONLY in literals; they are not
   allowed, even if escaped, inside quoted strings.

   And while we're talking about special characters: the IMAP spec, in
   the section titled "Mailbox International Naming Convention",
   describes how to encode mailbox names in modified UTF-7 [UTF-7 and
   RFC-2060].  Implementations must adhere to this in order to be
   interoperable in the international market, and servers should
   validate mailbox names sent by client and reject names that do not
   conform.

   As to special characters in userids and passwords: clients must not
   restrict what a user may type in for a userid or a password.  The
   formal grammar specifies that these are "astrings", and an astring
   can be a literal.  A literal, in turn can contain any 8-bit
   character, and clients must allow users to enter all 8-bit characters