R> 70_sare_bayes_poison_nxm.cf I personally don't use this -- I personally verify 75%+ of all mail that goes through SA's analysis on three domains, and I feed 100% of that mail (excepting lists like this) into SA-Learn. IMO there is no bayes poison, only bayes fodder. I expect the rule set would be useful for those with less comprehensive training. Also, since you don't mention Bayes above, if you /don't/ run Bayes, this rules file can be very useful.
I agree totally on the concept of poison in terms of training. There is no bayes poison, only fodder.
However, I would also agree that detecting lame attempts to poison bayes is a good spam sign. With SA 3.0's weak bayes scores in set3 (1.886 for BAYES_99), this can help even a system with a well trained bayes DB.
You say you're running with SURIBLs. Are you also running with other network tests? All standard network tests are good aids to SA scoring, but they can contribute to a timeout problem, since they need to wait for that other system somewhere on the network to respond.
Agreed. be sure to run spamassassin --lint -D to see if any are getting wedged.
This is especially true for pyzor, razor, and DCC. They have fixed 10 second timeouts on them. I use DCC and razor. Between the two razor is generally slower, and more prone to outage. (I just ran tests on 3 messages. Razor took a bit over twice as long for each message. But then again, razor is more complex as it does multiple hashes it does the e4 partial-body-text hash and e8 hashing of URLs. Still, if speed is your goal, razor might not be for you.)
DNSBL outages generally aren't as much of a problem, as SA 2.6x and higher have a good adaptive DNS timeout that makes the "one dead list" not so much of a problem. Once it gets a bunch of responses it shortens the timeout. If all the lists except one come back in the first second, the remaining list is given 3 seconds and then SA bails on it for a total time of 4 seconds. This can be a bit of a slowdown, but it's not as bad as 10 second razor timeouts.
