Network Working Group Keith Moore
Internet Draft University of Tennessee
Expires: May 20, 1995 Greg Vaudreuil
Octel Network Services
November 20, 1994
An Extensible Message Format
for Delivery Status Notifications
draft-ietf-notary-mime-delivery-03.txt
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This memo defines a MIME content-type that may be used by a message
transfer agent (MTA) or mail gateway to report the result of an attempt
to deliver a message to one or more recipients. This content-type is
meant to be a machine-processable alternative to the full range of
electronic mail delivery status notifications currently in use in the
Internet.
1. Introduction
This memo defines a MIME [1] content-type for delivery status
notifications (DSNs). A DSN can be used to notify the sender of a
message of any of several conditions: failed delivery, delayed delivery,
successful delivery, or the gatewaying of a message into an environment
that may not support DSNs. The "message/delivery-status" content-type
defined herein is intended for use within the framework of the
"multipart/report" content type defined in [2].
This memo defines only the format of the notifications. An extension to
the Simple Message Transfer Protocol (SMTP) [3] to fully support such
notifications is the subject of a separate memo [4].
Moore/Vaudreuil Expires 20 May 1995 [Page 1]
Delivery Status Notifications 20 November 1994
Because many messages are sent between the MIME-capable world and other
messaging systems (such as X.400 or the so-called "LAN-based" systems),
the DSN protocol is intended to be useful in a multi-protocol messaging
environment. To this end, the DSN protocol provides for the carriage of
"foreign" addresses and error codes, in addition to the addresses and
error codes normally used in Internet mail. Additional attributes may
also be defined to support "tunneling" of foreign notifications through
MIME-capable systems using the DSN protocol.
2. Requirements
The DSNs defined in this memo are expected to serve several purposes:
+ Inform human beings of the status of message delivery processing, as
well as the reasons for any delivery problems or outright failures
+ Allow mail user agents to keep track of the delivery status of
messages sent
+ Allow mailing list expanders to automatically maintain their
subscriber lists when delivery attempts fail
+ Convey delivery and non-delivery notifications resulting from attempts
to deliver messages to "foreign" mail systems via a gateway
+ Allow "foreign" notifications to be tunneled through a MIME-capable
message system and back into the original messaging system that issued
the original notification, or even to a third messaging system; and
+ Provide sufficient information to remote MTA maintainers so that they
understand the nature of reported errors. This feature is used in the
case that failure to deliver a message is due to the malfunction of a
remote MTA and the sender wants to report the problem to the remote
MTA administrator.
These purposes place the following constraints on the notification
protocol:
+ It must be readable by humans as well as being machine-parsable.
+ It must provide enough information to allow message senders (or the
user agents) to unambiguously associate a DSN with the message that
was sent and the original recipient address for which the DSN is
issued (if such information is available), even if the message was
forwarded to another recipient address.
+ It must be able to preserve the information associated with a delivery
attempt in a remote messaging system, using the "language" (addresses
and status codes) of that remote system.
Moore/Vaudreuil Expires 20 May 1995 [Page 2]
Delivery Status Notifications 20 November 1994
+ For any notifications issued by foreign mail systems, which are
translated by a mail gateway to the DSN format, the DSN must preserve
the "type" of the original system, so that the "foreign" attributes
mentioned above may be correctly interpreted.
A DSN consists of a set of per-message fields to identify the message
and the transaction during which the message was submitted, along with
other fields that apply to all delivery attempts described by the DSN.
The DSN also includes a set of per-recipient fields to convey the result
of the attempt to deliver the message, to each of one or more
recipients.
A message that is either gatewayed between dissimilar messaging systems
or auto-forwarded to an alternate recipient address may have its sender
or recipient addresses changed during transit. For any particular
recipient, up to three different formats of an address are of interest:
"original" The recipient address as originally specified by the sender.
"final" The recipient address as it was when the message was
presented to the "final" MTA to handle the message for that
recipient (i.e., the one which is issuing the DSN).
"remote" If an attempt was made by the "final" MTA to relay the
message to yet another MTA, and a DSN is issued by the
"final" MTA based on the response of the "remote" (next-hop)
MTA, the address presented to the "remote" MTA, along with
the status code returned by that MTA, may also be of
interest.
Figure 1 may be useful in explaining the difference between the
"original", "final", and "remote" MTAs:
+-----+ +--------+ +-----------+ +-----+ +------+
| | => |Original| => ... => |penultimate| => |Final| ===> |Remote|
| user| | MTA | | MTA | | MTA | <No! | MTA |
|agent| +--------+ +-----------+ +--v--+ +------+
| | |
| | <-------------------------------------------+
+-----+ (DSN returned to sender by Final MTA)
Figure 1. Illustration of Original, Final, and Remote MTAs
In the diagram, the "original" MTA is the one which accepts the message
from the sender's user agent. The message successfully passes through
perhaps several other MTAs until it arrives at the "final" MTA, which
for some reason needs to issue a DSN. The DSN is returned to the
sender. (By definition, the MTA that issues a DSN is always the "final"
MTA.)
Moore/Vaudreuil Expires 20 May 1995 [Page 3]
Delivery Status Notifications 20 November 1994
If the "final" MTA is issuing the DSN based on information obtained from
some other MTA downstream (for example, because the downstream MTA
refused to accept responsibility for delivery of a message), then the
MTA which reported that information is the "remote" MTA. (If the
"final" MTA issues the DSN based on information obtained locally, as in
the case of delivery to a local user, there is no "remote" MTA.)
Each of these addresses is useful under some circumstances:
+ The DSN must contain the original recipient address (rather than a
forwarding address or some modified version of the original address),
so that the recipient address in the DSN can be compared with the
recipient address as specified by the sender when the original message
was sent.
+ The "final" form of the address is needed when reporting a problem to
the postmaster of the site where message delivery failed, so that she
can attempt to reproduce the conditions that caused the failure.
+ When interpreting a DSN, the sender's user agent will want the latest
possible (i.e. "remote") status code if it is available. However,
this code may either not be available, or it might be from a foreign
mail system whose codes are not understood by the sender's user agent.
In these cases the "final" code might be more useful.
+ When gatewaying a DSN into a foreign MTS, the gateway may use either
the "remote" or "final" status codes and recipient addresses,
depending on circumstances. Similarly, it may be appropriate to use
either the original or the current recipient address for any
particular recipient. This situation is described in more detail in
Appendix 13.
Since different values for "sender address", "recipient address", and
"delivery status code" are needed according to the circumstance in which
a DSN will be used, and since the MTA that issues the DSN cannot
anticipate those circumstances, the DSN format described here allows
each of several different forms of the sender address, recipient
address, and status code to be conveyed.
3. Format of a Delivery Status Notification
A complete DSN is a MIME message with a top-level content-type of
multipart/report (defined in [2]). For a DSN, the report-type parameter
of the multipart/report content is "delivery-status".
A particular DSN describes the delivery status for exactly one message.
However, an MTA MAY report on the delivery status for several recipients
of the same message in a single DSN. Due to the nature of the mail
transport system (where responsibility for delivery of a message to its
recipients may be split among several MTAs, and delivery to any
Moore/Vaudreuil Expires 20 May 1995 [Page 4]
Delivery Status Notifications 20 November 1994
particular recipient may be delayed), multiple DSNs may be still be
issued.
The DSN is addressed (in both the header and envelope) to the return
address from the envelope of the message for which the DSN is being
generated. The From header field of the DSN contains the address of a
human who is responsible for maintaining the mail system at the final
MTA site (e.g. Postmaster), while the envelope sender address of the
DSN is set up to ensure that no delivery status reports will be issued
in response to the DSN itself. (For example, in SMTP, the MAIL FROM
address should be an empty string.)
NOTE: For delivery status notifications gatewayed from foreign systems,
the headers of the original message may not be available. In this case
the third component of the DSN may be omitted, or it may contain
"simulated" RFC 822 headers which contain the same information. In
particular, it is very desirable to preserve the subject, date, and
message-id (or equivalent) fields from the original message.
The message/delivery-status content-type is defined as follows:
MIME type name: message
MIME subtype name: delivery-status
Optional parameters: none
Encoding considerations: "7bit" encoding is sufficient and
should be used to maintain
readability when viewed by non-MIME
mail readers.
Security considerations: discussed in section 6 of this memo.
The message/delivery-status report type for use in the multipart/report
is "delivery-status".
The body of a message/delivery-status consists of one or more "fields"
formatted according to the ABNF of RFC 822 header "fields" (see [5]).
The per-message fields appear first. Following the per-message fields
are one or more groups of per-recipient fields. Each group of per-
recipient fields is preceded by a blank line. Using the ABNF of RFC
822, the syntax of the message/delivery-status content is as follows:
delivery-status-content =
per-message-fields 1*( CRLF per-recipient-fields )
These fields are described in detail below. Note: Since these fields
are defined according to the rules of RFC 822, the same conventions for
continuation lines and comments apply. Notification fields may be
continued onto multiple lines by beginning each additional line with a
SPACE or TAB. Text which appears in parenthesis is considered a comment
and not part of the contents of that notification field. Field names
are case-insensitive, so the names of notification fields may be spelled
in any combination of upper and lower case letters. Comments in DSN
Moore/Vaudreuil Expires 20 May 1995 [Page 5]
Delivery Status Notifications 20 November 1994
fields may use the "encoded-word" construct defined in [6].
Several fields exist to identify the "MTS type" of the original, final,
or remote MTA. For the purpose of this specification, a "message
transfer system" (MTS) is a service which transfers electronic mail
messages from one user (the sender) to one or more users (recipients).
A particular MTS will have its own protocols for (a) electronic mail
addresses for senders and recipients, (b) names of MTAs, (c) the format
of electronic mail messages, (d) transferring messages and
responsibility for message delivery from one MTA to another, and (e)
communicating delivery status conditions.
An MTS-type is a identifier for a particular message transfer system. A
registry of MTS-types is maintained by the Internet Assigned Numbers
Authority (IANA). IANA will not register MTS-type names beginning with
"X-"; these are reserved for experimental use.
The syntax for an MTS-type is:
mts-type = atom
Because DSNs may be issued for messages that originated in foreign mail
systems, or gatewayed from delivery status reports that were issued in
foreign mail systems, many of the address and status codes fields may be
in some format other than that normally used in the Internet. The
various MTS-type fields are used to identify the mail system in which a
particular address or status code appeared. For example, if the final-
mts-type is X400, the final-recipient address must be an X.400 recipient
address, and the final-status code must be an X.400-style error code.
Like notification field names, MTS-type names are also case-insensitve.
A number of DSN fields are defined to have a field body consisting of
"xtext". Within such fields, the normal RFC 822 special characters are
not used. Portions of "xtext" enclosed in paraenthesis are treated as
comments, but such comments are not considered separators for the
purpose of lexical analysis. Except for comments and escaped-crlf's,
all characters are significant. RFC 1522 encoded-words may NOT be used
in xtext.
"xtext" is defined as follows:
xtext = *( xchar / hexchar / escaped-crlf )
xchar = any ASCII CHAR between SPACE (32) and TILDE (126)
inclusive, except for "#", "\" and "(".
"hexchar"s are intended to encode octets that cannot be represented as
plain text, either because they are reserved, or because they are non-
printable. However, any octet value may be represented by a "hexchar".
hexchar = ASCII "#" immediately followed by two upper case
Moore/Vaudreuil Expires 20 May 1995 [Page 6]
Delivery Status Notifications 20 November 1994
hexadecimal digits
An escaped-crlf may appear at the end of a line to allow the field to be
continued to the next line without inserting any white space.
escaped-crlf = "\" immediately followed by the characters: CR LF
SPACE
When encoding a field whose body is defined as "xtext", a SPACE which
immediately precedes a CR LF pair should be encoded either as a
"hexchar", or as an "escaped-crlf" followed by a SPACE.
When decoding a field whose body is defined as "xtext", any number of
SPACEs which immediately precede a CR LF pair (i.e. end of line) should
be ignored.
3.1 Per-Message DSN Fields
Some fields of a DSN apply to all of the delivery attempts described by
that DSN. These fields may appear at most once in any DSN. These
fields are used to correlate the DSN with the original message
transaction and to provide additional information which may be useful to
gateways.
With the exception of the original-mts-type field itself, the format of
each of the per-message fields is specific to the original-mts-type.
per-message-fields = [ original-mts-type-field CRLF ]
[ original-envelope-id-field CRLF ]
final-mts-type-field CRLF
final-mta-field CRLF
[ received-from-field CRLF ]
[ arrival-date-field CRLF ]
*( extension-field CRLF )
3.1.1 The Original-MTS-Type field
original-mts-type-field = "Original-MTS-Type" ":" MTS-type
The original-mts-type field contains the MTS-type name of the MTS in
which the message was submitted. This name MUST be an IANA-registered
MTS-type name, unless it begins with "X-".
This field is required if the original-envelope-id field or any
original-recipient field is present. If neither of these fields is
present, the original-mts-type field may be omitted.
3.1.2 The Original-Envelope-Id field
Moore/Vaudreuil Expires 20 May 1995 [Page 7]
Delivery Status Notifications 20 November 1994
The optional original-envelope-id field contains an "envelope
identifier" which uniquely identifies the transaction during which the
message was submitted, and was either (a) specified by the sender and
supplied to the sender's MTA, or (b) generated by the sender's MTA and
made available to the sender when the message was submitted. Its
purpose is to allow the sender (or her user agent) to associate the
returned DSN with the specific transaction in which the message was
sent.
The original-envelope-id line is defined as follows:
original-envelope-id-field = "Original-Envelope-Id" ":" envelope-id
envelope-id = xtext
There may be at most one original-envelope-id field per DSN. If an
original "envelope identifier" is not available when a DSN is issued,
the original-envelope-id DSN field MUST NOT be included in the DSN.
NOTE IN DRAFT: This last sentence may be a bit too strong. The intent
is to prevent an MTA from simply concocting an envelope-id for a
message. For the envelope-id field to be useful, it must be unique for
each message transmission, known by the sender of the original message
when the message was sent, and be transmitted along with the message
envelope. However, the MTA issuing the DSN has no way of knowing
whether the envelope-id it received in a message envelope is the same as
the "original" one known by the message sender. Some mail protocols
require an envelope-id or similar token, and a gateway into such an
environemnt will have to concoct one without the sender's knowledge. If
a DSN is issued for such a message, it will contain an envelope-id which
is not specified by the sender. In general this seems unavoidable.
The envelope-id is NOT case-insensitive. The DSN must preserve the
original case and spelling of the envelope-id.
NOTE: The original-envelope-id is NOT to be confused with the message-id
from the message header. The message-id identifies the content of the
message, while the original-envelope-id identifies the transaction in
which the message is sent.
3.1.3 The Final-MTS-Type DSN field
final-mts-type-field = "Final-MTS-Type" ":" MTS-type
The final-mts-type field contains the name of the MTS via which the
message arrived at the final MTA. The MTS-type MUST be registered with
IANA, unless it begins with "X-".
NOTE WELL: If the final MTA is actually a multi-protocol MTA or mail
gateway, the final-mts-type is the name of the MTS by which the message
Moore/Vaudreuil Expires 20 May 1995 [Page 8]
Delivery Status Notifications 20 November 1994
ARRIVED at that MTA.
The final-mts-type field is REQUIRED.
3.1.4 The Final-MTA DSN field
final-mta-field = "Final-MTA" ":" xtext
The final-mta field contains the name of the MTA which issued the DSN.
This field is REQUIRED.
This is not necessarily the MTA which reported the success or failure of
a delivery attempt. For example, if an SMTP client attempts to relay a
message to an SMTP server and receives an error reply to a RCPT command,
the client is responsible for generating the DSN, and the client's
domain name will appear in the final-mta field.
The contents of the final-mta field are formatted according to the
conventions of the "final" MTS, as indicated by the final-mts-type
field.
Because the exact spelling of an MTA name may be significant in a
particular environment, MTA names must be considered case-sensitive.
3.1.5 The Received-From DSN field
The optional Received-From field indicates the name of the MTA from
which the message was received. (In Figure 1, this MTA is labelled the
"penultimate" MTA.)
received-from-field = "Received-From" ":" xtext
If the message was received from an Internet host, the contents of the
Received-From field should be the Internet domain name corresponding to
the network address of that host. Otherwise, the contents of this field
may be any printable string identifying the MTA from which the message
was received.
The contents of the received-from field are formatted according to the
conventions of the "final" MTS, as indicated by the final-mts-type
field. Since case is significant in some mail systems, the exact
spelling, including case, of the MTA name should be preserved.
3.1.6 The Arrival-Date DSN field
The optional Arrival-Date field indicates the date and time at which the
message arrived at the final MTA. If the Date field is also provided in
a per-recipient field, this can be used to determine the interval
Moore/Vaudreuil Expires 20 May 1995 [Page 9]
Delivery Status Notifications 20 November 1994
between when the message arrived at the final MTA and when the report
was issued for that recipient.
arrival-date-field = "Arrival-Date" ":" date-time
The date and time are expressed in RFC 822 'date-time' format. Numeric
timezones ([+/-]HHMM format) MUST be used.
3.1.7 Extension fields
Additional per-message DSN fields may be defined in the future, if
necessary to tunnel MTS-specific delivery for a particular MTS-type or
by any extension to this memo which is published as an RFC.
extension-field = extension-field-name ":" xtext
extension-field-name = atom
3.2 Per-Recipient DSN fields
A DSN contains information about attempts to deliver a message to one or
more recipients. The delivery information for any particular recipient
is contained in a group of contiguous per-recipient fields.
The syntax for the group of per-recipient fields is as follows:
per-recipient-fields = basic-fields mts-specific-fields
basic-fields = recipient-field CRLF
action-field CRLF
status-field CRLF
[ date-field CRLF ]
[ final-log-id-field CRLF ]
[ expiry-date-field CRLF ]
mts-specific-fields = [ original-recipient-field CRLF ]
[ final-recipient-field CRLF ]
[ final-status-field CRLF ]
[ remote-mts-type-field CRLF ]
[ remote-mta-field CRLF ]
[ remote-recipient-field CRLF ]
[ remote-status-field CRLF ]
*( extension-field CRLF )
The "basic" fields are generic in nature and are always defined
according to Internet mail conventions. Except for the "date" field,
these fields are required for each recipient listed in a DSN. When mts-
specific fields are either not available or not usable (say, by a
gateway to a different environment), the "basic" fields provide fallback
Moore/Vaudreuil Expires 20 May 1995 [Page 10]
Delivery Status Notifications 20 November 1994
values with a known syntax.
The syntax of each mts-specific field is specific to the mts-type for
which that field applies. For example, the format of the final-
recipient, final-mta, and final-status fields are given by the final-
mts-type field.
This combined approach allows "foreign" information to be preserved in
DSNs for messages that are gatewayed in or out of the Internet, while
retaining a set of "canonical" information which will always be present,
and which can provide minimum functionality.
3.2.1 Basic per-recipient fields
3.2.1.1 Recipient field
The Recipient field indicates the recipient for which this set of per-
recipient fields applies. This field MUST be present in each set of
per-recipient data.
The syntax of the field is as follows:
recipient-field = "Recipient" ":" [route] addr-spec
The value following the Recipient field contains the RFC 822 mailbox of
the recipient address. The address MUST be in RFC 822 "addr-spec"
format (with an optional "route" prefix), and MUST contain the fully-
qualified domain name of the recipient's domain.
(EXCEPTION: If the DSN is being issued for this recipient, because of an
improperly formatted address or incomplete domain name, the recipient
DSN field may contain the illegal address or the address with the
incomplete domain name.)
NOTE IN DRAFT: There is a conflict here between having a "failed" DSN
report exactly the conditions that cause an error, or having a
rigorously formatted field that contains the failed address (even if the
problem is masked when the address is reformatted). To this author
(KM), the former goal seems more important. Delivery failure is often
caused by bad address rewriting, and the portion of an MTA that
generates a DSN can hardly be expected to be better at such rewriting
(while attempting to translate a foreign address into 822 syntax) than
the portion of the MTA that rewrites such addresses for the message
envelope. The best way to solve the address rewriting problem would
seem to be to make the source of the problem obvious via accurate error
reporting using DSNs.
NOTE: Although RFC 1123 [7] discourages explicit source routing in
SMTP, and allows SMTPs to route directly to the final domain, source
Moore/Vaudreuil Expires 20 May 1995 [Page 11]
Delivery Status Notifications 20 November 1994
routes are still allowed.
If the recipient address as originally specified is available in RFC 822
addr-spec format, the Recipient field should contain that address.
Otherwise, the Recipient field should contain the closest available
recipient address to that specified by the sender, as expressed in RFC
822 addr-spec format.
This address may not correspond to the address as originally sent
because it may have been transformed during forwarding and gatewaying
into an totally unrecognizable mess. In the absence of the optional
original-recipient field, the Recipient field and any returned content
may be all the information available to correlate the DSN with a
particular message transaction.
Although domain names are case-insensitive, the case of alphabetic
characters in the local-part of the addr-spec must be preserved.
3.2.1.2 action field
The action field indicates the reason the DSN was issued. This field
MUST be present for each recipient named in the DSN.
The syntax for the action-field is:
action-field = "Action" ":" action-value
action-value = "failed" / "delayed" / "delivered" / "relayed"
The action-value may be spelled in any combination of upper and lower
case characters.
"failed" indicates that the message could not be delivered to the
recipient. The final MTA has abandoned any attempts to
deliver the message to this recipient. No further
notifications should be expected.
"delayed" indicates that the final MTA has so far been unable to
deliver or relay the message, but it will continue to
attempt to do so. Additional notification messages may be
issued as the message is further delayed or successfully
delivered, or if delivery attempts are later abandoned.
"delivered" indicates that the message was successfully delivered to
the recipient address specified by the sender, which
includes "delivery" to a mailing list expander. It does
not indicate that the message has been read. This is a
terminal state and no further DSN for this recipient should
be expected.
Moore/Vaudreuil Expires 20 May 1995 [Page 12]
Delivery Status Notifications 20 November 1994
"relayed" indicates that the message has been relayed or gatewayed
into an environment that does not accept responsibility for
generating DSNs according to this specification.
Additional notification messages may be provided by the
"remote" environment that may or may not conform to this
specification. (However, for subsequent notifications, the
'original-recipient' field will almost certainly not be
included because it will no longer be available.)
NOTE ON ACTION VS. STATUS CODES: Although the 'action' field appears to
be redundant with the 'status' field, this is not the case. In
particular, a 4XX status value could be used with an action-value of
either "delayed" or "failed".
3.2.1.3 status field
The per-recipient status field contains a status code which indicates
the delivery status of the message to that recipient. This field MUST
be present for each delivery attempt which is described by a DSN.
The syntax of the status field is:
status-field = "Status" ":" status-code
status-code = 3*DIGIT
"status" uses the set of reply codes from SMTP [3] and its extensions
([8], [9]), with additions to support indication of error conditions
that can never result from an SMTP dialogue. If an SMTP reply code is
not available, the closest match should be chosen from either the set of
SMTP reply codes or the additional codes listed in an appendix.
Although status-codes are purely numeric, explanatory text may be
included as a comment in parentheses following the status-code.
NOTE: These "new" codes should only appear in delivery status
notifications. The creation of "new" status-codes for delivery status
notifications DOES NOT extend the legal set of reply codes to be used
with the SMTP protocol.
The structure of DSN status-codes is described in an appendix to this
memo.
3.2.1.4 date field
The "date" field gives the date and time of the last delivery attempt
(whether successful or unsuccessful) by the final MTA. Note that this
may not be the same as the date header field of the message used to
transmit this delivery status notification. In cases where the DSN was
Moore/Vaudreuil Expires 20 May 1995 [Page 13]
Delivery Status Notifications 20 November 1994
generated by a gateway, the RFC 822 header will contain the time the
message was sent and the DSN date field should be the time the
notification event occurred.
date-field = "Date" ":" date-time
This field is optional. It SHOULD NOT be included if the actual date
and time of the last delivery attempt are not available (which might be
the case if the DSN were being issued by a gateway).
The date and time are expressed in RFC 822 'date-time' format. Numeric
timezones ([+/-]HHMM format) MUST be used.
3.2.1.5 final-log-id field
The "final-log-id" field gives the final-log-id of the message that was
used by the final-mta. This can be useful as an index to the final-
mta's log entry for that delivery attempt.
final-log-id-field = "Final-Log-ID" ":" xtext
This field is optional.
3.2.1.6 expiry-date field
For DSNs of type "delay", the "expiry-date" field gives the date after
which the final MTA expects to abandon all attempts to deliver the
message to that recipient.
expiry-date-field = "Expiry-Date" ":" date-time
The date and time are expressed in RFC 822 'date-time' format. Numeric
timezones ([+/-]HHMM format) MUST be used.
3.2.2 MTS-specific Per-recipient fields
NOTE: Unless otherwise stated, the syntax for a MTS-specific Per-
recipient field is:
mts-specific-field = field-name ":" xtext
This reflects the ability to carry any kind of addresses, MTA names, or
status codes. A particular MTS-type may place restrictions on the
allowable values for MTS-specific fields when that MTS-type is used.
With the exception of MTS-type fields, all MTS-specific fields are case
sensitive. The final-MTA must not change the case of any values
reported in these fields.
Moore/Vaudreuil Expires 20 May 1995 [Page 14]
Delivery Status Notifications 20 November 1994
3.2.2.5 original-recipient field
The "original-recipient" field indicates the original recipient address
as specified by the sender of the message for which the DSN is being
issued.
If the message originated outside of the Internet, the original-
recipient field will not necessarily contain an RFC 822-style recipient
address. However, if the original-mts-type field is present, the
original-recipient address MUST conform to the conventions of the the
original-mts-type.
This field is optional. It should be included only if the sender-
specified recipient address was present in the message envelope, such as
by the ESMTP extensions defined in [4]. This address is the same as
that provided by the sender and can be used to automatically correlate
DSN reports and message transactions.
3.2.2.6 final-recipient field
The final-recipient field contains the electronic mail address of the
recipient at the time the message was accepted for delivery by the final
MTA. This field is optional.
If the final-mts-type field is present, the syntax of the final-
recipient field MUST conform to the syntax for that MTS-type.
3.2.2.7 final-status field
The value associated with the final-status DSN field should be a
printable ASCII representation of a MTS-specific status code that
indicates the final MTA's precise reason for the success or failure to
to this recipient. The possible values for this field are specific to
the final-mts-type.
This field is optional.
3.2.2.8 remote-mts-type field
The value associated with remote-mts-type DSN field is the MTS type of
the "remote" MTA, as defined in section 2 of this document.
This field is optional. It SHOULD NOT be included if no remote MTA was
involved in the attempted delivery of the message to that recipient.
3.2.2.9 remote-mta field
Moore/Vaudreuil Expires 20 May 1995 [Page 15]
Delivery Status Notifications 20 November 1994
The value associated with the remote-mta DSN field should be a printable
ASCII representation of the name of the "remote" MTA that reported
delivery status to the "final" MTA.
NOTE: The remote-mta field preserves the "while talking to" information
that was provided in some pre-existing non-delivery reports.
This field is optional. It SHOULD NOT be included if no remote MTA was
involved in the attempted delivery of the message to that recipient.
The conventions for the name of the remote-mta field are specific to the
remote MTS-type.
3.2.2.10 remote-recipient field
The value associated with the remote-recipient DSN field should be a
printable ASCII representation of the recipient address as presented to
the "remote" MTA in an attempt by the "final" MTA to relay the message.
The conventions of the remote-recipient address are specific to the
remote MTS-type.
This field is optional. It SHOULD NOT be included if its value is the
same as that of the final-recipient DSN field.
3.2.2.11 remote-status field
The value associated with the remote-status DSN field should be a
printable ASCII representation of the status value returned by the
remote MTA to the final MTA in response to the final MTA's attempt to
relay the message to the remote MTA.
The conventions for interpreting the remote-status DSN field are
specific to the remote MTS-type.
This field is optional, because some mail systems supply no additional
information beyond that which is returned in the 'action' and 'status'
fields.
3.2.2.12 Extension fields
Per-recipient extension fields may also be defined, using the same
syntax as for per-message extension field.
4. Extension Mechanism for DSNs
The DSN body part includes several extensible fields. The extensible
fields are:
Moore/Vaudreuil Expires 20 May 1995 [Page 16]
Delivery Status Notifications 20 November 1994
(a) New Status Codes
New status codes may be defined to reflect error conditions which are
not covered either by existing SMTP reply codes or by the additional
codes defined in section 10.1 of this memo. New codes must be
consistent with the theory of status codes defined in section 10, and
MUST be defined in a published RFC.
NOTE IN DRAFT: I (KM) am leaving this section as-is until the WG gets
consensus on whether to define a new status code scheme or extend the
existing SMTP scheme.
(b) New MTS types
New MTS-type names may be defined to allow the carriage of foreign
address and status code information in mts-specific DSN fields. New
MTS-types must be defined in a published RFC, which ideally should
include a complete specification for exchanging mail between the
Internet and the foreign MTS-type.
At a minimum, the definition of an additional MTS-type should include:
(1) the proposed MTS-type name
(2) the syntax of addresses for that MTS-type, as they are to be
represented in DSN fields
(3) the syntax of MTA names for that MTS-type
(4) the syntax of status codes for that MTS-type, along with a list of
the codes that are valid
NOTE: A definition for the INTERNET MTS-type appears in section 11 of
this memo.
(c) New DSN Fields
Additional per-message or per-recipient DSN fields may be defined by any
extension to this memo that is published as an RFC. These fields should
be used only to contain additional information needed to tunnel or
report information from foreign systems. In the event the DSN fields
defined in this memo are insufficient for reporting delivery attempts in
Internet mail, this specification as a whole should be revised.
Extension field names that are specific to a particular MTS-type should
begin with the MTS-type name and a hyphen. For example: a field called
"X400-Remote-MTA-Brain-Death" would be specific to the "X400" MTS-type.
Extension field names beginning with "X-" are reserved for experimental
use.
5. Conformance and Usage Requirements
Moore/Vaudreuil Expires 20 May 1995 [Page 17]
Delivery Status Notifications 20 November 1994
An MTA or gateway conforms to this specification if it generates DSNs
according to the protocol defined in this memo. For MTAs and gateways
that do not support requests for positive delivery notification (such as
in [4]), it is sufficient that delivery failure reports use this
protocol.
A minimal implementation of this specification will generate only the
Recipient, Action, and Status fields. However, generation of the other
fields is strongly recommended.
MTAs and gateways MUST NOT generate the "original-recipient" field of a
DSN unless the mail transfer protocol ensures that the address provided
is the one originally specified by the sender at the time of submission.
(Ordinary SMTP does not make that guarantee, but the SMTP extension
defined in [4] permits such information to be carried in the envelope if
it is available.)
Each sender-specified recipient address should result in at most one
"delivered" or "failed" DSN for that recipient. If a DSN is requested
for a message that is forwarded to multiple recipients, the forwarding
MTA should normally issue a "relayed" DSN for the originally-specified
recipient and not propagate the request for a DSN to the forwarding
addresses. Alternatively, the forwarding MTA can relay the request for
a DSN to exactly one of the forwarding addresses and not propagate the
request to the others.
Submission of a message to a mailing list exploder is considered final
delivery of the message. Upon delivery of a message to a recipient
address corresponding to a mailing list expander, the final MTA should
issue an appropriate DSN exactly as if the recipient address were that
of an ordinary mailbox.
NOTE: This is actually intended to make DSNs usable by mailing lists
themselves. Any message sent to a mailing list subscriber should have
its envelope return address pointing to the list maintainer [see RFC
1123, section 5.3.7(E)]. Since DSNs are sent to the envelope return
address, all DSNs resulting from delivery to the recipients of a mailing
list will be sent to the list maintainer. The list maintainer may elect
to mechanically process DSNs upon receipt, and thus automatically delete
invalid addresses from the list. (See Appendix 14.)
This specification places no restrictions on the processing of DSNs
received by user agents or distribution lists.
6. Security considerations
The following security considerations apply when using DSNs:
6.1 Forgery
Moore/Vaudreuil Expires 20 May 1995 [Page 18]
Delivery Status Notifications 20 November 1994
DSNs may be forged as easily as ordinary Internet electronic mail. User
agents and automatic mail handling facilities (such as mail distribution
list expanders) that wish to make automatic use of DSNs should take
appropriate precautions to minimize the potential damage from denial-of-
service attacks.
Security threats related to forged DSNs include the receipt of:
+ A falsified delivery notification when the message as not delivered,
+ A falsified non-delivery notification when the message was delivered,
+ A falsified final recipient address,
+ A falsified remote-mta identification,
+ A falsified relay notification when the message is "dead ended".
+ Unsolicited DSNs
6.2 Confidentality
Another dimension of security is confidentiality. There may be cases in
which a message recipient is autoforwarding messages but does not wish
to divulge the address to which the messaes are autoforwarded. The
desire for such confidentiality will probably be heightened as "wireless
mailboxes", such as pagers, become more widely used as autoforward
addresses.
MTA authors are encouraged to provide a mechanism which enables the end
user to preserve the confidentality of a forwarding address. Depending
on the degree of confidentiality required, and the nature of the
environment to which a message were being forwarded, this might be
accomplished by one or more of:
a) issuing a "relayed" DSN (if a positive DSN were requested) when a
message were forwarded to a confidential forwarding address, and
disabling requests for positive DSNs for the forwarded message,
b) omitting the "remote-*" fields of a DSN whenever they would otherwise
contain a confidential forwarding address,
c) for messages forwarded to a confidential address, setting the
envelope return address (e.g. SMTP MAIL FROM address) to the empty
string (so that no DSNs could be issued), or
d) when forwarding mail to a confidential address, having the forwarding
MTA rewrite the envelope return address for the forwarded message and
attempt delivery of that message as if it were the originator. After
obtaining final delivery status, it would issue a "proxy" DSN to the
original sender.
6.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
"failure" DSN can not be relied upon as a guarantee that a message was
Moore/Vaudreuil Expires 20 May 1995 [Page 19]
Delivery Status Notifications 20 November 1994
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. If one of those
delivery attempts succeeds and the other one fails, a "failure" DSN
could be issued even though the message actually reached the recipient.
7. Acknowledgments
The authors wish to thank the following people for their reviews of
earlier drafts of this document and their suggestions for improvement:
Harald Alvestrand, Allan Cargille, Jim Conklin, Ned Freed, John Klensin,
Mark Nahabedian, Jean Charles Roy, and Gregory Sheehan.
8. References
[1] Borenstein, N., Freed, N. "Multipurpose Internet Mail Extensions",
RFC 1521, Bellcore, Innosoft, September 1993.
[2] Moore, K., Vaudreuil, G. "Multipart/Report", Internet-Draft.
[3] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
USC/Information Sciences Institute, August 1982.
[4] Moore, K. "SMTP Service Extension for Delivery Status
Notifications", Internet-Draft.
[5] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, UDEL, August 1982.
[6] Moore, K. "MIME (Multipurpose Internet Mail Extensions) Part Two:
Message Header Extensions for Non-Ascii Text", RFC 1522, University
of Tennessee, September 1993.
[7] Braden, R. "Requirements for Internet Hosts - Application and
Support" RFC 1123, October 1989.
[8] Klensin, J., Freed, N., Rose, M., Stefferud, E., Crocker, D. "SMTP
Service Extensions" RFC 1651, MCI, Innosoft International, Inc.,
Dover Beach Consulting, Inc., Network Management Associates, Inc.,
Silicon Graphics, Inc, July 1994.
[9] Klensin, J., Freed, N., Moore, K. "SMTP Service Extension for
Message Size Declaration" RFC 1653, MCI, Innosoft International,
Moore/Vaudreuil Expires 20 May 1995 [Page 20]
Delivery Status Notifications 20 November 1994
Inc., University of Tennessee, July 1994.
9. Author's Addresses
Keith Moore
University of Tennessee
107 Ayres Hall
Knoxville, TN 37996-1301
USA
email: moore@cs.utk.edu
Gregory M. Vaudreuil
Octel Network Services
17080 Dallas Parkway
Dallas, TX 75248-1905
USA
email: Greg.Vaudreuil@Octel.Com
Moore/Vaudreuil Expires 20 May 1995 [Page 21]
Delivery Status Notifications 20 November 1994
10. Appendix - Theory of status-codes
The first digit of the status-code is defined as follows:
2yz Positive Completion status
Final delivery of the message has been successfully completed.
4yz Transient Negative Completion status
Attempts to deliver the message have been abandoned because of the
persistence of "transient" failures. However, the error condition
appears to be temporary and the sender may wish to resend the
message.
In SMTP, 4yz reply codes indicate conditions where the SMTP client
is allowed to "try again later" to deliver a message. However, if
delivery attempts continue to fail, eventually the client will
"give up". At this the client should issue a DSN. The last 4yz
reply code obtained from the SMTP server should be reported as the
status-code.
5yz Permanent Negative Completion status
The message could not be delivered because of some permanent error
associated with the recipient address. The sender should not
attempt to resend the message to that recipient.
6yz Indeterminate Completion status
This group of status codes is used when a message is relayed or
gatewayed into a mail system from which any requested DSNs may not
be returned. No further notifications should be expected for this
message and recipient. However, they may be issued, perhaps with
incomplete information.
The second digit of the status-code is defined as follows:
x0z Syntax
These replies refer to syntax errors, syntactically-correct
commands that don't fit any functional category, and unimplemented
or superfluous commands.
x2z Connections
These replies refer to the transmission channel.
x5z Mail system
These replies indicate the status of the receiver mail system vis-
Moore/Vaudreuil Expires 20 May 1995 [Page 22]
Delivery Status Notifications 20 November 1994
a-vis the requested transfer or other mail system action.
x6z External servers
These replies indicate the status of any external servers that are
not an integral part of the mail system but whose operation is
necessary for the correct delivery of mail.
The third digit of the status-code gives a finer gradation of meaning.
10.1 New status-codes for DSNs
In addition to the reply codes defined for SMTP, the following codes are
usable as status-codes in DSNs:
400 Unspecified temporary failure
This code is a "fallback" to be used when translating temporary
failure codes from foreign mail systems, when no more precise
status-code is available.
426 Temporary communications failure
This code indicates a "temporary" failure to establish
communications with a host or network for which communications is
necessary to deliver the message. Such failures would include
"host unreachable", "network unreachable", and "connection refused"
codes.
466 Temporary routing lookup failure
This code indicates a "temporary" failure to locate information
necessary to route a message. Such failures would include
unanswered Domain Name Server queries, or other queries of database
servers that are necessary to route a message.
500 Unspecified permanent failure
This code is a "fallback" to be used when translating permanent
failure codes from foreign mail systems when no better status-code
is available.
601 Message relayed; expect no further notifications
This code is issued for messages for which a positive DSN was
requested but which were successfully relayed or gatewayed into an
environment which does not support such notifications.
Moore/Vaudreuil Expires 20 May 1995 [Page 23]
Delivery Status Notifications 20 November 1994
11. Appendix - definition of the INTERNET MTS-type
The INTERNET MTS-type is hereby defined to refer to what is commonly
known as Internet mail. This includes all electronic mail systems which
(a) use the RFC 822 and/or MIME protocols for the message content, (b)
use RFC 822-style sender and recipient addresses in their envelopes,
with domains registered in the Internet domain name system (DNS)
(including domains registered under "wildcard" mail exchanger (MX)
records), and (c) exchange such messages with the IP-connected Internet.
The INTERNET MTS is not limited to those systems using SMTP.
MTS-type-name: INTERNET
Address-syntax: Addresses for the INTERNET MTS must be in the "addr-
spec" format defined in RFC 822 (with an optional "route" prefix), using
fully-qualified domain names which are registered with the DNS.
MTA-name-syntax: An INTERNET MTA-name shall be the fully-qualified
domain name of the MTA issuing the DSN. The address Postmaster@{mta-
name} must be a valid address by which the maintainer of that MTA may be
reached.
Status-codes: Status codes for the INTERNET MTS consist of three decimal
digits. The initial set of status codes consists of the the set of SMTP
reply codes (including those defined by SMTP extensions), along with the
additional codes defined in appendix 10 of this memo.
Moore/Vaudreuil Expires 20 May 1995 [Page 24]
Delivery Status Notifications 20 November 1994
12. Appendix - collected grammar
delivery-status-content =
per-message-fields *( CRLF per-recipient-fields )
per-message-fields = [ original-mts-type-field CRLF ]
[ original-envelope-id-field CRLF ]
[ final-mts-type-field CRLF ]
final-mta-field CRLF
[ received-from-field CRLF ]
[ arrival-date-field CRLF ]
*( extension-field CRLF )
original-mts-type-field = "Original-MTS-Type" ":" mts-type
original-envelope-id-field = "Original-Envelope-Id" ":" envelope-id
envelope-id = xtext
final-mts-type-field = "Final-MTS-Type" ":" mts-type
final-mta-field = "Final-MTA" ":" xtext
arrival-date-field = "Arrival-Date" ":" date-time
extension-field = extension-field-name ":" xtext
extension-field-name = atom
per-recipient-fields = basic-fields mts-specific-fields
basic-fields = recipient-field CRLF
action-field CRLF
status-field CRLF
[ date-field CRLF ]
[ final-log-id-field CRLF ]
[ expiry-date-field CRLF ]
mts-specific-fields = [ original-recipient-field CRLF ]
[ final-recipient-field CRLF ]
[ final-status-field CRLF ]
[ remote-mts-type-field CRLF ]
[ remote-mta-field CRLF ]
[ remote-recipient-field CRLF ]
[ remote-status-field CRLF ]
*( extension-field CRLF )
recipient-field = "Recipient" ":" [route] addr-spec
action-field = "Action" ":" action-value
Moore/Vaudreuil Expires 20 May 1995 [Page 25]
Delivery Status Notifications 20 November 1994
status-field = "Status" ":" status-code
date-field = "Date" ":" date-time
final-log-id-field = "Final-Log-ID" ":" xtext
expiry-date-field = "Expiry-Date" ":" date-time
original-recipient-field = "Original-Recipient" ":" xtext
final-recipient-field = "Final-Recipient" ":" xtext
final-status-field = "Final-Status" ":" xtext
remote-mts-type-field = "Remote-MTS-Type" ":" mts-type
remote-mta-field = "Remote-MTA" ":" xtext
remote-recipient-field = "Remote-Recipient" ":" xtext
remote-status-field = "Remote-Status" ":" xtext
action-value = "failed" / "delayed" / "delivered" / "relayed"
status-code = 3*DIGIT
mts-type = atom
; NOTE: For fields whose field-body is defined as 'xtext',
; the normal RFC 822 special characters are not used.
; text enclosed in paraenthesis is treated as a comment,
; but such comments are not considered separators for
; the purpose of lexical analysis. Except for comments
; and escaped-crlf's, all characters are significant.
; RFC 1522 encoded-words may NOT be used in xtext.
xtext = *( xchar / hexchar / escaped-crlf )
xchar = any ASCII CHAR between SPACE (32) and TILDE (126)
inclusive, except for "#", "\" and "(".
; "hexchar"s are used to encode octets that cannot be represented
; as plain text, either because they are reserved, or because
; they are non-printable.
hexchar = ASCII "#" immediately followed by two upper
case hexadecimal digits
; An escaped-crlf may appear at the end of a line to allow the
; field to be continued to the next line without inserting any
; white space.
Moore/Vaudreuil Expires 20 May 1995 [Page 26]
Delivery Status Notifications 20 November 1994
escaped-crlf = "\" immediately followed by the characters: CR LF SPACE
Moore/Vaudreuil Expires 20 May 1995 [Page 27]
Delivery Status Notifications 20 November 1994
13. 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.
13.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. The
information may be transmitted in the mts-specific fields of a DSN that
are defined in this memo, or if necessary, in extension fields.
The gateway MUST attempt to supply reasonable values for the per-
recipient 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 status from the foreign system. In this case, the gateway
should make a best effort, falling back on "generic" codes such as 200
(success), 400 (temporary failure), and 500 (permanent failure) when
necessary.
The sender-specified recipient address, if available, should be
preserved in the original-recipient field.
The gateway should also attempt to preserve the "final" recipient
addresses, mta names, and status codes from the foreign system. Because
DSN fields are limited to the ASCII character set, it may be necessary
to encode foreign protocol elements as printable ASCII values. The
encoding method is specific to the MTS-type from which the delivery
report is being received. "remote" values, when available, should be
similarly preserved.
If it is desirable to provide transparent tunneling of the foreign
delivery status notifications through Internet mail, the gateway
specification may define per-recipient extension fields to carry
additional mts-specific information as necessary.
13.2 Gatewaying from DSNs to other mail systems
A DSN may be gatewayed from the Internet to 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.
Moore/Vaudreuil Expires 20 May 1995 [Page 28]
Delivery Status Notifications 20 November 1994
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, and the latest
available delivery status code. Each of these must be in the original
sender's format.
If the original-recipient address is available, and the original-mts-
type matches the destination MTS, the original-recipient address should
be provided in the resulting foreign delivery status report. Otherwise,
the gateway may translate the "canonical" recipient address into the
convention required by the destination system. The final- or remote-
recipient addresses may also be used. However, due to address
translation and mail forwarding, these may have little or no resemblance
to the original recipient address.
If the remote-status code is available and the remote-mts-type matches
the MTS to which the DSN is being gatewayed, the remote-status code can
be used directly. Otherwise, if the final-mts-type matches the
destination MTS, the final-status code may be used. Failing that, the
"canonical" status-code may be mapped into the set of status codes used
by the destination MTS.
If it is possible to tunnel a DSN through the destination MTS, the
gateway specification may define a means of preserving the DSN
information in the delivery status reports used by the destination MTS.
Such encapsulation will necessarily be specific to that particular MTS.
Moore/Vaudreuil Expires 20 May 1995 [Page 29]
Delivery Status Notifications 20 November 1994
14. Appendix - Guidelines for use of DSNs by mailing list expanders
DSNs are designed to be used by mailing list expanders 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 expander
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 expander 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 one of the 'status'
codes and the 'action' field. Recipients with action values other than
"failed" can generally be ignored; in particular, subscribers should not
be removed from a list due to "delayed" DSNs. The latest possible
status code understood by the list expander should be used; the 'remote-
status' code is best, followed by the 'final-status' code (if the codes
for the final or remote MTS-type are understood by the list expander),
and finally the 'status' code.
In general, almost any failure status code (even a "permanent" one) can
result from a temporary condition. It is therefore recommended that a
list expander not delete a subscriber based on any single failed 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. When choosing
whether to delete a subscriber, it may be useful to differentiate
between the status codes. 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 persists for several days can usually be considered a
reliable that that address is no longer valid.
Moore/Vaudreuil Expires 20 May 1995 [Page 30]
Delivery Status Notifications 20 November 1994
Moore/Vaudreuil Expires 20 May 1995 [Page 31]
Delivery Status Notifications 20 November 1994
15. 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 MTS-type names or extension fields in these
examples is not to be construed as a definition for those MTS-types or
extension fields.
These examples were manually translated from bounced messages using
whatever information was available.
Moore/Vaudreuil Expires 20 May 1995 [Page 32]
Delivery Status Notifications 20 November 1994
15.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
Original-MTS-Type: INTERNET
Final-MTS-Type: INTERNET
Final-MTA: cs.utk.edu
Recipient: louisl@larry.slip.umd.edu
Action: failed
Status: 426 (connection timed out)
Date: Thu, 7 Jul 1994 17:15:49 -0400
Original-Recipient: louisl@larry.slip.umd.edu
--RAA14128.773615765/CS.UTK.EDU
content-type: message/rfc822
[original message goes here]
--RAA14128.773615765/CS.UTK.EDU--
Moore/Vaudreuil Expires 20 May 1995 [Page 33]
Delivery Status Notifications 20 November 1994
15.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
Original-MTS-Type: INTERNET
Final-MTA: cs.utk.edu
Final-MTS-Type: INTERNET
Recipient: arathib@vnet.ibm.com
Action: failed
Status: 550 ('arathib@vnet.IBM.COM' is not a registered gateway user)
Remote-MTS-Type: INTERNET
Remote-MTA: vnet.ibm.com
Original-Recipient: arathib@vnet.ibm.com
Recipient: johnh@hpnjld.njd.hp.com
Action: delayed
Status: 466 (hpnjld.njd.jp.com: host name lookup failure)
Original-Recipient: johnh@hpnjld.njd.hp.com
Recipient: wsnell@sdcc13.ucsd.edu
Action: failed
Status: 550 (user unknown)
Remote-MTS-Type: INTERNET
Remote-MTA: sdcc13.ucsd.edu
Original-Recipient: wsnell@sdcc13.ucsd.edu
--JAA13167.773673707/CS.UTK.EDU
content-type: message/rfc822
[original message goes here]
--JAA13167.773673707/CS.UTK.EDU--
Moore/Vaudreuil Expires 20 May 1995 [Page 34]
Delivery Status Notifications 20 November 1994
Moore/Vaudreuil Expires 20 May 1995 [Page 35]
Delivery Status Notifications 20 November 1994
15.3 A delivery report generated by Message Router (MAILBUS) and
gatewayed by PMDF_MR to a DSN. I assume that PMDF_MR could have
preserved the MAILBUS status code in the DSN (NOTE IN DRAFT: right
Ned?), I just don't know what it would be.
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
Final-MTA: SYS30
Final-MTS-Type: mailbus
Recipient: nair_s@SYS30.timeplex.com
Status: 500 (unknown failure)
Action: failed
Final-Recipient: nair_s
Final-Status: ??? (no matching directory entry found)
--[;84229080704991/122306@SYS30]--
Moore/Vaudreuil Expires 20 May 1995 [Page 36]
Delivery Status Notifications 20 November 1994
15.4 A delay report from a multiprotocol MTA. Note that there is no
returned content; so no third body part 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
Final-MTS-Type: INTERNET
Final-MTA: sun2.nsfnet-relay.ac.uk
Recipient: thomas@de-montfort.ac.uk
Status: 400 (unknown temporary failure)
Action: delayed
--foobar--
Moore/Vaudreuil Expires 20 May 1995 [Page 37]
Delivery Status Notifications 20 November 1994
15.5 A DSN gatewayed from a X.400 nondelivery notification
From: "UK.AC.NSF MTA" <postmaster@nsfnet-relay.ac.uk>
To: na-digest-bounces@netlib2.cs.utk.edu
Subject: Delivery Report (failure) for sdz009@prime.napier.ac.uk
Date: Mon, 11 Jul 1994 02:09:43 +0100
Message-ID: <"sun3.nsfne.309:11.06.94.01.09.27"@nsfnet-relay.ac.uk>
content-type: multipart/report; report-type=delivery-status;
boundary=foobar
--foobar
content-type: text/plain
This report relates to your message: Subject: NA Digest, V. 94, # 27,
Message-ID: <199407031824.OAA23971@localhost>,
To: na-digest list:;
of Sun, 3 Jul 1994 19:47:56 +0100
Your message was not delivered to sdz009@prime.napier.ac.uk
for the following reason:
Message timed out
--foobar
content-type: message/delivery-status
Final-MTS-Type: X400
Final-MTA: sun3.nsfnet-relay.ac.uk in /PRMD=uk.ac/ADMD= /C=gb/
Recipient: sdz009@prime.napier.ac.uk
Action: failed
Status: 400 (unknown temporary failure)
Final-Recipient: /S=sdz009/OU=prime/O=napier/PRMD=UK.AC/ADMD= /C=GB/
Final-Status: 1/5 (unable-to-transfer/maximum-time-expired)
X400-Subject-Intermediate-Trace-Information: /PRMD=uk.ac/ADMD= /C=gb/
arrival Sun, 3 Jul 1994 19:47:56 +0100 action Relayed
X400-Subject-Intermediate-Trace-Information: /PRMD=uk.ac/ADMD= /C=gb/
arrival Sun, 3 Jul 1994 19:24:03 +0100 action Relayed
--foobar
content-type: message/rfc822
[returned content]
--foobar--
Moore/Vaudreuil Expires 20 May 1995 [Page 38]
Delivery Status Notifications 20 November 1994
16. Appendix - changes since the July 14 draft
1. Title and order of paragraphs in section 3 changed to describe the
overall structure of the message before the description of the
message/delivery-status content-type.
2. Some text added to section 3 to explicitly state that comments and
continuation lines are allowed in the same manner as in RFC 822.
3. Some fields are now explicitly marked as case-sensitive or
case-insensitive.
4. "Rcpt" is now spelled "Recipient" in notification fields, and the
"INET" MTS-Type is now "INTERNET".
5. "X-" MTS-types are now allowed.
6. Received-From field added.
7. Section 3.2.1.2: added example to show how action and status-codes
work, contrasting conversion-with-loss with conversion-prohibited.
8. Changed 'xchar' grammar to disallow the characters "(", "#", and
"\"; added "#"XX notation for hexadecimal encoding; added "\" CR LF
SPACE notation to allow transparent continuation of lines.
9. Section 3.2.1.3: clarified "MUST be present for each recipient" ->
"MUST be present for each delivery attempt...".
10. Section 3.2.2.6: deleted the text which said that the
final-recipient field shouldn't appear if it is redundant with either
original-recipient or recipient.
11. Section 3.2.2.11: fixed incomplete sentence.
12. Section 5: added note about the use of DSNs by mailing lists.
13. Appendix 10: removed description of x1z status-codes; these are
useful in SMTP (e.g. HELP command) but are not applicable to delivery
status reports.
15. Added text to clarify the difference between original, final, and
remote MTAs.
15. Add text to suggest that subject, date, and message-id be retained
in the third (returned content) body part of a DSN.
16. Added some prose to (sort-of) define "MTS".
17. Added Arrival-date per-message field.
Moore/Vaudreuil Expires 20 May 1995 [Page 39]
Delivery Status Notifications 20 November 1994
18. Added Expiry-date per-recipient field.
19. Added more prose to say that (a) a single DSN can describe
delivery status for multiple recipients of the same message, but (b)
the delivery status for all recipients of the same message doesn't
have to be in a single DSN, and (c) a single DSN cannot describe
delivery events for multiple messages.
20. Expanded the security considerations section.
21. Explicitly allow the first body part of a DSN to be a
multipart/alternative.
22. Add a note to the effect that comments may be used in the
status-code field.
23. Added an appendix about use of DSNs by mailing lists.
24. Renumbered references.
25. Added prose in the acknowledgements section. (Please let me know
if I've left anybody out! -km)
26. Explicitly allow encoded-words in comments.
27. Allow an optional "route" to appear in the 'recipient' field,
and in {final,remote}-recipient fields of the "internet" mts-type.
28. Fix a few troff glitches.
STILL TO DO
1. Change "original-xxx" to "earliest-xxx" (if I can find the
right words...)
2. Figure out and describe how to treat DSNs which result from
multi-recipient mail forwarding. Intentions: (a) make the result
unambiguous and meaningful to the sender, (b) uniform handling -
don't make handing of "delivered" DSNs too different from
"relayed/delayed/failed" DSNs.
Moore/Vaudreuil Expires 20 May 1995 [Page 40]
