RFC 5161

The IMAP ENABLE Extension

📅 published March 2008, from ietf

RFC 5161: The IMAP ENABLE Extension 💖

Okay bestie, let's get into it 🎀 This is RFC 5161, "The IMAP ENABLE Extension," from the Network Working Group. It's a Standards Track doc dated March 2008. The authors are A. Gulbrandsen, Ed. of Oryx Mail Systems GmbH and A. Melnikov, Ed. of Isode Limited. The title block doesn't list anything it obsoletes or updates, so it's a standalone spec 🦋

Status of This Memo ✨

This is an Internet standards track protocol for the Internet community, and it's open for discussion and suggestions for improvements. For the standardization state and status of this protocol, check the current edition of "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈

Abstract 🌸

Most IMAP extensions are used by the client whenever it wants to, as long as the server supports them. A few extensions, though, need the server to know whether a client supports them. The ENABLE extension lets an IMAP client say which extensions it supports 🫶

1. Overview 🦋

Okay so several IMAP extensions let the server send unsolicited responses specific to those extensions in certain situations. The catch is that servers can't send those responses until they know the clients support the extension, so they don't choke on the extension response data 😭

Up until now, extensions have usually said the server can't send those unsolicited responses until the client has used a command carrying the extension data. At that point the server knows the client is aware of the extension. CONDSTORE ([RFC4551]), ANNOTATE ([ANNOTATE]), and some extensions still under consideration all use different commands to turn server extensions on. For example, CONDSTORE uses a SELECT or FETCH parameter, and ANNOTATE uses a side effect of FETCH 🙈

The ENABLE extension gives the client a clear, explicit way to say it supports particular extensions. This is done with a brand new ENABLE command 💅

An IMAP server that supports ENABLE advertises it by including the word ENABLE in its capability list ✨

Most IMAP extensions don't require the client to enable them in any way, so ENABLE is only for the ones that do 👑

2. Conventions Used in This Document 📝

Bestie, these are the key words that carry the requirement weight in this doc: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL". They're interpreted as described in [RFC2119] 💖

Formal syntax is defined by [RFC5234] and [RFC3501] 🧚

Example lines prefixed with "C:" are sent by the client, and lines prefixed with "S:" are sent by the server. The five characters [...] mean something has been elided ✨

3. Protocol Changes 🔥

3.1. The ENABLE Command 💅

This is the main event, so pay attention 👀

Arguments: capability names

Result:    OK: Relevant capabilities enabled
           BAD: No arguments, or syntax error in an argument

The ENABLE command takes a list of capability names and asks the server to enable the named extensions. Once something is enabled with ENABLE, it stays active until the IMAP connection closes. For each argument, the server does the following:

  • If the argument is not an extension known to the server, the server MUST ignore the argument.
  • If the argument is an extension known to the server, and it is not specifically permitted to be enabled using ENABLE, the server MUST ignore the argument. (Note that knowing about an extension doesn't necessarily mean supporting it 🙃)
  • If the argument is an extension that the server supports and that needs to be enabled, the server MUST enable the extension for the duration of the connection. Right now this only applies to CONDSTORE ([RFC4551]). Also, once an extension is enabled, there's no way to disable it 😤

If the ENABLE command succeeds, the server MUST send an untagged ENABLED response (see Section 3.2) 🎀

Clients SHOULD only include extensions that need to be enabled by the server. At the time of publication, CONDSTORE is the only one (so ENABLE CONDSTORE is an additional "CONDSTORE enabling command" as defined in [RFC4551]). Future RFCs may add to this list 🌸

The ENABLE command is only valid in the authenticated state (see [RFC3501]), before any mailbox is selected. Clients MUST NOT issue ENABLE once they SELECT/EXAMINE a mailbox. Server implementations don't have to check whether a mailbox was selected or previously selected during the connection, though 🙈

The ENABLE command can be issued multiple times in one session, and it's additive. "ENABLE a b" followed by "ENABLE c" is the same as a single "ENABLE a b c" 🦋 Each ENABLED response that goes with an ENABLE command SHOULD only contain the extensions enabled by that particular ENABLE command 💜

There are no limits on pipelining ENABLE. For example, you can send ENABLE and then immediately SELECT, or a LOGIN immediately followed by ENABLE 🚀

The server MUST NOT change the CAPABILITY list as a result of executing ENABLE. In other words, a CAPABILITY command issued right after an ENABLE command MUST list the same capabilities as one issued before it. Here's how that looks:

C: t1 CAPABILITY
S: * CAPABILITY IMAP4rev1 ID LITERAL+ ENABLE X-GOOD-IDEA
S: t1 OK foo
C: t2 ENABLE CONDSTORE X-GOOD-IDEA
S: * ENABLED X-GOOD-IDEA
S: t2 OK foo
C: t3 CAPABILITY
S: * CAPABILITY IMAP4rev1 ID LITERAL+ ENABLE X-GOOD-IDEA
S: t3 OK foo again

In the next example, the client enables CONDSTORE 🍓

C: a1 ENABLE CONDSTORE
S: * ENABLED CONDSTORE
S: a1 OK Conditional Store enabled

3.2. The ENABLED Response 🧁

Contents:   capability listing

The ENABLED response shows up as a result of an ENABLE command. Its capability listing is a space-separated list of capability names that the server supports and that were successfully enabled. The ENABLED response can have no capabilities at all, which just means none of the extensions the client listed were successfully enabled 💅

3.3. Note to Designers of Extensions That May Use the ENABLE Command ⚠️

Designers of IMAP extensions are discouraged from creating extensions that require ENABLE unless there's no good alternative design. Extensions that cause potentially incompatible behavior changes to deployed server responses (and so benefit from ENABLE) have a higher complexity cost than extensions that don't 💀

4. Formal Syntax 📜

The following syntax spec uses Augmented Backus-Naur Form (ABNF) notation as specified in [RFC5234], including the core rules in Appendix B.1. [RFC3501] defines the non-terminals "capability" and "command-any" 🤓

Except as noted otherwise, all alphabetic characters are case-insensitive. Using upper or lower case characters to define token strings is only for editorial clarity. Implementations MUST accept these strings in a case-insensitive fashion 🔥

capability    =/ "ENABLE"

command-any   =/ "ENABLE" 1*(SP capability)

response-data =/ "*" SP enable-data CRLF

enable-data   = "ENABLED" *(SP capability)

5. Security Considerations 💀

It is believed that this extension doesn't add any security considerations that aren't already present in the base IMAP protocol [RFC3501]. Please keep that in mind when you implement it 🙏

6. IANA Considerations 🧚

IANA has added ENABLE to the IMAP4 Capabilities Registry ✨

7. Acknowledgments 🫶

The editors want to thank Randy Gellens, Chris Newman, Peter Coates, Dave Cridland, Mark Crispin, Ned Freed, Dan Karp, Cyrus Daboo, Ken Murchison, and Eric Burger for their comments and corrections. That said, it doesn't necessarily mean they endorse this extension, agree with every detail, or are responsible for any errors the editors introduced 💖

8. Normative References 📚

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
  • [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
  • [RFC4551] Melnikov, A. and S. Hole, "IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization", RFC 4551, June 2006.

9. Informative References 🔍

  • [ANNOTATE] Daboo, C. and R. Gellens, "IMAP ANNOTATE Extension", Work in Progress, August 2006.

Editors' Addresses 📮

Arnt Gulbrandsen
Oryx Mail Systems GmbH
Schweppermannstr. 8
D-81671 Muenchen
Germany

Fax: +49 89 4502 9758
EMail: arnt@oryx.com


Alexey Melnikov
Isode Ltd
5 Castle Business Village
36 Station Road
Hampton, Middlesex  TW12 2BX
UK

EMail: Alexey.Melnikov@isode.com

Copyright (C) The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🔐

The IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or on the extent to which any license under such rights might or might not be available. It also doesn't represent that it has made any independent effort to identify any such rights. Information on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the results of an attempt to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF online IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please send that information to the IETF at ietf-ipr@ietf.org 💜

📦 where this page comes from