Terry Zink's Cyber Security Blog

Discussing Internet security in (mostly) plain English

The problem of backscatter, part 9 - Block it with content analysis

The problem of backscatter, part 9 - Block it with content analysis

  • Comments 4

We can see how backscatter is a problem, so how do we go about stopping it?  What are some of the techniques we can employ to keep it out of our inboxes?

One such technique is to block all NDR messages, or at least tag phrases and characteristics that commonly occur in NDR backscatter as inputs to a spam filter decision.  I found the following list at this site and it's a good start:

Field Test String
From contains Mailer-Daemon
From contains postmaster@
Body contains Status: 5.1.1
Subject contains Returned mail
Subject starts with Delivery Status Notification
Subject starts with Undelivered Mail Returned to Sender
Subject contains failure notice
Body contains Status: 5.7.1
From contains Mail Administrator
Subject contains blocked by our bulk email filter
Subject starts with Undeliverable
Subject starts with Delivery Notification

If a spam filter were to look for the above characteristics and block mail based on them, there's a good chance that it would block a very healthy portion of NDR backscatter.  The problem is that it would also block a lot of legitimate NDR mail.  That's the trade-off that would have to be made.

Another, riskier characteristic to block would be to block all mail with a null sender <> in the SMTP MAIL FROM.  Because many MTAs will send bounces with null senders (so as not to receive a bounce back if the NDR cannot be delivered), blocking all mail with null senders will succeed in blocking the bulk of NDRs.  There are some drawbacks to this:

  1. Like the above, blocking on null senders means you will block some legitimate NDRs.

  2. Not all null sender messages are NDRs.  Some messages like automated reports use them as well.  Other types of quickly written processes/scripts (that hopefully define their variables before use if they are written in PHP) that generate alerts also use null senders, simply by convenience.Thus, if you block on null senders, you are likely to incur collateral damage.

  3. It's not guaranteed to catch all NDR backscatter.  Some MTAs will bounce messages with something like bounces@example.org, or postmaster@example.com, or something similar.  This is a case of managing expectations; you won't get everything by blocking on null senders, but you will get some of it.

There are some mail delivery systems that already refuse to route mail with empty senders due to the excessive abuse of backscatter.  These systems are prone to the false positive problems described above.  You can get around this by setting inbound allow policy rules for other characteristics, for example, you could have Allow rules for IP 292.168.22.99 and Reject rules for MAIL FROM's of <>.  The inbound Allow rule supercedes the Reject rule.  The drawback for this is that you'll end up creating tons of Allow rules because you'll realize that you want to receive empty sender mail from more sources than you think.  Thus, the manageability becomes an issue.

So, content filtering based upon From/Subject/Body examination is one way to fight backscatter, albeit with false positive problems.  If you have a handle on who you want to accept mail from (no pun intended) then you can create exceptions.  But remember, managing exceptions can be a real pain after a while.

Leave a Comment
  • Please add 5 and 7 and type the answer here:
  • Post
  • PingBack from http://blog.a-foton.ru/2008/07/the-problem-of-backscatter-part-9-block-it-with-content-analysis/

  • By far the most effective filter for DSN messages is

    going to be to match RFC3464 bounces:

    if sender is <>

    and Content-Type: contains "multipart/report"

    I have mailserver filters that identify and tag different DSN types.  For example, exim generated bounces can be identified by the inclusion of an

    "X-Failed-Recipients:" header.

    Based purely on the backscatter I've received so far this week:

    249 RFC3464

    43 nonstandard (exim)

    38 nonstandard (qmail)

    6 nonstandard (other)

    5 nonstandard (exchange)

    3 unknown

    2 nonstandard (smtp32)

    1 nonstandard (type1)

    1 nonstandard (old sendmail)

    + 11 other responses (DSNs not using null senders, confirmation requests, googlegroups.com nonsense.)

  • Also, every time a null sender is used for connection, a check is made on the DNSBL http://www.backscatterer.org/?target=backscatter

    and positive hits are tagged on the mail.

    Currently 133 hits out of 347 backscatter mails.

  • Other uses of empty reverse paths include auto-responders (RFC 3834), e.g., vacation mails (RFC 5230), and message disposition notifications (RFC 3798). Apart from being difficult blocking all bounces including good bounces is a dubious plan, mail reliability depends on error reports. Even black-listed "backscatterers" can send good (wanted) mails with an empty reverse path. Blocking known "backscatterers" might work for senders never sending mail to them. But where senders are organized enough to guarantee this they can likely also deploy BATV and/or SPF FAIL without losing good bounces.

Page 1 of 1 (4 items)