3 ms·
As many others have pointed out - this doesn't keep the email encrypted from the providers at either end. We're already basically there for what this is sugges
by brongondwana 10y ago
As many others have pointed out - this doesn't keep the email encrypted from the providers at either end.
We're already basically there for what this is suggesting - opportunistic TLS between providers is so high that the only sites that aren't doing it are the ones who aren't going to be deploying any new solution either.
And it still requires secure DNS to avoid being MITM degraded. Once you assume secure DNS is reliably deployed, lots of things become easier - but you still don't need encrypt partial payloads, because there's no "middleman" unless you're using a forwarding service.
And if you're using a forwarding service, who's publishing the DNS keys? This solution didn't address that at all, the forwarding service would have to decrypt the email with the key for the alias name, then re-encrypt it to the final destination. Either that or proxy the key request, which is trivially MITMable.
Upshot - this adds complexity and theater but doesn't protect against any credible attack vector.
As for the "coffee shop reads your email". Please. Basically every server who cares about security (the audience for ideas like this) already disables non-encrypted SMTP/IMAP/POP. At FastMail we only open the ports for SSL, because STARTTLS is nice, but it's MITM removable, and even if we reject login with the plaintext password, it's already been over the wire.
https://www.fastmail.com/help/technical/ssltlsstarttls.html https://www.fastmail.com/help/technical/ssltlsstarttls.html
I'm too lazy to find one of those checklist things to paste about why this won't work, but I'm not jumping to implement it.
- jorangreef 10y ago"At FastMail we only open the ports for SSL" Does that mean that you do not support user mail submission on port 587 at all?
- EmilStenstrom 10y agoPlease see the other comments to find lots of real world examples of people sending unencrypted e-mail via their ISP without knowing about it. These are the audience for these kinds of ideas, not people that already have PGP installed. I don't see where you got that idea from?
- EmilStenstrom 10y ago> there's no "middleman" unless you are using an e-mail forwarding service Each time an e-mail passes through an e-mail service that service is required to add a "Received" header to the e-mail. So you can easily check out of your real e-mails to see if you are using any middleman or not. The first e-mail I opened looks like this: Received: from exdb06.ug.kth.se (192.168.32.116) by exdb02.ug.kth.se Received: from mx5.kth.se (130.237.32.10) by exdb06.ug.kth.se (192.168.32.116) Received: from mx5.kth.se (localhost [127.0.0.1]) Received: from mx5.kth.se ([127.0.0.1]) Received: from buffalo.birch.relay.mailchannels.net (buffalo.birch.relay.mailchannels.net [23.83.209.24]) Received: from relay.mailchannels.net (localhost [127.0.0.1]) Received: from uscentral412.accountservergroup.com (ip-10-27-139-41.us-west-2.compute.internal [10.27.139.41]) Received: from uscentral412.accountservergroup.com (uscentral412.accountservergroup.com [10.102.194.57]) Received: from friendly by uscentral412.accountservergroup.com with local (Exim 4.87)