Fun is a very curious way of putting it, considering how batshit crazy IMAP is. The rest of the involved email standards are also a huge dumpster fire.
You know the term "opinionated software"? IMAP is an opinionated protocol, designed for clients and servers that work exactly the same way that Mark Crispin's PINE and UW-IMAPd did. Disagree with Crispin about anything, and the protocol will fight you every step of the way.
Mind you, I think PINE may have been the greatest email program ever written, but Crispin was not the easiest person to get along with.
Why would you need to deal with IMAP at all for a webmail client? If the mail server is the one hosting the webmail frontend, you could read the Maildir or mbox (or whatever you're using to store emails) directly. IMAP's only really relevant for locally-installed clients (i.e. the exact thing webmail's supposed to replace).
If I were to write a webmail client for either myself or as a non-toy-project, I would definitely want to be able to host the webmail backend somewhere else than the MTA/MDA, and especially not give the webmail full access to every user's email.
That leaves you with either using some protocol that already exists (IMAP or now JMAP as another persion mentioned in the thread) or coming up with my own.
There are still a couple options here besides IMAP:
- Use server-local users, and have the webmail prompt for those credentials and use them to browse that user's Maildir via SFTP. "Good enough" for small-scale operations. Probably not the best choice for large-scale operations, but likely "good enough" for small-scale.
- Store the emails in a SQL database (e.g. Postgres), with row-level permissions to SQL users for each address, and have the webmail prompt for credentials for those SQL users and use those to connect to the DB and query messages. Probably the ideal choice for large-scale operations.
Both of these options seem more reasonable to me than trying to do anything with IMAP.
The first option would likely be terribly slow. Scanning emails to check for things that have been moved around and client-side-grepping emails would be extremely slow. For this to even work you'd probably want some local cache, which is not trivial to do. Granted, my benchmark here is people like me who have over 100k emails on their account.
The second is likely the better thing to do (But likely not in postgres for large-scale, if anything due to the SPOF. Unless someone really enjoys maintaining postgres clusters). However, you still need some IMAP/JMAP somewhere for normal mail client access, and in this case you'd likely have to implement your own translation/access layer. I would probably come up with something that wouldn't have users directly access a database, and instead provide some sort of identity-aware access layer. Basically reimplementing IMAP/JMAP, again.
I wrote a webmail client (I've apparently long since lost most of the code) to go along with a personal email server I was running about 12 years ago, so it's entirely possible I was just speaking for myself.
If you are going to write your own webmail, use dovecot for your mail-server and then target the maildir store rather than IMAP. You will be much happier.
