Concerns and questions about the secure and encrypted transmission of email messages have flooded the inboxes of our staff here at SocketLabs. Compromised systems, database thefts, and technology breaches across entire organizations are common place in today’s news. As a result the technology industry has seen a new focus on the security and encryption of communications across all platforms.

What is SSL and TLS and how can it protect my data?

Secure Sockets Layer (SSL) and Transport Layer Security (TLS) are methods of encrypting traffic from one point to another, similar to the way your data is transmitted from your browser to your bank’s website. TLS is the successor to SSL, but the differences between the two are negligible in most cases, and as a result the terms are commonly fused together. For the most part, normal email communications are not encrypted at all. By using SSL email or TLS email, a layer of security can be added to your messages.

The Push Towards Encryption

In February 2014, SocketLabs attended an email security conference and the topic of pervasive use of SSL/TLS was brought to the forefront of discussion very quickly. Mailbox providers made it clear that they were rapidly deploying support for encryption, if they hadn’t already, and were pushing us as senders to follow suit. There was a newfound focus on addressing privacy concerns of their users.

SSL/TLS have been around for years so one of the recurring questions asked is why we haven’t previously had a focus on encryption technologies. What many may not realize is that before 2014, the implementation rate of SSL/TLS in MX hosts was, frankly, pathetic. Few system administrators wanted to deal with the headaches in certificate management, and myths about CPU cost resulted in many holding back deployment.

More recently, though, these tides have turned. Statistics provided by Michael Adkins, Mail Integrity Engineer at Facebook, give some great insight into the Current State of STARTTLS Deployment. Adkins notes that over 76% of unique MX hosts Facebook interacted with now support STARTTLS, resulting in about 60% of the mail they sent being delivered over an encrypted connection.

Google is pushing the hardest for a faster adoption of SSL/TLS. They are now publicly shaming anyone that is not encrypting their mail traffic. You can find their report here and you can search for the SocketLabs On-Demand SMTP service via our infrastructure domain [ email-od.com ]. This tactic seems to be working for Google as both Comcast and Apple’s iCloud email service have both implemented STARTTLS support since the report’s release. Google has also provided data from the start of 2014 which shows a near 100% growth rate in SSL/TLS adoption across their mail streams, both inbound and outbound.

Secure Delivery with Hurricane MTA Server

With this newfound push towards secure message delivery, we didn’t waste any time building in new encryption features and fixing existing encryption related issues in Hurricane MTA Server, the on-premise email delivery solution we offer here at SocketLabs. While Hurricane MTA already supported basic encryption options, there were opportunities to improve these offerings which we could no longer ignore. For example, those running Hurricane MTA Server v2.2.0.36 will now see flags for ignoring certificate errors, and fixes for timeouts in the SSL/TLS handshake process. We’ve also added a beta feature to Hurricane SMTP Load Balancer to support the StartTLS command.

Hurricane MTA is also the engine that powers our On-Demand cloud service. One of the big advantages to our cloud platform is that it is developed in-house from end-to-end. Unlike other services, we are not reliant on a third party to update their MTA product to enhance how we deliver mail. We are not aware of any other hosted SMTP provider that is operated atop their own MTA.

Secure Relay with SocketLabs On-Demand

Delivery

We have transitioned all SocketLabs On-Demand servers to utilize opportunistic TLS encryption in the message delivery process. We now deliver millions of messages a day securely. SocketLabs delivers all messages – platform wide – to major providers like Gmail, AOL, Yahoo, and Hotmail securely. We have been setting encryption ON by default to all domains across our servers.

To reduce potential hiccups in creating a secure connection we currently ignore any certificate warnings and errors. This means that we will deliver mail using SSL/TLS to domains with self-signed certificates or other common certificate issues. We hope to eventually be able to open up some per server configuration options in our Control Panel to allow for a more refined control. For now in order to modify these options please see our new knowledgebase article on what our support team can customize in regards to SSL/TLS for your server: [ https://support.socketlabs.com/kb/140/ ].

Injection

It is important to understand that there are two separate and unique message transmissions when relaying a message through SocketLabs. While we have full control over the final message delivery process, we do not have control over how a message passes from you, our users, to our inbound SMTP gateway. The smtp.socketlabs.com gateway has supported secure connections via SSL/TLS over port 465, although we’ve never publicly documented its support. For more information on exactly what is supported by our inbound gateway please see our new knowledge-base article on the topic:  [ https://support.socketlabs.com/kb/141/ ].

Our Support for SSL/TLS

One of the reasons we have been shy about publicly documenting support for secure inbound connections to our platform is because of the false sense of security it could have created. Users may have incorrectly assumed that since they were relaying messages to our platform over an encrypted channel that the messages remained encrypted until they were delivered to the recipient, but this is not the case. SSL/TLS does not encrypt individual messages; it actually encrypts the communication from one mail server to another. It may help to think of SSL as a secure tunnel for data. So when messages are relayed to us using SSL/TLS, due to the nature of SSL/TLS, that encryption is terminated when we receive the message. The actual message data is not encrypted at this point. To deliver the message securely to the recipient’s mail server, an SSL/TLS encrypted connection would need to be opened from our servers to the recipient’s mail server. And we are working on improving the our ability to establish these outbound SSL/TLS encrypted connections as much as possible. If you have any questions, please contact our On-Demand Support Team.

Additional Resources

With a topic as hot as secure email delivery, there are a lot of great resources you will find on the internet.  Our partner, Return Path, recently blogged about Why You Should Take Advantage of SMTP over TLS.  To check if your mail server, or mailbox provider supports SSL/TLS check out STARTTLS.info from Einar Otto Stangvik.

Does this make you wonder if your server is protected? Use our free MTA-STS Verification Tool to get a head start on encryption and verification issues with Socketlabs.

All other comments, questions, and concerns about secure email delivery can be directed to our On-Demand Support Team.
[Update 7/6/17]