←back to thread

How IMAP works under the hood

(blog.lohr.dev)
230 points michidk | 1 comments | 29 Mar 25 09:05 UTC | HN request time: 0.21s | source
Show context
rmccue ◴[31 Mar 25 11:00 UTC] No.43533504[source]▶
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.)

replies(2): >>43535532 #>>43538067 #
mjl- ◴[31 Mar 25 18:24 UTC] No.43538067[source]▶
> 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!).

replies(1): >>43539669 #
1. csb6 ◴[31 Mar 25 20:37 UTC] No.43539669[source]▶
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.