Discuss December 2004

discuss@lists.surbl.org

43 participants
80 discussions

surebase.com?
by Jeff Chan 12 Dec '04

12 Dec '04

Anyone heard of: Deerfield Communications Inc. 4241 Old U.S. 27 South Gaylord, MI 49735 US Domain Name: SUREBASE.COM Administrative Contact - M.N.Lopes daSilva - tropical(a)ve.net SureBase.com c/o Technical Web Edf Santiago de Leon, Piso 2, Ofic 21, Av-Casanova Caracas, 1010 VE Phone - 01127618432 Fax - Technical Contact - HostMaster DNS2Go - hostmaster(a)DNS2Go.com Deerfield Communications Inc. 4241 Old U.S. 27 South Gaylord, MI 49735 US Phone - (517) 732-8856 Fax - (517) 731-2642 Billing Contact - M.N.Lopes daSilva - tropical(a)ve.net SureBase.com c/o Technical Web Edf Santiago de Leon, Piso 2, Ofic 21, Av-Casanova Caracas, 1010 VE Phone - 01127618432 Fax - Record update date - 2004-05-27 09:50:52 Record create date - 2000-05-13 Record will expire on - 2005-05-13 Database last updated on - 2004-12-11 19:13:36 EST Domain servers in listed order: NS.TUCONDOMINIO.COM 66.227.4.217 NS2.TUCONDOMINIO.COM 66.227.4.218 I got a spam sent straight from their server NS.TUCONDOMINIO.COM 66.227.4.217 mentioning domains: joysongcreations.com surebase.com joysongcreations.com is relatively new and has no RBL, SBL or NANAS. surebase.com was registered in 2000, has no RBL or SBL but has 4000+ NANAS. This one is puzzling. Anyone have more info? Jeff C. -- "If it appears in hams, then don't list it."

2 2

Re: [SURBL-Discuss] RFC: consensus list?
by Frank Ellermann 11 Dec '04

11 Dec '04

Jeff Chan wrote: > Ask application writers like SpamAssassin and others > to check or modify their code to be able to handle bits > in the other octets, i.e. 127.0.1.X, 127.64.X.X, etc. > Should we let them know ahead of time that their code > should be able to handle these cases without breaking? In rxwhois 1.7.1 dedicated to one "Jeff Chan" <eg> I've added support for either 127.0.X.Y or 127.1.X.Y. The latter is for OPM and allows up to 16 bits. For the former I now display 127.0.0.0/31 as "utter dubious". 2.0.0.127.wadb.isipp.com = 127.0.0.1, I'll probably eliminate WADB, it's below my minimal standards for any well-behaved BL. We can discuss about more than 16 bits in 2006, is that okay ? > Comments? I'm not sure why OPM uses 127.1.0.Y instead of 127.0.0.Y. A simple explanation would be "avoid 127.0.0.0/31 like hell and allow up to 8 bits in Y". Another explanation could be "no 127.0.0.0/31, up to 16 bits in 127.1.X.Y, _and_ additionally a version number in the case of incompatible changes, starting with version 1 in 127.1.X.Y". Bye, Frank -- <http://purl.net/xyzzy/src/rxwhois.cmd> <http://purl.net/xyzzy/rxwhois.htm>

1 0

RE: [SURBL-Discuss] FP rate
by Chris Santerre 09 Dec '04

09 Dec '04

>-----Original Message----- >From: Jeff Chan [mailto:jeffc@surbl.org] >Sent: Thursday, December 09, 2004 2:06 AM >To: SURBL Discuss >Subject: Re: [SURBL-Discuss] FP rate > > >On Wednesday, December 8, 2004, 8:51:04 PM, RD RD wrote: >> Hello List, > >> Is there an available % FP rate for SC and JP ? >> I thought I should ask to help me decide whether I should >keep dropping >> e-mails w/ blacklisted URIs. > >FP rates vary a lot depending on whose spam and ham corpra are >used, but here are some from SpamAssassin corpora against >older versions of the SURBL lists. Most of the SURBL lists >now have better FP rates due to cleanup we've been doing >along the way: > >OVERALL% SPAM% HAM% S/O RANK SCORE NAME >2424443 2357143 67300 0.972 0.00 0.00 (all messages) >100.000 97.2241 2.7759 0.972 0.00 0.00 (all messages as %) > 7.595 7.8122 0.0045 0.999 1.00 0.00 URIBL_SC_SURBL > 76.754 78.9448 0.0178 1.000 0.80 0.00 URIBL_OB_SURBL > 77.230 79.4340 0.0208 1.000 0.60 1.00 URIBL_PJ_SURBL > 0.985 1.0126 0.0045 0.996 0.50 0.00 URIBL_AB_SURBL > 82.119 84.4600 0.1367 0.998 0.40 0.00 URIBL_WS_SURBL > 0.021 0.0216 0.0045 0.829 0.00 0.00 URIBL_PH_SURBL I still can't believe SC is beating WS in FP rate!!! Bah!!!! Must reduce FP rate more!! Must perse thru thousands of domains.....mind going numb......... Ahhhh but look at the spam hit rates! Who's your daddy now?! :-) --Chris

4 4

SpamAssassin Discussion LIst
by Rob McEwen 09 Dec '04

09 Dec '04

Even thought I don't use SpamAssassin, from time to time, I desire to discuss and even contribute ideas related to developing or enhancing rules base filtering. Like SpamAssassin, the mail filter I use is capable of using Regular Expressions in a way that is similar to SpamAssassin. When I get the urge to post questions and suggestions, I keep thinking that the SURBL list is not the best targeted forum for this topic and I should probably join the SpamAssassin discussion group to discuss this topic. However, after searching, I now see that there is more than one list for SpamAssassin. Therefore, does anyone know **which** SpamAssassin list I should join (and where to subscribe) if I'm interested in rules development? Thanks, Rob McEwen

3 2

RE: [SURBL-Discuss] Feature Request: Whitelist_DNSRBL
by Rob McEwen (PowerView Systems) 09 Dec '04

09 Dec '04

Speaking of whitelisting, I'm using a caching dns server on my box which is based on BINDS. I currently use the following syntax in the names.config files to manually whitelist: zone "yahoo.com.multi.surbl.org" in { type master; }; This **works** and causes the DNS caching server to return a "not found" WITHOUT having to ever check external DNS servers to resolve this. Also, the return times are lightening fast (<4ms). However, I'm still getting some kind of weird system errors logged in my "Events" log related to this process. Basically, I think I goofed up the syntax or I am missing some information here. Does anyone here happen to be familar with BIND and have any suggestions as to the correct syntax? What **should** my example from above look like? Thanks, Rob McEwen

3 3

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss December 2004