IMAP4 Implementation Recommendations
RFC 2683

Document Type RFC - Informational (September 1999; Errata)
Updated by RFC 7162
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 2683 (Informational)
Telechat date
Responsible AD (None)
Send notices to (None)
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]
Show full document text