7Network Working Group K. Moore
8Request for Comments: 3464 University of Tennessee
9Obsoletes: 1894 G. Vaudreuil
10Category: Standards Track Lucent Technologies
14 An Extensible Message Format for Delivery Status Notifications
18 This document specifies an Internet standards track protocol for the
19 Internet community, and requests discussion and suggestions for
20 improvements. Please refer to the current edition of the "Internet
21 Official Protocol Standards" (STD 1) for the standardization state
22 and status of this protocol. Distribution of this memo is unlimited.
26 Copyright (C) The Internet Society (2003). All Rights Reserved.
30 This memo defines a Multipurpose Internet Mail Extensions (MIME)
31 content-type that may be used by a message transfer agent (MTA) or
32 electronic mail gateway to report the result of an attempt to deliver
33 a message to one or more recipients. This content-type is intended
34 as a machine-processable replacement for the various types of
35 delivery status notifications currently used in Internet electronic
38 Because many messages are sent between the Internet and other
39 messaging systems (such as X.400 or the so-called "Local Area Network
40 (LAN)-based" systems), the Delivery Status Notification (DSN)
41 protocol is designed to be useful in a multi-protocol messaging
42 environment. To this end, the protocol described in this memo
43 provides for the carriage of "foreign" addresses and error codes, in
44 addition to those normally used in Internet mail. Additional
45 attributes may also be defined to support "tunneling" of foreign
46 notifications through Internet mail.
58Moore & Vaudreuil Standards Track [Page 1]
60RFC 3464 Delivery Status Notifications January 2003
65 1. Introduction ....................................................3
66 1.1 Purposes .....................................................3
67 1.2 Requirements .................................................4
68 1.3 Terminology ..................................................5
69 2. Format of a Delivery Status Notification ........................7
70 2.1 The message/delivery-status content-type .....................9
71 2.1.1 General conventions for DSN fields ........................9
72 2.1.2 "*-type" sub-fields .......................................9
73 2.1.3 Lexical tokens imported from RFC 822 .....................10
74 2.2 Per-Message DSN Fields ......................................11
75 2.2.1 The Original-Envelope-Id field ...........................11
76 2.2.2 The Reporting-MTA DSN field ..............................12
77 2.2.3 The DSN-Gateway field ....................................13
78 2.2.4 The Received-From-MTA DSN field ..........................14
79 2.2.5 The Arrival-Date DSN field ...............................14
80 2.3 Per-Recipient DSN fields ....................................14
81 2.3.1 Original-Recipient field .................................15
82 2.3.2 Final-Recipient field ....................................15
83 2.3.3 Action field .............................................16
84 2.3.4 Status field .............................................18
85 2.3.5 Remote-MTA field .........................................19
86 2.3.6 Diagnostic-Code field ....................................19
87 2.3.7 Last-Attempt-Date field ..................................20
88 2.3.8 final-log-id field .......................................20
89 2.3.9 Will-Retry-Until field ...................................20
90 2.4 Extension fields ............................................21
91 3. Conformance and Usage Requirements .............................22
92 4. Security Considerations ........................................23
93 4.1 Forgery .....................................................23
94 4.2 Confidentiality .............................................23
95 4.3 Non-Repudiation .............................................25
96 5. References .....................................................25
97 6. Acknowledgments ................................................26
98 Appendix A - Collected Grammar ....................................27
99 Appendix B - Guidelines for Gatewaying DSNS .......................29
100 Gatewaying from other mail systems to DSNs ......................29
101 Gatewaying from DSNs to other mail systems ......................30
102 Appendix C - Guidelines for Use of DSNS By Mailing List Exploders .30
103 Appendix D - IANA Registration Forms for DSN Types ................31
104 IANA registration form for address-type .........................32
105 IANA registration form for diagnostic-type ......................32
106 IANA registration form for MTA-name-type ........................32
107 Appendix E - Examples .............................................33
108 Simple DSN ......................................................34
109 Multi-Recipient DSN .............................................35
110 DSN from gateway to foreign system ..............................36
114Moore & Vaudreuil Standards Track [Page 2]
116RFC 3464 Delivery Status Notifications January 2003
119 Delayed DSN .....................................................37
120 Appendix F - Changes from RFC 1894 ................................38
121 Authors' Addresses ................................................39
122 Full Copyright Statement ..........................................40
126 This memo defines a Multipurpose Internet Mail Extensions (MIME)
127 [MIME1] content-type for Delivery Status Notifications (DSNs). A DSN
128 can be used to notify the sender of a message of any of several
129 conditions: failed delivery, delayed delivery, successful delivery,
130 or the gatewaying of a message into an environment that may not
131 support DSNs. The "message/delivery-status" content-type defined
132 herein is intended for use within the framework of the
133 "multipart/report" content type defined in [REPORT].
135 This memo defines only the format of the notifications. An extension
136 to the Simple Message Transfer Protocol (SMTP) [SMTP] to fully
137 support such notifications is the subject of a separate memo [DRPT].
141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
143 document are to be interpreted as described in BCP 14, RFC 2119
148 The DSNs defined in this memo are expected to serve several purposes:
150 (a) Inform human beings of the status of message delivery processing,
151 as well as the reasons for any delivery problems or outright
152 failures, in a manner that is largely independent of human
155 (b) Allow mail user agents to keep track of the delivery status of
156 messages sent, by associating returned DSNs with earlier message
159 (c) Allow mailing list exploders to automatically maintain their
160 subscriber lists when delivery attempts repeatedly fail;
162 (d) Convey delivery and non-delivery notifications resulting from
163 attempts to deliver messages to "foreign" mail systems via a
170Moore & Vaudreuil Standards Track [Page 3]
172RFC 3464 Delivery Status Notifications January 2003
175 (e) Allow "foreign" notifications to be tunneled through a MIME-
176 capable message system and back into the original messaging
177 system that issued the original notification, or even to a third
180 (f) Allow language-independent and medium-independent, yet reasonably
181 precise, indications of the reason for the failure of a message
184 (g) Provide sufficient information to remote MTA maintainers (via
185 "trouble tickets") so that they can understand the nature of
186 reported errors. This feature is used in the case that failure
187 to deliver a message is due to the malfunction of a remote MTA
188 and the sender wants to report the problem to the remote MTA
193 These purposes place the following constraints on the notification
196 (a) It must be readable by humans as well as being machine-parsable.
198 (b) It must provide enough information to allow message senders (or
199 the user agents) to unambiguously associate a DSN with the
200 message that was sent and the original recipient address for
201 which the DSN is issued (if such information is available), even
202 if the message was forwarded to another recipient address.
204 (c) It must be able to preserve the reason for the success or failure
205 of a delivery attempt in a remote messaging system, using the
206 "language" (mailbox addresses and status codes) of that remote
209 (d) It must also be able to describe the reason for the success or
210 failure of a delivery attempt, independent of any particular
211 human language or of the "language" of any particular mail
214 (e) It must preserve enough information to allow the maintainer of a
215 remote MTA to understand (and if possible, reproduce) the
216 conditions that caused a delivery failure at that MTA.
218 (f) For any notifications issued by foreign mail systems, which are
219 translated by a mail gateway to the DSN format, the DSN must
220 preserve the "type" of the foreign addresses and error codes, so
221 that these may be correctly interpreted by gateways.
226Moore & Vaudreuil Standards Track [Page 4]
228RFC 3464 Delivery Status Notifications January 2003
231 A DSN contains a set of per-message fields that identify the message
232 and the transaction during which the message was submitted, along
233 with other fields that apply to all delivery attempts described by
234 the DSN. The DSN also includes a set of per-recipient fields to
235 convey the result of the attempt to deliver the message to each of
236 one or more recipients.
240 A message may be transmitted through several message transfer agents
241 (MTAs) on its way to a recipient. For a variety of reasons,
242 recipient addresses may be rewritten during this process, so each MTA
243 may potentially see a different recipient address. Depending on the
244 purpose for which a DSN is used, different formats of a particular
245 recipient address will be needed.
247 Several DSN fields are defined in terms of the view from a particular
248 MTA in the transmission. The MTAs are assigned the following names:
252 The Original MTA is the one to which the message is submitted for
253 delivery by the sender of the message.
257 For any DSN, the Reporting MTA is the one which is reporting the
258 results of delivery attempts described in the DSN.
260 If the delivery attempts described occurred in a "foreign" (non-
261 Internet) mail system, and the DSN was produced by translating
262 the foreign notice into DSN format, the Reporting MTA will still
263 identify the "foreign" MTA where the delivery attempts occurred.
265 (c) Received-From MTA
267 The Received-From MTA is the MTA from which the Reporting MTA
268 received the message, and accepted responsibility for delivery of
273 If an MTA determines that it must relay a message to one or more
274 recipients, but the message cannot be transferred to its "next
275 hop" MTA, or if the "next hop" MTA refuses to accept
276 responsibility for delivery of the message to one or more of its
277 intended recipients, the relaying MTA may need to issue a DSN on
278 behalf of the recipients for whom the message cannot be
282Moore & Vaudreuil Standards Track [Page 5]
284RFC 3464 Delivery Status Notifications January 2003
287 delivered. In this case the relaying MTA is the Reporting MTA,
288 and the "next hop" MTA is known as the Remote MTA.
290 Figure 1 illustrates the relationship between the various MTAs.
292+-----+ +--------+ +---------+ +---------+ +------+
293| | | | |Received-| | | | |
294| | => |Original| => ... => | From | => |Reporting| ===> |Remote|
295| user| | MTA | | MTA | | MTA | <No! | MTA |
296|agent| +--------+ +---------+ +----v----+ +------+
298| | <-------------------------------------------+
299+-----+ (DSN returned to sender by Reporting MTA)
301 Figure 1. Original, Received-From, Reporting and Remote MTAs
303 Each of these MTAs may provide information that is useful in a DSN:
305 + Ideally, the DSN will contain the address of each recipient as
306 originally specified to the Original MTA by the sender of the
309 This version of the address is needed (rather than a forwarding
310 address or some modified version of the original address) so that
311 the sender may compare the recipient address in the DSN with the
312 address in the sender's records (e.g., an address book for an
313 individual, the list of subscribers for a mailing list) and take
316 Similarly, the DSN might contain an "envelope identifier" that was
317 known to both the sender's user agent and the Original MTA at the
318 time of message submission, and which, if included in the DSN, can
319 be used by the sender to keep track of which messages were or were
322 + If a message was (a) forwarded to a different address than that
323 specified by the sender, (b) gatewayed to a different mail system
324 than that used by the sender, or (c) subjected to address rewriting
325 during transmission, the "final" form of the recipient address
326 (i.e., the one seen by the Reporting MTA) will be different than
327 the original (sender-specified) recipient address. Just as the
328 sender's user agent (or the sender) prefers the original recipient
329 address, so the "final" address is needed when reporting a problem
330 to the postmaster of the site where message delivery failed,
331 because only the final recipient address will allow her to
332 reproduce the conditions that caused the failure.
338Moore & Vaudreuil Standards Track [Page 6]
340RFC 3464 Delivery Status Notifications January 2003
343 + A "failed" DSN should contain the most accurate explanation for the
344 delivery failure that is available. For ease of interpretation,
345 this information should be a format that is independent of the mail
346 transport system that issued the DSN. However, if a foreign error
347 code is translated into some transport-independent format, some
348 information may be lost. It is therefore desirable to provide both
349 a transport-independent status code and a mechanism for reporting
350 transport-specific codes. Depending on the circumstances that
351 produced delivery failure, the transport-specific code might be
352 obtained from either the Reporting MTA or the Remote MTA.
354 Since different values for "recipient address" and "delivery status
355 code" are needed according to the circumstance in which a DSN will be
356 used, and since the MTA that issues the DSN cannot anticipate those
357 circumstances, the DSN format described here may contain both the
358 original and final forms of a recipient address, and both a
359 transport-independent and a transport-specific indication of delivery
362 Extension fields may also be added by the Reporting MTA as needed to
363 provide additional information for use in a trouble ticket or to
364 preserve information for tunneling of foreign delivery reports
365 through Internet DSNs.
367 The Original, Reporting, and Remote MTAs may exist in very different
368 environments and use dissimilar transport protocols, MTA names,
369 address formats, and delivery status codes. DSNs therefore do not
370 assume any particular format for mailbox addresses, MTA names, or
371 transport-specific status codes. Instead, the various DSN fields
372 that carry such quantities consist of a "type" sub-field followed by
373 a sub-field whose contents are ordinary text characters, and the
374 format of which is indicated by the "type" sub-field. This allows a
375 DSN to convey these quantities regardless of format.
379 A DSN is a MIME message with a top-level content-type of
380 multipart/report (defined in [REPORT]). When a multipart/report
381 content is used to transmit a DSN:
383 (a) The report-type parameter of the multipart/report content is
386 (b) The first component of the multipart/report contains a human-
387 readable explanation of the DSN, as described in [REPORT].
394Moore & Vaudreuil Standards Track [Page 7]
396RFC 3464 Delivery Status Notifications January 2003
399 (c) The second component of the multipart/report is of content-type
400 message/delivery-status, described in section 2.1 of this
403 (d) If the original message or a portion of the message is to be
404 returned to the sender, it appears as the third component of the
407 NOTE: For delivery status notifications gatewayed from foreign
408 systems, the headers of the original message may not be available.
409 In this case the third component of the DSN may be omitted, or it may
410 contain "simulated" RFC 822 headers that contain equivalent
411 information. In particular, it is very desirable to preserve the
412 subject, date, and message-id (or equivalent) fields from the
416 transport envelope) to the return address from the transport envelope
417 which accompanied the original message for which the DSN was
418 generated. (For a message that arrived via SMTP, the envelope return
419 address appears in the MAIL FROM command.)
422 address of a human who is responsible for maintaining the mail system
423 at the Reporting MTA site (e.g., Postmaster), so that a reply to the
424 DSN will reach that person. Exception: if a DSN is translated from a
425 foreign delivery report, and the gateway performing the translation
426 cannot determine the appropriate address, the From field of the DSN
427 MAY be the address of a human who is responsible for maintaining the
430 The envelope sender address of the DSN SHOULD be chosen to ensure
431 that no delivery status reports will be issued in response to the DSN
432 itself, and MUST be chosen so that DSNs will not generate mail loops.
434 command MUST use a NULL return address, i.e., "MAIL FROM:<>".
437 message. However, an MTA MAY report on the delivery status for
438 several recipients of the same message in a single DSN. Due to the
439 nature of the mail transport system (where responsibility for
440 delivery of a message to its recipients may be split among several
441 MTAs, and delivery to any particular recipient may be delayed),
442 multiple DSNs may still be issued in response to a single message
450Moore & Vaudreuil Standards Track [Page 8]
452RFC 3464 Delivery Status Notifications January 2003
457 The message/delivery-status content-type is defined as follows:
459 MIME type name: message
460 MIME subtype name: delivery-status
461 Optional parameters: none
462 Encoding considerations: "7bit" encoding is sufficient and
463 MUST be used to maintain readability
464 when viewed by non-MIME mail readers.
465 Security considerations: discussed in section 4 of this memo.
467 The message/delivery-status report type for use in the
468 multipart/report is "delivery-status".
471 "fields" formatted according to the ABNF of RFC 822 header "fields"
472 (see [RFC822]). The per-message fields appear first, followed by a
473 blank line. Following the per-message fields are one or more groups
474 of per-recipient fields. Each group of per-recipient fields is
475 preceded by a blank line. Using the ABNF of RFC 822, the syntax of
476 the message/delivery-status content is as follows:
478 delivery-status-content = per-message-fields 1*
479 ( CRLF per-recipient-fields )
481 The per-message fields are described in section 2.2. The
482 per-recipient fields are described in section 2.3.
4842.1.1 General conventions for DSN fields
487 same conventions for continuation lines and comments apply.
488 Notification fields may be continued onto multiple lines by beginning
489 each additional line with a SPACE or HTAB. Text that appears in
490 parentheses is considered a comment and not part of the contents of
491 that notification field. Field names are case-insensitive, so the
492 names of notification fields may be spelled in any combination of
493 upper and lower case letters. Comments in DSN fields may use the
494 "encoded-word" construct defined in [MIME3].
4962.1.2 "*-type" sub-fields
498 Several DSN fields consist of a "-type" sub-field, followed by a
499 semicolon, followed by "*text". For these fields, the keyword used
500 in the address-type, diagnostic-type, or MTA-name-type sub-field
501 indicates the expected format of the address, status-code, or
502 MTA-name which follows.
506Moore & Vaudreuil Standards Track [Page 9]
508RFC 3464 Delivery Status Notifications January 2003
511 The "-type" sub-fields are defined as follows:
519 example, when a DSN field contains a reply code reported via the
520 Simple Mail Transfer Protocol [SMTP], the "smtp" diagnostic-type
523 diagnostic-type = atom
526 example, for an SMTP server on an Internet host, the MTA name is
527 the domain name of that host, and the "dns" MTA-name-type is
532 Values for address-type, diagnostic-type, and MTA-name-type are
533 case-insensitive. Thus address-type values of "RFC822" and "rfc822"
537 registry of address-types, diagnostic-types, and MTA-name-types,
538 along with descriptions of the meanings and acceptable values of
539 each, or a reference to one or more specifications that provide such
540 descriptions. (The "rfc822" address-type, "smtp" diagnostic-type,
541 and "dns" MTA-name-type are defined in [DRPT].) Registration forms
542 for address-type, diagnostic-type, and MTA-name-type appear in
545 IANA will not accept registrations for any address-type,
546 diagnostic-type, or MTA-name-type name that begins with "X-". These
547 type names are reserved for experimental use.
5492.1.3 Lexical tokens imported from RFC 822
551 The following lexical tokens, defined in [RFC822], are used in the
552 ABNF grammar for DSNs: atom, CHAR, comment, CR, CRLF, DIGIT, LF,
553 linear-white-space, SPACE, text. The date-time lexical token is
554 defined in [HOSTREQ].
562Moore & Vaudreuil Standards Track [Page 10]
564RFC 3464 Delivery Status Notifications January 2003
5672.2 Per-Message DSN Fields
569 Some fields of a DSN apply to all of the delivery attempts described
570 by that DSN. At most, these fields may appear once in any DSN.
571 These fields are used to correlate the DSN with the original message
572 transaction and to provide additional information which may be useful
576 [ original-envelope-id-field CRLF ]
577 reporting-mta-field CRLF
578 [ dsn-gateway-field CRLF ]
579 [ received-from-mta-field CRLF ]
580 [ arrival-date-field CRLF ]
581 *( extension-field CRLF )
585 The optional Original-Envelope-Id field contains an "envelope
586 identifier" that uniquely identifies the transaction during which the
587 message was submitted, and was either (a) specified by the sender and
588 supplied to the sender's MTA, or (b) generated by the sender's MTA
589 and made available to the sender when the message was submitted. Its
590 purpose is to allow the sender (or her user agent) to associate the
591 returned DSN with the specific transaction in which the message was
594 If such an envelope identifier was present in the envelope that
595 accompanied the message when it arrived at the Reporting MTA, it
596 SHOULD be supplied in the Original-Envelope-Id field of any DSNs
597 issued as a result of an attempt to deliver the message. Except when
598 a DSN is issued by the sender's MTA, an MTA MUST NOT supply this
599 field unless there is an envelope-identifier field in the envelope
600 that accompanied this message on its arrival at the Reporting MTA.
602 The Original-Envelope-Id field is defined as follows:
604 original-envelope-id-field =
605 "Original-Envelope-Id" ":" envelope-id
609 There may be at most one Original-Envelope-Id field per DSN.
611 The envelope-id is CASE-SENSITIVE. The DSN MUST preserve the
612 original case and spelling of the envelope-id.
618Moore & Vaudreuil Standards Track [Page 11]
620RFC 3464 Delivery Status Notifications January 2003
623 NOTE: The Original-Envelope-Id is NOT the same as the
624 Message-Id from the message header. The Message-Id identifies
625 the content of the message, while the Original-Envelope-Id
626 identifies the transaction in which the message is sent.
630 reporting-mta-field =
631 "Reporting-MTA" ":" mta-name-type ";" mta-name
635 The Reporting-MTA field is defined as follows:
637 A DSN describes the results of attempts to deliver, relay, or gateway
638 a message to one or more recipients. In all cases, the Reporting-MTA
639 is the MTA that attempted to perform the delivery, relay, or gateway
640 operation described in the DSN. This field is required.
642 Note that if an SMTP client attempts to relay a message to an SMTP
643 server and receives an error reply to a RCPT command, the client is
644 responsible for generating the DSN, and the client's domain name will
645 appear in the Reporting-MTA field. (The server's domain name will
646 appear in the Remote-MTA field.)
648 Note that the Reporting-MTA is not necessarily the MTA which actually
649 issued the DSN. For example, if an attempt to deliver a message
650 outside of the Internet resulted in a non-delivery notification which
651 was gatewayed back into Internet mail, the Reporting-MTA field of the
652 resulting DSN would be that of the MTA that originally reported the
653 delivery failure, not that of the gateway which converted the foreign
654 notification into a DSN. See Figure 2.
674Moore & Vaudreuil Standards Track [Page 12]
676RFC 3464 Delivery Status Notifications January 2003
679 sender's environment recipient's environment
680 ............................ ..........................................
683 +-----+ +--------+ +--------+ +---------+ +---------+ +------+
684 | | | | | | |Received-| | | | |
685 | |=>|Original|=>| |->| From |->|Reporting|-->|Remote|
686 | user| | MTA | | | | MTA | | MTA |<No| MTA |
687 |agent| +--------+ |Gateway | +---------+ +----v----+ +------+
689 | | <============| |<-------------------+
693 ...........................: :.........................................
695 Figure 2. DSNs in the presence of gateways
697 (1) message is gatewayed into recipient's environment
698 (2) attempt to relay message fails
699 (3) reporting-mta (in recipient's environment) returns non-delivery
701 (4) gateway translates foreign notification into a DSN
703 The mta-name portion of the Reporting-MTA field is formatted
704 according to the conventions indicated by the mta-name-type
705 sub-field. If an MTA functions as a gateway between dissimilar mail
706 environments and thus is known by multiple names depending on the
707 environment, the mta-name sub-field SHOULD contain the name used by
708 the environment from which the message was accepted by the
711 Because the exact spelling of an MTA name may be significant in a
712 particular environment, MTA names are CASE-SENSITIVE.
716 The DSN-Gateway field indicates the name of the gateway or MTA that
717 translated a foreign (non-Internet) delivery status notification into
718 this DSN. This field MUST appear in any DSN that was translated by a
719 gateway from a foreign system into DSN format, and MUST NOT appear
722 dsn-gateway-field = "DSN-Gateway" ":" mta-name-type ";" mta-name
724 For gateways into Internet mail, the MTA-name-type will normally be
725 "dns", and the mta-name will be the Internet domain name of the
730Moore & Vaudreuil Standards Track [Page 13]
732RFC 3464 Delivery Status Notifications January 2003
737 The optional Received-From-MTA field indicates the name of the MTA
738 from which the message was received.
740 received-from-mta-field =
741 "Received-From-MTA" ":" mta-name-type ";" mta-name
743 If the message was received from an Internet host via SMTP, the
744 contents of the mta-name sub-field SHOULD be the Internet domain name
745 supplied in the HELO or EHLO command, and the network address used by
746 the SMTP client SHOULD be included as a comment enclosed in
747 parentheses. (In this case, the MTA-name-type will be "dns".)
749 The mta-name portion of the Received-From-MTA field is formatted
750 according to the conventions indicated by the MTA-name-type sub-
753 Since case is significant in some mail systems, the exact spelling,
754 including case, of the MTA name SHOULD be preserved.
7562.2.5 The Arrival-Date DSN field
759 the message arrived at the Reporting MTA. If the Last-Attempt-Date
760 field is also provided in a per-recipient field, this can be used to
761 determine the interval between when the message arrived at the
762 Reporting MTA and when the report was issued for that recipient.
764 arrival-date-field = "Arrival-Date" ":" date-time
766 The date and time are expressed in RFC 822 'date-time' format, as
767 modified by [HOSTREQ]. Numeric timezones ([+/-]HHMM format) MUST be
7702.3 Per-Recipient DSN fields
772 A DSN contains information about attempts to deliver a message to one
773 or more recipients. The delivery information for any particular
774 recipient is contained in a group of contiguous per-recipient fields.
775 Each group of per-recipient fields is preceded by a blank line.
786Moore & Vaudreuil Standards Track [Page 14]
788RFC 3464 Delivery Status Notifications January 2003
791 The syntax for the group of per-recipient fields is as follows:
793 per-recipient-fields =
794 [ original-recipient-field CRLF ]
795 final-recipient-field CRLF
798 [ remote-mta-field CRLF ]
799 [ diagnostic-code-field CRLF ]
800 [ last-attempt-date-field CRLF ]
801 [ final-log-id-field CRLF ]
802 [ will-retry-until-field CRLF ]
803 *( extension-field CRLF )
8052.3.1 Original-Recipient field
808 as specified by the sender of the message for which the DSN is being
811 original-recipient-field =
812 "Original-Recipient" ":" address-type ";" generic-address
814 generic-address = *text
816 The address-type field indicates the type of the original recipient
817 address. If the message originated within the Internet, the
818 address-type field will normally be "rfc822", and the address will be
820 should be used if the Reporting MTA cannot determine the type of the
821 original recipient address from the message envelope.
823 This field is optional. It should be included only if the sender-
824 specified recipient address was present in the message envelope, such
825 as by the SMTP extensions defined in [DRPT]. This address is the
826 same as that provided by the sender and can be used to automatically
827 correlate DSN reports and message transactions.
831 The Final-Recipient field indicates the recipient for which this set
832 of per-recipient fields applies. This field MUST be present in each
833 set of per-recipient data.
842Moore & Vaudreuil Standards Track [Page 15]
844RFC 3464 Delivery Status Notifications January 2003
847 The syntax of the field is as follows:
849 final-recipient-field =
850 "Final-Recipient" ":" address-type ";" generic-address
852 The generic-address sub-field of the Final-Recipient field MUST
853 contain the mailbox address of the recipient (from the transport
854 envelope), as it was when the Reporting MTA accepted the message for
857 The Final-Recipient address may differ from the address originally
858 provided by the sender, because it may have been transformed during
859 forwarding and gatewaying into a totally unrecognizable mess.
860 However, in the absence of the optional Original-Recipient field, the
861 Final-Recipient field and any returned content may be the only
862 information available with which to correlate the DSN with a
863 particular message submission.
865 The address-type sub-field indicates the type of address expected by
866 the reporting MTA in that context. Recipient addresses obtained via
867 SMTP will normally be of address-type "rfc822".
869 NOTE: The Reporting MTA is not expected to ensure that the address
870 actually conforms to the syntax conventions of the address-type.
871 Instead, it MUST report exactly the address received in the envelope,
872 unless that address contains characters such as CR or LF which are
873 not allowed in a DSN field.
875 Since mailbox addresses (including those used in the Internet) may be
876 case sensitive, the case of alphabetic characters in the address MUST
881 The Action field indicates the action performed by the Reporting-MTA
882 as a result of its attempt to deliver the message to this recipient
883 address. This field MUST be present for each recipient named in the
886 The syntax for the action-field is:
888 action-field = "Action" ":" action-value
891 "failed" / "delayed" / "delivered" / "relayed" / "expanded"
893 The action-value may be spelled in any combination of upper and lower
898Moore & Vaudreuil Standards Track [Page 16]
900RFC 3464 Delivery Status Notifications January 2003
903 "failed" indicates that the message could not be delivered to the
904 recipient. The Reporting MTA has abandoned any attempts
905 to deliver the message to this recipient. No further
906 notifications should be expected.
908 "delayed" indicates that the Reporting MTA has so far been unable
909 to deliver or relay the message, but it will continue to
910 attempt to do so. Additional notification messages may
911 be issued as the message is further delayed or
912 successfully delivered, or if delivery attempts are later
915 "delivered" indicates that the message was successfully delivered to
916 the recipient address specified by the sender, which
917 includes "delivery" to a mailing list exploder. It does
918 not indicate that the message has been read. This is a
919 terminal state and no further DSN for this recipient
923 "relayed" indicates that the message has been relayed or gatewayed
924 into an environment that does not accept responsibility
925 for generating DSNs upon successful delivery. This
926 action-value SHOULD NOT be used unless the sender has
927 requested notification of successful delivery for this
930 "expanded" indicates that the message has been successfully
931 delivered to the recipient address as specified by the
932 sender, and forwarded by the Reporting-MTA beyond that
933 destination to multiple additional recipient addresses.
934 An action-value of "expanded" differs from "delivered" in
935 that "expanded" is not a terminal state. Further
936 "failed" and/or "delayed" notifications may be provided.
938 Using the terms "mailing list" and "alias" as defined in [DRPT],
939 section 7.2.7: An action-value of "expanded" is only to be used when
940 the message is delivered to a multiple-recipient "alias". An
941 action-value of "expanded" SHOULD NOT be used with a DSN issued on
942 delivery of a message to a "mailing list".
945 might seem to be redundant with the 'status' field, this is not
946 the case. In particular, a "temporary failure" ("4") status code
947 could be used with an action-value of either "delayed" or
948 "failed". For example, assume that an SMTP client repeatedly
949 tries to relay a message to the mail exchanger for a recipient,
950 but fails because a query to a domain name server timed out.
954Moore & Vaudreuil Standards Track [Page 17]
956RFC 3464 Delivery Status Notifications January 2003
959 After a few hours, it might issue a "delayed" DSN to inform the
960 sender that the message had not yet been delivered. After a few
961 days, the MTA might abandon its attempt to deliver the message
962 and return a "failed" DSN. The status code (which would begin
963 with a "4" to indicate "temporary failure") would be the same for
966 Another example for which the action and status codes may appear
967 contradictory: If an MTA or mail gateway cannot deliver a message
968 because doing so would entail conversions resulting in an
969 unacceptable loss of information, it would issue a DSN with the
970 'action' field of "failure" and a status code of 'XXX'. If the
971 message had instead been relayed, but with some loss of
972 information, it might generate a DSN with the same XXX status-
973 code, but with an action field of "relayed".
977 The per-recipient Status field contains a transport-independent
978 status code that indicates the delivery status of the message to that
979 recipient. This field MUST be present for each delivery attempt
980 which is described by a DSN.
982 The syntax of the status field is:
984 status-field = "Status" ":" status-code
986 status-code = DIGIT "." 1*3DIGIT "." 1*3DIGIT
988 ; White-space characters and comments are NOT allowed within
989 ; a status-code, though a comment enclosed in parentheses
990 ; MAY follow the last numeric sub-field of the status-code.
991 ; Each numeric sub-field within the status-code MUST be
992 ; expressed without leading zero digits.
994 Status codes thus consist of three numerical fields separated by ".".
995 The first sub-field indicates whether the delivery attempt was
996 successful (2= success, 4 = persistent temporary failure, 5 =
997 permanent failure). The second sub-field indicates the probable
998 source of any delivery anomalies, and the third sub-field denotes a
999 precise error condition, if known.
1001 The initial set of status-codes is defined in [STATUS].
1010Moore & Vaudreuil Standards Track [Page 18]
1012RFC 3464 Delivery Status Notifications January 2003
1017 The value associated with the Remote-MTA DSN field is a printable
1018 ASCII representation of the name of the "remote" MTA that reported
1019 delivery status to the "reporting" MTA.
1021 remote-mta-field = "Remote-MTA" ":" mta-name-type ";" mta-name
1023 NOTE: The Remote-MTA field preserves the "while talking to"
1024 information that was provided in some pre-existing nondelivery
1028 involved in the attempted delivery of the message to that recipient.
10302.3.6 Diagnostic-Code field
1032 For a "failed" or "delayed" recipient, the Diagnostic-Code DSN field
1033 contains the actual diagnostic code issued by the mail transport.
1034 Since such codes vary from one mail transport to another, the
1035 diagnostic-type sub-field is needed to specify which type of
1036 diagnostic code is represented.
1038 diagnostic-code-field =
1039 "Diagnostic-Code" ":" diagnostic-type ";" *text
1041 NOTE: The information in the Diagnostic-Code field may be somewhat
1042 redundant with that from the Status field. The Status field is
1043 needed so that any DSN, regardless of origin, may be understood by
1044 any user agent or gateway that parses DSNs. Since the Status code
1045 will sometimes be less precise than the actual transport diagnostic
1046 code, the Diagnostic-Code field is provided to retain the latter
1047 information. Such information may be useful in a trouble ticket sent
1048 to the administrator of the Reporting MTA, or when tunneling foreign
1049 non-delivery reports through DSNs.
1051 If the Diagnostic Code was obtained from a Remote MTA during an
1052 attempt to relay the message to that MTA, the Remote-MTA field should
1054 field indicates that the Diagnostic Code was issued by the Remote
1055 MTA. The absence of a Remote-MTA indicates that the Diagnostic Code
1056 was issued by the Reporting MTA.
1058 In addition to the Diagnostic-Code itself, additional textual
1059 description of the diagnostic, MAY appear in a comment enclosed in
1066Moore & Vaudreuil Standards Track [Page 19]
1068RFC 3464 Delivery Status Notifications January 2003
1071 This field is optional, because some mail systems supply no
1072 additional information beyond that which is returned in the 'action'
1073 and 'status' fields. However, this field SHOULD be included if
1074 transport-specific diagnostic information is available.
1078 The Last-Attempt-Date field gives the date and time of the last
1079 attempt to relay, gateway, or deliver the message (whether successful
1080 or unsuccessful) by the Reporting MTA. This is not necessarily the
1081 same as the value of the Date field from the header of the message
1082 used to transmit this delivery status notification: In cases where
1083 the DSN was generated by a gateway, the Date field in the message
1084 header contains the time the DSN was sent by the gateway and the DSN
1085 Last-Attempt-Date field contains the time the last delivery attempt
1088 last-attempt-date-field = "Last-Attempt-Date" ":" date-time
1090 This field is optional. It MUST NOT be included if the actual date
1091 and time of the last delivery attempt are not available (which might
1092 be the case if the DSN were being issued by a gateway).
1094 The date and time are expressed in RFC 822 'date-time' format, as
1095 modified by [HOSTREQ]. Numeric timezones ([+/-]HHMM format) MUST be
1100 The "final-log-id" field gives the final-log-id of the message that
1101 was used by the final-mta. This can be useful as an index to the
1102 final-mta's log entry for that delivery attempt.
1104 final-log-id-field = "Final-Log-ID" ":" *text
1106 This field is optional.
1110 For DSNs of type "delayed", the Will-Retry-Until field gives the date
1111 after which the Reporting MTA expects to abandon all attempts to
1112 deliver the message to that recipient. The Will-Retry-Until field is
1113 optional for "delay" DSNs, and MUST NOT appear in other DSNs.
1115 will-retry-until-field = "Will-Retry-Until" ":" date-time
1122Moore & Vaudreuil Standards Track [Page 20]
1124RFC 3464 Delivery Status Notifications January 2003
1127 The date and time are expressed in RFC 822 'date-time' format, as
1128 modified by [HOSTREQ]. Numeric timezones ([+/-]HHMM format) MUST be
1133 Additional per-message or per-recipient DSN fields may be defined in
1134 the future by later revisions or extensions to this specification.
1135 Extension-field names beginning with "X-" will never be defined as
1136 standard fields; such names are reserved for experimental use. DSN
1137 field names NOT beginning with "X-" MUST be registered with the
1138 Internet Assigned Numbers Authority (IANA) and published in an RFC.
1140 Extension DSN fields may be defined for the following reasons:
1142 (a) To allow additional information from foreign delivery status
1143 reports to be tunneled through Internet DSNs. The names of such
1144 DSN fields should begin with an indication of the foreign
1145 environment name (e.g., X400-Physical-Forwarding-Address).
1147 (b) To allow the transmission of diagnostic information which is
1148 specific to a particular mail transport protocol. The names of
1149 such DSN fields should begin with an indication of the mail
1150 transport being used (e.g., SMTP-Remote-Recipient-Address). Such
1151 fields should be used for diagnostic purposes only and not by
1152 user agents or mail gateways.
1154 (c) To allow transmission of diagnostic information which is specific
1155 to a particular message transfer agent (MTA). The names of such
1156 DSN fields should begin with an indication of the MTA
1157 implementation that produced the DSN. (e.g., Foomail-Queue-ID).
1159 MTA implementers are encouraged to provide adequate information, via
1160 extension fields if necessary, to allow an MTA maintainer to
1161 understand the nature of correctable delivery failures and how to fix
1162 them. For example, if message delivery attempts are logged, the DSN
1163 might include information that allows the MTA maintainer to easily
1164 find the log entry for a failed delivery attempt.
1166 If an MTA developer does not wish to register the meanings of such
1167 extension fields, "X-" fields may be used for this purpose. To avoid
1168 name collisions, the name of the MTA implementation should follow the
1169 "X-", (e.g., "X-Foomail-Log-ID").
1178Moore & Vaudreuil Standards Track [Page 21]
1180RFC 3464 Delivery Status Notifications January 2003
11833. Conformance and Usage Requirements
1185 An MTA or gateway conforms to this specification if it generates DSNs
1186 according to the protocol defined in this memo. For MTAs and
1187 gateways that do not support requests for positive delivery
1188 notification (such as in [DRPT]), it is sufficient that delivery
1189 failure reports use this protocol.
1191 A minimal implementation of this specification need generate only the
1192 Reporting-MTA per-message field, and the Final-Recipient, Action, and
1193 Status fields for each attempt to deliver a message to a recipient
1194 described by the DSN. Generation of the other fields, when
1195 appropriate, is strongly recommended.
1198 DSN unless the mail transfer protocol provides the address originally
1199 specified by the sender at the time of submission. (Ordinary SMTP
1200 does not make that guarantee, but the SMTP extension defined in
1201 [DRPT] permits such information to be carried in the envelope if it
1204 Each sender-specified recipient address SHOULD result in at most one
1205 "delivered" or "failed" DSN for that recipient. If a positive DSN is
1206 requested (e.g., one using NOTIFY=SUCCESS in SMTP) for a recipient
1207 that is forwarded to multiple recipients of an "alias" (as defined in
1208 [DRPT], section 7.2.7), the forwarding MTA SHOULD normally issue a
1209 "expanded" DSN for the originally-specified recipient and not
1210 propagate the request for a DSN to the forwarding addresses.
1211 Alternatively, the forwarding MTA MAY relay the request for a DSN to
1212 exactly one of the forwarding addresses and not propagate the request
1215 By contrast, successful submission of a message to a mailing list
1216 exploder is considered final delivery of the message. Upon delivery
1217 of a message to a recipient address corresponding to a mailing list
1218 exploder, the Reporting MTA SHOULD issue an appropriate DSN exactly
1219 as if the recipient address were that of an ordinary mailbox.
1221 NOTE: This is actually intended to make DSNs usable by mailing
1222 lists themselves. Any message sent to a mailing list subscriber
1223 should have its envelope return address pointing to the list
1224 maintainer [see RFC 1123, section 5.3.7(E)]. Since DSNs are sent
1225 to the envelope return address, all DSNs resulting from delivery
1226 to the recipients of a mailing list will be sent to the list
1227 maintainer. The list maintainer may elect to mechanically
1228 process DSNs upon receipt, and thus automatically delete invalid
1229 addresses from the list. (See section 7 of this memo.)
1234Moore & Vaudreuil Standards Track [Page 22]
1236RFC 3464 Delivery Status Notifications January 2003
1239 This specification places no restrictions on the processing of DSNs
1240 received by user agents or distribution lists.
12424. Security Considerations
1244 The following security considerations apply when using DSNs:
1248 DSNs may be forged as easily as ordinary Internet electronic mail.
1249 User agents and automatic mail handling facilities (such as mail
1250 distribution list exploders) that wish to make automatic use of DSNs
1251 should take appropriate precautions to minimize the potential damage
1252 from denial-of-service attacks.
1254 Security threats related to forged DSNs include the sending of:
1256 (a) A falsified delivery notification when the message is not
1257 delivered to the indicated recipient,
1259 (b) A falsified non-delivery notification when the message was in
1260 fact delivered to the indicated recipient,
1262 (c) A falsified Final-Recipient address,
1264 (d) A falsified Remote-MTA identification,
1266 (e) A falsified relay notification when the message is "dead ended".
1268 (f) Unsolicited DSNs
1272 Another dimension of security is confidentiality. There may be cases
1273 in which a message recipient is autoforwarding messages but does not
1274 wish to divulge the address to which the messages are autoforwarded.
1275 The desire for such confidentiality will probably be heightened as
1276 "wireless mailboxes", such as pagers, become more widely used as
1277 autoforward addresses.
1279 MTA authors are encouraged to provide a mechanism which enables the
1280 end user to preserve the confidentiality of a forwarding address.
1281 Depending on the degree of confidentiality required, and the nature
1282 of the environment to which a message were being forwarded, this
1283 might be accomplished by one or more of:
1290Moore & Vaudreuil Standards Track [Page 23]
1292RFC 3464 Delivery Status Notifications January 2003
1295 (a) issuing a "relayed" DSN (if a positive DSN was requested) when a
1296 message is forwarded to a confidential forwarding address, and
1297 disabling requests for positive DSNs for the forwarded message,
1299 (b) declaring the message to be delivered, issuing a "delivered" DSN,
1300 re-sending the message to the confidential forwarding address,
1301 and arranging for no DSNs to be issued for the re-sent message,
1303 (c) omitting "Remote-*" or extension fields of a DSN whenever they
1304 would otherwise contain confidential information (such as a
1305 confidential forwarding address),
1307 (d) for messages forwarded to a confidential address, setting the
1308 envelope return address (e.g., SMTP MAIL FROM address) to the
1309 NULL reverse-path ("<>") (so that no DSNs would be sent from a
1310 downstream MTA to the original sender),
1312 (e) for messages forwarded to a confidential address, disabling
1313 delivery notifications for the forwarded message (e.g., if the
1314 "next-hop" MTA uses ESMTP and supports the DSN extension, by
1315 using the NOTIFY=NEVER parameter to the RCPT command), or
1317 (f) when forwarding mail to a confidential address, having the
1318 forwarding MTA rewrite the envelope return address for the
1319 forwarded message and attempt delivery of that message as if the
1320 forwarding MTA were the originator. On its receipt of final
1321 delivery status, the forwarding MTA would issue a DSN to the
1324 In general, any optional DSN field may be omitted if the Reporting
1325 MTA site determines that inclusion of the field would impose too
1326 great a compromise of site confidentiality. The need for such
1327 confidentiality must be balanced against the utility of the omitted
1328 information in trouble reports and DSNs gatewayed to foreign
1331 Implementers are cautioned that many existing MTAs will send non-
1332 delivery notifications to a return address in the message header
1333 (rather than to the one in the envelope), in violation of SMTP and
1334 other protocols. If a message is forwarded through such an MTA, no
1335 reasonable action on the part of the forwarding MTA will prevent the
1336 downstream MTA from compromising the forwarding address. Likewise,
1337 if the recipient's MTA automatically responds to messages based on a
1338 request in the message header (such as the nonstandard, but widely
1339 used, Return-Receipt-To extension header), it will also compromise
1340 the forwarding address.
1346Moore & Vaudreuil Standards Track [Page 24]
1348RFC 3464 Delivery Status Notifications January 2003
1353 Within the framework of today's internet mail, the DSNs defined in
1354 this memo provide valuable information to the mail user; however,
1355 even a "failed" DSN can not be relied upon as a guarantee that a
1356 message was not received by the recipient. Even if DSNs are not
1357 actively forged, conditions exist under which a message can be
1358 delivered despite the fact that a failure DSN was issued.
1360 For example, a race condition in the SMTP protocol allows for the
1361 duplication of messages if the connection is dropped following a
1362 completed DATA command, but before a response is seen by the SMTP
1365 This will cause the SMTP client to retransmit the message, even
1366 though the SMTP server has already accepted it [SMTPDUP]. If one of
1367 those delivery attempts succeeds and the other one fails, a "failed"
1368 DSN could be issued even though the message actually reached the
13715. Normative References
1373 [DRPT] Moore, K., "SMTP Service Extension for Delivery Status
1374 Notifications", RFC 3461, January 2003.
1376 [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format
1377 for Delivery Status Notifications", RFC 1894, January 1996.
1379 [HOSTREQ] Braden, R. (ed.), "Requirements for Internet Hosts -
1380 Application and Support", STD 3, RFC 1123, October 1989.
1382 [MIME1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
1383 Extensions (MIME) Part One: Format of Internet Message
1384 Bodies", RFC 2045, November 1996.
1386 [MIME3] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
1387 Part Three: Message Header Extensions for Non-ASCII Text",
1388 RFC 2047, November 1996.
1390 [REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the
1391 Reporting of Mail System Administrative Messages", RFC
1394 [RFC822] Crocker, D., "Standard for the format of ARPA Internet Text
1395 Messages", STD 11, RFC 822, August 1982.
1397 [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
1402Moore & Vaudreuil Standards Track [Page 25]
1404RFC 3464 Delivery Status Notifications January 2003
1407 [SMTPDUP] Partridge, C., "Duplicate Messages and SMTP", RFC 1047,
1410 [STATUS] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC
1413 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1414 Requirement Levels", BCP 14, RFC 2119, March 1997.
1418 The authors wish to thank the following people for their reviews of
1419 early drafts of RFC 1894, of which this document is a revision, and
1420 their suggestions for improvement: Eric Allman, Harald Alvestrand,
1421 Allan Cargille, Jim Conklin, Peter Cowen, Dave Crocker, Roger Fajman,
1422 Ned Freed, Marko Kaittola, Steve Kille, John Klensin, John Gardiner
1423 Myers, Mark Nahabedian, Julian Onions, Jacob Palme, Jean Charles Roy,
1424 and Gregory Sheehan.
1458Moore & Vaudreuil Standards Track [Page 26]
1460RFC 3464 Delivery Status Notifications January 2003
1463Appendix A - collected grammar
1465 NOTE: The following lexical tokens are defined in RFC 822: atom,
1466 CHAR, comment, CR, CRLF, DIGIT, LF, linear-white-space, SPACE, text.
1467 The date-time lexical token is defined in [HOSTREQ].
1469 action-field = "Action" ":" action-value
1471 action-value = "failed" / "delayed" / "delivered"
1472 / "relayed" / "expanded"
1476 arrival-date-field = "Arrival-Date" ":" date-time
1478 delivery-status-content = per-message-fields
1479 1*( CRLF per-recipient-fields )
1481 diagnostic-code-field = "Diagnostic-Code" ":"
1482 diagnostic-type ";" *text
1484 diagnostic-type = atom
1486 dsn-gateway-field = "DSN-Gateway" ":" mta-name-type ";" mta-name
1490 extension-field = extension-field-name ":" *text
1492 extension-field-name = atom
1494 final-recipient-field =
1495 "Final-Recipient" ":" address-type ";" generic-address
1497 final-log-id-field = "Final-Log-ID" ":" *text
1499 generic-address = *text
1501 last-attempt-date-field = "Last-Attempt-Date" ":" date-time
1505 mta-name-type = atom
1507 original-envelope-id-field =
1508 "Original-Envelope-Id" ":" envelope-id
1514Moore & Vaudreuil Standards Track [Page 27]
1516RFC 3464 Delivery Status Notifications January 2003
1519 original-recipient-field =
1520 "Original-Recipient" ":" address-type ";" generic-address
1523 [ original-envelope-id-field CRLF ]
1524 reporting-mta-field CRLF
1525 [ dsn-gateway-field CRLF ]
1526 [ received-from-mta-field CRLF ]
1527 [ arrival-date-field CRLF ]
1528 *( extension-field CRLF )
1531 [ original-recipient-field CRLF ]
1532 final-recipient-field CRLF
1535 [ remote-mta-field CRLF ]
1536 [ diagnostic-code-field CRLF ]
1537 [ last-attempt-date-field CRLF ]
1538 [ final-log-id-field CRLF ]
1539 [ will-retry-until-field CRLF ]
1540 *( extension-field CRLF )
1542 received-from-mta-field =
1543 "Received-From-MTA" ":" mta-name-type ";" mta-name
1546 "Remote-MTA" ":" mta-name-type ";" mta-name
1548 reporting-mta-field =
1549 "Reporting-MTA" ":" mta-name-type ";" mta-name
1551 status-code = DIGIT "." 1*3DIGIT "." 1*3DIGIT
1553 ; White-space characters and comments are NOT allowed within a
1554 ; a status-code, though a comment enclosed in parentheses
1555 ; MAY follow the last numeric sub-field of the status-code.
1556 ; Each numeric sub-field within the status-code MUST be
1557 ; expressed without leading zero digits.
1559 status-field = "Status" ":" status-code
1561 will-retry-until-field = "Will-Retry-Until" ":" date-time
1570Moore & Vaudreuil Standards Track [Page 28]
1572RFC 3464 Delivery Status Notifications January 2003
1575Appendix B - Guidelines for gatewaying DSNs
1577 NOTE: This section provides non-binding recommendations for the
1578 construction of mail gateways that wish to provide semi-transparent
1579 delivery reports between the Internet and another electronic mail
1580 system. Specific DSN gateway requirements for a particular pair of
1581 mail systems may be defined by other documents.
1583Gatewaying from other mail systems to DSNs
1585 A mail gateway may issue a DSN to convey the contents of a "foreign"
1586 delivery or non-delivery notification over Internet mail. When there
1587 are appropriate mappings from the foreign notification elements to
1588 DSN fields, the information may be transmitted in those DSN fields.
1589 Additional information (such as might be useful in a trouble ticket
1590 or needed to tunnel the foreign notification through the Internet)
1591 may be defined in extension DSN fields. (Such fields should be given
1592 names that identify the foreign mail protocol, e.g., X400-* for X.400
1593 NDN or DN protocol elements)
1595 The gateway must attempt to supply reasonable values for the
1596 Reporting-MTA, Final-Recipient, Action, and Status fields. These
1597 will normally be obtained by translating the values from the remote
1598 delivery or non-delivery notification into their Internet-style
1599 equivalents. However, some loss of information is to be expected.
1600 For example, the set of status-codes defined for DSNs may not be
1601 adequate to fully convey the delivery diagnostic code from the
1602 foreign system. The gateway should assign the most precise code
1603 which describes the failure condition, falling back on "generic"
1604 codes such as 2.0.0 (success), 4.0.0 (temporary failure), and 5.0.0
1605 (permanent failure) when necessary. The actual foreign diagnostic
1606 code should be retained in the Diagnostic-Code field (with an
1607 appropriate diagnostic-type value) for use in trouble tickets or
1610 The sender-specified recipient address, and the original envelope-id,
1611 if present in the foreign transport envelope, should be preserved in
1612 the Original-Recipient and Original-Envelope-ID fields.
1614 The gateway should also attempt to preserve the "final" recipient
1615 addresses and MTA names from the foreign system. Whenever possible,
1616 foreign protocol elements should be encoded as meaningful printable
1619 For DSNs produced from foreign delivery or nondelivery notifications,
1620 the name of the gateway MUST appear in the DSN-Gateway field of the
1626Moore & Vaudreuil Standards Track [Page 29]
1628RFC 3464 Delivery Status Notifications January 2003
1631Gatewaying from DSNs to other mail systems
1633 It may be possible to gateway DSNs from the Internet into a foreign
1634 mail system. The primary purpose of such gatewaying is to convey
1635 delivery status information in a form that is usable by the
1636 destination system. A secondary purpose is to allow "tunneling" of
1637 DSNs through foreign mail systems, in case the DSN may be gatewayed
1638 back into the Internet.
1640 In general, the recipient of the DSN (i.e., the sender of the
1641 original message) will want to know, for each recipient: the closest
1642 available approximation to the original recipient address, the
1643 delivery status (success, failure, or temporary failure), and for
1644 failed deliveries, a diagnostic code that describes the reason for
1647 If possible, the gateway should attempt to preserve the Original-
1648 Recipient address and Original-Envelope-ID (if present), in the
1649 resulting foreign delivery status report.
1651 When reporting delivery failures, if the diagnostic-type sub-field of
1652 the Diagnostic-Code field indicates that the original diagnostic code
1653 is understood by the destination environment, the information from
1654 the Diagnostic-Code field should be used. Failing that, the
1655 information in the Status field should be mapped into the closest
1656 available diagnostic code used in the destination environment.
1658 If it is possible to tunnel a DSN through the destination
1659 environment, the gateway specification may define a means of
1660 preserving the DSN information in the delivery status reports used by
1663Appendix C - Guidelines for use of DSNs by mailing list exploders
1665 This section pertains only to the use of DSNs by "mailing lists" as
1666 defined in [4], section 7.2.7.
1668 DSNs are designed to be used by mailing list exploders to allow them
1669 to detect and automatically delete recipients for whom mail delivery
1672 When forwarding a message to list subscribers, the mailing list
1673 exploder should always set the envelope return address (e.g., SMTP
1674 MAIL FROM address) to point to a special address which is set up to
1675 receive non-delivery reports. A "smart" mailing list exploder can
1676 therefore intercept such non-delivery reports, and if they are in the
1677 DSN format, automatically examine them to determine for which
1678 recipients a message delivery failed or was delayed.
1682Moore & Vaudreuil Standards Track [Page 30]
1684RFC 3464 Delivery Status Notifications January 2003
1687 The Original-Recipient field should be used if available, since it
1688 should exactly match the subscriber address known to the list. If
1689 the Original-Recipient field is not available, the recipient field
1690 may resemble the list subscriber address. Often, however, the list
1691 subscriber will have forwarded his mail to a different address, or
1692 the address may be subject to some re-writing, so heuristics may be
1693 required to successfully match an address from the recipient field.
1694 Care is needed in this case to minimize the possibility of false
1697 The reason for delivery failure can be obtained from the Status and
1698 Action fields, and from the Diagnostic-Code field (if the status-type
1699 is recognized). Reports for recipients with action values other than
1700 "failed" can generally be ignored; in particular, subscribers should
1701 not be removed from a list due to "delayed" reports.
1703 In general, almost any failure status code (even a "permanent" one)
1704 can result from a temporary condition. It is therefore recommended
1705 that a list exploder not delete a subscriber based on any single
1706 failure DSN (regardless of the status code), but only on the
1707 persistence of delivery failure over a period of time.
1709 However, some kinds of failures are less likely than others to have
1710 been caused by temporary conditions, and some kinds of failures are
1711 more likely to be noticed and corrected quickly than others. Once
1712 more precise status codes are defined, it may be useful to
1713 differentiate between the status codes when deciding whether to
1714 delete a subscriber. For example, on a list with a high message
1715 volume, it might be desirable to temporarily suspend delivery to a
1716 recipient address which causes repeated "temporary" failures, rather
1717 than simply deleting the recipient. The duration of the suspension
1718 might depend on the type of error. On the other hand, a "user
1719 unknown" error that persisted for several days could be considered a
1720 reliable indication that address were no longer valid.
1722Appendix D - IANA registration forms for DSN types
1724 The forms below are for use when registering a new address-type,
1725 diagnostic-type, or MTA-name-type with the Internet Assigned Numbers
1726 Authority (IANA). Each piece of information requested by a
1727 registration form may be satisfied either by providing the
1728 information on the form itself, or by including a reference to a
1729 published, publicly available specification which includes the
1730 necessary information. IANA MAY reject DSN type registrations
1731 because of incomplete registration forms, imprecise specifications,
1732 or inappropriate type names.
1738Moore & Vaudreuil Standards Track [Page 31]
1740RFC 3464 Delivery Status Notifications January 2003
1743 To register a DSN type, complete the applicable form below and send
1744 it via Internet electronic mail to <IANA@IANA.ORG>.
1746IANA registration form for address-type
1748 A registration for a DSN address-type MUST include the following
1751 (a) The proposed address-type name.
1753 (b) The syntax for mailbox addresses of this type, specified using
1754 BNF, regular expressions, ASN.1, or other non-ambiguous language.
1756 (c) If addresses of this type are not composed entirely of graphic
1757 characters from the US-ASCII repertoire, a specification for how
1758 they are to be encoded as graphic US-ASCII characters in a DSN
1759 Original-Recipient or Final-Recipient DSN field.
1761 (d) [optional] A specification for how addresses of this type are to
1762 be translated to and from Internet electronic mail addresses.
1764IANA registration form for diagnostic-type
1766 A registration for a DSN address-type MUST include the following
1769 (a) The proposed diagnostic-type name.
1771 (b) A description of the syntax to be used for expressing diagnostic
1772 codes of this type as graphic characters from the US-ASCII
1775 (c) A list of valid diagnostic codes of this type and the meaning of
1778 (d) [optional] A specification for mapping from diagnostic codes of
1779 this type to DSN status codes (as defined in [5]).
1781IANA registration form for MTA-name-type
1783 A registration for a DSN MTA-name-type must include the following
1786 (a) The proposed MTA-name-type name.
1788 (b) A description of the syntax of MTA names of this type, using BNF,
1789 regular expressions, ASN.1, or other non-ambiguous language.
1794Moore & Vaudreuil Standards Track [Page 32]
1796RFC 3464 Delivery Status Notifications January 2003
1799 (c) If MTA names of this type do not consist entirely of graphic
1800 characters from the US-ASCII repertoire, a specification for how
1801 an MTA name of this type should be expressed as a sequence of
1802 graphic US-ASCII characters.
1804Appendix E - Examples
1806 These examples are provided as illustration only, and are not
1807 considered part of the DSN protocol specification. If an example
1808 conflicts with the protocol definition above, the example is wrong.
1810 Likewise, the use of *-type sub-field names or extension fields in
1811 these examples is not to be construed as a definition for those type
1812 names or extension fields.
1814 These examples were manually translated from bounced messages using
1815 whatever information was available.
1850Moore & Vaudreuil Standards Track [Page 33]
1852RFC 3464 Delivery Status Notifications January 2003
1857 This is a simple DSN issued after repeated attempts to deliver a
1858 message failed. In this case, the DSN is issued by the same MTA from
1859 which the message was originated.
1861 Date: Thu, 7 Jul 1994 17:16:05 -0400 From: Mail Delivery Subsystem
1862 <MAILER-DAEMON@CS.UTK.EDU> Message-Id:
1863 <199407072116.RAA14128@CS.UTK.EDU> Subject: Returned mail: Cannot
1864 send message for 5 days To: <owner-info-mime@cs.utk.edu> MIME-
1865 Version: 1.0 Content-Type: multipart/report; report-type=delivery-
1867 boundary="RAA14128.773615765/CS.UTK.EDU"
1869 --RAA14128.773615765/CS.UTK.EDU
1871 The original message was received at Sat, 2 Jul 1994 17:10:28 -0400
1874 ----- The following addresses had delivery problems -----
1875 <louisl@larry.slip.umd.edu> (unrecoverable error)
1877 ----- Transcript of session follows -----
1878 <louisl@larry.slip.umd.edu>... Deferred: Connection timed out
1879 with larry.slip.umd.edu.
1880 Message could not be delivered for 5 days
1881 Message will be deleted from queue
1883 --RAA14128.773615765/CS.UTK.EDU
1884 content-type: message/delivery-status
1886 Reporting-MTA: dns; cs.utk.edu
1888 Original-Recipient: rfc822;louisl@larry.slip.umd.edu
1889 Final-Recipient: rfc822;louisl@larry.slip.umd.edu
1892 Diagnostic-Code: smtp; 426 connection timed out
1893 Last-Attempt-Date: Thu, 7 Jul 1994 17:15:49 -0400
1895 --RAA14128.773615765/CS.UTK.EDU
1896 content-type: message/rfc822
1898 [original message goes here]
1900 --RAA14128.773615765/CS.UTK.EDU--
1906Moore & Vaudreuil Standards Track [Page 34]
1908RFC 3464 Delivery Status Notifications January 2003
1913 This is another DSN issued by the sender's MTA, which contains
1914 details of multiple delivery attempts. Some of these were detected
1915 locally, and others by a remote MTA.
1917 Date: Fri, 8 Jul 1994 09:21:47 -0400
1918 From: Mail Delivery Subsystem <MAILER-DAEMON@CS.UTK.EDU>
1919 Subject: Returned mail: User unknown
1920 To: <owner-ups-mib@CS.UTK.EDU>
1922 Content-Type: multipart/report; report-type=delivery-status;
1923 boundary="JAA13167.773673707/CS.UTK.EDU"
1925 --JAA13167.773673707/CS.UTK.EDU
1926 content-type: text/plain; charset=us-ascii
1928 ----- The following addresses had delivery problems -----
1929 <arathib@vnet.ibm.com> (unrecoverable error)
1930 <wsnell@sdcc13.ucsd.edu> (unrecoverable error)
1932 --JAA13167.773673707/CS.UTK.EDU
1933 content-type: message/delivery-status
1935 Reporting-MTA: dns; cs.utk.edu
1937 Original-Recipient: rfc822;arathib@vnet.ibm.com
1938 Final-Recipient: rfc822;arathib@vnet.ibm.com
1940 Status: 5.0.0 (permanent failure)
1941 Diagnostic-Code: smtp; 550 'arathib@vnet.IBM.COM' is not a
1942 registered gateway user
1943 Remote-MTA: dns; vnet.ibm.com
1945 Original-Recipient: rfc822;johnh@hpnjld.njd.hp.com
1946 Final-Recipient: rfc822;johnh@hpnjld.njd.hp.com
1948 Status: 4.0.0 (hpnjld.njd.jp.com: host name lookup failure)
1950 Original-Recipient: rfc822;wsnell@sdcc13.ucsd.edu
1951 Final-Recipient: rfc822;wsnell@sdcc13.ucsd.edu
1954 Diagnostic-Code: smtp; 550 user unknown
1955 Remote-MTA: dns; sdcc13.ucsd.edu
1957 --JAA13167.773673707/CS.UTK.EDU
1958 content-type: message/rfc822
1962Moore & Vaudreuil Standards Track [Page 35]
1964RFC 3464 Delivery Status Notifications January 2003
1967 [original message goes here]
1969 --JAA13167.773673707/CS.UTK.EDU--
1971DSN from gateway to foreign system
1973 A delivery report generated by Message Router (MAILBUS) and gatewayed
1974 by PMDF_MR to a DSN. In this case the gateway did not have
1975 sufficient information to supply an original-recipient address.
1977 Disclose-recipients: prohibited
1978 Date: Fri, 08 Jul 1994 09:21:25 -0400 (EDT)
1979 From: Message Router Submission Agent <AMMGR@corp.timeplex.com>
1980 Subject: Status of: Re: Battery current sense
1981 To: owner-ups-mib@CS.UTK.EDU
1982 Message-id: <01HEGJ0WNBY28Y95LN@mr.timeplex.com>
1984 content-type: multipart/report;
1985 report-type=delivery-status;
1986 boundary="84229080704991.122306.SYS30"
1988 --84229080704991.122306.SYS30
1989 content-type: text/plain
1991 Invalid address - nair_s
1992 %DIR-E-NODIRMTCH, No matching Directory Entry
1995 --84229080704991.122306.SYS30
1996 content-type: message/delivery-status
1998 Reporting-MTA: mailbus; SYS30
2000 Final-Recipient: unknown; nair_s
2001 Status: 5.0.0 (unknown permanent failure)
2004 --84229080704991.122306.SYS30--
2018Moore & Vaudreuil Standards Track [Page 36]
2020RFC 3464 Delivery Status Notifications January 2003
2025 A delay report from a multiprotocol MTA. Note that there is no
2026 returned content, so no third body part appears in the DSN.
2029 From: <postmaster@nsfnet-relay.ac.uk>
2030 Message-Id: <199407092338.TAA23293@CS.UTK.EDU>
2031 Received: from nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk
2032 id <g.12954-0@sun2.nsfnet-relay.ac.uk>;
2033 Sun, 10 Jul 1994 00:36:51 +0100
2034 To: owner-info-mime@cs.utk.edu
2035 Date: Sun, 10 Jul 1994 00:36:51 +0100
2036 Subject: WARNING: message delayed at "nsfnet-relay.ac.uk"
2037 content-type: multipart/report; report-type=delivery-status;
2041 content-type: text/plain
2043 The following message:
2045 UA-ID: Reliable PC (...
2046 Q-ID: sun2.nsf:77/msg.11820-0
2048 has not been delivered to the intended recipient:
2050 thomas@de-montfort.ac.uk
2052 despite repeated delivery attempts over the past 24 hours.
2054 The usual cause of this problem is that the remote system is
2055 temporarily unavailable.
2057 Delivery will continue to be attempted up to a total elapsed time of
2058 168 hours, i.e., 7 days.
2060 You will be informed if delivery proves to be impossible within this
2063 Please quote the Q-ID in any queries regarding this mail.
2066 content-type: message/delivery-status
2068 Reporting-MTA: dns; sun2.nsfnet-relay.ac.uk
2070 Final-Recipient: rfc822;thomas@de-montfort.ac.uk
2074Moore & Vaudreuil Standards Track [Page 37]
2076RFC 3464 Delivery Status Notifications January 2003
2079 Status: 4.0.0 (unknown temporary failure)
2084Appendix F - Changes from RFC 1894
2086 Changed Authors contact information
2088 Updated required standards boilerplate
2090 Edited the text to make it spell-checker and grammar checker
2093 Updated references to point to later, more mature documents, changed
2094 reference enumeration scheme.
2096 Fixed paragraph numbering on page 20
2098 Fixed Delayed DSN example
2100 Added Table of Contents
2102 Moved Appendices to the end of the document
2104 Changed the MTA-name-Type for gateways into Internet mail, the
2105 MTA-name-type from "SMTP" to "dns".
2130Moore & Vaudreuil Standards Track [Page 38]
2132RFC 3464 Delivery Status Notifications January 2003
2138 University of Tennessee
2139 1122 Volunteer Blvd, Suite 203
2140 Knoxville TN 37996-3450
2143 Phone: +1-865-974-3126
2144 Fax: +1-865-974-8296
2145 EMail: moore@cs.utk.edu
2148 Gregory M. Vaudreuil
2154 Phone: +1 214 823 9325
2155 EMail: GregV@ieee.org
2186Moore & Vaudreuil Standards Track [Page 39]
2188RFC 3464 Delivery Status Notifications January 2003
2191Full Copyright Statement
2193 Copyright (C) The Internet Society (2003). All Rights Reserved.
2195 This document and translations of it may be copied and furnished to
2196 others, and derivative works that comment on or otherwise explain it
2197 or assist in its implementation may be prepared, copied, published
2198 and distributed, in whole or in part, without restriction of any
2199 kind, provided that the above copyright notice and this paragraph are
2200 included on all such copies and derivative works. However, this
2201 document itself may not be modified in any way, such as by removing
2202 the copyright notice or references to the Internet Society or other
2203 Internet organizations, except as needed for the purpose of
2204 developing Internet standards in which case the procedures for
2205 copyrights defined in the Internet Standards process must be
2206 followed, or as required to translate it into languages other than
2209 The limited permissions granted above are perpetual and will not be
2210 revoked by the Internet Society or its successors or assigns.
2212 This document and the information contained herein is provided on an
2213 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
2214 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
2215 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
2216 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
2217 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2221 Funding for the RFC Editor function is currently provided by the
2242Moore & Vaudreuil Standards Track [Page 40]