https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6400
--- Comment #21 from Darxus <[email protected]> 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.
