Continuing on from my previous post about the format of Delivery Status Notifications, a DSN must be addressed to the return address from the transport envelope which accompanied the original message for which the DSN was generated. (For a message that arrived via SMTP, the envelope return address appears in the MAIL FROM command.)
The From field of the message header of the DSN should contain the address of a human who is responsible for maintaining the mail system at the Reporting MTA site, such as postmaster@.
The envelope sender address of the DSN should be chosen to ensure that no delivery status reports will be issued in response to the DSN itself, and MUST be chosen so that DSNs will not generate mail loops. Whenever an SMTP transaction is used to send a DSN, the MAIL FROM command MUST use a NULL return address, i.e., "MAIL FROM:<>".
The message/delivery-status content-type
The message/delivery-status content-type is defined as follows:
The message/delivery-status report type for use in the multipart/report is "delivery-status".
The body of a message/delivery-status consists of one or more "fields" formatted according to the ABNF of RFC 822 header "fields" (see [RFC822]). The per-message fields appear first, followed by a blank line. Following the per-message fields are one or more groups of per-recipient fields. Each group of per-recipient fields is preceded by a blank line. Using the ABNF of RFC 822, the syntax of the message/delivery-status content is as follows:
delivery-status-content = per-message-fields 1* ( CRLF per-recipient-fields )
At this point, I'm going to end the summary of the proper format of an NDR. If you're any more interested in it, read the RFC. After having seen a lot NDR messages, it seems to me that mail operators treat the RFC a lot like the Pirates Code from Pirates of the Caribbean - they're not really rules, they're more like guidelines.
In my next post, I will continue on with some intricacies with the who sends the NDR and when.
PingBack from http://blog.a-foton.ru/2008/07/the-problem-of-backscatter-part-5-a-bit-more-on-rfc-3464/