Dear John letters from your Exchange Server - Non Delivery Reports…

Ok, most of us are familiar with NDRs and generally we hate the sight of them – however they can be very useful little critters indeed as they can provide vital clues to transport problems within our mail environments, they also can turn into a problem for you and others if not configured correctly.

As we all know an NDR consists of three numbers each separated with a period (x.x.x).

As a quick summary any NDR code that begins with 5 (5.x.x) is called a permanent (or fatal) transport error – in essence your message will not reach where it needs to go, but an NDR code that begins with 4 (4.x.x) are called Persistent Transient Failure which means that there is a slight chance that your message will reach its destination – for example 4.4.1 (The remote host is not responding) could mean that the receiving MTA is down temporarily – the message will be retried until it expires – if the remote host becomes available within the expiry time the message will be delivered.

In this post I would like to talk a little bit about NDR’s with a view to perhaps give an insight as to why they are useful (if a pain the backside) and also help you understand what can be the pitfalls should the be configured incorrectly.

The Construct of an NDR code;

Lets begin with a visual representation of how an NDR code is constructed:

Construction of an NDR

The above error code (5.1.4) “two objects have the same proxy address” can be logged when two mailboxes contain identical SMTP destinations – generally speaking Exchange will not allow you to add duplicate SMTP addresses to recipients via the ADUC (Active Directory Users and Computers), but, with a mis-configured ADC (Active Directory Connector) it is possible to end up with a contact and a user with the same SMTP proxy.

Ok so now we know what an NDR conceptually looks like – how to they look in real life – the following is an example NDR from an Exchange 2007 server:

Delivery has failed to these recipients or distribution lists:

bloggy@flangemanifold.local
This recipient e-mail address was not found in the recipient e-mail system. Microsoft Exchange will not try to redeliver this message for you. Please check the recipient e-mail address and try resending this message, or provide the following diagnostic text to your system administrator. 


Sent by Microsoft Exchange Server 2007
Diagnostic information for administrators:

Generating server: Gatica.flangemanifold.local

bloggy@flangemanifold.local
#550 5.1.1 RESOLVER.ADR.RecipNotFound; not found ##

Original message headers:

Received: from Gatica.flangemanifold.local ([192.168.1.30]) by Gatica.flangemanifold.local ([192.168.1.30]) with mapi; Sun, 6 May 2007 12:20:49 +0100 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: binary From: "Andrew J. Grogan" To: "bloggy@flangemanifold.com" Date: Sun, 6 May 2007 12:20:48 +0100 Subject: Thread-Index: AQHHj9CY01vBwRlgC0y83nfOG7+Bqw== Message-ID: Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: MIME-Version: 1.0  

The above NDR is 5.1.1 which when looking at it definition is a permanent failure and can mean the following;

The e-mail account does not exist in the organisation that the mail item was sent to, or the message was sent to an outdated entry in a personal address book (or contacts) or, the SMTP address contains characters contained within RFC821 SMTP’s RFC definition.

Normally this NDR means that you have sent a mail to a person that does not have a mail account in the destination domain, or the SMTP address on your original message is wrong – the amount of times that I have seen this message passed to me via our Helpdesk as a “problem with our mail server” only to find that the personal sending the mail has sent it to “Joanna.someone@someplace.com” when it should have gone to “joanne.someone@someplace.com”.

 

Ok, so far we have looked at how an NDR is constructed and looked briefly at some simple NDR’s now lets have a look at the NDR’s that you could see when using Exchange server (or may even see when sending to other mail systems) – the following table has been referenced from: http://www.microsoft.com/technet/prodtechnol/exchange/guides/ExMgmtGuide/fb7830cf-23c6-48a6-8759-526b7854ae39.mspx?mfr=true and is copyright Microsoft.

These are known as the Standard NDR list.

In addition to the above there is an extended set of NDR’s which can be referenced here: http://www.ietf.org/rfc/rfc3463.txt

NDRs – Good or Bad guys;

Directory Harvesting is a very simple way for nasty people to cause you and your mail system grief. The concept is very simple.

The person simply connects to your Outside MTA and then begins the process of guessing your mail addresses (for example – most people will know the latter half of your e-mail address [the domain] – @someplace.com, but most companies also use a defined format for pre-fix addresses – or . and so on) – eventually they will gain access to your GAL, and due to the tools that these people use can kill performance your mail server.

In Exchange the way in which this issues was mitigated by incorrect destinations being bounced asynchronously. Basically the meant that rather than informing the source MTA that the recipient does not exist in the organisation it will claim that all destinations are valid. This (in theory) would frustrate Harvest Attacks as all replies from your domain would be valid so there is no real way to differentiate between a good address or a bad one.

The idea falls down however as, Exchange will need to notify legitimate senders that in some way there mail did not reach a final destination correctly, so Exchange creates a new mail item (the NDR) and returns that to the sender – but – if the sender is trying to propagate spam and has not used their real e-mail address and used the address of someone else (that is legitimate) then your mail server will send a reply to them, thusly you by proxy become a source of spam.

The following diagram will explains the above concept:

ndr-iss

The above problem can be mitigated further (not cured) by enabling Recipient filtering via the Exchange System Manager, like so:

Start the Exchange System Manager.

Go to the Global Settings area – right click on Message Delivery and select properties – like so:

Ex-Fil-pro

When you have clicked on properties you will need to choose the Recipient Filter Tab of the dialog that appears – like so:

Ex-Fil-rt

Tick the box that is entitled “Filter Recepients who are not in the directory

You will be presented with a Informational Message – click OK.

After this, you will need to enable to Recipient Filter on the server that is responsible for you SMTP bridgehead (or relay) communication to the outside world – this can be achieved by drilling down into the servers configuration and selecting the Properties of the SMTP server instance – like so:

SMTP-Prop

When you have done this you will be presented with the following dialog box – you will need to click on the “Advanced Button” on the general page – like so:

SMTP-Props

When you have clicked on the Advanced button you will be presented with the following dialog box:

adv-smtp

Select the IP address configuration for the server, and the click on the “Edit” button, and you will be presented with the following dialog:

Filtering Configuraton

Tick “Apply Recipient Filter” and then click OK.

Stop NDRS from leaving the Organisation;

You can stop NDR’s from leaving your Organisation quite simply by Using the ESM.

Expand the Global Settings Container then select the “Internet Message Format” – in the right hand plane the view will change to display something similar to “Default”  – right click on the “Default” and select Properties from the dialog box that appears click on the Advanced tab and un tick “Allow Non-delivery Reports” then click apply.

Summary;

Well we have had a look at Exchange NDR’s, what they are and how they can be both useful and dangerous – hope that you all liked the article.



Add this page to your favorite Social Bookmarking websites

Last Updated (Wednesday, 30 December 2009 14:09)

 
English (United Kingdom)