How IMAP works under the hood

I started writing a guide to IMAP back when I was working on an email client: https://github.com/rmccue/griffin/tree/master/docs/imap

Pulling large amounts of data for things like threading can be difficult on certain servers; my preferred approach ended up being to pull every ID and thread ID to maintain an in-memory tree. (This was, iirc, partially because Gmail’s implementation was slightly crippled with relation to threading.)

(I never finished the guide because I stopped on the project, alas - if IMAP were easier to work with, I might have finished it! And sadly, no JMAP support on Gmail, and the gateway was broken.)

> Gmail’s implementation was slightly crippled

Gmail is not "crippled". A tiny but vocal community of old nerds have a petrified mental model of email that they associate with unix IMAP software from the 1990's, but those concepts do not appear in the IMAP standards anywhere.

My memory is hazy on it, _but_ from memory, there were some issues around IDs and persistence which don't occur on other servers, as well as the auth being a bit funky. (Gmail also uses its own extension to the protocol for IDs instead of using eg OBJECTID.)

To be clear, I have no opinion on IMAP or what things _should_ do; I certainly was not using IMAP software in the 1990s :) However, trying to implement a client that works across providers does mean trying to operate per the standards, which was a struggle and why I started documenting it :)