> I started writing a guide to IMAP back when I was working on an email client
I would be very interested in hearing from developers about how they write email clients that need to work with all the servers out there, with the varying levels of IMAP4 (original, rev1, rev2, combinations of at least a dozen extensions) and various levels of buggy behaviour.
I'm assuming a client developer would implement various "profiles". With an "advanced" profile for servers that implement things like CONDSTORE/QRESYNC, and a "very basic" profile that only do the absolute minimum. And probably a profile or two in between. When you encounter unexpected behaviour (eg bad syntax in protocol), you would downgrade the profile for that server for a while (it may get fixed)? If it works like this, I'm curious to the profiles developer choose. If it's not like this, I wonder how client developers work around compatibility issues (can't just keep reconnecting and trying the same if it results in an error!).
As someone currently working on an IMAP client, my strategy has been to start by implementing the base IMAPrev2 specification and checking that it still works with a rev1 server. RFC 9051 has guidance on how to handle servers that use older IMAP protocol versions and is largely backwards compatible.
The goal is to have the client work without any extensions. E.g., if the server doesn’t have the UNSELECT capability it falls back to selecting a nonexistent mailbox (which has the same effect). Obviously there are some very useful extensions that the client needs to support, but those can be viewed as optimizations to reduce network traffic or add extra features if the server supports them.