On Thu, 15 Dec 2011 11:14:18 +1000
Noel Butler wrote:
> On Wed, 2011-12-14 at 11:58 +0100, Matus UHLAR - fantomas wrote:
>
> > I wonder why SA disables DNWSL rules, with this logic blacklists,
> > not whitelists, should be disabled...
> >
>
>
> Personally, I think all whitelists should be dis
Personally, I think all whitelists should be disabled by default (I
disabled all whitelists as of some years ago, and occasionally check
to see no new ones has cropped up).
That way is someone wants to allow others to decide who they can trust
(always a bad idea IMHO, trust to each networks
On Wed, 2011-12-14 at 11:58 +0100, Matus UHLAR - fantomas wrote:
> On 12.12.11 12:58, 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:
> >
> >
On Wed, 14 Dec 2011 10:18:52 -0500, Kevin A. McGrail wrote:
Not quite. We are working on return codes that lead to the end the
purposefully wrong answers for DNSBLs so Blocked doesn't mean
blackholing the requests. Confusing, I know.
yes, its a hell out there in dns world, rbldnsd only suppor
On 12/14/2011 2:11 PM, Sergio wrote:
Thank you Kam.
You are welcome.
And as pointed out by others:
score __RCVD_IN_DNSWL 0
might also be needed to actually stop the query.
However, DNSWL and SA have been working to implement some rules that let
admins know they are blocked without misfirin
Thank you Kam.
Regards,
Sergio
On Mon, Dec 12, 2011 at 7:37 PM, 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 th
On 12/14/2011 4:24 AM, Benny Pedersen wrote:
On Tue, 13 Dec 2011 09:21:47 -0500, David F. Skoll wrote:
I think we need an informational RFC that specifies best-practices for
a DNS{B,W}L to inform clients that they have been blocked.
good intention, but if dns is blocket there is no result anyw
On Wed, 14 Dec 2011 10:24:47 +0100
Benny Pedersen wrote:
> good intention, but if dns is blocket there is no result anyway so it
> does not work
If DNS is completely blocked, then there's not much harm done. If a DNSBL
returns a hit for any query, then there's a lot of harm done and there shou
On 12.12.11 12:58, 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
On Tue, 13 Dec 2011 09:21:47 -0500, David F. Skoll wrote:
I think we need an informational RFC that specifies best-practices
for
a DNS{B,W}L to inform clients that they have been blocked.
good intention, but if dns is blocket there is no result anyway so it
does not work
On Tue, 2011-12-13 at 15:33 -0500, David F. Skoll wrote:
> I think something like this would be good:
>
> $ tar xvfz Mail-SpamAssassin-xxx.tar.gz
> $ cd Mail-SpamAssassin-xxx
> $ perl Makefile.PL
> [...]
>
> The following RBLs have certain usage restrictions. Would you like to
> enable them? If
On Tue, 13 Dec 2011 15:24:34 -0500
dar...@chaosreigns.com wrote:
> If you can come up with a way to disable all network tests that have
> a free use limit without crippling spamassassin, please tell us.
> That would be lovely.
I think something like this would be good:
$ tar xvfz Mail-SpamAssass
On 12/13, Kevin A. McGrail wrote:
> Is there a formal policy for including (or excluding) DNS-based lists
whats
>There is formal consensus from the PMC that ^ work^ for most installations
> is
>adequate for default inclusion once the mer
On 12/13/2011 2:00 PM, David F. Skoll wrote:
Hi,
Is there a formal policy for including (or excluding) DNS-based lists
from SpamAssassin's default rules? I think that SpamAssassin should
not enable any DNS-based list by default unless the list owners have a
clear policy that the list is free to
Hi,
Is there a formal policy for including (or excluding) DNS-based lists
from SpamAssassin's default rules? I think that SpamAssassin should
not enable any DNS-based list by default unless the list owners have a
clear policy that the list is free to use by SpamAssassin users,
regardless of query
I don't think there really needs to be consensus. I've yet to see one
that blocks 127.0.0.1, and they all have some sort of test address
(usually 127.0.0.x)
Given that the worst that happens if this system fails is that SA
stops using the list until sa-update updates the check rule, as long
On 12/13/2011 10:37 AM, Kevin A. McGrail wrote:
This system would result in one query per BL per SA restart, or per
ruleset reload or per hour or whatever, rather than one or more
queries per processed message. That's a step forward to DNSBL
operators, but more importantly, it would avoid the
This system would result in one query per BL per SA restart, or per
ruleset reload or per hour or whatever, rather than one or more
queries per processed message. That's a step forward to DNSBL
operators, but more importantly, it would avoid the situation where
users are negatively impacted b
On 12/13/2011 5:44 AM, Kevin A. McGrail wrote:
On 12/13/2011 2:19 AM, Dave Warren wrote:
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
On 12/13/2011 9:21 AM, David F. Skoll wrote:
I think we need an informational RFC that specifies best-practices for
a DNS{B,W}L to inform clients that they have been blocked.
For example, a testpoint like:
blocked.dnsbl.example.org
could return an A record for name servers that are blocke
On Tue, 13 Dec 2011 14:09:19 +
Martin Gregorie wrote:
> At the risk of exposing my ignorance, I had a thought.
>
> Since the entire 127/8 is reserved for loopback, nothing in the
> 127.0.0/24 block should be used as addresses. So, what is preventing
> RBLs and RWLs from using the third octe
On 2011-12-13 15:21, David F. Skoll wrote:
I think we need an informational RFC that specifies best-practices for
a DNS{B,W}L to inform clients that they have been blocked.
For example, a testpoint like:
blocked.dnsbl.example.org
could return an A record for name servers that are blocked
I think we need an informational RFC that specifies best-practices for
a DNS{B,W}L to inform clients that they have been blocked.
For example, a testpoint like:
blocked.dnsbl.example.org
could return an A record for name servers that are blocked and NXDOMAIN
for others. This might even work
On Tue, 13 Dec 2011, Kevin A. McGrail wrote:
On 12/13/2011 2:19 AM, Dave Warren wrote:
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
Similarly, 127.0.0.1 should nev
On Tue, Dec 13, 2011 at 3:00 PM, Michael Scheidell
wrote:
> [..] Blocking the ip address by firewall
> will save bandwidth and cpu cycles.
Firewalling will have the same effect as returning no answer - it will
cause retries and thus will roughly triple the amount of queries
received (although th
On 12/13/11 8:09 AM, "Martin Gregorie" wrote:
> On Tue, 2011-12-13 at 13:52 +0100, Axb wrote:
>> On 2011-12-13 13:44, Kevin A. McGrail wrote:
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
On Tue, 2011-12-13 at 13:52 +0100, Axb wrote:
> On 2011-12-13 13:44, Kevin A. McGrail wrote:
> >> 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 nev
On 12/13/11 7:44 AM, Kevin A. McGrail wrote:
Blocking seems to be the only thing that really achieves the goal
they want beyond conversion to paying customers which is not SA's issue.
I agree with Kevin.
A while back, I published an 'example' blocking list,
'blocked.secnap.net' (wildcard e
On 2011-12-13 13:44, Kevin A. McGrail wrote:
On 12/13/2011 2:19 AM, Dave Warren wrote:
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 DN
On 12/13/2011 2:19 AM, Dave Warren wrote:
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 imp
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
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
> >
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
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 ev
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 no
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
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_H
(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: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 D
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 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 anno
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
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
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
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.
1
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 i
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 t
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 disabl
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.
The "ok for most users" is acceptable for us to make a rule enabled by
default. I'm sure there are other cases such as SpamHaus, I believe.
However, i
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 defaul
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, usin
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 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 fals
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 si
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
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 do
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 D
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
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. DNSB
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 t
On 12/12/11 12:03 PM, "Jeremy McSpadden" 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 fa
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.net
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 disable
63 matches
Mail list logo
