> Only a handful of mail providers (like Google) have the option to encrypt traffic server to server.

SSL/TLS is available for everyone.

> Most mail servers transmit messages in the clear to each other and only encrypt the server to client side.

I hear this again and again, but I can't really find any data that confirms this claim one way or another. Anyone on HN running their own mailserver wanting to comment on how large portion of connections get encrypted?

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. [email protected] to [email protected]), such delivery can be trivially encrypted.

> 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.

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)?

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.)

Perhaps only a handful such as Google will use SSL but Google is a HUGE percentage of email.

I completely assume that Google will turn over your entire email history to the US government whenever they ask, and without telling you, then or later.