We need better client support for JMAP. Apple Mail, Thunderbird, Outlook (as if), and so on. I'm surprised some of the smaller ones like Canary or Spark don't implement it as a product differentiator.
Outlook ? Lol. In 2 years-time Outlook will only connect to MS365 and that's it. You're betting MS will switch to JMAP ? Lol again.
P.S. ("New" Outlook already only connects to MS365 servers and then stores your credentials and data on Azure, while they proxy to your actual IMAP/SMTP server )
One big differentiator is JMAP allows one network connection to track new emails that may get delivered across different folders. With IMAP you need a connection open for each folder.
I'd make a reasonable guess that it enables much better Javascript clients, either via Electron or the Web Browser.
You don't need major providers to support it, they support SMTP and that's how messages are relayed. JMAP is just so you: the client, can fetch your mail from wherever you host your mail.
IMAP is a shit protocol in general. Notably, email UIDs are not guaranteed to be static across sessions (aka, next time you connect they may be different), which is just straight up dumb. You IMAP client has to do a lot of workarounds just for this, which leads to gnarly bugs and inefficiences.
That's not strictly true. IMAP has two things, UIDs which are mostly static (there's a UIDVALIDITY cache invalidation key to let a client know that UID information has been lost and recalculated); and message numbers.
UIDs don't change, but of course they can be deleted so it's a gappy list, meaning you can request even quite a large looking range of UIDs and get nothing back.
Message numbers change in every session, and also change every time you get an EXPUNGE. They're basically an ordered list without gaps, so you do a memmove at the offset of the EXPUNGE each time you get an expunge.
There are efforts like UIDONLY (RFC9586) to avoid having to keep that mapping at all, and there's OBJECTID (RFC8474) to let you cache a lot more even when UIDs are changed or when messages are moved between folders.
I don’t even remotely disagree with this. But that wasn’t the point: the point was that JMAP is only a competitive advantage if (major) email providers actually adopt it. Bad technologies regularly win because of inertia.
I agree. For what I read quickly, it seems to be mostly the same stuff but "modernized". It's like the flavor of the day for email technology.
Fundamentally it hasn't really changed much which is why I am a bit skeptical. Sure, you have a "better" and more efficient protocol that is easier to work with/implement but then what?
It's still just email with most of the inherent flaws built in.
I’ve got a friend who’s been pitching me on building a new email client for years. “I’ll do it if we exclusively use JMAP.” “okay does that include Gmail and Apple/iCloud accounts?” “Nope.”
I could sort of see dual-supporting Gmail's proprietary API and JMAP, but unless the #2-5 competitors support it… what’s the point? (sorry to put on the pessimism hat)
There isn’t really a great motivating feature or use-case driving client or server adoption.
To be honest, I’m not sure why end-users would want JMAP for e-mail access.
It would be interesting if they do successfully roll out all of these additional RFC proposals providing a cohesive “groupware” protocol covering calendering, contacts, file shares, etc, we see notable server implementations, and interest is enough to drive client support.
People say things like that, and I wonder if I’ve just been living in a gilded tower of using Apple Mail with decent IMAP server implementations.
I’m also pretty familiar with the wire protocol and its implementation — it’s never struck me as particularly horrible.
A new protocol isn’t likely to solve the problem of poorly implemented clients and servers — e.g. Google doesn’t really care about good IMAP support, so they’re unlikely to care much about JMAP, either. They just want you to use their webapp.
Sounds like it :) I’ve been very happy with Mail.app since MacOS 10.0. My use has always been with my employer’s IMAP servers, and my own cryus (and eventually) dovecot self-hosted IMAP servers.
Mail.app is what NeXT used internally, and Apple uses to this day AFAIK. Steve Jobs historically paid a lot of attention to it and wasn’t shy about weighing in on any changes.
Most of the complaints that I’ve heard about it seemed to stem from poor IMAP servers (e.g. Gmail), but it sounds like your knowledge in the space would be a lot more detailed and recent than mine, so I would be very interested in your thoughts.
Gmail does indeed _intentionally_ provide poor IMAP service. But the long and short of it is that Apple Mail simply isn't a first-class product. It's an afterthought.
