The methods here are outwith the scope of the SpamExperts filtering system, and this information is provided for guidance only. We are unable to provide support for these systems.
It is common to want to intercept SMTP traffic at a network application layer. However, these methods are often in violation of the data protection laws and result in a significant downgrade of the overall email security as well as providing increased risks and chance of delivery failure.
This article summarizes what can and what cannot be done within the bounds of data protection laws at the time of writing.
Please seek professional legal advice to ensure your compliance with local legislation.
Outgoing port 25 network block
Many providers block outgoing port 25 by default in their networks, force their users to use a third-party SMTP service, or force their users to use an anti-spam SMTP gateway (such as SpamExperts).
To limit the egress of malicious SMTP traffic from a network, it is advisable to block outbound SMTP traffic (generally port 25) from the internal network, to the public internet.
Outgoing port 25 redirection
If you operate your own closed network, assuming your networking equipment supports conditional routing, you can add a port-based ACL and policy-based routing (routers Layer-3+) to route SMTP traffic to the filtering system.
After authorizing your IP range(s) as SpamExperts outgoing users, you can forward all SMTP outgoing traffic for those ranges to the SpamExperts server IPs (at port 587, or custom port 25 outbound listeners). The SpamExperts servers will accept the connections, scan the email, and deliver legitimate messages to the internet signed with the SpamExperts SSL certificate.
With this configuration, the delivery of legitimate messages will be done from an IP address assigned to the SpamExperts 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 SpamExperts filter server IP space. DKIM is not affected as we do not modify the body of the messages.
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. 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 SpamExperts solution to identify/block spam (and delivery from a clean IP)
- Force-redirect port 25 outgoing for that IP to the SpamExperts solution, to analyze the spam and determine to e.g. terminate the account
Transparent port 25 filtering (original sending IP is retained)
We do not recommend using this method, due to the security implications listed below.
- With transparent filtering, both the sender or recipient are not able to detect that filtering is taking place
- The biggest challenge is to preserve the source public IP address for delivery to the destination system, which means that the filtering environment has to act as a transparent proxy. For security, email uses STARTTLS session encryption, which is negotiated between the sender and the recipient systems
- When intercepting proxied traffic for scanning, message content cannot be read or blocked by a filtering solution due to the TLS security having encrypted the data between the sender and recipient systems. This causes a high risk of false negative detections
Systems offering transparent filtering can work around this limitation, by disabling STARTTLS in the connection. We do not recommend or encourage this procedure. When you send an email, the recipients system will tell the sending system “I support STARTTLS“, and the servers continue the conversation using an encrypted session.
This means that anyone who manages to intercept the traffic, can read every part of it. This is potentially in violation of the GDPR and other data privacy laws, and opens users to all associated penalties.