Introduction
There seem to be a lot of confusion and a number of misconceptions regarding the email backscatter phenomena, so I decided to gather the most frequently asked questions we receive and answer them in this article. I also try to offer some solutions against the backscatter problem.
Questions and answers
What is email backscatter?
Email backscatter occurs when a spammer spoofs a legitimate domain name to send spam to your server. Your server sends a bounce message (Non-Delivery Report or NDR) back when it realizes the email is spam or cannot be delivered (because the recipient does not exist). However, the bounce will be sent to the innocent party whose email address the spammer spoofed, instead of the spammer.
Why is it a problem?
Because your server will flood legitimate senders (who has nothing to do with the original spam you received) with NDR emails, putting extra load on them, and actually spamming them with bounce messages of emails they never sent.
Why should I care?
Sending large amount of NDRs puts an extra load not only on the target servers, but on yours, too, and it probably violates the terms of service of your ISP. Your server may also end up on various DNS blacklist for sending bogus NDR emails (like backscatterer.org). And, of course, flooding innocent people with junk is not a very nice thing to do. You know the golden rule: "Do unto others as you would have them do unto you."
Can I disable NDRs in ORF?
No, you can't, as ORF never sends any NDRs actually: your Exchange/SMTP server does. ORF is an SMTP protocol level filter which only tells your SMTP/Exchange server to return SMTP responses indicating the status of the email in various stages of the SMTP conversation between the sender and recipient servers.
For example, if the email is rejected by the Reverse DNS Test at Before Arrival because the sender has no MX records, ORF will tell your server to return SMTP response code 550 and the SMTP response text "5.2.1 Mailbox unavailable. Sender domain must have a DNS MX record." after the RCPT TO: command. If the sender server encounters such protocol-level rejection during the SMTP conversation, it will generate an NDR for the sender email address itself. The SMTP code and text is included in the NDR sent. Your (recipient) server will not send any NDRs in this scenario, thus backscatter is a non-issue.
But why does my server send out NDRs then?
In some cases, the recipient server realizes the email cannot be delivered only after the SMTP conversation has ended, and it tries to notify the sender by sending an NDR email. This practice was OK before the time of spammers and email forgery (even the RFC says it should be done this way), but nowadays, it is strongly discouraged.
Such thing may occur if the email was relayed through a secondary MX or front-end server to a primary MX/back-end server, (so the email has already been accepted from the original sender by the secondary MX/front-end), but the relay target server (primary MX/back-end) cannot deliver the email.
Your server should not send any NDRs to non-local recipients, or it should be absolutely sure that the NDR returned is delivered to the actual sender. The latter is currently impossible (there is a method called Bounce Address Tag Validation, which was meant to solve this, but currently, there are many problems with the concept), so the only option we have is not to send any NDRs out.
How can I prevent sending NDRs?
You should disable NDRs in Exchange: for instructions, see the knowledge base articles of Microsoft for Exchange 2003/2000 and 2013/2010/2007. Do not worry: local users will still be notified if their emails cannot be delivered, this will disable NDRs for non-local recipients only.
I don't have Exchange. Can I disable NDRs on my IIS SMTP gateway?
No, you can't. The only way to stop sending them is setting up a catch-all account to collect the NDRs and schedule a batch file to clear them up periodically.
What else can I do to stop sending NDRs?
Reject, don't bounce. You should run ORF on the perimeter server and reject everything you can, especially emails sent to non-existent recipients (Recipient Validation). If you have a secondary MX, you should secure it the same way as your primary one, or (if it is not possible), consider dropping it.
Why is my secondary MX a problem?
If it never relays any spam to your primary one, there is nothing wrong with it. However, in most cases, the secondary MX is hosted by an ISP or other third-party, it is not secured against spam and cannot validate the recipients. Thus, it will relay everything (including spam and emails sent to non-existent addresses) to your primary MX.
The email could have been rejected at the SMTP protocol level during the original SMTP conversation only (between the original sender and the secondary MX). The only way to notify the sender now about the failed delivery is sending an NDR, and you know where that leads: backscatter.
My ORF runs on a back-end server / I can't drop our secondary MX, my boss won't let me. What should I do?
If your only option is filtering at On Arrival, drop blacklisted emails after accepting them (without notifying the sender). Delivering such emails to "Junk" or "Spam" folders from where it will eventually be deleted automatically (e.g. after 30 days) is common practice. See our Knowledge Base article regarding this.
OK, I promise not to send any NDRs. But how can I prevent spammers from spoofing my email addresses and prevent others from flooding me with NDRs?
You should publish SPF records for your domains: Sender Policy Framework (SPF) is an email authentication protocol which allows domain owners to publish a policy to stop email forgery in the name of the domain. In short, the policy defines which hosts are authorized to send emails in the name of the publisher domain. For more information, please visit the official SPF page and read our article. Once you have an SPF record published, the target server of the spammer can check it, forgery can be detected during the SMTP conversation, and the target server will reject the spammer instead of sending a backscatter NDR to you.
This sounds good, but what if the spam target server does not check my SPF policy?
SPF is a good thing, but it is still not that widely adopted. If the spammer target does not bother detecting the email forgery, it will not help. If all else fails, you can try using our Backscatter Protection External Agent , which tries to detect (and reject) backscatter NDRs by checking the Message ID of original email attached to the NDR, and if it does not match your message ID pattern (which your server generates for outgoing emails), the email was not sent by your server. If it was not sent by your server, the NDR was returned to a spoofed email (backscatter).
The agent solves my backscatter problem for good, right?
Unfortunately, some servers not only ignore your SPF policy, but send non-standard NDRs, which from the agent cannot extract the original message ID, so the agent is not guaranteed to detect them all . But if you have both the agent enabled and the SPF policy published, you reduce the chance for getting backscatter NDRs.
I read about backscatterer.org, which lists backscatter sending hosts. What do you think: should I use this list?
We do not recommend using backscatterer.org, as these hosts are not sending spam emails, they are only misconfigured and/or the administrator have never heard about this problem. Rejecting ALL emails from backscatter NDR sending (but otherwise legitimate) senders will increase your false positive rate tremendously. Some NDRs to clean up from the inbox are always better than losing important legitimate emails.
Conclusion
Backscatter can be a serious issue, but following these simple guidelines, you can reduce (or even eliminate) the problem: