Why Outgoing Spam Filtering should not be done transparently


Datacenters and web hosting companies are facing challenges in today’s market, where their entire IP space may get a bad reputation resulting in email from their networks being blocked by recipients. In response, email security vendors often are asked for providing a transparent filtering solution to scan all outgoing email from their unmanaged (hardware/virtual) servers.

The approach offered  by some companies in the anti-spam industry is to use policy based routing to intercept and redirect outgoing port 25 traffic via a local filtering solution, transparently scan the traffic (without having their end clients make any modifications), and then delivering to the internet. This way the customer often does not notice or know about such filtering taking place.

Let’s dive further into the technical options for transparent filtering.

The biggest challenge is to preserve the source IP address for delivery, which means that the environment has to act as a transparent proxy. Generally, email uses TLS encryption, which is negotiated between the sender and the recipient. Thus, when trying to intercept such traffic, spam cannot be actually read/blocked by a filtering solution due to the TLS security encrypting all data already.

Companies offering transparent filtering allegedly work around this limitation, by secretly turning off “TLS” in the connection. Basically, if you try and send an email, the recipient will tell you “I support STARTTLS!“, and the servers continue the conversation encrypted. In case you actually intercept and hide that message, the sender assumes that the recipient does not support TLS encryption and hence will deliver all email unencrypted in plain-text, leaving a gap for any third-party/cyber-criminal to eavesdrop on that specific conversation.

As a security company, this is obviously something we can NOT encourage. This would mean that anyone who manages to intercept the traffic can actually read every piece of it. It is also in violation of the EU data privacy laws, so if a provider purposely disables STARTTLS in the conversation, and forces all communication to be unencrypted, such company would be liable for serious penalties.

The only way for an email security provider to work around this is to effectively execute a man-in-the-middle (MITM) attack, by replacing the TLS encryption certificate with its own during the STARTTLS negotiation. That way, the filtering service can actually decrypt the messages itself, and then re-encrypt them using it’s own certificate for delivery.

The biggest advantage is that all emails are still securely delivered to their destination mail servers. A downside however is that the certificate used for the deliveries does not actually match with the certificate that was originally used by the sender. These types of attacks are often used by cyber-criminals or intelligence agencies/governments to intercept email flows. To protect against such MITM attacks, several of the largest ISPs have recently proposed a draft document to build in technology to prevent this and ensure there’s no one snooping on your emails.

It’s understandable how tempting it is to be able to perform fully transparent SMTP email filtering of unmanaged servers, however the internet is quickly protecting itself against such unsafe behaviours.

There are already many recipients (i.e. governmental agencies) that force-require specific delivery certificates, which hence would reject email from such transparent filter. Moreover, organizations such as Google have announced to start showing warnings when this behavior is detected.

Here at SpamExperts, we hence don’t believe this is a long-term feasible solution, especially if we take into account the growing concerns over privacy and security in the past few years.

It is sad to see when peers from the email security industry offer the transparent filtering solution to potential or existing clients (with encryption disabled, or with a MITM TLS “attack”), and interestingly we have not yet found a single party that actually has such email filter setup live on a large scale.

It would likely be unwise to intercept encrypted traffic or disable SSL/TLS encryption from a marketing/PR perspective as well, as it’s an equal trick to the “Gogo in-flight” SSL interception many people may still remember. Such negative PR is likely to hit any organization that is detected in applying a similar trick to filter the email traffic.

Here is what SpamExperts recommends to prevent spam from unmanaged servers in your network:

  1. You block outbound port 25, and force your customers to use a spam filtering smarthost to relay email to the internet.
  2. You redirect port 25 outbound to a spam filtering solution, and have the email delivered from a separate “delivery IP space” allocated to the spam filtering servers. That way, the spam filtering correctly takes “ownership” of the delivery, and hence the security negotiation would properly match.
  3. You don’t do any active filtering, and instead passively respond to spam outbreaks by subscribing to free feedback loops using for example, an open source abuse management tool such as Abuse.IO. When you have spamming customers, you simply warn them and if no improvement is made block their port 25 (to force them to use an external relay or spam filtering solution).

These proposed solutions are technically valid and represent a clean way to solve outbound spam issues.

If you know of any companies which apply transparent filtering, let us know! We’d love to start a public discussion on what behavior for outgoing email filtering is acceptable, legal, technically valid, and preferred.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s