Red Line Software - we help you manage the efficiency of your office operations.

In business there is nearly no company that is not running a mail server to give its employees the possibility of receiving emails right on their desk. But running mail servers means that every administrator has to deal with lots of things. Starting with SPAM, “non delivery reports” is another big thing.

Within this article we will dive a little bit deeper into NDRs, how to deal with them and how to configure them within Exchange Server 2003 as part of Small Business Server 2003.

“Non Delivery Report” Basics

In general, every person using email knows the correct address of their contacts. But there is no guarantee at all that messages are non deliverable due to wrong addresses. If this is so, then there is the need to inform the sender of this problem. These are “non delivery reports” (NDRs). But very often wrong NDRs from spammers or viruses make their way to your mail server.

NDRs can come from:

• Your Email Server System
• Recipient Email Server System
• Relay Servers between

NDRs are standardized, more information on them can be found within the following Requests for comment (RFCs):

• RFC 1891 – SMTP Service Extension for Delivery Status Notifications
• RFC 1892 – The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages
• RFC 1893 – Enhanced Mail System Status Codes
• RFC 1894 – An Extensible Message Format for Delivery Status Notifications

A typical NDR could look like this:

This is the Postfix program at host unknown.domain.com.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to <postmaster>
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The Postfix program
<test1234567890@slkdfjaslkdfjlksadjf.com>: Host or domain name not found. Name
service error for name=slkdfjaslkdfjlksadjf.com type=A: Host not found

Each mail server can now decide how its NDR is configured:

• Original message with embedded body
• Message with original message as attachment

Exchange performs the second option since resending the message to the correct recipient is easier.

Problems with NDRs

The general thought behind NDRs in the RFCs is good, because each sender should be informed if they use the wrong recipient address, but this has negative effects, too.

Lots of spammers use non-existing sender addresses or domains. When they send lots of messages, the recipient servers send NDRs, which the sender message system receives. It tries to figure out where to route these messages without success, with the result that the local message system creates an NDR itself. Due to the design of message systems this new NDR is not rerouted again. Within Exchange Server it will be saved to BADMAIL.

The path to BADMAIL can be configured in the following setting:

Figure 1: Configuring the BADMAIL Directory

The result of this behavior is that lots of companies are not rerouting NDRs at all. Surely, this is against RFCs, but on the other hand their reaction to SPAM-NDRs can be understood as well. The big thing for the future of messaging systems is to filter these messages and not to route them anymore by design.

Exchange and NDRs

Exchange provides NDRs as new emails with an attachment containing the original email. This NDR is rerouted to the original sender and in addition, to the messaging system’s Postmaster, which is the user granted Exchange administrative permission during the first steps of the setup. This user will be given an additional email address following the syntax postmaster@domain.com.

Figure 2: Configuring the Postmaster

The easiest way to avoid unnecessaryNDRs is to configure Exchange Recipient Filtering to not reroute messages with unknown recipients that are not listed in the directory. This can be done in the following setting:

Figure 3: Configuring Recipient Policies

Figure 4: Activating Recipient Policies

But this means that Exchange must have a direct connection to the internet or via an SMTP proxy server. But if you are using a relay server in between, the system will not be able to reroute messages and will generate NDRs instead. This means you will have to configure the relay to have a list of valid internal SMTP addresses.

Since many systems generate reports which lots of users do not understand, Exchange tries to analyze NDRs and replace them with understandable error messages. The original NDR is completely hidden and you as administrator are able to resend the message using a button shown in the error message. This works properly with each Outlook Client and with Outlook Web Access. The language of each system message is the message of your Exchange Server implementation. If you want to disable this conversion of NDRs, you will have to change the following registry setting:

Changing this setting will result in that Exchange routes its own NDRs but adds the hidden original NDR as an attachment. The only problem is that “Resend again” is not available anymore. This configuration disables not only NDRs, it disables delivery reports, too.

If you want to change the language of NDRs on your messaging server system, this can be done quite easily by using a tool provided by Internet Information Server:

The ID can be the following:

The language of NDRs is defined in the file called “mdbsz.dll”. This file can be edited and language can be changed using Resource Kit Editors like rltools.exe or rlquiked.exe, but the problem then is that if the next Hotfix or Service Pack is applied to Exchange, you might have to change these settings again.

Author: Markus Klein

Markus Klein is a MCSA/MCSE Messaging & Security and Microsoft Certified Trainer. He is working as Consultant and IT Senior Trainer at Bechtle AG in the northwest of Germany. He is specialized in Active Directory, Exchange, Security, ISA Server and Clustering on Windows 2000 and Windows Server 2003 designs, migrations and implementations. Markus is a graduate on economical informatics from the University of Applied Science in Osnabrueck/Germany.