mirror of
https://github.com/uw-imap/imap.git
synced 2024-11-16 10:28:23 +01:00
284 lines
9.1 KiB
Plaintext
284 lines
9.1 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
Network Working Group M. Crispin
|
||
Request for Comments: 1732 University of Washington
|
||
Category: Informational December 1994
|
||
|
||
|
||
IMAP4 COMPATIBILITY WITH IMAP2 AND 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
|
||
|
||
This is a summary of hints and recommendations to enable an IMAP4
|
||
implementation to interoperate with implementations that conform to
|
||
earlier specifications. None of these hints and recommendations are
|
||
required by the IMAP4 specification; implementors must decide for
|
||
themselves whether they want their implementation to fail if it
|
||
encounters old software.
|
||
|
||
IMAP4 has been designed to be upwards compatible with earlier
|
||
specifications. For the most part, IMAP4 facilities that were not in
|
||
earlier specifications should be invisible to clients unless the
|
||
client asks for the facility.
|
||
|
||
In some cases, older servers may support some of the capabilities
|
||
listed as being "new in IMAP4" as experimental extensions to the
|
||
IMAP2 protocol described in RFC 1176.
|
||
|
||
This information may not be complete; it reflects current knowledge
|
||
of server and client implementations as well as "folklore" acquired
|
||
in the evolution of the protocol.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Crispin [Page 1]
|
||
|
||
RFC 1732 IMAP4 - Compatibility December 1994
|
||
|
||
|
||
IMAP4 client interoperability with old servers
|
||
|
||
In general, a client should be able to discover whether an IMAP2
|
||
server supports a facility by trial-and-error; if an attempt to use a
|
||
facility generates a BAD response, the client can assume that the
|
||
server does not support the facility.
|
||
|
||
A quick way to check whether a server implementation supports the
|
||
IMAP4 specification is to try the CAPABILITY command. An OK response
|
||
that includes the IMAP4 capability value indicates a server that
|
||
supports IMAP4; a BAD response or one without the IMAP4 capability
|
||
value indicates an older server.
|
||
|
||
The following is a list of facilities that are only in IMAP4, and
|
||
suggestions for how new clients might interoperate with old servers:
|
||
|
||
CAPABILITY command
|
||
A BAD response to this command indicates that the server
|
||
implements IMAP2 (or IMAP2bis) and not IMAP4.
|
||
|
||
AUTHENTICATE command.
|
||
Use the LOGIN command.
|
||
|
||
LSUB and LIST commands
|
||
Try the RFC 1176 FIND command.
|
||
|
||
* 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 searching
|
||
options listed in search_old in the IMAP4 grammar. This may
|
||
entail doing multiple searches to achieve the desired
|
||
results.
|
||
|
||
BODYSTRUCTURE fetch data item
|
||
Try to fetch the non-extensible BODY data item.
|
||
|
||
body section number 0
|
||
Fetch the entire message and extract the header.
|
||
|
||
RFC822.HEADER.LINES and RFC822.HEADER.LINES.NOT fetch data items
|
||
Use RFC822.HEADER and remove the unwanted information.
|
||
|
||
BODY.PEEK[section], RFC822.PEEK, and RFC822.TEXT.PEEK fetch data
|
||
items Use the corresponding non-PEEK versions and manually
|
||
clear the \Seen flag as necessary.
|
||
|
||
|
||
|
||
Crispin [Page 2]
|
||
|
||
RFC 1732 IMAP4 - Compatibility December 1994
|
||
|
||
|
||
UID fetch data item and the UID commands
|
||
No equivalent capabilitity exists in older servers.
|
||
|
||
FLAGS.SILENT, +FLAGS.SILENT, and -FLAGS.SILENT store data items
|
||
Use the corresponding non-SILENT versions and ignore the
|
||
untagged FETCH responses which com eback.
|
||
|
||
|
||
The following IMAP4 facilities were introduced in the experimental
|
||
IMAP2bis revisions to RFC-1176, and may be present in a server that
|
||
does not support the CAPABILITY command:
|
||
|
||
CREATE, DELETE, and RENAME commands
|
||
To test whether these commands are present, try a CREATE
|
||
INBOX command. If the response is NO, these commands are
|
||
supported by the server. If the response is BAD, they are
|
||
not. Older servers without the CREATE capability may sup-
|
||
port implicit creation of a mailbox by a COPY command with a
|
||
non-existant name as the destination.
|
||
|
||
APPEND command
|
||
To test whether this command is present, try to append a
|
||
zero-length stream to a mailbox name that is known not to
|
||
exist (or at least, highly unlikely to exist) on the remote
|
||
system.
|
||
|
||
SUBSCRIBE and UNSUBSCRIBE commands
|
||
Try the form of these commands with the optional MAILBOX
|
||
keyword.
|
||
|
||
EXAMINE command
|
||
Use the SELECT command instead.
|
||
|
||
flags and internal date argument to APPEND command
|
||
Try the APPEND without any flag list and internal date argu-
|
||
ments.
|
||
|
||
BODY, BODY[section], and FULL fetch data items
|
||
Use RFC822.TEXT and ALL instead. Server does not support
|
||
MIME.
|
||
|
||
PARTIAL command
|
||
Use the appropriate FETCH command and ignore the unwanted
|
||
data.
|
||
|
||
|
||
IMAP4 client implementations must accept all responses and data for-
|
||
mats documented in the IMAP4 specification, including those labeled
|
||
|
||
|
||
|
||
Crispin [Page 3]
|
||
|
||
RFC 1732 IMAP4 - Compatibility December 1994
|
||
|
||
|
||
as obsolete. This includes the COPY and STORE unsolicited responses
|
||
and the old format of dates and times. In particular, client imple-
|
||
mentations must not treat a date/time as a fixed format string; nor
|
||
may they assume that the time begins at a particular octet.
|
||
|
||
IMAP4 client implementations must not depend upon the presence of any
|
||
server extensions that are not in the base IMAP4 specification.
|
||
|
||
The experimental IMAP2bis version specified that the TRYCREATE spe-
|
||
cial information token is sent as a separate unsolicited OK response
|
||
instead of inside the NO response.
|
||
|
||
The FIND BBOARDS, FIND ALL.BBOARDS, and BBOARD commands of RFC 1176
|
||
are removed from IMAP4. There is no equivalent to the bboard com-
|
||
mands, which provided a separate namespace with implicit restrictions
|
||
on what may be done in that namespace.
|
||
|
||
Older server implementations may automatically create the destination
|
||
mailbox on COPY if that mailbox does not already exist. This was how
|
||
a new mailbox was created in older specifications. If the server
|
||
does not support the CREATE command (see above for how to test for
|
||
this), it will probably create a mailbox on COPY.
|
||
|
||
Older server implementations may not preserve flags or internal dates
|
||
on COPY. Some server implementations may not permit the preservation
|
||
of certain flags on COPY or their setting with APPEND as site policy.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Crispin [Page 4]
|
||
|
||
RFC 1732 IMAP4 - Compatibility December 1994
|
||
|
||
|
||
IMAP4 server interoperability with old clients
|
||
|
||
In general, there should be no interoperation problem between a
|
||
server conforming to the IMAP4 specification and a well-written
|
||
client that conforms to an earlier specification. Known problems are
|
||
noted below:
|
||
|
||
Poor wording in the description of the CHECK command in earlier
|
||
specifications implied that a CHECK command is the way to get the
|
||
current number of messages in the mailbox. This is incorrect. A
|
||
CHECK command does not necessarily result in an EXISTS response.
|
||
Clients must remember the most recent EXISTS value sent from the
|
||
server, and should not generate unnecessary CHECK commands.
|
||
|
||
An incompatibility exists with COPY in IMAP4. COPY in IMAP4
|
||
servers does not automatically create the destination mailbox if
|
||
that mailbox does not already exist. This may cause problems with
|
||
old clients that expect automatic mailbox creation in COPY.
|
||
|
||
The PREAUTH unsolicited response is new in IMAP4. It is highly
|
||
unlikely that an old client would ever see this response.
|
||
|
||
The format of dates and times has changed due to the impending end
|
||
of the century. Clients that fail to accept a four-digit year or
|
||
a signed four-digit timezone value will not work properly with
|
||
IMAP4.
|
||
|
||
An incompatibility exists 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, JE-30
|
||
University of Washington
|
||
Seattle, WA 98195
|
||
|
||
Phone: (206) 543-5762
|
||
|
||
EMail: MRC@CAC.Washington.EDU
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Crispin [Page 5]
|
||
|