Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: SpamAssassin: users

DNSWL will be disabled by default as of tomorrow

 

 

First page Previous page 1 2 Next page Last page  View All SpamAssassin users RSS feed   Index | Next | Previous | View Threaded


me at junc

Dec 12, 2011, 5:58 PM

Post #26 of 46 (916 views)
Permalink
Re: DNSWL will be disabled by default as of tomorrow [In reply to]

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


KMcGrail at PCCC

Dec 12, 2011, 6:12 PM

Post #27 of 46 (923 views)
Permalink
Re: DNSWL will be disabled by default as of tomorrow [In reply to]

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


me at junc

Dec 12, 2011, 6:25 PM

Post #28 of 46 (928 views)
Permalink
Re: DNSWL will be disabled by default as of tomorrow [In reply to]

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 :-)


guenther at rudersport

Dec 12, 2011, 7:09 PM

Post #29 of 46 (918 views)
Permalink
Re: DNSWL will be disabled by default as of tomorrow [In reply to]

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; }}}


lists at hireahit

Dec 12, 2011, 11:19 PM

Post #30 of 46 (919 views)
Permalink
Re: DNSWL will be disabled by default as of tomorrow [In reply to]

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


KMcGrail at PCCC

Dec 13, 2011, 4:44 AM

Post #31 of 46 (910 views)
Permalink
Re: DNSWL will be disabled by default as of tomorrow [In reply to]

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


axb.lists at gmail

Dec 13, 2011, 4:52 AM

Post #32 of 46 (909 views)
Permalink
Re: DNSWL will be disabled by default as of tomorrow [In reply to]

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.


michael.scheidell at secnap

Dec 13, 2011, 6:00 AM

Post #33 of 46 (911 views)
Permalink
Re: DNSWL will be disabled by default as of tomorrow [In reply to]

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/
______________________________________________________________________


martin at gregorie

Dec 13, 2011, 6:09 AM

Post #34 of 46 (911 views)
Permalink
Re: DNSWL will be disabled by default as of tomorrow [In reply 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 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.
>


dan.mcdonald at austinenergy

Dec 13, 2011, 6:16 AM

Post #35 of 46 (908 views)
Permalink
Re: DNSWL will be disabled by default as of tomorrow [In reply to]

On 12/13/11 8:09 AM, "Martin Gregorie" <martin [at] 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
>>>> 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


matthias at leisi

Dec 13, 2011, 6:20 AM

Post #36 of 46 (909 views)
Permalink
Re: DNSWL will be disabled by default as of tomorrow [In reply to]

On Tue, Dec 13, 2011 at 3:00 PM, Michael Scheidell
<michael.scheidell [at] secnap> 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


jhardin at impsec

Dec 13, 2011, 6:21 AM

Post #37 of 46 (906 views)
Permalink
Re: DNSWL will be disabled by default as of tomorrow [In reply to]

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 [at] impsec FALaholic #11174 pgpk -a jhardin [at] impsec
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


rwmaillists at googlemail

Dec 13, 2011, 6:30 AM

Post #38 of 46 (911 views)
Permalink
Re: DNSWL will be disabled by default as of tomorrow [In reply to]

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.


lists at hireahit

Dec 13, 2011, 8:46 AM

Post #39 of 46 (893 views)
Permalink
Re: DNSWL will be disabled by default as of tomorrow [In reply to]

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


KMcGrail at PCCC

Dec 13, 2011, 9:37 AM

Post #40 of 46 (894 views)
Permalink
Re: DNSWL will be disabled by default as of tomorrow [In reply to]

> 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


lists at hireahit

Dec 13, 2011, 9:45 AM

Post #41 of 46 (896 views)
Permalink
Re: DNSWL will be disabled by default as of tomorrow [In reply to]

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


KMcGrail at PCCC

Dec 13, 2011, 9:51 AM

Post #42 of 46 (896 views)
Permalink
Re: DNSWL will be disabled by default as of tomorrow [In reply to]

> 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


uhlar at fantomas

Dec 14, 2011, 2:58 AM

Post #43 of 46 (898 views)
Permalink
Re: DNSWL will be disabled by default as of tomorrow [In reply to]

On 12.12.11 12:58, darxus [at] chaosreigns 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 [at] fantomas ; 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


noel.butler at ausics

Dec 14, 2011, 5:14 PM

Post #44 of 46 (894 views)
Permalink
Re: DNSWL will be disabled by default as of tomorrow [In reply to]

On Wed, 2011-12-14 at 11:58 +0100, Matus UHLAR - fantomas wrote:

> On 12.12.11 12:58, darxus [at] chaosreigns 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.
Attachments: signature.asc (0.48 KB)


KMcGrail at PCCC

Dec 15, 2011, 5:11 AM

Post #45 of 46 (903 views)
Permalink
Re: DNSWL will be disabled by default as of tomorrow [In reply to]

> 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


rwmaillists at googlemail

Dec 15, 2011, 5:54 AM

Post #46 of 46 (890 views)
Permalink
Re: DNSWL will be disabled by default as of tomorrow [In reply to]

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.

First page Previous page 1 2 Next page Last page  View All SpamAssassin users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.