I noticed disabling DNSWL in SA didn't seem to affect bandwidth. Then Matthias pointed out the possibility it was because this lacked:
meta __DNSBL_FOO 0 Seems Karsten's ranting was correct :P Shame, would have been fun to see that data. I see http://wiki.apache.org/spamassassin/DnsBlocklists says you should use: score __RCVD_IN_ZEN 0 .."score" instead of "meta". Is one better than the other? Should we open a bug to disable things like __RCVD_IN_DNSWL when all its subrules have a score of 0? Current behavior seems not great. On 12/12, [email protected] wrote: > https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6668 > > Kevin A. McGrail <[email protected]> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|REOPENED |RESOLVED > Resolution| |FIXED > > --- Comment #24 from Kevin A. McGrail <[email protected]> 2011-12-12 16:31:32 > UTC --- > > The reason for the special result code, as indicated in the posting > > referenced > > above, is that REFUSED rcode will result in triple the amount of queries in > > most cases. > > In the absence of a patch to implement your special return value (which I > think > needs to be outside of 127.X and should be discussed with other RBLs), I can > only recommend that you simply blackhole the requests from servers in excess > of > 100K that you consider abusive. > > Additionally, as with Joao, I am also happy to support your project with a > public nameserver. > > However, I can't support your policy that causes FPs in SA as I feel it is > unrealistic to launch an RBL and not expect this type of problem. > > As of today, DNSWL will be disabled by default in SA's rules. SA Admins > wishing to use it, should add something like this to your local.cf: > > #ENABLING DNSWL - BUG 6668 > score RCVD_IN_DNSWL_NONE 0 -0.0001 0 -0.0001 > score RCVD_IN_DNSWL_LOW 0 -0.7 0 -0.7 > score RCVD_IN_DNSWL_MED 0 -2.3 0 -2.3 > score RCVD_IN_DNSWL_HI 0 -5 0 -5 > > This disabling will be effective with the next rules update. > > However, please note that we are *very* open to discussing policy changes that > will help maintain your project, it's success as a spam test and not cause FPs > so that it could be re-enabled by default. > > Regards, > KAM > > svn commit -m 'Changing scores of DNSWL due to FPs caused by their nameservers > anti-abuse policies - Bug 6668' > Sending rules/50_scores.cf > Transmitting file data . > Committed revision 1213299. > > -- > Configure bugmail: > https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are the assignee for the bug. > -- "Think, or I will set you on fire." http://www.ChaosReigns.com
