How to Monitor Exchange 2007 Non-Delivery Reports (NDR)
So far in this article series I’ve shown you how to create a dedicated postmaster mailbox that can be used to intercept responses to non-delivery reports, and I wrote another article that discusses the meaning of various types of non-delivery reports. If you read that article, you know that some types of nondelivery reports can indicate problems within your Exchange Server organization, or that one of your users may be trying to use your Exchange Server organization as a spam distribution point. Fortunately, there is an easy way of monitoring certain types of nondelivery reports.
You probably don‘t want to monitor every type of nondelivery report that comes through your organization. For example, 5.1.1 reports indicate that a message was sent to a nonexistent recipient. Typically, there probably isn‘t going to be a lot of benefit to monitoring this type of report. On the other hand, 5.7.1 errors can indicate various security issues, and may be worth paying attention to.
Using the Exchange Management Console to Monitor NDR
Exchange Server 2007 is configured by default to monitor certain types of nondelivery reports. The status codes contained within the nondelivery reports are known as Delivery Status Notification codes, and are often abbreviated as DSNs. You can configure the hub transport server to look for specific DSNs, and forward nondelivery reports with those DSN codes to the Exchange recipient.
To do so, open the Exchange Management Console, and navigate through the console tree to Organization Configuration | Hub Transport. Now, choose that Global Settings tab from the results pane, and then click the Properties link found in the Actions pane. When you do, the console will display the Transport Settings Properties sheet, shown in Figure A, below.
The Transport Settings Properties sheet allows you to specify which DSN codes you want to monitor.
As you can see in Figure A, the Message Delivery tab contains a list of the DSN codes that are monitored by default. You can use the Add and Edit buttons to modify the list of codes to meet your needs.
Keep in mind though, that Exchange only sends these nondelivery reports to the user that‘s associated with the message. If you want these codes sent to the postmaster mailbox, you have a couple of options. One option is to define the transport rule that will copy these types of messages to the postmaster mailbox. The other option is to configure similar monitoring on your image transport server. When DSN codes are monitored on an edge transport server, nondelivery reports are copied to the postmaster mailbox (assuming that exists).
Unfortunately, you can‘t use the Exchange Management Console to configure monitoring on an edge transport server. Instead, he will have to use the Exchange Management Shell. The command for doing so is:
Set-TransportConfig –GenerateCopyofDSNFor DSN1, DSN2, DSN3, DSN4
In the command above, DSN1, DSN2, DSN3, and DSN4 are placeholders for the actual DSN status codes. A real life example of the command would look like this:
Set-TransportConfig –GenerateCopyofDSNFor 5.1.4, 5.2.0, 5.4.4, 5.4.6, 5.4.8
In this article, I have explained that monitoring certain types of DSN codes can give you insight into certain aspects of your system that may point to potential problems. I then went on to show you how to modify Exchange Server‘s default DSN monitoring configuration.
More in Exchange Server
Microsoft Exchange Servers Hit By Stealthy IIS Backdoors
Jul 27, 2022 | Rabia Noureen
Kaspersky Discloses New 'SessionManager' Backdoor Targetting Microsoft Exchange Servers
Jul 1, 2022 | Rabia Noureen
M365 Changelog: (Updated) Safe Links Global Settings Migrated to Custom Policies
Jun 28, 2022 | Petri Staff
Microsoft Postpones the Release of Next Version of Exchange Server Until 2025
Jun 3, 2022 | Rabia Noureen
M365 Changelog: Get-AdvancedThreatProtectionDocumentReport and Get-AdvancedThreatProtectionDocumentDetail to be retired
May 24, 2022 | Petri Staff
M365 Changelog: (Updated) Microsoft Defender for Office 365: Updates to URL Protection Report
May 24, 2022 | Petri Staff
Most popular on petri