172 lines
5.7 KiB
Plaintext
172 lines
5.7 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
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]
|
||
|