https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6220
--- Comment #19 from Warren Togami <[email protected]> 2011-12-12 19:09:10 UTC --- (In reply to comment #18) > (In reply to comment #17) > > DNSWL was just disabled by default due to returning known wrong answers to > > in > > abuse situations (bug 6668). Should this bug be closed as evaluated and > > deemed > > inappropriate for the same reason? Should the handling of the 127.0.0.255 > > value be changed to not cause false positives? > > I would agree. > > Until there is some RBL consensus on a "disabled" answer && code in SA to deal > with it && it doesn't break the currently supported versions, there is no way > an RBL that purposefully causes FPs due to overusage can be considered for > default enabling. > > Again, my understanding is that this is a good RBL that has promise and should > be considered by Admins, though. > > Are we on the same page? Huh!? Did something change significantly? http://www.spamtips.org/2011/05/dnsbl-safety-report-5142011.html http://www.spamtips.org/2011/01/dnsbl-safety-report-182011.html http://www.spamtips.org/2011/01/dnsbl-safety-report-122011.html http://mail-archives.apache.org/mod_mbox/spamassassin-dev/201102.mbox/%[email protected]%3E SEMBLACK has a long history of inconsistent behavior. It often has been measured to have a poor safety rating. It usually has unacceptably high overlap. Once I caught him outright copying other DNSBL's into his own. More recently it behaved as a less safe subset of one of our other DNSBL's. For these reasons I strongly advice folks to avoid using SEMBLACK. -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
