BGP blackholing spam [was Spammer Bust]

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

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

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.