TLS over SMTP – How to protect your email from prying eyes on the internet
August 9, 2013 Leave a comment
Those who have worked with email servers should know what SMTP is but many do not understand what TLS has to do with it. It is even more amazing how many people don’t realize that e-mail is worse then a postcard written in pencil. It is in clear text easy to read, modify, and pretend to be someone else to get what you want.
My last post on DMARC, SPF, and DKIM would help protect many people from receiving emails pretending to be from your domain, sometimes called email spoofing or phishing. This post will focus on options to keep those prying eyes from seeing emails sent from your domain by encrypting the connections between the receiving and sending domain email gateways using TLS.
Think of TLS to SMTP as what SSl or HTTPS is to HTTP. Except one difference, TLS can happen on the same port as SMTP. So how do we ensure that the receiver does not revert back to cleartext? Well we create policies to cover the receivers we want to send mail to to ensure they are forced to receive using TLS or the email fails.
So the first thing to do is to check if TLS is enabled on your SMTP server. Best and quickest way to do this is to use the SMTP testing tool at mxtoolbox.com. You can check yours and anyone you what to send emails too.
Next if you don’t have TLS, you can generate a self-signed or better yet get a inexpensive Public CA signed SSL certificate from RapidSSL. Then setup your gateway or exchange server to use TLS for its interfaces and mailflows.
Now who do you ensure that mail is sent TLS, and if it can’t be sent TLS and you still want it to get your message through securely? Here is where one could create another smart-host or gateway, that also acts as a secure ad-hoc webmail server as needed. If the server can connect via TLS it send that message through also letting the sender know that it was delivered, and possibly read securely and letting the receiver know that they are receiving a secure mail via TLS.
If for some reason TLS fails the message is hosted on the webmail server, and a registration and seporate notification that a secure email is awaiting the receiver on the senders web server. The user registers somehow and picks up the message. The sender is then notified that the message has been received.
There are probably products out there that do this. They are expensive, but this is not really rocket science. I’ll post back if I find an easy open source solution to this problem.
But if you just enable TLS you are making huge strides to protecting your sensitive emails, and even consumer email such as Google Gmail defaults to TLS.