Having worked with IMAP before myself, the spec is very vague a lot. It's a bad spec.

We had our own IMAP server implementation and had all sorts of problems even between different versions of outlook.

Each project had an inbox which you could cc in, resulting in huge inboxes (for the 2000s at least). You could also drag and drop an email you'd received into the project folder to share it with colleagues. And we had mysterious disappearing emails, but only at some clients.

One (of the many) problems I remember is that messages could have an ID, but the spec declared that it could change between sessions, so one version of outlook stored that in a short uint (max 65535) because why would you need more for a temporary id. So have fun if you sent anything more than that. And of course the client had different versions of outlook on different sites so it took ages to even figure out what was happening.

Another was that you had to make several back and forths on every request, messages about the messages, to say the payload and number of messages, but the spec was gleefully vague about the order this should happen in. So back then what worked for one email client resulted in an empty inbox for another.

I don't think we ever got it working properly with Firebird.

Validation of UIDs is thankfully something I don't have to worry about. It looks like a total nightmare.

Outlook is known to have a horrible IMAP implementation.

I've found Outlook's not too bad actually, and at least they support ActiveSync and MAPI for desktop and mobile. I always had the most problems with Gmail over IMAP.

Could you highlight what you consider as vague?

Your app looks really cool! I've been looking for something like this for a while now to deal with my crazy inbox. You've made a lot of right choices like opt-in cookies, credit-based purchases, and audit logs, so keep on keeping on! Thanks and best of luck!

Hey thanks! :) Glad to hear you like it!

In the past I've used a 3rd party component [1] for IMAP, it was like outsourcing all the work of dealing with the quirks of each server.

[1]: https://sockettools.com

I hope it does go somewhere, as IMAP isn't well suited to mobile, and neither is webmail.

Its still far better than POP. Its really nice how you can let the server decode the structure of a message and then selectively download only the parts you actually want to display.

(Yes, I once wrote a mobile IMAP client.)

This is ironic as imap was designed specifically for mobile and remote machines.

The definition of those terms is quite different of course today, so my statement isn’t meant to contradict yours. I doubt Mark ever saw a laptop, at least when working with imap. Imap was a real step forward at the time.

It's literally a virtual filesystem and a terrible one at that.

Why is IMAP not well suited to mobile?

Too many network hops! Imagine if an account has an account with 3 folders and want to synchronize all of them. Then need at least to select each folder examine is there something new and fetch needed data. This is at least 6 network calls. You can do that with just one call in JMAP.

Some server support only basic IMAP and do not offer QResync and Condstore extensions. So to detect deleted move email you need to select entire email UIDs to see is it still there. A lo of unneeded network call just to fully synchronize client state.

I even do not want to start that some providers like Outlook don't offer UTF8 extension, so the cannot implement a good search for different languages.

> Although the protocol spec is tight

Are you talking about the IMAP RFC? It's the worst spec I have ever seen and so many parts are open to interpretation. If you think it's tight it must be because you didn't realized all the ambiguities.

My use case is pretty specific, I'm only dealing with a small subset.

I guess I was just lucky and can remain happily ignorant.