Eating Enemy Resources

Serious Attack, or Just Chinese Water Torture?

In Charlie Wilson's War, the title character is amazed the CIA station chief in Afghanistan appears to have no interest in ejecting the Soviets from Afghanistan, and learns that the local station chief seems to hope the Soviets will stay in Afghanistan a long time, suffering expense and frustration as they spend good money on bullets mowing down mostly helpless locals until the Soviets are too tired to pull the trigger or too broke to reload.

Maybe in a shooting war this is a shocking strategy, and escalation is warranted to achieve ejection of the enemy.  Hence, Charlie Wilson's War.

Outside the context of shooting wars, though, there are some amusing applications for this strategy of wasting enemy resources.

SPAMS and SCAMS

Spam is a nuisance because (a) it wastes your time, (b) it consumes storage and CPU resources for your server or (if administering your mailserver isn't your problem) your client software.  It also makes it harder to spot legitimate emails.  Daniel Hartmeier responds to automatic-harvested email addresses (including mailing list addresses) with relaydb, which shunts connections from spammers -- even if they come through desirable mailing lists -- to be ministered to by a daemon designed to protect him from the spammer's attention.  He cleverly looks at the mail headers not to find out where the email claims it originated -- this can be forged -- but based on where his computer actually received the email (which he knows, because his computer made this record).  If that address is not on the blacklist, his software assumes the connection is good and looks at the immediately-prior connection (assuming that the good connection is telling the truth about where it got the message).  The minute one of the connections turns out to be on the blacklist, the email is given second-class treatment.  In the case of an active connection involving a known spammer (the link explains how Daniel builds this list -- or rather, how his software builds this list for him), his computer services the connection with a daemon that pretends to be a mailserver, but just wastes spammers' computing resources pretending to have intermittent errors, or pretending to have a terrifically slow connection that tends to lose packets.  Daniel eats up spammer resources without having to spend much time or attention at all, and avoids most of their junk mail in the process.

One of the benefits of avoiding spam is avoiding the scam attempts they contain. 

Those who don't successfully avoid spam will encounter scam efforts.  Possible response to email scams is to game the scammers -- including as Daniel does with their connections, but instead with the human scammers themselves.  To waste scammer time and energy entertainingly one can mislead scammers that you've fallen for it, and have them run around like a chicken with their heads cut off chasing funds you never sent.  In an escalation of this game, one can run actual scams against scammers themselves.  The administrator of an anti-scam site has acquired a number of African carvings of Western-themed objects by tapping the same greed scammers ordinarily leverage to get victims to jump through hoops.

Conclusion

While some conflicts with identifiable enemies and known borders might be subject to naked force as a viable solution, some are better approached with thoughtfulness rather than mere money or muscle.  Daniel's relaydb seems an ingenius way to prevent spammers (including scammers) from reaching one's inbox -- a delightful way to avoid the problem without spending a fortune in prosecutorial resources and international legal efforts doomed by virtue of non-extradition caused by China and Nigeria having little interest in having the law enforced on domestic enterprises.  The more labor-intensive efforts undertaken to run individual scammers in circles are probably great therapy for their perpetrators, but unlikely to impact many scammers and unfeasible for the typical spam victim.  

Software vendors should think carefully why they are not offering solutions like relaydb and spamd (both licensable without fee) to their customers.

My own experience suggests that major vendors, including major Unix vendors, simply do not believe improvements to the status quo exist, or are useful.  For example, when Apple's Hubbard (of FreeBSD fame) received my question about improving MacOS X's firewall by looking at one of the stateful packet filters being developed, he responded that there was no reason there should be more than one firewall and that anyone working on a firewall for FreeBSD other than ipfw was wasting resources that could be employed somewhere actually useful.  The fact that the stateful packet filter pf has become (since FreeBSD 5.3 was released in 2004) part of the FreeBSD base system seems a strong indication that actual users of FreeBSD disagree with Hubbard's assessment that competing firewall tools are a waste of time.  (Hubbard's argument to me appeared chiefly based on an argument like how much performance improvement do you expect is possible in a firewall? and utterly ignored that ipfw did not actually conduct stateful packet inspection and thus filtered packets rather than connections, which limits its ability to apply different rules to users capable of proving privilege to access different system resources, for example, and that ifpw does not support failover for firewalls.  Hubbard's answer?  Nobody is using MacOS X for a firewall, so who cares?  The fact someone might be interested in using his company's product for more things if it were more capable seemed oddly off his radar.)

The upshot?

Vendors won't give us what we want, apparently, so we're in for self-help for the foreseeable future.  If you use a Unix-based system, consider delaydb and spamd;  if not, and you have time to kill, try baiting the spammers a bit and see how much fun you can have :-)  

But ... use a throwaway email address!