]> Fastmail

rjbs@semiotic.systems

ART Mail Maintenance imap This document presents a set of IMAP extensions, each of which is recommended as a priority for general-purpose IMAP client and server implementations.

Introduction IMAP4 ( et al.) is a complex protocol, and many extensions have been written over its decades of use. Programmers working on IMAP4 clients or servers today have very little guidance on which extensions have much support or have significant value. This document, prepared by a group of established IMAP4 client and server authors, is meant to serve as an overview of which standards should be targeted by living IMAP4 code. There are many trade-offs involved in implementing IMAP4. This document focuses on reducing round trips required to complete common tasks and on eliminating likely confusion for users or user agents.

Conventions and Definitions This document does not define a formal specification, and words "should" and "should not" are used with specific meaning in the document, distinct from that described in . should - This word means that the action described is strongly recommended and will enhance interoperability or usability. should not - This phrase means that the action described is strongly recommended against, and might hurt interoperability or usability.

Core Protocol Version The current IMAP protocol is IMAP4rev2, specified in . New server implementations should target IMAP4rev2. This means some of the extensions listed below are required, and that the server is subject to certain further restrictions. Existing server implementations that target earlier revisions of IMAP4 should pursue the recommended extensions below. That is: we suggest IMAP4rev1 with all of the extensions below as a goal before full IMAP4rev2. IMAP4rev2 and IMAP4rev1 are both in active use, so IMAP4 clients should be capable of interoperating with either protocol. Clients should avoid relying on behaviors removed in IMAP4rev2, and should be capable of operating without features mandated in IMAP4rev2. The extensions below were chosen with the goal of eliminating wasted effort. They are either commonly offered even by IMAP4rev1 servers or provide so much utility that they are worth implementing as optional best-case code paths. For an IMAP4rev1 client, the most essential components of IMAP4rev2 are: support for , without which other extensions can't be enabled support for UTF-8 as also described in the list of new mailbox attributes from the removal of the CHECK command The rest of IMAP4rev2 provides extensions that may be beneficial for a client, but don't necessarily have to be used. Many of those extensions are mentioned in separate sections below. For a complete list of changes between revisions, see Appendix E of the RFC.

The most effective IMAP extensions These are the IMAP extensions we believe have the most impact and are most widely implemented. They are listed in no particular order, and instead we've provided an explanation of their benefit, so that implementors can choose based on their product's priorities.

COMPRESS, RFC 4978 With the extension enabled, the IMAP conversation in both directions is compressed using DEFLATE. In practice, this leads to a 20-40% (or more) reduction in bandwidth used. The deflate algorithm is widely implemented and adds very little computing cost to providing service.

CONDSTORE and QRESYNC, RFC 7162 These extensions, from provide efficient mechanisms for re-synchronization. When an IMAP client can make use of these features, it can efficiently update its local cache by only fetching new or changed data. Without these features, the client needs to rescan old mail for changes. Implementing these extensions reduces bandwidth usage and means an IMAP client is fully up to date much more quickly after coming back online. CONDSTORE and QRESYNC are probably the most important extensions to implement to improve IMAP efficiency. For clients that perform no local caching, these extensions provide no benefit.

ESEARCH, RFC 4731 The extension (not to be confused with the ESEARCH command provided by the MULTISEARCH extension) extends the core search mechanism to allow limiting results, getting a count of results, and getting results in a more compact format. This reduces bandwidth and can allow server-side query optimizations. This extension is required by IMAP4rev2.

ID, RFC 2971 The extension adds the ID command and response, through which the client identifies itself (by name and version) to the server, and the server does the same in return. When a client or server author digs into a bug or other problematic behavior, knowing what piece of software is at the other end of the connection makes it easier to reproduce and diagnose problems. It also means that there's a path to contact the maintainers of the software involved.

IDLE, RFC 2177 The extension allows the client to switch into a passive mode and request that updates to the currently selected mailbox instead be pushed to the client by the server. It replaces continued polling or reconnection to check for new mail, reducing network overhead and providing lower-latency updates to end users. This extension is required by IMAP4rev2. For a more richly-featured replacement to IDLE, see NOTIFY below.

LITERAL+, RFC7888 The extension introduces both LITERAL+ and LITERAL- as capabilities. These capabilities indicate support for non-synchronizing string literals. Without this capability, a client sending a literal to the server must wait for the server to acknowledge that it is now waiting for the content of a literal. Using the non-synchronizing form, the literal's content may be transmitted immediately. This reduces wait time and round trips between client and server. LITERAL- support is a strict subset of LITERAL+ support. LITERAL+ is required by IMAP4rev2.

MOVE, RFC 6851 The command provides a way to atomically move a message from one mailbox to another, combining a message copy and expunge. This eliminates the possibility of a copied-but-not-deleted message. Also, because there's no intermediate state where the message exists twice, the command won't fail due to quota limitations. This extension is required by IMAP4rev2.

OBJECTID, RFC 8474 The extension provides unique identifiers to messages and threads. This has a number of distinct benefits: Mailbox renames can be synchronized extremely efficiently. Without a mailbox id, synchronizing a mailbox rename can be very expensive, especially if it has child mailboxes. Mailbox renames need not break Sieve scripts, which can target mailboxes by id in addition to name. Messages appearing in multiple mailboxes only need to be synchronized once, saving bandwidth and storage space. The unique identifiers can be used to make calls, if JMAP is available for the target server.

SPECIAL-USE, RFC 6154 The extension describes a way to add metadata to a mailbox to indicate that the mailbox is for a well-known purpose. For example, the trash mailbox or sent mailbox can be marked as such. This helps client authors meet user expectations consistently across implementations. On servers without this extension, clients are left to make their own mailboxes, and two clients may pick different names, leaving the user with both "Sent" and "Sent Messages". At minimum, servers and clients should implement support for \Drafts, \Junk, \Sent, and \Trash. In addition to the behavior from the specification: No one mailbox in a user's personal namespace should have more than one special use attribute. Any combination of two special uses on a mailbox is likely to confuse both users and their user agent software. No one special use attribute should be present on two different mailboxes in a user's personal namespace. A client should not be forced to pick between two \Sent mailboxes, for example. Special use mailboxes should be at the root of the user's personal mailbox hierarchy, and servers should reject attempts to move special-use mailboxes elsewhere in the hierarchy. Usually, moving a special use mailbox from the top level is the result of a mistake, and leads to complications when users, no longer seeing a "Sent" mailbox, create a new one - which doesn't work. This extension is required by IMAP4rev2.

UIDPLUS, RFC 4315 The extension adds a new command (UID EXPUNGE) and several response codes. The UID EXPUNGE command allows for expunging of deleted mail included in the sequence set provided as a command argument. Because it uses UIDs instead of sequence numbers, it can be used by clients synchronizing from an offline state. Without UID EXPUNGE, the client must either toggle the \Deleted flag on messages or risk purging more mail than expected. This extension is required by IMAP4rev2.

Further effective IMAP extensions These extensions are also useful and recommended, although they apply to more specific scenarios than the more general-use extensions listed in the previous section

MULTISEARCH, RFC 7377 The extension adds a new command (ESEARCH, not to be confused with the ESEARCH capability) which can search multiple mailboxes at once. This makes searches both faster and more efficient. Without multisearch, searching multiple mailboxes will require the client to pipeline a series of SELECT and SEARCH commands. Combining these into a single command may also permit the server to perform a much more efficient search.

NOTIFY, RFC 5465 The IDLE command, described above, switches the IMAP conversation into a massive mode where the server will push changes to the currently selected mailbox. The extension provides an improved form of IDLE. It can instruct the server to provide updates for multiple mailboxes, and to send STATUS lines for mailboxes with updates. This is especially valuable for servers that may deliver new mail to mailboxes other than the inbox, using mail rules or other routing. While implementing NOTIFY is demanding for servers, clients can get most of the benefit without too much effort. Most clients need only send this command:

...and they will receive prompt notices about new and deleted messages and may not need to write any further code. Clients that only listen to responses when they send commands should use SELECTED-DELAYED instead of SELECTED. Clients that also implement OBJECTID may send (UID EMAILID THREADID) instead of (UID)."

REPLACE, RFC 8508 The command provides a way to atomically replace one message with another, combining an append and single-message expunge. It's primarily used for managing draft messages, but can also be used for editing messages "in place" in other ways. Use of the REPLACE command eliminates the possibility of appending without deleting message. Also, because there's no intermediate state, a REPLACE command won't fail due to quota limitations as could happen with append-then-expunge.

Additional notes for client implementations When possible, clients should use the UID command instead of the message sequence number commands it supersedes. For example, UID FETCH, not FETCH. UIDs persist between IMAP sessions, making offline operation simpler. When the extension is available, it permits sessions using only the UID form of commands to achieve better client and server performance.

Additional notes for server implementations Retrieving the BODYSTRUCTURE data item should be efficient. IMAP4 clients will expect fetching the BODYSTRUCTURE to cost no more than fetching the ENVELOPE. Slow implementations, like parsing the stored message for each request, are likely to result in a poor user experience.

Security Considerations TODO Security

IANA Considerations This document has no IANA actions.

The Internet Message Access Protocol Version 4rev2 (IMAP4rev2) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev2 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev2 also provides the capability for an offline client to resynchronize with the server. IMAP4rev2 includes operations for creating, deleting, and renaming mailboxes; checking for new messages; removing messages permanently; setting and clearing flags; parsing per RFCs 5322, 2045, and 2231; searching; and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev2 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev2 does not specify a means of posting mail; this function is handled by a mail submission protocol such as the one specified in RFC 6409. Most IMAP extensions are used by the client when it wants to and the server supports it. However, a few extensions require the server to know whether a client supports that extension. The ENABLE extension allows an IMAP client to say which extensions it supports. [STANDARDS-TRACK] This specification extends the Internet Message Access Protocol, specifically IMAP4rev1 (RFC 3501), to support UTF-8 encoded international characters in user names, mail addresses, and message headers. This specification replaces RFC 6855. This specification does not extend IMAP4rev2 (RFC 9051), since that protocol includes everything in this extension. Some IMAP message stores include special-use mailboxes, such as those used to hold draft messages or sent messages. Many mail clients allow users to specify where draft or sent messages should be put, but configuring them requires that the user know which mailboxes the server has set aside for these purposes. This extension adds new optional mailbox attributes that a server may include in IMAP LIST command responses to identify special-use mailboxes to the client, easing configuration. [STANDARDS-TRACK] The UIDONLY extension to the Internet Message Access Protocol (RFCs 3501 and 9051) allows clients to enable a mode in which information about mailbox changes is returned using only Unique Identifiers (UIDs). Message numbers are not returned in responses and cannot be used in requests once this extension is enabled. This helps both clients and servers to reduce resource usage required to maintain a map between message numbers and UIDs. This document defines an experimental IMAP extension. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The COMPRESS extension allows an IMAP connection to be effectively and efficiently compressed. [STANDARDS-TRACK] Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalf of the same user and multiple users accessing shared mailboxes. These clients need a mechanism to efficiently synchronize state changes for messages within the mailbox. Initially defined in RFC 4551, the Conditional Store facility provides a protected update mechanism for message state information and a mechanism for requesting only changes to the message state. This memo updates that mechanism and obsoletes RFC 4551, based on operational experience. This document additionally updates another IMAP extension, Quick Resynchronization, which builds on the Conditional STORE extension to provide an IMAP client the ability to fully resynchronize a mailbox as part of the SELECT/EXAMINE command, without the need for additional server-side state or client round trips. Hence, this memo obsoletes RFC 5162. Finally, this document also updates the line-length recommendation in Section 3.2.1.5 of RFC 2683. This document extends IMAP (RFC 3501) SEARCH and UID SEARCH commands with several result options, which can control what kind of information is returned. The following result options are defined: minimal value, maximal value, all found messages, and number of found messages. [STANDARDS-TRACK] This document describes an ID extension which will enable Internet Message Access Protocol - Version 4rev1 (IMAP4rev1) to advertise what program a client or server uses to provide service. The ID extension allows the server and client to exchange identification information on their implementation in order to make bug reports and usage statistics more complete. [STANDARDS-TRACK] This document specifies the syntax of an IDLE command, which will allow a client to tell the server that it's ready to accept such real-time updates. [STANDARDS-TRACK] The Internet Message Access Protocol (RFC 3501) contains the "literal" syntactic construct for communicating strings. When sending a literal from client to server, IMAP requires the client to wait for the server to send a command continuation request between sending the octet count and the string data. This document specifies an alternate form of literal that does not require this network round trip. This document specifies 2 IMAP extensions: LITERAL+ and LITERAL-. LITERAL+ allows the alternate form of literals in all IMAP commands. LITERAL- is the same as LITERAL+, but it disallows the alternate form of literals unless they are 4096 bytes or less. This document obsoletes RFC 2088. This document defines an IMAP extension consisting of two new commands, MOVE and UID MOVE, that are used to move messages from one mailbox to another. [STANDARDS-TRACK] This document updates RFC 3501 (IMAP4rev1) with persistent identifiers on mailboxes and messages to allow clients to more efficiently reuse cached data when resources have changed location on the server. This document specifies a protocol for clients to efficiently query, fetch, and modify JSON-based data objects, with support for push notification of changes and fast resynchronisation and for out-of- band binary data upload/download. The UIDPLUS extension of the Internet Message Access Protocol (IMAP) provides a set of features intended to reduce the amount of time and resources used by some client operations. The features in UIDPLUS are primarily intended for disconnected-use clients. [STANDARDS-TRACK] The IMAP4 specification allows the searching of only the selected mailbox. A user often wants to search multiple mailboxes, and a client that wishes to support this must issue a series of SELECT and SEARCH commands, waiting for each to complete before moving on to the next. This extension allows a client to search multiple mailboxes with one command, limiting the delays caused by many round trips and not requiring disruption of the currently selected mailbox. This extension also uses MAILBOX, UIDVALIDITY, and TAG fields in ESEARCH responses, allowing a client to pipeline the searches if it chooses. This document updates RFC 4466 and obsoletes RFC 6237. This document defines an IMAP extension that allows a client to request specific kinds of unsolicited notifications for specified mailboxes, such as messages being added to or deleted from such mailboxes. [STANDARDS-TRACK] This document defines an IMAP extension that can be used to replace an existing message in a message store with a new message. Message replacement is a common operation for clients that automatically save drafts or notes as a user composes them.

Acknowledgments TODO acknowledge.