Why Does SM Spam Filtering Continue To Fail?
Question asked by Brian Davidson - 8/1/2020 at 10:58 AM
We continue to see an excessive number of email messages that seem to bypass spam filtering. This is not new  to the current version of SM (17.x) but an issue we've never solved, even after opening tickets and tweaking the filters. Without re-hashing old troubleshooting steps (that didn't work), I'm wondering if anyone can answer a simple question:

Why would SM not add weight to a message that clearly is on a blacklist used in the filters? Simple example: SORBS -  Aggregate is in use, assigning a  weight of "4". Some messages which SORBS identifies as spam are weighted by SM's spam filters, some are not.  For those getting through the spam filter and not weighted I'm manually checking the IP's on MX Toolbox, finding they should have been weighted.

To be clear, I'm not expecting 100% accuracy. But messages sent by IPs clearly on multiple blacklists that slip through repeatedly are troublesome and annoying to clients.

It just seems to be incredibly inconsistent. Am I the only one finding SM's spam filters inconsistent ?

Thanks for any clarification to this process!

P.S. - better documentation of how SM 17 spam filters work would be a great asset and improvement.

4 Replies

Reply to Thread
Douglas Foster Replied
Workaround, not an explanation.

I use Declude with a SmarterMail server configured as an incoming gateway, which can be implented today at no extra cost.  Declude has many RBL checking options.   I have a few RBLs enabled and it has been reliable.   I delete on match found rather than weighting, so SM is not involved in the disposition.

If the bug occurs in the SM weight evaluation, rather than the RBL check, your situation may persist even with Declude.  

Does SM write a message header to indicate which spam tests were triggered?  If so, this would help with debugging.  Declude has this capability.
Steve Norton Replied
Are you using your own DNS servers to make direct lookups rather than forwarding to ISP or public DNS servers or are you doing zone transfers?
Douglas Foster Replied
Steve Norton brings up an important point.  Zone transfers do not reliably transfer the RBL database.  So it is important to NOT forward to public DNS servers like Google or Cloudflare   You need to use your our own DNS server which will query the RBL site directly.

Spamhaus has documentation about this problem.  I do not know which other services will have the same problem.
Brian Davidson Replied
Good point about the DNS servers and something we need to examine! 

I appreciate the feedback and advice.

Reply to Thread