One of the primary pieces of advice given to mail administrators regarding backscatter is "reject mail during the SMTP transaction rather than accepting the mail and generating a DSN (bounce)".

It's solid advice to be sure, but it breaks down in situations when mail is accepted by one system to be forwarded on to system with a stricter criteria for message acceptance. The two main scenarios are "dumb" secondaries and primaries that rewrite certain addresses that get forwarded on to remote systems with, for example, different policies regarding spam filtering. For the purposes of backscatter these are essentially the same thing.

Both of these scenarios are quite common but, since they complicate matters, their usefulness is routinely denied by the advocates of various email spam-control schemes. Secondaries are frequently deemed unnecessary because the internet is "more reliable these days" (hah!).

"Dumb" secondaries (secondaries that accept mail without performing the same acceptance checks as primaries) are commonly found on low profile machines not specced-out for the needs of mail filtering. It's not unusual, in my experience, for two companies on different networks to reciprocally host a box installed for the purpose of secondary MX and secondary DNS. It's also common for sites to use secondaries provided by a third-party, such as their upstream network provider.

(And I'd note that there are major email providers out there generating bounce messages on their secondaries, it's not just dusty legacy setups.)

So if I'm administering a machine using a secondary out of my administrative control, I usually put in an exception in my transaction ACLs to blindly accept mails from secondaries in order to prevent them from generating DSNs (and possibly filling their queues with undeliverable bounces).

But then I'm faced with dealing with how to suppress the bogus DSNs.

My exim-fu is weak, and I don't know how to avoid generating bounces for bogus mail that has already been accepted. I'm not sure if any of the ACL rules can actually apply to internally generated DSN mail.

If there's an elegant solution, I don't know it yet.

My solution in the mean-time is just to write custom routers for common scenarios.

Using the split config, I place custom routers after the local delivery routers, but before the remote delivery routers, e.g. /etc/exim4/conf.d/router/188_local_drop_backscatter .

I then use "match" regexps against $message_body . $message_body, by default, is the first 500 bytes of the message body - this is usually enough to capture the rejection explanation at the top, but if you want to match something from the headers of the rejected mail you may need to set something like "message_body_visible = 2000" in the main section of the exim config.

In the following example, assume your server doesn't have virus scanning, but you forward mail to one that does. I've taken the decision here that a scenario in which a bounce message contains "This message contains a virus" (the rejection message from the remote site) near the top of the message body will not be delivered to the listed recipient, but will instead be dropped.

drop_backscatter_virus:
   debug_print = "R: drop_backscatter_virus for $local_part@$domain"
   driver = redirect
   senders = :
   domains = ! +local_domains : ! +relay_to_domains
   data = :blackhole:
   condition = "${if \
       match{$message_body}{This message contains a virus} {true} \
   }"
   allow_defer
   allow_fail