RFC 1732

IMAP4 COMPATIBILITY WITH IMAP2 AND IMAP2BIS 💖

Okay bestie, let's get into RFC 1732! 🎀 Here's the title block tea first:

• RFC number: 1732, from the Network Working Group ✨
• Author: M. Crispin (Mark R. Crispin) at the University of Washington 🧚
• Category: Informational, so it's giving "helpful info," not "official standard" 📚
• Date: December 1994 🍓
• Obsoletes / Updates: the title block doesn't list anything it obsoletes or updates 🤷‍♀️

---

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

Okay so this doc is basically a cheat sheet 📝 of hints and recommendations so an IMAP4 implementation can vibe with older implementations that follow earlier specs. None of this is required by the IMAP4 spec, so implementors must decide for themselves whether they want their implementation to fail when it runs into old software 💀

IMAP4 was designed to be upwards compatible with earlier specifications. For the most part, IMAP4 facilities that weren't in earlier specs 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 info may not be complete. It reflects current knowledge of server and client implementations, plus "folklore" picked up while the protocol was evolving. Lowkey iconic 🙈

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 gets a BAD response, the client can assume the server doesn't support it 🔍

A quick way to check whether a server supports the IMAP4 specification is to try the CAPABILITY command. An OK response that includes the IMAP4 capability value means the server supports IMAP4. A BAD response, or one without the IMAP4 capability value, means it's an older server 👑

The following facilities are only in IMAP4, plus 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.
• UID fetch data item and the UID commands
  • No equivalent capability 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 come back.

The following IMAP4 facilities were introduced in the experimental IMAP2bis revisions to RFC 1176, and may be present in a server that doesn't 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 support implicit creation of a mailbox by a COPY command with a non-existent 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 arguments.
• 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 formats documented in the IMAP4 specification, including those labeled as obsolete. This includes the COPY and STORE unsolicited responses and the old format of dates and times. In particular, client implementations 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 special 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's no equivalent to the bboard commands, which provided a separate namespace with implicit restrictions on what may be done in that namespace. Bye bboards 👋

Older server implementations may automatically create the destination mailbox on COPY if that mailbox doesn't already exist. This was how a new mailbox got created in older specifications. If the server doesn't 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. 🔒

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:

• CHECK command: 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.
• COPY behavior: 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.
• PREAUTH: The PREAUTH unsolicited response is new in IMAP4. It is highly unlikely that an old client would ever see this response.
• Dates and times: 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. 📆
• Backslashes in quoted strings: 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.

⚠️ Yikes, bestie. This memo has zero security discussion, so don't assume anything is safe just because it's in here. Handle everything with extreme caution and do your own security homework 🔐😭

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

That's the whole RFC! Iconic compatibility energy 🌈👑💖