IMAP versions don’t tell the whole story

As I worked through IMAP capability examples, I learned that IMAP4rev1 means version 4, revision 1. That name identifies a protocol baseline, but it does not describe every feature a server supports. Optional extensions can add behavior without changing the IMAP4rev1 name.

These two simplified server responses made the distinction clear:

* CAPABILITY IMAP4rev1 IDLE
* CAPABILITY IMAP4rev1 IDLE OBJECTID

Both servers support rev1 and IDLE; only the second advertises OBJECTID. RFC 8474 extends rev1 with persistent identifiers. Clients must check capabilities rather than infer extension support from the protocol revision. IMAP4rev2 is a later baseline, published in 2021.

The OBJECTID extension defines:

• MAILBOXID: identifies a mailbox across renames.
• EMAILID: identifies a message independently of its mailbox-specific UID.
• THREADID: groups related messages; servers without threading support return NIL.

MAILBOXID and EMAILID are required by the extension. THREADID is optional: a server can advertise OBJECTID without calculating thread relationships, but it must return NIL when THREADID is requested in that case. These identifiers help clients reuse cached data when resources change location.

IMAP4rev2 is specified in RFC 9051. Adding an optional extension to a rev1 server does not automatically turn it into a rev2 server.

When writing a client or comparing servers, I need to check the advertised capabilities for the extension I want to use. For OBJECTID, that means looking for OBJECTID itself. The revision tells me the starting point; the capability list tells me which optional features are available.