A related issue... I recently switched PSBL to "tflags reuse" because PSBL had been enabled for quite a while now, thus there should be sufficient corpora to determine its true performance at the time of its delivery. Without "reuse" we've been seeing only PSBL's listing status of all lastexternal IP's currently in the masscheck, which is less of an accurate measure. Unfortunately, we are unable to measure MSPIKE in the same manner because the corpora lacks a year of MSPIKE testing. This has been a chicken & egg problem. At the moment we only know for certain "MSPIKE is awesome." But we are unable to determine its relative level of awesomicity because it isn't an apples to apples comparison.
Any ideas how we can break through this chicken & egg problem? Perhaps if we did something like: * All major sources of corpora use MSPIKE from now on. * Implement something like "tflags reuse after=20110101" * This still wouldn't be an apples to apples comparison, but it would be an improvement? Now back to your comment below. IIRC, most of the resentment voiced last year was primarily in adding of more DNSBL's to the nightly masscheck without discussion. I came to agree to discuss it here before doing any more of that in the future. As for the wisdom of adding a new DNSBL to 3.3.x or 3.4.0, perhaps we should discuss that anew? We may also want to discuss removal of older DNSBL's that have proven to be less effective than the candidates for default inclusion. For example, why do we continue to query NJABL when it seems to catch very little of anything? (It also seems to be the slowest of all my DNS queries.) SPAMCOP and BRBL have had poor rates of FP for the past year now. BRBL perhaps is tolerable because it seems to catch 90%+ of spam. But why do we continue to use SPAMCOP while others like PSBL, SEMBLACK and MSPIKE have nearly the performance but with consistently better safety? Let us consider replacing less effective queries with better queries. While I'm bringing up these long-standing problems, I might also point out the other elephant we've been ignoring out of apathy. http://www.mail-archive.com/[email protected]/msg69546.html As I discovered last year, the whitelists have nearly zero impact on the safety of spamassassin. I think we should further reduce all of their default scores. Leave it up to the user to manually (and unwisely) increase the whitelist scores on their own server. Warren 2010/12/22 Karsten Bräckelmann <[email protected]> > On Wed, 2010-12-22 at 08:05 -0500, Kevin A. McGrail wrote: > > I'm +1 for mailspike being in a release. I'm also a nameserver for it > > and have been tweaking the cf file with the author's help. it has > > overlap with other rbls but about a 10% differential. > > 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. > > > > "Warren Togami Jr." <[email protected]> wrote: > > > Would you folks consider accepting it as default in 3.3.2, or would you > > > prefer waiting until 3.4.0 to enable a new DNSBL by default? > > -- > char *t="\10pse\0r\0dtu...@ghno > \x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4"; > main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? > c<<=1: > (c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; > }}} > >
