Slashdot Mirror
A New Type Of Realtime Blocklist: The SURBL
Glamdrlng writes "The SURBL, or "Spam URI Realtime Blocklist", represents a nexus of RBL's and content filtering that may bring us one step closer to a spam magic bullet. While traditional RBL's perform a DNS lookup on the connecting mail server, SURBL's take this a step further by parsing the text of the email looking for URI's and doing a lookup on those web servers. They also prevent "joe jobs" by maintaining a whitelist of legitimate web servers whose domain names may show up in spam messages, e.g. EBay, Paypal, Microsoft, etc. The only requirement to implement the SURBL is a plugin on your MTA such as spamassassin that can parse the body of each email. While there is no MTA that directly supports SURBL's without a plugin, the author hints at one being in development."
Blocking URLs is an "ACTIVE" measure - and one that opens very bad
possibilities for abuse. While the While-List would protect against
this it will protect the BIG players on the market - it can still
wreak havoc on small/medium enterprises - e.g. a competitor of a
(pretty much) 'niche' firm could get a spam out advertising the
COMPETITOR in order to get HIM blocked...
Or - the other way around - a company gets itself a whitelisting
(via a "fake" joe-job on itself) and then continues spamming...
Please stick to PASSIVE measures! They can't be abused...
This article advocates a
(x) technical ( ) legislative ( ) market-based ( ) vigilante
approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)
( ) Spammers can easily use it to harvest email addresses
( ) Mailing lists and other legitimate email uses would be affected
( ) No one will be able to find the guy or collect the money
( ) It is defenseless against brute force attacks
( ) It will stop spam for two weeks and then we'll be stuck with it
(x) Users of email will not put up with it
( ) Microsoft will not put up with it
( ) The police will not put up with it
( ) Requires too much cooperation from spammers
( ) Requires immediate total cooperation from everybody at once
( ) Many email users cannot afford to lose business or alienate potential employers
( ) Spammers don't care about invalid addresses in their lists
( ) Anyone could anonymously destroy anyone else's career or business
Specifically, your plan fails to account for
( ) Laws expressly prohibiting it
( ) Lack of centrally controlling authority for email
( ) Open relays in foreign countries
( ) Ease of searching tiny alphanumeric address space of all email addresses
( ) Asshats
( ) Jurisdictional problems
( ) Unpopularity of weird new taxes
( ) Public reluctance to accept weird new forms of money
( ) Huge existing software investment in SMTP
( ) Susceptibility of protocols other than SMTP to attack
( ) Willingness of users to install OS patches received by email
( ) Armies of worm riddled broadband-connected Windows boxes
(x) Eternal arms race involved in all filtering approaches
( ) Extreme profitability of spam
( ) Joe jobs and/or identity theft
( ) Technically illiterate politicians
( ) Extreme stupidity on the part of people who do business with spammers
( ) Dishonesty on the part of spammers themselves
( ) Bandwidth costs that are unaffected by client filtering
( ) Outlook
and the following philosophical objections may also apply:
( ) Ideas similar to yours are easy to come up with, yet none have ever
been shown practical
( ) Any scheme based on opt-out is unacceptable
( ) SMTP headers should not be the subject of legislation
( ) Blacklists suck
(x) Whitelists suck
( ) We should be able to talk about Viagra without being censored
( ) Countermeasures should not involve wire fraud or credit card fraud
( ) Countermeasures should not involve sabotage of public networks
( ) Countermeasures must work if phased in gradually
( ) Sending email should be free
( ) Why should we have to trust you and your servers?
( ) Incompatiblity with open source or open source licenses
( ) Feel-good measures do nothing to solve the problem
( ) Temporary/one-time email addresses are cumbersome
( ) I don't want the government reading my email
( ) Killing them that way is not slow and painful enough
Furthermore, this is what I think about you:
(x) Sorry dude, but I don't think it would work.
( ) This is a stupid idea, and you're a stupid person for suggesting it.
( ) Nice try, assh0le! I'm going to find out where you live and burn your
house down!
There are millions of legitimate sites, and most of them aren't major sites like ebay, yahoo, etc. If I want to do a joe-job on an enemy small site, I can cause them a lot of pain by including their link. They'll have a dificult time someone wasn't spamming on their behalf.
I don't see this as the be-all, end-all for spam, but I do find it a very interesting and potentially very effective arrow for my spam-killer quiver.
"I'd rather be a lightning rod than a seismometer." -Ken Kesey
I mean, really, who comes up with the names for these things?
Show me one self-respecting spammer who's going to quake in their boots at the threat of being hit with a "SURBL".
("Oh no.. please.. not the SURBL. Don't SURBL me.. Its too much... no.. No.. NOOOOOO!)
Why not just call it a "NERF" and be done with it?
I propose we come up with Spam deterrents with names like "Knuckle Duster", "Jagged Bottle", "Bloodied Crowbar" and "Bubba the Love Truncheon".
Norman Cook's Ode to Sl
Combine it with spamassassin, and you can whitelist emails from companies that you want to recieve email from. Heck, with spamassassin you can give it a very small weight, and adjust the results manually. Every bit of extra information helps, and just ignoring it because it is compiled by somebody else doesn't make sense to me.
The only requirement to implement the SURBL is a plugin on your MTA such as spamassassin that can parse the body of each email.
Anything which requires extra software on the MTA or client side is not a simple requirement as it cannotn be implemented universally. This is doomed to fail.
From the article:
Though the article's author feels that "most SC users probably make an effort to uncheck legitimate domains to prevent false reporting," I have read reports that some mail server admins claim that SpamCop's users are rather likely to mistakenly report ham as spam. So the domain whitelist becomes important, but what practices have the SURBL administrators put in place to prevent corruption with respect to sites reported to whitelist at surbl dot org?
Spammers could then post their web sites as search URL's on Google, MSN, etc.. If you block those URL's then lots of people would complain that they can't send Google entries. Even if you solved that, then what happens with sites like tinyurl.com? If you block them then you have liability and legal issues to think about. No doubt the spammers will script up a number of ways to cloak the marketeers site urls.
This type of system is very abusable.
I know I have gotten spam reports from places like spam cop because people have included the URL of my website in their spam. My site had nothing to do with the spam other than the spammer was using an article on the site to back up his point of view.
This type of system could very easily be abused to blackhole many mailing lists.
A good way to start if you're running your own mailserver is to use an internal IP-based blacklist such as the one found here. It's incomplete due to Geocities limitations but send e-mail to that account and the guy running it will send you the whole file. It's a list that he's been compiling now for more than a year of IP blocks, mostly class Bs, that have virtually no useful SMTP traffic and should be completely cut off. This generally consists of the vast majority of Chinese, Korean and Brazillian DULs.
We've been able to effectively stop about 50% of the spam using these lists and save resources and bandwidth. What's left is to start RBL'ing the domestic DUL IP space (Comcast, SWBell, Bellsouth, etc.) on a class B-level until the ISPs start cracking down on their rogue users.
We can't ever have a workable spam filter because of the adaptability of spam.
This is because the solutions of the day focus on content instead of anonymity.
I've said it before, I'll probably say it again, get rid of unauthenticated email and the spam problem becomes a thousand times easier to fight. SPF and various RMX solutions exist in design today. If people want the spam problem to go away, that can be done today. Unfortunately people would rather piss and moan and call for legislation or perfect solutions than deal with these good ones today.
In the case of spam the perfect is the enemy of the good enough. We should stop spam today.
check this summary of spam methods.
http://netextend.com/junkmail
Overview
Solutions
Conclusion
Read the full report at
http://netextend.com/junkmail
At least 80% of our incoming spam, brute-force attacks, and other SMTP violations are coming from behind legitimate hosts like AOL, Verizon, Blueyonder, RoadRunner, and so on. Not forged IPs that pretend to be those hosts, but actual IPs that return to those MXs.
Look at today's list of brute-force attacks so far.. (as of Mon Apr 12 17:55:53 EDT 2004)
Every single one of these lists gets collected and reported, per day, per provider, and to date, not a single one of them has done anything to stop the abuse. In fact, it keeps increasing every day. The more we block, the faster they come at us.
This exact method is the basis of the MT-Blacklist comment-spam prevention system for Movable Type-based blogs. It works wonderfully, as it identifies spam on the basis of the one feature it must have to be successful--a link back to the spammer's site.
Sorry, but that's not because it's a SpamAssassin plugin vs an MTA plugin. That's because the SMTP protocol doesn't allow for what you describe.
Let's say I'm an MTA. When you connect to me, the first thing you do is introduce yourself, then tell me the envelope sender and envelope recipient of the message you're about to send, then give me the full message including headers and body. My options for blocking the message are:
Existing RBLs work at step 2. Filtering based on message content can't happen until step 7. You could build it into the MTA, but MTAs are complex enough as it is; using something else (SpamAssassin, Procmail, whatever) is a better idea.
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
I see one major problem with this, which is that Spammers might now be able to cause problems for legitimate websites simply by including their URL in the a Spam.
I'm a little sensitive to this since a spammer is actually Jo-jobbing one of my domains (not autopr0n), and I get hundreds of "user unknown" messages every day, along with a handful of messages telling me "my" email was blocked. It's really irritating.
But, if it's done right, it could work out pretty well. In fact, this would actually be effective against a lot of the current Spam out there, and kill Spam with off-site images.
Anyway, let me throw one countermeasure out there. Suppose spammers start including commonly mailed URLs (such as those on hotornot, yahoo, etc) in their spams in order to decrease the usefulness of these things. If this thing gets popular, expect to see a lot of Spam include a lot of random URLs the way they now include lots of random words. You'll also start to see things like "Javascript decryption" and other techniques to prevent machines from figuring out which, exactly, URL it is that is being advertised, rather then random noise.
autopr0n is like, down and stuff.