by Cherie Ansari
Consultant, Professional Services
Are your emails not getting delivered because of backscatter? Do you know if you’re on the Backscatterer blacklist? Do you want to learn how to get de-listed or want an explanation of what it is so you can take precaution? Quite often it’s a non-technical person who identifies this problem first, but they (or you) may not know what it is.
Backscatter occurs when your mail server unintentionally sends auto-generated replies to recipients who didn’t send the email in the first place. Confused? Wait, there’s more. When one of those recipients happens to be a spam trap, the senders’ IPs are at risk of getting on either a specialized backscatter blacklist, or a more general blacklist which uses the spam trap data.
To help visualize backscatter, I think of three parties – "The Good, the Bad, and the Ugly." "The Bad" would reflect the spammer, or bad actor, intentionally causing havoc on the systems. They send masses of forged emails to victims around the world. "The Good" would reflect whoever is listed in the Return-Path: header, the From: header, or sometimes Reply-To:. Surprisingly, "The Ugly" would reflect the recipient of the spam, who ends up sending backscatter.
Say a spammer sends an “I hate you” email to a thousand people with a From: address of email@example.com. One of those recipient addresses is unknown@returnpath.net, where returnpath.net is a legitimate domain, but it doesn’t have an active “unknown” email account. If Return Path handles incoming bounces asynchronously, then we would accept the incoming email first, and then send a rejection later — thus "asynchronous." The rejection would be in the form of a new email message, a non-delivery notification sent to email@example.com saying that their “I hate you” email was not delivered because the unknown@returnpath.net email account doesn’t exist. Example Corp. would be completely confused of what’s going on because they never sent the undeliverable email in the first place.
Let’s look at the same scenario, but assume the forged sending email address is a spam trap. Now Return Path would be sending a rejection email to a spam trap, and if that spam trap happens to be one that feeds into the Backscatter Blacklist or another blacklist, then Return Path’s IP address would get blacklisted.
To minimize the risk of sending backscatter, check your mail server configuration (or ask your IT staff to check it) to determine how the rejection of incoming email is handled. Make sure that it is handling bounces synchronously, which means that rejections occur immediately during the SMTP conversation.
You can test the bounce processing by opening an SMTP connection to your MX server, and attempting to send a message to an address that you know is invalid. If the server rejects the email immediately after the RCPT TO command, then that means bounces are being handled synchronously. If the server lets you continue to send the email, then the bounce is handled asynchronously, which is not what you want.
There are many more recommendations on how to help minimize backscatter, but not all of them are viable solutions from a business standpoint. In a perfect world, you would never send auto-generated email replies, but seriously, I need to be able to send my out-of-office notifications. So, start by looking into your bounce handling procedures because it can make the biggest impact on backscatter with minimal effect to your business.
