The combination of a good amount of rules, Pyzor, Razor and immediate DNSBL blocking was still effective.
In the last months though, it appears something changed and a lot of unwanted email was going through.
Order was somewhat kept using IP addresses and IP ranges blocking — but at the price of sometimes blacklisting IP addresses in use by very common mass mailers and it also looked like the spammers had an infinite amount of new origin servers this time around.
More importantly, the antivirus was not getting updates correctly anymore so we had to do something.
The upgrade took some time because we wanted to make sure we'd have no false positives and could roll the new system in place of the older one.
We currently have a web UI at mailfilter.net7.be for looking at your registered domain email traffic going through the filtering system.
We wanted to be able to continue providing the quarantine system we currently have in place on that UI so that users can manually check which email has been blocked and have the possibility to release it.
We know some of our users also make use of the black and whitelist so we wanted to keep that working as well.
In conclusion: we needed something that we could easily hack into without recompiling everything.
There were other considerations in how we configure MTAs and how the filtering platform have to be able to send emails as well for some of our servers and customers. If you didn't know, we generally use Postfix as the MTA for all of the servers we deploy.
There is a relatively new project called Rspamd which provides a fast way of filtering email through a Milter filter, which is something that wasn't around when we developped the initial antispam platform.
The milter protocol was invented by the Sendmail developpers so that we could send the data along to a filtering software while the SMTP connection is still open.
Basically, all of the SMTP commands are also sent live to the milter filter, which can then decide of an action (accept, reject, quarantine, ...) based on the content it's receiving in real time.
Older filtering system would not work in parallel like that, they would have to fully accept an email before it could be passed through to other programs (like Spamassassin for instance).
Like the older system, Rspamd assigns a score to emails and we can configure actions to occur at specific score threshold.
- Score <= 4 — Accept immediately (no greylisting, no delays);
- Score > 4 — Soft-reject (greylisting);
- Score > 14 OR Virus detected — Quarantine.
Interoperability with previous tools
The web UI that was developped for the previous system is mostly still working with the new one.
Greylisting status is now shown in the listing (it was previously hidden):
Greylisted emails are currently logged multiple times, once per delivery attempt by the origin server. In the specific example above we see the email ended up being accepted in the end.
The multiple logging will probably be fixed at a later date to only register the greylisting one time.
The entire web UI will probably be upgraded at some point too as it's quite dated and not as mobile-friendly as we'd like.
The detail view works slightly differently as show in the example below:
- The message size is currently not saved in database although that may change at a later date;
- The delivery steps only show the last server that made contact with our SMTP servers;
- We no longer save the full email headers.
You can release an email from quarantine, which will send it to the recipient of that email. Be careful as you're allowed to release emails with viruses.
As before, we keep quarantined emails for 30 days.
We invite you to review the "Quarantine" tab to make sure there aren't any false positives in there.
We're doing this ourselves as we adjust the new system but we're open to any feedback.
How do I know if I'm using the Net7 antispam?
When using our email hosting services you should be going through the Net7 filtering platform already.
You can check that it's the case by looking up your domain name's MX records. We advise using:
- MX priority 5 — mxpool1.net7.be
- MX priority 50 — mxpool2.net7.be
Users are currently allowed to have different levels of black/whitelist, as in domain admins can create lists that get applied by default while specific users for these domains can create their own lists which will take precedence over the domain admin lists.
Finally, we have one global list that gets used if nothing else matched.
Whitelisted or blacklisted emails are flagged as such in the email lists. Blacklisted emails are quarantined and as such can be released would you still want to see a specific one.
A list matching will add a rule called "BWLIST" in the rule listing:
In case you're using web forms to send emails or mailing lists, you can request us to set up whitelisting for the SMTP From addresses that these services use so that you're certain to always receive these emails.
We have another level of whitelist that works with IP addresses and IP ranges that you may also request being added to for additional security.
Limitations and changes
In the preferences tab of the web UI, all of the features pictured below are no longer affecting anything:
We will probably change that page in the future and are thinking about keeping a switch to temporarily disable spam checks for your email domains only. Don't hesitate to shoot us a comment below if that's a feature you'd like to have.
We also used to edit the subject line of emails as ***SPAM SUSPECTED*** but decided to remove that feature. There is a header set to emails with the spam score and spam suspected status, if that's something you want to use with your email client or server.
Strict HELO checks
Unless a sending server has special authorization with our infractructure, we're now enforcing strict DNS checks as to how SMTP servers identify themselves.
SMTP servers trying to identify themselves as an invalid domain name or one that does not exist will no longer be allowed.
If you think you may have a legitimate web form being in that case please send us the server IP address so that we can allow it through although it's always a good idea to just have a valid DNS hostname configured for your SMTP server.
From direct observation and mail stats, the new system seems to be much more effective with no apparent false positives and that is with our IP blocklist not enabled.
We will probably create an IP blocklist in the future for unsolicited mailing lists but that will be a very precise and tightly controlled list with the least possible amount of entries.
This is all in the effort of continuing to refine the antispam process and make it more relevant to our specific activity.
We might publish some of the techniques we used to hack into Rspamd to have it save metadata to our databases at some later point.
Feel free to give your feedback by email or through the comment section below.