view Side-By-Side changes
An Extensible Message Format
for Delivery Status Notifications
draft-ietf-notary-mime-delivery-02.txt
draft-ietf-notary-mime-delivery-03.txt
Status of this Memo
This document is an Internet Draft. Internet Drafts Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, areas, and
its Working Groups. working groups. Note that other groups may also distribute working
documents as Internet Drafts.
Internet Drafts 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 Internet-Drafts as reference material
or to cite them other than as a "work ``work in progress". 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 inter-network 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 [8]. [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 [5]. [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
Moore/Vaudreuil Expires 14 January 1995 [Page 1]
Delivery Status Notifications 14 July 1994
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 a message delivery, 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 a remote MTA maintainer maintainers so that she
understands 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 administrator.
These purposes place the following constraints on the notification
protocol:
+ It must be readable by humans as well as being machine-parsable machine-parsable.
+ It must provide enough information to allow the sender of a message senders (or his the
user agent) 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 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 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.
Moore/Vaudreuil Expires 14 January 1995 [Page 2]
Delivery Status Notifications 14 July 1994
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.
Each of these addresses is
Figure 1 may be useful under some circumstances. The original
recipient address is needed 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 sender to be able
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
associate issue a DSN. The DSN with is returned to the recipient specified in
sender. (By definition, the MTA that issues a DSN is always the message. The "final" form of
MTA.)
Moore/Vaudreuil Expires 20 May 1995 [Page 3]
Delivery Status Notifications 20 November 1994
If the address "final" MTA is needed when reporting a problem 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
remote postmaster. When interpreting a DSN, message), then the sender's user agent
will want
MTA which reported that information is the "remote" status code if it is available. Either MTA. (If the
"final" form or MTA issues the "remote" form of an address may be useful to a
gateway which must translate a MIME DSN into the format required by a
foreign mail system.
3. message/delivery-status Content-type
The message/delivery-status content-type is defined based on information obtained locally, 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".
Moore/Vaudreuil Expires 14 January 1995 [Page 3]
Delivery Status Notifications 14 July 1994
A complete DSN is a MIME message with a top-level content-type case of
multipart/report. The DSN is addressed (in both the header and
envelope) delivery to the return address from the envelope a local user, there is no "remote" MTA.)
Each of the message for
which the DSN these addresses is being generated. useful under some circumstances:
+ The From header field of the DSN
contains must contain the original recipient address of (rather than a human who is responsible for maintaining the
mail system at the final MTA site (e.g. Postmaster), while the envelope
sender
forwarding address or some modified version of the DSN is set up to ensure original address),
so that no delivery status
reports will be issued the recipient address in response to the DSN itself. (For example, in
SMTP, can be compared with the MAIL FROM
recipient address should be an empty string.) as specified by the sender when the original message
was sent.
+ The first component "final" form of the multipart/report should be address is needed when reporting a human- readable
text problem to
the postmaster of the site where message delivery failed, so that summarizes, in prose, she
can attempt to reproduce the delivery status information conditions that is presented in detail in caused the message/delivery-status component.
The second component of failure.
+ When interpreting a DSN, the multipart/report must be sender's user agent will want the
message/delivery-status content described in section 3 of latest
possible (i.e. "remote") status code if it is available. However,
this memo.
The third and final component of the multipart/report should contain code may either the entire message as received not be available, or it might be from a foreign
mail system whose codes are not understood by the final MTA or, if at all
possible, sender's user agent.
In these cases the headers of that message.
NOTE: For delivery status notifications gatewayed from "final" code might be more useful.
+ When gatewaying a DSN into a foreign systems, MTS, the headers of gateway may use either
the original message "remote" or "final" status codes and recipient addresses,
depending on circumstances. Similarly, it may not be available. In this case
the third component of appropriate to use
either the DSN should be omitted.
The body of a message/delivery-status consists of one original or the current recipient address for any
particular recipient. This situation is described in more "fields"
formatted detail in
Appendix 13.
Since different values for "sender address", "recipient address", and
"delivery status code" are needed according to the ABNF of RFC 822 header "fields". The per-
message fields appear first. Following circumstance in which
a DSN will be used, and since the per-message fields are one
or more groups MTA that issues the DSN cannot
anticipate those circumstances, the DSN format described here allows
each of per-recipient fields. Each group several different forms of per-recipient
fields the sender address, recipient
address, and status code to be conveyed.
3. Format of a Delivery Status Notification
A complete DSN is preceded by a blank line. Using MIME message with a top-level content-type of
multipart/report (defined in [2]). For a DSN, the ABNF of RFC 822, the
syntax report-type parameter
of the message/delivery-status multipart/report content is as follows:
delivery-status-content =
per-message-fields *( CRLF per-recipient-fields )
These fields are described in detail below.
Several fields exist to identify the "MTS type" of the original, final,
or remote MTA. An MTS-type is a identifier for a "delivery-status".
A particular mail system
which is registered with DSN describes the Internet Assigned Numbers Authority (IANA).
The syntax delivery status for exactly one message.
However, an MTS-type is:
mts-type = atom
Because DSNs may be issued for messages that originated in foreign mail
systems, or gatewayed from MTA MAY report on the delivery status reports that were issued in
foreign mail systems, many for several recipients
of the address and status codes fields may be
in some format other than that normally used same message in the Internet. The
various MTS-type fields are used a single DSN. Due to identify the nature of the mail
transport system in which (where responsibility for delivery of a
particular address or status code appeared. For example, if the final-
mts-type is X400, the final-rcpt address must message to its
recipients may be an X.400 recipient
address, split among several MTAs, and the final-status code must be an X.400-style error code. delivery to any
Moore/Vaudreuil Expires 14 January 20 May 1995 [Page 4]
Delivery Status Notifications 14 July 20 November 1994
3.1 Per-Message DSN Fields
Some fields of a DSN apply to all of the delivery attempts described by
that DSN. These fields
particular recipient may appear at most once in any DSN. These
fields are used to correlate the be delayed), multiple DSNs may be still be
issued.
The DSN with is addressed (in both the original message
transaction header and envelope) to provide additional information which may be useful to
gateways.
With the exception return
address from the envelope of the original-mts-type field itself, the format of
each of message for which the per-message fields DSN 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 ]
*( extension-field CRLF )
3.1.1. The original-mts-type field
original-mts-type-field = "Original-MTS-Type" ":" MTS-type being
generated. The original-mts-type From header 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.
This field is optional.
3.1.2 The original-envelope-id field
The optional original-envelope-id field DSN 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 address of a
human who is responsible for maintaining the sender's MTA, or (b) generated by mail system at the sender's final
MTA and
made available to site (e.g. Postmaster), while the envelope sender when address of the message was submitted. Its
purpose
DSN is set up to allow the sender (or her user agent) ensure that no delivery status reports will be issued
in response to associate the
returned DSN with the specific transaction itself. (For example, in which 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 was
sent. There may not be at most one original-envelope-id field per DSN. 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 original-envelope-id line message/delivery-status content-type is defined as follows:
original-envelope-id-field = "Original-Envelope-Id" ":" envelope-id
envelope-id = xtext
If an original "envelope identifier" is not available when a DSN
MIME type name: message
MIME subtype name: delivery-status
Optional parameters: none
Encoding considerations: "7bit" encoding is
issued, the original-envelope-id DSN field MUST NOT sufficient and
should be included used to maintain
readability when viewed by non-MIME
mail readers.
Security considerations: discussed in the
DSN.
Moore/Vaudreuil Expires 14 January 1995 [Page 5]
Delivery Status Notifications 14 July 1994
NOTE: section 6 of this memo.
The original-envelope-id message/delivery-status report type for use in the multipart/report
is NOT "delivery-status".
The body of a message/delivery-status consists of one or more "fields"
formatted according to be confused with the message-id
from the message header. ABNF of RFC 822 header "fields" (see [5]).
The message-id identifies per-message fields appear first. Following the content 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
message, while the original-envelope-id identifies ABNF of RFC
822, the transaction in
which syntax of the message message/delivery-status content is sent.
3.1.3. The final-mts-type DSN field
final-mts-type-field as follows:
delivery-status-content = "Final-MTS-Type" ":" MTS-type
The final-mta-type field contains
per-message-fields 1*( CRLF per-recipient-fields )
These fields are described in detail below. Note: Since these fields
are defined according to the name rules of RFC 822, the MTS via which the
message arrived at the final MTA. The MTS-type must same conventions for
continuation lines and comments apply. Notification fields may be registered
continued onto multiple lines by beginning each additional line with
IANA.
NOTE WELL: If the final MTA is actually a multi-protocol MTA
SPACE or mail
gateway, the final-mts-type TAB. Text which appears in parenthesis is the name considered a comment
and not part of the MTS by which the message
ARRIVED at contents of that MTA.
3.1.4. The final-mta DSN field
final-mta-field = "Final-MTA" ":" xtext
The final-mta field contains notification field. Field names
are case-insensitive, so the name 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 MTA which issued the DSN.
This is not necessarily "encoded-word" construct defined in [6].
Several fields exist to identify the MTA which reported "MTS type" of the success original, final,
or failure remote MTA. For the purpose of this specification, a delivery attempt. For example, if an SMTP client attempts to relay "message
transfer system" (MTS) is a
message to an SMTP server and receives an error reply service which transfers electronic mail
messages from one user (the sender) to a RCPT command,
the client is responsible one or more users (recipients).
A particular MTS will have its own protocols for generating the DSN, (a) electronic mail
addresses for senders and the client's
domain name will appear in the final-mta field.
The contents recipients, (b) names of MTAs, (c) the final-mta field are formatted according to the
conventions format
of the "final" MTS, as indicated by the final-mts-type field
3.1.5. Extension fields
Additional per-message DSN fields may be defined in the future, if
necessary electronic mail messages, (d) transferring messages and
responsibility for message delivery from one MTA to tunnel MTS-specific another, and (e)
communicating delivery status conditions.
An MTS-type is a identifier for a particular MTS-type or
by any extension to this memo which message transfer system. A
registry of MTS-types is published as 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 RFC.
extension-field = extension-field-name ":" xtext
extension-field-name MTS-type is:
mts-type = atom
3.2 Per-Recipient DSN fields
A DSN contains information about attempts to deliver a message to one
Because DSNs may be issued for messages that originated in foreign mail
systems, or
more recipients. The gatewayed from delivery information for any particular recipient
is contained status reports that were issued in a group
foreign mail systems, many of contiguous per-recipient fields.
Moore/Vaudreuil Expires 14 January 1995 [Page 6]
Delivery Status Notifications 14 July 1994
The syntax for the group of per-recipient address and status codes fields is as follows:
per-recipient-fields = basic-fields mts-specific-fields
basic-fields = rcpt-field CRLF
action-field CRLF
status-field CRLF
[ date-field CRLF ]
[ final-log-id-field CRLF ]
mts-specific-fields = [ original-rcpt-field CRLF ]
[ final-rcpt-field CRLF ]
[ final-status-field CRLF ]
[ remote-mts-type-field CRLF ]
[ remote-mta-field CRLF ]
[ remote-rcpt-field CRLF ]
[ remote-status-field CRLF ]
*( extension-field CRLF ) may be
in some format other than that normally used in the Internet. The "basic"
various MTS-type fields are generic in nature and are always defined
according used to Internet mail conventions. Except for identify the "date" field,
these fields are required for each recipient listed mail system in which a DSN. When mts-
specific fields are either not available
particular address or not usable (say, by a
gateway to a different environment), the "basic" fields provide fallback
values with a known syntax.
The syntax of each mts-specific field is specific to the mts-type for
which that field applies. status code appeared. For example, if the format of final-
mts-type is X400, the final-rcpt,
final-mta, 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 given by the final-mts-type
field.
This combined approach allows "foreign" information defined to be preserved in
DSNs for messages that are gatewayed in or out of the Internet, while
retaining have 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 Rcpt field
The Rcpt field indicates body consisting of
"xtext". Within such fields, the recipient 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 which this set the
purpose of per-
recipient fields applies. This field MUST lexical analysis. Except for comments and escaped-crlf's,
all characters are significant. RFC 1522 encoded-words may NOT be present used
in each set of
per-recipient data.
The syntax of the field xtext.
"xtext" is defined as follows:
rcpt-field
xtext = "Rcpt" ":" addr-spec *( 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 14 January 20 May 1995 [Page 7] 6]
Delivery Status Notifications 14 July 20 November 1994
The value following the Rcpt field contains
hexadecimal digits
An escaped-crlf may appear at the RFC 822 mailbox end of a line to allow the
recipient address. The address MUST field to be in RFC 822 "addr-spec" format,
and MUST contain the fully-qualified domain name of the recipient's
domain.
If the recipient address as originally specified is available in RFC 822
addr-spec format,
continued to the Rcpt field should contain that address.
Otherwise, next line without inserting any white space.
escaped-crlf = "\" immediately followed by the Rcpt characters: CR LF
SPACE
When encoding a field whose body is defined as "xtext", a SPACE which
immediately precedes a CR LF pair should contain the closest available recipient
address to that specified 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 sender.
This address delivery attempts described by
that DSN. These fields may not correspond appear at most once in any DSN. These
fields are used to correlate the address as originally sent
because it may have been transformed during forwarding DSN with the original message
transaction and gatewaying
into an totally unrecognizable mess. In to provide additional information which may be useful to
gateways.
With the absence exception of the optional
original-rcpt field, the Rcpt original-mts-type field and any returned content may be all itself, the information available format of
each of the per-message fields is specific to correlate the DSN with a particular message
transaction.
3.2.1.2 action 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 action original-mts-type field indicates contains the reason MTS-type name of the DSN MTS in
which the message was issued. submitted. This field name MUST be present for each recipient.
The syntax for an IANA-registered
MTS-type name, unless it begins with "X-".
This field is required if the action-field is:
action-field = "Action" ":" action-value
action-value = "failed" / "delayed" / "delivered" / "relayed"
The action-value may be spelled in original-envelope-id field or any combination
original-recipient field is present. If neither of upper and lower
case characters.
"failed" indicates that these fields is
present, the message could not original-mts-type field may be delivered to the
recipient. omitted.
3.1.2 The final MTA has abandoned any attempts to
deliver the message to this recipient. No further
notifications should be expected.
"delayed" indicates that 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 final MTA has so far been unable transaction during which the
message was submitted, and was either (a) specified by the sender and
supplied to
deliver the sender's MTA, or relay (b) generated by the message, but it will continue to
attempt sender's MTA and
made available 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 sender when the message was successfully delivered submitted. Its
purpose is to allow the recipient address specified by sender (or her user agent) to associate the sender,
returned DSN with the specific transaction in which
includes "delivery" to a mailing list expander. It does
not indicate that the message has been read. This 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
terminal state and no further DSN for this recipient should is issued,
the original-envelope-id DSN field MUST NOT be expected.
"relayed" indicates that included in the message has been relayed or gatewayed
Moore/Vaudreuil Expires 14 January 1995 [Page 8]
Delivery Status Notifications 14 July 1994
into DSN.
NOTE IN DRAFT: This last sentence may be a bit too strong. The intent
is to prevent an environment that does not accept responsibility MTA from simply concocting an envelope-id for
generating DSNs according a
message. For the envelope-id field to this specification. Additional
notification messages may be provided useful, it must be unique for
each message transmission, known by the "remote"
environment that may or may not conform to this
specification. (However, for subsequent notifications, sender of the
'original-rcpt' field will not be included.)
NOTE: Although original message
when the 'action' field appears to message was sent, and be redundant transmitted along with the
'status' field, this is not message
envelope. However, 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 MTA issuing the delivery status DSN has no way of knowing
whether the envelope-id it received in a message to that recipient. This field MUST
be present for each recipient.
The syntax of envelope is the status field is:
status-field = "Status" ":" status-code
status-code = 3*DIGIT
"status" uses same as
the set of reply codes from SMTP "original" one known by the message sender. Some mail protocols
require an envelope-id or similar token, and its extensions, with
additions to support indication of error conditions that can never
result from a gateway into such an SMTP dialogue.
environemnt will have to concoct one without the sender's knowledge. If
a DSN is issued for such a message, it will contain an SMTP reply code envelope-id which
is not available, specified by the closest match should be chosen from either sender. In general this seems unavoidable.
The envelope-id is NOT case-insensitive. The DSN must preserve the set
original case and spelling of SMTP reply
codes or the additional codes listed in an appendix. envelope-id.
NOTE: These "new" codes should only appear in delivery status
notifications. The creation of "new" status-codes for delivery status
notifications DOES original-envelope-id is NOT extend the legal set of reply codes to be used confused with the SMTP protocol.
The structure message-id
from the message header. The message-id identifies the content of DSN status-codes is described the
message, while the original-envelope-id identifies the transaction in an appendix to this
memo.
3.2.1.4 date
which the message is sent.
3.1.3 The Final-MTS-Type DSN field
final-mts-type-field = "Final-MTS-Type" ":" MTS-type
The "date" final-mts-type field gives contains the date and time name of the last delivery attempt
(whether successful or unsuccessful) by MTS via which the
message arrived at the final MTA. Note that this
may not The MTS-type MUST be registered with
IANA, unless it begins with "X-".
NOTE WELL: If the same as the date header field of the message used to
transmit this delivery status notification. In cases where the DSN was
generated by final MTA is actually a multi-protocol MTA or mail
gateway, the RFC 822 header will contain the time the
message was sent and final-mts-type is the DSN date field should be name of the time MTS by which the
notification event occurred.
date-field = "Date" ":" date-time message
Moore/Vaudreuil Expires 14 January 20 May 1995 [Page 9] 8]
Delivery Status Notifications 14 July 20 November 1994
This
ARRIVED at that MTA.
The final-mts-type 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). REQUIRED.
3.1.4 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 Final-MTA DSN field
final-mta-field = "Final-MTA" ":" xtext
The "final-log-id" final-mta field gives contains the final-log-id name of the message that was
used by the final-mta. This can be useful as an index to MTA which issued the final-
mta's log entry for that delivery attempt.
final-log-id-field = "Final-Log-ID" ":" xtext DSN.
This field is optional.
3.2.2 MTS-specific Per-recipient fields
NOTE: Unless otherwise stated, REQUIRED.
This is not necessarily the syntax for MTA which reported the success or failure of
a MTS-specific Per-
recipient field is:
mts-specific-field = field-name ":" xtext
This reflects 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 ability 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 carry any kind the
conventions of addresses, MTA names, or
status codes, as long the "final" MTS, as they can indicated by the final-mts-type
field.
Because the exact spelling of an MTA name may be represented as printable ASCII
characters. A significant in a
particular MTS-type may place restrictions on the
allowable values for MTS-specific fields when that MTS-type is used.
3.2.2.5 original-rcpt environment, MTA names must be considered case-sensitive.
3.1.5 The Received-From DSN field
The "original-rcpt" optional Received-From field indicates the original recipient address as
specified by the sender name of the message for MTA from
which the DSN message was received. (In Figure 1, this MTA is being
issued. labelled the
"penultimate" MTA.)
received-from-field = "Received-From" ":" xtext
If the message originated outside of the Internet, the original-rcpt
field will not necessarily contain was received from an RFC 822-style recipient address.
However, if Internet host, the original-mts-type contents of the
Received-From field is present, should be the original-rcpt
address MUST conform Internet domain name corresponding to
the conventions network address of that host. Otherwise, the the original-mts-type.
This contents of this field is optional. It should
may be included only if any printable string identifying the sender-
specified recipient address was present in MTA from which the message envelope, such as
by
was received.
The contents of the ESMTP extensions defined in [5]. This address is received-from field are formatted according to the same
conventions of the "final" MTS, as
that provided indicated by the sender and can final-mts-type
field. Since case is significant in some mail systems, the exact
spelling, including case, of the MTA name should be used to automatically correlate preserved.
3.1.6 The Arrival-Date DSN reports and message transactions.
Moore/Vaudreuil Expires 14 January 1995 [Page 10]
Delivery Status Notifications 14 July 1994
3.2.2.6 final-rcpt field
The final-rcpt optional Arrival-Date field contains the electronic mail address of the
recipient at indicates the date and time at which the
message was accepted for delivery by arrived at the final MTA. This field is optional. If the final-mts-type Date field is present, also provided in
a per-recipient field, this can be used to determine the syntax of interval
Moore/Vaudreuil Expires 20 May 1995 [Page 9]
Delivery Status Notifications 20 November 1994
between when the final-rcpt
field MUST conform to message arrived at the syntax final MTA and when the report
was issued for that MTS-type. recipient.
arrival-date-field = "Arrival-Date" ":" date-time
The final-rcpt field SHOULD NOT date and time are expressed in RFC 822 'date-time' format. Numeric
timezones ([+/-]HHMM format) MUST be included if either (a) used.
3.1.7 Extension fields
Additional per-message DSN fields may be defined in the 'original-
rcpt' field is present future, if
necessary to tunnel MTS-specific delivery for a particular MTS-type or
by any extension to this recipient and its value memo which is the same published as
the final-rcpt value, 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 (b) the value specified
more recipients. The delivery information for any particular recipient
is contained in a group of contiguous per-recipient fields.
The syntax for the 'rcpt' field group of per-recipient fields is
the same as the final-rcpt value.
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. 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 possible values "basic" fields are generic in nature and are always defined
according to Internet mail conventions. Except for this field 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 final-mts-type.
This field is optional.
3.2.2.8 remote-mts-type field
The value associated "basic" fields provide fallback
Moore/Vaudreuil Expires 20 May 1995 [Page 10]
Delivery Status Notifications 20 November 1994
values with remote-mts-type DSN a known syntax.
The syntax of each mts-specific field is specific to the MTS type of
the "remote" MTA, that is, the one mts-type for
which that reported field applies. For example, the result format of the
delivery attempt to the "final" MTA which issued final-
recipient, final-mta, and final-status fields are given by the DSN. final-
mts-type field.
This field is optional. It SHOULD NOT combined approach allows "foreign" information to be included preserved in a DSN if the final
MTA had ultimate responsibility
DSNs for delivery messages that are gatewayed in or out of the message.
3.2.2.9 remote-mta field
The value associated with the remote-mta DSN field should be Internet, while
retaining a printable
ASCII representation set of the "remote" MTA that reported delivery status
to the "final" MTA.
NOTE: "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 remote-mta Recipient field preserves indicates the "while talking to" information
that was provided in some pre-existing non-delivery reports. recipient for which this set of per-
recipient fields applies. This field is optional. It SHOULD NOT MUST be included present in the DSN fields for
a recipient unless the final MTA had ultimate responsibility for the
delivery each set of the message to that recipient.
per-recipient data.
The conventions for the name syntax of the remote-mta field are specific to the
remote MTS-type.
Moore/Vaudreuil Expires 14 January 1995 [Page 11]
Delivery Status Notifications 14 July 1994
3.2.2.10 remote-rcpt field is as follows:
recipient-field = "Recipient" ":" [route] addr-spec
The value associated with following the remote-rcpt DSN Recipient field should be a
printable ASCII representation contains the RFC 822 mailbox of
the recipient address. The address as presented to
the "remote" MTA MUST be in RFC 822 "addr-spec"
format (with an attempt by the "final" MTA to relay optional "route" prefix), and MUST contain the message.
The conventions fully-
qualified domain name of the remote-rcpt address are specific to recipient's domain.
(EXCEPTION: If the remote
MTS-type.
This field is optional. It SHOULD NOT be included if its value DSN is the
same as that being issued for this recipient, because of an
improperly formatted address or incomplete domain name, the final-rcpt recipient
DSN field.
3.2.2.11 remote-status field
The value associated may contain the illegal address or the address with the remote-status
incomplete domain name.)
NOTE IN DRAFT: There is a conflict here between having a "failed" DSN field should be
report exactly the conditions that cause an error, or having a
printable ASCII representation of
rigorously formatted field that contains the status value returned by failed address (even if the
remote MTA to
problem is masked when the final 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 in response that
generates a DSN can hardly be expected to the final MTA's attempt be better at such rewriting
(while attempting to
relay translate a foreign address into 822 syntax) than
the message to portion of the remote MTA.
The conventions MTA that rewrites such addresses for interpreting the remote-status DSN field are
specific message
envelope. The best way to solve the remote MTS-type.
This field is optional, because some mail systems supply no additional
information beyond that which is returned in the
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:
(a) New Status Codes
New status codes may address rewriting problem would
seem to be defined to reflect error conditions which are
not covered either by existing SMTP reply codes or by make the additional
codes defined in section 10.1 source of this memo. New codes must be
consistent with the theory of status codes defined problem obvious via accurate error
reporting using DSNs.
NOTE: Although RFC 1123 [7] discourages explicit source routing in section 10,
SMTP, and
MUST be defined in a published RFC.
(b) New MTS types
New MTS-type names may be defined allows SMTPs to route directly 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 final domain, source
Moore/Vaudreuil Expires 14 January 20 May 1995 [Page 12] 11]
Delivery Status Notifications 14 July 20 November 1994
Internet and
routes are still allowed.
If the foreign MTS-type.
At a minimum, recipient address as originally specified is available in RFC 822
addr-spec format, the definition of an additional MTS-type Recipient field should include:
(1) contain that address.
Otherwise, the proposed MTS-type name
(2) Recipient field should contain the syntax of addresses for closest available
recipient address to that MTS-type, specified by the sender, as they are 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
represented in all the information available to correlate the DSN fields
(3) with a
particular message transaction.
Although domain names are case-insensitive, the syntax case of MTA names for that MTS-type
(4) alphabetic
characters in the syntax local-part of status codes 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 that MTS-type, along with a list of each recipient named in the codes that are valid
NOTE: A definition DSN.
The syntax for the INET MTS-type appears action-field is:
action-field = "Action" ":" action-value
action-value = "failed" / "delayed" / "delivered" / "relayed"
The action-value may be spelled in section 11 any combination of this
memo.
(c) New DSN Fields
Additional per-message or per-recipient DSN fields may upper and lower
case characters.
"failed" indicates that the message could not be defined by delivered to the
recipient. The final MTA has abandoned any
extension attempts to
deliver the message to this memo that is published as an RFC. These fields recipient. No further
notifications 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 expected.
"delayed" indicates that are specific to a particular MTS-type should
begin with the MTS-type name and a hyphen. For example: MTS-type.
Extension field names beginning with "X-" are reserved for experimental
use.
5. Conformance and Usage Requirements
An final MTA or gateway conforms has so far been unable to this specification if
deliver or relay the message, but it generates DSNs
according will continue to
attempt to the protocol defined in this memo. For MTAs and gateways
that do not support requests for positive delivery so. Additional notification (such messages may be
issued as
in [5]), it is sufficient that delivery failure reports use this
protocol.
A minimal implementation of this specification will generate only the
Rcpt, Action, and Status fields. However, generation of the other
fields message is strongly recommended.
MTAs and gateways MUST NOT generate the "original-rcpt" field of a DSN
unless the mail transfer protocol ensures further delayed or successfully
delivered, or if delivery attempts are later abandoned.
"delivered" indicates that the address provided is message was successfully delivered to
the one originally recipient address specified by the sender at the time of submission.
(Ordinary SMTP sender, which
includes "delivery" to a mailing list expander. It does
not make indicate that guarantee, but the SMTP extension
defined in [5] permits such information to be carried in the envelope if
it message has been read. This is available.)
Each sender-specified recipient address should result in at most one
"delivered" or "failed" DSN for that recipient. If a
terminal state and no further DSN is requested for this recipient should
be expected.
Moore/Vaudreuil Expires 14 January 20 May 1995 [Page 13] 12]
Delivery Status Notifications 14 July 20 November 1994
for a message that is forwarded to multiple recipients, the forwarding
MTA should normally issue a
"relayed" DSN for indicates that the originally-specified
recipient and message has been relayed or gatewayed
into an environment that does not propagate the request accept responsibility for a DSN
generating DSNs according to this specification.
Additional notification messages may be provided by the forwarding
addresses. Alternatively, the forwarding MTA can relay the request for
a DSN
"remote" environment that may or may not conform to exactly one of this
specification. (However, for subsequent notifications, the forwarding addresses and
'original-recipient' field will almost certainly not propagate be
included because it will no longer be available.)
NOTE ON ACTION VS. STATUS CODES: Although the
request 'action' field appears to
be redundant with the others.
Submission of a message to a mailing list exploder 'status' field, this is considered final
delivery 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 message. Upon delivery status of a the 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. recipient. This specification places no restrictions on field MUST
be present for each delivery attempt which is described by a DSN.
The syntax of the processing 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 user agents or distribution lists.
6. Security considerations the recipient. Even if DSNs may are not actively forged,
conditions exist under which a message can be forged as easily as ordinary Internet electronic mail. User
agents and automatic mail handling facilities (such as mail distribution
list expanders) delivered despite the fact
that wish to make automatic use a failure DSN was issued.
For example, a race condition in the SMTP protocol allows for the
duplication of DSNs should take
appropriate precautions 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 minimize retransmit the potential damage from denial-of-
service attacks. 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
(watch
The authors wish to thank the following people for their reviews of
earlier drafts of this space) 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.
[2]
[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.
[3] Westine, A., Postel, J. "Problems with the Maintenance of Large
Mailing Lists", RFC 1211, USC/Information Sciences Institute, March
1991.
[4] Borenstein, N., Freed, N. "Multipurpose Internet Mail Extensions", 11, RFC 1341, Bellcore, Innosoft, June 1992.
[5] 822, UDEL, August 1982.
[6] Moore, K. "SMTP Service Extension "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 Delivery Status
Notifications", Internet Draft.
[6] Hosts - Application and
Support" RFC 1123, October 1989.
[8] Klensin, J., Freed, N., Rose, M., Stefferud, E., Crocker, D. "SMTP
Service Extensions" RFC 1425, United Nations University, 1651, MCI, Innosoft
Moore/Vaudreuil Expires 14 January 1995 [Page 14]
Delivery Status Notifications 14 July 1994 International, Inc.,
Dover Beach Consulting, Inc., Network Management Associates, Inc., The Branch Office, February 1993.
[7]
Silicon Graphics, Inc, July 1994.
[9] Klensin, J., Freed, N., Moore, K. "SMTP Service Extension for
Message Size Declaration" RFC 1427, United Nations University, 1653, MCI, Innosoft International,
Moore/Vaudreuil Expires 20 May 1995 [Page 20]
Delivery Status Notifications 20 November 1994
Inc., University of Tennessee, February
1993.
[8] Moore, K., Vaudreuil, G. "Multipart/Report", Internet-Draft (in
preparation) 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 14 January 20 May 1995 [Page 15] 21]
Delivery Status Notifications 14 July 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.
x1z Information
These are replies to requests for information, such as status or
help.
x2z Connections
Moore/Vaudreuil Expires 14 January 1995 [Page 16]
Delivery Status Notifications 14 July 1994
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
Moore/Vaudreuil Expires 14 January 1995 [Page 17]
Delivery Status Notifications 14 July 1994
requested but which were successfully relayed or gatewayed into an
environment which does not support such notifications.
Moore/Vaudreuil Expires 14 January 20 May 1995 [Page 18] 23]
Delivery Status Notifications 14 July 20 November 1994
11. Appendix - definition of the INET INTERNET MTS-type
The INET 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), (DNS)
(including domains registered under "wildcard" mail exchanger (MX)
records), and (c) exchange such messages with the IP-connected Internet.
The INET INTERNET MTS is not limited to those systems using SMTP.
MTS-type-name: INET INTERNET
Address-syntax: Addresses for the INET INTERNET MTS must be in the "addr-spec" "addr-
spec" format defined in RFC 822, 822 (with an optional "route" prefix), using
fully-qualified domain names which are registered with the DNS.
MTA-name-syntax: An INET INTERNET MTA-name shall be the fully-qualified
domain name of the MTA issuing the DSN. The address Postmaster@{mta-name} Postmaster@{mta-
name} must be a valid address by which the maintainer of that MTA may be
reached.
Status-codes: Status codes for the INET 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 14 January 20 May 1995 [Page 19] 24]
Delivery Status Notifications 14 July 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 = rcpt-field 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-rcpt-field original-recipient-field CRLF ]
[ final-rcpt-field final-recipient-field CRLF ]
[ final-status-field CRLF ]
[ remote-mts-type-field CRLF ]
[ remote-mta-field CRLF ]
[ remote-rcpt-field remote-recipient-field CRLF ]
[ remote-status-field CRLF ]
*( extension-field CRLF )
rcpt-field
recipient-field = "Rcpt" "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
Moore/Vaudreuil Expires 14 January 1995 [Page 20]
Delivery Status Notifications 14 July 1994
original-rcpt-field
expiry-date-field = "Original-Rcpt" "Expiry-Date" ":" date-time
original-recipient-field = "Original-Recipient" ":" xtext
final-rcpt-field
final-recipient-field = "Final-Rcpt" "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-rcpt-field
remote-recipient-field = "Remote-Rcpt" "Remote-Recipient" ":" xtext
remote-status-field = "Remote-Status" ":" xtext
action-value = "failed" / "delayed" / "delivered" / "relayed"
status-code = 3*DIGIT
mts-type = atom
; note: for NOTE: For fields whose field-body is defined as 'xtext',
; the normal RFC 822 special characters and are not used.
; text enclosed in paraenthesis is treated as a comment,
; but such comments are NOT recognized. 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 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 used in xtext
xtext 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 = *(any ASCII CHAR between "\" immediately followed by the characters: CR LF SPACE (32) through TILDE
(126) inclusive)
Moore/Vaudreuil Expires 14 January 20 May 1995 [Page 21] 27]
Delivery Status Notifications 14 July 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 Rcpt, 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-rcpt 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 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 Internet. delivery status reports used by the destination MTS.
Such encapsulation will necessarily be specific to that particular MTS.
Moore/Vaudreuil Expires 14 January 20 May 1995 [Page 22] 29]
Delivery Status Notifications 14 July 20 November 1994
In general, the recipient of the DSN (i.e., the sender
14. Appendix - Guidelines for use of the original
message) will want DSNs by mailing list expanders
DSNs are designed to know, be used by mailing list expanders to allow them to
detect and automatically delete recipients for each recipient: the closest available
approximation whom mail delivery fails
repeatedly.
When forwarding a message to list subscribers, the original recipient address, 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 latest
available DSN format,
automatically examine them to determine for which recipients a message
delivery status code. Each of these must failed or was delayed.
The original-recipient field should be in used if available, since it
should exactly match the original
sender's format. subscriber address known to the list. If the original-rcpt address
original-recipient field is not available, and the original-mts-type
matches recipient field may
resemble the destination MTS, list subscriber address. Often, however, the list
subscriber will have forwarded his mail to a different address, or the original-rcpt
address should may be
provided in the resulting foreign delivery status report. Otherwise,
the gateway subject to some re-writing, so heuristics may translate the "canonical" rcpt be required
to successfully match an address into from the
convention required by recipient field. Care is
needed in this case to minimize the destination system. possibility of false matches.
The final- or remote-
rcpt addresses may also 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 used. However, ignored; in particular, subscribers should not
be removed from a list due to address translation
and mail forwarding, these may have little or no resemblance to "delayed" DSNs. The latest possible
status code understood by the
original recipient address.
If list expander should be used; the remote-status 'remote-
status' code is available and best, followed by the remote-mts-type matches 'final-status' code (if the MTS to which codes
for the DSN is being gatewayed, final or remote MTS-type are understood by the remote-status list expander),
and finally the 'status' code.
In general, almost any failure status code (even a "permanent" one) can
be used directly. Otherwise, if the final-mts-type matches
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
destination MTS, status code), but only on the final-status code may 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 used. Failing that, the
"canonical" status-code noticed and corrected quickly than others. When choosing
whether to delete a subscriber, it may be mapped into useful to differentiate
between the set of status codes used
by the destination MTS.
If codes. For example, on a list with a high message
volume, it is possible might be desirable to temporarily suspend delivery to tunnel a DSN through the destination MTS,
recipient address which causes repeated "temporary" failures, rather
than simply deleting the
gateway specification may define a means recipient. The duration of preserving the DSN
information in suspension
might depend on the delivery status reports used by type of error. On the destination MTS.
Such encapsulation will necessarily other hand, a "user unknown"
error which persists for several days can usually be specific to considered a
reliable that particular MTS. that address is no longer valid.
Moore/Vaudreuil Expires 20 May 1995 [Page 30]
Delivery Status Notifications 20 November 1994
Moore/Vaudreuil Expires 14 January 20 May 1995 [Page 23] 31]
Delivery Status Notifications 14 July 20 November 1994
14.
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 14 January 20 May 1995 [Page 24] 32]
Delivery Status Notifications 14 July 20 November 1994
14.1
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: INET INTERNET
Final-MTS-Type: INET INTERNET
Final-MTA: cs.utk.edu
Rcpt:
Recipient: louisl@larry.slip.umd.edu
Action: failed
Status: 426 (connection timed out)
Date: Thu, 7 Jul 1994 17:15:49 -0400
Original-Rcpt:
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 14 January 20 May 1995 [Page 25] 33]
Delivery Status Notifications 14 July 20 November 1994
14.2
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: INET INTERNET
Final-MTA: cs.utk.edu
Final-MTS-Type: INET
Rcpt: INTERNET
Recipient: arathib@vnet.ibm.com
Action: failed
Status: 550 ('arathib@vnet.IBM.COM' is not a registered gateway user)
Remote-MTS-Type: INET INTERNET
Remote-MTA: vnet.ibm.com
Original-Rcpt:
Original-Recipient: arathib@vnet.ibm.com
Rcpt:
Recipient: johnh@hpnjld.njd.hp.com
Action: delayed
Status: 466 (hpnjld.njd.jp.com: host name lookup failure)
Original-Rcpt:
Original-Recipient: johnh@hpnjld.njd.hp.com
Rcpt:
Recipient: wsnell@sdcc13.ucsd.edu
Action: failed
Status: 550 (user unknown)
Remote-MTS-Type: INET INTERNET
Remote-MTA: sdcc13.ucsd.edu
Original-Rcpt:
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 14 January 20 May 1995 [Page 26] 34]
Delivery Status Notifications 14 July 20 November 1994
Moore/Vaudreuil Expires 14 January 20 May 1995 [Page 27] 35]
Delivery Status Notifications 14 July 20 November 1994
14.3
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 (right (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
Rcpt:
Recipient: nair_s@SYS30.timeplex.com
Status: 500 (unknown failure)
Action: failed
Final-Rcpt:
Final-Recipient: nair_s
Final-Status: ??? (no matching directory entry found)
--[;84229080704991/122306@SYS30]--
Moore/Vaudreuil Expires 14 January 20 May 1995 [Page 28] 36]
Delivery Status Notifications 14 July 20 November 1994
14.4
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 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 00:36:51 19:24:03 +0100
Subject: WARNING: message delayed at "nsfnet-relay.ac.uk"
content-type: multipart/report; report-type=delivery-status;
boundary=foobar action Relayed
--foobar
content-type: text/plain
The following message:
UA-ID: Reliable PC (...
Q-ID: sun2.nsf:77/msg.11820-0
has not been delivered 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 intended recipient:
thomas@de-montfort.ac.uk
despite repeated delivery attempts over
overall structure of the past 24 hours.
The usual cause message before the description of this problem is 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 remote system same manner as in RFC 822.
3. Some fields are now explicitly marked as case-sensitive or
case-insensitive.
4. "Rcpt" is
temporarily unavailable.
Delivery will continue 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 be attempted up show how action and status-codes
work, contrasting conversion-with-loss with conversion-prohibited.
8. Changed 'xchar' grammar to a total elapsed
time disallow the characters "(", "#", and
"\"; added "#"XX notation for hexadecimal encoding; added "\" CR LF
SPACE notation to allow transparent continuation of 168 hours, ie 7 days.
You will lines.
9. Section 3.2.1.3: clarified "MUST be informed 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 proves
status reports.
15. Added text to be impossible
within this time.
Please quote clarify the Q-ID difference between original, final, and
remote MTAs.
15. Add text to suggest that subject, date, and message-id be retained
in any queries regarding this mail.
--foobar
content-type: message/delivery-status
Final-MTS-Type: INET
Final-MTA: sun2.nsfnet-relay.ac.uk
Rcpt: thomas@de-montfort.ac.uk
Status: 400 (unknown temporary failure)
Action: delayed
--foobar-- 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 14 January 20 May 1995 [Page 29] 39]
Delivery Status Notifications 14 July 20 November 1994
14.5 A DSN gatewayed from
18. Added Expiry-date per-recipient field.
19. Added more prose to say that (a) 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) single DSN can describe
delivery status 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:; multiple recipients of Sun, 3 Jul 1994 19:47:56 +0100
Your the same message, but (b)
the delivery status for all recipients of the same message was not delivered doesn't
have to sdz009@prime.napier.ac.uk be in a single DSN, and (c) a single DSN cannot describe
delivery events for multiple messages.
20. Expanded the following reason:
Message timed out
--foobar
content-type: message/delivery-status
Final-MTS-Type: X400
Final-MTA: sun3.nsfnet-relay.ac.uk 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 /PRMD=uk.ac/ADMD= /C=gb/
Rcpt: sdz009@prime.napier.ac.uk
Action: failed
Status: 400 (unknown temporary failure)
Final-Rcpt: /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-- 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 14 January 20 May 1995 [Page 30] 40]
----