Slashdot Mirror
Fighting the Hydra -- A Spam Warrior's Tale
Selanit writes "Salon has an interesting article about the battle against spam from the viewpoint of Suresh Ramasubramanian, a sysadmin working in Hong Kong. His most interesting complaint concerns the fragmentation of anti-spam forces: not only does he have to deal with spammers, but also with anti-spammers who assume because his company is Chinese that he isn't doing anything about spam. Hmm ... decentralized opponents striking from the shadows against quarreling allies. Does this sound familiar to anyone else?"
Just one question... what if the spammer doesn't connect to your SMTP server to send billions of messages from it? What if the spammer (with half a brain, and some scripting ability), only sends a few emails through your SMTP server? Most SMTP servers are wide open still, and simply sending 10 emails on one server and moving on to another open server would be so low that statistical usage wouldn't show anything on the radar screen... or did I not understand what you are trying to do?
From the article: expert spammers can also switch IP addresses as quickly as the blocks are applied.
A honeypot for spam - mentioned here previously, I think - would be one answer. It would recognize a spammer and, instead of disconnecting, it would accept all the spam - very sllloooowwwly, then discard it. It's not a trivial programming task, since the spam would have to be recognized, then treated differently from that point on from regular email. But it's feasible, I think and would help fight the large scale attack noted at the beginning of the linked article.
"that's not encryption - it's a new perl script that I'm working on..." - from some Matrix parody
Fun? The article repeatedly made the point that fighting spam is no fun at all.
Peace has finally come from a package called Active Spam Killer [paganini.net], a package which works from a white list, and provides a convenient way for new correspondents to get themselves onto the whitelist.
You're adding an authentication layer to your specific mail account. Now, all we need to do is implement 4.1234E13 different mail account authentication systems. Each with it's own bugs, weirdo assumptions (HTML only, perhaps? Imagine how Mickysoft might do this...) and other deficiencies. Everyone you correspond with will have a different one. What fun!
Authentication is the only feasible solution to spam. If we could collectively decide on a method of implementing it in a standard fashion we could avoid the mess.
Don't hold your breath.
Maw! Fire up the karma burner!
Just the thought of this makes me sick.. Almost as sick as those who make spamming profitable.
Now that I've thought about it. How is spamming still profitable? Are there that many people out there that are into having sex with farm animals? Or believe their are pills that increase life span? Who the hell are these people?
Now, some people may feel it's my own fault for taking advantage of the part of RFC 2821 which states that if a mailserver defers checking to see if it can relay or deliver the mail then "These servers SHOULD treat a failure for one or more recipients as a "subsequent failure" and return a mail message as discussed in section 6.".
But, I guess they feel that everyone runs sendmail, so every time they test my mailserver, I end up with another batch of relay rejected messages intended for them sitting in my postmaster mailbox.
There are two parts of this that bug me:
1) you would have their real email address and
2) you could use a 'what number is this a picture of' type questions. The problem is figuring out how to make it multilingual.
But really it dosn't need to be standardized at all, since these things are going to have to be handled by real people, rather then computers.
autopr0n is like, down and stuff.
Taken from a larger context, spam is just another facet in life from which emerges attempts to control our behavior.
A glaring example brought forward by the war in Iraq is the ceaseless barrage of sloganeering one faces these days. Some of it in favor of the war, some against. Some more coordinated than others.
How much remains when the content added to bend our will is removed? How much from the war news, from life in general?
I'm sick of it. Life is complex enough without having to move about in a cloud of misleading information.
No wonder everyone is half nuts these days. GIGO.
> Yeah, these people blocking all mail from Chinese and korean
> subdomains are idiots. How are they supposed to work with anti-spammers
> there if they can't even talk to them?
While spam might come from Chinese or Korean subdomains, it usually is about American products to the degree that the stuff offered is completely useless for someone from the Netherlands. They might at least filter on the target email address you'd think.
Let's hope so. Then I'd just accept all mail slowly and spam would go away!
Seriously there are flaws in this kind of defense. First, I'm already seeing several spammers who already send mail slowly, probably to avoid setting off statistical trappers and to make it harder to scan through log files. Also don't forget that the spammers usually have much more bandwidth than the recipient; you can never win by trying to fight the battle of resources!
BTW, this is NOT very tricky programming to do if you use the Milter programming interface to sendmail...in fact it is quite easy to do. But like I mentioned, you're sort of self defeating, because you burn your own resources by being slow.
<link rel="DoNotEmail" href="mailto:aa0u@kjernsmo.net" />
(yeah, that's a real, living trollbox, spambots, do your worst! :-) ) Very few users will ever see this, but the spambots will harvest it. It is clear that many of them do.
The other thing you mention, I think that is what is meant by a Teergrube. Marc Merlin has some good stuff on using Exim and SpamAssassin to reject messages or making spammers stick in a teergrube. He has some debs too.
Unfortunately, I haven't had time and I haven't been feeling adventurous enough to try all this, but clearly, it works well.
Employee of Inrupt, Project Release Manager and Community Manager for Solid
I don't see how anyone is going to trust the USA in an international treaty any time soon. The USA will simply opt out of any regulation as soon as it hampers their economic well-being.
First.
Get off the USA bashing kick, all countries look after their own economic needs. (aka, sweat shops are illegal in the USA, but the WTO says that in 3rd world countries as its the only work available, they are legal...)
Second.
The USA (aka Federal Government) has nothing to do with Spam guidelines unless its a Federal Law. (Which could be considered a violation of Interstate Commerce, thats part of the reason no laws are passed at the Federal level... btw, IANAL...) This is also why we are trying to pass State level laws for Spam.
But, if ISPs who want to deal with SPAM can join blacklists, whitelists, coalition, etc. Nothing is stopping them. But on the Other side, there is money to be made in Spam, and companies willing to make a buck will do it. (All around the world, not just the USA or Hong Kong.)
One possible solution to the problem of bounce messages is to not send them.
When an undeliverable mail arrives check against a set of criteria, and if the mail looks like spam then don't send the bounce, since the adresses are likely to be faked anyway. This way the poor sod that got his adress used as the sender won't recieve (as many) bounces. The disadvantage is the possibility for false positives, that a legitimate mail might be tagged as spam and the sender won't see the bounce. Anyway for a large mail service it should be relatively easy to detect multiple identical undeliverable mails, and then don't bounce for them.
In the event that a spammer uses a real "bounce-to" address to clean their adress list this would rob them of that possibility too
- We are the slashdot. Resistance is futile. Prepare to be moderated -
Shuresh is also a regular poster in the newsgroup news.admin.net-abuse.email, a discussion forum about e-mail abuse.
Check his postings from the Google Groups archive.
How do people feel about scripts to fill website logs with crap? Here's mine, quick and dirty, written in about 30 seconds because I was pissed off:
#!/bin/bashCOUNT=0
while [ $COUNT -lt 10000 ]; do
lynx -dump http://www.resumeagencies.com/recruiterspage.asp?
sleep 1
let COUNT=COUNT+1
echo $COUNT
done
Note the fact that I'm calling what I hope is a dynamic page, so with luck, I'm wasting their server's processor time. The script is otherwise, as you can see, completely unrefined.
Legality, anyone? Other problems (despite the obvious fact that I have to waste my bandwidth to fuck with spammers)? Obviously, it's a DoS attack of sorts, but then again, so is an unsolicited e-mail. If they want to challenge me legally on that point, then I will do the same to them. My website very clearly points to the policies which apply to all e-mails sent to my domain.
Fire and Meat. Yummy.
There was something about the article that bothered me - perhaps it was just unclear reporting, or perhaps it wasn't.
According to the article, this guy is having to block off a flood of mail from spammers to his system. The way I read the article, this flood is not for Outblaze users, but just for relaying. Why the bleep does his mail server even accept this mail? Any modern sensible set up mail server should follow a ruleset like:
if (sender is one of my users)
accept
else if (recepient is one of my users)
accept
else
bugger off spammer
endif
Ideally, the mail server would log system that were trying to send mail that didn't pass that test and tell the router to drop packets from them for a few hours.
Bam! 90% of problem solved.
Having received spams relayed by Outblaze servers, I don't think that's what is happening. I think they are running open mail servers, and trying to keep the spammers from using them.
I could be wrong, but that's how I read the article.
www.eFax.com are spammers
First, try to convince the server to give you a listing of
Then, turn it into a big list of URLs for pages and images, say "url_file_you_made". Finally, write a shell script to use that for nefarious purposes, like this:That one really can suck down some bandwidth, especially if you tweak the usleep. In this case, each download is forked off and lasts for at most 1 second, so with usleep at
Also if the form is POST, you can use good ol' curl again like this to poison it:note it isn't URL encoded. That's multipart. You can do URL encoded POST with
Fuck Beta. Fuck Dice
Heh...I run sendmail on a 486DX/33. I accept everything very slowly. :-)
But in all seriousness - I expect that some day, somebody will find a security hole which I've overlooked. However, when that day comes, my little 486 certainly won't be much of an asset. If a spammer finds a way to exploit sendmail, and tries to relay 5 bazillion e-mails, my box would certainly crash. I consider it a boon to the internet if I make myself very difficult to exploit, and sticking a just-barely-does-the-job server up there is a step in that direction. I'd rather have my home server fall on its sword than help fight a battle for the spammers.
You know this is trivial to defeat right?
Detect and run from, sure, but not _defeat_. (for a value or "defeat" == "get yer spam through")
Excessively slow server detection will be a standard feature of all next generation spam software.
Oh it is now. Has been, for at least a year. My buddy, who runs his own mail server, teergrubes anything he can detect as spam. The spammers flee, then remove him from their lists. He cares not whether this is automatic or requires manual effort on the part of the spammer. They go away.
I'd make it even simpler: teergrube _everything_, for about fifteen seconds a line. Legit mail has to tolerate these kinds of delays (and much worse, in fact) in order to get through to servers which are stuffed with spam traffic. A spammer can't afford to fool around for even one minute to send a message - he has to send a million a day in order to make money. Of course this probably wouldn't work for Mr. Ramasubramanian, but it will for my friend, and for me if I ever put up a mail server. You'd probably be pleasantly surprised at how many of those 32767+ connections will be dropped _immediately_ at the first continuation reply, no matter how short its delay.
I still think you can never win the resource battle
Sure we can. A thousand spammers facing 1,000,000 tarpits haven't a chance.
Exceeding the recommended torque is not recommended.