You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by Justin Mason <jm...@jmason.org> on 2007/10/01 22:41:25 UTC
clarification of our inclusion policy (fwd)
[Moving this discussion from the private list.]
Matt Kettler writes:
> SpamAssassin's past behaviors could be summed up as:
>
> We'll include anything we find useful, but we'll disable by default
> anything that's not free for everyone.
>
> I base that on two past decisions by the project:
>
> SA has a tendency to include anything we find useful, as it's nearly
> always had MAPS RBL rules, despite MAPS being a commercial subscription
> RBL for anyone other than educational institutions and private users..
> (note: I'm not sure what's happened to MAPS licensing since trend bought
> it.)
>
> SA also appears to disable-by-default anything that's not "free for
> anyone", based on the past where SA disabled razor for having a
> restriction on free use by "large volume users". Although their policy
> was also vague, I think razor were not sure what limits to
> set so they were trying to pick it out based on those causing
> substantial load on their servers.
Yep. I'm not really sure what Razor's plans were there, though; but the
effects of the restrictions were clear enough at the time.
We disabled DCC since its licensing rules changed, too, to
block commercial use.
> Now, personally I don't have a problem if we want to talk about changing
> that slightly, but I think that policy is a good baseline to work from.
I agree. +1
> I certainly think it's reasonable to allow services that have a "free
> for all, unless your query load winds up DoS'ing our servers" to be
> enabled by default. Every network check has that policy, even if they
> don't write it down.
yes. +1 Note that many of the other DNSBLs ask that high-volume users rsync a
local zone -- they don't charge, but they do *imply* that high-volume direct
querying is *discouraged*.
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.
> Restrictions against appliance vendors (ie: barracuda) I'm not sure how
> I feel about. In some ways I can see the argument "if you're an
> appliance vendor, you should be expected to check the licensing of all
> the network tests", but that seems a little far-fetched for the
> small-shop guys making SA "appliances". If we do start allowing these,
> we really should at least include a README.appliances file telling
> appliance vendors that not all network tests are free for their use and
> they should check with the services directly.
+1. Perhaps just in the existing README, though.
--j.
Re: clarification of our inclusion policy (fwd)
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
Graham Murray wrote:
> Michael Peddemors <mi...@linuxmagic.com> writes:
>
>> And with the current SA, this is more difficult to turn off via a config
>> option for example..
>
> I do not think it is difficult. Does setting the scores of the following
> rules to zero in local.cf not turn off spamhaus RBL checking?
> __RCVD_IN_ZEN RCVD_IN_SBL RCVD_IN_XBL RCVD_IN_PBL
URIBL_SBL queries sbl.spamhaus.org, FWIW.
[dos@cyan 3.2]$ pwd
/home/dos/sasvn/rules/branches/3.2
[dos@cyan 3.2]$ grep spamhaus * | grep -v :lang | grep -v \#
20_dnsbl_tests.cf:header __RCVD_IN_ZEN eval:check_rbl('zen',
'zen.spamhaus.org.')
20_dnsbl_tests.cf:header RCVD_IN_XBL
eval:check_rbl('zen-lastexternal', 'zen.spamhaus.org.', '127.0.0.[45678]')
20_dnsbl_tests.cf:header RCVD_IN_PBL
eval:check_rbl('zen-lastexternal', 'zen.spamhaus.org.', '127.0.0.1[01]')
25_uribl.cf:uridnsbl URIBL_SBL sbl.spamhaus.org. TXT
[dos@cyan 3.2]$
Re: clarification of our inclusion policy (fwd)
Posted by Graham Murray <gr...@gmurray.org.uk>.
Michael Peddemors <mi...@linuxmagic.com> writes:
> And with the current SA, this is more difficult to turn off via a config
> option for example..
I do not think it is difficult. Does setting the scores of the following
rules to zero in local.cf not turn off spamhaus RBL checking?
__RCVD_IN_ZEN RCVD_IN_SBL RCVD_IN_XBL RCVD_IN_PBL
I have set these in my systems (as they reject on zen at SMTP time) and
I do not think that Spamassassin querying spamhaus since I added these
rules.
Re: clarification of our inclusion policy (fwd)
Posted by Michael Peddemors <mi...@linuxmagic.com>.
On Tuesday 02 October 2007 18:47, Matt Kettler wrote:
> 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
>...
> 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.
Understood, however with RBL's that are of a high level of effectiveness,
there are more and more pressures in real world environments to reduce the
amount of actual data a server has to process. If as some of the talk in the
industry hints at, that there will be legal requirements to track or retain
email, then such reductions become more and more paramount. And I do think
that your particular setup may be in the minority now, and even more so in
the future, so what I am saying is not to DROP RBL's in SA, but not to
include certain ones that may be problematic by default. Make it an option
to do eg SpamHaus checks, not a default perhaps..
In recent weeks, we have seen the effect of 3 different ISP's whose mail
services were affected by SpamHaus blocking their DNS Servers, with
accompanying large increases in local processing times and concurrencies.
And with the current SA, this is more difficult to turn off via a config
option for example..
--
--
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors - President/CEO - LinuxMagic
Products, Services, Support and Development
Visit us at http://www.linuxmagic.com
------------------------------------------------------------------------
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" is a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-589-0037 Beautiful British Columbia, Canada
This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.
Re: clarification of our inclusion policy (fwd)
Posted by Matt Kettler <mk...@verizon.net>.
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.
Re: clarification of our inclusion policy (fwd)
Posted by Michael Peddemors <mi...@linuxmagic.com>.
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.
--
--
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors - President/CEO - LinuxMagic
Products, Services, Support and Development
Visit us at http://www.linuxmagic.com
------------------------------------------------------------------------
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" is a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-589-0037 Beautiful British Columbia, Canada
This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.