Home > MS Exchange, Technology > Deciphering Non-Delivery Reports (NDRs)

Deciphering Non-Delivery Reports (NDRs)

22 October 2009 Kirrin

In our work and personal lives, we send or receive at least 10 e-mails per day, some people send at least 5 times that amount and receive just as much. With all those e-mails zipping around in cyberspace and hopping from e-mail server to e-mail server, there will surely be a time when someone will make a mistake or a server will be offline and the result is what is known as a non-delivery report (NDR). I will try to help you to decipher what a NDR is and what should be done.


Non-delivery reports (NDRs) are inevitable. You can only hope that when they do occur that you either have a quick solution or that it is situation that is out of your control. NDRs are e-mails generated by an e-mail server to indicate that an e-mail did not reach the intended destination. The most common cause, I have found for an NDR is an e-mail server being offline. A most frustrating affair is to troubleshoot a non-delivery report without seeing the actual report. Reviewing the actual NDR is critical to the troubleshooting process, as this report normally contains an error report and description indicating why the message was not delivered.

Take a look at the the non-delivery report in the figure below, I sent an e-mail to my Google Wave account, but received an NDR with the following reason for the undelivered message.

You do not have permission to send to this recipient.  For assistance, contact your system administrator. <jti.org.jm #5.7.1 smtp;550 5.7.1 <kirrinjones @ googlewave.com>... Relaying denied>

Sample Non-Delivery Report

Sample Non-Delivery Report

Although the above message may not seem very descriptive, it actually contains very critical information. This is one of the more clear and to the point NDRs. Unfortunately I wanted to finish up the article because it was on my to-do list long enough, and that was the only non-delivery report I could find. So let’s look at this NDR. The first line (You do not have permission to send to this recipient. For assistance, contact your system administrator.) immediately tells you why your e-mail was rejected, you are not authorised to send e-mails to that person. This does not mean that this person cannot receive e-mails, it just means you cannot send to that person. You normally get this error message when an e-mail server requires you to authenticate with it before it accepts e-mails from you. So if you can’t authenticate, then you can’t deliver your e-mail. The next information (<jti.org.jm #5.7.1 smtp;550 5.7.1 <kirrinjones @ googlewave.com>... Relaying denied>) tells you which server that is required to authenticate, this is normally your e-mail server (or your provider), and the delivery status notification (DSN) code that is related to such an error. See the table below for more DSNs and their explanations. It then goes on to tell you the e-mail address of the recipient that the e-mail was intended for and finally the permission related status message.

As you can clearly see, even though the information look very sparse and almost like gibberish (and some of them really do), if you know how to decipher the information, then you really have a lot to go on when figuring out why your e-mails, or your network users’ e-mails aren’t getting to their destination.

DSN codes are defined in RFC 1893 in order to help SMTP-based e-mail systems give better diagnostics reporting. The DSN codes are broken up into three positions, a.b.c. The a value represents the class of the error code. The three classes are:

  1. 2.b.c – these codes represent a success.
  2. 4.b.c – these codes represent a temporary (transient) failure, such as a connection problem.
  3. 5.b.c – these codes represent a permanent error.

The second part of the code, b, indicates the subject of the failure, and the last part of the code, c, indicates the details of the problem or the report. There are seven different types of subjects (b) for these DSNs that identify the major problems, these are:

  1. a.1.c – these codes indicate an addressing problem or an incorrect address.
  2. a.2.c -  these codes indicate a problem with the destination mailbox, such as it being full or cannot accept an e-mail larger than a specific size.
  3. a.3.c – these codes indicate a problem with the destination e-mail system, such as the server being offline or not accepting e-mails.
  4. a.4.c – these codes indicate a problem with the network, message routing, or delivery timeouts due to a connection failure.
  5. a.5.c – these codes indicate problems with the SMTP protocol, such as an unsupported SMTP command.
  6. a.6.c – these codes indicate problems with conversion or media.
  7. a.7.c – these codes indicate a problem with security.

Nice, confused yet? Great, now take a look at the table below for a bit more clarity on what was explain above. Note that I have not provided you with the full listing of DSNs.

dsncodetable

Having to deal with most of these issues on a daily basis, I know the benefits of getting familiar with the errors that can occur. It can save you a lot of headaches and time if you know exactly what to start looking at based on the error message and numbers.

Well that’s it for this article, hope it was informative and helpful in someway.


Categories: MS Exchange, Technology
  1. Chris
    23 October 2009 at 16:09 | #1

    Kirrin, good stuff! Good Stuff!!!

    • 23 October 2009 at 16:27 | #2

      Hey Chris, thanks for reading and commenting. Glad you like the article. Keep checking back for more interesting stuff.

Comments are closed.