Thanks to all who responded to me privately about the problem of Microsoft Exchange 5.5 sending so many NDRs that it is causing network congestion. Several people responded with suggestions on how to fix (or detour) the problem. I'll summarize those suggestions below. A few people suggested that what I was asking for would violate the RFC for SMTP or gave suggestions on how unknown users can be handled (according to the RFC) without sending NDRs. I'll summarize what the RFC requires, how the change request could be a violation of the RFC, and how it can be implemented to comply with the RFC below. A few people contacted Microsoft to say that they are experiencing the same problem and requested the ability to disable NDR to the Internet in Microsoft Exchange Server 5.5. A Microsoft Product Support Services manager called me this morning to explain that Microsoft will not be making a design change to the legacy product. I'll summarize Microsoft's position on this fix request below. Not only are the large number of NDRs caused by the MyDoom worm a problem, but Reverse NDR spam attacks (see http://www.cmsconnect.com/Praetor/RNDR/prRNDR.htm) is also a problem that cannot easily be dealt with in Microsoft Exchange 5.5. NDRs sent to domains without a properly configured MX server can set in the SMTP outbound queue for 3 days, creating a big backlog in the outbound queue, so big that other problems can happen. Unfortunately, IMO mass mailing worms and spammers have made NDRs almost useless by causing so many illegitimate NDRs that people will no longer pay attention to NDRs. Work arounds ============ Upgrade from Exchange 5.5 ------------------------- The first suggested fix is to upgrade to Microsoft Exchange 200x. This was the first suggestion from Microsoft. Migrating from Windows NT 4 and Exchange 5.5 requires implementing Windows 200x Active Directory, which is a non-trivial change. It is not something that is going to happen over night. I realize that Windows NT 4 and Exchange Server 5.5 are no longer in mainstream support, but there are still a lot of customers using these products. We support several small businesses (6 to 50 users) that just do not have the budget to upgrade to Windows 200x/Exchange 200x right now. Exchange 200x does have the ability to disable NDRs (see MS KB 294757). I am not sure how that configuration change is carried out in the SMTP protocol. Does this setting cause Exchange 200x to respond to a RCPT command with an unknown To: address with a 550 error? Or does Exchange 200x accept the message and then just not send an NDR? Also, Exchange 2000 has a "Accept messages without notifying sender of filtering" option that does accept messages and not send a NDR (see MS KB 276321). I really wonder if the argument about violating the RFC holds up if Exchange 200x can disable NDRs. Front-end Filter ---------------- Install some other SMTP server (that can handle NDRs as we require) as a front-end to the Exchange Server 5.5 server. This font-end server might be provided by a service provider. One person is using an MTA configured to perform an LDAP lookup on the recipient address and reject the message if it isn't a valid email address. Bitbucket Recipient for Unknown Addresses ----------------------------------------- If the unknown recipient addresses are predictable, you can prevent an NDR by add the bogus recipient addresses into a bitbucket mailbox--actually a Distribution List with NO MEMBERS and an additional SMTP addresses for the DL--(see http://assp.sourceforge.net/fom/cache/76.html for details). This works best for addresses such as former employees and not the randomly generated addresses of the MyDoom worm. Filter to Drop Messages ----------------------- A filter (event sync) to detect a MyDoom message and drop it before accepting the message (see http://www.vamsoft.com/orf/tools.asp#novarg) could reduce the traffic to send an NDR when the recipient of the message does not exist. Unfortunately, I think that a tool like this requires Exchange 2000 or later (or the IIS 5.0 or later SMTP service). NDRs and the SMTP RFC ===================== RFC 821 (SMTP protocol) requires that if a mail server accepts mail and then later discovers it cannot deliver the mail, it MUST send an "undeliverable mail" notification message (NDR). Such messages SHOULD be sent with a null return address to prevent looping of NDR messages--yet more unnecessary mail traffic--(a lot of them are not sent that way and we end up sending an NDR message for NDRs sent to us because of a spoofed return addresses in the worm-generated message). Another way to handle an unknown recipient address is during the RCPT command to verify the recipient and if unknown return a 550 error. (It is then up to the originating MTA to send an NDR to the client.) This has the advantage that the original message is not transmitted/processed/stored and an NDR message does not have to be sent, reducing network bandwidth by two messages. However, the time to validate the user might slow down the transfer of messages. Enabling 550 response to unknown users might enable an SMTP AUTH relay attack (see http://www.vamsoft.com/orf/authattack.asp). It appears that Exchange 5.5 only validates the domain part of the recipient address in a RCPT command. Microsoft PSS Response ====================== Microsoft Product Support Services (PSS) initially responded that Exchange 5.5 is in the extended support phase and no non-security fixes are made to products in this phase. Microsoft PSS also responded that the requested fix cannot be implemented because sending Non Delivery Reports follows the RFC. After going through an escalation process, Microsoft PSS responded that they took the case to development and it would require a design change to implement. Microsoft declined to make a design change in this legacy product. Darryl J. Roberts, MCSE, MCP+I, CompTIA CTT+, CSSA Software Engineering Unlimited, Microsoft Certified Partner PO Box 6476, Ventura, CA, USA 93006-6476 tel. 1-805-650-6030, fax 1-805-650-1835 ----- NTBugtraq Editor's Note: Most viruses these days use spoofed email addresses. As such, using an Anti-Virus product which automatically notifies the perceived sender of a message it believes is infected may well cause more harm than good. Someone who did not actually send you a virus may receive the notification and scramble their support staff to find an infection which never existed in the first place. Suggest such notifications be disabled by whomever is responsible for your AV, or at least that the idea is considered. -----