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
three guesses and the first two don't count...
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?
Presently the only problem with this is that there are no plug-ins for the MTAs themselves yet. The plug-in is for spamassassin. That means that the message has to be transfered and passed onto Spamassassin before it can be dropped or tagged whereas, the other RBLs allow you to drop the connection before the message is transfered. This problem will be solved once there are plug-ins for the MTAs themselves.
But, I have to ask, why aren't existing RBLs like Spamhaus effective. They should be far more effective than the ~40% that I am experiencing.
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.
I am continually adding certain domain names to my spam filter, if found in text. I'd love it for this tool to do it for me, as long as I can trust the low false positive rate.
Mencken had it right. So glad that's old news.
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.
We can't ever have a workable spam filter because of the adaptability of spam. However much you try, the spammers will come up with a way to circumvent your block. How long do you think that it would take for the spammers to figure out how to send emails that the whitelist software would mistake for legit? Nothing short of a trained monkey going through your inbox will sort this out effectively.
------- "A true friend stabs you in the front." -Eliot
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.
I've been playing with a honeypot email account for the last couple of months. Those "remove me from your list" links sure are a good way to get more spam (Spammers are lying scum). I hope this SURBL suggestion doesn't get implemented at the ISP level. Then I wouldn't be able to go the spammers site (carefully editing the URL as needed, and with Mozilla) and sign up my honeypot account for more penis enlargement spam!
Look at the mod history of the parent, and remember you don't get Karma for Funny mods. Lesson: never make a joke when logged in.
My suggestion is to present the user with those images containing a word (like the one used by Yahoo! etc during registration) everytime the user needs to send a mail (before clicking Send). This is a reasonably difficult Turing-type tests which could weed out a majority of automated scripts/spambots.
An immediate problem with this scheme that I see is that for the words to be sufficiently random and crack-proof, they would have to be served in real-time to the mail program, and could need tweaks in current mail programs. A static list coded into the program might be too easy to break. This isn't too impractical, since an Internet connection is assumed during most email transactions.
Another problem, ofcourse is that it will not work with text-based mailers like PINE, but as long as it weeds out all the spam sent from all the freebie mail accounts we could see an improvement.
Comments/Suggestions?
An Indian-American Hindu committed to non-violent thought/speech/action alarmed by the global explosion of radical Islam
Sounds like a soft drink name...
Good point, but I think it will take very little time for developers to enhance spamassasin to mark anything as spam if it has more than, say, 5, URIs in it that don't point to the same domain. (If this feature isn't in spamassassin already.)
It would be interesting seeing how effective this would be. I can see some problems with it though. Most of the spam I get uses a msn or yahoo address which just redirects you. My impression, is that this would become valid now. I also see problems with things like tiny url. Which is just an alias for another url, supposedly much larger. This would mean banning the use of all these types of urls.
Ok, so you want me to sort through (validate???) tens of thousands or millions of IP addresses to create my own blacklist? That's way too much work!!! If I'm going to implement my own IP blacklist, I'm going to cut down the administrative overhead and just use this entry:
0.0.0.0/0 REJECT
Seriously, an RBL is an IP blacklist but, the list is maintained in an automated fashion by thousands of systems that report back to the RBL. RBLs are really a much better solution that your own personal list.
WTFATAM
Cloud City Digital: DVD Production at its cheapest/finest
Let's coin a new term: YASSI for yet another stupid spam-related idea.
This boneheaded scheme falls into the same category as all content-based filtering systems: It doesn't address the most henous crime on the part of spammers, which is the consumption of bandwidth and network resources. And like other client-side/content-based filtering systems, the system will work about 12 minutes before the spammers figure out a way around it and then your system doesn't work. And of course, you'll have to constantly update it in order to make in effective, which means you have yet another piece of software that requires routine updating, slows down the mail service, your computer and everything in between. And after all that, you'll still get spam.
The main reason spam is prevalent is because SPAMMERS STEAL BANDWIDTH WITHOUT PAYING FOR IT. When you force them to operate from a single location, then they have to act ethically and then they have to pay premium money to spam, and then they go out of business because it's only economical when they steal resources.
You don't have content-based filtering on other primary methods of communication. It's a federal crime to go through mail; (at least before Patriot) you needed a court order to tap phones. E-mail should be an equally sacred communication medium that shouldn't be subject to "strip searches" before it hits your inbox. And this whole boneheaded scheme will NEVER stop spam in the first place, so let's stop pursuing these efforts.
RBLs are most effective right now. The worm invasion is evidence of that, as spammers are finding less IP space to operate from so they're engaging in more aggressive tactics to take over peoples' machines, which, hopefully sooner-or-later, will land these sleazebags in jail.
... it would only be a matter of seconds before http://www.sco.com/ was added to the block list.
Spam is not going to stop until every single user is postively identified on the internet. And it will happen. Get used to the idea.
There is already a cure for spam - give everyone unlimited email addresses, give out different addresses to different recipients, and delete any email that receives spam (along with possibly sending an email of complaint to whoever you originally have that particular address to). The whole thing could easily be built into mail clients and supported by mail providers. It works fine for me. It costs me $35 to buy my own domain and a one off payment of about $30 to zoneedit to set up the mail forwarding. It works so well, and has worked for the least 3 or 4 years, that I almost suspect that there is some kind of conspiracy to overlook this method in order to promote other dubious methods.
Doesn't it make you feel good to know that our freedoms are protected by politicans, lawyers and journalists.
All in all the only place I get spam is on an old hotmail account.
I like how this troll starts out non-trollish, and becomes gradualy more blatent as it goes on. Counting on mods not reading the whole post.... supurb....
Unfortunately I really don't see anything new or original in this idea. Until they start prosecuting these morons, we're not going to have a viable solution. By morons I mean the people that are BUYING this crap, rather than sending it ;)
What about encoded URLs? And I'm not just talking HTTP escaped, I mean base64-encoded crap.
Are you going to spend the CPU power on decoding, parsing, and checking each incoming message? On a high-traffic mailserver, that's a lot of CPU.
Sounds like a great idea especially for home users or some such but, as soon as you look at the bigger picture things start to break down. First of all, what about legitimate mailinglists? Some of them have hundreds of thousands of addresses. You want the administrator to have to go through and click a web page for each and every address on the list? Never gonna happen.
What about corporate use? Many legitimate emails go to a dozen recipients almost like a mailinglist. Think of the lost productivity with the senders clicking webpages for each reply and forward. Think of the dreaded Everyone group. Well, that would be an advantage but, you start to see what I mean.
Your idea is very similar in concept to a few others in that it requires a cost, someone reading a picture and clicking a button for the message to transfer. This scheme is better implemented by the various proposals that invoke a computational cost for each message transferred, like those from AOL Yahoo and Microsoft but, even these proposals all have major drawbacks and no one is rushing to implement them.
See the above list? Your post fits into:
(x) Requires immediate total cooperation from everybody at once
Also, accessibility, custom SMTP clients, yadda yadda yadda... but you've already realized your mistake so I'll stop now.
Sounds like the start of a good omlette if you ask me.
I would suggest that this solution be implemented mainly by freebie "webmail" accounts rather than in the Corporate or other "trusted" environments. Most mailing lists would be sent out using academic or corporate accounts anyway - definitely not freebie accounts - atleast that's my assumption, though it's not too outstretched.
An Indian-American Hindu committed to non-violent thought/speech/action alarmed by the global explosion of radical Islam
I want a XP version so I can install on my windoze box -- Joe 12 pack
Seriously, anything that has to be on the MTA has to be implemented by the ISP in general -duh!- and is technically impraticable for the even experienced user. And most of the humongous ISPs won't listen to a bunch of nerds (sarcasm) trying to get the latest gimmicks installed on their servers.
I've seen different and creative things like Cloudmark's Spamnet and maybe if someone should take their initiative and release a FOSS alternative...
Spam IS an annoyance and waste of bandwidth/time/money but when the medicine for it is just too hard or to expensive to implement it won't fly.
Dear aunt, let's set so double the killer delete select all
Simple: have Sendmail, Postfix, etc, all stick in a sleep() call before they spit out the mail acknowledgement! No spammer could possibly hope to send out a million e-mails when they can't open that many sockets on their machine.
Though it might help marginally, just like my filter file that scans for the URL's of some of the worst repeat offenders and for any .biz or .info URLs. But if it this approach catches on significantly, the more sophisticated spammers will just build their URLs in scripts.
Damn HTML mail and whoever invented that.
check this summary of spam methods.
http://netextend.com/junkmail
Overview
Solutions
Conclusion
Read the full report at
http://netextend.com/junkmail
One thing I've noticed a lot recently, is spammers including a big list of domains that have nothing to do with them in the text of thier junk mail. In the past 2 weeks, i've probally got about 10 spamcop reports for my customers, and in every case, my customer has had nothing to do with the junk mail, except for being listed in a list of about 15 URLs, that are not associated with the spammer. This system here says it has a whitelist for paces like ebay, paypal etc, but what about smaller people. They'd get blocked, and potentially lose business, due to something that they had absolutley nothing to do with.
Simple: spammers edit their clients to time out while waiting for acknowledgement.
Having just configured my email server with a ROBUST array of RBLs, I think this is a fantastic idea. I've been using the body_checks feature in postfix and manually adding violating URI's to create my own blacklist for several months now. I would love to benefit from a shared list. I don't care much for the white-list feature, that seems to me to create a backdoor for the spammer. Combined, RBL and private blacklisting (IPs and Addys) allow me to block 6000 plus spam A DAY. That's for a mere 150 plus users. Server side spam blocking using only Bayesian processing is an immense processor drain as is server side virus scanning. Look at it this way. Spammers need to make money. To do so you must be presented a URI to complete a transaction to make that money. They cannot easily change this URI without incurring cost so it will always be in the spam. Spammers who try to include too much "sales" content in their spams instead of a URI will be caught by a secondary bayesian filter. P.s. We have been successfully blocking encrypted URI's for months now. It's an easy rule to set up and legitimate users will never encrypt a URI. It's really quite beautiful.
Only out of laziness have I not implemented a whitelist approach to my email. I think this is probably the one true way to stop spam. (yes they could fake the addresses on my list but what are the chances of them getting the exact names on my list?)
What I would really like is a very easy to use whitelist manager at the MTA level. I've got norton spam block installed which does a good job but it doesn't bounce those messages back to the pricks who sent them. It does do a whitelist blacklist approach though.
Why not have a really cool plugin to mail programs that can manage your whitelist on the server. Then the only mail I get is the ones that I have purposely asked for. This would require some new standards put in place on the MTA but how hard could this really be? This doesn't work unless I can edit my whitelist from my email program.
This should work just like the phone. The only mail I get should be the ones that I've A) given my address to, and B) allow incoming messages from.
go ahead, bash the idea to the ground. my week isn't complete unless I see YetAnotherAntiSpam idea get pissed on at slashdot.
I'm getting the following spamassassin error after installing the SURBL plugin:
/etc/spamassassin/spamcop_uri.cf, rule SPAMCOP_URI_RBL, line 1, near "eval:"
Failed to compile URI SpamAssassin tests, skipping: ^I(syntax error at
any idea?
SpamAssassin version 2.63
Not really. It is another tool to make spammys lives difficult. Fighting spam is like tools on Unix. You put together a lot of little tools and come up with a big whomper to solve a problem.
Are there problems with this? Yes, there are some. It may be possible to "joe job" someone and get their domain listed. The same goes for RBLs on email servers, but those do tend to get sorted out sooner rather than later.
As far as objecting to the extra effort required to install, if it bothers you to spend a few hours now to stop endless hours of spam later, then put up with the spam and don't install the tool. If your users are going to revolt because you are using the tool, don't.
What I find interesting is the possibillity of using this to block spammy domains on my company network to keep clueless users from surfing to spammy's site while at work. This may force spammy to abandon using the web to spam and start handing out 800 numbers. That's fine, the same works on any text string, so blocking 800 numbers wouldn't be any more work than blocking web sites.
- The spam still has to be received in order to filter it. So bandwith, storage, and processing costs are still levied onto the receiver.
- It does nothing to stop the spam being SENT. It just hides it from the user.In other words, automated "JHD" ("Just Hit Delete").
- It's potentially easily defeated, as someone posted above. Just fill the message with widely whitelisted URL's and throw the whole thing into uselessness.
This isn't any closer to a silver bullet than any other filtering scheme. It might have a use for spoting mail that gets through SBL/XBL/DUHL/SPEWS/&c.lists, but worthless as a first line of defense.First, there is no spam magic bullet. There never will be.
This is very similar to what SpamPal along with the URLBody plugin does. (Client-side, Windows-only, also not a magic bullet.) The only difference being that this checks URLs against existing DNSBLs, and this is a new DNSBL specifically for this purpose.
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.
I deal with a lot of small clients who have their own e-mail servers or use e-mail servers provided by their ISP.
I have long since quit trying to do ANY kind of filtering and/or blocking at the server and left it up to each recipient at their end.
Why? Because TOO MUCH legitimate mail from other small companies continually gets blocked.
In my experience, many many small and home-based organizations are falsely reported and added to blocklists. Most of the time, those companies have no clue that either they're even on a blacklist or that their ISPs mail servers and/or entire netblocks have been added.
Blocklists suck... and I'm also now having to try and educate (and convince) clients that e-mail is not, nor has it ever been, a reliable form of communication.
How would blind people use this system? Are you just going to shut them all out?
Perhaps these projects should work together. Is there an MovableType plugin that does real-time trackback and comment spam blocking? I wonder how difficult it would be to have the blacklist plugin for MovableType use the same technology.
...if you want a free consistent testing of your email service.
Seriously, I have found and fixed problems quicker with my email service because I was *not* getting any Spam.
Regardless, Spam is certainly here to stay just like mosquitoes.
So buy some Off and start spraying!
I use a relay trap, adaptive filter with a simple keyword, 4 virus checking programs updating on the hour and whitelist the full email address of critical communicators to bring my Spam problems to a trickle.
Even that trickle has of late been next to zero as I adapt to any new technique.
The above system does require vigilance but pays off with Job Security.
Keep the spam a coming.
Can't leave em? Than love em!
This article advocates a ( ) 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 ( ) 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 ( ) 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 ( ) 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: ( ) Sorry dude, but I don't think it would work. ( ) This is a stupid idea, and you're a stupid person for suggesting it.
I've been doing this with my e-mail server (link in sig) for at least a year now. You can view the entire list of domains I filter at the Indie-Mail site. I even have a right up describing the why and how of this system on www.icarusindie.com called "An Analysis of Spam." And this is probably the 20th time I'm hawked this method up on Slashdot.
The process is mostly automated but when it comes to blacklisting a domain, it's manual. You cannot automate it fully because legitimate domains make it into spams. yahoo, msn and w3c.org are the most common. Even without it being intentional on the spammers part. The automated part rips through e-mail logs pulling out who it's to, from and the subject and then all the urls. I can then clear out any entries that are going to account that aren't mine. And from there I go through and make sure the ones that do get added are actually spam domains.
A computer can't really tell the difference between a spam domain and a legitimate domain. Humans can.
Spam domains are blatently labeled like "medsforyou.com" contain random letters and numbers or have the spams images linked in the root. 8000hosting.com/ad.jpg is a big giant clue that this is a spam domain. I've seen links with 6 or 7 subdomains tacked on. I manually remove all the subdomain garbage and block the main one.
The link ripper not only yanks out the root domain (and any subdomains) but also the exact URL of what it was pointing to.
The main problem with anti-spam tools is that they rely on computers to find patterns. Spammers are not computers. They're idiots but not computers. And you can't get around the fact you need humans to be effective without causing colateral damage. Spammers do not always use computer identifiable patterns.
The other "problem" with this method is that it only says 50% of the bandwidth cost at max since the server has to recieve the message for parsing. So it's only good for people offering e-mail services like myself who can't risk being over zealous in fighting spam which could result in losing other people's e-mail.
ISPs are forced for the sake of bandwidth to use IP blacklisting while this sort of method would work as a secondary filter.
Again, there is no silver bullet. You cannot just rely on one form of spam protection if your goal is irradication. This method is just the least error prone when done properly. IP blacklisting can be like nuking a small villiage to kill a fly. This is a highly focused and reasonably sized flyswatter that may occasionally flak off some paint if swung too hard.
And never underestimate the number of domains spammers own. I get a dozen or so new domains to filter out ever few days. I may get spam but at least it's costing them real money to get it to me.
Ben
Work Safe Porn
check out the anonymous e-mail through www.icarusindie.com
Instead of a picture I just present a riddle or other question.
A human can search Google for the answer in order to be able to send their anonymous message. A program would need to be written and trained to be able to do that specifically for my web-site. I'm confident only someone with an academic interest in such a challenge would do it. And so far it hasn't been abused.
I use the same type of challenge but render the text to an image and add some noise on the Indie-Mail sign up page to keep bots off.
I also use a server generated ChallengeID that must be present which prevents anyone from using any page but the one I offer to even attempt to submit the form. If you don't use my page, the challenge file isn't generated on the server and without the file the server will ignore the request to process the form. You are also never sent the question number or question in text form. Everything the server needs to know about what question you're supposed to supply the answer to is stored in the server generated file that never leaves the server. And everything you need to know is in an image.
So far that hasn't been broken either. And if it is, I can adapt faster than bots can.
Ben
Work Safe Porn
It's too late. By the time I can "parse" the freaking email, I already received it. The server already spent time with it, it already consumed bendwidth, it already filled my logs. I don't want spam anywhere near my router. All these filtering tools suck in the sense you have to receive the whole shebang before deciding it is SPAM. Nothing short of public castration will satisfy the problem.
And that's mob vigilantism violence.
Why not? Because its simple to get around:
They will use a free webhosting service...and one with a legitimate name. Set up the account so the index.html contains a redirect to the spammer's client site. That is going to be tough to stop.
If you install "spamass-milter", you can have your MTA bounce spam based upon SpamAssassin's evaluation. If you install this plug-in, you're good to go.
--
All I know about Bush is that Clinton had a job before he was president
Gozer the Traveler. He will come in one of the pre-chosen forms. During the rectification of the Vuldrini, the traveler came as a large and moving Torg. Then, during the third reconciliation of the last of the McKetrick supplicants, they chose a new form for him: that of a giant SURBL. Many Spammers and Mass mailers knew what it was to be roasted in the depths of the SURBL that day, I can tell you.
Exactly what I was going to say. Outlook probably renders many things into a URL which are not technically URLs. Who's to say a content filter can catch them all? If the content filter parses Javascript, then spammers will send in emails which run infinite loops and bog down the mail server. But even without, I'll bet there are quite a few Outlook bugs/features which render quite questionable URLs as links.
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.
You can also use this patch :. patch.gz
:
http://docsnyder.de/nospam/sa_check_blackhat_isps
(from the author)
Since spammers often host their spamvertised sites at spamfriendly ISPs (e. g. Chinanet), I've been doing some tests with "hat-checking" spamvertised URLs.
After resolving the URL hostname, the resulting IPs get RBL-checked against *.blackholes.us to find if they belong to a known spamfriendly ISP. If yes, the spam score will rise.
and you can use http://www.blackholes.us for the country/ISP zones.
My other idea of quarantine has yet to be proven to be a bad idea. Hopefully someone will now implement that.
Very well, (re)program ALL mailservers to adhere 100% without exception to all pertinent SMTP-related RFCs in their entirety (such as rfc821).
Try to nail the spammer and discconnect him/her before you get to the DATA phase of the connection. Otherwise, the mailserver will have to either accept the message unconditionally or return
570 Command DATA Message rejected due to content
after spam analysing the message like a particular 'clueless' ISP listed at rfc-ignorant.org does....
In this manner, header forgeries become (almost) impossible, sender hosts are properly FQDNed and whatnot....
Is spamcopurl the one you're referring to?
I kill off any message that contains a script tag instantly.
There's no legitimate use for javascript in an e-mail. E-mails are not web-pages. The only interaction an e-mail needs is a link if that.
If you need to show someone some neat javascript trick you post it on a site and tell the user to go to the site.
Joe jobs will go up eventually but like I said in my other post, you can't fight spammers with computers alone. There has to be some manual work involved.
Like beating them over the head with shovels and making sure the only domains that make it into the filter are legitimate spam domains.
It's also not costly to initiate a connection to domains to verify they're live. It'd be very easy to plug in a simple TCP/IP winsock class into part of the processing program to try to connect to the domains you're ripping out of e-mails.
Ben
Work Safe Porn
Where's the MTA/Milter that after detecting a spam, sends a guy to the spammers house who, upon arrival, shoots the spammer in the back of the head and then deposits a can of Hormel SPAM(tm) on the corpse?
I'd require no more than 1% false positives for spammer identification. Can't make an omelette and all that.
I'll pay $29.95 a month for that one.
In the law there is no overlap between theft and copyright infringement whatsoever.
While I'm not totally sold on the idea, it seemed to have enough promise to be worth trying. So here's a plugin to qpsmtpd, a replacement smtpd for qmail (it also delivers to postfix, IIRC). Implements most of the basic suggestions in SURBL's proposal.
(I'd like to be able to slap a bell and yell "first implementation!" in a childish slashdot fashion, but I'd be surprised if this really was the first, since it's easy to do a simple implementation and parallels similar DNSBLs in some respects.)
I don't think holding back technology is the answer. Your approach is like taking a step backward instead of confronting the problem in a proactive way.
Differences between the two lists and more topics about our project are described on the SURBL site. If anyone has a question or comment about SURBL you can write to me directly at jeffc at surbl dot org, or much better ask the growing SURBL community on our discussion list. The separate announcement list is a good way to keep up with news about the project. Archives of the lists are available on the list site.
Folks who have tried SURBL have generally been pleased with the results, and we expect to improve the ~60% spam detection rate and lower the already low (<0.1%) false positive rate further in the next version of the data engine behind sc.surbl.org. As has been previously mentioned, Devin Carraway has written an MTA use of SURBL domain data to check message body URIs in his qpsmtpd plugin called uribl. This is the first MTA use for SURBL that I've heard of, though I don't necessarily claim to have heard of all uses of SURBL so far. Some other folks are thinking about implementing a sendmail milter for which will probably use sc.surbl.org since they are also a major ISP source of SpamCop's data.
Since I probably won't be posting here too often, I'd like to thank some of the people who have been quietly very supportive and responsible for the success of this effort so far including Eric Kolve, Justin Mason, Daniel Quinlan, Raymond Dijkxhoorn, Julian Haight, Kelsey Cummings and others who already know how greatly they have helped to make SURBL possible.
One thing we could use some help with now are more BIND-compatible secondary DNS servers and rsynced rbldnsd servers. Please see the SURBL site for details, and lend a hand if you can. DNS traffic may get kind of heavy when SA 3.0 comes out since it has SURBL support in URIDNSBL (URIBL), so we definitely need some help with name service.
This is highly similar to chris.kainaw.com/ferriera with one exception. This system blocks domain names. Ferriera takes it one step further and blocks the IP addresses the domain names are mapped to.
The previous comment is purposely vague and generalized, but all of the facts are completely true.
>Colorless green dreams sleep furiously.
are you RACTER? is the policeman's beard half-constructed?
Both sc.surbl.org and ws.surbl.org SURBLs are intended to be used with message body scanning programs that can extact URI domains and compare them against name-type RBLs such as ours. Other uses of the lists such as in conventional RBL code won't work as well as the intended use. It needs to be stated clearly that our use of RBLs is pretty different from what they have been used for before. For example no name resolution of the message body domain is needed or desired.