(rather than to the one in the envelope), in violation of SMTP and
other protocols. If a message is forwarded through such an MTA, no
reasonable action on the part of the forwarding MTA will prevent the
downstream MTA from compromising the forwarding address. Likewise,
if the recipient's MTA automatically responds to messages based on a
request in the message header (such as the nonstandard, but widely
used, Return-Receipt-To extension header), it will also compromise
the forwarding address.
4.3 Non-Repudiation
Within the framework of today's internet mail, the DSNs defined in
this memo provide valuable information to the mail user; however,
even a "failed" DSN can not be relied upon as a guarantee that a
message was not received by the recipient. Even if DSNs are not
actively forged, conditions exist under which a message can be
delivered despite the fact that a failure DSN was issued.
For example, a race condition in the SMTP protocol allows for the
duplication of messages if the connection is dropped following a
completed DATA command, but before a response is seen by the SMTP
client. This will cause the SMTP client to retransmit the message,
even though the SMTP server has already accepted it.[9] If one of
those delivery attempts succeeds and the other one fails, a "failed"
DSN could be issued even though the message actually reached the
recipient.
5. Appendix - collected grammar
NOTE: The following lexical tokens are defined in RFC822: atom,
CHAR, comment, CR, CRLF, DIGIT, LF, linear-white-space, SPACE, text.
The date-time lexical token is defined in [8].
action-field = "Action" ":" action-value
action-value =
"failed" / "delayed" / "delivered" / "relayed" / "expanded"
address-type = atom
arrival-date-field = "Arrival-Date" ":" date-time
delivery-status-content =
per-message-fields 1*( CRLF per-recipient-fields )
diagnostic-code-field =
"Diagnostic-Code" ":" diagnostic-type ";" *text
diagnostic-type = atom
dsn-gateway-field = "DSN-Gateway" ":" mta-name-type ";" mta-name
envelope-id = *text
extension-field = extension-field-name ":" *text
extension-field-name = atom
final-recipient-field =
"Final-Recipient" ":" address-type ";" generic-address
generic-address = *text
last-attempt-date-field = "Last-Attempt-Date" ":" date-time
mta-name = *text
mta-name-type = atom
original-envelope-id-field =
"Original-Envelope-Id" ":" envelope-id
original-recipient-field =
"Original-Recipient" ":" address-type ";" generic-address
per-message-fields =
[ original-envelope-id-field CRLF ]
reporting-mta-field CRLF
[ dsn-gateway-field CRLF ]
[ received-from-mta-field CRLF ]
[ arrival-date-field CRLF ]
*( extension-field CRLF )
per-recipient-fields =
[ original-recipient-field CRLF ]
final-recipient-field CRLF
action-field CRLF
status-field CRLF
[ remote-mta-field CRLF ]
[ diagnostic-code-field CRLF ]
[ last-attempt-date-field CRLF ]
[ will-retry-until-field CRLF ]
*( extension-field CRLF )
received-from-mta-field =
"Received-From-MTA" ":" mta-name-type ";" mta-name
remote-mta-field = "Remote-MTA" ":" mta-name-type ";" mta-name
reporting-mta-field =
"Reporting-MTA" ":" mta-name-type ";" mta-name
status-code = DIGIT "." 1*3DIGIT "." 1*3DIGIT
; White-space characters and comments are NOT allowed within a
; status-code, though a comment enclosed in parentheses MAY follow
; the last numeric subfield of the status-code. Each numeric
; subfield within the status-code MUST be expressed without
; leading zero digits.
status-field = "Status" ":" status-code
will-retry-until-field = "Will-Retry-Until" ":" date-time
6. Appendix - Guidelines for gatewaying DSNs
NOTE: This section provides non-binding recommendations for the
construction of mail gateways that wish to provide semi-transparent
delivery reports between the Internet and another electronic mail
system. Specific DSN gateway requirements for a particular pair of
mail systems may be defined by other documents.
6.1 Gatewaying from other mail systems to DSNs
A mail gateway may issue a DSN to convey the contents of a "foreign"
delivery or non-delivery notification over Internet mail. When there
are appropriate mappings from the foreign notification elements to
DSN fields, the information may be transmitted in those DSN fields.
Additional information (such as might be useful in a trouble ticket
or needed to tunnel the foreign notification through the Internet)
may be defined in extension DSN fields. (Such fields should be given
names that identify the foreign mail protocol, e.g. X400-* for X.400
NDN or DN protocol elements)
The gateway must attempt to supply reasonable values for the
Reporting-MTA, Final-Recipient, Action, and Status fields. These
will normally be obtained by translating the values from the remote
delivery or non-delivery notification into their Internet-style
equivalents. However, some loss of information is to be expected.
For example, the set of status-codes defined for DSNs may not be
adequate to fully convey the delivery diagnostic code from the
foreign system. The gateway should assign the most precise code
which describes the failure condition, falling back on "generic"
codes such as 2.0.0 (success), 4.0.0 (temporary failure), and 5.0.0
(permanent failure) when necessary. The actual foreign diagnostic
code should be retained in the Diagnostic-Code field (with an
appropriate diagnostic-type value) for use in trouble tickets or
tunneling.
The sender-specified recipient address, and the original envelope-id,
if present in the foreign transport envelope, should be preserved in
the Original-Recipient and Original-Envelope-ID fields.
The gateway should also attempt to preserve the "final" recipient
addresses and MTA names from the foreign system. Whenever possible,
foreign protocol elements should be encoded as meaningful printable
ASCII strings.
For DSNs produced from foreign delivery or nondelivery notifications,
the name of the gateway MUST appear in the DSN-Gateway field of the
DSN.
6.2 Gatewaying from DSNs to other mail systems
It may be possible to gateway DSNs from the Internet into a foreign
mail system. The primary purpose of such gatewaying is to convey
delivery status information in a form that is usable by the
destination system. A secondary purpose is to allow "tunneling" of
DSNs through foreign mail systems, in case the DSN may be gatewayed
back into the Internet.
In general, the recipient of the DSN (i.e., the sender of the
original message) will want to know, for each recipient: the closest
available approximation to the original recipient address, the
delivery status (success, failure, or temporary failure), and for
failed deliveries, a diagnostic code that describes the reason for
the failure.
If possible, the gateway should attempt to preserve the Original-
Recipient address and Original-Envelope-ID (if present), in the
resulting foreign delivery status report.
When reporting delivery failures, if the diagnostic-type subfield of
the Diagnostic-Code field indicates that the original diagnostic code
is understood by the destination environment, the information from
the Diagnostic-Code field should be used. Failing that, the
information in the Status field should be mapped into the closest
available diagnostic code used in the destination environment.
If it is possible to tunnel a DSN through the destination
environment, the gateway specification may define a means of
preserving the DSN information in the delivery status reports used by
that environment.
7. Appendix - Guidelines for use of DSNs by mailing list exploders
NOTE: This section pertains only to the use of DSNs by "mailing
lists" as defined in [4], section 7.2.7.
DSNs are designed to be used by mailing list exploders to allow them
to detect and automatically delete recipients for whom mail delivery
fails repeatedly.
When forwarding a message to list subscribers, the mailing list
exploder should always set the envelope return address (e.g. SMTP
MAIL FROM address) to point to a special address which is set up to
received nondelivery reports. A "smart" mailing list exploder can
therefore intercept such nondelivery reports, and if they are in the
DSN format, automatically examine them to determine for which
recipients a message delivery failed or was delayed.
The Original-Recipient field should be used if available, since it
should exactly match the subscriber address known to the list. If
the Original-Recipient field is not available, the recipient field
may resemble the list subscriber address. Often, however, the list
subscriber will have forwarded his mail to a different address, or
the address may be subject to some re-writing, so heuristics may be
required to successfully match an address from the recipient field.
Care is needed in this case to minimize the possibility of false
matches.
The reason for delivery failure can be obtained from the Status and
Action fields, and from the Diagnostic-Code field (if the status-type
is recognized). Reports for recipients with action values other than
"failed" can generally be ignored; in particular, subscribers should
not be removed from a list due to "delayed" reports.
In general, almost any failure status code (even a "permanent" one)
can result from a temporary condition. It is therefore recommended
that a list exploder not delete a subscriber based on any single
failure DSN (regardless of the status code), but only on the
persistence of delivery failure over a period of time.
However, some kinds of failures are less likely than others to have
been caused by temporary conditions, and some kinds of failures are
more likely to be noticed and corrected quickly than others. Once
more precise status codes are defined, it may be useful to
differentiate between the status codes when deciding whether to
delete a subscriber. For example, on a list with a high message
volume, it might be desirable to temporarily suspend delivery to a
recipient address which causes repeated "temporary" failures, rather
than simply deleting the recipient. The duration of the suspension
might depend on the type of error. On the other hand, a "user
unknown" error which persisted for several days could be considered a
reliable indication that address were no longer valid.
8. Appendix - IANA registration forms for DSN types
The forms below are for use when registering a new address-type,
diagnostic-type, or MTA-name-type with the Internet Assigned Numbers
Authority (IANA). Each piece of information requested by a
registration form may be satisfied either by providing the
information on the form itself, or by including a reference to a
published, publicly available specification which includes the
necessary information. IANA MAY reject DSN type registrations
because of incomplete registration forms, imprecise specifications,
or inappropriate type names.
To register a DSN type, complete the applicable form below and send
it via Internet electronic mail to <IANA@IANA.ORG>.
8.1 IANA registration form for address-type
A registration for a DSN address-type MUST include the following
information:
(a) The proposed address-type name.
(b) The syntax for mailbox addresses of this type, specified using BNF,
regular expressions, ASN.1, or other non-ambiguous language.
(c) If addresses of this type are not composed entirely of graphic
characters from the US-ASCII repertoire, a specification for how
they are to be encoded as graphic US-ASCII characters in a DSN
Original-Recipient or Final-Recipient DSN field.
(d) [optional] A specification for how addresses of this type are to be
translated to and from Internet electronic mail addresses.
8.2 IANA registration form for diagnostic-type
A registration for a DSN address-type MUST include the following
information:
(a) The proposed diagnostic-type name.
(b) A description of the syntax to be used for expressing diagnostic
codes of this type as graphic characters from the US-ASCII
repertoire.
(c) A list of valid diagnostic codes of this type and the meaning of
each code.
(d) [optional] A specification for mapping from diagnostic codes of this
type to DSN status codes (as defined in [5]).
8.3 IANA registration form for MTA-name-type
A registration for a DSN MTA-name-type must include the following
information:
(a) The proposed MTA-name-type name.
(b) A description of the syntax of MTA names of this type, using BNF,
regular expressions, ASN.1, or other non-ambiguous language.
(c) If MTA names of this type do not consist entirely of graphic
characters from the US-ASCII repertoire, a specification for how an
MTA name of this type should be expressed as a sequence of graphic
US-ASCII characters.
9. Appendix - Examples
NOTE: These examples are provided as illustration only, and are not
considered part of the DSN protocol specification. If an example
conflicts with the protocol definition above, the example is wrong.
Likewise, the use of *-type subfield names or extension fields in
these examples is not to be construed as a definition for those type
names or extension fields.
These examples were manually translated from bounced messages using
whatever information was available.
9.1 This is a simple DSN issued after repeated attempts
to deliver a message failed. In this case, the DSN is
issued by the same MTA from which the message was originated.
Date: Thu, 7 Jul 1994 17:16:05 -0400
From: Mail Delivery Subsystem <MAILER-DAEMON@CS.UTK.EDU>
Message-Id: <199407072116.RAA14128@CS.UTK.EDU>
Subject: Returned mail: Cannot send message for 5 days
To: <owner-info-mime@cs.utk.edu>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary="RAA14128.773615765/CS.UTK.EDU"
--RAA14128.773615765/CS.UTK.EDU
The original message was received at Sat, 2 Jul 1994 17:10:28 -0400
from root@localhost
----- The following addresses had delivery problems -----
<louisl@larry.slip.umd.edu> (unrecoverable error)
----- Transcript of session follows -----
<louisl@larry.slip.umd.edu>... Deferred: Connection timed out
with larry.slip.umd.edu.
Message could not be delivered for 5 days
Message will be deleted from queue
--RAA14128.773615765/CS.UTK.EDU
content-type: message/delivery-status
Reporting-MTA: dns; cs.utk.edu
Original-Recipient: rfc822;louisl@larry.slip.umd.edu
Final-Recipient: rfc822;louisl@larry.slip.umd.edu
Action: failed
Status: 4.0.0
Diagnostic-Code: smtp; 426 connection timed out
Last-Attempt-Date: Thu, 7 Jul 1994 17:15:49 -0400
--RAA14128.773615765/CS.UTK.EDU
content-type: message/rfc822
[original message goes here]
--RAA14128.773615765/CS.UTK.EDU--
9.2 This is another DSN issued by the sender's MTA, which
contains details of multiple delivery attempts. Some of
these were detected locally, and others by a remote MTA.
Date: Fri, 8 Jul 1994 09:21:47 -0400
From: Mail Delivery Subsystem <MAILER-DAEMON@CS.UTK.EDU>
Subject: Returned mail: User unknown
To: <owner-ups-mib@CS.UTK.EDU>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary="JAA13167.773673707/CS.UTK.EDU"
--JAA13167.773673707/CS.UTK.EDU
content-type: text/plain; charset=us-ascii
----- The following addresses had delivery problems -----
<arathib@vnet.ibm.com> (unrecoverable error)
<wsnell@sdcc13.ucsd.edu> (unrecoverable error)
--JAA13167.773673707/CS.UTK.EDU
content-type: message/delivery-status
Reporting-MTA: dns; cs.utk.edu
Original-Recipient: rfc822;arathib@vnet.ibm.com
Final-Recipient: rfc822;arathib@vnet.ibm.com
Action: failed
Status: 5.0.0 (permanent failure)
Diagnostic-Code: smtp;
550 'arathib@vnet.IBM.COM' is not a registered gateway user
Remote-MTA: dns; vnet.ibm.com
Original-Recipient: rfc822;johnh@hpnjld.njd.hp.com
Final-Recipient: rfc822;johnh@hpnjld.njd.hp.com
Action: delayed
Status: 4.0.0 (hpnjld.njd.jp.com: host name lookup failure)
Original-Recipient: rfc822;wsnell@sdcc13.ucsd.edu
Final-Recipient: rfc822;wsnell@sdcc13.ucsd.edu
Action: failed
Status: 5.0.0
Diagnostic-Code: smtp; 550 user unknown
Remote-MTA: dns; sdcc13.ucsd.edu
--JAA13167.773673707/CS.UTK.EDU
content-type: message/rfc822
[original message goes here]
--JAA13167.773673707/CS.UTK.EDU--
9.3 A delivery report generated by Message Router (MAILBUS) and
gatewayed by PMDF_MR to a DSN. In this case the gateway did not
have sufficient information to supply an original-recipient address.
Disclose-recipients: prohibited
Date: Fri, 08 Jul 1994 09:21:25 -0400 (EDT)
From: Message Router Submission Agent <AMMGR@corp.timeplex.com>
Subject: Status of : Re: Battery current sense
To: owner-ups-mib@CS.UTK.EDU
Message-id: <01HEGJ0WNBY28Y95LN@mr.timeplex.com>
MIME-version: 1.0
content-type: multipart/report; report-type=delivery-status;
boundary="84229080704991.122306.SYS30"
--84229080704991.122306.SYS30
content-type: text/plain
Invalid address - nair_s
%DIR-E-NODIRMTCH, No matching Directory Entry found
--84229080704991.122306.SYS30
content-type: message/delivery-status
Reporting-MTA: mailbus; SYS30
Final-Recipient: unknown; nair_s
Status: 5.0.0 (unknown permanent failure)
Action: failed
--84229080704991.122306.SYS30--
9.4 A delay report from a multiprotocol MTA. Note that there is no
returned content, so no third body part appears in the DSN.
From: <postmaster@nsfnet-relay.ac.uk>
Message-Id: <199407092338.TAA23293@CS.UTK.EDU>
Received: from nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk
id <g.12954-0@sun2.nsfnet-relay.ac.uk>;
Sun, 10 Jul 1994 00:36:51 +0100
To: owner-info-mime@cs.utk.edu
Date: Sun, 10 Jul 1994 00:36:51 +0100
Subject: WARNING: message delayed at "nsfnet-relay.ac.uk"
content-type: multipart/report; report-type=delivery-status;
boundary=foobar
--foobar
content-type: text/plain
The following message:
UA-ID: Reliable PC (...
Q-ID: sun2.nsf:77/msg.11820-0
has not been delivered to the intended recipient:
thomas@de-montfort.ac.uk
despite repeated delivery attempts over the past 24 hours.
The usual cause of this problem is that the remote system is
temporarily unavailable.
Delivery will continue to be attempted up to a total elapsed
time of 168 hours, ie 7 days.
You will be informed if delivery proves to be impossible
within this time.
Please quote the Q-ID in any queries regarding this mail.
--foobar
content-type: message/delivery-status
Reporting-MTA: dns; sun2.nsfnet-relay.ac.uk
Final-Recipient: rfc822;thomas@de-montfort.ac.uk
Status: 4.0.0 (unknown temporary failure)
Action: delayed
--foobar--
10. Acknowledgments
The authors wish to thank the following people for their reviews of
earlier drafts of this document and their suggestions for
improvement: Eric Allman, Harald Alvestrand, Allan Cargille, Jim
Conklin, Peter Cowen, Dave Crocker, Roger Fajman, Ned Freed, Marko
Kaittola, Steve Kille, John Klensin, John Gardiner Myers, Mark
Nahabedian, Julian Onions, Jacob Palme, Jean Charles Roy, and Gregory
Sheehan.
11. References
[1] Borenstein, N., Freed, N. "Multipurpose Internet Mail Extensions",
RFC1521, Bellcore, Innosoft, September 1993.
[2] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting
of Mail System Administrative Messages", RFC1892, Octal Network
Services, January 1996.
[3] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC821,
USC/Information Sciences Institute, August 1982.
[4] Moore, K., "SMTP Service Extension for Delivery Status
Notifications", RFC1891, University of Tennessee, January 1996.
[5] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC1893, Octal
Network Services, January 1996.
[6] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC822, UDEL, August 1982.
[7] Moore, K. "MIME (Multipurpose Internet Mail Extensions) Part Two:
Message Header Extensions for Non-Ascii Text", RFC1522, University
of Tennessee, September 1993.
[8] Braden, R. (ed.) "Requirements for Internet Hosts - Application and
Support", STD 3, RFC1123, USC/Information Sciences Institute,
October 1989.
[9] Partridge, C., "Duplicate Messages and SMTP", RFC1047, BBN,
February 1988.
11. Authors' Addresses
Keith Moore
University of Tennessee
107 Ayres Hall
Knoxville, TN 37996-1301
USA
EMail: moore@cs.utk.edu
Phone: +1 615 974 3126
Fax: +1 615 974 8296
Gregory M. Vaudreuil
Octel Network Services
17080 Dallas Parkway
Dallas, TX 75248-1905
USA