Sadly, Google and Microsoft are in the business of getting their users to use their own gmail and outlook clients. They don't want to be invisible IMAP/JMAP back-ends, they want to own your e-mail experience.
MSGraph is slower and not as convenient for email compared to JMAP. In addition to requiring more API calls for the same result, MSGraph starts throttling with HTTP 429 responses after several calls, making the initial synchronization much slower than JMAP or even IMAP.
Hopefully, next year there will be JMAP support for Contacts. As RFC drafts, there are already JMAP specifications for Files and Calendar...
No doubt JMAP is superior for the problem it solves. I wonder if it will matter in the end though. I have the impression MS is positioning it self to be the only viable AI platform where mail and calendars are just a tiny part of that. So while not really competing in the same domain it may be that both IMAP and JMAP may feel as relevant to the world as IRC or XMPP in the not too distant future.
Sure, and we're the vocal (?) minority here. The SOHO/corporate/family world will uncritically use whatever shit MS regurgitates for them for all the usual reasons.
It does, but IMAP is clearly not a priority, and they certainly aren't interested in JMAP. They support IMAP (with caveats) because you can't really offer e-mail without IMAP, but they want you to use their GMail app.
Normally, email providers let you organize into folders. And IMAP (if I understand correctly) DOES NOT allow clients to see those folders and replicate the folder structure.
But Gmail doesn't have "folders". They have "labels". I wont go into all the details about how Gmail labels work that frustrate and annoy me, but the point is that IMAP clients cannot see labels, they can't replicate it on the client end, etc.
This caused a legitimate problem at work when the finance dept. wants to use this service that reads emails to automatically scan invoices into their system and whatnot. They wanted to be able to only have a subfolder automatically imported into the program, because too many of the emails were not relevant to get imported, creating more work to clear them out.
We were not able to achieve a solution with a simple folder for the users to move emails into to get them imported. Instead, we had to set up a second email account specifically for this importing service, and whenever finance wants something imported, they forward the email to that second account.
The problem is that in IMAP the concept of labels doesn't exist. Thus they are implemented using folders, which is a concept in IMAP. But that issue is, a message is then in multiple folders (to reflect that it has multiple labels), but in the way this happens in IMAP, they are different messages, even if the content is the same. And thus I can imagine, automated programs, not aware of this, may for example see 2 invoices (because the email has 2 labels) rather than 1.
IMAP has a concept of flags/keywords (https://datatracker.ietf.org/doc/html/rfc9051 2.3.2) and there's a whole bunch of servers and clients that support using it in a similar way as labels - Thunderbird, Zimbra, dovecot, etc.
It's not a feature originally built for labelling like Gmail, so it has a few complexities ("Servers MAY permit the client to define new keywords") and enough clients (especially mobile) that don't support it - but they could just like Thunderbird or some webmail clients.
I've used it basically exactly like Gmail labels for years on TB on desktop.
> Normally, email providers let you organize into folders. And IMAP (if I understand correctly) DOES NOT allow clients to see those folders and replicate the folder structure.