Discuss

discuss@lists.surbl.org

1867 discussions

RE: Applying SURBL against blog comment spammers
by Chris Santerre 03 Sep '04

03 Sep '04

>-----Original Message----- >From: Jeff Chan [mailto:jeffc@surbl.org] >Sent: Thursday, September 02, 2004 9:04 PM >To: spamassassin-users(a)incubator.apache.org >Cc: SURBL Discuss >Subject: Re: Applying SURBL against blog comment spammers > > >On Thursday, September 2, 2004, 5:43:26 PM, Loren Wilton wrote: >>> Given the lack of commonality, it may not make much sense to >>> add to the mail spam lists, since it would be an extra 2000+ >>> records that would probably not get hits on mail. >>> >>> The MT-Blacklist doesn't seem to update too frequently (the >>> last new record was from 8/29) and has about 2000 records. >>> Matthew's list was pretty sparse so far. So I'm still >>> pondering things. > >> Just from a technical/philosophical point, I think a separate list is >> desirable. Although I agree that making it part of multi >would probably be >> the way to go, and I agree with the basic concept that "spam >is spam". > >> However, I think the reasons for a separate list are: > >> 1. Separate source feed. A new list allows the source >feed to be more >> easily documented. >> 2. (As stated) little overlap with email spammers, at >least so far. >> 3. Probably a different update cycle and removal (from >old age) cycle >> requirement > >> The different means of updating and possibly different aging >method are high >> on my list of reasons for suggesting a separate list. On >the other hand, >> having it part of multi would be nice, since (I assume, possibly >> incorrectly) that one query could check a lot of lists based >on the bitmap. > >Correct. I'm still wavering if a blog spam list should be part >of multi. There are programs that use multi but (unadvisedly) >don't differentiate between the source lists. That kind of >argues for keeping multi focussed on only mail spam and making >a blog spam list separate. On the other hand there's much less >overhead in adding a list internally to multi than setting up >a whole new list. > >> It probably would also be good to devote some thought to how >entries will be >> added to this list and validated. We surely don't want some >annoyed blog >> spammer spamming the list with every valid doamin they can find! > >Yes, data quality is always an issue. Any of these ventures will >struggle if spammers are able to poison the data. Keeping >legitimate domains out of any feed is key and provisions would >need to be made for that. > As always I agree. I think any new idea should be kept out of mutli until more testing is done. Having said that, if a blog spam matches all the requirments we would use in a SURBL entry now, then why not list? And why not list in the regular WS list? I'm saying I would only add hand checked domains like those I found in JM's example. Preemptive listings. Again, only domains that are obvious, like the examples I listed. If there is any question of a blog spam domain being used for legit, then it follows the very same rules we have now. Don't blacklist. Add to unclassified ;) --Chris

1 0

RE: [SURBL-Discuss] Whitelist Please
by Chris Santerre 03 Sep '04

03 Sep '04

>-----Original Message----- >From: Jeff Chan [mailto:jeffc@surbl.org] >Sent: Thursday, September 02, 2004 9:24 AM >To: SURBL Discuss >Subject: Re: [SURBL-Discuss] Whitelist Please > > >On Thursday, September 2, 2004, 6:19:04 AM, Chris Santerre wrote: >> Uh...I'm confused. So you did or did not whitelist all of >these. I would >> have thought that this one link would have been enough. Confused :) > >They are all whitelisted. > >> Flogo sucks donkey doughnuts. HOWEVER there are lusers who >sign up for it. I >> would not list them. But some of these other domains, I would list. > >I'm going to assume similar policies across all their domains. >It doesn't make much sense for them to be tame spammer on some >sites and uber spammer on others. > >> euniverse is not squeeky clean. > >Never said they were. The question is do they have legitimate >uses, and it sounds like the answer is yes. > >Jeff C. > Did I ever send the RBL results for dietingplans.com? Results: Positive=9, Negative=21 (2004-09-01 19:09:48 UTC) * @SPAM/spamsource: 12.129.205/24: 553 SPAM,BULK ATT mail3051.flowgo.com special(a)intelligentx.com 2002-04; SBL http://www.spamhaus.org/SBL/sbl.lasso?query=SBL5535; SPEWS [1] euniverse/yourbigvote, see http://spews.org/ask.cgi?S1 * AHBL/dnsbl.ahbl.org: 12.129.205/24: 553 AHBL Spam Source; AHBL Open Proxy [Details] * AUDNSBL/dnsbl.net.au: 12.129.205/24: 553 AUDNSBL Multiple Spam Traps Block List [Remove] * DRBL/drbl.all: 12.129.205/24: 553 DRBL weight: 1.4; vote.drbl.sandy.ru(a)ns.sci-nnov.ru/0.6 vote.drbl.vsu.ru(a)ns.vsu.ru/0.8; flowgo.com; flowgo.com spam engine. 20020218. Blocked by blacklist-admin(a)vsu.ru * SBL/spamhaus.org: 12.129.205/24: 553 SBL http://www.spamhaus.org/SBL/sbl.lasso?query=SBL5535 * SPEWS/spews.org: 12.129.205/24: 553 SPEWS2 [1] euniverse/yourbigvote, see http://spews.org/ask.cgi?S1677 * BLARS/block.blars.org: INET 127.3.8.32 * INTERSIL/flowgo.bulk: Flowgo/Euniverse/media synergy/etc.; http://www.cauce.org/incidents/flonetwork.com/index.shtml; 2001May01; dig TXT netlist.flowgoaway.com for CIDR list * FIVETEN/flonetwork.com.bulk: UNKNOWN TXT (permfail,nodata) I mean, to me this is a no brainer to list. :) --Chris (I'm annoying sometimes!)

4 3

RE: Applying SURBL against blog comment spammers
by Chris Santerre 03 Sep '04

03 Sep '04

>-----Original Message----- >From: Jeff Chan [mailto:jeffc@surbl.org] >Sent: Thursday, September 02, 2004 3:24 AM >To: SATalk >Cc: SURBL Discuss >Subject: Re: Applying SURBL against blog comment spammers > > >On Wednesday, September 1, 2004, 11:25:40 PM, Matthew Hunter wrote: >> I just whipped up some code to reject trackback/comment spam >> using a SURBL as a data source. Unfortunately, the people >> spamming my weblogs aren't in multi.surbl.org, so I will have to >> maintain my own local blacklist server. > >> The single most useful thing that could be done wrt fighting spam >> in weblogs would be an SURBL source that had the offending >> domains in it. I would offer to make mine public, but I don't >> have the IP to spare at the moment... > >> Does anyone know of an appropriate SURBL list? > >Hi Matthew, >We could perhaps set up a separate SURBL for blog spammers. >It would be a slight shift in focus since the other SURBLs are >all for email spam. Can you give an idea of how many records >you have? > >Also have you tried Jay Allen's MT-Blacklist/Comment Spam >list: > > http://www.jayallen.org/comment_spam/ > >It would be interesting to look at your data to see if there's >much overlap with our existing lists. In the case of Jay's data, >there's nearly none. > Hell I'm feeling a little saucy this morning so lets mull this over. This goes against Jeff's thoughts. But if they are spamming, then just add them to SURBL. Does it matter if they spam email or blogs? To me, not really. Adding them to the regular SURBL is sure to cause them some pain. Legit domains still get removed. SO I say, go ahead and add them. However I would like to see an example of a spam'd blog. I've never seen one. --Chris

7 12

Re: RE: [SURBL-Discuss] Proposing a greylist
by Rob McEwen 03 Sep '04

03 Sep '04

> > 1)We DO NOT include it in multi. > > Please reconsider this... Including it in multi means a lot less DNS > traffic, and that's a serious plus when you're using a greylist that you > probably won't use to increase the spam score by much. > > Bret Bret, You are reinforcing all of Jeff's arguments for NOT doing greylisting. If we create an unconfirmed.surbl.org list and then merge this into the multi list, then we might as well not worry about FPs anymore. Heck, we might was well throw every domain found in every spamtrap and be done with spam forever ;) Also, the fact that you would even suggest this further proves Jeff's point. I'm all in favor of creating an unconfirmed.surbl.org list. But it would HAVE to stay separate from the multi.surbl.org list or ALL the problems Jeff described will come true. ...not to mention, this would also result in even MORE DNS traffic because many of use would then start using EVERY list but the multi list. Rob McEwen

2 1

Re: Applying SURBL against blog comment spammers
by Jeff Chan 03 Sep '04

03 Sep '04

On Thursday, September 2, 2004, 5:43:26 PM, Loren Wilton wrote: >> Given the lack of commonality, it may not make much sense to >> add to the mail spam lists, since it would be an extra 2000+ >> records that would probably not get hits on mail. >> >> The MT-Blacklist doesn't seem to update too frequently (the >> last new record was from 8/29) and has about 2000 records. >> Matthew's list was pretty sparse so far. So I'm still >> pondering things. > Just from a technical/philosophical point, I think a separate list is > desirable. Although I agree that making it part of multi would probably be > the way to go, and I agree with the basic concept that "spam is spam". > However, I think the reasons for a separate list are: > 1. Separate source feed. A new list allows the source feed to be more > easily documented. > 2. (As stated) little overlap with email spammers, at least so far. > 3. Probably a different update cycle and removal (from old age) cycle > requirement > The different means of updating and possibly different aging method are high > on my list of reasons for suggesting a separate list. On the other hand, > having it part of multi would be nice, since (I assume, possibly > incorrectly) that one query could check a lot of lists based on the bitmap. Correct. I'm still wavering if a blog spam list should be part of multi. There are programs that use multi but (unadvisedly) don't differentiate between the source lists. That kind of argues for keeping multi focussed on only mail spam and making a blog spam list separate. On the other hand there's much less overhead in adding a list internally to multi than setting up a whole new list. > It probably would also be good to devote some thought to how entries will be > added to this list and validated. We surely don't want some annoyed blog > spammer spamming the list with every valid doamin they can find! Yes, data quality is always an issue. Any of these ventures will struggle if spammers are able to poison the data. Keeping legitimate domains out of any feed is key and provisions would need to be made for that. Jeff C. -- Jeff Chan mailto:jeffc@surbl.org http://www.surbl.org/

1 0

Re: [SURBL-Discuss] Proposing a greylist
by Rob McEwen 03 Sep '04

03 Sep '04

> OK, here are a few thoughts, after reading this thread, and making a few > specific replies. I think that combining (1) Ryan's specific proposal in his previous message ...with... (2) the cautions in my "just to be sure... so that... unconfirmed.surbl.org will get too convoluted and too bulky to be effective" previous message... (as well as keeping unconfirmed.surbl.org OUT of multi.surbl.org) ...will be a winner! What do you think Jeff?

2 1

Re: [SURBL-Discuss] Proposing a greylist
by Rob McEwen 03 Sep '04

03 Sep '04

> Good idea. Let's do it. I'll be able to submit more domains to *this* > list than I could to ws. It will finally give meaning to that pile of > domains I always end up with and get ulcers trying to classify as black > or white. For the record... and just to be sure... I vote that unconfirmed.surbl.org NOT contain those things that we tend to agree with as NOT being spam, but sometimes gets reported as spam by end users. For example, people sometimes forget that they really DID subscribe to a particular newsletter, and then complain about it as being spam. The SallyFoster.com site is a great example where a one-time e-mail is sent only at the request of a relative or friend. Another example is a legitimate newsletter with an open-loop signup page where someone signed up their friends or enemies (without their knowledge) for the newsletter.... not good practice, but if it represents a tiny fraction of that newletter's distribution, the newsletter is otherwise totally opt-in, and there are few to none NANAS hits... then this kind of stuff shouldn't get on the greylist. Instead, unconfirmed.surbl.org ought to be for those really hard to classify things that ARE getting NANAS hits, that DO hit spamtraps, but that have enough legitimate purposes to not get placed in the regular SURBL lists. If this advice is not heeded, then unconfirmed.surbl.org will get too convoluted and too bulky to be effective. Rob McEwen

3 2

Re: [SURBL-Discuss] Proposing a greylist
by Rob McEwen 03 Sep '04

03 Sep '04

>It would reduce overall traffic and >ease administration to include it in multi One thing that I failed to explain is that the software I use DOES report the return code, but was constructed to work with SURBL without giving a lot of thought to the idea of doing different things based particular return codes. It reports the SURBL code for every "hit" in the log files, but within the programming logic, the variable that can be acted on is assigned more of a yes/no as to whether or not there was a single valid hit. Therefore, not every SURBL has the option to do different things based on the return code. Also, it would be EASY... very easy... for an administrator who DOES have option to do different things based on return codes to not exercise these options and block ALL multi stuff, regardless of the return code. (All administrators are not going to be SURBL gurus) Rob McEwen

4 3

Immediate WL ASAP
by Chris Santerre 03 Sep '04

03 Sep '04

206.132.3.30/ Listed in SURBL. Bigfoot interactive. I don't doubt they might have been once used by spammers. But it is blocking junk mail from Target, the redneck superstore! Yeeehaaaawww! --Chris (I didn't munge!)

2 1

RE: [SURBL-Discuss] Proposing a greylist
by Chris Santerre 02 Sep '04

02 Sep '04

>-----Original Message----- >From: Bret Miller [mailto:bret.miller@wcg.org] >Sent: Thursday, September 02, 2004 1:45 PM >To: rob(a)powerviewsystems.com; SURBL Discussion list >Subject: RE: [SURBL-Discuss] Proposing a greylist > > >OK, OK... How about an "evilmulti" that included "unconfirmed", which >would increase surbl's data size and processing-- having to build two >multi lists, but would significantly reduce DNS query traffic since >those using the "unconfirmed" list and the "multi" list could use a >single query per URI instead of 2 per URI. > >Bret I say that can be determined after testing the list in general. But for now, mutli is no no. :) Now, lets say for giggles Jeff says, "OK I agree to test this theory." Uh....how do we submit to it? Where is it? And who took my screwdrivers from my basement? --Chris

2 1

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