[spambayes-dev] Experience with Word Pairs

[Seth Goodman]

> From: Tyson Whitehead
> Sent: Thursday, September 01, 2005 8:01 AM

<...>

> PS:  On the subject of spam, I believe it would be a good idea to
> create a system that automaticaly replied to (and visits any links
> in) detected (and flagged) spam.
>
> This would greatly decrease the economic feasability of spam.
> Valid responses would be buried in piles of return spam.  Websites
> would be immediately DOSed.
>
> The tricky bit would be making sure the system could not be
> manipulated to take out legitimate sites.

You've got the major problem identified.  Most return-paths in spam are
already forged.  It would be trivial for spammers to include buried
references to legitimate web sites to make retaliating against URL's listed
in spam self-defeating.  This is largely why this retaliation concept has
never gone very far.

At present, you can do an SPF check on the return path.  If the domain owner
has published a SPF record and the SPF result in PASS (as opposed to
neutral, softfail or unknown, and definitely not fail), you can then assume
that the return-path domain is validated.  At that point, you could fake a
DSN to the authenticated return-path, if your provider doesn't whack you for
masquerading as their MTA.  There is nothing stopping you from sending them
hate mail as a form letter, though.  In the absence of a definitive SPF
pass, you are pretty much stuck with no knowledge as to which addresses are
forged.  Abusing one innocent bystander would do more harm than any benefit
from using the resources of 100 spammers, so you have to be _very_ careful.

You should also be aware that network abuse, even for a good cause, still
violates the TOS of virtually every honest provider on the planet.  That
being said, if you receive a piece of spam with a URL that is listed in
SURBL, you are on rather solid ground to send a bot to that site and use
some of their bandwidth - lots of it.  Since they did sent you an invitation
to visit their site, you're just paying them the requested visit :)  Unless
they publish a site use policy that prohibits non-human visitors or limits
bandwidth, I suspect you would be on pretty defensible ground.  However,
IANAL!

If you want to get back at spammers, one excellent strategy is to start
implementing blacklists (DNSBL's) and reject messages at SMTP time.  You
would preferably do this at the start of the TCP connection, before they can
even issue any SMTP commands.  While I am a giant fan of SpamBayes, it is,
after all, a post-acceptance content filter.  The spammer knows that the
message has been accepted, and a small fraction of those will ultimately be
read.  OTOH, if the message is rejected during the SMTP session, they know
with surety that _no one_ will read that message.  The more immediate
rejections they experience, the less attractive spamming becomes as a
business.  Since blacklists are always a bit behind and spammers are highly
mobile, we will always need content filters.  However, the more messages we
can reject, instead of accepting and silently dropping, the weaker the
spammers business model becomes.

Another method for "fighting back" that has gained a following is the
tarpit.  This is an evolution of the earlier technique of "teergrubing".
Briefly, a tarpit is a process run on the recipient MTA that traps hostile
senders by decreasing the acceptable packet size to a ridiculously small
value, responding only after very long time delays and _always_ requesting
retransmissions.  It is the essence of passive-aggressive behavior.  Since
we don't want the TCP session to ever end, we don't need to keep track of
its state and it is therefore possible to tarpit an arbitrary number of
hostile senders with one single process at the recipient.  OTOH, each sender
has to keep an open socket and process going as long as they are stuck in
your tarpit, which is often for a few days.  Typical 'nix machines can
handle 15K or so processes before they are brought to their knees, and Win
boxes die before that.  If you tarpit a zombied Windows box, you are actuall
y doing the owner a favor.  When their box finally stops working, they _may_
call their local provider for assistance and figure out they have been
compromised.

There are a number of public domain implementations of tarpits if you want
to set up your own MTA.  They are written so it only takes a few percent of
a typical CPU to trap a few thousand hostile senders at a time.  Some of the
systems automatically populate their own list of IP's to tarpit based on
spam received, others rely on external blacklists.  The U.S. Dept. of
Defense became interested in this technique as a method of countering a
large-scale DDoS that might paralyze sections of the internet.  Their
analysis calculates the number of tarpits necessary to neutralize a
wide-scale TCP-based attack, and the number is surprisingly small.  They
are, as the U.S. Food and Drug Administration would say, "safe and effective
when used as directed".

--

Seth Goodman