Opportunistic TLS and MessageLabs

Back in February 2008, I suggested to the Sendmail admins that we look into opportunistic TLS.   Like all encryption there is a performance hit.   Unlike S/MIME or PGP the encryption is only during transit between links.   Additionally there is no guarantee that all links will be encrypted.   Hence the word opportunistic.   While you don’t want to get a false sense of security from it, I don’t see a reason not to implement it on a system that has the performance capacity.  

The Sendmail admins added opportunistic TLS to outbound email pretty quickly.   However they found that to add it for inbound email required recompiling Sendmail.   As a result, this was put on the shelf for a while.   Here we are 2.5 years later, and as part of moving Sendmail to a Solaris blade server, they added opportunistic TLS for inbound email.  

There’s always a but…

We use MessageLabs as our secure email gateway.   I assumed that because I could connect to them on port 25 and initiate the command STARTTLS that meant they supported opportunistic TLS.     The exact phrase I used in Feb 2008 was “I suspect messagelabs would then send our inbound email across a SSL session making our email slightly more secure.”   It turns out my assumptions are incorrect.  

Symantec MessageLabs does not support opportunistic TLS (Solution ID: DA_116296).   Solution ID DA_136900 claims that opportunistic TLS is a security threat rather than a security feature.   Because it only encrypts a connection when it can, unencrypted email can be sent.   This is of course true.   But at a minumum, I would know that the connection from my servers to MessageLabs was encrypted.   Final secure delivery would depend on the configuration of the recipient servers.  

It seems to me that Symantec MessageLabs is trying to force customers to purchase their Boundary Encryption product.

I have been informed via the comments that if MessageLabs receives the message via SMTP/TLS they will attempt to preserve that level of security on delivery to the next hop.   That makes sense.   In most cases adding encryption merely for the last hop is pointless.   Sweetness.  

So the onus is back on other mail providers.   I saw a great rant recently on Gmail not providing opportunistic TLS.   


  1. Hi, I work on the MessageLabs email software. While I’m not writing on behalf of the company I wanted to address your question:

    MessageLabs will attempt opportunistic TLS if the original mail was received over TLS; mails received over plain text will not be upgraded to TLS (unless as you point out you pay extra for the Boundary Encryption product — specially Secure Connect).

    Obviously this means not everything will be encrypted, but if the sender used opportunistic encryption we will honor that through to you.

    • That is awesome news. Sounds like I should have opened a ticket before ranting. (although to be fair to myself I did go to the knowledge base).

      Not quite opportunistic, but sounds like the correct middle ground.

Comments are closed.