Hacker News new | ask | show | jobs
by danrik 4683 days ago
The entire email transation between a sender and a recipient usually looks like this:

Sending Client [--A---> Sender SMTP Server [--B---> Recipient SMTP Server [--C--> Recipient IMAP/POP server <---D----] Recipient Client

Connections A and D are easily possible to encrypt, provided your provider provides SSL/TLS on their SMTP and IMAP/POP servers. Most usually do. Connection C is usually local to a single machine, or for large email providers will go over an intranet of some kind.

What is at issue is connection B, which goes over the public internet. That is almost always in clear text, as most of this infrastructure was designed 30 years ago and hasn't evolved much since then. If you are sending email within a single provider (e.g. sender@gmail.com to recipient@gmail.com), such delivery can be trivially encrypted.
1 comments
zokier 4683 days ago
> That is almost always in clear text, as most of this infrastructure was designed 30 years ago and hasn't evolved much since then

Email has definitely evolved since it's inception. STARTTLS (RFC3207) is the relevant standard here.

link
bigiain 4683 days ago
I don't suppose anyone has any stats (or even educated guesses) about how many mail servers you'd not be able to connect/send to if you enforced TLS connections from your outgoing SMTP server (as in, refused to send data to servers that didn't respond appropriately to a STARTTLS command)?
link
tedunangst 4683 days ago
Having run a mail server that used to have a self-signed cert and that now doesn't offer starttls at all, I can tell you I experienced zero failed deliveries (well, nobody has ever complained, and I still get all the mail I expect to get). Maybe incoming mail will use starttls if available, but if it's not (mitm, fake mx record, etc.) the remote server isn't going to stop. It just delivers in plaintext.

I mean, it's trival to see this is true. Open up your mail server's configuration file. Where's the line that specifies trusted root CAs for relaying to remote servers? Oh, there isn't one? So how does it verify the chain of trust?

(I realize I didn't quite address your question. Solid answer: at least one. But I'm fairly confident the number of server configured as you suggest is extremely close to zero.)

link