Dealing with backscatter, revisited

Back in January, I wrote about how I deal with email backscatter nowadays. Since then, I’ve made a notable tweak.

This is that I no longer reject “null-sender” traffic during the SMTP transaction. It turned out that it broke Exim’s implementation of Sender Address Verification, which performs the SAV check using a MAIL FROM of <>, rendering it indistinguishable from a bounce during the SMTP transaction.

Now, I’ve complained about SAV, but I have to be pragmatic anyway (Postel’s law and all that!) — so it was better to just allow other sites to perform SAV lookups against our server, and fix the anti-bounce stuff some other way.

The new method (below) does this, by allowing null-sender SMTP traffic just fine; it detects bounces in Postfix if they arrive via SMTP in RFC-3464 format, and bounces that slip past are then dealt with in a more CPU-intensive manner using the SpamAssassin “VBounce” ruleset (which is part of the now-released SpamAssassin 3.2.0, btw).

This increases the load, since some bounces cannot be rejected at MAIL FROM time now, and instead we have to wait ’til DATA — but CPU hasn’t been a problem recently, so this is ok.

Here are the updated instructions:

In Postfix

In my Postfix configuration, on the machine that acts as MX for my domains — edit ‘/etc/postfix/header_checks’, and add these lines:

/^Content-Type: multipart\/report; report-type=delivery-status\;/  REJECT no third-party DSNs
/^Content-Type: message\/delivery-status; /     REJECT no third-party DSNs

Edit ‘/etc/postfix/’, and ensure it contains:

header_checks = regexp:/etc/postfix/header_checks

Then run:

sudo /etc/init.d/postfix restart

This catches most of the bounces — RFC-3464-format Delivery-Status-Notification messages from other mail servers.

In SpamAssassin

As before, install the Virus-bounce ruleset and set it up. This will catch challenge-response mails, “out of office” noise, “virus scanner detected blah” crap, and bounce mails generated by really broken groupware MTAs — the stuff that gets past the Postfix front-line.

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


  1. Posted May 30, 2007 at 20:26 | Permalink

    If you want to totally avoid the processing, you can put hashed cookies in the envelope from (rewrite it like VERP) , if you get a bounce to an address which doesn’t contain a valid cookie, reject it at SMTP time. Of course you have spend a little CPU computing the hash and doing rewrites (in both directions), but it works, and is not RFC ignorant ;-P

    I still use exim call-backs, but I use Tony’s recipe for avoiding callbacks to people in’s DSN blacklist (which in effect becomes a whitelist). It still cuts out quite a bit of dictionary spam for me (100s a week).

  2. Posted May 30, 2007 at 22:42 | Permalink

    yeah — maybe someday Postfix will make it easy to use BATV or similar in my envelope sender addresses, and I can ditch half of this. (The other half will still be necessary to combat the more brain-dead bounce generators, the ones that mail the From: header address anyway.)

  3. Posted August 28, 2007 at 14:49 | Permalink

    Can’t you use Postfix’ internal VERP module to encode all addresses? I do something similar with qpsmtpd.

  4. Posted September 23, 2007 at 13:32 | Permalink

    sorry for not replying, Jonas.

    yes, I probably could — but I run my domains on a shared server, and modifying all users’ outbound MAIL FROMs would be a big change — I don’t think everyone on the server would be happy with that.

    There are still sites that can’t deal with BATV-style changing MAIL FROM addresses —, for one.

  5. Posted June 11, 2009 at 16:13 | Permalink

    here is a nice article about how to protect yourself from backscatter spam.

    i think it’s a good read…have a look:

  6. Alex F
    Posted October 28, 2009 at 16:30 | Permalink

    Hi, the fact that you use REJECT in your header check doesn’t it make the whole mechanism useless? Because you bounce back to the supposed sender (who is forged) with the message “no third-party” and you end up with your mail queue getting full with “Connection timed out”. And even if the supposed sender is real, you end up bouncing back to him, and in this case, spamming him.

    Shouldn’t you use DISCARD?

  7. Alex F
    Posted October 29, 2009 at 18:01 | Permalink

    (please mail me back when you give an answers. 10x.)

  8. Joao Luis
    Posted January 12, 2011 at 10:42 | Permalink

    This check gets applied to MIME annexed messages also. Doesn’t this prevents users/postmasters from using this postfix to forward email messages that contains such kind of messages as annexes ? (For example, if I try to forward a failed delivery report to anyone using alpine I get the SMTP error 550 5.7.1 no third-party DSNs).

    Does disabling nested_header_checks (setting it to empty) solves the problem without compromising the original solution’s purpose ?

    (Just asking if anyone with experience can give any feedback on this issue).

  9. Posted October 2, 2012 at 16:00 | Permalink

    Hi, thanks for the helpful site. Just thought you’d like to know that although I didn’t find a solution that helped me here, I did eventually find one here: