MAPILab - Microsoft Outlook Add-ins and Software for Microsoft Exchange Server
EnglishGermanRussian
You are here: Home / Support / FAQs and articles / NDR Spam Attack: The Solution

NDR Spam Attack: The Solution

By default, Microsoft® Exchange Server accepts all messages received via SMTP protocol. In case the server is unable to find a recipient within the system the message is returned to the sender (non-delivery report, NDR). This approach, however, may cause a potential security threat: since the sender’s address is not checked, a sender with malicious intentions may set any address as the reply-to address.

As anti-spam activities around the world become more and more widespread, spammers are inventing new ways of sending unsolicited mail. NDR-attacks allow spammers to bypass most of the server side and client side spam check filters:

  • since Exchange Server returns undelivered messages as an attachment, spam filters that monitor the message body and headers for specified keywords operate less than effectively, often allowing such messages to pass through undetected;
  • many users delete unsolicited mail manually without reading it (this takes less than a second); however, when they see a message with ‘Undelivered Mail’ in the subject line they may very well open and read the attached message, not only potentially wasting their time – but what if it contains a virus, or more specifically a worm which would then send messages to all the contacts in their address book?;
  • because the source of such mail is a so-called “honest” server (one that is not found in SPEWS or ORDB databases), sever filters, including the latest filters introduced in Microsoft Exchange 2003 Server will pass the message through.

The consequences of such a security loophole could be devastating:

  • Administrator mailbox gets cluttered with NDR copies, making it easy to lose actual important messages;
  • Server load may cause its malfunction or decrease its efficiency; if the number of connections is limited other mail server connections may be refused;
  • Internet-connection load may cause spontaneous Internet speed slowdown for users on the corporate network.

But all the different points mentioned above really aren’t worth the paper they’re written on when compared with the possible effects of possibly being listed on a spam source list. Getting off the list is much harder than getting on the list. While you spend your time writing to your spam list administrators explaining that some users were not quite right in saying that they were getting unsolicited mail from your server, your users may not be sending their messages out as well as unable to receive all the mail they may be expecting to get. Undoubtedly the most unpleasant experience is getting your server listed in an open relay database (a list of servers accepting mail from any address and delivering it to the addressee - such servers are what all spammers are after). In this case, hundreds of spammers who monitor open relays databases will try to use your server to send unsolicited mail. For several weeks, while your spam database program ensures your server is not closed, your server should expect serious loads. And if there are any spammers who use NDR for sending unsolicited mail there will be only one solution available to you - disable NDR to stop the madness.

It would be incorrect to say that Microsoft does not have any solutions at all for this issue. You may refer to Q315631 — HOW TO: Forward Mail with Unresolved Recipients to a Single Mailbox. This method requires you to create additional virtual SMTP server, used to redirect all mail addressed to unresolved recipients, create an ActiveX component using Microsoft Visual Basic, that will modify the address in a message received and then return the message to the main SMTP server.

The major drawback of this method, besides the complexity of implementation, is about the fact that the Exchange Server keeps receiving all messages. This results in unwanted traffic loss and unwanted server loads.

The optimum solution for such a situation is to block all messages to non-existent addresses on SMTP protocol level. In such a case, the NDR will be generated for the sender by the sender's SMTP server, which is actually common practice.

Mail Storage Guard offers both methods of protection from NDR-attack. It can either redirect all mail with unresolved recipients to a given mailbox or refuse the accepting of mail on SMTP protocol level. Simply press the button once to switch protection mode: don’t accept mail from unresolved addresses during attack or send it to the administrator’s account so he can redirect it to the correct address manually.

Mail Storage Guard checks addresses for the existence of both Active Directory and simple text file lists, which allow the use of Microsoft Exchange Server and Windows SMTP when it is used as a front end to another mail server.

For a detailed description of Mail Storage Guard features see the product description page.

Learn more:

Related links
Support area
Post suggestion
FAQs and articles
 
 
Search on MAPILab.com:
Get our Newsletter:
E-mail:
© 2003-2009 MAPILab Ltd. All Rights Reserved.

Microsoft and the Office logo are trademarks or registered trademarks of Microsoft Corporation in the United States and/or other countries.
Quick links to MAPILab software:

MAPILab Reports

Add-ins for Outlook

Plugins for Outlook

Addons for Office

Plugins for Microsoft Excel

Software for SharePoint

Add-ons for Exchange

Groupware tools

Developer solutions