I think that this is losing its appropriateness here on NANOG, and that
we ought to take it elsewhere (spam-request@zorch.sf-bay.org is where we
took it last time). Some points are technical enough to need a reply
here, though:

Our mail server regularly gets stuck with a full listen queue due to
occasional cases of one-way routing out on the net,... deliberately
introducing this would kill it. Consider, for instance, that the spammer
is probably sending mail to dozens of accounts on your system, and each
attempt will generate multiple SYN's, and each one of those wastes a slot
for several minutes. Even if you've cranked it up from the default of 5,
you'll be hosed for hours.

Most vendors now ship kernels capable of hashing PCBs and having listen
queues thousands of entries long. Sun, SGI, DEC, and BSDi all have it.
Though the original demand was due to WWW traffic, it now has an applic-
ation in SMTP due to DJB's "qmail", which opens multiple streams to the
same host if a message has multiple recipients on that host. (DJB says
this results in better aggregate mail throughput, and I will not dispute
him (not here, that is.))

If a spammer is using a "qmail"-like mailer, both you and he are going to
be short of slots for a while, whenever your host's recipients sort to the
top of his delivery list. On the other hand a spammer only has a handful
of machines and usually only a 56K or T1 to spam from -- this means he
can't be trying to open _too_ many simultaneous connections or he'll thrash
his line and/or machines into dust, making too little overall progress to
make the, um, "endeavour", um, "worthwhile."

Now we're into a less technical area -- United States law:

Of course, I suspect that any evidence that multiple providers were filtering
mail based on some agreed-upon list would land all of them in court, though
I'm not a lawyer.

Neither am I. But the evidence showing that a given provider is or is not
following the advice of a central netblock blacklist is VERY hard to get at
and prove conclusively. And the central blacklist editor is not responsible
for what other (undetectable) people do with the information made available.
Once I can find a way to keep ISC and CIX out of it, I will _welcome_ a
chance to do this up in court and find out what the law has to say about it.

Finally, we're into idle speculation -- hit 'd' now.

Imagine, for a minute, that some spammer discovers that one of YOUR unix
boxes can be used to forward mail for them, some weekend when you're out
of town,... and your IP address gets blacklisted. How soon would you call
your lawyer to help you recover from what could be a total loss of business?

Well, there are two issues there. First, Eric knows that Sendmail needs to
be plugged. 8.8, now in final alpha testing, has all kinds of hooks to
prevent a host from being used as a relay. Given that the last couple of
Moneyworld spams were bounced (at me, anyway) through a host in Thailand,
and that no responsible blacklist operator (counting myself, anyway) will
be willing to blacklist an innocent relay, I see the next year or so as our
battleground for turning off the generic SMTP relay service now available on
most Internet SMTP servers. Fortunately, folks will see a good use for this
feature (saving their line and host resources) even if they don't dislike
spam as much as I do. So convincing folks to upgrade ought to be simple.

No part of this battle can be won overnight. Right now I'm trying to educate
ISP's that they can't turn a blind eye to spam unless they want the rest of
us throwing inside fastballs at their heads. They will in turn educate their
customers. Blacklisting netblocks is just an educational tool, not a direct
means toward stopping the spammers. This is why filters that block only SMTP
aren't good enough.

I looked, again, at the Advertising Blacklist whose URL was posted here
earlier, and no mention is made of blocking netblocks. Once I get past my
own internal legal hurdles, I'll try to have a link added on that page that
lets folks know about the netblock blacklist.