Discuss

discuss@lists.surbl.org

2 participants
1870 discussions

RE: Feature Request: Whitelist_DNSRBL
by Chris Santerre 09 Dec '04

09 Dec '04

>-----Original Message----- >From: Bill Landry [mailto:billl@pointshare.com] >Sent: Wednesday, December 08, 2004 11:04 AM >To: users(a)spamassassin.apache.org; discuss(a)lists.surbl.org >Subject: Re: Feature Request: Whitelist_DNSRBL > > >----- Original Message ----- >From: "Daryl C. W. O'Shea" <spamassassin(a)dostech.ca> > >> >> Was the whitelist you were referring to really the SURBL >server-side >> whitelist? >> > >> > >> > Yes! But local SURBL whitelists are needed to reduce >traffic and time. >> >> >> I'd much rather see SURBL respond with 127.0.0.0 with a >really large TTL >> for white listed domains. Any sensible setup will run a >local DNS cache >> which will take care of the load and time issue. > >I agree, and have suggested a whitelist SURBL several times on >the SURBL >discussion list, but it has always fallen on deaf ears - nary >a response. >It would be nice if someone would at least respond as to why >this is not a >reasonable suggestion. Well we have talked about it and .... didn't come up with a solid answer. The idea would cause more lookups and time for those who don't cache dns. We do have a whitelist that our private research tools do poll. The idea is that if it isn't in SURBL then it is white. This also puts more work to the already overworked contributors. ;) --Chris

5 7

Re: Feature Request: Whitelist_DNSRBL
by Jeff Chan 09 Dec '04

09 Dec '04

On Wednesday, December 8, 2004, 8:15:28 AM, David Hooton wrote: > The floor in offering a DNS based whitelist is that it encourages > people to place a negative score on it. The problem with this is that > spammers can poison messages with whitelisted domains, thereby > bypassing the power of the SURBL Agreed, that's another possible misuse of whitelists if they existed in RBL form. > The concept of "Whitelist" in the SURBL world is more of an "Exclusion > List" as in "we exclude these domains from being listed" rather than > we consider the presence of these domains in an email to be a good > sign of ham. Which is how we use them throughout SURBLs. There is no whitening of messages due to whitelist inclusion, only non-checking of whitelisted domains. That was a deliberate design decision IIRC. It seems to be revisited every so often, along with other design decisions, most of which I hope are mostly right. None of these decisions were made in a vacuum, we discussed most of them collaboratively and openly. Some of them were made when the project was just Eric Kolve and me, and some were later, but even two heads are better than one. :-) > An excluded domain is therefore ignored in all data and not allocated > a score positively or negatively, so trying to poison a message with > whitelisted domains is therefore pointless. Yep. > I think we either need to look at a DNS version of > uridnsbl_skip_domain with long TTL's or we should look at releasing a > .cf file. I personally think the more proper implementation may be > the DNS based version in order to avoid BigEvil type situations. The the solution we came up for SA 3 with of a small, hard-coded exclusion list seems to fit the data well and be somewhat optimal in terms of performance. An advantage of a separate local whitelist .cf might be for local programs to be able to output and maintain their own list, as Chris initially suggested. But I get back to the point that whitehats are pretty stable, and a hard coded list which anyone can edit or update locally in their existing 25_uribl.cf fits the data pretty well. Jeff C. -- Jeff Chan mailto:jeffc@surbl.org http://www.surbl.org/

1 0

Re: Feature Request: Whitelist_DNSRBL
by Bill Landry 09 Dec '04

09 Dec '04

----- Original Message ----- From: "Daryl C. W. O'Shea" <spamassassin(a)dostech.ca> > >> Was the whitelist you were referring to really the SURBL server-side > whitelist? > > > > > > Yes! But local SURBL whitelists are needed to reduce traffic and time. > > > I'd much rather see SURBL respond with 127.0.0.0 with a really large TTL > for white listed domains. Any sensible setup will run a local DNS cache > which will take care of the load and time issue. I agree, and have suggested a whitelist SURBL several times on the SURBL discussion list, but it has always fallen on deaf ears - nary a response. It would be nice if someone would at least respond as to why this is not a reasonable suggestion. Bill

3 2

Feature Request: Whitelist_DNSRBL
by Chris Santerre 09 Dec '04

09 Dec '04

OK, we know that the popular domains like yahoo.com and such are hard coded into SA to be skipped on DNSRBL lookups. But it would be great to have a function to add more locally. Thinking one step bigger, it would be even better to feed this a file. This way maybe SURBL can create a file for the top hit legit domains. Then using SARE and RDJ, people could update that. This would reduce a lot of traffic and time. This might also help with the mysterious bug we have seen where some local domains are being flagged as SURBL hit, when they aren't in SURBL. Perhaps whitelisting local domains so they are skipped would do away with this. Thoughts, suggestions, or coffee? Chris Santerre System Admin and SARE Ninja http://www.rulesemporium.com http://www.surbl.org 'It is not the strongest of the species that survives, not the most intelligent, but the one most responsive to change.' Charles Darwin

4 3

RE: [SURBL-Discuss] RE: Feature Request: Whitelist_DNSRBL
by Dallas L. Engelken 08 Dec '04

08 Dec '04

> > > >Chris Santerre wrote: > >> Well we have talked about it and .... didn't come up with a > >solid answer. > >> The idea would cause more lookups and time for those who > >don't cache dns. We > >> do have a whitelist that our private research tools do poll. > >The idea is > >> that if it isn't in SURBL then it is white. > >> > >> This also puts more work to the already overworked contributors. ;) > > > >want to put me on the round robin list again? > > Yes I would, but I think it is broke. We have been trying to > get one person off, but haven't been able to. Security issue. > I'll let Dallas chime in on this one. > Ya, things are still tight where its hosted. When I get some time here, I'd like to assume responsibility for hosting rulesemporium.com if nobody cares. I've just been so fricken busy lately. Dallas

1 0

RE: [SURBL-Discuss] RE: Feature Request: Whitelist_DNSRBL
by Chris Santerre 08 Dec '04

08 Dec '04

>-----Original Message----- >From: Alex Broens [mailto:surbl@alexb.ch] >Sent: Wednesday, December 08, 2004 12:34 PM >To: SURBL Discussion list >Subject: Re: [SURBL-Discuss] RE: Feature Request: Whitelist_DNSRBL > > >Chris Santerre wrote: >> Well we have talked about it and .... didn't come up with a >solid answer. >> The idea would cause more lookups and time for those who >don't cache dns. We >> do have a whitelist that our private research tools do poll. >The idea is >> that if it isn't in SURBL then it is white. >> >> This also puts more work to the already overworked contributors. ;) > >want to put me on the round robin list again? Yes I would, but I think it is broke. We have been trying to get one person off, but haven't been able to. Security issue. I'll let Dallas chime in on this one. --Chris

1 0

Re: Feature Request: Whitelist_DNSRBL
by Bill Landry 08 Dec '04

08 Dec '04

----- Original Message ----- From: "David Hooton" <david.hooton(a)gmail.com> > On Wed, 8 Dec 2004 08:03:35 -0800, Bill Landry <billl(a)pointshare.com> wrote: > > I agree, and have suggested a whitelist SURBL several times on the SURBL > > discussion list, but it has always fallen on deaf ears - nary a response. > > It would be nice if someone would at least respond as to why this is not a > > reasonable suggestion. > > The floor in offering a DNS based whitelist is that it encourages > people to place a negative score on it. The problem with this is that > spammers can poison messages with whitelisted domains, thereby > bypassing the power of the SURBL I agree, it should not be used as a HAM indicator, way too easy to abuse. I was suggesting that the whitelist be used as a way to exclude the domain from being constantly queried against the SURBL name servers. > The concept of "Whitelist" in the SURBL world is more of an "Exclusion > List" as in "we exclude these domains from being listed" rather than > we consider the presence of these domains in an email to be a good > sign of ham. Exactly. > An excluded domain is therefore ignored in all data and not allocated > a score positively or negatively, so trying to poison a message with > whitelisted domains is therefore pointless. Yep, agree wholeheartedly. > I think we either need to look at a DNS version of > uridnsbl_skip_domain with long TTL's or we should look at releasing a > .cf file. I personally think the more proper implementation may be > the DNS based version in order to avoid BigEvil type situations. Indeed, my thoughts exactly. Bill

1 0

RE: [SURBL-Discuss] Feature Request: Whitelist_DNSRBL
by Chris Santerre 08 Dec '04

08 Dec '04

>> Thoughts, suggestions, or coffee? > >First, where's that coffee? In my belly! >then: I keep a .cf file with a quite a few lines like. > >uridnsbl_skip_domain ibill.com blabla.tld local-boobie-site.dom Doh! It helps to RTFM I guess :) LOL at boobie-site! Seeing as this feature is in place and I'm just thickheaded, I'll talk with Jeff about creating a cf file, or the 127.0.0.0 issue. But I'm leaning towards the cf file for now. Stay tuned..... --Chris (Ooh baby do you know what that's worth, oooh heaven is a place on earth!)

1 0

RE: Feature Request: Whitelist_DNSRBL
by Chris Santerre 08 Dec '04

08 Dec '04

> >>Thinking one step bigger, it would be even better to feed >this a file. This >>way maybe SURBL can create a file for the top hit legit >domains. Then using >>SARE and RDJ, people could update that. This would reduce a >lot of traffic >>and time. > >Wait, now you're bringing SURBL into this.. are you talking >normal DNSRBLS, >or URIDNSBLS? Or both? Dang my brain!!! I meant URIDNSBLS!! Freaking too many abreviations in my head :) > >Was the whitelist you were referring to really the SURBL >server-side whitelist? Yes! But local SURBL whitelists are needed to reduce traffic and time. > >>This might also help with the mysterious bug we have seen >where some local >>domains are being flagged as SURBL hit, when they aren't in >SURBL. Perhaps >>whitelisting local domains so they are skipped would do away >with this. > >Agreed.. It would provide users a short-term fix, although really the >problem does need to be rooted out at some point.. > >>Thoughts, suggestions, or coffee? > >All of the above? Pouring a cup right NOW! --Chris

1 0

Re: Feature Request: Whitelist_DNSRBL
by Matt Kettler 08 Dec '04

08 Dec '04

At 10:17 AM 12/8/2004 -0500, Chris Santerre wrote: >OK, we know that the popular domains like yahoo.com and such are hard coded >into SA to be skipped on DNSRBL lookups. But it would be great to have a >function to add more locally. Um. They are?? AFAIK there are absolutely no whitelists to the DNSRBLs in SA itself. Don't confuse the "EXISTING_DOMAINS" list in DNS.pm with a whitelist. That's actually a list of domains that are used to test if your DNS is working if you don't have dns_available set to yes. SA does a quick MX query for one of the domains in the list, and if it gets an answer, it knows it's working... However, I do agree it would be nice to be able to have a DNSBL whitelist capability, if for no other reason than fixing any listings that might cause short-term FPs. >Thinking one step bigger, it would be even better to feed this a file. This >way maybe SURBL can create a file for the top hit legit domains. Then using >SARE and RDJ, people could update that. This would reduce a lot of traffic >and time. Wait, now you're bringing SURBL into this.. are you talking normal DNSRBLS, or URIDNSBLS? Or both? Was the whitelist you were referring to really the SURBL server-side whitelist? >This might also help with the mysterious bug we have seen where some local >domains are being flagged as SURBL hit, when they aren't in SURBL. Perhaps >whitelisting local domains so they are skipped would do away with this. Agreed.. It would provide users a short-term fix, although really the problem does need to be rooted out at some point.. >Thoughts, suggestions, or coffee? All of the above?

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss