It is possible to encrypt SMTP connections with standard SSL/TLS technology.
FastMail has been using opportunistic encryption on their incoming and outgoing SMTP servers for years. If you send an email to another service that does opportunistic encryption, and if both the sender and recipient uses SSL to access their mailboxes (as FastMail requires), the email will never be transmitted in plain text over the Internet.
The problem with such opportunistic encryption, is that you could insert a man in the middle which basically intercepts the traffic and modifies the handshake to exclude the STARTTLS extension.
With opportunistic SMTP encryption this will cause things to proceed in plain text.
The sinister thing about this is that e-mails still flow, so it still works.
There exists some Cisco network gear that intentionally breaks STARTLS commands in it's default configuration (and wasn't debugging _that_ on a piece of network gear a client owned but didn't know about a fun waste of several weeks…)
Meanwhile, does SMTP have something like HTTP Strict Transport Security? It would be nice for an impartial party to compile a list of mail servers that pledge to accept encrypted connections, and for sending MTAs to treat it as a connection failure if the destination is on that list but doesn't appear to support encryption.
A very naive estimate based on one day of logs from one server says over 75% of our incoming port 25 connections are encrypted. Although that says nothing about the quality of the cipher in use and the type of messages that come through, its still significantly higher than I would have expected.
I can see I'll be spending some time on this in the next few days!
Thanks for that. They're useful numbers for me, because I've got this plan…
My current side-project involves a RaspberryPi (sitting in my loungeroom on my home ADSL connection), iRedMail, full disk encryption, a handful of inexpensive VPS providers with APIs that allow automated provisioning (DigitalOcean, NineFold, and Hetzner – to spread out the jurisdictions) – with the RasPi opening a reverse SSH tunnel for ports 25 and 465. Add in a DNS provider with a useable API so the 'Pi can spin up and shut down VPSes itself and update MX records to suit, and VPS images configured to not log anything mail-related, and I think I've gone as far as I can to secure my end of all my email. Having physical control of the hardware/storage that my email relies on won't protect me against NSA level targeted-at-me snooping, or even local law enforcement with sufficient "probable cause" to get a judge to sign a search warrant, but at least I'll _know_ if someone grabs my server hardware. (Hmmm, I wonder if there's some NSL-type coercion that could be used against my partner to force her to let someone take/image my 'Pi while I'm not home, and not be allowed to tell me?)
Possible over-paranoid ideas include refusing port 25 smtp connections that wont negotiate a secured connection in response to a STARTLLS command, and possibly blacklisting mail originating from any of the 8 known PRISM collaborators. I like the _idea_ of ensuring none of my mail arrives from known-intercepted sources, but reality dictates otherwise since way too many of the people I really do want to communicate with are exclusively using gmail/yahoo for email (or worse still, have migrated largely to Facebook messaging instead of email).
FastMail has been using opportunistic encryption on their incoming and outgoing SMTP servers for years. If you send an email to another service that does opportunistic encryption, and if both the sender and recipient uses SSL to access their mailboxes (as FastMail requires), the email will never be transmitted in plain text over the Internet.