Backscatter Considerations

In this post, I would like to talk about an underdesirable effect of rejecting emails at On Arrival—one that may cause your network to take part in abusing innocent servers, called “backscattering”.

Let’s assume you have a front-end SMTP server in the DMZ and an Exchange server on the private intranet. ORF is running on the Exchange server, configured to reject emails. What is going to happen with incoming spam in this setup? The front-end will receive the spam and relay it to the Exchange server. ORF will blacklist and reject the spam during the transmission. The front-end server, encountering the transmission error, will generate Non-Delivery Report (NDR) and return it to the original email sender. Perfectly how the RFC requires.

What’s wrong with this? It’s that the sender is always forged. The NDR will be sent to a perfectly innocent domain that is not involved in the spam attack anyhow. Actually, this is how we got into the anti-spam business in the first place—a spammer forging our domain name forced us to write our first extension to IIS SMTP for disabling a specific recipient.

Help the fellow admins: if you run ORF behind a front-end SMTP server and can’t move ORF to the DMZ, consider changing the On Arrival action to tagging or redirecting.

2 thoughts on “Backscatter Considerations

  1. Josh

    If you run ORF on a front end exchange server behind a firewall is there still an issue with backscatter?

  2. Pingback: Vamsoft Insider » Drop your secondary MX

Leave a Reply

Your email address will not be published. Required fields are marked *

AlphaOmega Captcha Classica  –  Enter Security Code