Post by John R. Levine
Since some of my domains date back to 1993 and 1995, I get a great
deal of spam to addresses that were scraped a long time ago, many by
broken scrapeware that got the addresses wrong so that the the target
addresses of the spam were never valid and so get 100% spam.
I long ago made those addresses into spamtraps, but in recent months
the amount of spam has gone up so much that bouncing the spam has
become a siginificant load on my system, particularly since most of
the return addresses are fake so the bounces all double bounce. I'm
also getting a lot of bounces from other places to bogus addresses in
my domains forged (out of spite I presume) as return addresses on spam
sent to random people all over the net. I've gotten as many as 50,000
bounces a day to forged abuse.net addreses, and double bouncing all
those slows my system to a crawl.
John's story is pretty much exactly the same as mine, except my bounce
and double-bounce numbers aren't nearly as high. There are only two
real people "behind" the three domain names I own -- myself and my
wife. Only one domain name (jcb-sc.com) gets any serious spam
traffic. qmail forwards email sent to my wife's email addresses
directly to her account at work.
Yet my system has about 240 emails in the queue, waiting to go out,
all of it bounces of spam. I've had qmail deliver double bounces into
/dev/null for over a week now, after carefully watching a
spam-gathering Mailbox for a week to verify that nothing useful was
showing up there. I think those "deliveries" account for the majority
of email activity on my system.
My server has no trouble keeping up with this load. My only problem
with it is the extra time it takes to review my system's log files.
But, in theory, things could get worse.
So badrcptto probably makes sense for me. I don't intend to reject
simple typos, so I don't think I want goodrcptto, but the spamtrap
addresses I've used in the past are as close to 100% reliable
indicators that an incoming message is spam as is feasible to detect
via technology, regardless of how many other legitimate email
addresses are listed in the RCPT TO of the message.
Rejecting such emails during the SMTP session makes a lot of sense to
me, since it means I won't have to view the spam if it happens to
include my correct email addresses in the header. If my system can be
"legally" configured to dump detected spam, bounces of spam, and
double bounces into /dev/null, and can be configured to bounce
post-SMTP-detected spam based on spamtrap addresses in the headers,
there's no basis I can see for the claim that I must not reject
SMTP-time-detected spam (or, for that matter, effectively direct it
into /dev/null, perhaps with some kind of tarpitting enabled as long
as my server's resources allow) based on certain known spamtrap
addresses appearing in RCPT TO.
My main reason for not using badrcptto right now is that I'm too lazy
and/or careful about patching a qmail setup that has been working (and
basically bulletproof) for several years now.
Oh, one more somewhat-related item: just for fun, I put up a new
spamtrap address on the home page of my original web site (the one
shown below currently just redirects to it). I used white-on-white as
a primitive means to obscure it from most readers, along with verbeage
to alert humans to the fact that it's a spamtrap. And I set up a
.qmail file named .qmail-vikings to bounce any email sent to it, using
a distinctive bounce message:
|bouncesaying 'Spam spam spam spam spam spam spam spam Wonderful Spam, Marvelous Spam.'
Within just a few hours of putting it up, I got my first email to
craig-vikings, and have since gotten at least one more. And that spam
had to get through the pre-qmail-smtpd bad-reverse-DNS check and
qmail-smtpd badmailfrom checks first -- though I don't, of course,
know how many other spams would have been sent to that address if
those earlier filters weren't in place.
So even the ancient practice of web crawling for email addresses to
spam is alive, well, and quick on its feet.
Which means we will, indeed, probably have to maintain any anti-spam
technologies we deploy for a very long time: though the leading edge
of the spammers' technology advances, its trailing edge doesn't have
to keep up, and what's in the middle is basically just a bunch of bots
doing what they've always done, and not caring one whit about their
success rate, since cycles and TCP connections are cheap.
James Craig Burley