Protecting Yourself and Others from Backscatter Spam with Exchange Server 2007

Written by Paul Cunningham on April 29, 2009

BackscatterMost of the articles you’ll read on a blog such as this will describe how to protect yourself from certain types of spam.  Most of the articles I’ve written so far do exactly that.  Today I’m going to add another dimension to my post and discuss how to protect both yourself and others from “backscatter” spam.

What is Backscatter Spam?

The term “backscatter spam” refers to a spam attack that targets non-existent email addresses and causes email “bounce” messages to be sent to innocent parties.  The “bounce” messages are known as Non-Delivery Reports (NDRs) and are sent by an email server to let the sender know that the message was not delivered.

NDRs are a normal and useful part of the SMTP protocol.  However when NDRs were first envisaged the concept of address spoofing was not considered.  Address spoofing is when a spammer forges the “From” address on a piece of spam they are sending.  This is how backscatter affects innocent parties – even though they didn’t send the spam, they receive the NDR because their email address was forged by the spammer.

Why does Backscatter Occur with Exchange Server 2007?

An Exchange Server 2007 email server will contribute to the backscatter problem simply due to this default configuration.

Exchange Server 2007 Allow NDRs

This check box tells the Exchange server to send NDRs back to any sending domain (note the wildcard * used as the domain name).  Because the message has already been accepted in full and the original SMTP connection from the spam source disconnected, the Exchange server performs a DNS lookup for the MX record (Mail eXchanger) and sends the NDR to that server.

If the spam forged the email address of john.smith[at]contoso.com, then John is the one who receives the NDR.  John also receives a copy of the spam message, which is included with the NDR message.  So although the spammer has not successfully reached the first intended recipient, they have reached John who is now curious as to what email he apparently sent that caused the NDR (this curiosity increases the chance that he will open the spam and maybe click on a link within it).

Preventing Backscatter from Being Sent by Your Exchange Server

The simplest and most obvious way to prevent an Exchange server sending backscatter spam is to uncheck the box for allowing NDRs to be sent to external domains.  Unfortunately this is not the best way to go about doing it.  NDRs are a valid part of the SMTP protocol and serve a genuinely useful purpose.  Imagine if a business partner incorrectly addressed a critical email and received no NDR.  A business could lose money if the mistake is not noticed straight away, which it would be if an NDR was sent back to the sender.  NDRs are necessary and should not be disabled.

The safest way to prevent backscatter from originating from your server is to block the inbound spam to begin with.  Because most spam originates from compromised home computers it therefore usually comes from untrustworthy blocks of IP addresses.  These IP addresses are included in popular RBL databases such as SpamHaus.  With Exchange Server 2007 you can make use of Connection Filtering to look up sending IP addresses in the SpamHaus database and terminate the SMTP connection.

Because the SMTP connection is terminated without accepting the message your Exchange server does not need to send an NDR to the forged sender address.  Furthermore, because the software used by spammers to send out emails from compromised computers does not bother sending NDRs it will not send one to the forged sender either.

Preventing Backscatter from Being Received by Your Exchange Server

Protecting your own Exchange server from receiving backscatter spam is a little more complicated.  Connection Filtering is not useful here, because the NDRs containing the original spam are likely to be coming from trusted IP addresses.

Content filtering is the most effective way of detecting and blocking backscatter spam that is wrapped up in NDR messages.  Exchange Server 2007 has content filtering capabilities, but they are not very effective in dealing with backscatter spam for some reason.

Fortunately the problem has been solved by third party Exchange 2007 spam filters that can block NDR spam. If NDR spam is becoming a problem for your organisation then it is time to evaluate and deploy one of these anti-spam solutions.

Comments

Pingback: Backscatter Spam and Exchange Server 2007 | The Capslock Assassin

pero October 11, 2012

Hello,
if I understand correctly what you mean in “Preventing Backscatter from Being Sent by Your Exchange Server”, then I can tell you, that you are completly wrong.
You should send NDR to your local users only! Any other mail should be rejected (not bounced!) if the user is unknown.

If your bussiness partner sends an email to you with a misspelled recipient address, then you should reject it. If your exchange rejected the mail, then your partner’s smtp server will send NDR to it’s local user (to your partner). So your partner is informed that his mail has not arrived, but he is informed by his SMTP server, not by yours

And if your user sends a misspelled mail out, then the remote smtp server have to REJECT it (no NDR here!). And because the remote server rejected it, your exchange should send NDR to your LOCAL user.

If you config your server this way, you will not generate backscatter spam!

nordex October 20, 2012

pero, it seems you have no clue how the smtp protocol really works, what you sugest would mean a complete rewrite of how it was implemented. and that is impossible.

when an email arrives from the sender it first reaches it’s own server the users server, when it is sendt onward to what it decides is it’s next hop in the chain it will no longer know if it arrived.
all it knows is that it forwarded the mail to its intended target whatever its exists or not.

the target server will either forward the mail to it’s user if it exist or throw an NDR and it’s here the problem occures as described above.

seriousIT October 31, 2012

@Pero

That sounds more accurate to me as well!!

seriousIT October 31, 2012

Correction: i meant @nordex

pero March 5, 2013

Nordex, i know how SMTP works :)

“the target server will either forward the mail to it’s user if it exist or throw an NDR and it’s here the problem occures as described above.”

This is not right. This behavior causes backscatterer spam! The target server must accept the mail if the user is known or _REJECT_ it if the user is unknown with a “user unkonown” reject code.
If the target server rejects the mail, then the user’s SMTP server will genreate the NDR to it’s local user because it was not accepted by the target server.

It’s very easy to check out if i’m wrong ot not with gmail.
Let’s say, you have an email address at your ISP.
If you send a mail to a non-existent gmail address, the ISP’s SMTP server will generate an NDR, because Gmail will reject the mail with 550 SMTP error (NO NDR here)!
So this is NOT gmail, who sends the NDR!
Try it out, and think it over :)

Google will generete NDR to it’s local users only.

That’s why it is not recommended to completely disable NDR.

pero March 5, 2013

Here you can find how to configure exchange 2003 to prevent sending backscatter:
http://support.microsoft.com/default.aspx?scid=kb;en-us;886208
Maybe it’s something similar with 2007.

This artice explains the same thing that I did:

“To resolve this issue, create a recipient filter to prevent Exchange Server 2003 from accepting messages that are sent to recipients who do not exist.”

I haven’t checked if its working, because I do not operate MS Exchange, but Linux based mail systems,

Mike June 18, 2013

Pero is right. If you have your server configured to reject email from unknown users, it will immediately notify the sending server. So if someone sends an email to your company but misspells the address, they will get an error from their server.

Pero- are there any downsides you know of to turning off NDRs? Seems like it should be a non-issue, but this is the first time I have done this.

  • (required)
  • (required)