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.
