spamassassin-dev December 2011 archive
Main Archive Page > Month Archives  > spamassassin-dev archives
spamassassin-dev: [Bug 6400] GA feedback for Mailspike DNSBL

[Bug 6400] GA feedback for Mailspike DNSBL

From: <bugzilla-daemon_at_nospam>
Date: Thu Dec 01 2011 - 15:44:09 GMT
To: dev@spamassassin.apache.org

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6400

--- Comment #21 from Darxus <Darxus@ChaosReigns.com> 2011-12-01 15:44:09 UTC ---
(In reply to comment #19)
> Nope, that incident was March 2011.
>
> I actually was thinking along the lines of the dev@ threads "Other DNSBL's",
> Oct 2009, and "3.3.2 and MSPIKE", Dec 2010, and similar discussions about when
> and how to include new DNSBLs.
>
> DNSBLs do cause additional network traffic and load, which in particular for
> larger sites is a real concern. Any addition like this definitely needs to be
> communicated load and clear in the release announcement.
>
> Regardless, whether excessive queries might result in FP return values.

Thanks for the references. They happened before I subscribed to the dev list.
I just read through them here:
http://old.nabble.com/Other-DNSBL%27s-td25925640.html
http://old.nabble.com/3.3.2-and-MSPIKE-td30513395.html

There was *no* objection to adding tested DNSBLs to existing releases. Except
for your claim, again, in the second thread, that there had been a previous
objection. Which there wasn't, in those threads. The only objection of any
kind was:

Henrik K, Dec 22, 2010
> Not that it isn't a worthy cause, but you can't just start adding arbitrary
> unknown lists to mass checks. Some of them might crumble from the sudden
> mass check flood.

Which is not relevant to this bug. Also, I'm not convinced it's true.

And this is where you first claimed there had previously been a relevant
objection:

Karsten Bräckelmann-2, Oct 19, 2009
> A micro 3.3.x release probably is not the best opportunity, though. I
> recall there has been quite some discussion and resentment last time.
> Even when including new BLs for 3.4, we really need to communicate that
> added network load better to the user-base.

Was there another thread that I haven't read where this resentment was
discussed?

"MSPIKE (previously named ANBREP) has proven consistently in weekly masschecks
since before the release of 3.3.0" - Warren. So MSPIKE has been good since
before 2010-01-27. Two years. And from what I can tell, for at least a year,
it hasn't been added to the default rule set because of your unsubstantiated
claim that somebody else objected.

Can you start over and tell me why you don't think MSPIKE should be added to
existing 3.3 releases? I don't think anybody will mind the increased network
load. I think everyone will appreciate the resulting increased accuracy.

I wouldn't care so much if it was easy for us to maintain two sets of rule
updates. But we can't. So not adding MSPIKE to 3.3 means never adding MSPIKE
to spamassassin, or at least sub-optimal scoring in one of the major releases,
which you don't seem okay with either. Which results in spamassassin being
incapable of ever adding another useful DNSBL, which is not okay.

Somewhat related, spamassassin needs an announcement list, for announcing
changes like this, and releases. (bug 6714)

Not relevant to this bug, bug I can't help repeating why we use reuse, from one
of those threads:

Bjoern Sikora, Oct 19, 2009
> Please pay attention that some blacklists do only list IP addresses for hours.
> When running the mass check you need realtime data to get reliable results.

-- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.