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.

That is an immature view on how real products and real standards work. The standard document may say one thing, but what people do in the real world is the real standard.

For context: I spent 11 years at Intel managing pre-silicon and post-silicon processor validation. No processor that does only and exactly what the Programmers Reference Manual says, and takes the phrase "undefined behavior" seriously, will be successful. Google would do well to adjust their philosophy.

If an x86 implementation was imperfectly compatible with Intel CPUs, nobody would buy it. Gmail, on the other hand, is a massive market success. It is those who shout that IMAP must be exactly and only whatever mutt+uw was doing in 1997 who are on the wrong side of history.