Email Bounces
In the past few weeks, we have seen a sharp rise in email bounces. These bounces are for emails that the person did not send. While there are many reasons you can get a bounce, the current wave appears to be a spamming technique where spammers spoof reply-to addresses.
Backscatter
Backscatter occurs when a Mail Transport Agent (aka email server) sends a bounce to a person who did not really send the email. Spam Links has a good description of Backscatter and why it happens. Essentially, someone is spoofing the Reply-To field in an email. They then send it to a mail server and it bounces not back to the sending server but to the Reply-To address. Thus you may receive hundreds of spam messages this way.
Symantec, in their April 2008 Spam Report, also noted an upward trend in backscatter attacks. So if you are seeing this issue, you are certainly not alone.
Backscatter Victim?
Unfortunately, there is little you can do. The protocols for email permit anyone to craft a Reply-To address. There is nothing you can do to force someone not to do it. There are some emerging tools that can help. SPF, sender policy framework, is a DNS based method to try to prevent email forgeries. Using DNS, you can specify what servers and IPs are allowed to send email from your domain. SPF can work very well, however, the technique is not widely adopted. Gmail, HotMail and some other major ISPs do use SPF records; however, using SPF alone will not prevent backscatter. The mail administrators must also configure their systems not to bounce emails that fail SPF tests.
If you are being bombarded by these bounces, you may be able to use your own spam filtering to drop the emails. They often have similar subjects, like failed delivery, Delivery Status Notification, or something similar. Typically the attack stops in 2-3 days.
Otherwise, you just have to keep deleting those emails.
Don’t Backscatter
A main source of backscatter is MTA’s that bounce email to unknown users. You should not bounce email that is sent to unknown users. On Plesk and Cpanel there are setting to reject/fail email to unknown users.
On Ensim, there is a problem in that the system creates a default catch-all. While this does not create a backscatter issue, it does create some management problems. The default prevents you from rejecting email to unknown users. As a result, Ensim servers can become overloaded with dictionary-based email attacks. If you remove the catch-alls, then your server will reject email to unkown users.
If your server does bounce emails, you could potential end up in RBLs like Spamcop.net, which not treats backscatter as spam.
Catch-22
Hackers are taking advantage of a key feature of email delivery. Bounces are important for system administrators as they are the first notification that something in the email systems may be awry. However, when they become hijacked by spammers, they become useless as you have to sort through the emails to find real bounces. As a result, some admins just route all bounces to the bit bucket. Disabling bounces can be dangerous however as they can give you an earlier indication if your system has been exploited by a spam bot. Many spammers use web based exploits to use your system to send out the messages. Disabling bounces or null-routing them prevents you from seeing these messages.
Headers, Headers, Headers
To determine if you are the victim of backscatter or if your server is really spamming, you have to analyze the email headers. If the headers do not contain your server as a source for the email, then backscatter is the cause.
Many attackers now spoof many headers in attempts to obfuscate the true sender, but with careful analysis you can often find the source.
Summary
If your inbox is full of those “Delivery Failure Notification” messages then you are likely seeing backscatter. Check the email headers and if the header nearest the bottom is not your server, then it is definitely backscatter.