Well I think you hit the nail on the head with this paragraph. Whilst Microsoft and the standard sendmail distribution ship with realying on by default, 95% of sites will probably relay. If this was changed (yup, makes installation harder), 95% of sites wouldn't have relaying on by default.
Last time I asked Eric Allman to make non-relay the default, he claimed that it would do more harm than good since it would be a change from previous behaviour and if not configured perfectly would make a Sendmail upgrade into something that would break previously working config files. I was sympathetic, BIND has the same problem from time to time. Maybe I should ask him again -- depending on how much spam he's received in the year or so since I last asked him, he may be willing to change his mind. Microsoft's situation is inverted and they have NO excuse at all. Could somebody who hasn't been burned to a crisp by IETF politics please write a "Mail Relay Requirements" RFC that we can brandish at these vendors? (Dave Crocker seems like a logical choice for this given his past credits.)
One of the big problems we found is that if you naively blackhole a route, you only stop backtraffic to that destination. Some sites were sending us so many SYN opens, that as our SYNACKs never got there, we ended up turning a mild source of SPAM into a powerful SYN flood attack. The solution is to (a) ensure you are running kernels capable of handling this reasonably well,
As it happens, you need this anyway. There are a lot of SYN-flood generators out there and there are a lot of sociopathic teenagers (of all ages) willing to torpedo your mail servers just for fun, with or without a blackhole list.
and (b) (more important) ensure that your blackholing router returns ICMP unreachable for these nets, not simply swallows the packet. For various reasons this is difficult to do with Cisco's without unpleasant things like telnet <blackholed address> giving you a logon onto the router.
I think the access-list that controls telnet is still in force in this case, so if you're only allowing telnet from your NOC (which seems wise, right?) then only your NOC will get the IOS prompt when telnetting to a black hole. The ICMP thing is hard for another reason, which is that modern TCP's ignore ICMP _even_in_SYN_WAIT_ which seems utterly wrong to me. (I patched it here but not everybody has OS source for their mail relays.) This is another possible topic to be covered in a Mail Relay Requirements RFC, perhaps.
I'll publish the fix when we have it honed. (The unreachable should make the kernel drop the record of the half open connection).
Should, but doesn't, unless you have OS kernel source and know how to use it.
One particular site (something at AT&T worldnet - no compulsion about naming them as this was so ridiculous) was sending us one open every minute *per mail message queued* (i.e. they were running with -q1m). This is seriously clueless. We spent the best part of a half a day's engineering time trying to get through to a clueful person there. Evenetually we got through to the person allegedly running the server who had no idea how or why it had been set up like that, but didn't want to change it, or disable relaying. So now they are in the appropriate access list deny in the relevant border router even for incoming packets. No complaints yet.
The Worldnet people are not stupid. They've spent a huge amount of time and money preventing third party relay even though they have nationwide dialup pools which they lease to other providers, and vice versa. The only spam I get via Worldnet's relays comes from Worldnet customers at this point, which is a heck of a feat, one worthy of succession by, oh, let's say UUNET.