
Network Working Group                                        Keith Moore
Internet Draft                                   University of Tennessee
Expires: January 14, 1995                                 Greg Vaudreuil
                                                  Octel Network Services
                                                           July 14, 1994


                      An Extensible Message Format
                   for Delivery Status Notifications

                 draft-ietf-notary-mime-delivery-02.txt


Status of this Memo

This document is an Internet Draft.  Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, and
its Working Groups.  Note that other groups may also distribute working
documents as Internet Drafts.

Internet Drafts are valid for a maximum of six months and may be
updated, replaced, or obsoleted by other documents at any time.  It is
inappropriate to use Internet Drafts as reference material or to cite
them other than as a "work in progress".


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 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].

This memo defines only the format of the notifications.  An extension to
the Simple Message Transfer Protocol (SMTP) to fully support such
notifications is the subject of a separate memo [5].

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, as well as
  the reasons for any delivery 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 so that she
  understands the nature of reported errors.  This feature is used in
  the case that failure to deliver a message is due to the malfunction
  of a remote MTA and the sender wants to report the problem to the
  remote MTA administrator

These purposes place the following constraints on the notification
protocol:

+ It must be readable by humans as well as being machine-parsable

+ It must provide enough information to allow the sender of a message
  (or his user agent) to unambiguously associate a DSN with the message
  that was sent and the original recipient address for which the DSN is
  issued (if such information is available), even if the message was
  forwarded to another recipient address

+ It must be able to preserve the information associated with a delivery
  attempt in a remote messaging system, using the "language" (addresses
  and status codes) of that remote system

+ 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 useful under some circumstances. The original
recipient address is needed by the message sender to be able to
associate a DSN with the recipient specified in the message.  The
"final" form of the address is needed when reporting a problem to a
remote postmaster.  When interpreting a DSN, the sender's user agent
will want the "remote" status code if it is available.  Either the
"final" form or 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 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 of
multipart/report.  The DSN is addressed (in both the header and
envelope) to the return address from the envelope of the message for
which the DSN is being generated.  The From header field of the DSN
contains the address of a human who is responsible for maintaining the
mail system at the final MTA site (e.g.  Postmaster), while the envelope
sender address of the DSN is set up to ensure that no delivery status
reports will be issued in response to the DSN itself.  (For example, in
SMTP, the MAIL FROM address should be an empty string.)

The first component of the multipart/report should be a human- readable
text message that summarizes, in prose, the delivery status information
that is presented in detail in the message/delivery-status component.
The second component of the multipart/report must be the
message/delivery-status content described in section 3 of this memo.
The third and final component of the multipart/report should contain
either the entire message as received by the final MTA or, if at all
possible, the headers of that message.

NOTE: For delivery status notifications gatewayed from foreign systems,
the headers of the original message may not be available. In this case
the third component of the DSN should be omitted.

The body of a message/delivery-status consists of one or more "fields"
formatted according to the ABNF of RFC 822 header "fields".  The per-
message fields appear first.  Following the per-message fields are one
or more groups of per-recipient fields.   Each group of per-recipient
fields is preceded by a blank line.  Using the ABNF of RFC 822, the
syntax of the message/delivery-status content is as follows:

     delivery-status-content =
         per-message-fields *( 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 particular mail system
which is registered with the Internet Assigned Numbers Authority (IANA).

The syntax for an MTS-type is:

     mts-type = atom

Because DSNs may be issued for messages that originated in foreign mail
systems, or gatewayed from delivery status reports that were issued in
foreign mail systems, many of the address and status codes fields may be
in some format other than that normally used in the Internet.  The
various MTS-type fields are used to identify the mail system in which a
particular address or status code appeared.  For example, if the final-
mts-type is X400, the final-rcpt address must be an X.400 recipient
address, and the final-status code must be an X.400-style error code.



Moore/Vaudreuil          Expires 14 January 1995                [Page 4]

Delivery Status Notifications                               14 July 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 may appear at most once in any DSN.  These
fields are used to correlate the DSN with the original message
transaction and to provide additional information which may be useful to
gateways.

With the exception of the original-mts-type field itself, the format of
each of the per-message fields is specific to the original-mts-type.

     per-message-fields = [ original-mts-type-field CRLF ]
                          [ original-envelope-id-field CRLF ]
                          [ final-mts-type-field CRLF ]
                          [ final-mta-field CRLF ]
                          *( extension-field CRLF )


3.1.1. The original-mts-type field

     original-mts-type-field = "Original-MTS-Type" ":" MTS-type

The original-mts-type field contains the MTS-type name of the MTS in
which the message was submitted.  This name MUST be an IANA-registered
MTS-type name.

This field is optional.


3.1.2 The original-envelope-id field

The optional original-envelope-id field contains an "envelope
identifier" which uniquely identifies the transaction during which the
message was submitted, and was either (a) specified by the sender and
supplied to the sender's MTA, or (b) generated by the sender's MTA and
made available to the sender when the message was submitted.  Its
purpose is to allow the sender (or her user agent) to associate the
returned DSN with the specific transaction in which the message was
sent.  There may be at most one original-envelope-id field per DSN.

The original-envelope-id line 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 is
issued, the original-envelope-id DSN field MUST NOT be included in the
DSN.





Moore/Vaudreuil          Expires 14 January 1995                [Page 5]

Delivery Status Notifications                               14 July 1994



NOTE: The original-envelope-id is NOT to be confused with the message-id
from the message header.  The message-id identifies the content of the
message, while the original-envelope-id identifies the transaction in
which the message is sent.


3.1.3. The final-mts-type DSN field

     final-mts-type-field = "Final-MTS-Type" ":" MTS-type

The final-mta-type field contains the name of the MTS via which the
message arrived at the final MTA.  The MTS-type must be registered with
IANA.

NOTE WELL: If the final MTA is actually a multi-protocol MTA or mail
gateway, the final-mts-type is the name of the MTS by which the message
ARRIVED at that MTA.


3.1.4. The final-mta DSN field

     final-mta-field = "Final-MTA" ":" xtext

The final-mta field contains the name of the MTA which issued the DSN.
This is not necessarily the MTA which reported the success or failure of
a delivery attempt.  For example, if an SMTP client attempts to relay a
message to an SMTP server and receives an error reply to a RCPT command,
the client is responsible for generating the DSN, and the client's
domain name will appear in the final-mta field.

The contents of the final-mta field are formatted according to the
conventions of the "final" MTS, as indicated by the final-mts-type field


3.1.5. Extension fields

Additional per-message DSN fields may be defined in the future, if
necessary to tunnel MTS-specific delivery for a particular MTS-type or
by any extension to this memo which is published as an RFC.

     extension-field = extension-field-name ":" xtext

     extension-field-name = atom


3.2 Per-Recipient DSN fields

A DSN contains information about attempts to deliver a message to one or
more recipients.  The delivery information for any particular recipient
is contained in a group of contiguous per-recipient fields.




Moore/Vaudreuil          Expires 14 January 1995                [Page 6]

Delivery Status Notifications                               14 July 1994



The syntax for the group of per-recipient 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 )

The "basic" fields are generic in nature and are always defined
according to Internet mail conventions.  Except for the "date" field,
these fields are required for each recipient listed in a DSN.  When mts-
specific fields are either not available or not usable (say, by a
gateway to a different environment), the "basic" fields provide fallback
values with a known syntax.

The syntax of each mts-specific field is specific to the mts-type for
which that field applies.  For example, the format of the final-rcpt,
final-mta, and final-status fields are given by the final-mts-type
field.

This combined approach allows "foreign" information to be preserved in
DSNs for messages that are gatewayed in or out of the Internet, while
retaining a set of "canonical" information which will always be present,
and which can provide minimum functionality.


3.2.1 Basic per-recipient fields


3.2.1.1 Rcpt field

The Rcpt field indicates the recipient for which this set of per-
recipient fields applies.  This field MUST be present in each set of
per-recipient data.

The syntax of the field is as follows:

     rcpt-field = "Rcpt" ":" addr-spec





Moore/Vaudreuil          Expires 14 January 1995                [Page 7]

Delivery Status Notifications                               14 July 1994



The value following the Rcpt field contains the RFC 822 mailbox of the
recipient address.  The address MUST 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, the Rcpt field should contain that address.
Otherwise, the Rcpt field should contain the closest available recipient
address to that specified by the sender.

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-rcpt field, the Rcpt field and any returned content may be all
the information available to correlate the DSN with a particular message
transaction.


3.2.1.2 action field

The action field indicates the reason the DSN was issued.  This field
MUST be present for each recipient.

The syntax for the action-field is:

     action-field = "Action" ":" action-value

     action-value = "failed" / "delayed" / "delivered" / "relayed"

The action-value may be spelled in any combination of upper and lower
case characters.

"failed"     indicates that the message could not be delivered to the
             recipient.  The final MTA has abandoned any attempts to
             deliver the message to this recipient.  No further
             notifications should be expected.

"delayed"    indicates that the final MTA has so far been unable to
             deliver or relay the message, but it will continue to
             attempt to do so.  Additional notification messages may be
             issued as the message is further delayed or successfully
             delivered, or if delivery attempts are later abandoned.

"delivered"  indicates that the message was successfully delivered to
             the recipient address specified by the sender, which
             includes "delivery" to a mailing list expander.  It does
             not indicate that the message has been read.  This is a
             terminal state and no further DSN for this recipient should
             be expected.

"relayed"    indicates that the message has been relayed or gatewayed



Moore/Vaudreuil          Expires 14 January 1995                [Page 8]

Delivery Status Notifications                               14 July 1994



             into an environment that does not accept responsibility for
             generating DSNs according to this specification. Additional
             notification messages may be provided by the "remote"
             environment that may or may not conform to this
             specification.  (However, for subsequent notifications, the
             'original-rcpt' field will not be included.)

NOTE: Although the 'action' field appears to be redundant with the
'status' field, this is not the case.  In particular, a 4XX status value
could be used with an action-value of either "delayed" or "failed".


3.2.1.3 status field

The per-recipient status field contains a status code which indicates
the delivery status of the message to that recipient.  This field MUST
be present for each recipient.

The syntax of the status field is:

     status-field = "Status" ":" status-code

     status-code = 3*DIGIT

"status" uses the set of reply codes from SMTP and its extensions, 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.

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
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




Moore/Vaudreuil          Expires 14 January 1995                [Page 9]

Delivery Status Notifications                               14 July 1994



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.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, as long as they can be represented as printable ASCII
characters.  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 field

The "original-rcpt" 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-rcpt
field will not necessarily contain an RFC 822-style recipient address.
However, if the original-mts-type field is present, the original-rcpt
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 [5].  This address is the same as
that provided by the sender and can be used to automatically correlate
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 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-rcpt
field MUST conform to the syntax for that MTS-type.

The final-rcpt field SHOULD NOT be included if either (a) the 'original-
rcpt' field is present for this recipient and its value is the same as
the final-rcpt value, or (b) the value specified in the 'rcpt' field 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.  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, that is, the one that reported the result of the
delivery attempt to the "final" MTA which issued the DSN.

This field is optional.  It SHOULD NOT be included in a DSN if the final
MTA had ultimate responsibility for delivery of the message.


3.2.2.9 remote-mta field

The value associated with the remote-mta DSN field should be a printable
ASCII representation 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 in the DSN fields for
a recipient unless the final MTA had ultimate responsibility for the
delivery of the message to that recipient.

The conventions for the name 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

The value associated with the remote-rcpt 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-rcpt 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-rcpt 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


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 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.

(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



Moore/Vaudreuil          Expires 14 January 1995               [Page 12]

Delivery Status Notifications                               14 July 1994



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 INET 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: MTS-type.

Extension field names beginning with "X-" are reserved for experimental
use.


5. Conformance and Usage Requirements

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 [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 is strongly recommended.

MTAs and gateways MUST NOT generate the "original-rcpt" 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 [5] 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



Moore/Vaudreuil          Expires 14 January 1995               [Page 13]

Delivery Status Notifications                               14 July 1994



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.

This specification places no restrictions on the processing of DSNs
received by user agents or distribution lists.


6. Security considerations

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.


7. Acknowledgments

   (watch this space)


8. References

[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
    USC/Information Sciences Institute, August 1982.

[2] 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",
    RFC 1341, Bellcore, Innosoft, June 1992.

[5] Moore, K.  "SMTP Service Extension for Delivery Status
    Notifications", Internet Draft.

[6] Klensin, J., Freed, N., Rose, M., Stefferud, E., Crocker, D.  "SMTP
    Service Extensions" RFC 1425, United Nations University, 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] Klensin, J., Freed, N., Moore, K.  "SMTP Service Extension for
    Message Size Declaration" RFC 1427, United Nations University,
    Innosoft International, Inc., University of Tennessee, February
    1993.

[8] Moore, K., Vaudreuil, G. "Multipart/Report", Internet-Draft (in
    preparation)


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 1995               [Page 15]

Delivery Status Notifications                               14 July 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-
     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 1995               [Page 18]

Delivery Status Notifications                               14 July 1994



11. Appendix - definition of the INET MTS-type

The INET MTS-type 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), and (c)
exchange such messages with the IP-connected Internet.  The INET MTS is
not limited to those systems using SMTP.

MTS-type-name: INET

Address-syntax:  Addresses for the INET MTS must be in the "addr-spec"
format defined in RFC 822, using fully-qualified domain names which are
registered with the DNS.

MTA-name-syntax:  An INET MTA-name shall be the fully-qualified domain
name of the MTA issuing the DSN.  The address Postmaster@{mta-name} must
be a valid address by which the maintainer of that MTA may be reached.

Status-codes: Status codes for the INET 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 1995               [Page 19]

Delivery Status Notifications                               14 July 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 ]
                     *( 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

extension-field = extension-field-name ":" xtext

extension-field-name = atom

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 )

rcpt-field = "Rcpt" ":" addr-spec

action-field = "Action" ":" action-value

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 = "Original-Rcpt" ":" xtext

final-rcpt-field = "Final-Rcpt" ":" 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-Rcpt" ":" xtext

remote-status-field = "Remote-Status" ":" xtext

action-value = "failed" / "delayed" / "delivered" / "relayed"

status-code = 3*DIGIT

mts-type = atom

; note: for fields whose field-body is defined as 'xtext',
; special characters and comments are NOT recognized.
; encoded-words may NOT be used in xtext

xtext = *(any ASCII CHAR between SPACE (32) through TILDE
(126) inclusive)



























Moore/Vaudreuil          Expires 14 January 1995               [Page 21]

Delivery Status Notifications                               14 July 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, 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 field.

The gateway should also attempt to preserve the "final" recipient
addresses, mta names, and status codes from the foreign system.  Because
DSN fields are limited to the ASCII character set, it may be necessary
to encode foreign protocol elements as printable ASCII values.  The
encoding method is specific to the MTS-type from which the delivery
report is being received.  "remote" values, when available, should be
similarly preserved.

If it is desirable to provide transparent tunneling of the foreign
delivery status notifications through Internet mail, the gateway
specification may define per-recipient extension fields to carry
additional mts-specific information as necessary.


13.2 Gatewaying from DSNs to other mail systems

A DSN may be gatewayed from the Internet to foreign mail system.  The
primary purpose of such gatewaying is to convey delivery status
information in a form that is usable by the destination system.  A
secondary purpose is to allow "tunneling" of DSNs through foreign mail
systems, in case the DSN may be gatewayed back into the Internet.



Moore/Vaudreuil          Expires 14 January 1995               [Page 22]

Delivery Status Notifications                               14 July 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-rcpt address is available, and the original-mts-type
matches the destination MTS, the original-rcpt address should be
provided in the resulting foreign delivery status report.  Otherwise,
the gateway may translate the "canonical" rcpt address into the
convention required by the destination system.  The final- or remote-
rcpt addresses may also be used.  However, due to address translation
and mail forwarding, these may have little or no resemblance to the
original recipient address.

If the remote-status code is available and the remote-mts-type matches
the MTS to which the DSN is being gatewayed, the remote-status code can
be used directly.  Otherwise, if the final-mts-type matches the
destination MTS, the final-status code may be used.  Failing that, the
"canonical" status-code may be mapped into the set of status codes used
by the destination MTS.

If it is possible to tunnel a DSN through the destination MTS, the
gateway specification may define a means of preserving the DSN
information in the delivery status reports used by the destination MTS.
Such encapsulation will necessarily be specific to that particular MTS.




























Moore/Vaudreuil          Expires 14 January 1995               [Page 23]

Delivery Status Notifications                               14 July 1994



14. 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 1995               [Page 24]

Delivery Status Notifications                               14 July 1994



14.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
Final-MTS-Type: INET
Final-MTA: cs.utk.edu

Rcpt: louisl@larry.slip.umd.edu
Action: failed
Status: 426 (connection timed out)
Date: Thu, 7 Jul 1994 17:15:49 -0400
Original-Rcpt: 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 1995               [Page 25]

Delivery Status Notifications                               14 July 1994



14.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
Final-MTA: cs.utk.edu
Final-MTS-Type: INET

Rcpt: arathib@vnet.ibm.com
Action: failed
Status: 550 ('arathib@vnet.IBM.COM' is not a registered gateway user)
Remote-MTS-Type: INET
Remote-MTA: vnet.ibm.com
Original-Rcpt: arathib@vnet.ibm.com

Rcpt: johnh@hpnjld.njd.hp.com
Action: delayed
Status: 466 (hpnjld.njd.jp.com: host name lookup failure)
Original-Rcpt: johnh@hpnjld.njd.hp.com

Rcpt: wsnell@sdcc13.ucsd.edu
Action: failed
Status: 550 (user unknown)
Remote-MTS-Type: INET
Remote-MTA: sdcc13.ucsd.edu
Original-Rcpt: 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 1995               [Page 26]

Delivery Status Notifications                               14 July 1994

























































Moore/Vaudreuil          Expires 14 January 1995               [Page 27]

Delivery Status Notifications                               14 July 1994



14.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 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: nair_s@SYS30.timeplex.com
Status: 500 (unknown failure)
Action: failed
Final-Rcpt: nair_s
Final-Status: ??? (no matching directory entry found)

--[;84229080704991/122306@SYS30]--



















Moore/Vaudreuil          Expires 14 January 1995               [Page 28]

Delivery Status Notifications                               14 July 1994



14.4  A delay report from a multiprotocol MTA.  Note that there is no
returned content; so no third body part in the DSN.


From: <postmaster@nsfnet-relay.ac.uk>
Message-Id: <199407092338.TAA23293@CS.UTK.EDU>
Received: from nsfnet-relay.ac.uk by sun2.nsfnet-relay.ac.uk
id <g.12954-0@sun2.nsfnet-relay.ac.uk>;
Sun, 10 Jul 1994 00:36:51 +0100
To: owner-info-mime@cs.utk.edu
Date: Sun, 10 Jul 1994 00:36:51 +0100
Subject: WARNING: message delayed at "nsfnet-relay.ac.uk"
content-type: multipart/report; report-type=delivery-status;
      boundary=foobar

--foobar
content-type: text/plain

The following message:

UA-ID:  Reliable PC (...
Q-ID:   sun2.nsf:77/msg.11820-0

has not been delivered to the intended recipient:

thomas@de-montfort.ac.uk

despite repeated delivery attempts over the past 24 hours.

The  usual cause of this problem is that the remote system is
temporarily unavailable.

Delivery will continue to be attempted up to a total elapsed
time of  168 hours, ie 7 days.

You  will  be  informed  if  delivery proves to be impossible
within this time.

Please quote the Q-ID in any queries regarding this mail.

--foobar
content-type: message/delivery-status

Final-MTS-Type: INET
Final-MTA: sun2.nsfnet-relay.ac.uk

Rcpt: thomas@de-montfort.ac.uk
Status: 400 (unknown temporary failure)
Action: delayed
--foobar--




Moore/Vaudreuil          Expires 14 January 1995               [Page 29]

Delivery Status Notifications                               14 July 1994



14.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/

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--










Moore/Vaudreuil          Expires 14 January 1995               [Page 30]

