Backscatter: What is it? How do I stop it?

What is it?
Backscatter is a certain kind of mail you receive that you didn't ask to receive. If you've ever received a “Your mail could not be delivered” bounce notification, a “Your mail contained a virus” notice, or a request to confirm your signup request for a mailing list you've never heard of, you've probably received backscatter. The backscatter problem is inherently linked to the spam problem, as most backscatter received is due to somebody else on the internet doing something bad and spam-related.

Types of backscatter:
  • Misdirected bounces from spam runs, from mail servers who “accept then bounce” instead of rejecting mail during the SMTP transaction.
  • Misdirected virus/worm “OMG your mail was infected!” email notifications from virus scanners.
  • Misdirected “please confirm your subscription” requests from mailing lists that allow email-based signup requests.
  • Out of office or vacation autoreplies and autoresponders.
  • Challenge requests from “Challenge/Response” anti-spam software. Maybe C/R software works great for you, but it generates significant backscatter to people you don't know.
How bad is this problem?
Let's do some quick math on the back of a napkin. A quick check of my personal spamtrap account finds 2,039 pieces of backscatter, just by searching for a few common phrases found in bounce messages and challenge/response requests. Out of the 320,000 recent pieces of spam I've got in that account, that may not seem like much. But that's just me and my tiny domains. Think about a big site, like say, Outblaze, with millions of users across hundreds of domains.

Spam lists contain a high percentage of invalid addresses, driving a high bounce rate. A normal mailing to a legitimate list will result in 3-10% of the mail bouncing, per mailing. And that's if you handle bounces properly. When working with senders, I know that if they haven't tracked bounces properly in the past, a list can have anywhere from 30-50% bounce rate. Spammers rarely handle bounces properly, so let's assume a 40% bounce rate on a spam run. If a spammer sends two million pieces of spam, that leaves 800,000 bounces. Where do those bounces go? I know from helping clients legitimately handle bounces, maybe 7-10% of email servers accept the mail then bounce it back later.

Do the math based on all of these assumptions: 2,000,000 spams, 40% bounce rate, 9% of mail servers send backscatter... That means that for that two million spam run, 72,000 bounce notifications (NDRs) are going to be sent back to the sender address. Since spammers forge the sender's address, this mail is going to be be received by people who had nothing to do with the spam. This, in a nutshell, is backscatter. And there's a lot of it floating around.

How can you stop backscatter?

If you're an end user, there's probably not a ton you can do to prevent the receipt of backscatter. Some anti-spam blacklists (such as backscatterer.org) actively block servers that generate backscatter. Spamcop used to do so in the past, but I don't believe they actively target these kind of servers at the moment. Though, any spamtrap-based DNSBL is going to (intentionally or not) catch servers sending backscatter, because the backscatter will hit their spamtrap addresses just like it's hitting you and everybody else.

Whatever you do, don't use a “Challenge/Response” anti-spam application or service. It makes the problem worse for everybody else on the internet – your challenge requests are just another kind of backscatter.

The same goes for those anti-spam applications that promise to send fake bounces on your behalf. The reasoning is that the spammers will realize your address is dead, and stop sending you mail. That's simply not true. You're going to bounce off the lists of good senders, who actually process bounces. The bad guys (whom are responsible for far more of the mail you receive) don't process bounces. They're the ones creating this whole backscatter problem to begin with. Yours will be just another bogus bounce notification bothering some innocent, unrelated third-party.

Don't set an “out of office” reply, either. Besides contributing to the backscatter problem yourself, you're sending random notes out to the world telling whoever receives the notice that you have a live email address and you'll be back soon to receive it. Guess what? You're confirming for spammers that your email address is valid! That means you're going to get even more spam. I see over 800 out of office replies in my spamtrap mailbox. If I were a sleazy spammer, it would be very easy to write a script to save those addresses in a file, and wait and see how many more I get today, tomorrow, next week, etc.

It might be useful to report backscatter as spam via your favorite spam-reporting service. It helps to collect stats on the problem, and helps to nudge sites to fix their backscatter-generating problems.

If you administer a mail server, here's what you can do to minimize your contribution to the backscatter problem:
  • Don't allow email-based signup requests for your email list. I've got more than 330 “please confirm your subscription” requests in my spamtrap account. If you do this, you're going to end up blacklisted, because these misdirected requests are going to hit spamtraps run by anti-spam groups, too. Instead, only allow web-based signups. People go to your website, fill out a web form to sign up, then send them the confirmation request.
  • Don't use Challenge/Response, and don't allow your users to, either. As I mention above, it fixes your spam problem at the cost of everybody else's spam problem. Few, if any implementations of C/R are smart enough to prevent responses to spam messages and other random junk. Justin Mason puts it succinctly: C/R is “broken and abusive.” Over on his blog, he rounds up a bunch of opinions on why this technology is flawed. I've also made my opinions known on the subject, as well.
  • Don't run autoresponders, out-of-office notifications, etc. You'll annoy people and your mail could end up being blocked. I've seen people complaining that anti-spam blacklists have listed them because of this kind of backscatter. This generally impacts your mail far beyond out of office responses. Spamcop has a FAQ with more information.
  • Don't bounce mail after accepting it from a remote site. If you run an unpatched version of Qmail, or some other MTA that accepts all mail, then later sends bounces for some of that mail, then you are at the heart of the problem. Those who came before you learned a long time ago that this behavior contributes to the internet's spam problem. That includes AOL (the site with possibly the largest percentage of end-user mailboxes in the US), who has spent tons of time and money over the years, ensuring that as much as their rejected mail as possible is rejected during the SMTP transaction, and not later. Before they made this change, they were a significant source of backscatter. They may not be perfect at this today, but they've made huge strides, and are to be commended.
    Jeremy Harris was kind enough to pass along this support note from Microsoft on how to configure Exchange 2003 so that it does not work in "accept, then reject" mode.
    You might ask yourself, "What's the point? If I reject the mail, somebody will be sending a bounce." That's usually not true -- most spam is sent by infected zombie computers, and the software spammers are running doesn't bother with things like bounces.
  • Configure your virus scanner to silently strip or discard viruses/worms instead of sending a notification back to the sender. It's a fact: Viruses and worms sent via email do not have valid sender addresses. If you send a notification back, it goes to the wrong person, an innocent third-party. This is backscatter, and your server just succeeded in annoying somebody.
  • If you run an ISP, rate limit outbound mail or detect usage of large numbers of different envelope senders. This helps to combat “outscatter,” which is what happens when users on your network have virus-infected desktops utilizing your SMTP servers to send outbound spam. Since they're on your network, they'd normally be allowed to relay mail through your server. But, if left unchecked, you'll find your outbound mail servers blacklisted for sending spam, as the place it's being transmitted from, as far as the rest of the internet is concerned, is your outbound mail server.
  • Read and learn. Anti-spam groups like Spamhaus have posted and linked to useful information about the backscatter problem and what to do about it. Justin Mason's blog covers this topic, as well. The Spam Links site has an entire section devoted to backscatter. It's worth reading.
I hope you found this information useful. If you see anything out of date, or think there's more information I should consider adding, don't hesitate to contact me with your thoughts and feedback.

10 comments:

Filmore said...

IMO this is the best description of the Backscatter problem on the net! Bravo!

Ronald Klop said...

Web sign up for mailing lists wil not help unless you use a captcha. In fact, web forms with e-mail confirmation contribute to the problem.

Al Iverson said...

No, actually, opt-in confirmations aren't really the same problem at all. If indeed they are a problem, which I'm not convinced they are.

Mikey said...

Not using out-of-office replies is unfortunately not a real option in today's business world. If a client sends an e-mail they expect a response. Coming back a week or two later saying "sorry, I was on vacation" does not cut it.


The real problem is not backscatter anyway -- that is just a symptom. The real problem is the spam itself, and we need to be focused on stomping out this problem rather than running around trying to band-aid the symptoms.

Al Iverson said...

Backscatter is effectively one type of spam; it's definitely part of the "spam problem." Fixing the spam problem takes a lot of action on a lot of fronts -- you can't just say "well, I really need my out of office replies, so ignore this."

Filmore said...

Blocking spam bots (easily identifiable as having IPs on block lists or dynamic blocks) at the SMTP gateway is a great way to reduce backscatter from vacation auto-responders. Check out http://www.spamcop.net/fom-serve/cache/329.html for more info...

p said...

using an RBL that requests 50 euro to get delisted does not encourage anyone to work to resolve the problem.

using an RBL that publicly states that their RBL is not negotiable is not an option.

I have always worked with other RBL's exspecialy ones that offer full headers, as this is often the only way to resolve compromised webmail accounts.

Dancez said...

Thanks for this article. Backscatter has been an annoyance to my company for some time. For one period we were receiving more than one million per day; most from spam filters. It went quiet but recently started again and currently the level is 10,000 per day. Now using the backscatterer.org list to successfully filter it automatically.

Fuhrmanator said...

Vacation auto-responders have grown up (at least on Gmail). They're smarter now in that they can be enabled to respond only to "From" addresses that are in a contact list. That way, incoming spams are unlikely to bounce.

NoetiCat said...

"ant-spam blacklists"

Getting spammed with ants is a bit annoying, isn't it...