sa-updates failures since few days : failed to parse line URIBL_SBL_A
Hi We encountered a problem with sa-update since the last week-end. It fails with this error : config: failed to parse line, skipping, in /tmp/.spamassassin32504f7H7V4tmp/72_active.cf: uridnsblURIBL_SBL_A sbl.spamhaus.org. A May be it's related to : https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6696 Anybody has got the same error ? I'm using spamassassin 3.3.1. Regards -- View this message in context: http://old.nabble.com/sa-updates-failures-since-few-days-%3A-failed-to-parse-line-URIBL_SBL_A-tp32958554p32958554.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: sa-updates failures since few days : failed to parse line URIBL_SBL_A
On 12/12/2011 6:17 AM, numberxiii wrote: Hi We encountered a problem with sa-update since the last week-end. It fails with this error : config: failed to parse line, skipping, in /tmp/.spamassassin32504f7H7V4tmp/72_active.cf: uridnsblURIBL_SBL_A sbl.spamhaus.org. A May be it's related to : https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6696 Anybody has got the same error ? I'm using spamassassin 3.3.1. You are correct and it is related to 6696. https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6720 is tracking this issue. Regards, KAM
DNSWL will be disabled by default as of tomorrow
Tomorrow's sa-update will include disabling of the DNSWL rules. If you wish to locally enable them with the same scores which had previously been default, use this: score RCVD_IN_DNSWL_NONE -0.0001 score RCVD_IN_DNSWL_LOW -0.7 score RCVD_IN_DNSWL_MED -2.3 score RCVD_IN_DNSWL_HI -5 It was disabled because it is returning a value triggering RCVD_IN_DNSWL_HI for all queries from DNS servers deemed abusive, causing false negatives in SpamAssassin. It was the only network test, enabled in SpamAssassin by default, intentionally returning known incorrect values under any circumstances. It is recommended that you use a local, caching, non-forwarding DNS server with SpamAssassin: http://wiki.apache.org/spamassassin/CachingNameserver This should prevent you from being considered abusive by DNSWL unless you are actually doing multi-million queries per day, based on the list DNSWL provided yesterday of who is currently categorized as abusive: * Google Public DNS servers (multi-million queries per 24 hours, no response from Google contacts) * Some big hosting provider resolvers: softlayer.com, dimenoc.com, theplanet.com, bluehost.com, dyndns.com, netline.net.uk (multi-million queries per 24 hours, no response/action from abuse@ and similar contacts) * Five single hosts with multi-million queries per 24 hours with no response/action from multiple contacts. Problems have only been occurring when people use the above DNS Servers. Relevant bug (and source of above list): https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6668 -- Begin at the beginning and go on till you come to the end; then stop. - Lewis Carrol, Alice in Wonderland http://www.ChaosReigns.com
Re: DNSWL will be disabled by default as of tomorrow
Thank you! I raised this question a few months ago and was in awe that it was enabled by default. It has caused quite a few issues that i've seen around the ML. They should return a different value than a negative score. Very bad design. -- Jeremy McSpadden Flux Labs, Inc http://www.fluxlabs.nethttp://www.fluxlabs.net/ Endless Solutions Office : 850-588-4626 Cell : 850-890-2543 Fax : 850-254-2955 On Dec 12, 2011, at 11:58 AM, dar...@chaosreigns.commailto:dar...@chaosreigns.com wrote: Tomorrow's sa-update will include disabling of the DNSWL rules. If you wish to locally enable them with the same scores which had previously been default, use this: score RCVD_IN_DNSWL_NONE -0.0001 score RCVD_IN_DNSWL_LOW -0.7 score RCVD_IN_DNSWL_MED -2.3 score RCVD_IN_DNSWL_HI -5 It was disabled because it is returning a value triggering RCVD_IN_DNSWL_HI for all queries from DNS servers deemed abusive, causing false negatives in SpamAssassin. It was the only network test, enabled in SpamAssassin by default, intentionally returning known incorrect values under any circumstances. It is recommended that you use a local, caching, non-forwarding DNS server with SpamAssassin: http://wiki.apache.org/spamassassin/CachingNameserver This should prevent you from being considered abusive by DNSWL unless you are actually doing multi-million queries per day, based on the list DNSWL provided yesterday of who is currently categorized as abusive: * Google Public DNS servers (multi-million queries per 24 hours, no response from Google contacts) * Some big hosting provider resolvers: softlayer.comhttp://softlayer.com, dimenoc.comhttp://dimenoc.com, theplanet.comhttp://theplanet.com, bluehost.comhttp://bluehost.com, dyndns.comhttp://dyndns.com, netline.net.ukhttp://netline.net.uk (multi-million queries per 24 hours, no response/action from abuse@ and similar contacts) * Five single hosts with multi-million queries per 24 hours with no response/action from multiple contacts. Problems have only been occurring when people use the above DNS Servers. Relevant bug (and source of above list): https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6668 -- Begin at the beginning and go on till you come to the end; then stop. - Lewis Carrol, Alice in Wonderland http://www.ChaosReigns.com
Re: DNSWL will be disabled by default as of tomorrow
On 12/12/11 12:03 PM, Jeremy McSpadden jer...@fluxlabs.net wrote: Thank you! I raised this question a few months ago and was in awe that it was enabled by default. It has caused quite a few issues that i've seen around the ML. They should return a different value than a negative score. Can I ask you a fairly blunt question? What action could they have taken that would have caused you to notice that you were engaging in abusive miss-use of their service by continuing to forward your requests through google? I'm quite serious. DNSBLs have this problem of never being able to get rid of the queries from sources that appear to be abusive. What can be done so that a part-time admin will take notice and fix their equipment? A log message? Special header in every e-mail? Change the subject line to you have Spamassassin integrated wrong!? Or a visit from Guido and some of the boys, trying to make an offer you can't refuse? In this case, they moved you to action by causing your customers some grief. That made you look into the issue, get guidance that you really need to run a local recursive caching DNS server in order to get clear answers from DNSBLs, and then I imagine you fixed the problem. How else could they have let you know? -- Daniel J McDonald, CCIE # 2495, CISSP # 78281 Very bad design. On Dec 12, 2011, at 11:58 AM, dar...@chaosreigns.com wrote: Tomorrow's sa-update will include disabling of the DNSWL rules. If you wish to locally enable them with the same scores which had previously been
Re: DNSWL will be disabled by default as of tomorrow
I agree with what you are saying, but to enable a plugin out of the box; with no warning or instructions stating you need to run a local caching dns server in order to use this plugin successfully if your machine is using a dns server that may or may not be used and making millions of queries therefore banned which returns a score that is giving a negative score ... has no justification. (sorry for the run on sentence) -- Jeremy McSpadden Flux Labs, Inc http://www.fluxlabs.nethttp://www.fluxlabs.net/ Endless Solutions Office : 850-588-4626 Cell : 850-890-2543 Fax : 850-254-2955 On Dec 12, 2011, at 12:35 PM, Daniel McDonald wrote: Can I ask you a fairly blunt question? What action could they have taken that would have caused you to notice that you were engaging in abusive miss-use of their service by continuing to forward your requests through google? I'm quite serious. DNSBLs have this problem of never being able to get rid of the queries from sources that appear to be abusive. What can be done so that a part-time admin will take notice and fix their equipment? A log message? Special header in every e-mail? Change the subject line to you have Spamassassin integrated wrong!? Or a visit from Guido and some of the boys, trying to make an offer you can't refuse? In this case, they moved you to action by causing your customers some grief. That made you look into the issue, get guidance that you really need to run a local recursive caching DNS server in order to get clear answers from DNSBLs, and then I imagine you fixed the problem. How else could they have let you know? -- Daniel J McDonald, CCIE # 2495, CISSP # 78281
Re: DNSWL will be disabled by default as of tomorrow
On 12/12/2011 1:35 PM, Daniel McDonald wrote: Can I ask you a fairly blunt question? What action could they have taken that would have caused you to notice that you were engaging in abusive miss-use of their service by continuing to forward your requests through google? I'm quite serious. DNSBLs have this problem of never being able to get rid of the queries from sources that appear to be abusive. What can be done so that a part-time admin will take notice and fix their equipment? A log message? Special header in every e-mail? Change the subject line to you have Spamassassin integrated wrong!? Or a visit from Guido and some of the boys, trying to make an offer you can't refuse? In this case, they moved you to action by causing your customers some grief. That made you look into the issue, get guidance that you really need to run a local recursive caching DNS server in order to get clear answers from DNSBLs, and then I imagine you fixed the problem. How else could they have let you know? There is nothing an RBL admin can do to guarantee access to the admin of a downstream server. The use of DNS is purposefully done to provide a distributed network and purposefully giving wrong answers is DNS poisoning. If you choose to run an RBL, you have to know you might need to blackhole requests from people that don't follow the access rules. Sending an incorrect answer to get someone's attention is akin to firing a few rounds through a window to get the attention of the window cleaner. However, I would love to see RBLs get together and come up with a specific this is a non-answer answer that can be programatically used. However, realize that many RBLs are designed to be implemented in FAR simpler situations than SA that can only deal with yes/no. Regards, KAM
Re: DNSWL will be disabled by default as of tomorrow
I concur 100%. Daniel is wrong. The problem isn't dnswl.org the problem is the person who made the decision in SpamAssassin to have the default for the dnswl plugin ENABLED by default. That decision has been recognized to have been a mistake which is why SA is making an update that will turn it off by default. This is not a blame the user for stupid configuration mistakes problem this is a blame the software developer for a stupid configuration mistake And the software developer has acknowledged it was a mistake. So why people are calling SA users abusive is beyond me. Anyone who produces software understands that the users of the software are not as knowledgeable about whatever it is the software does - in a word, they are ignorant. That is why there are software developers and software users. If the users knew as much as the developer did they could write their own software and they wouldn't need the developers. Thus, the developer has an obligation to be somewhat responsible in not putting in defaults that shoot people in the foot. If those users want to enable things that shoot themselves in the foot that is their affair. The SA developers understand this, I don't see why it's so difficult a concept for others to grasp. Ted On 12/12/2011 10:48 AM, Jeremy McSpadden wrote: I agree with what you are saying, but to enable a plugin out of the box; with no warning or instructions stating you need to run a local caching dns server in order to use this plugin successfully if your machine is using a dns server that may or may not be used and making millions of queries therefore banned which returns a score that is giving a negative score ... has no justification. (sorry for the run on sentence) -- Jeremy McSpadden Flux Labs, Inc http://www.fluxlabs.net http://www.fluxlabs.net/ Endless Solutions *Office*: 850-588-4626 *Cell*: 850-890-2543 *Fax* : 850-254-2955 On Dec 12, 2011, at 12:35 PM, Daniel McDonald wrote: Can I ask you a fairly blunt question? What action could they have taken that would have caused you to notice that you were engaging in abusive miss-use of their service by continuing to forward your requests through google? I'm quite serious. DNSBLs have this problem of never being able to get rid of the queries from sources that appear to be abusive. What can be done so that a part-time admin will take notice and fix their equipment? A log message? Special header in every e-mail? Change the subject line to you have Spamassassin integrated wrong!? Or a visit from Guido and some of the boys, trying to make an offer you can't refuse? In this case, they moved you to action by causing your customers some grief. That made you look into the issue, get guidance that you really need to run a local recursive caching DNS server in order to get clear answers from DNSBLs, and then I imagine you fixed the problem. How else could they have let you know? -- Daniel J McDonald, CCIE # 2495, CISSP # 78281
Re: DNSWL will be disabled by default as of tomorrow
On Mon, 2011-12-12 at 11:50 -0800, Ted Mittelstaedt wrote:
I concur 100%. Daniel is wrong. The problem isn't
dnswl.org the problem is the person who made the decision in
SpamAssassin to have the default for the dnswl plugin ENABLED
Please don't forget that this became an issue only after DNSWL policy
change. At the time the DNSWL rules have been enabled by default in SA,
there where no deliberately false listing responses.
by default. That decision has been recognized to have been a
mistake which is why SA is making an update that will
turn it off by default.
Not a mistake -- but a dangerous rule to ship in the face of the DNSWL
policy change.
This is not a blame the user for stupid configuration mistakes
problem this is a blame the software developer for a stupid
configuration mistake And the software developer has
acknowledged it was a mistake. So why people are calling
SA users abusive is beyond me.
See above, not a mistake.
And I don't see anyone calling the users abusive. But the DNS servers.
Which is causing collateral damage to some users.
--
char *t=\10pse\0r\0dtu\0.@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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: DNSWL will be disabled by default as of tomorrow
On 12/12/2011 12:24 PM, Karsten Bräckelmann wrote: On Mon, 2011-12-12 at 11:50 -0800, Ted Mittelstaedt wrote: I concur 100%. Daniel is wrong. The problem isn't dnswl.org the problem is the person who made the decision in SpamAssassin to have the default for the dnswl plugin ENABLED Please don't forget that this became an issue only after DNSWL policy change. At the time the DNSWL rules have been enabled by default in SA, there where no deliberately false listing responses. Not to belabor the point but according to the Internet Archive this DNSWL policy change happened in October 2010, that is when the website was changed. SA 3.3.2 shipped June 2011 so it seems that there should have been sufficient time to change the default. by default. That decision has been recognized to have been a mistake which is why SA is making an update that will turn it off by default. Not a mistake -- but a dangerous rule to ship in the face of the DNSWL policy change. SA users have been burned several times in the past by blacklist providers who decided for whatever reason they were going to stop offering service, and started handing out positive entries for every query. on defaults for any outside providers simply aren't appropriate, and the SA developers should have known this by now as a result of that happening. Normally I would be the last person to defend DNSWL as I deplore the FUD reasoning that they use - the claim that the existence of IPv6 will make blacklists obsolete is a flat out lie, all that is needed to be done is for a BL query plugin to parse the incoming IP address and see if it's in the /64 or /56, rather than do an exact match. I also deplore this offer it free until people are dependent on it then charge the crap out of the commercial providers who you have snared business model. And I detest this guilty until your prove yourself innocent by seeking our blessing rubbish. So I had to really stretch to write what I wrote, as I would love to blame DNSWL for it but in this case, they really are blameless. This is not a blame the user for stupid configuration mistakes problem this is a blame the software developer for a stupid configuration mistake And the software developer has acknowledged it was a mistake. So why people are calling SA users abusive is beyond me. See above, not a mistake. And I don't see anyone calling the users abusive. But the DNS servers. Which is causing collateral damage to some users. This is a mailing list mainly for SA administrators, users of SA in this context are the administrators that install it, not the end users using SA-enabled mailservers. And DNS servers don't just query for no reason. Ted
Re: DNSWL will be disabled by default as of tomorrow
On 12/12/11 19:50, Ted Mittelstaedt wrote: I concur 100%. Daniel is wrong. The problem isn't dnswl.org the problem is the person who made the decision in SpamAssassin to have the default for the dnswl plugin ENABLED by default. That decision has been recognized to have been a mistake which is why SA is making an update that will turn it off by default. This is not a blame the user for stupid configuration mistakes problem this is a blame the software developer for a stupid configuration mistake And the software developer has acknowledged it was a mistake. So why people are calling SA users abusive is beyond me. Anyone who produces software understands that the users of the software are not as knowledgeable about whatever it is the software does - in a word, they are ignorant. That is why there are software developers and software users. If the users knew as much as the developer did they could write their own software and they wouldn't need the developers. Thus, the developer has an obligation to be somewhat responsible in not putting in defaults that shoot people in the foot. If those users want to enable things that shoot themselves in the foot that is their affair. The SA developers understand this, I don't see why it's so difficult a concept for others to grasp. Ted So does this mean SA should disable ALL network based tests by default as they all have the same potential to return false positives/negatives to get the attention of (abusive) sysadmins? About the only difference is dnswl.org got to hit folks with a -5 score whereas most others would have significantly less scoring impact available, but the potential threat is the same. I can understand the decision if dnswl.org have requested SA disable lookups by default, but otherwise it's a last resort attempt to get the attention of someone after all other reasonable efforts to communicate the issue have failed. I personally don't think it unreasonable. Either way, I appreciate the heads up here so we (SA users) may make the decision whether or not to re-enable dnswl.org on our own setups.
Re: DNSWL will be disabled by default as of tomorrow
So does this mean SA should disable ALL network based tests by default as they all have the same potential to return false positives/negatives to get the attention of (abusive) sysadmins? About the only difference is dnswl.org got to hit folks with a -5 score whereas most others would have significantly less scoring impact available, but the potential threat is the same. In the past, the RBL errors I can think of were less RBL policy and more RBLs going under where things such as registrars took over DNS and returned answers for every query. However, the stability of an RBL and their infrastructure is a major concern for the SA project to consider an RBL for inclusion for just these type of reasons. There is a lot of debate concerning RBLs, their impact and their inclusion in SA. I can understand the decision if dnswl.org have requested SA disable lookups by default, but otherwise it's a last resort attempt to get the attention of someone after all other reasonable efforts to communicate the issue have failed. I personally don't think it unreasonable. Either way, I appreciate the heads up here so we (SA users) may make the decision whether or not to re-enable dnswl.org on our own setups. As an aside, DNSWL most likely disagrees with disabling the rules by default in SA. However, it was an SA decision to do so in light of complaints of the rule misfiring on purpose due to over-quota policies for DNSWL. Regards, KAM
Re: DNSWL will be disabled by default as of tomorrow
On Mon, 2011-12-12 at 13:01 -0800, Ted Mittelstaedt wrote:
On 12/12/2011 12:24 PM, Karsten Bräckelmann wrote:
Please don't forget that this became an issue only after DNSWL policy
change. At the time the DNSWL rules have been enabled by default in SA,
there where no deliberately false listing responses.
Not to belabor the point but according to the Internet Archive this
DNSWL policy change happened in October 2010, that is when the
website was changed.
Back in Oct 2010 the policy has been changed, introducing the free usage
limits and a subscription offer. However, the policy was enforced by
blocking requests of abusive hosts only. Harmless, and will not result
in FPs.
The policy change we're discussing -- serving FP listings to excessive
over-limit abusers -- was established just recently, Oct 17, 2011.
If you want to see for yourself, please have a look at the DNSWL news,
linked from their main site.
SA 3.3.2 shipped June 2011 so it seems that there should have been
sufficient time to change the default.
See above, off by one year.
While the team arguably didn't react appropriately to the initial
heads-up by Darxus just a few weeks ago, I stand to what I said.
And I don't see anyone calling the users abusive. But the DNS servers.
Which is causing collateral damage to some users.
This is a mailing list mainly for SA administrators, users of SA in
this context are the administrators that install it, not the end users
I did not say, neither imply anything else. With no word did I refer to
end-users or clients -- frankly, in context the interpretation of
users as users of SA, people running the product is the only one
that makes sense. And is generally to be assumed in this place anyway.
But thanks for stating the obvious.
using SA-enabled mailservers. And DNS servers don't just query for
no reason.
DNS servers don't query for no reason, but because the admin chose to
use it.
Again, I stand to what I said. I have not seen anyone blaming users.
--
char *t=\10pse\0r\0dtu\0.@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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: error on SA learning.
Obviously intended for the list, rather than me only.
On Sun, 2011-12-11 at 12:52 -0600, Sergio wrote:
Thank you all, I have fixed it.
It was certainly an error in NetAddr-IP.
Sergio
2011/12/11 Karsten Bräckelmann guent...@rudersport.de
On Sun, 2011-12-11 at 07:16 -0600, Sergio wrote:
netset: cannot include 0:0:0:0:0:0:0:1/128 as it has already been
included
Bug 6681. Certain NetAddr-IP Perl module versions are broken, avoid
versions 4.045 to 4.054.
--
char *t=\10pse\0r\0dtu\0.@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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: DNSWL will be disabled by default as of tomorrow
On 2011/12/12 14:35, Karsten Bräckelmann wrote:
On Mon, 2011-12-12 at 13:01 -0800, Ted Mittelstaedt wrote:
On 12/12/2011 12:24 PM, Karsten Bräckelmann wrote:
Please don't forget that this became an issue only after DNSWL policy
change. At the time the DNSWL rules have been enabled by default in SA,
there where no deliberately false listing responses.
Not to belabor the point but according to the Internet Archive this
DNSWL policy change happened in October 2010, that is when the
website was changed.
Back in Oct 2010 the policy has been changed, introducing the free usage
limits and a subscription offer. However, the policy was enforced by
blocking requests of abusive hosts only. Harmless, and will not result
in FPs.
The policy change we're discussing -- serving FP listings to excessive
over-limit abusers -- was established just recently, Oct 17, 2011.
If you want to see for yourself, please have a look at the DNSWL news,
linked from their main site.
SA 3.3.2 shipped June 2011 so it seems that there should have been
sufficient time to change the default.
See above, off by one year.
While the team arguably didn't react appropriately to the initial
heads-up by Darxus just a few weeks ago, I stand to what I said.
And I don't see anyone calling the users abusive. But the DNS servers.
Which is causing collateral damage to some users.
This is a mailing list mainly for SA administrators, users of SA in
this context are the administrators that install it, not the end users
I did not say, neither imply anything else. With no word did I refer to
end-users or clients -- frankly, in context the interpretation of
users as users of SA, people running the product is the only one
that makes sense. And is generally to be assumed in this place anyway.
But thanks for stating the obvious.
using SA-enabled mailservers. And DNS servers don't just query for
no reason.
DNS servers don't query for no reason, but because the admin chose to
use it.
Again, I stand to what I said. I have not seen anyone blaming users.
Hm, their limit is 100,000 queries. LKML can probably account for about
that many queries per month for one user. Add in Fedora and spam and I am
pretty sure two users could overrun their limits.
{^_^}
Re: DNSWL will be disabled by default as of tomorrow
On Mon, 2011-12-12 at 15:42 -0800, jdow wrote:
Hm, their limit is 100,000 queries. LKML can probably account for about
that many queries per month for one user. Add in Fedora and spam and I am
pretty sure two users could overrun their limits.
100,000 queries per *day*, not month.
Plus, using a *caching* DNS server, no matter how much mail the LKML
list-server emits a day, it's just a few queries to the DNSWL mirrors.
And guess what, the second subscriber does not add any additional
queries.
*sigh*
--
char *t=\10pse\0r\0dtu\0.@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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: DNSWL will be disabled by default as of tomorrow
On 12/12/2011 2:35 PM, Karsten Bräckelmann wrote: On Mon, 2011-12-12 at 13:01 -0800, Ted Mittelstaedt wrote: On 12/12/2011 12:24 PM, Karsten Bräckelmann wrote: Please don't forget that this became an issue only after DNSWL policy change. At the time the DNSWL rules have been enabled by default in SA, there where no deliberately false listing responses. Not to belabor the point but according to the Internet Archive this DNSWL policy change happened in October 2010, that is when the website was changed. Back in Oct 2010 the policy has been changed, introducing the free usage limits and a subscription offer. However, the policy was enforced by blocking requests of abusive hosts only. Harmless, and will not result in FPs. The policy change we're discussing -- serving FP listings to excessive over-limit abusers -- was established just recently, Oct 17, 2011. If you want to see for yourself, please have a look at the DNSWL news, linked from their main site. The text regarding high-use queries appeared on the website in October 2010. Whether or not it's enforced by serving FP's to excessive users is beside the point - high-query users lost the right to use DNS as soon as that text appeared. In other words the behavior of the whitelist at that time changed from everyone use us, please, commercial or otherwise, the same way to some of you use us this way and others use us that way Knowing that SA was being used by both groups which the whitelist was expecting different behavior from should have been enough to turn off access to that list in the default config of SA. it's no different than MAPS access -OK for some, not OK for others, that too is defaulted to off. The serving FPs is tangential. It has the action of forcing behavior in SA that a year earlier would have been the sensible thing to do. Ted SA 3.3.2 shipped June 2011 so it seems that there should have been sufficient time to change the default. See above, off by one year. While the team arguably didn't react appropriately to the initial heads-up by Darxus just a few weeks ago, I stand to what I said. And I don't see anyone calling the users abusive. But the DNS servers. Which is causing collateral damage to some users. This is a mailing list mainly for SA administrators, users of SA in this context are the administrators that install it, not the end users I did not say, neither imply anything else. With no word did I refer to end-users or clients -- frankly, in context the interpretation of users as users of SA, people running the product is the only one that makes sense. And is generally to be assumed in this place anyway. But thanks for stating the obvious. using SA-enabled mailservers. And DNS servers don't just query for no reason. DNS servers don't query for no reason, but because the admin chose to use it. Again, I stand to what I said. I have not seen anyone blaming users.
Re: DNSWL will be disabled by default as of tomorrow
On Mon, 2011-12-12 at 16:04 -0800, Ted Mittelstaedt wrote:
The text regarding high-use queries appeared on the website in
October 2010. Whether or not it's enforced by serving FP's to
excessive users is beside the point -
No, it is not. It is precisely the point, and the reason for disabling
DNSWL by default.
high-query users lost the right to use DNS as soon as that text
appeared. In other words the behavior of the whitelist at that
time changed from everyone use us, please, commercial or
otherwise, the same way to some of you use us this way and others use
us that way Knowing that SA was being used by both groups which
the whitelist was expecting different behavior from should have been
enough to turn off access to that list in the default config of SA.
No. SA should be usable out-of-the-box with best possible performance
for the majority of users.
Plus, sites processing way above 100,000 messages a day do have the
admin power and knowledge to take care of these. The majority of smaller
sites does not.
The serving FPs is tangential.
Again, no. It is the very reason to pull DNSWL by default. It is the
core of the decision.
--
char *t=\10pse\0r\0dtu\0.@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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: DNSWL will be disabled by default as of tomorrow
On Mon, 12 Dec 2011 18:48:07 +, Jeremy McSpadden wrote: I agree with what you are saying, but to enable a plugin out of the box; with no warning or instructions stating you need to run a local caching dns server in order to use this plugin successfully if your machine is using a dns server that may or may not be used and making millions of queries therefore banned which returns a score that is giving a negative score ... has no justification. its the same for all dnsbl/dnswl, admins need to know what to do ? make another bugreport on bugzilla ?
Re: DNSWL will be disabled by default as of tomorrow
On 12/12/2011 4:27 PM, Karsten Bräckelmann wrote: On Mon, 2011-12-12 at 16:04 -0800, Ted Mittelstaedt wrote: The text regarding high-use queries appeared on the website in October 2010. Whether or not it's enforced by serving FP's to excessive users is beside the point - No, it is not. It is precisely the point, and the reason for disabling DNSWL by default. high-query users lost the right to use DNS as soon as that text appeared. In other words the behavior of the whitelist at that time changed from everyone use us, please, commercial or otherwise, the same way to some of you use us this way and others use us that way Knowing that SA was being used by both groups which the whitelist was expecting different behavior from should have been enough to turn off access to that list in the default config of SA. No. SA should be usable out-of-the-box with best possible performance for the majority of users. Plus, sites processing way above 100,000 messages a day do have the admin power and knowledge to take care of these. The majority of smaller sites does not. The serving FPs is tangential. Again, no. It is the very reason to pull DNSWL by default. It is the core of the decision. then why is DNSWL the only one that had access turned on by default originally? Ted
Re: DNSWL will be disabled by default as of tomorrow
On 12/12/2011 4:02 PM, Karsten Bräckelmann wrote: On Mon, 2011-12-12 at 15:42 -0800, jdow wrote: Hm, their limit is 100,000 queries. LKML can probably account for about that many queries per month for one user. Add in Fedora and spam and I am pretty sure two users could overrun their limits. 100,000 queries per *day*, not month. Plus, using a *caching* DNS server, no matter how much mail the LKML list-server emits a day, it's just a few queries to the DNSWL mirrors. And guess what, the second subscriber does not add any additional queries. *sigh* Most likely 90% of the ISPs and corporations out there who wanted to use the DNSWL and did this would experience no problems. But the text on the website is extremely hand-wavy. They state you must purchase a subscription if your selling anti-spam services. This is pretty unambiguous. They also state if you do more than 100,000 queries per day on the public nameservers you must purchase a subscription, this is also pretty unambiguous. But what is ambiguous is that they state that non-commercial use is OK, but they don't state that commercial use must require a subscription, and they don't define commercial or non-commercial use. So if I run a profit making ISP that offers spam-filtering as a free ad-on, I am not selling anti-spam services - or am it? Since the free add-on is a value-add, even though I may say it's free in the marketing, in truth I really am selling anti-spam services. And if I'm a commercial company with 200 employees and I run my own caching nameserver then what? I'm not non-commercial so my use isn't non-commercial. The TOS is basically structured so that the maintainers can pick and choose what users need to be designated as need to get money from and what users don't. And the more explicit TOS here: http://www.dnswl.org/license is no less ambiguous. It defines users then talks about commercial vendors of dnswl data - but commercial vendors of dnswl data isn't defined precisely and the implication overlaps the more precise definition of user. Now yeah I've been around and I get what they are driving at, I think most people reading do. But our I get what they are driving at has absolutely no legal weight and this is my problem with the DNSWL, it's why I don't use it. feeping creaturism comes to mind here. They suck you in for free and once your dependent on them they yank the rug out and change terms then want money. I hate when companies do that. I have a whole library of software programs that are versions released just prior to the commercial version. (and of course exist on no archive site today) and now the service providers are playing that game. When Unisys started charging for the GIF patent it triggered the abandonment of GIF and replacement by PNG and just about the time that this was completed the GIF patent expired, making PNG pointless except as a statement by the community along the lines of what you did is so unforgivable we are going to spend thousands of hours making sure your patent is gonna be screwed But it's OK for list providers to play this game, eh? Just not Unisys? Ted
Re: DNSWL will be disabled by default as of tomorrow
On Mon, 2011-12-12 at 16:39 -0800, Ted Mittelstaedt wrote:
Most likely 90% of the ISPs and corporations out there who wanted
to use the DNSWL and did this would experience no problems.
But the text on the website is extremely hand-wavy.
[...]
Now we seriously moved off-topic...
--
char *t=\10pse\0r\0dtu\0.@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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: DNSWL will be disabled by default as of tomorrow
But it's OK for list providers to play this game, eh? Just not Unisys? This is a discussion better suited to DNSWL's mailing lists than SA as we've disabled the rules. Overall, though, DNSWL has been good members of the anti-spam community and have supported running their tests for a long time. So I'm not going to give them a ton of grief because they haven't dotted every i or crossed every t. If you don't like the terms of the list provider, don't use them. It's pretty simple. regards, KAM
Re: DNSWL will be disabled by default as of tomorrow
On Mon, 12 Dec 2011 21:24:12 +0100, Karsten Bräckelmann wrote: And I don't see anyone calling the users abusive. But the DNS servers. Which is causing collateral damage to some users. and there is other dnseval rules that could make false possitive on shared dns servers aswell, might be time to enable dnssec ? :=)
Re: DNSWL will be disabled by default as of tomorrow
On Mon, 2011-12-12 at 16:37 -0800, Ted Mittelstaedt wrote:
then why is DNSWL the only one that had access turned on by default
originally?
Sorry, I don't understand what you're asking or referring to.
But then again, we're getting quite off-topic. And frankly, all this
arguing is mildly annoying. Might as well move on, and do something more
productive.
--
char *t=\10pse\0r\0dtu\0.@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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: DNSWL will be disabled by default as of tomorrow
On Mon, 12 Dec 2011 19:49:58 -0500, Kevin A. McGrail wrote: If you don't like the terms of the list provider, don't use them. It's pretty simple. make the bug report invalid / wont-fix then ? i dont get it :/
Re: DNSWL will be disabled by default as of tomorrow
On 12/12/2011 8:22 PM, Benny Pedersen wrote: On Mon, 12 Dec 2011 19:49:58 -0500, Kevin A. McGrail wrote: If you don't like the terms of the list provider, don't use them. It's pretty simple. make the bug report invalid / wont-fix then ? i dont get it :/ What bug are you talking about? For DNSWL, 6718 is a dupe and 6668 is considered resolved with the changing of the DNSWL scores to 0 which will be effective in the next sa-update.
Fwd: DNSWL will be disabled by default as of tomorrow
(Public apologies to Karste, wrote him instead of the list, mmm... I need to remember to write to the list and not just do a Reply.) What is the best way to dissable DNSWL manually? (in case I don't want to wait until tomorrow) Regards, Sergio
Re: Fwd: DNSWL will be disabled by default as of tomorrow
On 12/12/2011 8:35 PM, Sergio wrote: (in case I don't want to wait until tomorrow) What is the best way to dissable DNSWL manually? Add this to your local.cf and reload spamd (if you use that): score RCVD_IN_DNSWL_NONE 0 score RCVD_IN_DNSWL_LOW 0 score RCVD_IN_DNSWL_MED 0 score RCVD_IN_DNSWL_HI 0 regards, KAM
Re: DNSWL will be disabled by default as of tomorrow
On Mon, 12 Dec 2011 20:29:07 -0500, Kevin A. McGrail wrote: For DNSWL, 6718 is a dupe and 6668 is considered resolved with the changing of the DNSWL scores to 0 which will be effective in the next sa-update. DNSWL is scaned in deep received, but none have reporteed this :( dont know if others dns whitelists do this in default :( #6718 should have being resolved wont-fix #6668 agree on comment #1, the rest is just fuss imho
Re: DNSWL will be disabled by default as of tomorrow
On 12/12/2011 8:58 PM, Benny Pedersen wrote: On Mon, 12 Dec 2011 20:29:07 -0500, Kevin A. McGrail wrote: For DNSWL, 6718 is a dupe and 6668 is considered resolved with the changing of the DNSWL scores to 0 which will be effective in the next sa-update. DNSWL is scaned in deep received, but none have reporteed this :( DNSWL for SA is implemented with first-trusted on all the tests in SA I found. I don't see any deep-header parsing. #6718 should have being resolved wont-fix No, it was a duplicate complaint. Marking it a duplicate was accurate IMO. #6668 agree on comment #1, the rest is just fuss imho As I wrote comment 1, I have to agree it was brilliant ;-) regards, KAM
Re: DNSWL will be disabled by default as of tomorrow
On Mon, 12 Dec 2011 21:12:56 -0500, Kevin A. McGrail wrote: DNSWL is scaned in deep received, but none have reporteed this :( DNSWL for SA is implemented with first-trusted on all the tests in SA I found. I don't see any deep-header parsing. if its was we all need to use trusted_networks even more, its firstuntrusted, not first hop ;/ whitelists should be fitsthop only, no ? #6718 should have being resolved wont-fix No, it was a duplicate complaint. Marking it a duplicate was accurate IMO. spamassassin is not a book of howto setup dns servers or is it now ? #6668 agree on comment #1, the rest is just fuss imho As I wrote comment 1, I have to agree it was brilliant ;-) atleast some have humor in this month :-)
Re: Fwd: DNSWL will be disabled by default as of tomorrow
On Mon, 2011-12-12 at 20:37 -0500, Kevin A. McGrail wrote:
On 12/12/2011 8:35 PM, Sergio wrote:
(in case I don't want to wait until tomorrow)
What is the best way to dissable DNSWL manually?
Add this to your local.cf and reload spamd (if you use that):
score RCVD_IN_DNSWL_NONE 0
score RCVD_IN_DNSWL_LOW 0
score RCVD_IN_DNSWL_MED 0
score RCVD_IN_DNSWL_HI 0
Oh, hello there, pet-peeve! You, too, forgot to eliminate the actual DNS
querying rule.
While the above works as advertised to disable the rules, preventing it
from FP hits, it does not prevent the DNS queries. For that, you got to
meta out the non-scoring sub-rule all of those above depend on.
Canonical instructions.
Identify your system's default configuration directory. A brave 'man
spamassassin' is your friend. Go there.
Grep for the DNSBL rules (or better yet, a brief sub-pattern) you want
to disable. Ignore the noise like score and description, and identify
the actual (sub-)rules.
Score the rules you want to disable with 0. AND meta out their sub-rule
dependencies, to actually get rid of the DNS queries.
meta __DNSBL_FOO 0
Do NOT do that where you found the rules, but in your site-specific conf
dir. The mysterious thingy commonly referred to as 'local.cf'.
Just in case other rules might depend on the rules you want to disable
(again, a brave grep is your friend), also meta'ing out the rules in
question instead of scoring it zero is the better approach. No warnings
about dependencies with zero score.
Rules with a zero score are disabled, as a side-effect. Using meta rules
with a logical 0 is the exact definition of *disabling* a rule. By
overwriting whatever the rule does, with a you will never be true
logic evaluation of 0.
--
char *t=\10pse\0r\0dtu\0.@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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: DNSWL will be disabled by default as of tomorrow
On Tue, 2011-12-13 at 03:25 +0100, Benny Pedersen wrote:
On Mon, 12 Dec 2011 21:12:56 -0500, Kevin A. McGrail wrote:
DNSWL is scaned in deep received, but none have reporteed this :(
No, it is not. Never was.
DNSWL for SA is implemented with first-trusted on all the tests in SA
I found. I don't see any deep-header parsing.
Yep.
if its was we all need to use trusted_networks even more, its
firstuntrusted, not first hop ;/
whitelists should be fitsthop only, no ?
First *hop*? No. That's commonly some sender internal machine in the
case of spam. And a no-brainer to forge for spam.
#6718 should have being resolved wont-fix
No, it was a duplicate complaint. Marking it a duplicate was
accurate IMO.
Indeed. A duplicate. No question at all.
spamassassin is not a book of howto setup dns servers or is it now ?
Correct, it isn't. But it greatly benefits, and in quite some cases
requires setting one up.
Well, and an SMTP server or other glue software. SA ain't a book of
howto setup those either, is it? AKA, once again, I cannot follow you,
Benny. ;)
I highly welcome everyone to pay attention to the Subject. Then, after
writing whatever one feels to vent, and *before* sending, to carefully
and consciously re-read the Subject again.
--
char *t=\10pse\0r\0dtu\0.@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;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: DNSWL will be disabled by default as of tomorrow
On 12/12/2011 5:27 PM, Karsten Bräckelmann wrote: No. SA should be usable out-of-the-box with best possible performance for the majority of users. Perhaps a better long-term solution would be to validate DNS lists before using them? One possible implementation would be to test to ensure that 127.0.0.1 is not listed, and 127.0.0.2 is listed (with the testing criteria being configurable, but this is a starting point that will work for most lists). If a list is down or unresponsive for any reason, discards requests or blanks their zone file, the test entry would fail and SA would know to not use the list. Similarly, 127.0.0.1 should never be listed for any DNSBL that I'm aware of, and so when a list moves to a list-the-world configuration, this entry would spot it. -- Dave Warren, CEO Hire A Hit Consulting Services http://ca.linkedin.com/in/davejwarren
Re: Using ZMI_GERMAN ruleset
On Montag, 31. Oktober 2011 Axb wrote: tried it and dumped due to low hit rate stuff like body ZMIde_JOBSEARCH6 /Dank sehr grossen Angagement, aber auch der Umsetzung verschiedener Inovationen, konnte unsere Firma schon nach vier Jahren auf die internationalen Ebene hinaufsteigen/ is not efficient Its efficient in terms of filtering only spam with zero false positives, which is top priority for this ruleset. And you picked a very old and very long rule. Most rules nowadays are just one or even only part of a sentence, and it prooves very efficient. Stuff like the __ZMIde_JOBEARN1-28 rules move false positives to 0, and I'm constantly adding stuff. I've now tried to remove all old cruft, that means single-line rules. Rulesize went from 350KB to 296KB, that should save some RAM and CPU. -- mit freundlichen Grüssen, Michael Monnerie, Ing. BSc it-management Internet Services: Protéger http://proteger.at [gesprochen: Prot-e-schee] Tel: +43 660 / 415 6531 signature.asc Description: This is a digitally signed message part.
