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 :
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
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
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
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 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
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.
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
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
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
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
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
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
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:
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
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
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
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
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
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
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.
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
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
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
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
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 :/
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
(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
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
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
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
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
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
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
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
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/
36 matches
Mail list logo
