Hacker News new | past | comments | ask | show | jobs | submit login
[dupe] JMAP: Modern Mail Standard (jmap.io)
99 points by jbuild on Nov 21, 2019 | hide | past | favorite | 17 comments

Brilliant stuff, but kind of sad that this hasn't caught on already. I realize that standardization has only firmed up recently, but other standards like HTTP and TLS see preview releases supported in major products well before they are finalized.

Who uses JMAP besides FastMail?

Isn't email mostly consolidated to a handful of providers with published APIs? (Office365, Google, Yahoo) I'd be curious to see the market share of just those 3 combined.

And they don't have any incentive to move to this.

> Isn't email mostly consolidated to a handful of providers with published APIs?

Perhaps for individuals and small businesses, but certainly not for large organizations, many of whom are running their own Exchange (or whatever else) servers.

Imagine if some company offered a $5/month service that connects to o365/gmail/yahoo via imap, and then presents your email via jmap. After a few years of that company making money, I could see at least one of the big 3 offering a $1/month option to cut out the middleman. And if more of them start offering the same, then it's only a matter of time before one of them offers up jmap for free.

Unlikely, but seems plausible to me.

Don't need to undercut the middleman's pricing to be worth cutting a point of failure. Could even charge more and still attract users that never would have purchased it from the middleman.

That sounds a lot like Fastmail to me!

Looks like there are some open source mail server projects that support it: https://jmap.io/software.html

IMO, as a user the biggest advantage is mail being sent via the same protocol as it is received. Someone made an IMAP extension to do that but unfortunately it was never widely implemented.

Some aspects of JMAP haven't made it through the standards process yet, like calendars, quotas, and server-side S/MIME signature verification. Hopefully it will get wider implementation from the big email companies once those are complete.

> JMAP is therefore not introducing any new measures to address end-to-end encryption.

It seems like a wasted opportunity to not make E2EE a primary focus of a new email standard. Hopefully there will be standard extensions down the road to add this if JMAP takes off.

I've been reading about this, and there seems to be a lot of debate still on implementing E2EE via the email providers. From what I have gathered most email providers use TLS and encrypt data on disk at rest, but they feel like its pointless to implement E2EE, because by default as 99% of incoming emails are all unencrypted, and 99% of emails need to leave your email unencrypted(otherwise the receiving email party would be unable to read the encrypted message)

On the page they also bring up a great point: a bunch of optimizations allowed by JMAP (including storing attachments as blobs and separating their payloads from other content) wouldn't be possible if the individual messages were E2E encrypted.

How would spam detection work?

Maybe have a free unencrypted service, then use those users to train the spam detection. Then the spam detection runs client side for paid users.

How do various mail clients talk to their respective backends? I.e. what does iOS Mail use to talk to iCloud? The GMail iOS app speaks a bespoke binary protocol to Google's servers, not IMAP.

iCloud mail in iOS uses plain IMAP. The synchronization stack for iCloud is surprisingly based on open standards: IMAP, CalDAV and CardDAV.

Its JSON via REST - so totally different than IMAP. Which may be good.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact