Internet DRAFT - draft-vaudreuil-mime-delivery
draft-vaudreuil-mime-delivery
Network Working Group Greg Vaudreuil
Internet-Draft Tigon Corporation
Expires 7/22/94 January 22th, 1993
An Extensible Message Format
for Delivery Status Notifications
<draft-vaudreuil-mime-deliver-02.txt>
Note: See Appendix for changes from previous version.
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
The memo defines a MIME content type for the return of non-
delivery, delayed message, service availability, and other
message status notifications to the sender. This content type is
intended to be a machine processable alternative to the full
range of error messages currently sent on the Internet and to
provide a general mechanism for reporting message status
information to a users mail agent.
1.Introduction
The current Internet mail protocol suite is lacking in standard
mechanism for the handling of mail system errors, both on behalf
of users and for computer assisted management of large mailing
lists. There are few standards which would facilitate
implementation of user friendly mail interfaces. This document
defines an extensible format for the exchange of delivery status
notifications.
The current Internet mail system returns unsolicited non-delivery
notifications. This document defined a mechanism whereby these
notifications can be implemented using this format. This
document also provides for a mechanism for reporting two new
classes of non-delivery notifications expected to become common
with the deployment of the Multipurpose Internet Mail Extensions
(MIME) and Privacy Enhanced Mail (PEM).
It is likely that new delivery report types will be needed,
including positive delivery acknowledgment and read receipt
notification. As these new delivery report types are defined,
and in particular, as the mechanism for requesting those reports
Internet Draft Delivery Status November 22, 1993
are specified, the values for the delivery service notification
can be extended.
2.Delivery Status Notification Framework
The Delivery Status mechanism is implemented by defining two new
MIME content-types, Multipart/Delivery-Status and Text/Delivery-
Status. The Multipart/Delivery-Status is syntactically the same
as a multipart/mixed but contains exactly two parts, the first is
the Text/Delivery-Status and the second is a return of content.
If return of content is not requested or supported, the
Text/Delivery-Status may be send without Multipart/Delivery-
Status.
The Text/Delivery-Status contains the specific service
notification information, such as error reports, read-receipts,
and service unsupported notifications. This content-type is
formatted according to the rules for RFC 822 headers and contains
information for machine processing of the message. RFC 822
comments are permitted where appropriate for human consumption in
the absence of a parser capable of interpreting the service
notification.
Note: Limitations in the format for RFC 822 headers and the
necessity in places to structure sets of recipient addresses
may argue for use of the Structured Text Interchange Format
(STIF) or a lightweight SGML implementation - Please
comment. (This means you DCrocker!)
Return of content may be wasteful of network bandwidth and a
variety of implementation strategies can be used. Generally the
sender should choose the appropriate strategy and inform the
recipient of the required level of returned content required. In
the absence of any clear mechanism for requesting a level of
return of content, the agent which generated the delivery service
notification should return the full message content.
Vaudreuil Expires 7/22/94 [Page 2]
Internet Draft Delivery Status November 22, 1993
3.Multipart/Delivery-Status
Mime type name: Multipart
Mime Sub-Type name: Delivery-Status
Required Parameters: Boundary
Optional Parameters: None
Encoding Considerations: Quoted-Printable and Base-64 are
prohibited.
The syntax of a Multipart/Delivery-Status is identical to the
Multipart/Mixed content type. The Delivery Status may contain
two or three body parts. If present, a text/plain body part with
a human friendly text description of the error should be the
first body part. The next, or first body part, if the text/plain
part is present, is an Text/Delivery-Status, defined in a
subsequent section of this appendix. The last body part may be
of any content-type and contains the returned message for which
the Delivery Status is defined. The returned comment will
normally be a message/RFC822, or the content type message/sample
defined in this document.
If an Text/Delivery-Status does not include returned content, or
a text description of the error, Multipart/Delivery-Status should
not be used.
Vaudreuil Expires 7/22/94 [Page 3]
Internet Draft Delivery Status November 22, 1993
4.Text/Delivery-Status
Mime type name: Text
Mime Sub-Type name: Delivery-Status
Required Parameters: None
Optional Parameters: None
Encoding Considerations: 7bit is always sufficient.
The Text/Delivery-Status body provides delivery status
notifications. It is generally used with a Multipart/Delivery-
Status when the original content is to be returned to the sender.
The Text/Delivery-Status is a series of attribute-value pairs
formatted as RFC 822 headers. While this body-part is designed
to be machine parsable, RFC 822 comments are permitted in each
line. Text values in character sets other than US ASCII must be
formatted using the RFC 1522 encoded-word.
Generation of error messages from this error report for user
consumption should be based on the notification code, not the
explanatory text. Choice of an appropriate language and character
set is independent of the error. Applications implementing this
delivery status notification body part are expected to provided
localized descriptions of the errors based on the notification
code. The choice of US ASCII for the explanatory text in comments
is an interim measure based on current practice for ease of
transition.
4.1. Generic Service Notification Attributes
The following notification attributes are defined for all
delivery status notifications.
o Message-ID: - The RFC 822 message-id of the message causing
this delivery service notification.
o Envelope-Identifier: - The serial identifier of the message
envelope if one exists. This corresponds to the X.400 MTS
Identifier.
o Intended-Recipient:- A coma separated list of one or more
recipient email addresses for which this report applies.
These are the addresses as presented by the (E)SMTP envelope
RCPT-TO commands.
o Original-Recipients: - A coma separated list of one or more
recipient email addresses as specified in the original SMTP
envelope. These addresses if included must correspond on a
one to one basis with the intended recipient attributes.
o Recipient-Tags: - A coma separated list of one or more
recipient address tags. These tags are used by X.400 to
identify recipients and correlate error reports. When
Vaudreuil Expires 7/22/94 [Page 4]
Internet Draft Delivery Status November 22, 1993
provided, these tags must correspond on a one to one basis
with the intended recipients attributes.
o Sending-MTA: - The fully qualified domain address of the MTA
originating the message notification.
o Date: - The date and time according to the RFC822 "date-time"
of the notification event.
o Action: - The service notification type. The initially
defined action type is "Failed", that is, the message could
not be delivered.
o MTA-Notification-Code: - The response code returned which
caused message notification to be returned. The set of
response codes defined by the SMTP protocol is extended to
address general network notification events.
4.2. Extension Mechanism for Delivery Status Notifications
The delivery status notification body part include several
generic attribute value fields needed to correlate incoming
service delivery reports to the originally sent message and
recipients. The following mechanisms are permitted for
extension.
o New attributes may be defined as needed to convey information
beyond that possible with the generic attributes.
o New action keywords may be defined to indicate the current
message status.
o New MTA notification-codes may be defined as needed to
indicate the specific event resulting in the delivery status
notification.
New mechanisms for correlating error reports, notification
events, and indicating the intended recipients are prohibited.
This is necessary to insure that new delivery service
notifications are compatible with and generally useful without
understanding the specific notification provided.
In the event the generic attributes are insufficient for this
task, this specification as a whole should be revised.
Vaudreuil Expires 7/22/94 [Page 5]
Internet Draft Delivery Status November 22, 1993
5.Message/Sample
Mime type name: Message
Mime Sub-Type name: Sample
Required Parameters: None
Optional Parameters: None
Encoding Considerations: Any suitable content-transfer encoding
may be used.
The message/sample is defined as containing the returned headers
and body of an RFC 822 message which cannot be guaranteed to be
complete or which cannot be returned without transfer encoding.
A message transfer agent or a mail gateway may receive a message
fragment which should be returned to the sender. If there is no
guarantee that the message is a complete untruncated message,
labeling it as Message/RFC822 may be incorrect. In the case
where the message is a multipart message formatted according to
the MIME conventions, a truncated message may no longer be
parsable as indicated in the content-type.
Message/RFC822 messages may also not be transfer encoded. A MTA
or gateway which has received a returned message may not be able
to determine the content-type when required to return the
message. The message/sample may be encoded as needed to return
the message to the sender.
Vaudreuil Expires 7/22/94 [Page 6]
Internet Draft Delivery Status November 22, 1993
6.Initially defined Delivery Status Notification Types
6.1. MTA Non Delivery Notifications
The Internet currently provides non-delivery reports, but in a
non-standard and difficult to use format. This specification is
intended to replace these error reports with a standard
mechanism.
SMTP provides a standardized status reporting system in the use
of numeric reply-codes. The delivery status notification
mechanism provides a mechanism to make these error codes
available to the sender. Because the SMTP response codes do not
provide a complete diagnostic record, this specification has
extended the set of response codes to include non-SMTP network
and communications conditions which may cause non-delivery.
6.1.1. Framework for the MTA Failure notification type
The following delivery service notification is defined:
o The name of the delivery service notification is "MTA
Failure".
o The list of response codes includes all permanent SMTP and
ESMTP error codes and the additional codes defined in this
document.
o No additional attributed types are defined.
o No additional action types are defined.
Non-delivery notifications must be implemented in such a manner
that only a single delivery notification is generated per
message. The non-delivery notification should be send only when
further delivery attempts will not be performed.
6.1.2. SMTP/ESMTP Error Codes
SMTP provides a rich set of non-delivery error codes for
reporting on the status of a SMTP transaction.
The 500 series of error codes are "hard" failures, indicating
that the command cannot be completed. Not all these errors
require reporting the message as undeliverable. The listed
commands are a subset of the full SMTP diagnostics useful in the
Delivery-Status context.
550 Requested action not taken: mailbox
unavailable, mailbox not found, no access
552 Requested mail action aborted: exceeded
storage allocation
Vaudreuil Expires 7/22/94 [Page 7]
Internet Draft Delivery Status November 22, 1993
553 Requested action not taken: mailbox name
not allowed [E.g., mailbox syntax
incorrect]
554 Transaction Failed
6.1.3. Network or System Error Codes
Often mail transfer failures result from network or transport
level conditions which are not part of the SMTP protocol. These
errors are generally made known in current error reports, but
need to be assigned numeric codes to be used in the
Text/Delivery-Status content type. The following error codes are
defined to communicate these system failures. These are derived
from the SMTP error code convention of permanent (5XX) connection
(X2X) errors.
522 Host unreachable. The host specified is not
connected to the MTA.
522 Network Unreachable. The network the host
resides upon is either not connected to the
MTA or unreachable due to routing problems.
523 Host name does not exist. A non existent
destination was provided.
524 Service not available. SMTP on TCP port 25
is not available.
Vaudreuil Expires 7/22/94 [Page 8]
Internet Draft Delivery Status November 22, 1993
6.1.4. Example Non-Delivery Message
The following error message was sent to the user Keith on message
machine cs.utk.edu because the message addressed to Greg was mis-
addressed and does not exist on message machine Tigon.com. The
error message was sent by the mail program itself and not on
behalf of a particular user and therefor has the From: address of
"Postmaster".
To: Moore@cs.utk.edu
From: postmaster@Tigon.com
Mime-Version: 1.0
Date: Mon, 3 Fri 93 13:39:31 PDT
Message-ID: Tigon.com-1212121212
Content-type: Multipart/Delivery-Status;
boundary = "service-notification-boundary"
--service-notification-boundary
content-type: Text/Delivery-Status
Message-Id: cs.utk.edu-123456789
Intended-recipient: GregZ@Tigon.com
Action: Failed
Date: Fri, 3 Sep 93 13:39:31 PDT
MTA-Notification-Code: 550 (Invalid mailbox)
Sending-MTA: Tigon.com
--service-notification-boundary
Content-type: Message/Sample
Content-Transfer-Encoding: 7bit
Received: ......
Received: ......
To: GregZ@Tigon.com
From: Moore@cs.utk.edu
Subject: This is a test of your new address
Date: Fri, 3 Sep 93 13:36:12 PDT
This is a test message
Keith
--service-notification-boundary--
Vaudreuil Expires 7/22/94 [Page 9]
Internet Draft Delivery Status November 22, 1993
6.2. Unsupported Service Notification
The Multi-purpose Internet Mail Extensions (MIME) protocol
enables the sending of rich multi-media messages. The lack of
directory services makes it likely that a message will be sent
which cannot be viewed or converted to a media type which can be
viewed.
There is no defined mechanism for reporting to the sender when
such a message is deliverable but not readable or processable.
In many messaging environments, it may be useful to return a
message to the sender indicating that the specified content-type
is unsupported. It is expected that this information will be
cached, either informally by a human user, or by a local
directory for use by the user agent.
This unsupported service notification extension provides a
mechanism to report media conversion errors. At this time there
is no defined mechanism to request or prohibit message
conversion. Even in the absence of any defined mechanism, this
notification type is useful for reporting failures when a
recipient may attempt to convert a content as required for
successful delivery.
6.2.1. Framework for the Unsupported Service Notifications
The following delivery service notification is defined:
o The name of this delivery service notification is "Service
Failure".
o The list of response codes is extended by this service
notification type.
o One additional attributed types is defined, "Service-Not-
Available". This attribute may contain one or more coma
separate MIME content type designators which could not be
viewed by the recipient.
o No additional action types are defined.
Determination of what is a supported and what is an unsupported
feature and the mechanisms by which a user agent may report non-
support of content is left as an implementation choice. Note
that a user may have resources beyond his mail reading program by
which to process new content-types.
Only one service notification may be sent per message. Service
notifications are to be generated in such a manner that
subsequent delivery or read attempts will not result in
additional service notifications.
Vaudreuil Expires 7/22/94 [Page 10]
Internet Draft Delivery Status November 22, 1993
6.2.2. Service Failure Codes
A new series of error codes is defined to report these errors.
These errors are permanent (5XX) service (X6X) errors.
560 Content not supported.
561 Implicit conversion to a media type usable
by the recipient is prohibited by the
sender.
562 Conversion to a media type supported by the
recipient is not possible.
563 Conversion to a media type supported by the
recipient is not practical.
Vaudreuil Expires 7/22/94 [Page 11]
Internet Draft Delivery Status November 22, 1993
6.2.3. Example Unsupported Service Message
The following Delivery Status Notification was sent to user Keith
on machine cs.utk.edu when his fax image message sent to Greg on
machine Tigon.com could not be viewed. No return of content was
requested.
To: Moore@cs.utk.edu
From: GregV@Tigon.com
Message-ID: Tigon.com-1212121212
Mime-Version: 1.0
Date: Mon, 3 Fri 93 13:39:31 PDT
Content-type: Multipart/Delivery-Status;
boundary = "service-notification-boundary"
--service-notification-boundary
content-type: Text/Delivery-Status
Message-Id: cs.utk.edu-123456789
Intended-recipient: GregV@Tigon.com
Action: Failed
MTA-Notification-code: 560 (Media type is not supported)
Date: Fri, 3 Sep 93 13:39:31 PDT
Sending-MTA: Tigon.com
Service-Not-Available: Image/G3fax
--service-notification-boundary
Content-type: Message/Sample
Content-Transfer-Encoding: 7bit
Received: ......
To: GregV@Tigon.com
From: Moore@cs.utk.edu
Subject: This is a test of your new address
Date: Fri, 3 Sep 93 13:36:12 PDT
Mime-Version: 1.0
Content-Type: Image/G3Fax
Content-Transfer-Encoding: Base-64
......
--service-notification-boundary--
Vaudreuil Expires 7/22/94 [Page 12]
Internet Draft Delivery Status November 22, 1993
6.3. Delayed Message Notifications
It is common practice in the Internet to send a notification to
the message originator when a message is delayed beyond a
reasonable time. While these messages are simply advisory, it is
useful to report the delay in a standardized format to enable
automated sorting and if reasonable, discard. Multiple delayed
message notifications may be sent as the delay accumulates.
6.3.1. Framework for Delayed Message Notifications
The following delivery service notification is defined:
o The name of this delivery service notification is "Delayed
Message".
o The list of response codes include all temporary failure
response codes from SMTP and ESMTP and the new codes defined
in this document.
o One additional attributed types is defined, "Message-Status".
This attribute will indicate the additional time for which
future delivery attempts will be made. The value is a
positive integer representing the number of hours the message
will remain in queue.
o One new action type is defined, "Delayed". This action type
indicates that the message has been queued for further
processing.
o Return of content is not appropriate for this delivery
service notification type.
6.3.2. Delayed Message Codes
The 400 series of response codes are "soft" failures, indicating
that re-try is reasonable at a later time. These errors should
only be reported if the message is queued for future delivery
attempts. If these conditions are permanent, they must be
reported as a non-delivery notification using 5XX codes .
421 <domain> Service not available, [This may
be a reply to any command if the service
knows it must shut down]
450 Requested mail action not taken: mailbox
unavailable [E.g., mailbox busy]
451 Requested action aborted: local error in
processing
452 Requested action not taken: insufficient
system storage
Vaudreuil Expires 7/22/94 [Page 13]
Internet Draft Delivery Status November 22, 1993
Often mail transfer delays result from network or transport level
conditions which are not part of the SMTP protocol. These
conditions are generally made known in current error reports, but
need to be assigned numeric codes to be used in the
Text/Delivery-Status content type. The following error codes are
defined to communicate these system delays. These are derived
from the SMTP error code convention of temporary (4XX) connection
(X2X) errors.
424 Service not available. SMTP on TCP port 25 is
not available.
422 Host unreachable. The host specified is not
connected to the MTA.
6.3.3. Example Delayed Message Notice
The following message was sent to Keith on machine cs.utk.edu
reporting that the mail machine Tigon.com was temporarily
unavailable and that delivery attempts will continue for 3 days.
To: Moore@cs.utk.edu
From: GregV@Tigon.com
Message-ID: Tigon.com-1212121212
Mime-Version: 1.0
Date: Mon, 3 Fri 93 13:39:31 PDT
Content-type: Text/Delivery-Status
Action: Delayed
Intended-recipient: GregV@Tigon.com
Message-Status: 72 (Delivery attempts will continue for 3
days)
Date: Fri, 3 Sep 93 13:39:31 PDT
MTA-Notification-Code: 422 (Host unreachable)
Message-Id: cs.utk.edu-123456789
Sending-MTA: Tigon.com
Vaudreuil Expires 7/22/94 [Page 14]
Internet Draft Delivery Status November 22, 1993
6.4. Security Failure Notification Type
Privacy Enhanced Mail and other mail security protocols provide
the ability to protect a message content from modification. This
protection may render a message unsuitable for gatewaying into a
new environment or unreadable by a recipient without the
appropriate security keys.
6.4.1. Framework for Security Failure Message Notifications
The following delivery service notification is defined:
o The name of this delivery service notification is "Delayed
Message".
o The list of response codes include all temporary failure
response codes from SMTP, ESMTP, and the MTA Failure service
notification type.
o No additional attributed types is defined.
o No additional action type is defined.
6.4.2. Security Failure Codes
A new series of error codes is defined to report these
conditions. These response codes are permanent (5XX) security-
related (X7X) errors.
570 Message could not viewed due to security
protection
571 Message could not be relayed due to
security protection
Vaudreuil Expires 7/22/94 [Page 15]
Internet Draft Delivery Status November 22, 1993
7.Security Considerations
Message notifications are only as secure as the mechanism by
which they have been sent. It is important to note that
automatic deletion of an address from a mailing list based on
delivery status notifications may provide a mechanism for denial-
of-service attacks.
8.Authors Address
Gregory M. Vaudreuil
Tigon Corporation
17060 Dallas Parkway
Suite 109
Dallas, Texas 75248-1905
(214) 733 2722
Gvaudre@cnri.reston.va.us
Vaudreuil Expires 7/22/94 [Page 16]
Internet Draft Delivery Status November 22, 1993
Appendix - Changes from previous draft
o An optional Text/Plain body part can now be included in the
multipart/Delivery-Report. The text attributed has been
deleted in favor of this optional description. The
text/plain body part facilitates the use of non-ascii based
languages and is not subject to the formatting requirements
of the attribute/value syntax.
Vaudreuil Expires 7/22/94 [Page 17]
