rfc2683.txt

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

Network Working Group                                           B. Leiba
Request for Comments: 2683               IBM T.J. Watson Research Center
Category: Informational                                   September 1999


                  IMAP4 Implementation Recommendations

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

1. Abstract

   The IMAP4 specification [RFC-2060] describes a rich protocol for use
   in building clients and servers for storage, retrieval, and
   manipulation of electronic mail.  Because the protocol is so rich and
   has so many implementation choices, there are often trade-offs that
   must be made and issues that must be considered when designing such
   clients and servers.  This document attempts to outline these issues
   and to make recommendations in order to make the end products as
   interoperable as possible.

2. Conventions used in this document

   In examples, "C:" indicates lines sent by a client that is connected
   to a server.  "S:" indicates lines sent by the server to the client.

   The words "must", "must not", "should", "should not", and "may" are
   used with specific meaning in this document; since their meaning is
   somewhat different from that specified in RFC 2119, we do not put
   them in all caps here.  Their meaning is as follows:

   must --       This word means that the action described is necessary
                 to ensure interoperability.  The recommendation should
                 not be ignored.
   must not --   This phrase means that the action described will be
                 almost certain to hurt interoperability.  The
                 recommendation should not be ignored.







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


   should --     This word means that the action described is strongly
                 recommended and will enhance interoperability or
                 usability.  The recommendation should not be ignored
                 without careful consideration.
   should not -- This phrase means that the action described is strongly
                 recommended against, and might hurt interoperability or
                 usability.  The recommendation should not be ignored
                 without careful consideration.
   may --        This word means that the action described is an
                 acceptable implementation choice.  No specific
                 recommendation is implied; this word is used to point
                 out a choice that might not be obvious, or to let
                 implementors know what choices have been made by
                 existing implementations.

3. Interoperability Issues and Recommendations

3.1.   Accessibility

   This section describes the issues related to access to servers and
   server resources.  Concerns here include data sharing and maintenance
   of client/server connections.

3.1.1. Multiple Accesses of the Same Mailbox

   One strong point of IMAP4 is that, unlike POP3, it allows for
   multiple simultaneous access to a single mailbox.  A user can, thus,
   read mail from a client at home while the client in the office is
   still connected; or the help desk staff can all work out of the same
   inbox, all seeing the same pool of questions.  An important point
   about this capability, though is that NO SERVER IS GUARANTEED TO
   SUPPORT THIS.  If you are selecting an IMAP server and this facility
   is important to you, be sure that the server you choose to install,
   in the configuration you choose to use, supports it.

   If you are designing a client, you must not assume that you can
   access the same mailbox more than once at a time.  That means

   1. you must handle gracefully the failure of a SELECT command if the
      server refuses the second SELECT,
   2. you must handle reasonably the severing of your connection (see
      "Severed Connections", below) if the server chooses to allow the
      second SELECT by forcing the first off,
   3. you must avoid making multiple connections to the same mailbox in
      your own client (for load balancing or other such reasons), and
   4. you must avoid using the STATUS command on a mailbox that you have
      selected (with some server implementations the STATUS command has
      the same problems with multiple access as do the SELECT and



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


      EXAMINE commands).

   A further note about STATUS: The STATUS command is sometimes used to
   check a non-selected mailbox for new mail.  This mechanism must not
   be used to check for new mail in the selected mailbox; section 5.2 of
   [RFC-2060] specifically forbids this in its last paragraph.  Further,
   since STATUS takes a mailbox name it is an independent operation, not
   operating on the selected mailbox.  Because of this, the information
   it returns is not necessarily in synchronization with the selected
   mailbox state.

3.1.2. Severed Connections

   The client/server connection may be severed for one of three reasons:
   the client severs the connection, the server severs the connection,
   or the connection is severed by outside forces beyond the control of
   the client and the server (a telephone line drops, for example).
   Clients and servers must both deal with these situations.

   When the client wants to sever a connection, it's usually because it
   has finished the work it needed to do on that connection.  The client
   should send a LOGOUT command, wait for the tagged response, and then
   close the socket.  But note that, while this is what's intended in
   the protocol design, there isn't universal agreement here.  Some
   contend that sending the LOGOUT and waiting for the two responses
   (untagged BYE and tagged OK) is wasteful and unnecessary, and that
   the client can simply close the socket.  The server should interpret
   the closed socket as a log out by the client.  The counterargument is
   that it's useful from the standpoint of cleanup, problem
   determination, and the like, to have an explicit client log out,
   because otherwise there is no way for the server to tell the
   difference between "closed socket because of log out" and "closed
   socket because communication was disrupted".  If there is a
   client/server interaction problem, a client which routinely
   terminates a session by breaking the connection without a LOGOUT will
   make it much more difficult to determine the problem.

   Because of this disagreement, server designers must be aware that
   some clients might close the socket without sending a LOGOUT.  In any
   case, whether or not a LOGOUT was sent, the server should not
   implicitly expunge any messages from the selected mailbox.  If a
   client wants the server to do so, it must send a CLOSE or EXPUNGE
   command explicitly.

   When the server wants to sever a connection it's usually due to an
   inactivity timeout or is because a situation has arisen that has
   changed the state of the mail store in a way that the server can not
   communicate to the client.  The server should send an untagged BYE



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


   response to the client and then close the socket.  Sending an
   untagged BYE response before severing allows the server to send a
   human-readable explanation of the problem to the client, which the
   client may then log, display to the user, or both (see section 7.1.5
   of [RFC-2060]).

   Regarding inactivity timeouts, there is some controversy.  Unlike
   POP, for which the design is for a client to connect, retrieve mail,
   and log out, IMAP's design encourages long-lived (and mostly
   inactive) client/server sessions.  As the number of users grows, this
   can use up a lot of server resources, especially with clients that
   are designed to maintain sessions for mailboxes that the user has
   finished accessing.  To alleviate this, a server may implement an
   inactivity timeout, unilaterally closing a session (after first
   sending an untagged BYE, as noted above).  Some server operators have
   reported dramatic improvements in server performance after doing
   this.  As specified in [RFC-2060], if such a timeout is done it must
   not be until at least 30 minutes of inactivity.  The reason for this
   specification is to prevent clients from sending commands (such as
   NOOP) to the server at frequent intervals simply to avert a too-early
   timeout.  If the client knows that the server may not time out the
   session for at least 30 minutes, then the client need not poll at
   intervals more frequent than, say, 25 minutes.

3.2.   Scaling

   IMAP4 has many features that allow for scalability, as mail stores
   become larger and more numerous.  Large numbers of users, mailboxes,
   and messages, and very large messages require thought to handle
   efficiently.  This document will not address the administrative
   issues involved in large numbers of users, but we will look at the
   other items.

3.2.1. Flood Control

   There are three situations when a client can make a request that will
   result in a very large response - too large for the client reasonably
   to deal with: there are a great many mailboxes available, there are a
   great many messages in the selected mailbox, or there is a very large
   message part.  The danger here is that the end user will be stuck
   waiting while the server sends (and the client processes) an enormous
   response.  In all of these cases there are things a client can do to
   reduce that danger.

   There is also the case where a client can flood a server, by sending
   an arbitratily long command.  We'll discuss that issue, too, in this
   section.




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


3.2.1.1.  Listing Mailboxes

   Some servers present Usenet newsgroups to IMAP users.  Newsgroups,
   and other such hierarchical mailbox structures, can be very numerous
   but may have only a few entries at the top level of hierarchy.  Also,
   some servers are built against mail stores that can, unbeknownst to
   the server, have circular hierarchies - that is, it's possible for
   "a/b/c/d" to resolve to the same file structure as "a", which would
   then mean that "a/b/c/d/b" is the same as "a/b", and the hierarchy
   will never end.  The LIST response in this case will be unlimited.

   Clients that will have trouble with this are those that use

       C: 001 LIST "" *

   to determine the mailbox list.  Because of this, clients should not
   use an unqualified "*" that way in the LIST command.  A safer
   approach is to list each level of hierarchy individually, allowing
   the user to traverse the tree one limb at a time, thus:

       C: 001 LIST "" %
       S: * LIST () "/" Banana
       S: * LIST ...etc...
       S: 001 OK done

   and then

       C: 002 LIST "" Banana/%
       S: * LIST () "/" Banana/Apple
       S: * LIST ...etc...
       S: 002 OK done

   Using this technique the client's user interface can give the user
   full flexibility without choking on the voluminous reply to "LIST *".

   Of course, it is still possible that the reply to

       C: 005 LIST "" alt.fan.celebrity.%

   may be thousands of entries long, and there is, unfortunately,
   nothing the client can do to protect itself from that.  This has not
   yet been a notable problem.

   Servers that may export circular hierarchies (any server that
   directly presents a UNIX file system, for instance) should limit the
   hierarchy depth to prevent unlimited LIST responses.  A suggested
   depth limit is 20 hierarchy levels.




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


3.2.1.2.  Fetching the List of Messages

   When a client selects a mailbox, it is given a count, in the untagged
   EXISTS response, of the messages in the mailbox.  This number can be
   very large.  In such a case it might be unwise to use

       C: 004 FETCH 1:* ALL

   to populate the user's view of the mailbox.  One good method to avoid
   problems with this is to batch the requests, thus:

       C: 004 FETCH 1:50 ALL
       S: * 1 FETCH ...etc...
       S: 004 OK done
       C: 005 FETCH 51:100 ALL
       S: * 51 FETCH ...etc...
       S: 005 OK done
       C: 006 FETCH 101:150 ALL
       ...etc...

   Using this method, another command, such as "FETCH 6 BODY[1]" can be
   inserted as necessary, and the client will not have its access to the
   server blocked by a storm of FETCH replies.  (Such a method could be
   reversed to fetch the LAST 50 messages first, then the 50 prior to
   that, and so on.)

   As a smart extension of this, a well designed client, prepared for
   very large mailboxes, will not automatically fetch data for all
   messages AT ALL.  Rather, the client will populate the user's view
   only as the user sees it, possibly pre-fetching selected information,
   and only fetching other information as the user scrolls to it.  For
   example, to select only those messages beginning with the first
   unseen one:

       C: 003 SELECT INBOX
       S: * 10000 EXISTS
       S: * 80 RECENT