Re: _DKIMDOMAIN_ vs. _AUTHORDOMAIN_ (was: Re: dnswl dwl rule)

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

Re: _DKIMDOMAIN_ vs. _AUTHORDOMAIN_ (was: Re: dnswl dwl rule)

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

Re: _DKIMDOMAIN_ vs. _AUTHORDOMAIN_ (was: Re: dnswl dwl rule)

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..

Re: _DKIMDOMAIN_ vs. _AUTHORDOMAIN_ (was: Re: dnswl dwl rule)

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

Re: _DKIMDOMAIN_ vs. _AUTHORDOMAIN_ (was: Re: dnswl dwl rule)

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

_DKIMDOMAIN_ vs. _AUTHORDOMAIN_ (was: Re: dnswl dwl rule)

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

Re: dnswl dwl rule

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

Re: dnswl dwl rule

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 describe LOCAL_DNSWL_IN_DWL domain is dnswl

Re: dnswl dwl rule

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 -

Re: DNSWL overriding bayes_99 and bayes_999 rules

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 said, if you are using publi

Re: DNSWL overriding bayes_99 and bayes_999 rules

>> -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. As > others said, if you are usin

Re: DNSWL overriding bayes_99 and bayes_999 rules

Steve Dondley writes: > Note: I've changed the score of RCVD_IN_DNSWL_HI hits to -2.0 from > -5.0 until I get my misconfiguration figured out. Thanks for your > patience. Fair enough; that's not an unreasonable thing to do. Probably you want to turn report_safe to 0 for doing this testing. >

Re: DNSWL overriding bayes_99 and bayes_999 rules

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

Re: DNSWL overriding bayes_99 and bayes_999 rules

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

Re: DNSWL overriding bayes_99 and bayes_999 rules

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 ?

Re: DNSWL overriding bayes_99 and bayes_999 rules

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

Re: DNSWL overriding bayes_99 and bayes_999 rules

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

Re: DNSWL overriding bayes_99 and bayes_999 rules

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

Re: DNSWL overriding bayes_99 and bayes_999 rules

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

Re: DNSWL overriding bayes_99 and bayes_999 rules

You do obviously have a very misconfigured system on your end. Den 10-04-2021 kl. 17:51 skrev Steve Dondley: > > X-Spam-Status: Yes, score=20.8 required=5.0 tests=BASE64_LENGTH_79_INF, >     [...] >     ***RCVD_IN_DNSWL_HI***,RCVD_IN_PSBL,RCVD_IN_RP_RNBL,RCVD_IN_SBL_CSS, > RCVD_IN_VALIDITY_RPB

Re: DNSWL overriding bayes_99 and bayes_999 rules

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 AnV2NSCZbmCTcQAAB60

Re: DNSWL overriding bayes_99 and bayes_999 rules

Steve Dondley writes: > From: Steve Dondley > Date: Sat, 10 Apr 2021 11:51:16 -0400 > > > > 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 poi

Re: DNSWL overriding bayes_99 and bayes_999 rules

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

Re: DNSWL overriding bayes_99 and bayes_999 rules

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

Re: DNSWL overriding bayes_99 and bayes_999 rules

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

Re: DNSWL overriding bayes_99 and bayes_999 rules

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,DKIM_SI

Re: DNSWL overriding bayes_99 and bayes_999 rules

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 > mass checks it's at 0.23% of spam. Do y

Re: DNSWL overriding bayes_99 and bayes_999 rules

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.

Re: DNSWL overriding bayes_99 and bayes_999 rules

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't be any kind of "problemati

Re: DNSWL overriding bayes_99 and bayes_999 rules

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=BAYES_

Re: DNSWL overriding bayes_99 and bayes_999 rules

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=BAYES_99,BAYES_999, >    DATE_IN_PAST_0

Re: DNSWL overriding bayes_99 and bayes_999 rules

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,DKI

Re: DNSWL overriding bayes_99 and bayes_999 rules

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_IN_PAST_03_06,DKIM_SIGNED,DKI

Re: DNSWL fp and other problems

(writing with my dnswl.org hat on) > Am 11.05.2015 um 15:42 schrieb Alex Regan : > > 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 IP

Re: DNSWL fp and other problems

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

Re: DNSWL fp and other problems

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

Re: DNSWL fp and other problems

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

Re: DNSWL was re-enabled

On 12/26, 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. > > Instead, you need to meta out the rule,

Re: DNSWL was re-enabled

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

Re: DNSWL was re-enabled

> 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. Instead, you need to meta out the rule, overwriting the rule definition. And frankly, dis

Re: DNSWL will be disabled by default as of tomorrow

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

Re: DNSWL will be disabled by default as of tomorrow

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

Re: DNSWL will be disabled by default as of tomorrow

On Wed, 2011-12-14 at 11:58 +0100, Matus UHLAR - fantomas wrote: > On 12.12.11 12:58, dar...@chaosreigns.com wrote: > >Tomorrow's sa-update will include disabling of the DNSWL rules. If you > >wish to locally enable them with the same scores which had previously been > >default, use this: > > > >

Re: DNS{B,W}Ls and blocking (was Re: DNSWL will be disabled by default as of tomorrow)

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

Re: DNS{B,W}Ls and blocking (was Re: DNSWL will be disabled by default as of tomorrow)

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

Re: DNS{B,W}Ls and blocking (was Re: DNSWL will be disabled by default as of tomorrow)

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

Re: DNSWL will be disabled by default as of tomorrow

On 12.12.11 12:58, dar...@chaosreigns.com wrote: Tomorrow's sa-update will include disabling of the DNSWL rules. If you wish to locally enable them with the same scores which had previously been default, use this: score RCVD_IN_DNSWL_NONE -0.0001 score RCVD_IN_DNSWL_LOW -0.7 score RCVD_IN_DNSWL

Re: DNS{B,W}Ls and blocking (was Re: DNSWL will be disabled by default as of tomorrow)

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

Re: DNS list inclusion policy (was Re: DNSWL will be disabled by default as of tomorrow)

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

Re: DNS list inclusion policy (was Re: DNSWL will be disabled by default as of tomorrow)

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

Re: DNS list inclusion policy (was Re: DNSWL will be disabled by default as of tomorrow)

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

Re: DNS list inclusion policy (was Re: DNSWL will be disabled by default as of tomorrow)

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

DNS list inclusion policy (was Re: DNSWL will be disabled by default as of tomorrow)

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

Re: DNSWL will be disabled by default as of tomorrow

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

Re: DNSWL will be disabled by default as of tomorrow

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

Re: DNSWL will be disabled by default as of tomorrow

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

Re: DNSWL will be disabled by default as of tomorrow

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

Re: DNS{B,W}Ls and blocking (was Re: DNSWL will be disabled by default as of tomorrow)

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

Re: DNSWL will be disabled by default as of tomorrow

On Tue, 13 Dec 2011 14:09:19 + Martin Gregorie wrote: > At the risk of exposing my ignorance, I had a thought. > > Since the entire 127/8 is reserved for loopback, nothing in the > 127.0.0/24 block should be used as addresses. So, what is preventing > RBLs and RWLs from using the third octe

Re: DNS{B,W}Ls and blocking (was Re: DNSWL will be disabled by default as of tomorrow)

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

DNS{B,W}Ls and blocking (was Re: DNSWL will be disabled by default as of tomorrow)

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

Re: DNSWL will be disabled by default as of tomorrow

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

Re: DNSWL will be disabled by default as of tomorrow

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

Re: DNSWL will be disabled by default as of tomorrow

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

Re: DNSWL will be disabled by default as of tomorrow

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

Re: DNSWL will be disabled by default as of tomorrow

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

Re: DNSWL will be disabled by default as of tomorrow

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

Re: DNSWL will be disabled by default as of tomorrow

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

Re: DNSWL will be disabled by default as of tomorrow

On 12/12/2011 5:27 PM, Karsten Bräckelmann wrote: No. SA should be usable out-of-the-box with best possible performance for the majority of users. Perhaps a better long-term solution would be to validate DNS lists before using them? One possible implementation would be to test to ensure that

Re: DNSWL will be disabled by default as of tomorrow

On Tue, 2011-12-13 at 03:25 +0100, Benny Pedersen wrote: > On Mon, 12 Dec 2011 21:12:56 -0500, Kevin A. McGrail wrote: > > > > DNSWL is scaned in deep received, but none have reporteed this :( No, it is not. Never was. > > DNSWL for SA is implemented with first-trusted on all the tests in SA > >

Re: DNSWL will be disabled by default as of tomorrow

On Mon, 12 Dec 2011 21:12:56 -0500, Kevin A. McGrail wrote: DNSWL is scaned in deep received, but none have reporteed this :( DNSWL for SA is implemented with first-trusted on all the tests in SA I found. I don't see any deep-header parsing. if its was we all need to use trusted_networks ev

Re: DNSWL will be disabled by default as of tomorrow

On 12/12/2011 8:58 PM, Benny Pedersen wrote: On Mon, 12 Dec 2011 20:29:07 -0500, Kevin A. McGrail wrote: For DNSWL, 6718 is a dupe and 6668 is considered resolved with the changing of the DNSWL scores to 0 which will be effective in the next sa-update. DNSWL is scaned in deep received, but no

Re: DNSWL will be disabled by default as of tomorrow

On Mon, 12 Dec 2011 20:29:07 -0500, Kevin A. McGrail wrote: For DNSWL, 6718 is a dupe and 6668 is considered resolved with the changing of the DNSWL scores to 0 which will be effective in the next sa-update. DNSWL is scaned in deep received, but none have reporteed this :( dont know if others

Re: DNSWL will be disabled by default as of tomorrow

On 12/12/2011 8:22 PM, Benny Pedersen wrote: On Mon, 12 Dec 2011 19:49:58 -0500, Kevin A. McGrail wrote: If you don't like the terms of the list provider, don't use them. It's pretty simple. make the bug report invalid / wont-fix then ? i dont get it :/ What bug are you talking about? For D

Re: DNSWL will be disabled by default as of tomorrow

On Mon, 12 Dec 2011 19:49:58 -0500, Kevin A. McGrail wrote: If you don't like the terms of the list provider, don't use them. It's pretty simple. make the bug report invalid / wont-fix then ? i dont get it :/

Re: DNSWL will be disabled by default as of tomorrow

On Mon, 2011-12-12 at 16:37 -0800, Ted Mittelstaedt wrote: > then why is DNSWL the only one that had access turned on by default > originally? Sorry, I don't understand what you're asking or referring to. But then again, we're getting quite off-topic. And frankly, all this arguing is mildly anno

Re: DNSWL will be disabled by default as of tomorrow

On Mon, 12 Dec 2011 21:24:12 +0100, Karsten Bräckelmann wrote: And I don't see anyone calling the users abusive. But the DNS servers. Which is causing collateral damage to some users. and there is other dnseval rules that could make false possitive on shared dns servers aswell, might be time

Re: DNSWL will be disabled by default as of tomorrow

But it's OK for list providers to play this game, eh? Just not Unisys? This is a discussion better suited to DNSWL's mailing lists than SA as we've disabled the rules. Overall, though, DNSWL has been good members of the anti-spam community and have supported running their tests for a long

Re: DNSWL will be disabled by default as of tomorrow

On Mon, 2011-12-12 at 16:39 -0800, Ted Mittelstaedt wrote: > Most likely 90% of the ISPs and corporations out there who wanted > to use the DNSWL and did this would experience no problems. > > But the text on the website is extremely hand-wavy. [...] Now we seriously moved off-topic... -- char

Re: DNSWL will be disabled by default as of tomorrow

On 12/12/2011 4:02 PM, Karsten Bräckelmann wrote: On Mon, 2011-12-12 at 15:42 -0800, jdow wrote: Hm, their limit is 100,000 queries. LKML can probably account for about that many queries per month for one user. Add in Fedora and spam and I am pretty sure two users could overrun their limits. 1

Re: DNSWL will be disabled by default as of tomorrow

On 12/12/2011 4:27 PM, Karsten Bräckelmann wrote: On Mon, 2011-12-12 at 16:04 -0800, Ted Mittelstaedt wrote: The text regarding high-use queries appeared on the website in October 2010. Whether or not it's "enforced" by serving FP's to excessive users is beside the point - No, it is not. It i

Re: DNSWL will be disabled by default as of tomorrow

On Mon, 12 Dec 2011 18:48:07 +, Jeremy McSpadden wrote: I agree with what you are saying, but to enable a plugin out of the box; with no warning or instructions stating you need to "run a local caching dns server in order to use this plugin successfully if your machine is using a dns server t

Re: DNSWL will be disabled by default as of tomorrow

On Mon, 2011-12-12 at 16:04 -0800, Ted Mittelstaedt wrote: > The text regarding high-use queries appeared on the website in > October 2010. Whether or not it's "enforced" by serving FP's to > excessive users is beside the point - No, it is not. It is precisely the point, and the reason for disabl

Re: DNSWL will be disabled by default as of tomorrow

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

Re: DNSWL will be disabled by default as of tomorrow

On 12/12/2011 2:35 PM, Karsten Bräckelmann wrote: On Mon, 2011-12-12 at 13:01 -0800, Ted Mittelstaedt wrote: On 12/12/2011 12:24 PM, Karsten Bräckelmann wrote: Please don't forget that this became an issue only after DNSWL policy change. At the time the DNSWL rules have been enabled by defaul

Re: DNSWL will be disabled by default as of tomorrow

On Mon, 2011-12-12 at 15:42 -0800, jdow wrote: > Hm, their limit is 100,000 queries. LKML can probably account for about > that many queries per month for one user. Add in Fedora and spam and I am > pretty sure two users could overrun their limits. 100,000 queries per *day*, not month. Plus, usin

Re: DNSWL will be disabled by default as of tomorrow

On 2011/12/12 14:35, Karsten Bräckelmann wrote: On Mon, 2011-12-12 at 13:01 -0800, Ted Mittelstaedt wrote: On 12/12/2011 12:24 PM, Karsten Bräckelmann wrote: Please don't forget that this became an issue only after DNSWL policy change. At the time the DNSWL rules have been enabled by default

Re: DNSWL will be disabled by default as of tomorrow

On Mon, 2011-12-12 at 13:01 -0800, Ted Mittelstaedt wrote: > On 12/12/2011 12:24 PM, Karsten Bräckelmann wrote: > > Please don't forget that this became an issue only after DNSWL policy > > change. At the time the DNSWL rules have been enabled by default in SA, > > there where no deliberately fals

Re: DNSWL will be disabled by default as of tomorrow

So does this mean SA should disable ALL network based tests by default as they all have the same potential to return false positives/negatives to get the attention of (abusive) sysadmins? About the only difference is dnswl.org got to hit folks with a -5 score whereas most others would have si

Re: DNSWL will be disabled by default as of tomorrow

On 12/12/11 19:50, Ted Mittelstaedt wrote: I concur 100%. Daniel is wrong. The problem isn't dnswl.org the problem is the person who made the decision in SpamAssassin to have the default for the dnswl plugin ENABLED by default. That decision has been recognized to have been a mistake which is why

Re: DNSWL will be disabled by default as of tomorrow

On 12/12/2011 12:24 PM, Karsten Bräckelmann wrote: On Mon, 2011-12-12 at 11:50 -0800, Ted Mittelstaedt wrote: I concur 100%. Daniel is wrong. The problem isn't dnswl.org the problem is the person who made the decision in SpamAssassin to have the default for the dnswl plugin ENABLED Please do

Re: DNSWL will be disabled by default as of tomorrow

On Mon, 2011-12-12 at 11:50 -0800, Ted Mittelstaedt wrote: > I concur 100%. Daniel is wrong. The problem isn't > dnswl.org the problem is the person who made the decision in > SpamAssassin to have the default for the dnswl plugin ENABLED Please don't forget that this became an issue only after D

Re: DNSWL will be disabled by default as of tomorrow

I concur 100%. Daniel is wrong. The problem isn't dnswl.org the problem is the person who made the decision in SpamAssassin to have the default for the dnswl plugin ENABLED by default. That decision has been recognized to have been a mistake which is why SA is making an update that will turn it

Re: DNSWL will be disabled by default as of tomorrow

On 12/12/2011 1:35 PM, Daniel McDonald wrote: Can I ask you a fairly blunt question? What action could they have taken that would have caused you to notice that you were engaging in abusive miss-use of their service by continuing to forward your requests through google? I'm quite serious. DNSB

Re: DNSWL will be disabled by default as of tomorrow

I agree with what you are saying, but to enable a plugin out of the box; with no warning or instructions stating you need to "run a local caching dns server in order to use this plugin successfully if your machine is using a dns server that may or may not be used and making millions of queries t

Re: DNSWL will be disabled by default as of tomorrow

On 12/12/11 12:03 PM, "Jeremy McSpadden" wrote: > Thank you! I raised this question a few months ago and was in awe that it was > enabled by default. It has caused quite a few issues that i've seen around the > ML. They should return a different value than a negative score. Can I ask you a fa

Re: DNSWL will be disabled by default as of tomorrow

Thank you! I raised this question a few months ago and was in awe that it was enabled by default. It has caused quite a few issues that i've seen around the ML. They should return a different value than a negative score. Very bad design. -- Jeremy McSpadden Flux Labs, Inc http://www.fluxlabs.net

Re: DNSWL returns _HI trust level for everything to "abusive" DNS servers Re: Spam email many have RCVD_IN_DNSWL_MED

dar...@chaosreigns.com wrote: On 10/12, Alessio Cecchi wrote: > I have found the problem: Google name server > > >On 10/11, Alessio Cecchi wrote: > >>Received: from [175.145.6.37] (unknown [175.145.6.37]) > > > >$ host 37.6.145.175.list.dnswl.org > >Host 37.6.145.175.list.dnswl.org not found: 3(N

Re: DNSWL rules downscoring spam

Pasi Hirvonen wrote: > I just recently moved our mail setup to new hardware and I've been > paying close attention to what gets marked as spam and what > doesn't. > > Looking at my spam folder, I have received roughly 550 spam emails > to my email account since last tuesday (15th). Out of those 55

Re: DNSWL abuse reports by domain, over time

dar...@chaosreigns.com wrote: > Top 20, linear Y scale: > http://www.chaosreigns.com/dnswl/dnswlabusehistory.svg > > Top 10, logarithmic Y scale: > http://www.chaosreigns.com/dnswl/dnswlabusehistory_log.svg > [...] Could you create chart with number of reports instead of percent of reports? AFAIK

  1   2   >