RFC 2683 (rfc2683) - Page 2 of 23

IMAP4 Implementation Recommendations

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