
Network Working Group                                        Keith Moore
Internet Draft                                   University of Tennessee
                                                           21 March 1994


                         SMTP Service Extension
                   for Delivery Status Notifications

                      draft-ietf-notary-smtp-drpt-01.txt


1. Status of this Memo

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

   Internet-Drafts are draft documents valid for a maximum of six
months.  Internet-Drafts may be updated, replaced, or obsoleted by other
documents at any time.  It is not appropriate to use Internet-Drafts as
reference material or to cite them other than as a ``working draft'' or
``work in progress.''

   To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or
munnari.oz.au.


2. Abstract

   This memo defines an extension to the SMTP service, which allow an
SMTP client to specify (a) that delivery status notifications (DSNs)
should be generated under certain conditions, (b) whether such
notifications should return the contents of the message, and (c)
additional information, to be returned with a DSN, that allows the
sender to identify both the recipient and the transaction in which the
message was sent.


3. Introduction

   The SMTP protocol [1] requires that an SMTP server provide
notification of delivery failure, if it determines that a message cannot
be delivered to one or more recipients.  Traditionally, such
notification consists of an ordinary Internet mail message (format
defined by [2]), sent to the envelope sender address (the argument of
the SMTP MAIL command), containing an explanation of the error and at
least the headers the failed message.

   Experiences with large mail distribution lists [3] indicates that
such messages are often insufficient to diagnose problems, or even to
determine at which host or for which recipients a problem occurred.  In
addition, the lack of a standardized format for delivery notifications



K. Moore                Expires 21 September 1994               [Page 1]







SMTP Delivery Status Notifications                            March 1994



in Internet mail makes it difficult to exchange such notifications with
other message handling systems.

   Such experience has demonstrated a need for a delivery status
notification service for Internet electronic mail, which:

(a) is reliable, in the sense that any DSN request will either be
    honored at the time of final delivery, or result in a response that
    indicates that the request cannot be honored,

(b) should result in exactly one response for any particular sender-
    specified recipient,

(c) is stable, in that a DSN should never be issued in response to a
    DSN.

(d) preserves sufficient information to allow the sender to identify
    both the mail transaction and the recipient address which caused the
    notification, even when mail is forwarded or gatewayed to foreign
    environments, and

(e) interfaces acceptably with non-SMTP and non-822-based mail systems,
    both so that notifications returned from foreign mail systems may be
    useful to Internet users, and so that the notification requests from
    foreign environments may be honored.  Among the requirements implied
    by this goal are the ability to request non-return-of-content, and
    the ability to specify whether positive or negative delivery
    notifications, or both, or neither, should be issued.

   In an attempt to provide such a service, this memo uses the mechanism
defined in [4] to define an extension to the SMTP protocol.  Using this
mechanism, an SMTP client may request that an SMTP server issue or not
issue a delivery status notification (DSN) under certain conditions.
The format of a DSN is defined in [5].


4. Framework for the Delivery Status Notification Extension

   The following service extension is therefore defined:

(1) The name of the SMTP service extension is "Delivery Status
    Notification";

(2) the EHLO keyword value associated with this extension is "DSN", the
    meaning of which is defined in section 5 of this memo;

(3) no parameters are allowed with this EHLO keyword value;

(4) three optional parameters are added to the RCPT command, and one
    optional parameter is added to the MAIL command:




K. Moore                Expires 21 September 1994               [Page 2]







SMTP Delivery Status Notifications                            March 1994



    An optional parameter for the RCPT command, using the esmtp-keyword
    "NOTIFY", (to specify the conditions under which a delivery status
    notification should be generated), is defined in section 6.1,

    An optional parameter for the RCPT command, using the esmtp-keyword
    "RET", (to request that DSNs either return or not return the
    contents of a message), is defined in section 6.2,

    An optional parameter for the RCPT command, using the esmtp-keyword
    "ORCPT", (used to convey the "original" (sender-specified) recipient
    address), is defined in section 6.3, and

    An optional parameter for the MAIL command, using the esmtp-keyword
    "ENVID", (used to propagate a sender-specified unique identifier for
    this envelope, to be returned in a DSN), is defined in section 6.4;

(5) no additional SMTP verbs are defined by this extension.

   The remainder of this memo specifies how support for the extension
affects the behavior of a message transfer agent.


5.  The Delivery Status Notification service extension

   An SMTP client wishing to request a DSN for a message may issue the
EHLO command to start an SMTP session, to determine if the server
supports any of several service extensions.  If the server responds with
code 250 to the EHLO command, and the response includes the EHLO keyword
DSN, then the Delivery Status Notification extension (as described in
this memo) is supported.

   Ordinarily, when an SMTP server returns a positive (2xx) reply code
in response to a RCPT command, it agrees to accept responsibility for
either delivering the message to the named recipient, or sending a
notification to the sender of the message indicating that delivery has
failed.  However, an extended SMTP ("ESMTP") server which implements
this service extension will accept an optional NOTIFY parameter with the
RCPT command. If present, the NOTIFY parameter alters the default
conditions for generation of delivery status notifications from the
default (issue notifications only on failure) specified in [1].  The
ESMTP client may also request (via the RET parameter) that the contents
of the message be returned, or not returned, along with the DSN.

   In general, an ESMTP server which implements this service extension
will propagate delivery status notification requests when relaying mail
to other SMTP-based MTAs which also support this extension, and make a
"best effort" to ensure that such requests are honored when messages are
passed into other environments.

   In order that any delivery status notifications thus generated will
be meaningful to the sender, any ESMTP server which supports this



K. Moore                Expires 21 September 1994               [Page 3]







SMTP Delivery Status Notifications                            March 1994



extension will attempt to propagate the following information to any
other MTAs that are used to relay the message, for use in generating
DSN's:

(a) for each recipient, a copy of the original recipient address, as
    used by the sender of the message.

    This address need not be the same as the mailbox specified in the
    RCPT command.  For example, the addresses will be different if the
    message was forwarded from the sender-specified address to another
    address, or the message originated in a foreign environment that
    does not use Internet electronic mail addresses.

(b) for the entire SMTP transaction, an envelope identification string,
    which may be used by the sender to associate any delivery status
    notifications with the transaction used to send the original
    message.


6.  Additional parameters for RCPT and MAIL commands

   The extended RCPT and MAIL commands are issued by a client when it
wishes to request a DSN from the server, under certain conditions, for a
particular recipient.  The extended RCPT and MAIL commands are identical
to the RCPT and MAIL commands defined in [1], except that one or more of
the following parameters appear after the sender or recipient address,
respectively.  The general syntax for extended SMTP commands is defined
in [4].


6.1.  The NOTIFY parameter of the ESMTP RCPT command

   A RCPT command issued by a client may contain the optional esmtp-
keyword "NOTIFY", to specify the conditions under which the SMTP server
should generate DSNs for that recipient.  If the NOTIFY esmtp-keyword is
used, it MUST have an associated esmtp-value, which should consist of
one of the following keywords:

SUCCESS   to request that a DSN be issued only on successful delivery.
FAILURE   to request that a DSN be issued only on delivery failure.
ALWAYS    to request that a DSN be issued either on successful delivery,
          or on delivery failure.
NEVER     to request that a DSN not be issued under any conditions.

If the NOTIFY parameter is not included in a RCPT command, the SMTP
server should issue notifications for that recipient only if the message
cannot be delivered, as specified in [1].







K. Moore                Expires 21 September 1994               [Page 4]







SMTP Delivery Status Notifications                            March 1994



6.2 The RET parameter of the ESMTP RCPT command

   The RET esmtp-keyword on the extended RCPT command specifies whether
or not the message should be included in any DSN issued for this
recipient.  If the RET esmtp-keyword is used, it MUST have an associated
esmtp-value, which should contain one of the following keywords:

YES       requests that the message be returned in any delivery status
          notification issued for this recipient.
NO        requests that the message not be returned.

   The RET parameter is optional; it need not be specified to request a
DSN.  If the RET parameter was not specified for a particular recipient,
the MTA issuing the notification may choose to return the entire
content, partial content (e.g. the message headers only), or none of the
content.


6.3 The ORCPT parameter to the ESMTP RCPT command

   The ORCPT esmtp-keyword of the RCPT command is used to specify an
"original" recipient address that corresponds to the actual recipient to
which the message is to be delivered.   If the ORCPT esmtp-keyword is
used, it MUST have an associated esmtp-value, which consists of the
original recipient address, encoded according to the rules below.

IMPORTANT:  Because a message may have originated in a foreign
environment that does not use Internet-style electronic mail addresses,
the esmtp-value associated with the ORCPT keyword is NOT constrained to
conform to any particular address syntax.

   Ideally, the esmtp-value associated with this parameter should
contain (in encoded form) the same sequence of characters that the
sender used to specify the recipient.  However, for a message gatewayed
from an environment (such as X.400) in which a recipient address is not
a simple string of printable characters, the ORCPT parameter should
contain a printable representation of the recipient address that is
likely to be recognized by the sender.

   Any valid esmtp-value (as defined in [4]) may be associated with the
ORCPT keyword.  However, the syntax for an esmtp-value does not allow
the use of certain characters.  Since such characters might appear in
the original recipient address, the following scheme is used to encode
the original recipient address into a valid esmtp-value:

1. Any graphic ASCII character (range 32-126 inclusive), except for "=",
   SP, and "%", may be encoded as itself.

2. Any octet value may be encoded using the percent character ("%")
   followed by two hex digits.




K. Moore                Expires 21 September 1994               [Page 5]







SMTP Delivery Status Notifications                            March 1994



   The ORCPT parameter is optional.  It should not be supplied by the
SMTP client if the original recipient address (or a reasonable
printable-text representation thereof) is not available to the client.


6.4  The ENVID parameter to the ESMTP MAIL command

   The ENVID esmtp-keyword of the SMTP MAIL command is used to specify
an "envelope identifier" to be transmitted along with the message and
included in any DSNs issued for any of the recipients named in this SMTP
transaction.  The purpose of the envelope identifier is to allow the
sender of a message to identify the transaction for which the DSN was
issued.

   The ENVID esmtp-keyword MUST have an associated esmtp-value.  No
meaning is assigned by the mail system to the presence or absence of
this parameter or to any esmtp-value associated with this parameter; the
information is used only by the sender or his user agent.

   Use of the ENVID esmtp-keyword is optional.  It need not be specified
to request a DSN.


6.5. Restrictions on the use of Delivery Status Notification parameters

   No more than one ENVID parameter may appear in a single MAIL command.
No more than one each of the NOTIFY, RET, and ORCPT parameters may
appear in any RCPT command.  If multiple occurrences of any of these
parameters appear in a RCPT command, the ESMTP server should respond
with "5xx syntax error".


7. MTA conformance requirements

   Typically, a message transfer agent (MTA) which supports SMTP will
assume, at different times, both the role of a SMTP client and an SMTP
server, and may also provide local delivery, gatewaying to foreign
environments, forwarding, and mailing list expansion.  An MTA which, (in
its role as an SMTP server) issues the DSN keyword in response to the
EHLO command, MUST obey the rules below for a "conforming MTA" below.
The terms "conforming SMTP client" and "conforming SMTP server" refer to
a "conforming MTA" when acting in the role of an SMTP server or client,
respectively.


7.1 ESMTP protocol interactions

   The following rules apply to ESMTP transactions in which any of the
ENVID, NOTIFY, RET, or ORCPT keywords are used:

1. If an SMTP client issues a MAIL command containing a valid ENVID



K. Moore                Expires 21 September 1994               [Page 6]







SMTP Delivery Status Notifications                            March 1994



   parameter and associated esmtp-value, a conforming ESMTP server MUST
   return the same reply-code as it would to the same MAIL command
   without the ENVID parameter.  A conforming SMTP server MAY NOT refuse
   a MAIL command based on the presence or absence of an ENVID
   parameter, or on its associated esmtp-value.

   However, if the associated esmtp-keyword is not valid (i.e. contains
   illegal characters), or if there is more than one ENVID parameter in
   a particular MAIL command, the server should issue the response "501
   syntax error in parameter".

2. If an SMTP client issues a RCPT command containing any valid NOTIFY,
   RET, and/or ORCPT parameters, a conforming SMTP server MUST return
   the same response as it would to the same RCPT command without those
   NOTIFY, RET, and ORCPT parameters.  A conforming SMTP server MAY NOT
   refuse a RCPT command based on the presence or absence of any of
   these parameters.

   However, if any of the associated esmtp-keywords are not valid, or if
   there is more than one of any of these parameters in a particular
   RCPT command, the server should issue the response "501 syntax error
   in parameter".


7.2. Handling of messages received via SMTP

   This section describes how a conforming MTA should handle any
messages received via SMTP.


7.2.1. Relay of messages to other conforming SMTP servers

   The following rules govern the behavior of a conforming SMTP client,
when relaying a message which was received via the SMTP protocol, to an
SMTP server that supports the Delivery Status Notification service
extension:

1. Any ENVID parameter included in the MAIL command when message was
   received, MUST also appear on the MAIL command with which the message
   is relayed, with the same associated esmtp-value.  If no ENVID
   parameter was included in the MAIL command when the message was
   received, no ENVID parameter shall be supplied when the message is
   relayed.

2. If the NOTIFY parameter was supplied for a recipient when the message
   was received, the RCPT command issued when the message is relayed
   must also contain the NOTIFY parameter along with its associated
   esmtp-value.  If any RET or ORCPT parameters were present in the RCPT
   command for this recipient when the message was received, they must
   also appear in the RCPT command issued when relaying the message.
   When relaying a message to a particular recipient, no NOTIFY, RET, or



K. Moore                Expires 21 September 1994               [Page 7]







SMTP Delivery Status Notifications                            March 1994



   ORCPT parameters may be supplied which were not present in the RCPT
   command for that recipient when the message was received.


7.2.2.  Relay of messages to non-conforming SMTP servers

   The following rules govern the behavior of a conforming SMTP client,
when relaying a message which was received via the SMTP protocol, to an
SMTP server that does not support the Delivery Status Notification
service extension:

1. No ENVID, NOTIFY, RET, or ORCPT parameters may be issued when
   relaying the message.

2. If the NOTIFY parameter was supplied for a recipient, with an esmtp-
   value of either ALWAYS or SUCCESS, and the SMTP server returns a
   success (2XX) reply-code in response to the RCPT command, the client
   must issue a "relayed" DSN for that recipient.

3. If the NOTIFY parameter was supplied for a recipient with an esmtp-
   value of either ALWAYS or FAILURE, and the SMTP server returns a
   permanent failure (5XX) reply-code in response to the RCPT command,
   the client must issue a "failed" DSN for that recipient.

4. If the NOTIFY parameter was supplied for a recipient with an esmtp-
   value of NEVER, no DSN is issued, regardless of the reply-code
   returned by the SMTP server.

5. If no NOTIFY parameter was supplied for a recipient, and the SMTP
   server returns a permanent failure (5XX) reply-code in response to a
   RCPT command, the client must issue a "failed" DSN for that
   recipient.


7.2.3.  Local delivery of messages

   The following rules govern the behavior of a conforming MTA upon
successful delivery of a message that was received via the SMTP
protocol, to a local recipient's mailbox:

1. If the NOTIFY parameter was supplied for that recipient, with an
   esmtp-value of either ALWAYS or SUCCESS, the MTA must issue a
   "delivered" DSN for that recipient.

2. If the NOTIFY parameter was supplied for that recipient with an
   esmtp-value of NEVER, no DSN is issued.








K. Moore                Expires 21 September 1994               [Page 8]







SMTP Delivery Status Notifications                            March 1994



7.2.4.  Gatewaying a message into a foreign environment

   The following rules govern the behavior of a conforming MTA, when
gatewaying a message that was received via the SMTP protocol, into a
foreign (non-SMTP) environment:

1. If the the foreign environment is capable of issuing appropriate
   notifications under the conditions requested by the NOTIFY parameter,
   and the conforming MTA can ensure that any notification thus issued
   will be translated into a DSN and delivered to the original sender,
   then the MTA should gateway the message into the foreign environment,
   requesting notification under the desired conditions, without itself
   issuing a DSN.

2. If a NOTIFY parameter was supplied with an esmtp-keyword of ALWAYS,
   FAILURE, or SUCCESS, but the requested conditions specified by the
   associated esmtp-value cannot be met by the foreign mail environment,
   the MTA should issue a "relayed" DSN for that recipient.

3. If a NOTIFY parameter was supplied with an esmtp-keyword of NEVER, no
   DSN should be issued.

4. If no NOTIFY parameter was supplied for a particular recipient, no
   DSN should be issued by the gateway, but the gateway should attempt
   to ensure that appropriate notification will be provided by the
   foreign mail environment if eventual delivery failure occurs.

5. When gatewaying a message into a foreign environment, the return-of-
   content conditions specified by any RET parameter are nonbinding;
   however, the MTA should attempt to honor the request using whatever
   mechanisms exist in the foreign environment.


7.2.5.  Failure of a conforming MTA to deliver a message

   The following rules govern the behavior of a conforming MTA which
received a message via the SMTP protocol, and is unable to deliver a
message to a recipient specified in the SMTP transaction:

1. If a NOTIFY parameter was supplied for the recipient with an esmtp-
   keyword of either ALWAYS or FAILURE, a "failed" DSN should be issued
   by the MTA.

2. If a NOTIFY parameter was supplied for the recipient with an esmtp-
   keyword of either SUCCESS or NEVER, no DSN should be issued.

3. If no NOTIFY parameter was supplied for the recipient, a "failed" DSN
   should be issued.






K. Moore                Expires 21 September 1994               [Page 9]







SMTP Delivery Status Notifications                            March 1994



7.2.6.  Recipient-specified mail forwarding

   If a message intended for a particular recipient address is to be
"forwarded" to exactly one recipient address:

1. Any envelope-id included with the message as received, should be
   propagated in each ESMTP session used to forward the message to a
   conforming MTA.

2. Any NOTIFY, ORCPT, or RET parameters associated with a particular
   recipient should be propagated, for each of the recipients to which
   the message is forwarded.

   However, if the message is to be forwarded to multiple recipient
addresses on behalf of a single recipient, a "forwarded" DSN should be
issued, and the request for a DSN should NOT be propagated to the
recipient's forwarding addresses.

(NOTE IN DRAFT: this is intended to ensure exactly one notification per
request.  I'm concerned that DSNs will be difficult to use by mailing
list exploders if it's possible to get more than one notification per
request, say because a message was forwarded to two recipients, and
delivery succeeds for one and fails for the other.  On the other hand,
it's still possible to get both a "relayed" or "forwarded" DSN and
afterwards a "failed" DSN for the same recipient, and a foreign mail
system might not issue DSNs for forwarded messages and deliveries to
lists.)


7.2.7.  Delivery of a message to a mailing list

   If a particular recipient address refers to a mailing list, a message
is considered to be successfully delivered to that recipient if the MTA
determines that the message is eligible to be distributed to the members
of the list.  If a NOTIFY parameter was supplied with an esmtp-value of
either ALWAYS or SUCCESS, a "delivered" DSN should be issued.  Any
envelope-id, notify-request, return-of-content-request, or original-
recipient-address should NOT be propagated when delivering a message to
the recipients of that list.

   If the message is not eligible to be distributed to the list
membership (perhaps because the sender is not authorized), and either a
NOTIFY parameter was supplied with an esmtp-value of FAILURE, or no
NOTIFY parameter was supplied, a "failed" DSN should be issued.


7.3. Handling of messages from other sources

   For messages which originated from "local" users (whatever that
means), the specifications under which DSNs should be generated can be
communicated to the MTA via any protocol agreed on between the sender's



K. Moore                Expires 21 September 1994              [Page 10]







SMTP Delivery Status Notifications                            March 1994



mail composer (user agent) and the MTA.  The local MTA can then either
relay the message, or issue appropriate delivery status notifications.
However, if such requests are transmitted within the message itself (for
example in the headers), the requests MUST be removed from the message
before it is transmitted via SMTP.

   For messages gatewayed from non-SMTP sources and further relayed by
SMTP, the gateway should, using the SMTP extensions described here,
attempt to provide the delivery reporting conditions expected by the
source mail environment.  If appropriate, any DSNs returned to the
source environment should be translated into the format expected in that
environment.


8.  Format of delivery notifications

   The format of delivery status notifications is defined in [5].
Delivery status notifications are to be returned to the sender of the
original message according as outlined below.


8.1. SMTP Envelope to be used with delivery status notifications

   The sender address (in the SMTP MAIL command) must be an empty
string.  The recipient address (in the RCPT command) is copied from the
MAIL command of the message for which a delivery notification is being
issued.  The envelope of a delivery notification may not use the DSN
option.


8.2. Contents of the multipart/notification body part

   The multipart/notification body part should include either two or
three components:

(1) a text/plain body part containing a human-readable explanation of
    the conditions which produced the notification.
(2) a message/notification body part which contains the details of the
    notification in machine-readable form,
(3) if requested by the RET parameter, a message/sample body part
    containing the returned contents.

   For notifications issued as a result of the use of this extension,
the "type" parameter for the message/notification body part should be
"delivery-status".


8.3. Message/notification body field parameters

   For messages which were received via the SMTP protocol, the fields of
the message/delivery-report body part should be filled in as follows:



K. Moore                Expires 21 September 1994              [Page 11]







SMTP Delivery Status Notifications                            March 1994




(a) if an ENVID parameter was present on the MAIL command, an Envelope-
    ID field should appear in the message/notification body part, and
    the value associated with ENVID parameter should appear in that
    field.

(b) The Issuing-MTA field should appear in the message/notification body
    part, and it should contain the domain name of the SMTP server which
    is actually issuing this notification.

(c) The Notification-Date field should appear in the
    message/notification body part, and should contain the date and time
    of the last delivery attempt.

(d) For each recipient for whom a notification is being issued, a
    Recipient-Info field should appear.  The values within that field
    should be as follows:

    for       The "current" address of the recipient for which the
              report is being issued.

    status    If an attempt was made to forward or relay the message via
              SMTP, this value should contain the SMTP reply-code.
              Otherwise, it should contain a reasonable status-code from
              [5].

    action    As specified in section 5.4.3 of [5].

    orig      If the ORCPT parameter was provided for this recipient,
              the orig keyword should appear, and it's value taken from
              the ORCPT parameter.

    source    If the delivery status was obtained from a remote MTA, the
              name of that MTA should appear here.  Otherwise the domain
              name of the MTA issuing the report should appear here.


9. Acknowledgments

   (fill in this space)


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



K. Moore                Expires 21 September 1994              [Page 12]







SMTP Delivery Status Notifications                            March 1994



    Mailing Lists.", RFC 1211, USC/Information Sciences Institute, March
    1991.

[4] Klensin, J., Freed, N., Rose, M., Stefferud, E., Crocker., D.  "SMTP
    Service Extensions", RFC 1425, United Nations University, Innosoft
    International, Inc., Dover Beach Consulting, Inc., Network
    Management Associates, Inc., The Branch Office, February 1993.

[5] Moore, K.  "MIME Content-Types For Delivery Status Notifications",
    Internet-Draft "draft-moore-mime-delivery-01.txt", 21 March 1994.


11. Author's address

Keith Moore
University of Tennessee
107 Ayres Hall
Knoxville, TN 37996-1301
USA

email: moore@cs.utk.edu

































K. Moore                Expires 21 September 1994              [Page 13]







SMTP Delivery Status Notifications                            March 1994



APPENDIX: Changes since draft-moore-smtp-drpt-00.txt

1. The NORET parameter of the RCPT command has been renamed to RET,
   and it has been generalized to allow the sender to request either that
   the message content should be, or should not be, returned.  (This
   should allow better gatewaying into the Internet from other mail
   systems.)

   However, the request to return contents or not is now merely a
   request, it is longer binding on the server.  (This simplifies
   handling in client SMTPs when talking to SMTPs that do not support
   this extension.)

2. The TAG parameter of the RCPT command has been removed.  The new
   ORCPT parameter of the RCPT command is now used to convey
   sender-specified recipient information.

3. The MSGID parameter of the MAIL command has been renamed to ENVID
   ("envelope ID") to prevent confusion with the Message-ID header field.
   The ENVID parameter is no longer constrained to match the syntax of an
   RFC 822 message-id.

4. The DRPT parameter of the RCPT command has been renamed to NOTIFY,
   and reworked slightly to allow the sender to also request that reports
   be issued only on successful delivery.  (This is to allow support for
   mail originating from environments where this is the expected
   behavior.)

5. The requirements for SMTP servers that support this extension have
   been rewritten in the form of a case-by-case specification, based on
   the action taken by the server in routing the message.

6. Clients are no longer required to issue "address changed"
   notifications when forwarding mail to servers which also support this
   extension.

7. Added "motivations" paragraph in the Introduction.

8. Extension named changed (from "Delivery Report") to "Delivery
   Status Notification"; EHLO keyword changed from DRPT to DSN.

8. This document has been updated to reflect the new version of
   the author's delivery-report format proposal [5].











K. Moore                Expires 21 September 1994              [Page 14]










