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.