Discuss

discuss@lists.surbl.org

1 participants
1867 discussions

[SURBL-Discuss] RE: Add "$DATASET dnset @" directive to SURBL rbldnsd zone files?
by Dallas L. Engelken 28 Apr '04

28 Apr '04

> > > >> Can we please add a $DATASET definition to rbldnsd zone > >files for sc,ws, > >> and be? > >> If this gets added, rbldnsd operators would need to change their invocation of rbldnsd from zone:dnset:file to zone:combined:file To run a single zone... Because dnset does not expect to set $DATASET... Or if they want to combine lists into a single zone, use zone:combined:befile,scfile,wsfile how about making a duplicate of each set available with the $DATASET line added... So you have something like this, [root@rhn-1 surbl]# ll total 1040 -rw-r--r-- 1 root root 112368 Apr 28 10:22 be.surbl.org.dataset.rbldnsd -rw-r--r-- 1 root root 112268 Apr 27 06:13 be.surbl.org.rbldnsd -rw-r--r-- 1 root root 13957 Apr 28 10:22 mw.surbl.org.dataset.rbldnsd -rw-r--r-- 1 root root 13857 Apr 24 00:15 mw.surbl.org.rbldnsd -rw-r--r-- 1 root root 185420 Apr 28 10:22 sa.surbl.org.dataset.rbldnsd -rw-r--r-- 1 root root 185320 Apr 27 06:12 sa.surbl.org.rbldnsd -rw-r--r-- 1 root root 9416 Apr 28 10:22 sc.surbl.org.dataset.rbldnsd -rw-r--r-- 1 root root 9316 Apr 27 23:47 sc.surbl.org.rbldnsd -rw-r--r-- 1 root root 185420 Apr 28 10:22 ws.surbl.org.dataset.rbldnsd -rw-r--r-- 1 root root 185320 Apr 27 06:12 ws.surbl.org.rbldnsd That would allow you to combine zones -> uribl.yourdomain.com:combined:be.surbl.org.dataset.rbldnsd,sc.surbl.org. dataset.rbldnsd,ws.surbl.org.dataset.rbldnsd Or still run each individual zone by -> be.yourdomain.com:dnset:be.surbl.org.rbldnsd -> ws.yourdomain.com:dnset:ws.surbl.org.rbldnsd -> sc.yourdomain.com:dnset:sc.surbl.org.rbldnsd And not create any issues, besides having to maintain duplicate zone files. Dallas

1 0

[SURBL-Discuss] RE: Add "$DATASET dnset @" directive to SURBL rbldnsd zone files?
by Chris Santerre 28 Apr '04

28 Apr '04

>-----Original Message----- >From: Jeff Chan [mailto:jeffc@surbl.org] >Sent: Tuesday, April 27, 2004 10:07 PM >To: SURBL Discuss >Cc: SpamAssassin Users >Subject: RFC: Add "$DATASET dnset @" directive to SURBL rbldnsd zone >files? > > >Dallas Engleken of SARE has suggested that we add a >dataset directive to our rbldnsd zone files: > >> Can we please add a $DATASET definition to rbldnsd zone >files for sc,ws, >> and be? >> >> Ie.. On the 3rd line after $NS and $SOA, add a line labeled, >> >> $DATASET dnset @ >> >> It will not break anything currently set up, but it will >give those of >> use that use the 'combined' type with multi files in rbldnsd >(called via >> uribl.surbl.org:combined:sc,be,ws) to merge ws, sc, and be >together to >> create a single query. > >Does anyone have any comments on this, good, bad or otherwise? >Do other RBLs do it? Is it safe? > >Here's the man page entry: :-) > >> man rbldnsd >> >> combined >> This is a special dataset that stores no data >by itself but acts >> like a container for several other datasets of >any type except >> of combined type itself. The data file >contains an optional >> common section, where various specials are >recognized like $NS, >> $SOA, $TTL (see above), and a series of >sections, each of which >> defines one (nested) dataset and several >subzones of the base >> zone, for which this dataset should be >consulted. New (nested) >> dataset starts with a line >> $DATASET type subzone subzone... >> and all subsequent lines up to the end of >current file or to >> next $DATASET line are interpreted as a part >of dataset of type >> type. Note that combined datasets cannot be >nested. Every subâ >> zone will always be relative to the base zone >name specified on >> command line. If subzone specified as >single character "@", >> dataset will be connected to the base zone itself. >> >> This dataset type aims to simplify subzone >maintenance, in order >> to be able to include several subzones in one >file for easy data >> transfer, atomic operations and to be able >to modify list of >> subzones on remote secondary nameservers. >> >> Note that $NS and $SOA values applies to the >base zone only, >> regardless of the placement in the file. >Unlike the $TTL values >> and $n substitutions, which may be both global >and local for a >> given (subâ)dataset. > >Thumbs up or thumbs down? ;-) > >Jeff C. >-- But we are combining them anyway? Well WS and BE combined. So it would be WS and SC. I see no reason not to try it. --Chris

1 0

Re: second and third level domains - again!
by John Fawcett 28 Apr '04

28 Apr '04

Jeff Chan wrote on Mon Apr 26 03:58:58 CEST 2004 > The underlying principle as I see it is that most > major site will have functional anti-abuse and anti-spam > policies, so either a base domain is good or bad. I > know that seems simplistic, but it's easy and fast to > implement AND it seems to match reality pretty well. There may come a point where a "big" domain starts to appear in spam despite an outward image of "antispam" and the choice which the current infrastructure offers is to block all of it or none of it. Blocking all of it may produce too many FPs whereas blocking a subset may be acceptable. At the moment there haven't been any tough decisions to take on listing or whitelisting. Everything has been very clear cut. It's not guaranteed to stay that way. I don't know how real a risk this is, but I was worried about an infrastructure which effectively ties our hands on this point. (Once surbl is deployed in many different client software, I suppose it will be hard to change anything about the "public interface" to the data....) > That's an interesting idea. Basically you want to > signal redirection to higher domain levels with a > special result for levels that should never get > checked like co.uk. > That might be doable, but it would require extra > logic on the client side as you note. That already > sounds more complex than I like, though I see what > you're getting at. Better to control what goes into > the data (i.e. never let the TLD itself co.uk in), > and make sure the client is following similar rules. What I was proposing is a *change* to client processing logic, but not added *complexity*. rather a simplification. What I mean is that currently the client has to contain - processing logic - data on the ccTLDs (in the long run there will be multiple versions of the ccTLD data implemented in various client versions at any one time. Users will have to upgrade the client software to keep current with domain data). Using an A record in surbl to indicate "this domain is not listed but a subdomain is. Try again" would mean the client just follows a simple processing rule. It doesn't need to know anything about specific domain data. The logic would be something like this. lets assume that "url" is found in an email. level=2 more_info_result = '127.0.0.255' listed_result = '127.0.0.2' do { result = query_dns ( extract_domain (url, level)) level = level +1 }while (result == more_info_result) if (result == listed_result) { score it } > We will always catch bigspammer.co.uk with the current > strategy. I think that some of the ccTLDs have a mixed assignment strategy. This means that they should sometimes be checked at the 2nd level sometime at the 3rd level. The current logic always checks at a single predefined level. The two example I saw were: .fr and .ca Currently we check .ca at the third level, but it is possible to register a second level domain at .ca which we never catch so bigspammer.ca will get through. We check .fr at the second level however there are many "standard" second level domains (like .nom.fr) which means we probably want to be checking these ones at the third level. (Translation: any bigspammer.nom.fr domain is imune to the current strategy unless we want to upset everyone who has a nom.fr domain by listing that). > I know a lot of what I argue for above seems simplistic > when a more complex solution could have more interesting > results, but very often the simpler solutions are better, > especially in terms of resource consumption. You're right to argue for the most simple solution. (In fact there are probably simpler solutions than the one I suggested!). My concern was to avoid inflexibility in the infrastructure and automatic immunity for various classes of domains. John

4 5

access.db -> Bind zone file converter
by David Hooton 28 Apr '04

28 Apr '04

Hi All, We're wanting to move a bunch of our rather huge sendmail access files into bind compliant zone files. Does anyone have a tool that can do this in a slightly more automated way than our current options? We're also looking for a tool to convert a domain list into our own surbl zone (for the moment private, but we may release it later) again any pointers greatly appreciated :-) Regards, David Hooton Senior Partner Platform Networks www.platformnetworks.net ======================================================================== Pain free spam & virus protection by: www.mailsecurity.net.au Forward undetected SPAM to: spam(a)mailsecurity.net.au ========================================================================

4 6

[SURBL-Discuss] RFC: Add "$DATASET dnset @" directive to SURBL rbldnsd zone files?
by Jeff Chan 28 Apr '04

28 Apr '04

Dallas Engleken of SARE has suggested that we add a dataset directive to our rbldnsd zone files: > Can we please add a $DATASET definition to rbldnsd zone files for sc,ws, > and be? > > Ie.. On the 3rd line after $NS and $SOA, add a line labeled, > > $DATASET dnset @ > > It will not break anything currently set up, but it will give those of > use that use the 'combined' type with multi files in rbldnsd (called via > uribl.surbl.org:combined:sc,be,ws) to merge ws, sc, and be together to > create a single query. Does anyone have any comments on this, good, bad or otherwise? Do other RBLs do it? Is it safe? Here's the man page entry: :-) > man rbldnsd > > combined > This is a special dataset that stores no data by itself but acts > like a container for several other datasets of any type except > of combined type itself. The data file contains an optional > common section, where various specials are recognized like $NS, > $SOA, $TTL (see above), and a series of sections, each of which > defines one (nested) dataset and several subzones of the base > zone, for which this dataset should be consulted. New (nested) > dataset starts with a line > $DATASET type subzone subzone... > and all subsequent lines up to the end of current file or to > next $DATASET line are interpreted as a part of dataset of type > type. Note that combined datasets cannot be nested. Every subâ > zone will always be relative to the base zone name specified on > command line. If subzone specified as single character "@", > dataset will be connected to the base zone itself. > > This dataset type aims to simplify subzone maintenance, in order > to be able to include several subzones in one file for easy data > transfer, atomic operations and to be able to modify list of > subzones on remote secondary nameservers. > > Note that $NS and $SOA values applies to the base zone only, > regardless of the placement in the file. Unlike the $TTL values > and $n substitutions, which may be both global and local for a > given (subâ)dataset. Thumbs up or thumbs down? ;-) Jeff C. -- Jeff Chan mailto:jeffc@surbl.org http://www.surbl.org/

3 6

another redirector ?
by Simon Byrnand 28 Apr '04

28 Apr '04

Just spotted the following redirected URL in a spam. Doesn't look like it will be getting caught yet with the current redirector rules: http://images.google.ca/imgres?imgurl=gmib.free.fr/viagra.jpg&imgrefurl… Using images.google.ca as a redirector ? Thats a new one.... I'm not game to click on the link to see where it goes though... its from the same spammer that was blatently abusing the yahoo redirectors and msn ones... Is this a sign that the current system used in SpamCopURI (checking HTTP responses of specifically mentioned redirectors) is just going to play catchup all the time ? Regards, Simon

6 7

url parsing
by Eric Kolve 28 Apr '04

28 Apr '04

I have decided to add some URL parsing to SpamCopURI. I figure it will be kind of fun and should help catch a few of these edge cases that have popped up. If a few people could email me example redirects you have seen (you may want to tar.gz them up so they don't get filtered), that would helpful in making this more robust. I have examples for g.msn.com, ads.msn.com, rd.yahoo.com, and images.google.ca I am mainly looking for stuff like the URL Simon sent where the spam URL is hex encoded and is buried beneath three or four redirects. thanks, --eric

1 0

Re: [SURBL-Discuss] Simon's complex redirection
by Patrik Nilsson 28 Apr '04

28 Apr '04

At 10:55 2004-04-28 +1200, Simon Byrnand wrote: > > It's double-encoded. We can catch that easily. But first, my question -- > > does this *work* in an MUA, ie. should we? Simon, could you try it? > >What you get is the image preview in google which consists of an image in >the top frame, and the page that it came from in the bottom frame, and in >the bottom frame was a link "click here for ......." so yes it definately >does work... I guess this is a 'framer' rather than a redirector. A url that points to a frameset that loads an external page specified in the query url in one of the frames. For all practical purposes it's similar to a redirector, but with complications. The http response code from a GET request using the url will not indidate that it's a redirector. For a user loading the page in a browser, the adress of the spamvertized website will not be visible in the location bar. For some spammers, this would probably be prefered over traditional redirectors. Patrik

2 1

Re: Simon's complex redirection
by jm＠jmason.org 28 Apr '04

28 Apr '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Theo Van Dinter writes: > On Tue, Apr 27, 2004 at 03:46:32PM -0700, Justin Mason wrote: > > > http://images.google.ca/imgres?imgurl=gmib.free.fr/viagra.jpg&imgrefurl… > > eek! > > > It's double-encoded. We can catch that easily. But first, my question -- > > does this *work* in an MUA, ie. should we? Simon, could you try it? > > I don't know about an MUA, but it doesn't work in any browser I've tried > so far. You end up at http://images.google.com/images: > > Information returned from request (not including data): > <Connection> = <Keep-Alive> > <Content-Type> = <text/html> > <Content-length> = <161> > <Date> = <Tue, 27 Apr 2004 22:59:47 GMT> > <Location> = <http://images.google.com/images> > <Server> = <GWS/2.1> > <Set-Cookie> = <PREF=ID=2342b69354b6a6f5:LD=en:TM=1083106787:LM=1083106787:S=4Q5Kb3zcm_6V0Tjm; expires=Sun, > 17-Jan-2038 19:14:07 GMT; path=/; domain=.google.ca> > <code> = <301> Try http://images.google.ca/imgres?imgurl=gmib.free.fr/viagra.jpg&imgrefurl=htt… (NOTE: with & replaced with just &) that works. (although it still uses google's image results page for the display.) But just because it ends up at the imgres page doesn't mean we don't have to worry about it. This URL: http://www.google.com/url?q=http://www.google.com/url?q=%68%74%74%70%3A%2F%… also works -- Google redirects it to the target site http://www.expage.com/manger32 successfully -- but SpamAssassin doesn't parse it. - --j. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Exmh CVS iD8DBQFAjurMQTcbUG5Y7woRAi2KAKDkGfoSzXWzzP73ggTr0FEZYlbEEgCg7861 JrRcI4laMJDWumLpHAbWaT4= =/Hlu -----END PGP SIGNATURE-----

1 0

RE: [SURBL-Discuss] Fwd: Re: Goofy domain names
by Chris Santerre 26 Apr '04

26 Apr '04

>-----Original Message----- >From: Mark [mailto:admin@asarian-host.net] >Sent: Saturday, April 24, 2004 12:11 AM >To: David B Funk; SURBL Discussion list >Cc: SpamAssassin Users >Subject: Re: [SURBL-Discuss] Fwd: Re: Goofy domain names > > >David B Funk wrote: > >> On Sat, 24 Apr 2004, Mark wrote: >> >>> Why use expand_regex.pl at all? Instead of taking "/\d00\dhosting/", >>> and expand it into 100 potential domain names, why not simply accept >>> a query like: >>> >>> 9001hosting.com.be.surbl.org >>> >>> And, internally, do the regex "/\d00\dhosting/" on it? (and all >>> BigEvil regexes, for that matter). And return 127.0.0.2 on a match. >>> >>> Ultimately, using expand_regex.pl, imho, is utterly >self-defeating -- >>> without stretching the imagination too much, even. If only I change >>> the above regex to: >>> >>> /\d+00\d+hosting/ >>> >>> We're already looking at trillions of permutations! >>> >>> It seems to me be.surbl.org should not do an internal database query >>> on single domain names, but instead do a BigEvil regex (like SA >>> does). At least, that is what I thought it would do; and how I had >>> hoped it would have been. >> >> Because the DNS system is designed to work with static lists of data, >> not regex patterns. >> >> Theoretically you could design a DNS server front-end on a regex >> engine that would take fixed DNS queries and do regex matches. >> However the DNS zone-transfer mechanism is designed to deal with >> fixed data-sets, not regexes. > >DNS zone-transfers would not be affected. It would still be >the same, static >data-set being pushed back and forth. In fact, the >be.surbl.org DNS server >would not contain a regular DNS database at all (!), as it merely does >regexes on incoming queries! If anything, you'd have to transer BigEvil >regex rules, really. > >> Another detail, is that the DNS system is heavily based upon the >> concept of cacheing. Currently there's no meaningful way to cache a >> regex, only the results of every lookup permutation. That would >> impose an unrealistic demand on the down-stream DNS servers (remember >> those trillions of permutations!), > >Not at the client-side. When I were to query >"9001hosting.com.be.surbl.org", >there would be no overhead whatsoever, cache-wise, for a front-end DNS >system that does a behind-the-scenes regex on the query. It would still >reply with a single response. It would, to the client, appear >no different >then if the DNS server had retrieved the domain name from database. > >The caching DNS server at be.surbl.org itself might grow big, >though, as it >potentially holds those trillions of those domain names. But >it would, as >you say, really only cache the result of each looked-up >permutation. And no >more. And, in this, it would be no different from a regular DNS server. > >> Another detail, you're adding to the CPU load on the "regex-ifed" DNS >> servers. Doing a regex match is more CPU intensive than a database >> lookup on a fixed data set. When you have the potential of thousands >> or millions of clients beating upon a handfull of DNS servers, the >> CPU load considerations become critical. > >This is true. And it may indeed be quite a problem. > >> Might as well stick with BigEvil.cf > >My point exactly; without using real regexes in be.surbl.org, dropping >BigEvil.cf, for now, is ill-advised, really. > >Cheers! > >- Mark Wow that was a lot to read for a Monday Morning :) Bigevil won't be dropped. But it will change. You will have lots of options in the near future. Lots of options ;) --Chris

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