The problem of backscatter, part 4 - What the RFC says

  • Article

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:

  1. The report-type parameter of the multipart/report content is "delivery-status".

  2. The first component of the multipart/report contains a human-readable explanation of the DSN.

  4. The second component of the multipart/report is of content-type message/delivery-status.

  5. 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.