Slashdot Mirror

I have tried using Groovy for command line utilities and JVM performance has, in fact, been an issue. There are ways such as Nailgun for elminating JVM startup overhead, but Groovy (last I checked) doesn't provide an "out of box" solution.

Martian Software has an interesting (if somewhat dated) piece on using statistics to cause spammers pain. Essentially it's a real-time spam filtering system that slows down messages according to how "spammy" they seem to be. For individual messages, a few seconds or more delay would cause little if any problems, but when sending millions of spams, this is a very big issue indeed.

Personally I'd like to make the spammers pay - in CPU cycles - using methods like this. Of course I'd rather beat them witha baseball bat, but that's a wee bit illegal/impractical.

http://www.martiansoftware.com/nailgun/

Also, why would you CARE about the VM utilization? Also, Azureus (as I recall) has a multi-megabyte (up to 32?) cache for blocks it have recently been sent to attempt to reduce I/O, so it's sensible that it would take up more memory, JIT aside.

I have noticed that Azureus generates incredibly copious amounts of garbage though.

DDOS is an offensive maneuver. Here's an old but interesting article about a more defensive approach to inflict pain on spammers... a "dynamic tarpit" that identifies incoming messages as spam AS THEY ARE RECEIVED and then slows down the socket so the spam takes longer to deliver, consuming less resources at the receiving end and more at the sending end.

One is to set up a Teergrube/Tarpit (it's easy using the Linux ipchains TARPIT target) on a machine that shouldn't receive any mail by SMTP. You can tarpit everything, and nothing will get lost. (I think this is something everyone should do; it'd be neat if this sort of functionality was built into those little Linksys/Dlink firewall boxes...)

The other possibility is to set up your mail server so that, as soon as the client connects to your SMTP server spam filtering begins, and as soon as a message is determined to be spam -- ie, when the client is still connected -- you start tarpitting. By contrast, a lot of spam filtering happens after the message has been accepted and the connection closed.

TarProxy is meant to do just that. Here's an excellent article on how it works. The project page says it's in the middle of a big redesign, so I'm waiting for that; once something comes out, though, I'll definitely be trying it out.

One is to set up a Teergrube/Tarpit (it's easy using the Linux ipchains TARPIT target) on a machine that shouldn't receive any mail by SMTP. You can tarpit everything, and nothing will get lost. (I think this is something everyone should do; it'd be neat if this sort of functionality was built into those little Linksys/Dlink firewall boxes...)

The other possibility is to set up your mail server so that, as soon as the client connects to your SMTP server spam filtering begins, and as soon as a message is determined to be spam -- ie, when the client is still connected -- you start tarpitting. By contrast, a lot of spam filtering happens after the message has been accepted and the connection closed.

TarProxy is meant to do just that. Here's an excellent article on how it works. The project page says it's in the middle of a big redesign, so I'm waiting for that; once something comes out, though, I'll definitely be trying it out.

Ho ho, sorry about that. I'm talking about TarProxy, which I think should work as an SMTP proxy sitting in front of an existing mail server. Share and enjoy!

Actually, according to my stats, just about nothing. Oh sure, I get a lot of spam, and a lot of it appears to come from AOL, but it doesn't.

People invent bogus From lines, forge Return-Paths, add fake Received lines, set up PTR records in the DNS of their own netblock to resolve to AOL names.

For instance, one of the latest so-called AOL spams in my spamdump looks like this:

From: "Clement Crow" <o8utyszvc0n@aol.com>
Subject: Buy Phentermine, Viagra & more with NO PRESCRIPTION! US doctors and pharmacies! Overnight Shipping!

The only Received line I trust comes from my own MTA, and it says

Received: from host73.200-82-37.telecom.net.ar (unknown [200.82.37.73]) by {myhost.mydomain} (Postfix) with SMTP id DCFF8ADC4 for {me@mydomain}; Thu, 6 Mar 2003 02:44:15

So this is some clown sending me stuff from Argentina trying to pass themselves off as AOL. Not that I'm trying to defend them, but they're convientient shields (along with hotmail.com and yahoo.com) for spammers to hide behind.

Now if you'll excuse me, I have check out Tarproxy to see about integrating it into my inflict-pain-on-spammers setup.

This is a fix for a particular symptom of the problem. It handles only the case of one agent delivering lots of messages to the same server.

Like the man said, spammers vs. anti-spam solutions is an arms race - spammers will find a way to work around methods to keep them out. In the case that you have proposed, the work-around is simple: don't deliver all your messages to the same host in close proximity.

A better solution based on a similar concept is Vipul's Razor. This is based on the idea that spammers usually send the same message to thousands of recipients, so if the same message is received by a bunch of different and apparently unrelated accounts, it's probably spam. [and of course, the work-around for this is to vary your message slightly for each recipient]

Another issue is that all of the solutions that are now in use (except possibly the Tarpit solution) only shield the end user from spam: they don't address the burden placed on the network infrastructure.

So bottom line is, there's lots of little tricks like the one that you have suggested that can be used (separately and combined) to mitigate this problem, but (as you've indicated) they won't solve it.

Here are some more spam tarpits:

TarProxy
ChuckMail
OpenBSD's spamd (tarball)
Google Search Results