    Network Working Group                                         M. Crispin
    Request for Comments: 2061                      University of Washington
    Category: Informational                                    December 1996

                       IMAP4 COMPATIBILITY WITH IMAP2BIS

    Status of this Memo

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

    Introduction

       The Internet Message Access Protocol (IMAP) has been through several
       revisions and variants in its 10-year history.  Many of these are
       either extinct or extremely rare; in particular, several undocumented
       variants and the variants described in RFC 1064, RFC 1176, and RFC
       1203 fall into this category.

       One variant, IMAP2bis, is at the time of this writing very common and
       has been widely distributed with the Pine mailer.  Unfortunately,
       there is no definite document describing IMAP2bis.  This document is
       intended to be read along with RFC 1176 and the most recent IMAP4
       specification (RFC 2060) to assist implementors in creating an IMAP4
       implementation to interoperate with implementations that conform to
       earlier specifications.  Nothing in this document is required by the
       IMAP4 specification; implementors must decide for themselves whether
       they want their implementation to fail if it encounters old software.

       At the time of this writing, IMAP4 has been updated from the version
       described in RFC 1730.  An implementor who wishes to interoperate
       with both RFC 1730 and RFC 2060 should refer to both documents.

       This information is not complete; it reflects current knowledge of
       server and client implementations as well as "folklore" acquired in
       the evolution of the protocol.  It is NOT a description of how to
       interoperate with all variants of IMAP, but rather with the old
       variant that is most likely to be encountered.  For detailed
       information on interoperating with other old variants, refer to RFC
       1732.

    IMAP4 client interoperability with IMAP2bis servers

       A quick way to check whether a server implementation supports the
       IMAP4 specification is to try the CAPABILITY command.  An OK response
       will indicate which variant(s) of IMAP4 are supported by the server.

    Crispin                      Informational                      [Page 1]

    RFC 2061                  IMAP4 Compatibility              December 1996

       If the client does not find any of its known variant in the response,
       it should treat the server as IMAP2bis.  A BAD response indicates an
       IMAP2bis or older server.

       Most IMAP4 facilities are in IMAP2bis.  The following exceptions
       exist:

       CAPABILITY command
                The absense of this command indicates IMAP2bis (or older).

       AUTHENTICATE command.
                Use the LOGIN command.

       LSUB, SUBSCRIBE, and UNSUBSCRIBE commands
                No direct functional equivalent.  IMAP2bis had a concept
                called "bboards" which is not in IMAP4.  RFC 1176 supported
                these with the BBOARD and FIND BBOARDS commands.  IMAP2bis
                augmented these with the FIND ALL.BBOARDS, SUBSCRIBE BBOARD,
                and UNSUBSCRIBE BBOARD commands.  It is recommended that
                none of these commands be implemented in new software,
                including servers that support old clients.

       LIST command
                Use the command FIND ALL.MAILBOXES, which has a similar syn-
                tax and response to the FIND MAILBOXES command described in
                RFC 1176.  The FIND MAILBOXES command is unlikely to produce
                useful information.

       * in a sequence
                Use the number of messages in the mailbox from the EXISTS
                unsolicited response.

       SEARCH extensions (character set, additional criteria)
                Reformulate the search request using only the RFC 1176 syn-
                tax.  This may entail doing multiple searches to achieve the
                desired results.

       BODYSTRUCTURE fetch data item
                Use the non-extensible BODY data item.

       body sections HEADER, TEXT, MIME, HEADER.FIELDS, HEADER.FIELDS.NOT
                Use body section numbers only.

       BODY.PEEK[section]
                Use BODY[section] and manually clear the \Seen flag as
                necessary.

    Crispin                      Informational                      [Page 2]

    RFC 2061                  IMAP4 Compatibility              December 1996

       FLAGS.SILENT, +FLAGS.SILENT, and -FLAGS.SILENT store data items
                Use the corresponding non-SILENT versions and ignore the
                untagged FETCH responses which come back.

       UID fetch data item and the UID commands
                No functional equivalent.

       CLOSE command
                No functional equivalent.

       In IMAP2bis, the TRYCREATE special information token is sent as a
       separate unsolicited OK response instead of inside the NO response.

       IMAP2bis is ambiguous about whether or not flags or internal dates
       are preserved on COPY.  It is impossible to know what behavior is
       supported by the server.

    IMAP4 server interoperability with IMAP2bis clients

       The only interoperability problem between an IMAP4 server and a
       well-written IMAP2bis client is an incompatibility with the use of
       "\" in quoted strings.  This is best avoided by using literals
       instead of quoted strings if "\" or <"> is embedded in the string.

    Security Considerations

       Security issues are not discussed in this memo.

    Author's Address

       Mark R. Crispin
       Networks and Distributed Computing
       University of Washington
       4545 15th Aveneue NE
       Seattle, WA  98105-4527

       Phone: (206) 543-5762
       EMail: MRC@CAC.Washington.EDU

    Crispin                      Informational                      [Page 3]