Stepping up NDR and DSN filtering response

Stepping up NDR and DSN filtering response

Due to the enormous amount of feedback by our customer base we are stepping up the defense from NDRs received for the emails that were not originated by your users to begin with. This is often called NDR blowback, backscatter, fake virus or worm storm, etc. It happens when someone uses your email address to relay an enormous amount of SPAM to the remote servers and encounters a lot of dead mailboxes that may have already been removed or had their quotas filled with SPAM. Naturally, an error bounces back to you because the remote server thinks you sent it.

We have had NDR backscatter protection for quite some time but the cries from our customer base have forced us to take away our liberal stance on this issue. We are now strictly enforcing NDR legitimacy, meaning that we will only deliver NDR mail if the message was sent through one of our outbound servers. Anything else, because we cannot validate it, will be automatically thrown into the SPAM queue if you choose to quarantine SPAM messages.

Are NDRs SPAM?

No, the non-delivery receipts and delivery status notifications are not SPAM. They do not contain any unsolicited commercial communication, they are not selling anything, they are not dangerous in any way. They are annoying, very annoying when you receive a few hundred in a span of a minute. How did this happen? Well, someone you previously emailed likely got infected by a worm or a virus that searched their hard drive (mailboxes) for email addresses. It then took a random address and joined a botnet and sent thousands of messages and made them appear they came from you. Because the remote (recipient) server did not have proper SPAM protection it blindly accepted the message and issued a rejection.

How does ExchangeDefender know what passed through it and what did not?

ExchangeDefender outbound network stamps each outgoing message with a hash key. When the message is returned in a form of a DSN or NDR we check the SMTP header for the presence of our hash key, we decode it and compare with the local copy stored in our server along with the matching From: message. If the hash key matches the sender of the message the email is passed on to other filters. If it doesn’t it means that  the message is a bounce to the message you never sent in the first place because it did not go through our network and it did not get stamped.

What to do if you still keep on getting NDRs?

There are a few things:

  1. Check that you are sending mail using outbound.exchangedefender.com as your organizations smarthost.
  2. Check that you only have inbound30.exchangedefender.com as your only MX record. If you have more than one your configuration is broken, follow the deployment guide.
  3. Check that you are enforcing IP restrictions, port 25 only and from our exchangedefender.com network only.
  4. If everything looks correct and the NDR was received after Tuesday, May 10th, open a support request with the text of the NDR as well as full SMTP headers of the message for review.

Thank you for trusting us with your mail.