spamassassin-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Kettler <mkettler...@verizon.net>
Subject Re: clarification of our inclusion policy (fwd)
Date Wed, 03 Oct 2007 01:47:37 GMT
Michael Peddemors wrote:
> On Monday 01 October 2007 13:41, Justin Mason wrote:
>   
>> I think this is a case where pragmatism may need to be applied. The thing
>> is, we *could* disable Razor, and later DCC, back then, because there were
>> alternatives doing more or less the same thing. If we disable Spamhaus, I
>> think we'd be in a much worse position. :(   They're an important DNSBL.
>>     
>
> One other thing to consider in these arguments, is that in most environments 
> where they wish to use Spamhaus data, or any other RBL data for that matter, 
> usually have separate processes to block senders in that space, so it would 
> seem redundant for SA to do a check that in most cases will already have 
> occurred.  And that already allows for the flexibility that various licences 
> dictate.  
>
>   
I don't know that that assumption is reasonable grounds to remove RBLs
from SA... It may be true in some cases, but it's certainly not all cases.

I, like many others, use absolutely no RBLs to block messages at the MTA
layer, because I have yet to find any that are sufficiently accurate
that I'm willing to accept the false positives. Personally, I feel that
any "auto-deleter" should really approach the level of reliability of
good network hardware. XBL does pretty well, but even that's not a "four
nines" level of accuracy. In fact, it's only 99.8% accurate in the
latest SA mass-checks, so it's not even "three nines"

However, I do find it quite reasonable to use them in a scoring system,
where the RBL alone isn't enough to block a message, but when combined
with other factors or other RBLs, it becomes significant. And even with
that safety buffer, I only use SA for tagging purposes, allowing the
recipient the option of skimming the message. Because even SA has a
0.06% false-positive rate at a score threshold of 5.0.

In fact, problems associated with the whole "block if message meets
single criteria x" is one of the reasons Justin has mentioned as
motivating him to create spamassassin in the first place, so expecting
folks to use such a solution is somewhat contrary to the purpose of
SpamAssassin.






Mime
View raw message