Suspecting a Spam attack of some sort, I checked to be sure we weren't running an 'open relay' (we weren't). But I went ahead and locked it down further so that not even authorized users could send e-mail through the server from the outside.  None of this had any effect. I attempted to stem the tide (flood) by filtering out messages from the obvious offending domains such as *.hinet.net and *.yahoo.com.tw (actually *.tw) and several more. This seemed to help (queues were in the hundreds instead of thousands) but didn't cure the problem. Eventually I decided to bring in the 'big guns'; I called Microsoft. First I called Microsoft's virus and security line, 1-866-SAFETY. They suggested running Ad-Aware which looks for and removes spyware from your system. I ran it on the server and all the workstations. Although numerous 'problems' were found and fixed, this didn't fix the real problem. They then suggested I call their main support line. I did and after an extremely long hold time I eventually wound up with my new best friend, Doug.

First Doug checked all the obvious possible causes and then explained that he thought we were the victims of an NDR (Non-Delivery Report) Spam attack. Since they couldn't relay their junk through our server, they were tricking it into sending it. The specifications for Internet e-mail dictates that the server report back to a sender if it is unable to deliver a message. Exploiting this, the spammers will place the address of the ultimate Spam recipient in the From field of the message and then send it to a bogus account on the victim e-mail server. The server then dutifully reports back to the 'sender' (the Spam target) thus passing the Spam message on to its ultimate recipient. Pretty sneaky, huh? Pretty sick too.

To cure this, my new best friend first emptied the queue by renaming the queues folder (Program Files/Exchsrvr/MailRoot/vs1/queues). Naturally they started building again almost immediately. He then turned off the non-delivery report feature.

To turn off the NDR, follow these steps:

1. Open Exchange System Manager.
2. Open Global Settings.
3. Highlight Internet Message Formats on the tree (left) pane. This then exposes ‘Default’ on the right pane.
4. Right-click Defaults and select Properties from the drop down menu.
5. Click on the Advanced tap.
6. Uncheck the ‘Allow non-delivery reports’ check box
7. Click OK.

If you have other entries besides Default in the Internet Message Formats, you may want to repeat this processes on them as well.

This done, the queues quit building. We tested sending and receiving e-mail which seemed to work fine except for one small problem. My anti-spam filter uses, among many tools, RBL (Replay Blackhole Lists). This is a method whereby my server checks several RBL servers and filters out addresses found there. My client was listed on one of those services. However, I have found some of the RBLs will list senders rather indiscriminatingly. I’ve had them block messages from legitimate users of SBCGlobal and RoadRunner. They were only being trapped by one of my many lists so I don’t think the ‘damage’ is too great. However, should you experience such an attack, you may have to deal with the RBL services as well.

With all the concern these days about security, especially at Microsoft, I wondered why Microsoft hadn’t set the default to not allow non-delivery reports. But then Doug explained that the non-delivery report was part of the RFC (Request For Comments) that lay out the specifications for e-mail services on the Internet. Making that the default would be contrary to that standard. However, if this gets to be a major problem, Microsoft may just have to. Perhaps my little tale of woe will alert enough folks that this spam tactic will be short lived. But then the spammers will no doubt find another insidious way to spread their unwanted junk.