Encrypting mail between SMTP servers
One of the positive developments on the Internet over the last few years has been increased encryption of e-mail. The Internet is a hostile environment; sometimes your data goes through the servers and routers of companies you’ve never even heard of, or of governments you’ve heard of but don’t like. It makes sense to encrypt e-mail whenever possible.
We’ve supported encryption between our customers and our e-mail servers for a long time, protecting you from eavesdropping “hackers” when you use a WiFi connection at an Internet cafe, for example. But like most companies, we didn’t try encrypting outgoing e-mail after it left our servers or encrypting incoming e-mail from other servers. Although technical standards for doing that exist, they’re relatively new in Internet terms, and our original testing indicated it could cause problems with mail delivery due to many misconfigured servers on the Internet.
That’s changed: More recent testing indicates that it’s much more reliable, and other large companies like Gmail are starting to use it. Because of that, we now use strong TLS (SSL) encryption for inbound and outbound SMTP mail connections (“MX” mail delivery) wherever possible.
A concrete example will help explain what we mean. Imagine that last week, one of our customers in an Internet cafe sent mail to an address “@usbank.com”. That mail went through the cafe’s WiFi router, to our mail servers, through at least three Internet “backbone” routers run by other companies (including AT&T), then to the usbank.com servers.
Turning on SSL connections in the mail program (like Outlook) prevents other people in the cafe from viewing the mail, which is good because that’s probably the biggest risk. But it wouldn’t stop a technician at AT&T from reading it, for example, which you might have a problem with.
We now encrypt the mail “all the way through” if the final destination supports SMTP encryption. The usbank.com mail servers do, so the same message sent today is encrypted over every network connection, all the way from the Internet cafe to usbank.com. It’s now impossible for AT&T to eavesdrop on that mail. (A message in the other direction from usbank.com to our customers is also encrypted all the way through.)
Note that even this added protection isn’t the same as full person-to-person encryption, by the way. Although we’re not in the habit of reading customer e-mail, it’s still theoretically possible for us (or a technician at usbank.com) to do so, because we operate the encryption system. The only way to prevent this is to use encryption software like Pretty Good Privacy (PGP) on your own computer. That makes sure that nobody except you and the recipient can read messages you send, but requires that both of you install and configure the software.
By the way, if you want to check whether a given e-mail address offers encryption, there’s a useful third-party tool at CheckTLS.com for that. Just enter an e-mail address in the box at the top of the left column and click “Go”; it will tell you whether the receiving server accepts encrypted mail.
on Wednesday, January 12, 2011 at 11:40 pm (Pacific) Chris wrote:
Appreciate your thoroughness and enlightened management as always. Do I have to do anything on my end (other than enable SSL for incoming/outgoing in my e-mail clients, which is already the case) in order to take advantage of this new “all the way through” encryption?
on Thursday, January 13, 2011 at 12:23 pm (Pacific) Robert Mathews wrote:
Chris, you don’t need to do anything special. We always use encryption all the way through if the other SMTP mail server supports it, regardless of whether you’ve turned on SSL in your mail program (although you certainly should).