[rescue] Spam (was: Perverse Question)

Rich Kulawiec rsk at gsp.org
Sat Jun 7 12:02:50 CDT 2003

Various quick observations from a very long-time spamfighter:

1. Passing laws is NOT the answer.  For one thing, the 'net spans many
jurisdictions, so unless the same laws were passed simultaneously in
all of them, it would do no good.

For another, the laws which will be written and passed will be written
by whoever has the deepest pockets/most lobbyists.  In the US, recent
pro-spam lobbying efforts by the DMA and Microsoft have caused significant
backing to be put behind a purportedly-antispam bill which is in fact
highly pro-spam.

And finally, here in the US at least, we have a government that has
enacted completely idiotic laws like the CDA and the DMCA.  I'm pretty
confident that any attempt to tackle spam will result in similar
displays of technical cluelessness and constitutional ignorance.

2. Mail is not the only means by which spam propagates.  Direct-to-screen
popup spam is on the rise, aided by the terrible insecurity of M$ code and
the clueless newbie lusers who run it.  And, I might add, by irresponsible
morons like the one who wrote and released the spammers' current best friend,
AnalogX, which cheerfully turns any PC into an anonymizing spamplifier.
Spam via NNTP decimated Usenet years ago.  And so on.  The point is that
spammers will use every and any means available to them to spam, not just
SMTP, and they *will* *not* *stop* until forcibly removed from the 'net.
Which brings me to...

3. The answer to spam, if there is such a thing as a single answer,
is to recognize that spam does NOT exist in a vacuum; it relies on
support services such as IP connectivity, DNS, web hosting, mailboxes,
etc.  Anyone providing such services must revoke them immediately and
permanently.  (My AUP specifies that not only will I do so, but I will
confiscate all data, hardware and funds in my possession; that I will
assess a fine to cover clean-up costs as well as damage to my reputation;
and that I will publish any and all data that I see fit in any manner
I see fit in order to make it as difficult as possible for the spammer
to ever use the Internet again.)

The second part of this is that any ISP which does NOT do this -- at least
the immediate/permanent revocation of all services part -- is infected,
possibly rogue and in league with the spammers themselves, and therefore
must be quarantined in order to prevent the infection from spreading.
This is what some of the DNSBLs (e.g. SPEWS) do, and it's quite effective...
which is one reason why a number of pro-spam/pro-abuse ISPs show up
in nanae and whine about it on a regular basis.

YES, it's draconian: but if those ISPs would simply behave responsibly
and ethically by removing their spammers IMMEDIATELY when notified of
their presence, it wouldn't be necessary.  And spamming would be a
minor annoyance, no more.

	[ Note; this used to be SOP.  It was unthinkable that anyone would
	allow a spammer to operate for even 5 more minutes after detecting
	them.  Router passwords and wirecutters were all that were needed.
	However, some cash-starved ISPs have now been signing "pink contracts"
	(Google for it) in which they agree to ignore large-scale, long-term
	violations of their AUP in exchange for payoffs.  How else can
	one explain, for example, the flat refusal of Burst.net to remove
	the rabid spammers at azoogle.com? ]

I expect that soon the use of DNSBLs will be extended beyond merely
denying SMTP access to dropping all IP traffic.  We are going to
start seeing the IDP (Internet Death Penalty) as the logical follow-on
to the UDP (Usenet Death Penalty).

	[ Note: have you noticed that C&W is pulling out of the US?
	C&W is well-known for being an absolute cesspool of spammers.
	It would be interesting to known how much business they've lost
	because significant chunks of their IP space are on a LOT of
	public and private blocklists.  And don't forget AGIS, which
	announced that it would be the "spambone" and was so heavily
	blacklisted that no doubt there are *still* people blocking that
	IP space.  It's been burned to the ground and sewn with salt. ]

4. In May 2003, AT LEAST 82% of the incoming mail arriving at my servers
was spam.  I estimate that the real percentage is above 95%, because of
several ongoing dictionary-style spam attacks.

5. I block a lot of spam using the following measures, in order:

	A. Large (38,000 entries) list of domains.  Used in sendmail's
	"access" file, this is a fast, local lookup (i.e. doesn't require
	a DNS query) and bounces quite a bit of spam.  These are spammer's
	domains, spam support domains, spammer "front" domains (e.g. fake
	ISPs set up by spammers), etc.

	B. Small (100 entries) list of subdomains allocated to dialups
	and other dynamic IP blocks.  I may replace with it a DNSBL or
	two that specializes in this, because it'll be less to maintain.

	C. A number of DNSBLs (DNS block lists).  All DNSBLs have
	different criteria; I've chosen a mix that works for me.  Here is
	the list, in the order that I use them.  Note that an incoming
	connection will be blocked by the first one that it hits, so
	*for my purposes* I've tried to order them in a way that blocks
	the most spam with the fewest DNS queries.


		These are part of the blackholes.us DNSBLs, which
		includes other countries and about two dozen ISPs, by
		the way.  Since 100% of the mail ever received here from
		these countries is spam, and since they have serious
		infestations of spammers that they refuse to address,
		mail from these countries is no longer welcome here.


		These are focused on open relays and open proxies.
		They nail a LOT of spam.  There are hundreds of thousands
		of abusable (and abused) systems connected via broadband,
		and unfortunately their irresponsible and/or clueless
		owners refuse to secure them.


		Spamhaus gets frequently updated (multiple times per day)
		and lists a lot major spam factories.  It's quite good
		at detecting new network blocks that they're using for
		spamming and listing them quickly.


		This is another assorted batch which blocks more open
		relays and proxies, as well as some known spam-sources
		and -- in the case of "zombie", known hijacked networks.
		(Spammers have recently started falsifying documents
		in order to get routing for ASNs that were abandoned by
		dot-bombs and other defunct entities.  The zombie DNSBL
		attempts to list these as soon as they're detected.)

6. I also have started giving out "tagged" addresses to various web
sites, mailing lists, etc., and then exempting those tagged addresses
from my all the spam-blocking I described in (5).  Why?  Because if I
give out abc12345 at gsp.org to merchant X, and one day I get spammed by
spammer Y at abc12345 at gsp.org, I *KNOW* how they got that address.

Granted, it may have gone through intermediaries.  And granted, it
may have been sold, traded or stolen.  But in all cases, merchant X
is solely responsible for this, and they had better have a good
explanation for it.

For one story of such an address (though not one of mine) see:


7. I don't happen to use any header- or content-aware anti-spam
measures yet.  (Well, that's not quite true; I have a couple primitive
rules which block the spam generated by some viruses/worms.)  But I'm
not running SpamAssassin, bogofilter, spambouncer or any of the other
code that does naive Bayesian classification, etc.

There are two reasons for that: first, I'm nailing most of the spam
with the measures above.  I *may* also be blocking some non-spam
which happens to come from DNSBL-listed networks: and I don't care.
Until those networks remove their spamming parasites, NO traffic from
them will be accepted here.  Second, some of the header-/content-aware
programs are rather CPU-intensive, and I don't think I have the cycles
to spare to run them right now.

However, for those people who have the resources, I'd strongly advise
taking a serious look at them, even if all you do is run them in
"advisory" or "tagging" mode, i.e. not actually blocking anything, just
marking it as "probably spam".  The three I mentioned are all pretty
good; the first two are designed to integrate with an MTA; the last one
(spambouncer) is a good end-user solution which works via procmail.


More information about the rescue mailing list