3 ms·

> They lost a huge opportunity. Encryption at rest of emails and E2EE To implement E2EE for email would involve replacing literally every part of the tech stac

> They lost a huge opportunity. Encryption at rest of emails and E2EE To implement E2EE for email would involve replacing literally every part of the tech stack at literally every provider. You can't lose an opportunity you never had.

drdaeman 3y ago
I don't think so. I mean, I can't imagine what exactly needs to be replaced, and I'm not really getting what that GP quote is talking about, unless it's email metadata (encryption of which is impossible in practice) or full-text search (I always forget about it, as I don't really use it myself) First, at-rest encryption is perfectly doable with most typical software setups (Postfix/Exim/Dovecot/Cyrus/etc), and I think should be not so hard to achieve with proprietary systems as long as they a) capable of dealing with MIME messages (don't reprocess emails for storage) and b) have milter-like capabilities in their local delivery pipeline. You just throw in a milter that encrypts messages to a user-provided key (such as S/MIME or - hey, don't throw anything at me - PGP public key, or whatever MUA may support), and rely on the mail user agent (aka mail client) to be able to decrypt this mail. Second, I'm not sure how E2EE is even in the picture. It - by definition - should be all happening on the endpoints, so I'm not sure how providers (let alone protocols they use) even fit in the picture. And if anything, it's not on IMAP but on SMTP. But even then, SMTP/LMTP are delivering MIME-encapsulated data (that typically happens to be HTML or text pieces), and they don't really care about what sort of data is in there. This significantly hinders anti-spam capabilities, though.
- danielheath 3y ago
  > should be all happening on the endpoints Right - but Fastmail never had the opportunity to do that, which is what I read GP as asking for.

3 ms·

> They lost a huge opportunity. Encryption at rest of emails and E2EE To implement E2EE for email would involve replacing literally every part of the tech stac

by danielheath 3y ago

drdaeman 3y ago
I don't think so. I mean, I can't imagine what exactly needs to be replaced, and I'm not really getting what that GP quote is talking about, unless it's email metadata (encryption of which is impossible in practice) or full-text search (I always forget about it, as I don't really use it myself) First, at-rest encryption is perfectly doable with most typical software setups (Postfix/Exim/Dovecot/Cyrus/etc), and I think should be not so hard to achieve with proprietary systems as long as they a) capable of dealing with MIME messages (don't reprocess emails for storage) and b) have milter-like capabilities in their local delivery pipeline. You just throw in a milter that encrypts messages to a user-provided key (such as S/MIME or - hey, don't throw anything at me - PGP public key, or whatever MUA may support), and rely on the mail user agent (aka mail client) to be able to decrypt this mail. Second, I'm not sure how E2EE is even in the picture. It - by definition - should be all happening on the endpoints, so I'm not sure how providers (let alone protocols they use) even fit in the picture. And if anything, it's not on IMAP but on SMTP. But even then, SMTP/LMTP are delivering MIME-encapsulated data (that typically happens to be HTML or text pieces), and they don't really care about what sort of data is in there. This significantly hinders anti-spam capabilities, though.
- danielheath 3y ago
  > should be all happening on the endpoints Right - but Fastmail never had the opportunity to do that, which is what I read GP as asking for.