On 13 Oct 2016, at 1:06, li...@lazygranch.com wrote:

On the surface, SA hitting multiple RBLs sounds inefficient.


SpamAssassin is inherently inefficient. That's why in a production environment with heavily loaded systems, it is important to have layers ahead of it to deal with the bulk of spam. Fortunately, recent versions (since 3.3, I think) are more parallelized so that high-latency tests (i.e. 'net' rules) don't block each other or faster scans, so it is not a huge problem. Essentially all the DNSBL, DNSWL, and URIBL checks are done in the time it takes to do the slowest one.

However does each hit add to the SA rating?

Yes, although it's variable and subject to local adjustments.

There are some complications involving multiplexed DNSBLs and a few meta rules that combine DNSBL rules with each other or with other rules, but essentially DNSBL rules get summed up just like any other SA rules. The default ruleset has 65 scored rules calling the check_rbl_sub or check_rbl methods. Each rule's score is either determined by the SA project's RuleQA/massscan service or is set to a fixed value that can be changed in local config but isn't subject to nightly automated tuning. Few (if any) are ever individually scored above 3.6, so no single DNSBL can cause a message to be tagged as spam if you use the default threshold (5.) Of those 65 rules, 25 are disabled by having fixed scores of 0, 15 are effectively informational with fixed or tuned scores between -0.1 and 0.1, 11 are whitelists with scores < -0.1, and 14 are blacklists with scores > 0.1.

If so, that sounds like a plan. That is if a message is rejected by N RBLs, it is more significant than just one RBL.

That's the principle both in SA and in postscreen. SA does a much more complex aggregation of DNSBL results than I'd want to make postscreen do, but it is useful to have a simpler aggregation in postscreen to handle the clearest cases without needing to do any more work.

Reply via email to