Add files from ESR's dev directory that weren't under version control

svn path=/trunk/; revision=3881

1 files changed, 1739 insertions, 0 deletions

diff --git a/RFC/rfc1891.txt b/RFC/rfc1891.txt
new file mode 100644
index 00000000..23b58ba9
--- /dev/null
+++ b/RFC/rfc1891.txt
@@ -0,0 +1,1739 @@
+
+
+
+
+
+
+Network Working Group                                           K. Moore
+Request for Comments: 1891                       University of Tennessee
+Category: Standards Track                                   January 1996
+
+
+                         SMTP Service Extension
+                   for Delivery Status Notifications
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+1. Abstract
+
+   This memo defines an extension to the SMTP service, which allows 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(s) for which the DSN was
+   issued, and the transaction in which the original message was sent.
+
+   Any questions, comments, and reports of defects or ambiguities in
+   this specification may be sent to the mailing list for the NOTARY
+   working group of the IETF, using the address
+   <notifications@cs.utk.edu>.  Requests to subscribe to the mailing
+   list should be addressed to <notifications-request@cs.utk.edu>.
+   Implementors of this specification are encouraged to subscribe to the
+   mailing list, so that they will quickly be informed of any problems
+   which might hinder interoperability.
+
+   NOTE: This document is a Proposed Standard.  If and when this
+   protocol is submitted for Draft Standard status, any normative text
+   (phrases containing SHOULD, SHOULD NOT, MUST, MUST NOT, or MAY) in
+   this document will be re-evaluated in light of implementation
+   experience, and are thus subject to change.
+
+2. 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
+
+
+
+Moore                       Standards Track                     [Page 1]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+   the SMTP MAIL command), containing an explanation of the error and at
+   least the headers of the failed message.
+
+   Experience 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 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) when both success and failure notifications are requested,
+    provides an unambiguous and nonconflicting indication of whether
+    delivery of a message to a recipient succeeded or failed,
+
+(c) is stable, in that a failed attempt to deliver a DSN should never
+    result in the transmission of another DSN over the network,
+
+(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 delivery notifications, negative delivery notifications,
+    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].
+
+
+
+
+
+
+
+
+Moore                       Standards Track                     [Page 2]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+3. 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 4 of this memo;
+
+(3) no parameters are allowed with this EHLO keyword value;
+
+(4) two optional parameters are added to the RCPT command, and two
+    optional parameters are added to the MAIL command:
+
+    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 5.1,
+
+    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 5.2,
+    and
+
+    An optional parameter for the MAIL command, using the
+    esmtp-keyword "RET", (to request that DSNs containing an
+    indication of delivery failure either return the entire contents
+    of a message or only the message headers), is defined in section
+    5.3,
+
+    An optional parameter for the MAIL command, using the
+    esmtp-keyword "ENVID", (used to propagate an identifier for this
+    message transmission envelope, which is also known to the sender
+    and will, if present, be returned in any DSNs issued for this
+    transmission), is defined in section 5.4;
+
+(5) no additional SMTP verbs are defined by this extension.
+
+   The remainder of this memo specifies how support for the extension
+   effects the behavior of a message transfer agent.
+
+4.  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
+
+
+
+Moore                       Standards Track                     [Page 3]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+   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 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)
+   whether the entire contents of the original message should be
+   returned (as opposed to just the headers of that message), 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
+   extension will attempt to propagate the following information to any
+   other MTAs that are used to relay the message, for use in generating
+   DSNs:
+
+(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, if a message was originally addressed
+    to A@B.C and later forwarded to A@D.E, after such forwarding has
+    taken place, the RCPT command will specify a mailbox of A@D.E.
+    However, the original recipient address remains A@B.C.
+
+    Also, if the message originated from an environment which does not
+    use Internet-style user@domain addresses, and was gatewayed into
+    SMTP, the original recipient address will preserve the original
+    form of the recipient address.
+
+(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.
+
+
+
+
+Moore                       Standards Track                     [Page 4]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+5.  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].
+
+   NOTE: Although RFC 822 ABNF is used to describe the syntax of these
+   parameters, they are not, in the language of that document,
+   "structured field bodies".  Therefore, while parentheses MAY appear
+   within an emstp-value, they are not recognized as comment delimiters.
+
+   The syntax for "esmtp-value" in [4] does not allow SP, "=", control
+   characters, or characters outside the traditional ASCII range of 1-
+   127 decimal to be transmitted in an esmtp-value.  Because the ENVID
+   and ORCPT parameters may need to convey values outside this range,
+   the esmtp-values for these parameters are encoded as "xtext".
+   "xtext" is formally defined as follows:
+
+     xtext = *( xchar / hexchar )
+
+     xchar = any ASCII CHAR between "!" (33) and "~" (126) inclusive,
+          except for "+" and "=".
+
+; "hexchar"s are intended to encode octets that cannot appear
+; as ASCII characters within an esmtp-value.
+
+     hexchar = ASCII "+" immediately followed by two upper case
+          hexadecimal digits
+
+When encoding an octet sequence as xtext:
+
++ Any ASCII CHAR between "!" and "~" inclusive, except for "+" and "=",
+  MAY be encoded as itself.  (A CHAR in this range MAY instead be
+  encoded as a "hexchar", at the implementor's discretion.)
+
++ ASCII CHARs that fall outside the range above must be encoded as
+  "hexchar".
+
+5.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,
+
+
+
+Moore                       Standards Track                     [Page 5]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+   formatted according to the following rules, using the ABNF of RFC
+   822:
+
+     notify-esmtp-value = "NEVER" / 1#notify-list-element
+
+     notify-list-element = "SUCCESS" / "FAILURE" / "DELAY"
+
+Notes:
+
+a. Multiple notify-list-elements, separated by commas, MAY appear in a
+   NOTIFY parameter; however, the NEVER keyword MUST appear by itself.
+
+b. Any of the keywords NEVER, SUCCESS, FAILURE, or DELAY may be spelled
+   in any combination of upper and lower case letters.
+
+The meaning of the NOTIFY parameter values is generally as follows:
+
++ A NOTIFY parameter value of "NEVER" requests that a DSN not be
+  returned to the sender under any conditions.
+
++ A NOTIFY parameter value containing the "SUCCESS" or "FAILURE"
+  keywords requests that a DSN be issued on successful delivery or
+  delivery failure, respectively.
+
++ A NOTIFY parameter value containing the keyword "DELAY" indicates the
+  sender's willingness to receive "delayed" DSNs.  Delayed DSNs may be
+  issued if delivery of a message has been delayed for an unusual amount
+  of time (as determined by the MTA at which the message is delayed),
+  but the final delivery status (whether successful or failure) cannot
+  be determined.  The absence of the DELAY keyword in a NOTIFY parameter
+  requests that a "delayed" DSN NOT be issued under any conditions.
+
+   The actual rules governing interpretation of the NOTIFY parameter are
+   given in section 6.
+
+   For compatibility with SMTP clients that do not use the NOTIFY
+   facility, the absence of a NOTIFY parameter in a RCPT command may be
+   interpreted as either NOTIFY=FAILURE or NOTIFY=FAILURE,DELAY.
+
+5.2 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.
+   The ABNF for the ORCPT parameter is:
+
+
+
+
+Moore                       Standards Track                     [Page 6]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+     orcpt-parameter = "ORCPT=" original-recipient-address
+
+     original-recipient-address = addr-type ";" xtext
+
+     addr-type = atom
+
+   The "addr-type" portion MUST be an IANA-registered electronic mail
+   address-type (as defined in [5]), while the "xtext" portion contains
+   an encoded representation of the original recipient address using the
+   rules in section 5 of this document.  The entire ORCPT parameter MAY
+   be up to 500 characters in length.
+
+   When initially submitting a message via SMTP, if the ORCPT parameter
+   is used, it MUST contain the same address as the RCPT TO address
+   (unlike the RCPT TO address, the ORCPT parameter will be encoded as
+   xtext).  Likewise, when a mailing list submits a message via SMTP to
+   be distributed to the list subscribers, if ORCPT is used, the ORCPT
+   parameter MUST match the new RCPT TO address of each recipient, not
+   the address specified by the original sender of the message.)
+
+   The "addr-type" portion of the original-recipient-address is used to
+   indicate the "type" of the address which appears in the ORCPT
+   parameter value.  However, the address associated with the ORCPT
+   keyword is NOT constrained to conform to the syntax rules for that
+   "addr-type".
+
+   Ideally, the "xtext" portion of the original-recipient-address 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
+   representation of recipient address must be defined by a
+   specification for gatewaying between DSNs and that environment.
+
+5.3 The RET parameter of the ESMTP MAIL command
+
+   The RET esmtp-keyword on the extended MAIL command specifies whether
+   or not the message should be included in any failed DSN issued for
+   this message transmission.  If the RET esmtp-keyword is used, it MUST
+   have an associated esmtp-value, which is one of the following
+   keywords:
+
+   FULL  requests that the entire message be returned in any "failed"
+         delivery status notification issued for this recipient.
+
+   HDRS  requests that only the headers of the message be returned.
+
+
+
+
+
+Moore                       Standards Track                     [Page 7]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+   The FULL and HDRS keywords may be spelled in any combination of upper
+   and lower case letters.
+
+   If no RET parameter is supplied, the MTA MAY return either the
+   headers of the message or the entire message for any DSN containing
+   indication of failed deliveries.
+
+   Note that the RET parameter only applies to DSNs that indicate
+   delivery failure for at least one recipient.  If a DSN contains no
+   indications of delivery failure, only the headers of the message
+   should be returned.
+
+5.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 ABNF for the ENVID parameter is:
+
+     envid-parameter = "ENVID=" xtext
+
+   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.  The
+   ENVID parameter MAY be up to 100 characters in length.
+
+5.5 Restrictions on the use of Delivery Status Notification parameters
+
+   The RET and ENVID parameters MUST NOT appear more than once each in
+   any single MAIL command.  If more than one of either of these
+   parameters appears in a MAIL command, the ESMTP server SHOULD respond
+   with "501 syntax error in parameters or arguments".
+
+   The NOTIFY and ORCPT parameters MUST NOT appear more than once in any
+   RCPT command.  If more than one of either of these parameters appears
+   in a RCPT command, the ESMTP server SHOULD respond with "501 syntax
+   error in parameters or arguments".
+
+6. Conformance requirements
+
+   The Simple Mail Transfer Protocol (SMTP) is used by Message Transfer
+   Agents (MTAs) when accepting, relaying, or gatewaying mail, as well
+   as User Agents (UAs) when submitting mail to the mail transport
+
+
+
+Moore                       Standards Track                     [Page 8]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+   system.  The DSN extension to SMTP may be used to allow UAs to convey
+   the sender's requests as to when DSNs should be issued.  A UA which
+   claims to conform to this specification must meet certain
+   requirements as described below.
+
+   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, when acting as an SMTP server, issues the DSN keyword in
+   response to the EHLO command, MUST obey the rules below for a
+   "conforming SMTP client" when acting as a client, and a "conforming
+   SMTP server" when acting as a server.  The term "conforming MTA"
+   refers to an MTA which conforms to this specification, independent of
+   its role of client or server.
+
+6.1 SMTP protocol interactions
+
+   The following rules apply to SMTP transactions in which any of the
+   ENVID, NOTIFY, RET, or ORCPT keywords are used:
+
+(a) If an SMTP client issues a MAIL command containing a valid ENVID
+    parameter and associated esmtp-value and/or a valid RET parameter
+    and associated esmtp-value, a conforming SMTP server MUST return
+    the same reply-code as it would to the same MAIL command without
+    the ENVID and/or RET parameters.  A conforming SMTP server MUST
+    NOT refuse a MAIL command based on the absence or presence of
+    valid ENVID or RET parameters, or on their associated
+    esmtp-values.
+
+    However, if the associated esmtp-value is not valid (i.e. contains
+    illegal characters), or if there is more than one ENVID or RET
+    parameter in a particular MAIL command, the server MUST issue the
+    reply-code 501 with an appropriate message (e.g.  "syntax error in
+    parameter").
+
+(b) If an SMTP client issues a RCPT command containing any valid
+    NOTIFY and/or ORCPT parameters, a conforming SMTP server MUST
+    return the same response as it would to the same RCPT command
+    without those NOTIFY and/or ORCPT parameters.  A conforming SMTP
+    server MUST NOT refuse a RCPT command based on the presence or
+    absence of any of these parameters.
+
+    However, if any of the associated esmtp-values 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".
+
+
+
+
+Moore                       Standards Track                     [Page 9]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+6.2 Handling of messages received via SMTP
+
+   This section describes how a conforming MTA should handle any
+   messages received via SMTP.
+
+   NOTE: A DSN MUST NOT be returned to the sender for any message for
+   which the return address from the SMTP MAIL command was NULL ("<>"),
+   even if the sender's address is available from other sources (e.g.
+   the message header).  However, the MTA which would otherwise issue a
+   DSN SHOULD inform the local postmaster of delivery failures through
+   some appropriate mechanism that will not itself result in the
+   generation of DSNs.
+
+   DISCUSSION: RFC 1123, section 2.3.3 requires error notifications to
+   be sent with a NULL return address ("reverse-path").  This creates an
+   interesting situation when a message arrives with one or more
+   nonfunctional recipient addresses in addition to a nonfunctional
+   return address.  When delivery to one of the recipient addresses
+   fails, the MTA will attempt to send a nondelivery notification to the
+   return address, setting the return address on the notification to
+   NULL.  When the delivery of this notification fails, the MTA
+   attempting delivery of that notification sees a NULL return address.
+   If that MTA were not to inform anyone of the situation, the original
+   message would be silently lost.  Furthermore, a nonfunctional return
+   address is often indicative of a configuration problem in the
+   sender's MTA.  Reporting the condition to the local postmaster may
+   help to speed correction of such errors.
+
+6.2.1 Relay of messages to other conforming SMTP servers
+
+   The following rules govern the behavior of a conforming MTA, when
+   relaying a message which was received via the SMTP protocol, to an
+   SMTP server that supports the Delivery Status Notification service
+   extension:
+
+(a) Any ENVID parameter included in the MAIL command when a 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, the ENVID parameter MUST NOT be supplied when the
+    message is relayed.
+
+(b) Any RET parameter included in the MAIL command when a message was
+    received, MUST also appear on the MAIL command with which the
+    message is relayed, with the same associated esmtp-value.  If no RET
+    parameter was included in the MAIL command when the message was
+    received, the RET parameter MUST NOT supplied when the message is
+    relayed.
+
+
+
+Moore                       Standards Track                    [Page 10]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+(c) 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 the NOTIFY parameter was not supplied
+    for a recipient when the message was received, the NOTIFY parameter
+    MUST NOT be supplied for that recipient when the message is relayed.
+
+(d) If any ORCPT parameter was present in the RCPT command for a
+    recipient when the message was received, an ORCPT parameter with the
+    identical original-recipient-address MUST appear in the RCPT command
+    issued for that recipient when relaying the message.  (For example,
+    the MTA therefore MUST NOT change the case of any alphabetic
+    characters in an ORCPT parameter.)
+
+    If no ORCPT parameter was present in the RCPT command when the
+    message was received, an ORCPT parameter MAY be added to the RCPT
+    command when the message is relayed.  If an ORCPT parameter is added
+    by the relaying MTA, it MUST contain the recipient address from the
+    RCPT command used when the message was received by that MTA.
+
+6.2.2  Relay of messages to non-conforming SMTP servers
+
+   The following rules govern the behavior of a conforming MTA (in the
+   role of 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:
+
+(a) ENVID, NOTIFY, RET, or ORCPT parameters MUST NOT be issued when
+    relaying the message.
+
+(b) If the NOTIFY parameter was supplied for a recipient, with an esmtp-
+    value containing the keyword 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.
+
+(c) If the NOTIFY parameter was supplied for a recipient with an esmtp-
+    value containing the keyword 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.
+
+(d) If the NOTIFY parameter was supplied for a recipient with an esmtp-
+    value of NEVER, the client MUST NOT issue a DSN for that recipient,
+    regardless of the reply-code returned by the SMTP server.  However,
+    if the server returned a failure (5xx) reply-code, the client MAY
+    inform the local postmaster of the delivery failure via an
+    appropriate mechanism that will not itself result in the generation
+    of DSNs.
+
+
+
+
+Moore                       Standards Track                    [Page 11]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+    When attempting to relay a message to an SMTP server that does not
+    support this extension, and if NOTIFY=NEVER was specified for some
+    recipients of that message, a conforming SMTP client MAY relay the
+    message for those recipients in a separate SMTP transaction, using
+    an empty reverse-path in the MAIL command.  This will prevent DSNs
+    from being issued for those recipients by MTAs that conform to [1].
+
+(e) If a NOTIFY parameter was not supplied for a recipient, and the SMTP
+    server returns a success (2xx) reply-code in response to a RCPT
+    command, the client MUST NOT issue any DSN for that recipient.
+
+(f) If a NOTIFY parameter was not 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.
+
+6.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:
+
+   "Delivery" means that the message has been placed in the recipient's
+   mailbox.  For messages which are transmitted to a mailbox for later
+   retrieval via IMAP [6], POP [7] or a similar message access protocol,
+   "delivery" occurs when the message is made available to the IMAP
+   (POP, etc.) service, rather than when the message is retrieved by the
+   recipient's user agent.
+
+   Similarly, for a recipient address which corresponds to a mailing
+   list exploder, "delivery" occurs when the message is made available
+   to that list exploder, even though the list exploder might refuse to
+   deliver that message to the list recipients.
+
+(a) If the NOTIFY parameter was supplied for that recipient, with an
+    esmtp-value containing the SUCCESS keyword, the MTA MUST issue a
+    "delivered" DSN for that recipient.
+
+(b) If the NOTIFY parameter was supplied for that recipient which did
+    not contain the SUCCESS keyword, the MTA MUST NOT issue a DSN for
+    that recipient.
+
+(c) If the NOTIFY parameter was not supplied for that recipient, the MTA
+    MUST NOT issue a DSN.
+
+
+
+
+
+
+
+Moore                       Standards Track                    [Page 12]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+6.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:
+
+(a) 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.
+
+(b) If a NOTIFY parameter was supplied with the SUCCESS keyword, but the
+    destination environment cannot return an appropriate notification on
+    successful delivery, the MTA SHOULD issue a "relayed" DSN for that
+    recipient.
+
+(c) If a NOTIFY parameter was supplied with an esmtp-keyword of NEVER, a
+    DSN MUST NOT be issued.  If possible, the MTA SHOULD direct the
+    destination environment to not issue delivery notifications for that
+    recipient.
+
+(d) If the NOTIFY parameter was not supplied for a particular recipient,
+    a DSN SHOULD NOT be issued by the gateway. The gateway SHOULD
+    attempt to ensure that appropriate notification will be provided by
+    the foreign mail environment if eventual delivery failure occurs,
+    and that no notification will be issued on successful delivery.
+
+(e) 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.
+
+6.2.5  Delays in delivery
+
+   If a conforming MTA receives a message via the SMTP protocol, and is
+   unable to deliver or relay the message to one or more recipients for
+   an extended length of time (to be determined by the MTA), it MAY
+   issue a "delayed" DSN for those recipients, subject to the following
+   conditions:
+
+(a) If the NOTIFY parameter was supplied for a recipient and its value
+    included the DELAY keyword, a "delayed" DSN MAY be issued.
+
+(b) If the NOTIFY parameter was not supplied for a recipient, a
+    "delayed" DSN MAY be issued.
+
+
+
+Moore                       Standards Track                    [Page 13]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+(c) If the NOTIFY parameter was supplied which did not contain the DELAY
+    keyword, a "delayed" DSN MUST NOT be issued.
+
+   NOTE: Although delay notifications are common in present-day
+   electronic mail, a conforming MTA is never required to issue
+   "delayed" DSNs.  The DELAY keyword of the NOTIFY parameter is
+   provided to allow the SMTP client to specifically request (by
+   omitting the DELAY parameter) that "delayed" DSNs NOT be issued.
+
+6.2.6  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:
+
+(a) If a NOTIFY parameter was supplied for the recipient with an esmtp-
+    keyword containing the value FAILURE, a "failed" DSN MUST be issued
+    by the MTA.
+
+(b) If a NOTIFY parameter was supplied for the recipient which did not
+    contain the value FAILURE, a DSN MUST NOT be issued for that
+    recipient.  However, the MTA MAY inform the local postmaster of the
+    delivery failure via some appropriate mechanism which does not
+    itself result in the generation of DSNs.
+
+(c) If no NOTIFY parameter was supplied for the recipient, a "failed"
+    DSN MUST be issued.
+
+   NOTE: Some MTAs are known to forward undeliverable messages to the
+   local postmaster or "dead letter" mailbox.  This is still considered
+   delivery failure, and does not diminish the requirement to issue a
+   "failed" DSN under the conditions defined elsewhere in this memo.  If
+   a DSN is issued for such a recipient, the Action value MUST be
+   "failed".
+
+6.2.7 Forwarding, aliases, and mailing lists
+
+   Delivery of a message to a local email address usually causes the
+   message to be stored in the recipient's mailbox.  However, MTAs
+   commonly provide a facility where a local email address can be
+   designated as an "alias" or "mailing list"; delivery to that address
+   then causes the message to be forwarded to each of the (local or
+   remote) recipient addresses associated with the alias or list.  It is
+   also common to allow a user to optionally "forward" her mail to one
+   or more alternate addresses.  If this feature is enabled, her mail is
+   redistributed to those addresses instead of being deposited in her
+   mailbox.
+
+
+
+
+Moore                       Standards Track                    [Page 14]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+   Following the example of [9] (section 5.3.6), this document defines
+   the difference between an "alias" and "mailing list" as follows: When
+   forwarding a message to the addresses associated with an "alias", the
+   envelope return address (e.g. SMTP MAIL FROM) remains intact.
+   However, when forwarding a message to the addresses associated with a
+   "mailing list", the envelope return address is changed to that of the
+   administrator of the mailing list.  This causes DSNs and other
+   nondelivery reports resulting from delivery to the list members to be
+   sent to the list administrator rather than the sender of the original
+   message.
+
+   The DSN processing for aliases and mailing lists is as follows:
+
+6.2.7.1 mailing lists
+
+   When a message is delivered to a list submission address (i.e. placed
+   in the list's mailbox for incoming mail, or accepted by the process
+   that redistributes the message to the list subscribers), this is
+   considered final delivery for the original message.  If the NOTIFY
+   parameter for the list submission address contained the SUCCESS
+   keyword, a "delivered" DSN MUST be returned to the sender of the
+   original message.
+
+   NOTE: Some mailing lists are able to reject message submissions,
+   based on the content of the message, the sender's address, or some
+   other criteria.  While the interface between such a mailing list and
+   its MTA is not well-defined, it is important that DSNs NOT be issued
+   by both the MTA (to report successful delivery to the list), and the
+   list (to report message rejection using a "failure" DSN.)
+
+   However, even if a "delivered" DSN was issued by the MTA, a mailing
+   list which rejects a message submission MAY notify the sender that
+   the message was rejected using an ordinary message instead of a DSN.
+
+   Whenever a message is redistributed to an mailing list,
+
+(a) The envelope return address is rewritten to point to the list
+    maintainer.  This address MAY be that of a process that recognizes
+    DSNs and processes them automatically, but it MUST forward
+    unrecognized messages to the human responsible for the list.
+
+(b) The ENVID, NOTIFY, RET, and ORCPT parameters which accompany the
+    redistributed message MUST NOT be derived from those of the original
+    message.
+
+(c) The NOTIFY and RET parameters MAY be specified by the local
+    postmaster or the list administrator.  If ORCPT parameters are
+    supplied during redistribution to the list subscribers, they SHOULD
+
+
+
+Moore                       Standards Track                    [Page 15]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+    contain the addresses of the list subscribers in the format used by
+    the mailing list.
+
+6.2.7.2 single-recipient aliases
+
+   Under normal circumstances, when a message arrives for an "alias"
+   which has a single forwarding address, a DSN SHOULD NOT be issued.
+   Any ENVID, NOTIFY, RET, or ORCPT parameters SHOULD be propagated with
+   the message as it is redistributed to the forwarding address.
+
+6.2.7.3 multiple-recipient aliases
+
+   An "alias" with multiple recipient addresses may be handled in any of
+   the following ways:
+
+(a) Any ENVID, NOTIFY, RET, or ORCPT parameters are NOT propagated when
+    relaying the message to any of the forwarding addresses.  If the
+    NOTIFY parameter for the alias contained the SUCCESS keyword, the
+    MTA issues a "relayed" DSN.  (In effect, the MTA treats the message
+    as if it were being relayed into an environment that does not
+    support DSNs.)
+
+(b) Any ENVID, NOTIFY, RET, or ORCPT parameters (or the equivalent
+    requests if the message is gatewayed) are propagated to EXACTLY one
+    of the forwarding addresses.  No DSN is issued.  (This is
+    appropriate when aliasing is used to forward a message to a
+    "vacation" auto-responder program in addition to the local mailbox.)
+
+(c) Any ENVID, RET, or ORCPT parameters are propagated to all forwarding
+    addresses associated with that alias.  The NOTIFY parameter is
+    propagated to the forwarding addresses, except that it any SUCCESS
+    keyword is removed.  If the original NOTIFY parameter for the alias
+    contained the SUCCESS keyword, an "expanded" DSN is issued for the
+    alias.  If the NOTIFY parameter for the alias did not contain the
+    SUCCESS keyword, no DSN is issued for the alias.
+
+6.2.7.4 confidential forwarding addresses
+
+   If it is desired to maintain the confidentiality of a recipient's
+   forwarding address, the forwarding may be treated as if it were a
+   mailing list.  A DSN will be issued, if appropriate, upon "delivery"
+   to the recipient address specified by the sender.  When the message
+   is forwarded it will have a new envelope return address. Any DSNs
+   which result from delivery failure of the forwarded message will not
+   be returned to the original sender of the message and thus not expose
+   the recipient's forwarding address.
+
+
+
+
+
+Moore                       Standards Track                    [Page 16]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+6.2.8 DSNs describing delivery to multiple recipients
+
+   A single DSN may describe attempts to deliver a message to multiple
+   recipients of that message.  If a DSN is issued for some recipients
+   in an SMTP transaction and not for others according to the rules
+   above, the DSN SHOULD NOT contain information for recipients for whom
+   DSNs would not otherwise have been issued.
+
+6.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 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 message 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.
+
+6.4  Implementation limits
+
+   A conforming MTA MUST accept ESMTP parameters of at least the
+   following sizes:
+
+   (a) ENVID parameter: 100 characters.
+
+   (b) NOTIFY parameter: 28 characters.
+
+   (c) ORCPT parameter: 500 characters.
+
+   (d) RET parameter: 8 characters.
+
+   The maximum sizes for the ENVID and ORCPT parameters are intended to
+   be adequate for the transmission of "foreign" envelope identifier and
+   original recipient addresses.  However, user agents which use SMTP as
+   a message submission protocol SHOULD NOT generate ENVID parameters
+   which are longer than 38 characters in length.
+
+   A conforming MTA MUST be able to accept SMTP command-lines which are
+   at least 1036 characters long (530 characters for the ORCPT and
+   NOTIFY parameters of the RCPT command, in addition to the 512
+
+
+
+Moore                       Standards Track                    [Page 17]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+   characters required by [1]).  If other SMTP extensions are supported
+   by the MTA, the MTA MUST be able to accept a command-line large
+   enough for each SMTP command and any combination of ESMTP parameters
+   which may be used with that command.
+
+7.  Format of delivery notifications
+
+   The format of delivery status notifications is defined in [5], which
+   uses the framework defined in [8].  Delivery status notifications are
+   to be returned to the sender of the original message as outlined
+   below.
+
+7.1 SMTP Envelope to be used with delivery status notifications
+
+   The DSN sender address (in the SMTP MAIL command) MUST be a null
+   reverse-path ("<>"), as required by section 5.3.3 of [9].  The DSN
+   recipient address (in the RCPT command) is copied from the MAIL
+   command which accompanied the message for which the DSN is being
+   issued.  When transmitting a DSN via SMTP, the RET parameter MUST NOT
+   be used.  The NOTIFY parameter MAY be used, but its value MUST be
+   NEVER.  The ENVID parameter (with a newly generated envelope-id)
+   and/or ORCPT parameter MAY be used.
+
+7.2 Contents of the DSN
+
+   A DSN is transmitted as a MIME message with a top-level content-type
+   of multipart/report (as defined in [5]).
+
+   The multipart/report content-type may be used for any of several
+   kinds of reports generated by the mail system.  When multipart/report
+   is used to convey a DSN, the report-type parameter of the
+   multipart/report content-type is "delivery-status".
+
+   As described in [8], the first component of a multipart/report
+   content-type is a human readable explanation of the report.  For a
+   DSN, the second component of the multipart/report is of content-type
+   message/delivery-status (defined in [5]).  The third component of the
+   multipart/report consists of the original message or some portion
+   thereof.  When the value of the RET parameter is FULL, the full
+   message SHOULD be returned for any DSN which conveys notification of
+   delivery failure.  (However, if the length of the message is greater
+   than some implementation-specified length, the MTA MAY return only
+   the headers even if the RET parameter specified FULL.)  If a DSN
+   contains no notifications of delivery failure, the MTA SHOULD return
+   only the headers.
+
+   The third component must have an appropriate content-type label.
+   Issues concerning selection of the content-type are discussed in [8].
+
+
+
+Moore                       Standards Track                    [Page 18]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+7.3 Message/delivery-status fields
+
+   The message/delivery-status content-type defines a number of fields,
+   with general specifications for their contents.  The following
+   requirements for any DSNs generated in response to a message received
+   by the SMTP protocol by a conforming SMTP server, are in addition to
+   the requirements defined in [5] for the message/delivery-status type.
+
+   When generating a DSN for a message which was received via the SMTP
+   protocol, a conforming MTA will generate the following fields of the
+   message/delivery-status body part:
+
+(a) if an ENVID parameter was present on the MAIL command, an Original-
+    Envelope-ID field MUST be supplied, and the value associated with
+    the ENVID parameter must appear in that field.  If the message was
+    received via SMTP with no ENVID parameter, the Original-Envelope-ID
+    field MUST NOT be supplied.
+
+    Since the ENVID parameter is encoded as xtext, but the Original-
+    Envelope-ID header is NOT encoded as xtext, the MTA must decode the
+    xtext encoding when copying the ENVID value to the Original-
+    Envelope-ID field.
+
+(b) The Reporting-MTA field MUST be supplied.  If Reporting MTA can
+    determine its fully-qualified Internet domain name, the MTA-name-
+    type subfield MUST be "dns", and the field MUST contain the fully-
+    qualified domain name of the Reporting MTA. If the fully-qualified
+    Internet domain name of the Reporting MTA is not known (for example,
+    for an SMTP server which is not directly connected to the Internet),
+    the Reporting-MTA field may contain any string identifying the MTA,
+    however, in this case the MTA-name-type subfield MUST NOT be "dns".
+    A MTA-name-type subfield value of "x-local-hostname" is suggested.
+
+(c) Other per-message fields as defined in [5] MAY be supplied as
+    appropriate.
+
+(d) If the ORCPT parameter was provided for this recipient, the
+    Original-Recipient field MUST be supplied, with its value taken from
+    the ORCPT parameter.  If no ORCPT parameter was provided for this
+    recipient, the Original-Recipient field MUST NOT appear.
+
+(e) The Final-Recipient field MUST be supplied. It MUST contain the
+    recipient address from the message envelope.  If the message was
+    received via SMTP, the address-type will be "rfc822".
+
+(f) The Action field MUST be supplied.
+
+
+
+
+
+Moore                       Standards Track                    [Page 19]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+(g) The Status field MUST be supplied, using a status-code from [10].
+    If there is no specific code which suitably describes a delivery
+    failure, either 4.0.0 (temporary failure), or 5.0.0 (permanent
+    failure) MUST be used.
+
+(h) For DSNs resulting from attempts to relay a message to one or more
+    recipients via SMTP, the Remote-MTA field MUST be supplied for each
+    of those recipients.  The mta-name-type subfields of those Remote-
+    MTA fields will be "dns".
+
+(i) For DSNs resulting from attempts to relay a message to one or more
+    recipients via SMTP, the Diagnostic-Code MUST be supplied for each
+    of those recipients.  The diagnostic-type subfield will be "smtp".
+    See section 9.2(a) of this document for a description of the "smtp"
+    diagnostic-code.
+
+(j) For DSNs resulting from attempts to relay a message to one or more
+    recipients via SMTP, an SMTP-Remote-Recipient extension field MAY be
+    supplied for each recipient, which contains the address of that
+    recpient which was presented to the remote SMTP server.
+
+(k) Other per-recipient fields defined in [5] MAY appear, as
+    appropriate.
+
+8. Acknowledgments
+
+   The author wishes to thank Eric Allman, Harald Alvestrand, Jim
+   Conklin, Bryan Costales, Peter Cowen, Dave Crocker, Roger Fajman, Ned
+   Freed, Marko Kaittola, Steve Kille, John Klensin, Anastasios
+   Kotsikonas, John Gardiner Myers, Julian Onions, Jacob Palme, Marshall
+   Rose, Greg Vaudreuil, and Klaus Weide for their suggestions for
+   improvement of this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moore                       Standards Track                    [Page 20]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+9. Appendix - Type-Name Definitions
+
+   The following type names are defined for use in DSN fields generated
+   by conforming SMTP-based MTAs:
+
+9.1 "rfc822" address-type
+
+   The "rfc822" address-type is to be used when reporting Internet
+   electronic mail address in the Original-Recipient and Final-Recipient
+   DSN fields.
+
+(a) address-type name: rfc822
+
+(b) syntax for mailbox addresses
+
+    RFC822 mailbox addresses are generally expected to be of the form
+
+    [route] addr-spec
+
+    where "route" and "addr-spec" are defined in [2], and the "domain"
+    portions of both "route" and "addr-spec" are fully-qualified domain
+    names that are registered in the DNS.  However, an MTA MUST NOT
+    modify an address obtained from the message envelope to force it to
+    conform to syntax rules.
+
+(c) If addresses of this type are not composed entirely of graphic
+characters from the US-ASCII repertoire, a specification for how they
+are to be encoded as graphic US-ASCII characters in a DSN Original-
+Recipient or Final-Recipient DSN field.
+
+    RFC822 addresses consist entirely of graphic characters from the US-
+    ASCII repertoire, so no translation is necessary.
+
+9.2 "smtp" diagnostic-type
+
+   The "smtp" diagnostic-type is to be used when reporting SMTP reply-
+   codes in Diagnostic-Code DSN fields.
+
+(a) diagnostic-type name: SMTP
+
+(b) A description of the syntax to be used for expressing diagnostic
+codes of this type as graphic characters from the US-ASCII repertoire.
+
+    An SMTP diagnostic-code is of the form
+
+    *( 3*DIGIT "-" *text ) 3*DIGIT SPACE *text
+
+
+
+
+
+Moore                       Standards Track                    [Page 21]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+    For a single-line SMTP reply to an SMTP command, the diagnostic-code
+    SHOULD be an exact transcription of the reply.  For multi-line SMTP
+    replies, it is necessary to insert a SPACE before each line after
+    the first.  For example, an SMTP reply of:
+
+    550-mailbox unavailable
+    550 user has moved with no forwarding address
+
+    could appear as follows in a Diagnostic-Code DSN field:
+
+    Diagnostic-Code: smtp ; 550-mailbox unavailable
+     550 user has moved with no forwarding address
+
+(c) A list of valid diagnostic codes of this type and the meaning of
+each code.
+
+    SMTP reply-codes are currently defined in [1], [4], and [9].
+    Additional codes may be defined by other RFCs.
+
+9.3 "dns" MTA-name-type
+
+   The "dns" MTA-name-type should be used in the Reporting-MTA field.
+   An MTA-name of type "dns" is a fully-qualified domain name.  The name
+   must be registered in the DNS, and the address Postmaster@{mta-name}
+   must be valid.
+
+(a) MTA-name-type name: dns
+
+(b) A description of the syntax of MTA names of this type, using BNF,
+regular expressions, ASN.1, or other non-ambiguous language.
+
+    MTA names of type "dns" SHOULD be valid Internet domain names.  If
+    such domain names are not available, a domain-literal containing the
+    internet protocol address is acceptable.  Such domain names
+    generally conform to the following syntax:
+
+    domain = real-domain / domain-literal
+
+    real-domain = sub-domain *("." sub-domain)
+
+    sub-domain = atom
+
+    domain-literal = "[" 1*3DIGIT 3("." 1*3DIGIT) "]"
+
+    where "atom" and "DIGIT" are defined in [2].
+
+
+
+
+
+
+Moore                       Standards Track                    [Page 22]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+(c) If MTA names of this type do not consist entirely of graphic
+characters from the US-ASCII repertoire, a specification for how an MTA
+name of this type should be expressed as a sequence of graphic US-ASCII
+characters.
+
+    MTA names of type "dns" consist entirely of graphic US-ASCII
+    characters, so no translation is needed.
+
+10. Appendix - Example
+
+   This example traces the flow of a single message addressed to
+   multiple recipients.  The message is sent by Alice@Pure-Heart.ORG to
+   Bob@Big-Bucks.COM, Carol@Ivory.EDU, Dana@Ivory.EDU,
+   Eric@Bombs.AF.MIL, Fred@Bombs.AF.MIL, and George@Tax-ME.GOV, with a
+   variety of per-recipient options.  The message is successfully
+   delivered to Bob, Dana (via a gateway), Eric, and Fred.  Delivery
+   fails for Carol and George.
+
+   NOTE: Formatting rules for RFCs require that no line be longer than
+   72 characters.  Therefore, in the following examples, some SMTP
+   commands longer than 72 characters are printed on two lines, with the
+   first line ending in "\".  In an actual SMTP transaction, such a
+   command would be sent as a single line (i.e. with no embedded CRLFs),
+   and without the "\" character that appears in these examples.
+
+10.1 Submission
+
+   Alice's user agent sends the message to the SMTP server at Pure-
+   Heart.ORG.  Note that while this example uses SMTP as a mail
+   submission protocol, other protocols could also be used.
+
+<<< 220 Pure-Heart.ORG SMTP server here
+>>> EHLO Pure-Heart.ORG
+<<< 250-Pure-Heart.ORG
+<<< 250-DSN
+<<< 250-EXPN
+<<< 250 SIZE
+>>> MAIL FROM:<Alice@Pure-Heart.ORG> RET=HDRS ENVID=QQ314159
+<<< 250 <Alice@Pure-Heart.ORG> sender ok
+>>> RCPT TO:<Bob@Big-Bucks.COM> NOTIFY=SUCCESS \
+    ORCPT=rfc822;Bob@Big-Bucks.COM
+<<< 250 <Bob@Big-Bucks.COM> recipient ok
+>>> RCPT TO:<Carol@Ivory.EDU> NOTIFY=FAILURE \
+    ORCPT=rfc822;Carol@Ivory.EDU
+<<< 250 <Carol@Ivory.EDU> recipient ok
+>>> RCPT TO:<Dana@Ivory.EDU> NOTIFY=SUCCESS,FAILURE \
+    ORCPT=rfc822;Dana@Ivory.EDU
+<<< 250 <Dana@Ivory.EDU> recipient ok
+
+
+
+Moore                       Standards Track                    [Page 23]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+>>> RCPT TO:<Eric@Bombs.AF.MIL> NOTIFY=FAILURE \
+    ORCPT=rfc822;Eric@Bombs.AF.MIL
+<<< 250 <Eric@Bombs.AF.MIL> recipient ok
+>>> RCPT TO:<Fred@Bombs.AF.MIL> NOTIFY=NEVER
+<<< 250 <Fred@Bombs.AF.MIL> recipient ok
+>>> RCPT TO:<George@Tax-ME.GOV> NOTIFY=FAILURE \
+    ORCPT=rfc822;George@Tax-ME.GOV
+<<< 250 <George@Tax-ME.GOV> recipient ok
+>>> DATA
+<<< 354 okay, send message
+>>> (message goes here)
+>>> .
+<<< 250 message accepted
+>>> QUIT
+<<< 221 goodbye
+
+10.2 Relay to Big-Bucks.COM
+
+   The SMTP at Pure-Heart.ORG then relays the message to Big-Bucks.COM.
+   (For the purpose of this example, mail.Big-Bucks.COM is the primary
+   mail exchanger for Big-Bucks.COM).
+
+<<< 220 mail.Big-Bucks.COM says hello
+>>> EHLO Pure-Heart.ORG
+<<< 250-mail.Big-Bucks.COM
+<<< 250 DSN
+>>> MAIL FROM:<Alice@Pure-Heart.ORG> RET=HDRS ENVID=QQ314159
+<<< 250 sender okay
+>>> RCPT TO:<Bob@Big-Bucks.COM> NOTIFY=SUCCESS \
+    ORCPT=rfc822;Bob@Big-Bucks.COM
+<<< 250 recipient okay
+>>> DATA
+<<< 354 send message
+>>> (message goes here)
+>>> .
+<<< 250 message received
+>>> QUIT
+<<< 221 bcnu
+
+10.3 Relay to Ivory.EDU
+
+   The SMTP at Pure-Heart.ORG relays the message to Ivory.EDU, which (as
+   it happens) is a gateway to a LAN-based mail system that accepts SMTP
+   mail and supports the DSN extension.
+
+<<< 220 Ivory.EDU gateway to FooMail(tm) here
+>>> EHLO Pure-Heart.ORG
+<<< 250-Ivory.EDU
+
+
+
+Moore                       Standards Track                    [Page 24]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+<<< 250 DSN
+>>> MAIL FROM:<Alice@Pure-Heart.ORG> RET=HDRS ENVID=QQ314159
+<<< 250 ok
+>>> RCPT TO:<Carol@Ivory.EDU> NOTIFY=FAILURE \
+    ORCPT=rfc822;Carol@Ivory.EDU
+<<< 550 error - no such recipient
+>>> RCPT TO:<Dana@Ivory.EDU> NOTIFY=SUCCESS,FAILURE \
+    ORCPT=rfc822;Dana@Ivory.EDU
+<<< 250 recipient ok
+>>> DATA
+<<< 354 send message, end with '.'
+>>> (message goes here)
+>>> .
+<<< 250 message received
+>>> QUIT
+<<< 221 bye
+
+   Note that since the Ivory.EDU refused to accept mail for
+   Carol@Ivory.EDU, and the sender specified NOTIFY=FAILURE, the
+   sender-SMTP (in this case Pure-Heart.ORG) must generate a DSN.
+
+10.4 Relay to Bombs.AF.MIL
+
+   The SMTP at Pure-Heart.ORG relays the message to Bombs.AF.MIL, which
+   does not support the SMTP extension.  Because the sender specified
+   NOTIFY=NEVER for recipient Fred@Bombs.AF.MIL, the SMTP at Pure-
+   Heart.ORG chooses to send the message for that recipient in a
+   separate transaction with a reverse-path of <>.
+
+<<< 220-Bombs.AF.MIL reporting for duty.
+<<< 220 Electronic mail is to be used for official business only.
+>>> EHLO Pure-Heart.ORG
+<<< 502 command not implemented
+>>> RSET
+<<< 250 reset
+>>> HELO Pure-Heart.ORG
+<<< 250 Bombs.AF.MIL
+>>> MAIL FROM:<Alice@Pure-Heart.ORG>
+<<< 250 ok
+>>> RCPT TO:<Eric@Bombs.AF.MIL>
+<<< 250 ok
+>>> DATA
+<<< 354 send message
+>>> (message goes here)
+>>> .
+<<< 250 message accepted
+>>> MAIL FROM:<>
+<<< 250 ok
+
+
+
+Moore                       Standards Track                    [Page 25]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+>>> RCPT TO:<Fred@Bombs.AF.MIL>
+<<< 250 ok
+>>> DATA
+<<< 354 send message
+>>> (message goes here)
+>>> .
+<<< 250 message accepted
+>>> QUIT
+<<< 221 Bombs.AF.MIL closing connection
+
+10.5 Forward from George@Tax-ME.GOV to Sam@Boondoggle.GOV
+
+   The SMTP at Pure-Heart.ORG relays the message to Tax-ME.GOV.  (this
+   step is not shown).  MTA Tax-ME.GOV then forwards the message to
+   Sam@Boondoggle.GOV (shown below).  Both Tax-ME.GOV and Pure-Heart.ORG
+   support the SMTP DSN extension.  Note that RET, ENVID, and ORCPT all
+   retain their original values.
+
+<<< 220 BoonDoggle.GOV says hello
+>>> EHLO Pure-Heart.ORG
+<<< 250-mail.Big-Bucks.COM
+<<< 250 DSN
+>>> MAIL FROM:<Alice@Pure-Heart.ORG> RET=HDRS ENVID=QQ314159
+<<< 250 sender okay
+>>> RCPT TO:<Sam@Boondoggle.GOV> NOTIFY=SUCCESS \
+    ORCPT=rfc822;George@Tax-ME.GOV
+<<< 250 recipient okay
+>>> DATA
+<<< 354 send message
+>>> (message goes here)
+>>> .
+<<< 250 message received
+>>> QUIT
+<<< 221 bcnu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moore                       Standards Track                    [Page 26]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+10.6 "Delivered" DSN for Bob@Big-Bucks.COM
+
+   MTA mail.Big-Bucks.COM successfully delivers the message to Bob@Big-
+   Bucks.COM.  Because the sender specified NOTIFY=SUCCESS, mail.Big-
+   Bucks.COM issues the following DSN, and sends it to Alice@Pure-
+   Heart.ORG.
+
+To: Alice@Pure-Heart.ORG
+From: postmaster@mail.Big-Bucks.COM
+Subject: Delivery Notification (success) for Bob@Big-Bucks.COM
+Content-Type: multipart/report; report-type=delivery-status;
+    boundary=abcde
+MIME-Version: 1.0
+
+--abcde
+Content-type: text/plain; charset=us-ascii
+
+Your message (id QQ314159) was successfully delivered to
+Bob@Big-Bucks.COM.
+
+--abcde
+Content-type: message/delivery-status
+
+Reporting-MTA: dns; mail.Big-Bucks.COM
+Original-Envelope-ID: QQ314159
+
+Original-Recipient: rfc822;Bob@Big-Bucks.COM
+Final-Recipient: rfc822;Bob@Big-Bucks.COM
+Action: delivered
+Status: 2.0.0
+
+--abcde
+Content-type: message/rfc822
+
+(headers of returned message go here)
+
+--abcde--
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moore                       Standards Track                    [Page 27]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+10.7 Failed DSN for Carol@Ivory.EDU
+
+   Because delivery to Carol failed and the sender specified
+   NOTIFY=FAILURE for Carol@Ivory.EDU, MTA Pure-Heart.ORG (the SMTP
+   client to which the failure was reported via SMTP) issues the
+   following DSN.
+
+To: Alice@Pure-Heart.ORG
+From: postmaster@Pure-Heart.ORG
+Subject: Delivery Notification (failure) for Carol@Ivory.EDU
+Content-Type: multipart/report; report-type=delivery-status;
+              boundary=bcdef
+MIME-Version: 1.0
+
+--bcdef
+Content-type: text/plain; charset=us-ascii
+
+Your message (id QQ314159) could not be delivered to
+Carol@Ivory.EDU.
+
+A transcript of the session follows:
+
+(while talking to Ivory.EDU)
+>>> RCPT TO:<Carol@Ivory.EDU> NOTIFY=FAILURE
+<<< 550 error - no such recipient
+
+--bcdef
+Content-type: message/delivery-status
+
+Reporting-MTA: dns; Pure-Heart.ORG
+Original-Envelope-ID: QQ314159
+
+Original-Recipient: rfc822;Carol@Ivory.EDU
+Final-Recipient: rfc822;Carol@Ivory.EDU
+SMTP-Remote-Recipient: Carol@Ivory.EDU
+Diagnostic-Code: smtp; 550 error - no such recipient
+Action: failed
+Status: 5.0.0
+
+--bcdef
+Content-type: message/rfc822
+
+(headers of returned message go here)
+
+--bcdef--
+
+
+
+
+
+
+Moore                       Standards Track                    [Page 28]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+10.8 Relayed DSN For Dana@Ivory.EDU
+
+   Although the mail gateway Ivory.EDU supports the DSN SMTP extension,
+   the LAN mail system attached to its other side does not generate
+   positive delivery confirmations.  So Ivory.EDU issues a "relayed"
+   DSN:
+
+To: Alice@Pure-Heart.ORG
+From: postmaster@Ivory.EDU
+Subject: mail relayed for Dana@Ivory.EDU
+Content-Type: multipart/report; report-type=delivery-status;
+    boundary=cdefg
+MIME-Version: 1.0
+
+--cdefg
+Content-type: text/plain; charset=us-ascii
+
+Your message (addressed to Dana@Ivory.EDU) was successfully
+relayed to:
+
+ymail!Dana
+
+by the FooMail gateway at Ivory.EDU.
+
+Unfortunately, the remote mail system does not support
+confirmation of actual delivery.  Unless delivery to ymail!Dana
+fails, this will be the only delivery status notification sent.
+
+--cdefg
+Content-type: message/delivery-status
+
+Reporting-MTA: dns; Ivory.EDU
+Original-Envelope-ID: QQ314159
+
+Original-Recipient: rfc822;Dana@Ivory.EDU
+Final-Recipient: rfc822;Dana@Ivory.EDU
+Action: relayed
+Status: 2.0.0
+
+--cdefg
+Content-type: message/rfc822
+
+(headers of returned message go here)
+
+--cdefg--
+
+
+
+
+
+
+Moore                       Standards Track                    [Page 29]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+10.9 Failure notification for Sam@Boondoggle.GOV
+
+   The message originally addressed to George@Tax-ME.GOV was forwarded
+   to Sam@Boondoggle.GOV, but the MTA for Boondoggle.GOV was unable to
+   deliver the message due to a lack of disk space in Sam's mailbox.
+   After trying for several days, Boondoggle.GOV returned the following
+   DSN:
+
+To: Alice@BigHeart.ORG
+From: Postmaster@Boondoggle.GOV
+Subject: Delivery failure for Sam@Boondoggle.GOV
+Content-Type: multipart/report; report-type=delivery-status;
+              boundary=defgh
+MIME-Version: 1.0
+
+--defgh
+Your message, originally addressed to George@Tax-ME.GOV, and forwarded
+from there to Sam@Boondoggle.GOV could not be delivered, for the
+following reason:
+
+write error to mailbox, disk quota exceeded
+
+--defgh
+Content-type: message/delivery-status
+
+Reporting-MTA: Boondoggle.GOV
+Original-Envelope-ID: QQ314159
+
+Original-Recipient: rfc822;George@Tax-ME.GOV
+Final-Recipient: rfc822;Sam@Boondoggle.GOV
+Action: failed
+Status: 4.2.2 (disk quota exceeded)
+
+--defgh
+Content-type: message/rfc822
+
+(headers of returned message go here)
+
+--defgh--
+
+
+
+
+
+
+
+
+
+
+
+
+Moore                       Standards Track                    [Page 30]
+
+RFC 1891           SMTP Delivery Status Notifications       January 1996
+
+
+11. 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., and J. Postel, "Problems with the Maintenance of
+       Large Mailing Lists.", RFC 1211, USC/Information Sciences
+       Institute, March 1991.
+
+   [4] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker,
+       "SMTP Service Extensions", RFC 1651, MCI, Innosoft, Dover Beach
+       Consulting, Inc., Network Management Associates, Inc., Silicon
+       Graphics, Inc., July 1994.
+
+   [5] Moore, K., and G. Vaudreuil, "An Extensible Message Format for
+       Delivery Status Notifications", RFC 1894, University of Tennessee,
+       Octel Network Services, January 1996.
+
+   [6] Crispin, M., "Internet Message Access Protocol - Version 4", RFC
+       1730, University of Washington, 20 December 1994.
+
+   [7] Myers, J., and M. Rose, "Post Office Protocol - Version 3", RFC
+       1725, Carnegie Mellon, Dover Beach Consulting, November 1994.
+
+   [8] Vaudreuil, G., "The Multipart/Report Content Type for the
+       Reporting of Mail System Administrative Messages", RFC 1892, Octel
+       Network Services, January 1996.
+
+   [9] Braden, R., Editor, "Requirements for Internet Hosts - Application
+       and Support", STD 3, RFC 1123, IETF, October 1989.
+
+   [10] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893,
+        Octel Network Services, January 1996.
+
+12. Author's Address
+
+   Keith Moore
+   University of Tennessee
+   107 Ayres Hall
+   Knoxville, TN 37996-1301
+   USA
+
+   EMail: moore@cs.utk.edu
+
+
+
+
+
+Moore                       Standards Track                    [Page 31]
+