As one of the commenters in my previous post mentioned, RFC 3464 specifies the content-type for Delivery Status Notifications. This isn’t a series about the RFC specification so I shall attempt to summarize it as best I can. This post is mostly a repost of the RFC itself and I include it for the sake of completeness.
DSN’s must provide the following:
- It must be readable by humans as well as being machine-parsable.
- It must provide enough information to allow message senders to unambiguously associate a DSN with the message that was sent and the original recipient address for which the DSN is issued.
- 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.
- 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.
- 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.
- For any notifications issued by foreign mail systems, which are translated by a mail gateway to the DSN format, the DSN must preserve the “type” of the foreign addresses and error codes, so that these may be correctly interpreted by gateways.
Format of a Delivery Status Notification
A DSN is a MIME message with a top-level content-type of multipart/report. When a multipart/report content is used to transmit a DSN:
- The report-type parameter of the multipart/report content is “delivery-status”.
- The first component of the multipart/report contains a human-readable explanation of the DSN.
- The second component of the multipart/report is of content-type message/delivery-status.
- If the original message or a portion of the message is to be returned to the sender, it appears as the third component of the multipart/report.
In my next post, I’ll continue on the RFC.