Outgoing Port 25 Spam Filtering at Network Level

We regularly receive the request about possibilities to force filter all outgoing port 25 traffic at network level. Although various vendors claim to have a solution for this, they often are in violation of the data protection laws and result in a significant downgrade of the overall email security.

This article explains what can and what cannot be done within the bounds of data protection laws.

Transparent port 25 filtering (original sending IP is retained)

With transparent filtering, we refer to both the sender/recipient not being able to detect that filtering is taking place. The biggest challenge here 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 for scanning, spam cannot be actually read or blocked by a filtering solution due to the TLS security having encrypted the data already. Companies offering transparent filtering allegedly work around this limitation, by secretly turning off “TLS” in the connection. Normally, if you try and send an email, the recipient will tell you “I support STARTTLS encryption“, 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 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 something we cannot 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, said provider would be liable for serious penalties. Various vendors claim that this behavior would not be in violation of the EU data privacy laws, however there are no known full legal publications to support that claim (only partial publications that are likely partial for a reason).

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 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. If you'd still wish to apply this type of filtering, Spam Experts has build-in support for SOCKS5 proxy deliveries. Therefore you can technically use a SOCKS5 proxy in your network which spoofs the source IP address for the deliveries.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 behaviors.

There are already many recipients (i.e. governmental agencies) that force-require specific delivery certificates, which then would reject email from such transparent filter. Moreover, organizations such as Google have announced they will start showing warnings when this behavior is detected. Here at Spam Experts, we 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.

Interestingly, although this type of service is often offered, it is not commonly seen working on a large scale deployment.

Outgoing port 25 network block

Many providers nowadays simply block outgoing port 25 by default in the network (special customers are sometimes exempted), and force their users to use a third-party SMTP service, or they force their users to use the anti-spam SMTP gateway (such as Spam Experts). To send email, users can adjust their email clients/scripts to use the third-party SMTP service.

Outgoing port 25 redirection at the network level

If you operate your own networking, assuming your networking equipment supports it you could add a port based ACL and policy based routing (routers Layer-3+). Note that such port based ACL may take up quite some CPU resources on the routing equipment.

After authorizing your IP range(s) as Spam Experts outgoing users, you can forward all port 25 outgoing traffic for those ranges to the Spam Experts server IPs (at port 587, or a custom port 25 outbound listener). The Spam Experts servers will accept the connections, scan the email, and deliver the legitimate messages to the internet signed with the Spam Experts SSL certificate.

With this setup, the delivery of legitimate messages will be done from an IP address assigned to the Spam Experts server. You can configure which IP the system should use for delivery (depending on the source IP), however it's not possible to preserve the source IP of the originating server for delivery. This also means that SPF records (for example) would require updates to include the Spam Experts filter server IP space. DKIM is not affected as we do not modify the body of the messages.

Tip to preserve the original sending IP

For Spam Experts Local Cloud customers, we do have an option to re-route outgoing email for specific outgoing users via a SOCKS5 proxy. Therefore, if you can run a SOCKS5 proxy (such as Dante) and it can bind to the original sending source IP, it is possible to relay the filtered messages via the original source IP by use of the SOCKS5 proxy.

As a datacenter, how can I then best prevent ranges from getting blocked?

If you operate a datacenter, it's very important you monitor your IP space for abusive behavior. Many large mail companies (such as Hotmail and Gmail) can provide a free "feedback loop" with spam complaints from their users related to "your" IP space.

It is easy to automatically process such reports, e.g. using the opensource Abuse.io tool. If you get too many complaints about a specific IP, you can:

• Block port 25 outgoing for that IP until they've resolved the issue
• Block port 25 outgoing for that IP, and offer the client to relay their outgoing email via the Spam Experts solution to identify/block spam (and delivery from a clean IP)
• Force-redirect port 25 outgoing for that IP to the Spam Experts solution, to analyze the spam and determine to e.g. terminate the account

As a software development company, we value suggestions on how our technology can assist in preventing these issues.