The changing nature of email NDRs

We’ve all received NDRs, or non-delivery reports, the way that email servers attempt to be friendly to users when informing them that their email has not been delivered. NDRs have been with us since the very early days of email and several Internet Task Force (IETF) Request for Comments (RFCs) have addressed the need for email servers to generate NDRs in a common format. Given the use of SMTP as the de facto email connectivity standard for many years now (does anyone still use X.400?), you’d expect that NDRs would be a well-rounded feature of any self-respecting email server. It’s therefore strange to me that we still have some odd and cryptic information in NDRs arriving into user mailboxes.

To start with, let’s consider what an NDR is. The Wikipedia definition of a bounce message says “In the Internet's standard e-mail protocol SMTP, a bounce message, also called a Non-Delivery Report/Receipt (NDR), a (failed) Delivery Status Notification (DSN) message, a Non-Delivery Notification (NDN) or simply a bounce, is an automated electronic mail message from a mail system informing the sender of another message about a delivery problem. The original message is said to have bounced”.

OK, we know what an NDR, DSN, or NDN is so a common understanding of their use and function exists. Now let’s have a brief look at the guidance that the relevant standards might offer to developers who have to implement NDRs within an email server.

RFC3464 (January 2003) defines “An Extensible Message Format for Delivery Status Notifications” and states in section 1.2:

(a) It must be readable by humans as well as being machine-parsable.

(b) It must provide enough information to allow message senders (or the user agents) to unambiguously associate a DSN with the message that was sent and the original recipient address for which the DSN is issued (if such information is available), even if the message was forwarded to another recipient address.

(c) It must be able to preserve the reason for the success or failure of a delivery attempt in a remote messaging system, using the "language" (mailbox addresses and status codes) of that remote system.

(d) It must also be able to describe the reason for the success or failure of a delivery attempt, independent of any particular human language or of the "language" of any particular mail system.

(e) It must preserve enough information to allow the maintainer of a remote MTA to understand (and if possible, reproduce) the conditions that caused a delivery failure at that MTA.

The RFC then goes into great details about the individual fields that should be contained in a DSN and their contents, but it doesn’t lay out clear rules for how the DSN should be formatted. The decision about how a DSN should appear to the end user is left to the email vendor and an email system complies with RFC3464 if the required fields are contained in the DSN. However, looking back at section 1.2, it’s clear that the authors of the RFC wanted DSNs that were human-readable and contained sufficient information for a human to be able to figure out why a message failed to be delivered.

The more recent RFC6522 (January 2012) covers the use of MIME body parts for system administrative messages but doesn’t provide any additional guidance as to how DSNs should look when viewed by humans.

The standards have been around for over a decade so they are a well-worn trail for email developers. Of course, we can argue what “readable by humans” really means. For instance, readable doesn’t necessarily mean sensible, cogent, logical, or understandable. Any old text inserted into an NDR and sent back to a user could be deemed to be readable.

Let’s now consult some documentation to see how a vendor addresses the issue. Microsoft provides a good explanation of the various kind of NDRs and DSNs and the codes used in messages generated by Exchange 2013. The article explains that Exchange divides the NDR up into sections intended for the user and administrators. The information provided to the user should explain what caused the message to fail to be delivered. For example, it’s simply too large and exceeds the maximum message size for the organization. The administrative information is where all the cryptic data is provided, complete with the “enhanced status codes” that comply with RFC3463. The article ends with a useful list of the most common status codes.

Things are slightly different inside Office 365 where the Exchange Online team has been grappling with the problem of how to reduce the volume of NDRs processed by the service. They're doing this by focusing on the most common causes of NDRs and attempting to provide clearer and more precise text to end users to tell them what caused the NDR. Any email administrator is likely to guess the common causes, which include:

The work to improve and clarify NDRs has been ongoing for a while now. To perform a quick test of how things are progressing, I sent three messages to addresses that I knew were undeliverable to Office 365, Gmail, and Yahoo! Mail. All three services responded quickly with the expected NDR. Just focusing on the user section, the following information was presented.

Exchange Online/Office 365 NDR

Delivery has failed to these recipients or groups:

[email protected] ([email protected])
The email address you entered couldn't be found. Please check the recipient's email address and try to resend the message. If the problem continues, please contact your helpdesk.

The text is pretty straightforward and to the point. The last two sentences are common to all services.

Gmail NDR:

mx.google.com rejected your message to the following email addresses:

[email protected] ([email protected])

mx.google.com gave this error:
The email account that you tried to reach does not exist. Please try double-checking the recipient's email address for typos or unnecessary spaces. Learn more at http://support.google.com/mail/bin/answer.py?answer=6596 w4si631572wja.116 - gsmtp

The email address you entered couldn't be found. Please check the recipient's email address and try to resend the message. If the problem continues, please contact your helpdesk.

Slightly more verbose than Exchange, the text is also more technical and contains information that might baffle a non-technical user. For instance, is there any need to know the exact server that generated the error message (it’s also in the technical data). On the other hand, Google provides a helpful web link for the user to follow to get more information on likely causes for the problem – and then spoils it by including some gibberish on the end.

Yahoo! Mail NDR:

mta1169.mail.gq1.yahoo.com rejected your message to the following email addresses:

[email protected] ([email protected])

mta1169.mail.gq1.yahoo.com gave this error:
delivery error: dd This user doesn't have a yahoo.com account ([email protected]) [-5] - mta1169.mail.gq1.yahoo.com

A problem occurred while delivering this message to this email address. Try sending this message again. If the problem continues, please contact your helpdesk.

I think this is the worst of the three NDRs. Again we’re told what server generated the message (I care even less about knowing the details of mta1169.mail.gq1.yahoo.com than I did about mx.google.com) and the error text provided has an odd “dd” prefix and an odder [-5] suffix. This is text that only a nerd could love.

All three NDRs satisfy the requirements of RFC3464. In fact, they do a reasonable job of providing information to both users and administrators. I consider the Office 365 version to be the best because it is concise and clear and doesn’t include the various bits of extraneous rubbish that clutter up the Google and Yahoo! NDRs. I do like Google’s inclusion of a web link to further information. You could complain about the excessive use of white space in the NDRs but this is used to create a clear separation between the information intended for users and that intended for administrators.

>I realize that NDR formatting is unexciting to developers. However, I have a sneaky feeling that both Google and Yahoo! could follow the Office 365 lead and try to make their NDRs better with just a little effort. Wouldn’t that be a nice thing?

Follow Tony @12Knocksinna