The problem of backscatter, part 9 - Block it with content analysis
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:
Like the above, blocking on null senders means you will block some legitimate NDRs.
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.
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.