Carlos E. R. wrote: > Now, the culprit seems to be "RCVD_IN_BSP_TRUSTED". What on earth is > that? My method to learn a bit more is to grep for the token, via > "grep RCVD_IN_BSP_TRUSTED /usr/share/spamassassin/*", and what I got > is this:
I've also seen that rule fire once or twice recently too. Whether you use it or not depends quite a bit on how much you trust the bonded-sender guys. > Interestingly, spamassassin is so inconsistent that only the German > version contains a web link. It appears that failures can be reported, > but I don't know "who" is marked as trusted in that email. spamassassin is an apache project, you just use their bugzilla. > Two questions: > > How do I know which of the several received headers is considered > "trusty"? You'll have to run the addresses through the test manually - I think. Or maybe run the mail through spamassassin with debug on. > Now, where do spamassassin document the rationale for choosing a > particular test, how and when to use it, etc? A lot of it is done with statistics and checking the spamassassin collections of spam/ham (corpi). > It doesn't seem to me to be that reliable. > It is not the first time I have had to disable a > particular SA test. :-/ You can't really blame SA for this one - it probably is fairly reasonable to trust the bonded-sender guys. However, there are a few other weird and wonderful SA rules that need fixing or disabling: SUBJECT_ENCODED_TWICE - this happens a lot in emails written in Outlook in other languages but English. RCVD_IN_WHOIS* - as far as I'm concerned, the completeWhois people can't be depended on to deliver quality data, OBSCURED_EMAIL - it would never be able to do what it says it does. And that's just a few samples. /Per Jessen, Zürich -- http://www.spamchek.com/ - your spam is our business. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
