Delivery Status Notification
DSN, or more-commonly Non-Delivery Reports or "bounce messages," are email error reports explaining why a message failed to be delivered. Historically, mail delivery is assumed to always succeed and is silent on success, while problems with delivery are reported back to the sender. While the format of these messages have been standardised by RFC 3461, the subject lines used to denote them vary among MTAs and often confuse the lay person. Below are some examples of DSN subject lines:
Subject: Returned mail: ... Subject: Failure notice ... Subject: Delivery Status Notification Subject: Undelivered Mail Returned to Sender Subject: Bounced message for ... Subject: Postmaster notify ...
These messages typically have three parts. The first part is the human readable error message and normally includes a portion of the SMTP session transcript showing the exact error reported by the receiving MTA. While this section is intended to be human readable, it is often a technical explanation, which most users do not comprehend. However the bulk of the errors are typically caused by a typographical error in the mail address, such as an invalid user account name or local part before the at-sign (@), incorrect host or domain name after the at-sign, an account mailbox that is over disk space quota, or an account that has been deleted. The sender should carefully review the recipient's mail address and try again.
The second part of an error report is intended to be a machine readable summary of the error.
The third part of an error report is typically the original message headers containing useful information for postmasters, such as the mail route (Received headers), message-ID, subject, and recipient list. This information can aid with mail log searches and possible DNS issues. Sometimes this part also contains the complete text of the sender's message and is often abused by spammers that attempt to slip their tripe through to users in the guise of an error message. For this and privacy reasons, most MTAs default to reporting only the headers in error reports.
A bounce message is sent by the MTA that is trying to relay a message to its destination. If there is an error in delivery, then the MTA generates a report which is sent back using the the "null" sender address, ie. MAIL FROM:<> so as to avoid mail loops. The "null" sender is reserved and treated specially, such that delivery errors for bounce messages are directed to the MTA's postmaster (the infamous double bounce) or simply discarded. Spammers have abused the "null" sender in the past, however, a postmaster must NOT blindly reject the "null" sender, but instead content filter the bounce message. Blocking the "null" sender can cause more trouble in that error messages are lost, leaving users to believe that their mail was successfully delivered, because success is silent, while errors are supposed to be noisy.
Message Disposition Notification
MDN messages are formalised request and message format that allow senders to find out if their mail was received, viewed, and/or deleted by the receiver. These automated messages provide positive feedback about whether a message was read, instead of the default silence on success. Since these messages can be abused by Internet marketers and spammers, the sending of these reports is typically an opt-in choice by the receiver, configured in their MUA.
These messages also use the same "null" sender, ie. MAIL FROM:<>, mechanism to communicate the reports back to the requesting sender. Since the "null" sender address should never be blocked in order to allow proper error reporting, content filtering should be used instead, if MDN messages are to be blocked due to local mail policy.