Backscatter rising

Recently, more and more people have been complaining about backscatter; its levels seem to have increased over the past few weeks.

If you’re unfamiliar with the terminology — backscatter is mail you didn’t ask to receive, generated by legitimate, non-spam-sending systems in response to spam. Here are some examples, courtesy of Al Iverson:

  • 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.

It used to be OK to send some of these types of mail — but no longer. Nowadays, due to the rise in backscatter caused by spammer/malware abuse, it is no longer considered good practice to “accept then bounce” mail from an SMTP session, or in any other way respond by mail to an unauthorized address of the mail’s senders.

Backscatter as spam delivery mechanism

I would hazard a guess that this rise is due to one of the major spam-sending botnets adopting the use of “real” sender addresses rather than randomly-generated fake ones, probably in order to evade broken-by-design Sender-Address Verification filters.

There’s an alternate theory that spammers use backscatter as a means of spam delivery — intending for the mails to bounce, in effect using the bounce as the spam delivery mechanism. Symantec’s most recent “State of Spam” report in particular highlights this.

I don’t buy it, however. Compare their own example message — here’s what the mail originally sent by the spammer to the bouncer, rendered:


And here’s what it looks like once it passes through the bouncer’s mail system:


That’s simply unreadable. There’s absolutely no way for a targeted end user to read the “payload” there…

Getting rid of it

I haven’t run into this recent spike in backscatter at all, myself, since I have a working setup that deals with it. This blog post describes it. If you’re using Postfix and SpamAssassin, it would be well worth taking a look; if you’re just using SpamAssassin and not Postfix, you should still try using the Virus Bounce Ruleset to rid yourself of various forms of unwanted bounce message.

Note that you need to set the ‘whitelist_bounce_relays’ setting to use the ruleset, otherwise its rules will not fire.


There’s a theory that setting SPF records (or other sender-auth mechanisms like DomainKeys or DKIM) on your domains, will reduce the amount of backscatter sent to your domains. Again, I doubt it.

Backscatter is being sent by old, legacy mail systems. These systems aren’t configured to take SPF into account either. When they’re eventually updated, it’s likely they’ll be fixed to simply not send “accept then bounce” responses after the SMTP transaction has completed. It’s unlikely that a system will be fixed to take SPF into account, but not fixed to stop sending backscatter noise.

It’s good advice to use these records anyway, but don’t do it because you want to stop backscatter.

What about my own bounces?

You might be worried that the SpamAssassin VBounce ruleset will block bounces sent in response to your own mail. As long as the error conditions are flagged during the SMTP transaction (as they should be nowadays), and you’ve specified your own mailserver(s) in ‘whitelist_bounce_relays’, you’re fine.

This entry was posted in Uncategorized and tagged , , , , , . Bookmark the permalink. Both comments and trackbacks are currently closed.


  1. Nix
    Posted April 13, 2008 at 00:14 | Permalink

    Good post.

    I remember I had an interesting variety of bounce when I first went to direct-to-MX mail receipt: due to a silly sendmail configuration typo I was bouncing all unknown-addressed mail to… [email protected] my relay.

    These days, I’ve got scripts that spot unexpected outbound mail like that, but back then I didn’t, so the first I heard of it was an email from the long-suffering BOFH at my ISP reading simply ‘OI!’ and a snapshot of hundreds of double-bounces clogging up his inbox…

  2. Posted April 13, 2008 at 02:42 | Permalink

    I have a client, that requires anything marked spam or a virus to do a bounce back. It drives me crazy trying to explain to them what backscatter is. They would rather do without email then take a chance that an email to them got dropped somewhere.

    They are a large law firm, and could be sued if they didn’t respond back to an email even if it has a virus in it. So we let the sending user know there is a virus in their message. We then quarantine the email in a database and allow the user to login and view the message on a web page and or release it to be delivered their local system. While I say virus, this also pertains to Spam.

  3. David Malone
    Posted April 13, 2008 at 07:38 | Permalink

    I’ve seen quite a lot of these recently, strangely using a [email protected] address, which I’m suprised actually made it onto any modern spamer’s list. I was wondering if it was just a few people in maths or not – I’ll have to read the LWN article once it becomes available.

    BTW – does whitelist_bounce_relays allow any string that you find acceptable in the Received headers, or does it have to be a hostname? For example, will it accept IPv6 addresses that might be embeded in a [IPv6:…] string wen they show up in a header?

  4. Posted April 14, 2008 at 11:06 | Permalink

    Zerolove: could you set it up to perform the scan during the SMTP delivery transaction, and return a 550 error from that? That way you can ensure that error messages get back to the original sender. That’s the backscatter-free way to do it.

    David: the way ‘whitelist_bounce_relays’ works, is that it looks for Received headers in the mail, then searches for everything with a dot in it (regexp / (\S+\.\S+) /). So it should work for most stuff — although actually it may not work for IPv6 addresses!

    However, the idea is that it doesn’t try to find your mailserver based on reverse DNS, or whatever — it looks for a line which your mailserver has added, since a working MTA will always add a line identifying itself. e.g. here’s one of mine:

    Received: from (localhost [])
            by (Postfix) with ESMTP id 15CFF30C0F3;
            Thu, 14 Feb 2008 14:45:45 +0000 (GMT)

    note the “by” part. That “” is in my Postfix config as the machine’s own idea of what its hostname is. I presume your IPv6-using mailserver has a similar non-IPv6-address hostname that can be matched?

  5. David Malone
    Posted April 14, 2008 at 11:57 | Permalink

    Yep – the MTA does add some string that I can match on.I just didn’t really understand what the test was looking for based on the docs, and so couldn’t tell what it might match (the, the localhost or the []).

    I know other bits of SA parse the received headers to try and find hostnames (like the trusted relays code), and depend on knowing the format of received headers. Though this may have changed since I last looked.

  6. Posted April 14, 2008 at 14:07 | Permalink

    Justin: I will look into that, but right now we are using qmail with qmail-scanner-queue on that server. So it is not happening on the SMTP front end. Also we are required to quarantine spam/virus both for a certain amount of time.

  7. Posted April 22, 2008 at 22:24 | Permalink

    I have a customer who had such a bad backscatter problem (as a recipient) that it amounted to a Denial of Service attack. At first, he did not know what was happening at the beginning of the outbreak. Here is his story:

    Backscatter DoS Attack