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