From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1891.txt | 1739 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1739 insertions(+) create mode 100644 doc/rfc/rfc1891.txt (limited to 'doc/rfc/rfc1891.txt') diff --git a/doc/rfc/rfc1891.txt b/doc/rfc/rfc1891.txt new file mode 100644 index 0000000..23b58ba --- /dev/null +++ b/doc/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 + . Requests to subscribe to the mailing + list should be addressed to . + 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: RET=HDRS ENVID=QQ314159 +<<< 250 sender ok +>>> RCPT TO: NOTIFY=SUCCESS \ + ORCPT=rfc822;Bob@Big-Bucks.COM +<<< 250 recipient ok +>>> RCPT TO: NOTIFY=FAILURE \ + ORCPT=rfc822;Carol@Ivory.EDU +<<< 250 recipient ok +>>> RCPT TO: NOTIFY=SUCCESS,FAILURE \ + ORCPT=rfc822;Dana@Ivory.EDU +<<< 250 recipient ok + + + +Moore Standards Track [Page 23] + +RFC 1891 SMTP Delivery Status Notifications January 1996 + + +>>> RCPT TO: NOTIFY=FAILURE \ + ORCPT=rfc822;Eric@Bombs.AF.MIL +<<< 250 recipient ok +>>> RCPT TO: NOTIFY=NEVER +<<< 250 recipient ok +>>> RCPT TO: NOTIFY=FAILURE \ + ORCPT=rfc822;George@Tax-ME.GOV +<<< 250 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: RET=HDRS ENVID=QQ314159 +<<< 250 sender okay +>>> RCPT TO: 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: RET=HDRS ENVID=QQ314159 +<<< 250 ok +>>> RCPT TO: NOTIFY=FAILURE \ + ORCPT=rfc822;Carol@Ivory.EDU +<<< 550 error - no such recipient +>>> RCPT TO: 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: +<<< 250 ok +>>> RCPT TO: +<<< 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: +<<< 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: RET=HDRS ENVID=QQ314159 +<<< 250 sender okay +>>> RCPT TO: 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: 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] + -- cgit v1.2.3