You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by da...@chaosreigns.com on 2011/12/12 18:58:05 UTC
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
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
> 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 must be earned, not
> given based on third party advice, and most definitely never ever
> bought), so they must explicitly allow it.
>
While not specific to whitelists, I believe this idea is covered in:
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6729
regards,
KAM
Re: DNSWL will be disabled by default as of tomorrow
Posted by RW <rw...@googlemail.com>.
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 disabled by default (I
> disabled all whitelists as of some years ago, and occasionally check
> to see no new ones has cropped up).
Personally I've never had a significant problem with whitelists. I
suspect that much of the perceived problem is with end-users who
carelessly sign-up to opt-in marketing, and with admins who think: if
it looks like it could be spam, it is.
> That way is someone wants to allow others to decide who they can trust
> (always a bad idea IMHO, trust to each networks must be earned,
It's earned based on the QA that the SA project does. If a list is
working less well for you, then the best thing to do is adjust the
score, report the problem, and if possible contribute to SA's QA.
Based on your previously reported impossibly low FP rate, you clearly
have no idea what the effect of turning-off these lists is.
Re: DNSWL will be disabled by default as of tomorrow
Posted by Noel Butler <no...@ausics.net>.
On Wed, 2011-12-14 at 11:58 +0100, Matus UHLAR - fantomas wrote:
> On 12.12.11 12:58, darxus@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.
>
> well, same thing hapened with some blacklists in the past, which
> resulted to high number of FP's.
>
> While FNs mean (much/all) mail not to be detected, FP's are uch worse.
>
> I wonder why SA disables DNWSL rules, with this logic blacklists, not
> whitelists, should be disabled...
>
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 must be earned, not
given based on third party advice, and most definitely never ever
bought), so they must explicitly allow it.
Question about why we blocked DNSWL
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
> well, same thing hapened with some blacklists in the past, which
> resulted to high number of FP's.
>
> While FNs mean (much/all) mail not to be detected, FP's are uch worse.
>
> I wonder why SA disables DNWSL rules, with this logic blacklists, not
> whitelists, should be disabled...
>
The logic is that we do not publish rules that knowingly produce errant
scores. Whether those scores are positive or negative has little impact
on that policy.
DNSWL is working to reduce/eliminate that issue which I am very happy about.
Re: DNSWL will be disabled by default as of tomorrow
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
On 12.12.11 12:58, darxus@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.
well, same thing hapened with some blacklists in the past, which
resulted to high number of FP's.
While FNs mean (much/all) mail not to be detected, FP's are uch worse.
I wonder why SA disables DNWSL rules, with this logic blacklists, not
whitelists, should be disabled...
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"One World. One Web. One Program." - Microsoft promotional advertisement
"Ein Volk, ein Reich, ein Fuhrer!" - Adolf Hitler
Re: DNSWL will be disabled by default as of tomorrow
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
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: DNS list inclusion policy (was Re: DNSWL will be disabled by
default as of tomorrow)
Posted by Martin Gregorie <ma...@gregorie.org>.
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 unsure, say Y. (Y/N): [Y]
> [... a list of RBLs, preferably with links to their policy pages ...]
>
> so that at installation time, SA users are at least aware of the issues.
>
The only problem with this that I can see is, unfortunately, a biggish
one: it won't work for the package installs that I and, at a guess, a
lot of small installations use. I run the Fedora distro, and so the
version of SA I'm running is that installed and periodically updated by
yum.
I like the idea of the tool though, particularly if it can link to
descriptions of each RBL and, hopefully, to the masscheck results for
it. From my POV a post-install tool, and especially one that can be
re-run periodically, would be a lot more useful.
Martin
Re: DNS list inclusion policy (was Re: DNSWL will be disabled by
default as of tomorrow)
Posted by "David F. Skoll" <df...@roaringpenguin.com>.
On Tue, 13 Dec 2011 15:24:34 -0500
darxus@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-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 unsure, say Y. (Y/N): [Y]
[... a list of RBLs, preferably with links to their policy pages ...]
so that at installation time, SA users are at least aware of the issues.
For package maintainers, you'd want a noninteractive way to build SpamAssassin
and then a post-install configuration script that asks the RBL question.
(This is easily done on Debian; not so easy with RPM-based systems that
don't allow interaction during installation.)
Regards,
David.
Re: DNS list inclusion policy (was Re: DNSWL will be disabled by
default as of tomorrow)
Posted by da...@chaosreigns.com.
On 12/13, Kevin A. McGrail wrote:
> Is there a formal policy for including (or excluding) DNS-based lists
what s
> There is formal consensus from the PMC that ^ work^ for most installations is
> adequate for default inclusion once the merits of the BL are shown
I wanted to point out the logic behind this. SpamAssassin is heavily
dependent on network tests for accuracy. Disabling them results in
something like 5 times as many emails mis-classified, both false positives
and false negatives (with the default threshold of 5).
So the default configuration is set up to need minimal adjustment for small
installations likely to have the least ability to do those adjustments, and
require more adjustment for very large installations which are inevitably
going to need to change stuff anyway.
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.
And I do think it's appropriate to discuss this in terms of all network
tests, not just DNS tests.
These are the statistics from... 2009. Would be nice to get newer ones.
Why aren't these updated?
Set 0, no net, no bayes:
http://svn.apache.org/viewvc/spamassassin/trunk/rules/STATISTICS-set0.txt?view=markup
# False positives: 238 1.12%
# False negatives: 9678 21.93%
Set 1, with net, no bayes:
http://svn.apache.org/viewvc/spamassassin/trunk/rules/STATISTICS-set1.txt?view=markup
# False positives: 30 0.14%
# False negatives: 1381 3.13%
Without the network tests, it got 7.9x as many spams wrong, and 7.0x as
many hams wrong.
(Opened bug for those files being out of
date, I think the data gets generated daily:
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6726 )
--
"I love God. He's so deliciously evil." - Stewie Griffin, Family Guy 2x02
http://www.ChaosReigns.com
Re: DNSWL will be disabled by default as of tomorrow
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
> 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
> as the test IPs can be configured on a per-DNSBL basis, there
> shouldn't really be a problem.
>
> * DNSBL includes DNSWLs, domain based lists, etc... All we need is a
> "this entry should cause a result" and "this entry should not",
> whether it's positive or negative, an IP or domain, etc, shouldn't
> matter.
You're welcome to give it a whirl to come up with code to do the testing
but doing it on start-up is likely bound to have lots of problems with
servers rebooting that don't have net access yet, etc.
As I put on the bug, I think the best solution will be something that
internally monitors for block rules and if triggered, stops queries to
those BLs for an hour. Then it can try again. Your idea might be
better and I'm having forest for the trees vision.
regards,
KAM
Re: DNS list inclusion policy (was Re: DNSWL will be disabled by
default as of tomorrow)
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
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 use by SpamAssassin users,
> regardless of query volume [*], commercial vs. non-commercial use,
> etc. and a promise not to change the policy without reasonable (say,
> six months) notice.
>
> I realize this means practically no DNS lists will qualify to be
> enabled by default. I believe SA should ship all the rules for
> various DNS lists and have clear instructions (maybe even a tool for
> newbies that runs automatically from the makefile) to enable them.
> But I'm not sure it should serve as a marketing tool for DNSBL
> operators who want to charge money.
>
> (/me dons flame-proof suit...)
>
> Regards,
>
> David.
>
> [*] DNSBLs that force you to use a (free) rsync service if your query volume
> is too high are OK.
You are a brave person!
There is formal consensus from the PMC that work for most installations
is adequate for default inclusion once the merits of the BL are shown
combined with discussion if the infrastructure can withstand the query
onslaught.
Beyond that, we have the "new" issue of responding with purposefully
wrong answers which is a no-no for default inclusion. However, this
issue is NOT new. This issue was discussed by the PMC when URIBL was
being considered for inclusion:
"NOTE: URIBL fails with false positives once a threshold is exceeded.
This will not be acceptable for a default enabled SA test." and the
response: UPDATE FROM DALLAS: We don't return positive to anymore. We
moved our heavy hitter blocking
to the top level, so blocked users will timeout trying to reach our
mirrors.".
But consensus for the PMC is clear, that free for some licensing with
query volumes being acceptable.
From my notes, a daily limit and ok for non-commercial use has been
acceptable to SA to consider for default enabling. Of course, we've had
a LOT of discussions on this matter and Spamhaus, for example, changed
their query and SMTP limits based on discussions with SA.
So I know we try and be fair but flexible so we are not closed to new
BLs. I also personally try and support BLs by offering nameserver
resources.
In the end, your idea of an easier way for admins to review rules/BL for
inclusion/removal has good merit. I've had similar ideas with at least
making a list of rules that are disabled for these type of reasons more
in the forefront. The biggest con I can see is that rules and releases
are purposefully separated. If masscheck could be augmented, having
LOTS of different sa-update channels might be a good idea but that won't
enable the plugins.
Now what's more interesting is that I took on the crazy idea of writing
a policy for RBL inclusion. Let me formalize my notes and see if I can
post something today about that. It'll be really for the PMC to decide
but user/dev/rbl operator input is always good.
Regards,
KAM
DNS list inclusion policy (was Re: DNSWL will be disabled by
default as of tomorrow)
Posted by "David F. Skoll" <df...@roaringpenguin.com>.
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 volume [*], commercial vs. non-commercial use,
etc. and a promise not to change the policy without reasonable (say,
six months) notice.
I realize this means practically no DNS lists will qualify to be
enabled by default. I believe SA should ship all the rules for
various DNS lists and have clear instructions (maybe even a tool for
newbies that runs automatically from the makefile) to enable them.
But I'm not sure it should serve as a marketing tool for DNSBL
operators who want to charge money.
(/me dons flame-proof suit...)
Regards,
David.
[*] DNSBLs that force you to use a (free) rsync service if your query volume
is too high are OK.
Re: DNSWL will be disabled by default as of tomorrow
Posted by Dave Warren <li...@hireahit.com>.
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 situation where
>> users are negatively impacted by BL failures.
> Definitely on the same page. My thoughts are to build on the block
> notification rules to implement code that blocks the DNSBL queries for
> 1 hour. However, that's kind of a phase II. And since I doubt there
> will be consensus from DNSBL operators, it'll really be a one off
> thing per DNSBL to implement unless some alignment of planets occurs
> that I doubt is even in motion ;-)
>
> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6724
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 as the
test IPs can be configured on a per-DNSBL basis, there shouldn't really
be a problem.
* DNSBL includes DNSWLs, domain based lists, etc... All we need is a
"this entry should cause a result" and "this entry should not", whether
it's positive or negative, an IP or domain, etc, shouldn't matter.
--
Dave Warren, CEO
Hire A Hit Consulting Services
http://ca.linkedin.com/in/davejwarren
Re: DNSWL will be disabled by default as of tomorrow
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
> 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 by BL failures.
Definitely on the same page. My thoughts are to build on the block
notification rules to implement code that blocks the DNSBL queries for 1
hour. However, that's kind of a phase II. And since I doubt there will
be consensus from DNSBL operators, it'll really be a one off thing per
DNSBL to implement unless some alignment of planets occurs that I doubt
is even in motion ;-)
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6724
Regards,
KAM
Re: DNSWL will be disabled by default as of tomorrow
Posted by Dave Warren <li...@hireahit.com>.
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 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.
>>
> Unfortunately, 1 is a bitwise answer I've seen it used. In fact, just
> checking real quick, I've got an RBL that uses 1 on a live server now.
>
> # Last octet of A record is a bitmask:
> # x & 1 => greylist
> # x & 2 => dirty
> # x & 4 => spammer
> # x & 8 => good
>
> IMO, unfortunately again there is no standard to RBL responses though
> I think that multi/combined lists could define an octet that is a
> blocked answer combine with a simple rule.
Sorry, I might not have been entirely clear. I'm suggesting we create a
SpamAssassin syntax to say "This IP must be listed" and "This IP must
not be listed", both of which must be true for a DNSBL to service. The
specific IPs selected are just for example purposes and can be tweaked
on a per-list basis based on the list's design.
Depending on how difficult this would be to implement within
SpamAssassin, you could write the test rule such that it supplies an IP
to be tested, a SA rule name and a required score (so that, for example,
you could test bit-based lists)
If I DNSBL operator cannot publish an IP that will always be listed and
an IP that will never be listed, they simply wouldn't be candidates for
implementation in SpamAssassin; since virtually all DNSBLs have some
sort of test IPs, this probably won't be a big deal.
The point is that I'm not suggesting we herd cats and require every
DNSBL to agree upon test addresses, but rather, that we go through on a
blocklist-by-blocklist basis and use their existing test addresses.
> If the RBL is using a combined bitwise solution, that's a solution
> that would work in the existing rule structure on multiple SA platforms.
>
> Hopefully, they can also give a high TTL on the blocked query answer
> so caching is more effective but at the end of the day, this still
> means querys are coming in. So what has the RBL operator gained?
> 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.
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 by BL failures.
--
Dave Warren, CEO
Hire A Hit Consulting Services
http://ca.linkedin.com/in/davejwarren
Re: DNS{B,W}Ls and blocking (was Re: DNSWL will be disabled by default
as of tomorrow)
Posted by Axb <ax...@gmail.com>.
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 and NXDOMAIN
> for others. This might even work out-of-the-box for some existing lists
> that return an A record for any query (or it may not, if they expect
> a reverse-dotted-quad.)
>
> It could even return a TXT record giving the reason for the block.
>
> Anyway, assuming this idea is widely-accepted (hahaha!), it would be pretty
> easy to make something that periodically tests your list of DNSBLs and
> disables those that are blocking your query.
there is a BCP for BLs floating around which addresses some if not all
of this... MAAWF, RFC.. not sure which
Re: DNS{B,W}Ls and blocking (was Re: DNSWL will be disabled by default
as of tomorrow)
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
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 blocked and NXDOMAIN
> for others. This might even work out-of-the-box for some existing lists
> that return an A record for any query (or it may not, if they expect
> a reverse-dotted-quad.)
>
> It could even return a TXT record giving the reason for the block.
>
> Anyway, assuming this idea is widely-accepted (hahaha!), it would be pretty
> easy to make something that periodically tests your list of DNSBLs and
> disables those that are blocking your query.
This was mentioned as a possibility and it's a good idea.
But from SA's perspective, though, it means that it requires code. And
the big issue is NOT the delays. The big issue is the purposefully wrong
answers.
The code-requirement for a fix means that this new policy is delayed at
least 6 months after a major release for SA based on
http://wiki.apache.org/spamassassin/ReleaseGoals. So if we miss this
code getting into 3.4.0, that means it waits until 3.5.0 (or 4.0.0) + 6
months. If someone wants to submit code to actually do it, that'd be
great. But it's a got a delay before it matters either way.
I've opened a ticket
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6724 towards an
immediate solution.
regards,
KAM
Re: DNS{B,W}Ls and blocking (was Re: DNSWL will be disabled by
default as of tomorrow)
Posted by "David F. Skoll" <df...@roaringpenguin.com>.
On Wed, 14 Dec 2011 10:24:47 +0100
Benny Pedersen <me...@junc.org> 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 should
be a way to let a client know.
Regards,
David.
Re: DNS{B,W}Ls and blocking (was Re: DNSWL will be disabled by
default as of tomorrow)
Posted by Benny Pedersen <me...@junc.org>.
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 support udp while
bind required udp/tcp on top of that some severs still blackhole my ipv4
address in there dns servers, if that does not get better i will simply
disable DNSEval plugin in future
sorbs still use rbldnsd as front end servers :(
who can send me a named.conf that ONLY do queryes with udp ?
might be more simple just disable DNSEval :(
and now today my asus eee 1001ha does not boot windows xp, super that i
still have another asus eee that works, eee PC 2G Surf (512M mem, 2048M
harddisk, win xp)
it host freenas very well on that hardware
>
> Regards,
> KAM
Re: DNS{B,W}Ls and blocking (was Re: DNSWL will be disabled by default
as of tomorrow)
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
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 anyway so it
> does not work
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.
Regards,
KAM
Re: DNS{B,W}Ls and blocking (was Re: DNSWL will be disabled by
default as of tomorrow)
Posted by Benny Pedersen <me...@junc.org>.
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
DNS{B,W}Ls and blocking (was Re: DNSWL will be disabled by default
as of tomorrow)
Posted by "David F. Skoll" <df...@roaringpenguin.com>.
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 out-of-the-box for some existing lists
that return an A record for any query (or it may not, if they expect
a reverse-dotted-quad.)
It could even return a TXT record giving the reason for the block.
Anyway, assuming this idea is widely-accepted (hahaha!), it would be pretty
easy to make something that periodically tests your list of DNSBLs and
disables those that are blocking your query.
Regards,
David.
Re: DNSWL will be disabled by default as of tomorrow
Posted by Matthias Leisi <ma...@leisi.net>.
On Tue, Dec 13, 2011 at 3:00 PM, Michael Scheidell
<mi...@secnap.com> 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 they will effectively be discarded at a different
stage, firewall vs nameserver).
This effect was also reported in
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6048#c23
> google's attention, will it? and you still get the bandwidth and cpu cycles
> from the largest abusers.
For the few cases where it is being used, it reduced the load by an
order of a magnitude (eg netline.net.uk going from > 12 mio queries/24
hours to below 1 mio - still way too high, but definitely an
improvement).
-- Matthias
Re: DNSWL will be disabled by default as of tomorrow
Posted by Michael Scheidell <mi...@secnap.com>.
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 entry for ipv4 :-). Guess what? it was
added to a couple of perl dnsbl modules and used by people who never
looked at what it was!
Two things happened:
#1, lots of (hundreds of thousands of queries per day) from one or two
unnamed large ISP's
#2, calls from 'internet lawyers' demanding that we remove them from the
list. (we emailed them the bind zone and told them to identify their ip
address and we would gladly remove it).
Also, emailing or calling 'abusers' doesn't work.
Kevin and I both run two of three sa-update mirror servers, and we have
seen several 'ill configured' servers that try to pull the same
sa-update every 5 mins forever.
I had our night shift guys track down and send the admins a friendly
note, mentioning that they aren't getting the updates anyway, so why not
fix it?
No response, no change in activity (note: this might be due to one of
the distro's not being able to store and check pgp keys if they are in
the /tmp directory, a proposed SA bugzilla starts to address this, but
these queries are for older versions of SA)
And/or full /tmp filesystems, etc. We never did figure it out, but if
anyone wants a list of the top 10 ip's, they can email me offlist.
Now, I disagree TOTALLY on setting the 'abuser's dns queries to return
FP on DNSWL_HIGH, this serves no purpose. Blocking the ip address by
firewall will save bandwidth and cpu cycles. returning FP on HIGH won't
ever get google's attention, will it? and you still get the bandwidth
and cpu cycles from the largest abusers.
> Regards,
> KAM
--
Michael Scheidell, CTO
o: 561-999-5000
d: 561-948-2259
>*| *SECNAP Network Security Corporation
* Best Mobile Solutions Product of 2011
* Best Intrusion Prevention Product
* Hot Company Finalist 2011
* Best Email Security Product
* Certified SNORT Integrator
______________________________________________________________________
This email has been scanned and certified safe by SpammerTrap(r).
For Information please see http://www.spammertrap.com/
______________________________________________________________________
Re: DNSWL will be disabled by default as of tomorrow
Posted by John Hardin <jh...@impsec.org>.
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 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.
>
> Unfortunately, 1 is a bitwise answer I've seen it used. In fact, just
> checking real quick, I've got an RBL that uses 1 on a live server now.
Let's rephrase: querying 127.0.0.1 should never return a positive answer.
Returning 127.0.0.1 as an answer is not a problem.
This seems to me to be a reasonable test. If the BL returns a hit, and if
it hasn't been validated in the last X hours, then query 127.0.0.1 and see
if the list returns a positive. If so, discard the hit and suppress
querying the list for the next Y hours.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
North Korea: the only country in the world where people would risk
execution to flee to communist China. -- Ride Fast
-----------------------------------------------------------------------
2 days until Bill of Rights day
Re: DNSWL will be disabled by default as of tomorrow
Posted by RW <rw...@googlemail.com>.
On Tue, 13 Dec 2011 14:09:19 +0000
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 octet as a status indicator? It
> seems to me that the 4th octet can be used as at present as a query
> response which would by convention be a valid response if the 3rd
> octet is zero. OTOH if the 3rd octet was non-zero, this would
> indicate that the response is invalid, so this could provide an
> unambiguous way for the various RBLs and WLs to tell individual users
> to go away if they exceeded use limits, had an expired subscription,
> etc.
In DNSWL the 3rd octet contains a code for the type of business.
They could define an invalid code in the last octet if they wanted to,
but presumably they want people to notice if they are over quota.
Re: DNSWL will be disabled by default as of tomorrow
Posted by Daniel McDonald <da...@austinenergy.com>.
On 12/13/11 8:09 AM, "Martin Gregorie" <ma...@gregorie.org> 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
>>>> 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.
>>>>
>>> Unfortunately, 1 is a bitwise answer I've seen it used. In fact, just
>>> checking real quick, I've got an RBL that uses 1 on a live server now.
>>
> 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 octet as a status indicator? It seems
> to me that the 4th octet can be used as at present as a query response
> which would by convention be a valid response if the 3rd octet is zero.
I have in the past seen at least one DNSBL that used the 3rd octet, as they
had more than 8 lists in a multi-configuration. I don't recall which one it
was...
--
Daniel J McDonald, CCIE # 2495, CISSP # 78281
Re: DNSWL will be disabled by default as of tomorrow
Posted by Martin Gregorie <ma...@gregorie.org>.
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 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.
> >>
> > Unfortunately, 1 is a bitwise answer I've seen it used. In fact, just
> > checking real quick, I've got an RBL that uses 1 on a live server now.
>
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 octet as a status indicator? It seems
to me that the 4th octet can be used as at present as a query response
which would by convention be a valid response if the 3rd octet is zero.
OTOH if the 3rd octet was non-zero, this would indicate that the
response is invalid, so this could provide an unambiguous way for the
various RBLs and WLs to tell individual users to go away if they
exceeded use limits, had an expired subscription, etc.
This seems such an obvious solution that it must have been thought of in
the past and rejected for some reason I don't understand. What did I
miss?
Martin
> well, that BL would have to change - no big deal (we know who that is :)
>
> >
> > # Last octet of A record is a bitmask:
> > # x & 1 => greylist
> > # x & 2 => dirty
> > # x & 4 => spammer
> > # x & 8 => good
> >
> > IMO, unfortunately again there is no standard to RBL responses though I
> > think that multi/combined lists could define an octet that is a blocked
> > answer combine with a simple rule.
> >
> > Then they just need to be publishing a combined list to do that and not
> > use the other octets (i.e. return the bitwise for blocked only or at
> > least no purposefully incorrect answers). The score on the rule that
> > acknowledges a block should be minimal and the message on the rule would
> > have to link to a generic page on SA's wiki regarding "free for some"
> > services. It should NOT lead to a subscription page for a vendor. We are
> > not an advertising service.
> >
> > If the RBL is using a combined bitwise solution, that's a solution that
> > would work in the existing rule structure on multiple SA platforms.
> >
> > Hopefully, they can also give a high TTL on the blocked query answer so
> > caching is more effective but at the end of the day, this still means
> > querys are coming in. So what has the RBL operator gained? 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.
>
> been talking to SF about possibilities.... he has some interesting ideas
> (I'm not 100% sold on them, but he makes sense) - stay tuned.
>
Re: DNSWL will be disabled by default as of tomorrow
Posted by Axb <ax...@gmail.com>.
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 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.
>>
> Unfortunately, 1 is a bitwise answer I've seen it used. In fact, just
> checking real quick, I've got an RBL that uses 1 on a live server now.
well, that BL would have to change - no big deal (we know who that is :)
>
> # Last octet of A record is a bitmask:
> # x & 1 => greylist
> # x & 2 => dirty
> # x & 4 => spammer
> # x & 8 => good
>
> IMO, unfortunately again there is no standard to RBL responses though I
> think that multi/combined lists could define an octet that is a blocked
> answer combine with a simple rule.
>
> Then they just need to be publishing a combined list to do that and not
> use the other octets (i.e. return the bitwise for blocked only or at
> least no purposefully incorrect answers). The score on the rule that
> acknowledges a block should be minimal and the message on the rule would
> have to link to a generic page on SA's wiki regarding "free for some"
> services. It should NOT lead to a subscription page for a vendor. We are
> not an advertising service.
>
> If the RBL is using a combined bitwise solution, that's a solution that
> would work in the existing rule structure on multiple SA platforms.
>
> Hopefully, they can also give a high TTL on the blocked query answer so
> caching is more effective but at the end of the day, this still means
> querys are coming in. So what has the RBL operator gained? 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.
been talking to SF about possibilities.... he has some interesting ideas
(I'm not 100% sold on them, but he makes sense) - stay tuned.
Re: DNSWL will be disabled by default as of tomorrow
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
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 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.
>
Unfortunately, 1 is a bitwise answer I've seen it used. In fact, just
checking real quick, I've got an RBL that uses 1 on a live server now.
# Last octet of A record is a bitmask:
# x & 1 => greylist
# x & 2 => dirty
# x & 4 => spammer
# x & 8 => good
IMO, unfortunately again there is no standard to RBL responses though I
think that multi/combined lists could define an octet that is a blocked
answer combine with a simple rule.
Then they just need to be publishing a combined list to do that and not
use the other octets (i.e. return the bitwise for blocked only or at
least no purposefully incorrect answers). The score on the rule that
acknowledges a block should be minimal and the message on the rule would
have to link to a generic page on SA's wiki regarding "free for some"
services. It should NOT lead to a subscription page for a vendor. We
are not an advertising service.
If the RBL is using a combined bitwise solution, that's a solution that
would work in the existing rule structure on multiple SA platforms.
Hopefully, they can also give a high TTL on the blocked query answer so
caching is more effective but at the end of the day, this still means
querys are coming in. So what has the RBL operator gained? 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.
Regards,
KAM
Re: DNSWL will be disabled by default as of tomorrow
Posted by Dave Warren <li...@hireahit.com>.
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: DNSWL will be disabled by default as of tomorrow
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
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;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (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
Posted by Ted Mittelstaedt <te...@ipinc.net>.
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
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
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;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (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
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
> 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, it was the modification to their implementation that returned
responses that caused rules to misfire that caused the change on our end.
Regards,
KAM
Re: DNSWL will be disabled by default as of tomorrow
Posted by Ted Mittelstaedt <te...@ipinc.net>.
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
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
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;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (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
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
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;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (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
Posted by Benny Pedersen <me...@junc.org>.
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: DNSWL will be disabled by default as of tomorrow
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
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
Posted by Benny Pedersen <me...@junc.org>.
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
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
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.
Re: DNSWL will be disabled by default as of tomorrow
Posted by Benny Pedersen <me...@junc.org>.
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
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
> 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
Posted by Ted Mittelstaedt <te...@ipinc.net>.
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
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
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;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (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
Posted by jdow <jd...@earthlink.net>.
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: Fwd: DNSWL will be disabled by default as of tomorrow
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
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 misfiring rules that materially
affect the emails score. This is in bug 6724.
This weekend, we expect DNSWL to implement the changes needed from SA's
perspective to allow us re-enable DNSWL by default.
Regards,
KAM
> On Mon, Dec 12, 2011 at 7:37 PM, Kevin A. McGrail <KMcGrail@pccc.com
> <ma...@pccc.com>> 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 <http://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: Fwd: DNSWL will be disabled by default as of tomorrow
Posted by Sergio <se...@gmail.com>.
Thank you Kam.
Regards,
Sergio
On Mon, Dec 12, 2011 at 7:37 PM, Kevin A. McGrail <KM...@pccc.com> 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
>
> regards,
> KAM
>
>
Re: Fwd: DNSWL will be disabled by default as of tomorrow
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
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;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Fwd: DNSWL will be disabled by default as of tomorrow
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
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
Fwd: DNSWL will be disabled by default as of tomorrow
Posted by Sergio <se...@gmail.com>.
(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: DNSWL will be disabled by default as of tomorrow
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
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;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (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
Posted by Ted Mittelstaedt <te...@ipinc.net>.
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
Posted by Benny Pedersen <me...@junc.org>.
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
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
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;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (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
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
> 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
Posted by Ned Slider <ne...@unixmail.co.uk>.
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
Posted by Ted Mittelstaedt <te...@ipinc.net>.
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
Posted by Benny Pedersen <me...@junc.org>.
On Mon, 12 Dec 2011 18:48:07 +0000, 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
Posted by Jeremy McSpadden <je...@fluxlabs.net>.
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
Posted by Daniel McDonald <da...@austinenergy.com>.
On 12/12/11 12:03 PM, "Jeremy McSpadden" <je...@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, <da...@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
Posted by Jeremy McSpadden <je...@fluxlabs.net>.
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<http://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, <da...@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.com<http://softlayer.com>, dimenoc.com<http://dimenoc.com>,
theplanet.com<http://theplanet.com>, bluehost.com<http://bluehost.com>, dyndns.com<http://dyndns.com>, netline.net.uk<http://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