Hacker News new | past | comments | ask | show | jobs | submit login

> Clients that want to or need to (for example those doing PGP in the client) can still fetch the RFC5322 if needed. The message is represented by a blobId, and the raw bytes can be fetched using the same binary download mechanism as mentioned above.

This bit of JMAP has irked me - encryption is a second-class citizen, in a world rapidly evolving to need it every step of the way.

PGP/MIME / SMIME / Autocrypt and email is a chasm of insanity. You're constantly making choices about security vs usability and the user needs to be aware of them and yet the UX quickly becomes a maelstrom of icons and text and options and ...

Mailing lists are a big problem you have to solve and none of the solutions are very good.

That sounds like the perfect opportunity for a new email protocol like JMAP to solve.

Guess you're miss what JMAP protocol is trying to solve. It is not about content of the emails, but how emails are synchronized.

I haven't missed that.

I just believe, in today's atmosphere, synchronisation where encryption is a second-class citizen is a missed opportunity.

JMAP is for talking to the server. You don't want the server to have access to the plain text, only encrypted blobs, so that's the only thing that JMAP should give you. If JMAP dealt with providing the plain text, that means the server would be able to decrypt and that defeats the whole point of End-to-End Encryption.

Fortunately, Fastmail has a blog post that goes more in depth on the subject: https://fastmail.blog/2016/12/10/why-we-dont-offer-pgp/

What you want is something on top of emails, like autocrypt (https://autocrypt.org/)

When the email has been generated by some far off server, you want JMAP to apply a new layer of encryption on top of it while inside an HTTPS pipe?

That doesn't begin to solve the real issue of how to reliably encrypt from sender to sender across two servers it just makes the process even more needlessly complex.

No. But encrypted blobs are somewhat expected to fall within MIMEFiles.

> Clients that want to or need to (for example those doing PGP in the client) can still fetch the RFC5322 if needed.

Not a case of JMAP saying to the client, "Hey, here's this blob. It might be encrypted." But a case of asking the client to use a message standard they've replaced where possible.

That's what I mean by second-class citizen.

It is just a transport protocol. If email is SMIME/PGP encrypted the server will return for the email that has only one attachment with mime type "application/pkcs7-mime smime-type=enveloped-data". How this blob is processed is managed by the client if support SMIME or PGP. Do not forget email is a federated set of protocols, so the encryption cannot rely on servers, except if they are a walled garden as Proton for example.

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