RFC 2683 (rfc2683) - Page 2 of 23
IMAP4 Implementation Recommendations
Alternative Format: Original Text Document
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