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.

Joe Jared Wins

Joe Jared used to run an open-relay blacklist called Osirusoft. I respected what Joe’s intent was, though I was of the opinion that Joe ran things unwisely. Both of these things I mentioned way back in 2001, when an SF Gate Article slammed Joe (and blacklisting in general).

I recall that Joe has been defensive and combative in the past when people with affected/blocked mail reach out to him. He was also not very good at record keeping, something I knew from the past, and that fact came up in this case (Pallorium vs Jared).

Pallorium, a private detective agency, sued Joe, saying more or less that they weren’t running an open relaying mail server, they weren’t spammers, that Joe was careless, and that he offered no recourse to resolve the listing, because his website was periodically unavailable.

The court documents indicate that Joe admits that he had no idea how the server came to be listed, and that Joe’s tests after the lawsuit saga began show that the server was not actually an open relay. If records were kept showing where and why something was listed, I suspect it would’ve saved him some effort and perhaps prevented the lawsuit. It probably didn’t help that Joe was rude to the plaintiff on the phone about the issue, too.

Regardless, this case was clearly resolved in favor of spam blocking. I've always said that ISPs and anti-spam groups are pretty much free to block whatever mail they want, in their best efforts to block spam. The court and I seem to be in agreement on that point.

On one of the public anti-spam lists I’m, this spurred a discussion positing that this allows folks to probe for open relays and add them to a blacklist, as long as the person doing so has been receiving objectionable spam. Perhaps, but this isn’t quite precedent-setting. My understanding is that this would only apply in California courts, and that the decision is unpublished anyway. Not to mention, open relays (which I used to help people block myself back when I ran blacklists) are no longer the primary source of spam that they once were.

(If you don’t know what an open relay is, check my recent post on the topic.)

Senders: How to avoid false positives

As I often say, listen to as many sources of information as possible, and learn as much as you can from all of them. Don't be afraid to search for a second or third opinion on how to handle a deliverability problem or list management issue.

To that end, it's worth checking out this page. This information from the makers of the popular SpamAssassin spam filter offers valuable insight into how their system works. If you’re a mail sender, it’ll help guide you on how to finesse your legitimate mail, to reduce the likelihood that it'll be incorrectly classified as spam.

I don't agree with every suggestion it makes (many non-spammy senders use open detection that sets off their "web bug" detector, for example), but overall, there's some good info here. Read it, learn from it, and see what easy steps you can take to comply with these guidelines.

About the author, Al Iverson

Helping people deal with spam, list management, and deliverability issues is what I've been doing, first as a hobby, and now as my career, for the past ten years.

Since August, 2006, I've been the spam policy enforcement and deliverability guy for an email service provider located in the midwest. Prior to that, I spent just under six years working for a very large e-commerce service provider as the point person for spam and list management issues across the company's thousands of clients and dozen plus divisions and subsidiaries.

Before that, I worked for the Mail Abuse Prevention System (MAPS), one of the first anti-spam blacklist groups. There I created the MAPS RSS (Relay Spam Stopper) blacklist, to help address the scourge of spam being vectored through open-relaying mail servers. I also handled investigation and listing issues as a member of the RBL (Realtime Blackhole List) team.

Stopping spam is important to me. I do my part by guiding senders on how to send mail without sending spam, and guiding end recipients and system administrators on how to most effectively reduce the amount of spam they have to deal with.

I've been called the "baron of blacklists" for "waxing lyrically" on the topic of blacklists here and over on my other site, DNSBL Resource. There I publish news, information, commentary and reviews on the subject.

SPEWS Current Status

The SPEWS blacklist seems to have gone AWOL. A lot of people haven't realized this, and still believe they're being impacted by way of being listed on SPEWS. Over on my other site at dnsbl.com, I've posted two new articles that aim to help people dealing with this situation:

How to deliver mail to AOL

Are you having problems delivering mail to AOL? Does it sound to you like AOL's engaged in extortion and racketeering? If so, it's time to do a bit of learning and a bit of listening. Like it or not, I suspect that you probably don't know a ton about how the email infrastructure of the Internet actually works, and you're quite possibly listening to the opinions of other folks who are similarly inexperienced in this realm. Instead of debating myths and questionable opinions on how AOL is party to some secret conspiracy to make you pay to deliver your mail, lets talk facts about what causes AOL delivery problems and how to fix them. I know what I'm talking about. I actively deal with this kind of stuff every day. Read on and I’ll set the record straight.

There are three primary things that cause delivery issues when sending mail to AOL:

  1. You're not whitelisted,
  2. Your bounce handling is broken, or you're not looking at bounces; or
  3. You're generating too many complaints or too many bounces.

Allow me to break them down below. This is a bit quick and high level, but hey, that's the kind of advice you're going to get for free from some random guy on some random website.

You're not whitelisted. Fix that! Go here. Read it. Agree to the terms. Fill out the form. Work through this simple process and AOL will respond with a yay or nay. If yay, you're on track to be exempted from some of their basic spam filtering. This will resolve some of your issues, potential or actual. If nay, see steps two and three below, as they're probably preventing you from getting whitelisted.

To get whitelisted, you need to make sure you're mailing from an IP address that is being used just for your mail. If you're small enough to share a sending IP address with other people sending mail, you’re not really a sender. You’re a customer of a sender. Whoever owns, maintains, or supports that IP address should be filling out the whitelist form on your behalf.

Look at it this way. If you’re Bob at AOL and you can't mail Tom at Yahoo, then Yahoo and AOL are the folks who have to work it out…not you. It's the same kind of deal if you're sending to a tiny list off of a shared resource. You should nudge your service provider to address the issue, but if you don’t have your own IP and domain, and you don't have your own mail server, then you’re Bob the customer, not Bob the sender. The people griping don’t get that, or don’t agree with it, but that is ultimately the way the world works. It's not new, and it's not AOL-specific, and it didn't just appear as part of AOL's rollout of the Goodmail program. Simply put, it's been that way for the entire time I've been active in the email realm, over ten years.

Your bounce handling is broken, or you’re not looking at bounces.
I say this because every email AOL bounces back to you (over this type of an issue) contains a URL linking you to more information. AOL always includes this. So if you don't know what's going on with your AOL delivery, you probably don't have access to this data, or aren't looking at it. Make it a priority to change that!

Here's an example of an informational URL contained in an AOL bounce message: http://postmaster.aol.com/errors/554rlyb2.html

These URLs lead to pages that give you clear information about what’s going on. If your message is incorrectly formatted, they tell you. If you have a weird URL specified in a way that only spammers use, they tell you. If you’re generating too many spam complaints, they tell you. It’s that simple. AOL's the good guy here; they give you a lot more information than most receiving sites do. AOL puts a lot of effort into this process; they try hard to correctly report back to you about why they're blocking your mail, and there are many ISPs who are far worse at it. AOL's actually one of the good guys here.

You’re generating too many complaints or too many bounces.
If you get whitelisted, and are reading bounces correctly, and are still having blocking issues, then the information provided in bounces probably indicates that your mail is causing too many bounces or too many spam complaints. AOL (and many other ISPs) can tell how much of your attempted mail is undeliverable, and how many of your recipients report it as spam. These are important measures used by AOL (and others) to decide which mail gets through, and which mail gets bounced.

How to reduce your bounce rate: Don't attempt to remail bounced names. They’re not going to magically go through next time, and your failed attempts will actively damage your email reputation. If you don’t filter out bounces, your bounce rate will grow with each mailing, and you will quickly exceed AOL's spam-measuring bounce threshold. (Spam mail bounces at a high rate; spammers generally have very poor bounce handling. ISPs consider it a valid measure.) If you're doing this and still having this problem, then your signup/opt-in practices are broken, and they are resulting in too many invalid addresses being added to your list. It's making you look like a spammer.

How to reduce your spam complaint rate: Don't send mail to people who don't want it. Don't obtain lists from third parties. The people on those lists didn't opt-in to mail from you, and don't know who you are. Many of them will report your mail as spam. It doesn't matter if it's legal; it's just as legal for AOL to notice the high number of complaints and choose to block your mail. The most useful thing you can do is fix this. The most useless thing you can do is complain about it to the world at large. Don't tell the world you're not spamming and everybody's out to get you. As far as the recipients and receiving ISPs are concerned, you are sending spam.

Also, it's very important that you sign up for a feedback loop from AOL. This will provide you with copies of spam complaints brought against you by AOL users. You can (and should) ensure that these people are unsubscribed from your list. If you don't, you're not going to reduce spam complaints. This isn't a secret trick that makes it okay to suddenly buy lists or do other bad things--if you buy lists or harvest addresses, no amount of opting-out is going to save you--but handling feedback loops properly is a necessary part of managing your mailing list.

In closing, I would ask that you don’t be fooled by the fear, uncertainty and doubt (FUD) being spread by sites like DearAOL.com. In particular, that site appears to be supported by the Electronic Frontier Foundation (EFF), whose out-of-touch spam policy is guided by folks like John Gilmore, whom I've talked about here previously. A quick review of some of the supporting groups reveals at least one where I know that they utilize email practices that inherently cause deliverability issues. Wipe away the supposed "email tax," and many of these groups are still going to have trouble sending email, because their practices run them afoul of spam filters. (Don't just take my word on the questionable facts put forth by the anti-email tax crusaders-- Snopes has a very level-headed overview as well.)

In the interest of full disclosure, keep in mind that I currently work for an ESP (email service provider). Dealing with email delivery issues is what I do all day, every day. One of the reasons people outsource their mail to ESPs is to get expert assistance with these kind of issues. Though, I'm not trying to sell you anything. ESPs can certainly help if you’re having problems, and some problems are more complex than what I've touched on here. But, AOL's one of the easiest ISPs to deal with. My experience in this industry, and with AOL in particular, clearly tells me that it's not anywhere near as bad as some folks would lead you to believe.