Part 1 of 2 parts
If your users occasionally have e-mail messages that come back with a Non-Delivery Report (NDR), it is usually no big deal.
The NDR is often issued because a recipient's e-mail address was misspelled, or because of problems on the recipient's mail system. So when a user contacts the IT department because of an NDR, it is often easy to blow them off and just tell them that the problem isn't on your end.
Well, don't be so quick to dismiss the problem because NDRs, especially frequent ones, can be a sign of much deeper problems.
How can you tell the difference between a NDR that really is no big deal, and one that points to a serious problem? The secret lies in the text within the actual NDR and within your event logs.
Any NDR generated by an Exchange Server will contain the generic text error "your message did not reach some or all of its intended recipients." Usually, this message will be followed by a list of the recipients who didn't receive the message. If you read on, though, there is sometimes an explanation for the NDR. If the explanation says, "you do not have permission to send to this recipient," then you might have a problem.
Another variation of this message is, "the recipient could not be processed because it would violate the security policy in force." Typically, errors such as these two would be accompanied by event IDs 1709 and 1710 in the mail server's Application log.
The possible culprits
There are four different conditions that can cause these types of NDRs. One is that your mail server is configured to prevent relaying. Generally speaking, preventing mail relay is a good idea since spammers routinely exploit mail relays as a mechanism for hiding the source of their messages. However, Exchange has an option that allows you to disable mail relay to everyone except for authenticated users. Allowing authenticated users to relay mail is usually safe.
To enable mail relay for authenticated users, open the Exchange System Manager and navigate through the console tree to your organization | Administrative Groups | your administrative group | Servers | your server | Protocols | SMPT | Default SMTP Virtual Server. Right click on the Default SMTP Virtual Server and select the Properties command from the resulting shortcut menu. When you do, you will see the Default SMTP Virtual Server Properties sheet. Select the properties sheet's Access tab and click the Relay button. Finally, select the Allow all computers that successfully authenticate to relay, regardless of the list above check box, and click OK.
Another cause of these types of NDRs is a change in IP address. This problem tends to occur if the Exchange Server is behind an ISA Server, and the company's ISP issues a dynamic IP address rather than a static one. Once Exchange and ISA Server have been correctly configured, they will continue to work until the organization's IP address changes.
With the way that IP address leases work, companies with dynamic IP addresses tend to keep the same IP address for a long period of time, giving the illusion of a static address. However, if the company's Internet connection were to drop off line and the IP address lease expires during that time, then it is possible that someone else could grab the address that the company had been using, forcing the ISP's DHCP server to issue a new address. When this happens, the ISA Server's SMTP publishing policy is not automatically updated. Since this policy still contains the old address, mail is not delivered and NDRs are issued.
Tomorrow I'll look at the other reason for NDR problems: recipient policies.
Click here to read Part 2.
Brien M. Posey, MCSE, has been designated as a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. Brien has served as the CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer he has written for Microsoft, CNET, ZDNet, Tech Target, MSD2D, Relevant Technologies, and numerous other technology companies. You can visit Brien's personal Web sites at www.brienposey.com and www.relevanttechnologies.com.
