dsafley [2008.05.22 6:20:05 AM]
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. From a management standpoint this is very poor. The default prevents you from rejecting email to unknown users. As a result, Ensim servers can become overloaded with dictionary-based email attacks. 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.
Comments (2)
Three quick additions, SPF is actually about the envelope sender address (Return-Path, MAIL FROM), not the Reply-To address.
Receivers checking SPF hopefully reject a forged mail from, if it was spam that’s it. If it was no spam (erroneous sender policy or receiver rejected FAIL elsewhere, relevant for forwarding) the legit sender gets an error code, and will create a good bounce (non-delivery notification) for the user.
Spammers won’t reach many of their targets with an SPF FAIL protected address, and hopefully give up using an unprotected address after some time.
Posted by Frank | May 2, 2008 10:20 AM
Posted on May 2, 2008 10:20
Thanks. I was being careless with my wording. I will make a clarification in the post.
For the backscatter issue, the field is the return-path field. For SPF, I am pretty sure most filters key off of the mail from header. So you could still spoof a reply-to even with SPF filtering provided the mail from headers were correct.
Currently, when we implement SPF filtering for a client, we reject all messages that have a hardfail. Also, on control panels like Plesk, we setup the default templates to include SPF records by default.
I suspect SPF’s ability to curtail spam will be short lived, but at least it should cut down on the email forgeries which are much more dangerous than the spam.
*** Back Scatter 101
http://spamlinks.net/prevent-secure-backscatter.htm
Bounces are messages, officially called non-delivery reports (NDR) or delivery status notifications (DSN), that are generated by a mail server to report on the delivery status of an email message.
Problems arise with bounces if they are sent by a mail server to a non-local recipient. If a message did not originate locally, then a mail server cannot know for sure if the address it is sending the bounce to is forged or not. This quickly leads to unsolicited “backscatter” (or more rarely “outscatter”), sent to sites that never originated the email.