On Tue, Oct 11, 2022 at 11:52:17AM +0200, Matus UHLAR - fantomas wrote:
> > On Sat, Oct 01, 2022 at 04:42:09PM +0200, Matus UHLAR - fantomas wrote:
> > > perhaps these all should replace _DKIMDOMAIN_ by _AUTHORDOMAIN_ and
> > > AND-ed
> > > with DKIM_VALID_AU.
> > >
> > > can these checks be mad
On Sat, Oct 01, 2022 at 04:42:09PM +0200, Matus UHLAR - fantomas wrote:
perhaps these all should replace _DKIMDOMAIN_ by _AUTHORDOMAIN_ and AND-ed
with DKIM_VALID_AU.
can these checks be made the way DNS queries are done only when
DKIM_VALID_AU matches?
perhaps playing with priority
On 07.10
On Fri, Oct 07, 2022 at 04:41:57PM +0300, Henrik K wrote:
> It's not possible to use priority with askdns. The rule is launched then
> the all dependent tags are set, nothing more, nothing less.
... obvious typo but just to clarify, _when_ all tags are set..
On Sat, Oct 01, 2022 at 04:42:09PM +0200, Matus UHLAR - fantomas wrote:
>
> perhaps these all should replace _DKIMDOMAIN_ by _AUTHORDOMAIN_ and AND-ed
> with DKIM_VALID_AU.
>
> can these checks be made the way DNS queries are done only when
> DKIM_VALID_AU matches?
>
> perhaps playing with prio
Hello,
just bumping this if anyone has idea how to process DKIMWL and spamhaus DWL
in more efficient matter.
On 01.10.22 16:42, Matus UHLAR - fantomas wrote:
askdns LOCAL_DNSWL_IN_DWL _DKIMDOMAIN_.dwl.dnswl.org TXT
On 30.09.22 20:57, Matus UHLAR - fantomas wrote:
I'm not sure it should be
askdns LOCAL_DNSWL_IN_DWL _DKIMDOMAIN_.dwl.dnswl.org TXT
On 30.09.22 20:57, Matus UHLAR - fantomas wrote:
I'm not sure it should be done with _DKIMDOMAIN_, it's described to
contain all valid signatures:
_DKIMDOMAIN_
Signing Domain Identifier (SDID) (the 'd' tag) from valid signa
On 30.09.22 19:15, Benny Pedersen wrote:
Matus UHLAR - fantomas skrev den 2022-09-30 18:53:
On 30.09.22 18:04, Benny Pedersen wrote:
ifplugin Mail::SpamAssassin::Plugin::DKIM
ifplugin Mail::SpamAssassin::Plugin::AskDNS
askdns LOCAL_DNSWL_IN_DWL _DKIMDOMAIN_.dwl.dnswl.org TXT
desc
://gitlab.isc.org/isc-projects/bind9/-/issues/3331 is this a
problem with spamassassin ?
asked on dnswl irc for missing _ on dwl where answer just was that it
would not be needed, so far so good, but what abour other domain
blacklists ?
On 30.09.22 18:04, Benny Pedersen wrote:
ifplugin Mail::SpamAssassin::Plugin::DKIM
ifplugin Mail::SpamAssassin::Plugin::AskDNS
askdns LOCAL_DNSWL_IN_DWL _DKIMDOMAIN_.dwl.dnswl.org TXT
describe LOCAL_DNSWL_IN_DWL domain is dnswlisted in dnswl.org
score LOCAL_DNSWL_IN_DWL -
ifplugin Mail::SpamAssassin::Plugin::DKIM
ifplugin Mail::SpamAssassin::Plugin::AskDNS
askdns LOCAL_DNSWL_IN_DWL _DKIMDOMAIN_.dwl.dnswl.org TXT
describe LOCAL_DNSWL_IN_DWL domain is dnswlisted in dnswl.org
score LOCAL_DNSWL_IN_DWL -1 -1 -1 -1
endif # Mail::SpamAs
On 2021-04-12 03:11 AM, Matthias Leisi wrote:
> -2.0 RCVD_IN_DNSWL_HI RBL: Sender listed at
> https://www.dnswl.org/,
> high trust
> [203.160.71.180 listed in list.dnswl.org [1]] I looked up this, and the other
> one, and didn't find them in dnswl. As
> others
>> -2.0 RCVD_IN_DNSWL_HI RBL: Sender listed at
>> https://www.dnswl.org/,
>>high trust
>>[203.160.71.180 listed in list.dnswl.org]
> I looked up this, and the other one, and didn't find them in dnswl
rule name description
> --
> --
> -2.0 RCVD_IN_DNSWL_HI RBL: Sender listed at
> https://www.dnswl.org/,
> high trust
> [203.160.71.180 listed in list.dnswl.org]
I looked up this, and the other one
On 10 Apr 2021, at 12:55, Steve Dondley wrote:
You should fix URIBL_BLOCKED first.
You need a local, caching, non-forwarding DNS server for
SpamAssassin.
Yeah, setting up a DNS server for SA is on my todo list. Thanks.
When you say local, it doesn't have to be on the same machine as
spamass
On 2021-04-10 17:51, Steve Dondley wrote:
I have been looking at this issue a little more. I just grepped my
spam folder. Out of 1000 emails I have flagged as spam, 321 have been
flagged with RCVD_DNSWL_HI, a rule which adds -5 points to the eamil.
That's almost 1 out of 3 emails which seems pret
On 2021-04-10 17:36, Steve Dondley wrote:
Is anyone else seeing spam getting flagged with RCVD_DNSWL_HI
resulting in so many false positives?
report this ip to dnswl with content as provding evedence, you know
admins from dnswl.org here recently asked for this ?
You should fix URIBL_BLOCKED first.
You need a local, caching, non-forwarding DNS server for SpamAssassin.
Yeah, setting up a DNS server for SA is on my todo list. Thanks.
When you say local, it doesn't have to be on the same machine as
spamassassin, does it? I assume I can have the DNS ser
It would be helpful to post an entire actual set of headers --
unmodified -- along with the spamassassin -t report. I can't figure
out (from what you posted) the IP address of the server that was in
DNSWL_HI that delivered mail to your internal/trusted network.
OK, here is the entire output
On 10 Apr 2021, at 12:19, Steve Dondley wrote:
On 2021-04-10 12:10 PM, Greg Troxel wrote:
Steve Dondley writes:
Here are the headers from some egregious spam. It scored a whopping
20.8 point despite being flagged with "RCVD_IN_DNSWL_HI."
Return-Path:
Delivered-To: s...@example.com
Received
Steve Dondley writes:
> On 2021-04-10 12:10 PM, Greg Troxel wrote:
>> Steve Dondley writes:
>>
>>> Here are the headers from some egregious spam. It scored a whopping
>>> 20.8 point despite being flagged with "RCVD_IN_DNSWL_HI."
>>>
>>> Return-Path:
>>> Delivered-To: s...@example.com
>>> Recei
D_IN_SBL_CSS,
> RCVD_IN_VALIDITY_RPBL,RCVD_IN_XBL,***RDNS_NONE***,SPF_HELO_SOFTFAIL,
> [...]
DNSWL does not list any IP addresses without Reverse DNS (PTR), that
also matches with the forward DNS ( see the markings above ! ).
- So maybe you should look at your set up, instead of continuing your
game of claimi
re are too few e-mail headers there, and it looks like the mail was
submitted from your machine.
We even don't see the IP that's supposed to be in dnswl.
So my advice again is:
Run spamassassin -t on the message so you see the metadata about the
rules like which IP hit and the pe
-Version: 1.0
> Content-Type: multipart/mixed; boundary="--=_606E9920.15B94EAE"
> Message-Id: <20210408054816.cdd3d21...@email.example.com>
>
You should fix URIBL_BLOCKED first.
You need a local, caching, non-forwarding DNS server for SpamAssassin.
I haven't noticed much of any spam hitting DNSWL HI. I suspect you
have some other configuration issue.
-jeff
On 2021-04-10 12:10 PM, Greg Troxel wrote:
Steve Dondley writes:
Here are the headers from some egregious spam. It scored a whopping
20.8 point despite being flagged with "RCVD_IN_DNSWL_HI."
Return-Path:
Delivered-To: s...@example.com
Received: from email.example.com
by email.example
Steve Dondley writes:
> Here are the headers from some egregious spam. It scored a whopping
> 20.8 point despite being flagged with "RCVD_IN_DNSWL_HI."
>
> Return-Path:
> Delivered-To: s...@example.com
> Received: from email.example.com
> by email.example.com with LMTP
> id AnV2NSCZ
I have been looking at this issue a little more. I just grepped my
spam folder. Out of 1000 emails I have flagged as spam, 321 have been
flagged with RCVD_DNSWL_HI, a rule which adds -5 points to the eamil.
That's almost 1 out of 3 emails which seems pretty insane.
Here are the headers from s
On 2021-04-06 11:48 AM, Steve Dondley wrote:
I have emails that have been flagged as spam in the past but that are
still getting through, presumably because the servers are on some
DNSWL.
Example:
X-Spam-Status: No, score=0.9 required=5.0 tests=BAYES_99,BAYES_999,
DATE_IN_PAST_03_06
RW writes:
> On Tue, 06 Apr 2021 12:03:52 -0400
> Greg Troxel wrote:
>
>
>> You can and probably should report spam to dnswl. In theory HI should
>> have essentially no spam.
>
> I thought that because I've never received a single spam with it, but in
>
On Tue, 06 Apr 2021 12:03:52 -0400
Greg Troxel wrote:
> You can and probably should report spam to dnswl. In theory HI should
> have essentially no spam.
I thought that because I've never received a single spam with it, but in
mass checks it's at 0.23% of spam.
Den 06-04-2021 kl. 19:23 skrev Bill Cole:
> Because DNSWL has problematic sources,
Depending on the eyes looking at it, for NONE, maybe true? - "These are
legitimate mail servers, but they may also emit spam or have other
issues from time to time."
But there shouldn
On 2021-04-06 21:12, Arne Jensen wrote:
Den 06-04-2021 kl. 17:48 skrev Steve Dondley:
I have emails that have been flagged as spam in the past but that are
still getting through, presumably because the servers are on some
DNSWL.
Example:
X-Spam-Status: No, score=0.9 required=5.0 tests
Den 06-04-2021 kl. 17:48 skrev Steve Dondley:
> I have emails that have been flagged as spam in the past but that are
> still getting through, presumably because the servers are on some DNSWL.
>
> Example:
>
> X-Spam-Status: No, score=0.9 required=5.0 tests=
On 6 Apr 2021, at 11:48, Steve Dondley wrote:
I have emails that have been flagged as spam in the past but that are
still getting through, presumably because the servers are on some
DNSWL.
Example:
X-Spam-Status: No, score=0.9 required=5.0 tests=BAYES_99,BAYES_999,
DATE_IN_PAST_03_06
Steve Dondley writes:
> I have emails that have been flagged as spam in the past but that are
> still getting through, presumably because the servers are on some
> DNSWL.
>
> Example:
>
> X-Spam-Status: No, score=0.9 required=5.0 tests=BAYES_99,BAYES_999,
> DATE_I
I have emails that have been flagged as spam in the past but that are
still getting through, presumably because the servers are on some DNSWL.
Example:
X-Spam-Status: No, score=0.9 required=5.0 tests=BAYES_99,BAYES_999,
DATE_IN_PAST_03_06,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU
/pastebin.com/5LYS7s2v>
IP 163.231.6.26, mailout2-trp.thomsonreuters.com
<http://mailout2-trp.thomsonreuters.com/>, DNSWL Id 1251.
No abuse reports on this IP yet (overall for this DNSWL Id: one back in October
2014, two in April 2014, and four in 2012 - all but the October 2014 com
Hello Reindl,
Monday, May 11, 2015, 2:57:57 PM, you wrote:
RH> complain at dnswl.org
Don't complain, report it and the listing will then be reviewed
--
Best regards,
Niamhmailto:ni...@fullbore.co.uk
pgpKsVGuBiYkY.pgp
Description: PGP signature
On 5/11/2015 9:42 AM, Alex Regan wrote:
Hi,
I have a fp that was passed through thomsonreuters, hitting
RCVD_IN_DNSWL_HI, receiving -5 points, from an obvious hacked account.
http://pastebin.com/5LYS7s2v
This is with v3.4.1, but an older bayes database, so perhaps it needs
to be rebuilt. Ev
Am 11.05.2015 um 15:42 schrieb Alex Regan:
I have a fp that was passed through thomsonreuters, hitting
RCVD_IN_DNSWL_HI, receiving -5 points, from an obvious hacked account.
http://pastebin.com/5LYS7s2v
This is with v3.4.1, but an older bayes database, so perhaps it needs to
be rebuilt. Even w
Hi,
I have a fp that was passed through thomsonreuters, hitting
RCVD_IN_DNSWL_HI, receiving -5 points, from an obvious hacked account.
http://pastebin.com/5LYS7s2v
This is with v3.4.1, but an older bayes database, so perhaps it needs to
be rebuilt. Even with BAYES_99, it still wouldn't have
ess I should've
cc'd you. http://wiki.apache.org/spamassassin/DnsBlocklists says to
use the "score" method. I went with that.
> > That last one is really important, because without it, you'll still stop
> > getting hits on the dnswl rules, but you'll still
On Mon, Dec 26, 2011 at 12:39:45PM +0100, Karsten Bräckelmann wrote:
> > score __RCVD_IN_DNSWL 0
>
> It is a non-scoring "double underscore" sub-rule. It does not have a
> score. It cannot have a score. Setting its score to zero does nothing,
> and certainly not prevent the DNS query.
Surprise, i
And frankly, disabling a rule by logically making it never hit is the
better approach anyway. Just re-define rules to disable them:
meta FOO 0
> That last one is really important, because without it, you'll still stop
> getting hits on the dnswl rules, but you'll still be sen
abuse: RCVD_IN_DNSWL_BLOCKED
To disable dnswl, you should use:
score RCVD_IN_DNSWL_NONE 0
score RCVD_IN_DNSWL_LOW 0
score RCVD_IN_DNSWL_MED 0
score RCVD_IN_DNSWL_HI 0
score RCVD_IN_DNSWL_BLOCKED 0
score __RCVD_IN_DNSWL 0
That last one is really important, because without it, you'll still stop
getting h
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
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
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 lo
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
e 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.
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
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
d, 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 oct
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 o
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):
>
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_net
On 12/12/2011 8:58 PM, Benny Pedersen wrote:
On Mon, 12 Dec 2011 20:29:07 -0500, Kevin A. McGrail wrote:
For DNSWL, 6718 is a dupe and 6668 is considered resolved with the
changing of the DNSWL scores to 0 which will be effective in the next
sa-update.
DNSWL is scaned in deep received, but
On Mon, 12 Dec 2011 20:29:07 -0500, Kevin A. McGrail wrote:
For DNSWL, 6718 is a dupe and 6668 is considered resolved with the
changing of the DNSWL scores to 0 which will be effective in the next
sa-update.
DNSWL is scaned in deep received, but none have reporteed this :(
dont know if
On 12/12/2011 8: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
(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
ing 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.
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 t
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 th
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 mov
.
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 ISP
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
erver 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 ?
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 &qu
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 enabl
th.
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\
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 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,
> > t
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
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 whi
1 - 100 of 258 matches
Mail list logo
