idnits 2.17.1 draft-ietf-notary-smtp-drpt-05.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 31 longer pages, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 200: '...hile parentheses MAY appear within an ...' RFC 2119 keyword, line 224: '... MAY be encoded as itself. (A CHAR i...' RFC 2119 keyword, line 235: '...used, it MUST have an associated esmtp...' RFC 2119 keyword, line 244: '..., separated by commas, MAY appear in a...' RFC 2119 keyword, line 245: '...he NEVER keyword MUST appear by itself...' (96 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (21 June 1995) is 10536 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 821 (ref. '1') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 822 (ref. '2') (Obsoleted by RFC 2822) ** Downref: Normative reference to an Informational RFC: RFC 1211 (ref. '3') ** Obsolete normative reference: RFC 1651 (ref. '4') (Obsoleted by RFC 1869) == Outdated reference: A later version (-06) exists of draft-ietf-notary-mime-delivery-05 ** Obsolete normative reference: RFC 1730 (ref. '6') (Obsoleted by RFC 2060, RFC 2061) ** Obsolete normative reference: RFC 1725 (ref. '7') (Obsoleted by RFC 1939) == Outdated reference: A later version (-05) exists of draft-ietf-notary-mime-report-04 -- Unexpected draft version: The latest known version of draft-ietf-notary-status is -03, but you're referring to -04. Summary: 18 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Keith Moore 2 Internet-Draft University of Tennessee 3 Expires: 21 December 1995 21 June 1995 5 SMTP Service Extension 6 for Delivery Status Notifications 8 draft-ietf-notary-smtp-drpt-05.txt 10 1. Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, and 14 its working groups. Note that other groups may also distribute working 15 documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is not appropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 To learn the current status of any Internet-Draft, please check the 23 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Any questions, comments, and reports of defects or ambiguities in 29 this specification may be sent to the mailing list for the NOTARY 30 working group of the IETF, using the address . 31 Requests to subscribe to the mailing list should be addressed to 32 . Implementors of this specification 33 are encouraged to subscribe to the mailing list, so that they will 34 quickly be informed of any problems which might hinder interoperability. 36 2. Abstract 38 This memo defines an extension to the SMTP service, which allows an 39 SMTP client to specify (a) that delivery status notifications (DSNs) 40 should be generated under certain conditions, (b) whether such 41 notifications should return the contents of the message, and (c) 42 additional information, to be returned with a DSN, that allows the 43 sender to identify both the recipient(s) for which the DSN was issued, 44 and the transaction in which the original message was sent. 46 3. Introduction 48 The SMTP protocol [1] requires that an SMTP server provide 49 notification of delivery failure, if it determines that a message cannot 50 be delivered to one or more recipients. Traditionally, such 51 notification consists of an ordinary Internet mail message (format 52 defined by [2]), sent to the envelope sender address (the argument of 53 the SMTP MAIL command), containing an explanation of the error and at 54 least the headers of the failed message. 56 Experience with large mail distribution lists [3] indicates that such 57 messages are often insufficient to diagnose problems, or even to 58 determine at which host or for which recipients a problem occurred. In 59 addition, the lack of a standardized format for delivery notifications 60 in Internet mail makes it difficult to exchange such notifications with 61 other message handling systems. 63 Such experience has demonstrated a need for a delivery status 64 notification service for Internet electronic mail, which: 66 (a) is reliable, in the sense that any DSN request will either be 67 honored at the time of final delivery, or result in a response that 68 indicates that the request cannot be honored, 70 (b) when both success and failure notifications are requested, provides 71 an unambiguous and nonconflicting indication of whether delivery of 72 a message to a recipient succeeded or failed, 74 (c) is stable, in that a failed attempt to deliver a DSN should never 75 result in the transmission of another DSN over the network, 77 (d) preserves sufficient information to allow the sender to identify 78 both the mail transaction and the recipient address which caused the 79 notification, even when mail is forwarded or gatewayed to foreign 80 environments, and 82 (e) interfaces acceptably with non-SMTP and non-822-based mail systems, 83 both so that notifications returned from foreign mail systems may be 84 useful to Internet users, and so that the notification requests from 85 foreign environments may be honored. Among the requirements implied 86 by this goal are the ability to request non-return-of-content, and 87 the ability to specify whether positive delivery notifications, 88 negative delivery notifications, both, or neither, should be issued. 90 In an attempt to provide such a service, this memo uses the mechanism 91 defined in [4] to define an extension to the SMTP protocol. Using this 92 mechanism, an SMTP client may request that an SMTP server issue or not 93 issue a delivery status notification (DSN) under certain conditions. 94 The format of a DSN is defined in [5]. 96 4. Framework for the Delivery Status Notification Extension 98 The following service extension is therefore defined: 100 (1) The name of the SMTP service extension is "Delivery Status 101 Notification"; 103 (2) the EHLO keyword value associated with this extension is "DSN", the 104 meaning of which is defined in section 5 of this memo; 106 (3) no parameters are allowed with this EHLO keyword value; 108 (4) two optional parameters are added to the RCPT command, and two 109 optional parameters are added to the MAIL command: 111 An optional parameter for the RCPT command, using the esmtp-keyword 112 "NOTIFY", (to specify the conditions under which a delivery status 113 notification should be generated), is defined in section 6.1, 115 An optional parameter for the RCPT command, using the esmtp-keyword 116 "ORCPT", (used to convey the "original" (sender-specified) recipient 117 address), is defined in section 6.2, and 119 An optional parameter for the MAIL command, using the esmtp-keyword 120 "RET", (to request that DSNs containing an indication of delivery 121 failure either return the entire contents of a message or only the 122 message headers), is defined in section 6.3, 124 An optional parameter for the MAIL command, using the esmtp-keyword 125 "ENVID", (used to propagate an identifier for this message 126 transmission envelope, which is also known to the sender and will, 127 if present, be returned in any DSNs issued for this transmission), 128 is defined in section 6.4; 130 (5) no additional SMTP verbs are defined by this extension. 132 The remainder of this memo specifies how support for the extension 133 affects the behavior of a message transfer agent. 135 5. The Delivery Status Notification service extension 137 An SMTP client wishing to request a DSN for a message may issue the 138 EHLO command to start an SMTP session, to determine if the server 139 supports any of several service extensions. If the server responds with 140 code 250 to the EHLO command, and the response includes the EHLO keyword 141 DSN, then the Delivery Status Notification extension (as described in 142 this memo) is supported. 144 Ordinarily, when an SMTP server returns a positive (2xx) reply code 145 in response to a RCPT command, it agrees to accept responsibility for 146 either delivering the message to the named recipient, or sending a 147 notification to the sender of the message indicating that delivery has 148 failed. However, an extended SMTP ("ESMTP") server which implements 149 this service extension will accept an optional NOTIFY parameter with the 150 RCPT command. If present, the NOTIFY parameter alters the conditions for 151 generation of delivery status notifications from the default (issue 152 notifications only on failure) specified in [1]. The ESMTP client may 153 also request (via the RET parameter) whether the entire contents of the 154 original message should be returned (as opposed to just the headers of 155 that message), along with the DSN. 157 In general, an ESMTP server which implements this service extension 158 will propagate delivery status notification requests when relaying mail 159 to other SMTP-based MTAs which also support this extension, and make a 160 "best effort" to ensure that such requests are honored when messages are 161 passed into other environments. 163 In order that any delivery status notifications thus generated will 164 be meaningful to the sender, any ESMTP server which supports this 165 extension will attempt to propagate the following information to any 166 other MTAs that are used to relay the message, for use in generating 167 DSNs: 169 (a) for each recipient, a copy of the original recipient address, as 170 used by the sender of the message. 172 This address need not be the same as the mailbox specified in the 173 RCPT command. For example, if a message was originally addressed to 174 A@B.C and later forwarded to A@D.E, after such forwarding has taken 175 place, the RCPT command will specify a mailbox of A@D.E. However, 176 the original recipient address remains A@B.C. 178 Also, if the message originated from an environment which does not 179 use Internet-style user@domain addresses, and was gatewayed into 180 SMTP, the original recipient address will preserve the original form 181 of the recipient address. 183 (b) for the entire SMTP transaction, an envelope identification string, 184 which may be used by the sender to associate any delivery status 185 notifications with the transaction used to send the original 186 message. 188 6. Additional parameters for RCPT and MAIL commands 190 The extended RCPT and MAIL commands are issued by a client when it 191 wishes to request a DSN from the server, under certain conditions, for a 192 particular recipient. The extended RCPT and MAIL commands are identical 193 to the RCPT and MAIL commands defined in [1], except that one or more of 194 the following parameters appear after the sender or recipient address, 195 respectively. The general syntax for extended SMTP commands is defined 196 in [4]. 198 NOTE: Although RFC 822 ABNF is used to describe the syntax of these 199 parameters, they are not, in the language of that document, "structured 200 field bodies". Therefore, while parentheses MAY appear within an emstp- 201 value, they are not recognized as comment delimiters. 203 The syntax for "esmtp-value" in [4] does not allow SP, "=", control 204 characters, or characters outside the traditional ASCII range of 1-127 205 decimal to be transmitted in an esmtp-value. Because the ENVID and 206 ORCPT parameters may need to convey values outside this range, the 207 esmtp-values for these parameters are encoded as "xtext". "xtext" is 208 formally defined as follows: 210 xtext = *( xchar / hexchar ) 212 xchar = any ASCII CHAR between "!" (33) and "~" (126) inclusive, 213 except for "+" and "=". 215 ; "hexchar"s are intended to encode octets that cannot appear 216 ; as ASCII characters within an esmtp-value. 218 hexchar = ASCII "+" immediately followed by two upper case 219 hexadecimal digits 221 When encoding an octet sequence as xtext: 223 + Any ASCII CHAR between "!" and "~" inclusive, except for "+" and "=", 224 MAY be encoded as itself. (A CHAR in this range MAY instead be 225 encoded as a "hexchar", at the implementor's discretion.) 227 + ASCII CHARs that fall outside the range above must be encoded as 228 "hexchar". 230 6.1 The NOTIFY parameter of the ESMTP RCPT command 232 A RCPT command issued by a client may contain the optional esmtp- 233 keyword "NOTIFY", to specify the conditions under which the SMTP server 234 should generate DSNs for that recipient. If the NOTIFY esmtp-keyword is 235 used, it MUST have an associated esmtp-value, formatted according to the 236 following rules, using the ABNF of RFC 822: 238 notify-esmtp-value = "NEVER" / 1#notify-list-element 240 notify-list-element = "SUCCESS" / "FAILURE" / "DELAY" 242 Notes: 244 a. Multiple notify-list-elements, separated by commas, MAY appear in a 245 NOTIFY parameter; however, the NEVER keyword MUST appear by itself. 247 b. Any of the keywords NEVER, SUCCESS, FAILURE, or DELAY may be spelled 248 in any combination of upper and lower case letters. 250 The meaning of the NOTIFY parameter values is generally as follows: 252 + A NOTIFY parameter value of "NEVER" requests that a DSN not be 253 returned to the sender under any conditions. 255 + A NOTIFY parameter value containing the "SUCCESS" or "FAILURE" 256 keywords requests that a DSN be issued on successful delivery or 257 delivery failure, respectively. 259 + A NOTIFY parameter value containing the keyword "DELAY" indicates the 260 sender's willingness to receive "delayed" DSNs. Delayed DSNs may be 261 issued if delivery of a message has been delayed for an unusual amount 262 of time (as determined by the MTA at which the message is delayed), 263 but the final delivery status (whether successful or failure) cannot 264 be determined. The absence of the DELAY keyword in a NOTIFY parameter 265 requests that a "delayed" DSN NOT be issued under any conditions. 267 The actual rules governing interpretation of the NOTIFY parameter are 268 given in section 7. 270 For compatibility with SMTP clients that do not use the NOTIFY facility, 271 the absence of a NOTIFY parameter in a RCPT command may be interpreted 272 as either NOTIFY=FAILURE or NOTIFY=FAILURE,DELAY. 274 6.2 The ORCPT parameter to the ESMTP RCPT command 276 The ORCPT esmtp-keyword of the RCPT command is used to specify an 277 "original" recipient address that corresponds to the actual recipient to 278 which the message is to be delivered. If the ORCPT esmtp-keyword is 279 used, it MUST have an associated esmtp-value, which consists of the 280 original recipient address, encoded according to the rules below. The 281 ABNF for the ORCPT parameter is: 283 orcpt-parameter = "ORCPT=" original-recipient-address 285 original-recipient-address = addr-type ";" xtext 287 addr-type = atom 289 The "addr-type" portion MUST be an IANA-registered electronic mail 290 address-type (as defined in [5]), while the "xtext" portion contains an 291 encoded representation of the original recipient address using the rules 292 in section 6 of this document. The entire ORCPT parameter MAY be up to 293 500 characters in length. 295 When initially submitting a message via SMTP, if the ORCPT parameter 296 is used, it MUST contain the same address as the RCPT TO address (unlike 297 the RCPT TO address, the ORCPT parameter will be encoded as xtext). 298 Likewise, when a mailing list submits a message via SMTP to be 299 distributed to the list subscribers, if ORCPT is used, the ORCPT 300 parameter MUST match the new RCPT TO address of each recipient, not the 301 address specified by the original sender of the message.) 302 The "addr-type" portion of the original-recipient-address is used to 303 indicate the "type" of the address which appears in the ORCPT parameter 304 value. However, the address associated with the ORCPT keyword is NOT 305 constrained to conform to the syntax rules for that "addr-type". 307 Ideally, the "xtext" portion of the original-recipient-address should 308 contain, in encoded form, the same sequence of characters that the 309 sender used to specify the recipient. However, for a message gatewayed 310 from an environment (such as X.400) in which a recipient address is not 311 a simple string of printable characters, the representation of recipient 312 address must be defined by a specification for gatewaying between DSNs 313 and that environment. 315 6.3 The RET parameter of the ESMTP MAIL command 317 The RET esmtp-keyword on the extended MAIL command specifies whether 318 or not the message should be included in any failed DSN issued for this 319 message transmission. If the RET esmtp-keyword is used, it MUST have an 320 associated esmtp-value, which is one of the following keywords: 322 FULL requests that the entire message be returned in any "failed" 323 delivery status notification issued for this recipient. 325 HDRS requests that only the headers of the message be returned. 327 The FULL and HDRS keywords may be spelled in any combination of upper 328 and lower case letters. 330 If no RET parameter is supplied, the MTA MAY return either the 331 headers of the message or the entire message for any DSN containing 332 indication of failed deliveries. 334 Note that the RET parameter only applies to DSNs that indicate 335 delivery failure for at least one recipient. If a DSN contains no 336 indications of delivery failure, only the headers of the message should 337 be returned. 339 6.4 The ENVID parameter to the ESMTP MAIL command 341 The ENVID esmtp-keyword of the SMTP MAIL command is used to specify 342 an "envelope identifier" to be transmitted along with the message and 343 included in any DSNs issued for any of the recipients named in this SMTP 344 transaction. The purpose of the envelope identifier is to allow the 345 sender of a message to identify the transaction for which the DSN was 346 issued. 348 The ABNF for the ENVID parameter is: 350 envid-parameter = "ENVID=" xtext 352 The ENVID esmtp-keyword MUST have an associated esmtp-value. No 353 meaning is assigned by the mail system to the presence or absence of 354 this parameter or to any esmtp-value associated with this parameter; the 355 information is used only by the sender or his user agent. The ENVID 356 parameter MAY be up to 100 characters in length. 358 6.5 Restrictions on the use of Delivery Status Notification parameters 360 The RET and ENVID parameters MUST NOT appear more than once each in 361 any single MAIL command. If more than one of either of these parameters 362 appears in a MAIL command, the ESMTP server SHOULD respond with "501 363 syntax error in parameters or arguments". 365 The NOTIFY and ORCPT parameters MUST NOT appear more than once in any 366 RCPT command. If more than one of either of these parameters appears in 367 a RCPT command, the ESMTP server SHOULD respond with "501 syntax error 368 in parameters or arguments". 370 7. Conformance requirements 372 The Simple Mail Transfer Protocol (SMTP) is used by Message Transfer 373 Agents (MTAs) when accepting, relaying, or gatewaying mail, as well as 374 User Agents (UAs) when submitting mail to the mail transport system. 375 The DSN extension to SMTP may be used to allow UAs to convey the 376 sender's requests as to when DSNs should be issued. A UA which claims 377 to conform to this specification must meet certain requirements as 378 described below. 380 Typically, a message transfer agent (MTA) which supports SMTP will 381 assume, at different times, both the role of a SMTP client and an SMTP 382 server, and may also provide local delivery, gatewaying to foreign 383 environments, forwarding, and mailing list expansion. An MTA which, 384 when acting as an SMTP server, issues the DSN keyword in response to the 385 EHLO command, MUST obey the rules below for a "conforming SMTP client" 386 when acting as a client, and a "conforming SMTP server" when acting as a 387 server. The term "conforming MTA" refers to an MTA which conforms to 388 this specification, independent of its role of client or server. 390 7.1 SMTP protocol interactions 392 The following rules apply to SMTP transactions in which any of the 393 ENVID, NOTIFY, RET, or ORCPT keywords are used: 395 (a) If an SMTP client issues a MAIL command containing a valid ENVID 396 parameter and associated esmtp-value and/or a valid RET parameter 397 and associated esmtp-value, a conforming SMTP server MUST return the 398 same reply-code as it would to the same MAIL command without the 399 ENVID and/or RET parameters. A conforming SMTP server MUST NOT 400 refuse a MAIL command based on the absence or presence of valid 401 ENVID or RET parameters, or on their associated esmtp-values. 403 However, if the associated esmtp-value is not valid (i.e. contains 404 illegal characters), or if there is more than one ENVID or RET 405 parameter in a particular MAIL command, the server MUST issue the 406 reply-code 501 with an appropriate message (e.g. "syntax error in 407 parameter"). 409 (b) If an SMTP client issues a RCPT command containing any valid NOTIFY 410 and/or ORCPT parameters, a conforming SMTP server MUST return the 411 same response as it would to the same RCPT command without those 412 NOTIFY and/or ORCPT parameters. A conforming SMTP server MUST NOT 413 refuse a RCPT command based on the presence or absence of any of 414 these parameters. 416 However, if any of the associated esmtp-values are not valid, or if 417 there is more than one of any of these parameters in a particular 418 RCPT command, the server SHOULD issue the response "501 syntax error 419 in parameter". 421 7.2 Handling of messages received via SMTP 423 This section describes how a conforming MTA should handle any 424 messages received via SMTP. 426 NOTE: A DSN MUST NOT be returned to the sender for any message for 427 which the return address from the SMTP MAIL command was NULL ("<>"), 428 even if the sender's address is available from other sources (e.g. the 429 message header). However, the MTA which would otherwise issue a DSN 430 SHOULD inform the local postmaster of delivery failures through some 431 appropriate mechanism that will not itself result in the generation of 432 DSNs. 434 DISCUSSION: RFC 1123, section 2.3.3 requires error notifications to 435 be sent with a NULL return address ("reverse-path"). This creates an 436 interesting situation when a message arrives with one or more 437 nonfunctional recipient addresses in addition to a nonfunctional return 438 address. When delivery to one of the recipient addresses fails, the MTA 439 will attempt to send a nondelivery notification to the return address, 440 setting the return address on the notification to NULL. When the 441 delivery of this notification fails, the MTA attempting delivery of that 442 notification sees a NULL return address. If that MTA were not to inform 443 anyone of the situation, the original message would be silently lost. 444 Furthermore, a nonfunctional return address is often indicative of a 445 configuration problem in the sender's MTA. Reporting the condition to 446 the local postmaster may help to speed correction of such errors. 448 7.2.1 Relay of messages to other conforming SMTP servers 450 The following rules govern the behavior of a conforming MTA, when 451 relaying a message which was received via the SMTP protocol, to an SMTP 452 server that supports the Delivery Status Notification service extension: 454 (a) Any ENVID parameter included in the MAIL command when a message was 455 received, MUST also appear on the MAIL command with which the 456 message is relayed, with the same associated esmtp-value. If no 457 ENVID parameter was included in the MAIL command when the message 458 was received, the ENVID parameter MUST NOT be supplied when the 459 message is relayed. 461 (b) Any RET parameter included in the MAIL command when a message was 462 received, MUST also appear on the MAIL command with which the 463 message is relayed, with the same associated esmtp-value. If no RET 464 parameter was included in the MAIL command when the message was 465 received, the RET parameter MUST NOT supplied when the message is 466 relayed. 468 (c) If the NOTIFY parameter was supplied for a recipient when the 469 message was received, the RCPT command issued when the message is 470 relayed MUST also contain the NOTIFY parameter along with its 471 associated esmtp-value. If the NOTIFY parameter was not supplied 472 for a recipient when the message was received, the NOTIFY parameter 473 MUST NOT be supplied for that recipient when the message is relayed. 475 (d) If any ORCPT parameter was present in the RCPT command for a 476 recipient when the message was received, an ORCPT parameter with the 477 identical original-recipient-address MUST appear in the RCPT command 478 issued for that recipient when relaying the message. (For example, 479 the MTA therefore MUST NOT change the case of any alphabetic 480 characters in an ORCPT parameter.) 482 If no ORCPT parameter was present in the RCPT command when the 483 message was received, an ORCPT parameter MAY be added to the RCPT 484 command when the message is relayed. If an ORCPT parameter is added 485 by the relaying MTA, it MUST contain the recipient address from the 486 RCPT command used when the message was received by that MTA. 488 7.2.2 Relay of messages to non-conforming SMTP servers 490 The following rules govern the behavior of a conforming MTA (in the 491 role of client), when relaying a message which was received via the SMTP 492 protocol, to an SMTP server that does not support the Delivery Status 493 Notification service extension: 495 (a) ENVID, NOTIFY, RET, or ORCPT parameters MUST NOT be issued when 496 relaying the message. 498 (b) If the NOTIFY parameter was supplied for a recipient, with an esmtp- 499 value containing the keyword SUCCESS, and the SMTP server returns a 500 success (2xx) reply-code in response to the RCPT command, the client 501 MUST issue a "relayed" DSN for that recipient. 503 (c) If the NOTIFY parameter was supplied for a recipient with an esmtp- 504 value containing the keyword FAILURE, and the SMTP server returns a 505 permanent failure (5xx) reply-code in response to the RCPT command, 506 the client MUST issue a "failed" DSN for that recipient. 508 (d) If the NOTIFY parameter was supplied for a recipient with an esmtp- 509 value of NEVER, the client MUST NOT issue a DSN for that recipient, 510 regardless of the reply-code returned by the SMTP server. However, 511 if the server returned a failure (5xx) reply-code, the client MAY 512 inform the local postmaster of the delivery failure via an 513 appropriate mechanism that will not itself result in the generation 514 of DSNs. 516 When attempting to relay a message to an SMTP server that does not 517 support this extension, and if NOTIFY=NEVER was specified for some 518 recipients of that message, a conforming SMTP client MAY relay the 519 message for those recipients in a separate SMTP transaction, using 520 an empty reverse-path in the MAIL command. This will prevent DSNs 521 from being issued for those recipients by MTAs that conform to [1]. 523 (e) If a NOTIFY parameter was not supplied for a recipient, and the SMTP 524 server returns a success (2xx) reply-code in response to a RCPT 525 command, the client MUST NOT issue any DSN for that recipient. 527 (f) If a NOTIFY parameter was not supplied for a recipient, and the SMTP 528 server returns a permanent failure (5xx) reply-code in response to a 529 RCPT command, the client MUST issue a "failed" DSN for that 530 recipient. 532 7.2.3 Local delivery of messages 534 The following rules govern the behavior of a conforming MTA upon 535 successful delivery of a message that was received via the SMTP 536 protocol, to a local recipient's mailbox: 538 "Delivery" means that the message has been placed in the recipient's 539 mailbox. For messages which are transmitted to a mailbox for later 540 retrieval via IMAP [6], POP [7] or a similar message access protocol, 541 "delivery" occurs when the message is made available to the IMAP (POP, 542 etc.) service, rather than when the message is retrieved by the 543 recipient's user agent. 545 Similarly, for a recipient address which corresponds to a mailing 546 list exploder, "delivery" occurs when the message is made available to 547 that list exploder, even though the list exploder might refuse to 548 deliver that message to the list recipients. 550 (a) If the NOTIFY parameter was supplied for that recipient, with an 551 esmtp-value containing the SUCCESS keyword, the MTA MUST issue a 552 "delivered" DSN for that recipient. 554 (b) If the NOTIFY parameter was supplied for that recipient which did 555 not contain the SUCCESS keyword, the MTA MUST NOT issue a DSN for 556 that recipient. 558 (c) If the NOTIFY parameter was not supplied for that recipient, the MTA 559 MUST NOT issue a DSN. 561 7.2.4 Gatewaying a message into a foreign environment 563 The following rules govern the behavior of a conforming MTA, when 564 gatewaying a message that was received via the SMTP protocol, into a 565 foreign (non-SMTP) environment: 567 (a) If the the foreign environment is capable of issuing appropriate 568 notifications under the conditions requested by the NOTIFY 569 parameter, and the conforming MTA can ensure that any notification 570 thus issued will be translated into a DSN and delivered to the 571 original sender, then the MTA SHOULD gateway the message into the 572 foreign environment, requesting notification under the desired 573 conditions, without itself issuing a DSN. 575 (b) If a NOTIFY parameter was supplied with the SUCCESS keyword, but the 576 destination environment cannot return an appropriate notification on 577 successful delivery, the MTA SHOULD issue a "relayed" DSN for that 578 recipient. 580 (c) If a NOTIFY parameter was supplied with an esmtp-keyword of NEVER, a 581 DSN MUST NOT be issued. If possible, the MTA SHOULD direct the 582 destination environment to not issue delivery notifications for that 583 recipient. 585 (d) If the NOTIFY parameter was not supplied for a particular recipient, 586 a DSN SHOULD NOT be issued by the gateway. The gateway SHOULD 587 attempt to ensure that appropriate notification will be provided by 588 the foreign mail environment if eventual delivery failure occurs, 589 and that no notification will be issued on successful delivery. 591 (e) When gatewaying a message into a foreign environment, the return-of- 592 content conditions specified by any RET parameter are nonbinding; 593 however, the MTA SHOULD attempt to honor the request using whatever 594 mechanisms exist in the foreign environment. 596 7.2.5 Delays in delivery 598 If a conforming MTA receives a message via the SMTP protocol, and is 599 unable to deliver or relay the message to one or more recipients for an 600 extended length of time (to be determined by the MTA), it MAY issue a 601 "delayed" DSN for those recipients, subject to the following conditions: 603 (a) If the NOTIFY parameter was supplied for a recipient and its value 604 included the DELAY keyword, a "delayed" DSN MAY be issued. 606 (b) If the NOTIFY parameter was not supplied for a recipient, a 607 "delayed" DSN MAY be issued. 609 (c) If the NOTIFY parameter was supplied which did not contain the DELAY 610 keyword, a "delayed" DSN MUST NOT be issued. 612 NOTE: Although delay notifications are common in present-day electronic 613 mail, a conforming MTA is never required to issue "delayed" DSNs. The 614 DELAY keyword of the NOTIFY parameter is provided to allow the SMTP 615 client to specifically request (by omitting the DELAY parameter) that 616 "delayed" DSNs NOT be issued. 618 7.2.6 Failure of a conforming MTA to deliver a message 620 The following rules govern the behavior of a conforming MTA which 621 received a message via the SMTP protocol, and is unable to deliver a 622 message to a recipient specified in the SMTP transaction: 624 (a) If a NOTIFY parameter was supplied for the recipient with an esmtp- 625 keyword containing the value FAILURE, a "failed" DSN MUST be issued 626 by the MTA. 628 (b) If a NOTIFY parameter was supplied for the recipient which did not 629 contain the value FAILURE, a DSN MUST NOT be issued for that 630 recipient. However, the MTA MAY inform the local postmaster of the 631 delivery failure via some appropriate mechanism which does not 632 itself result in the generation of DSNs. 634 (c) If no NOTIFY parameter was supplied for the recipient, a "failed" 635 DSN MUST be issued. 637 NOTE: Some MTAs are known to forward undeliverable messages to the 638 local postmaster or "dead letter" mailbox. This is still considered 639 delivery failure, and does not diminish the requirement to issue a 640 "failed" DSN under the conditions defined elsewhere in this memo. If a 641 DSN is issued for such a recipient, the Action value MUST be "failed". 643 7.2.7 Forwarding, aliases, and mailing lists 645 Delivery of a message to a local email address usually causes the 646 message to be stored in the recipient's mailbox. However, MTAs commonly 647 provide a facility where a local email address can be designated as an 648 "alias" or "mailing list"; delivery to that address then causes the 649 message to be forwarded to each of the (local or remote) recipient 650 addresses associated with the alias or list. It is also common to allow 651 a user to optionally "forward" her mail to one or more alternate 652 addresses. If this feature is enabled, her mail is redistributed to 653 those addresses instead of being deposited in her mailbox. 655 Following the example of [9] (section 5.3.6), this document defines 656 the difference between an "alias" and "mailing list" as follows: When 657 forwarding a message to the addresses associated with an "alias", the 658 envelope return address (e.g. SMTP MAIL FROM) remains intact. However, 659 when forwarding a message to the addresses associated with a "mailing 660 list", the envelope return address is changed to that of the 661 administrator of the mailing list. This causes DSNs and other 662 nondelivery reports resulting from delivery to the list members to be 663 sent to the list administrator rather than the sender of the original 664 message. 666 The DSN processing for aliases and mailing lists is as follows: 668 7.2.7.1 mailing lists 670 When a message is delivered to a list submission address (i.e. placed 671 in the list's mailbox for incoming mail, or accepted by the process that 672 redistributes the message to the list subscribers), this is considered 673 final delivery for the original message. If the NOTIFY parameter for 674 the list submission address contained the SUCCESS keyword, a "delivered" 675 DSN MUST be returned to the sender of the original message. 677 NOTE: Some mailing lists are able to reject message submissions, 678 based on the content of the message, the sender's address, or some other 679 criteria. While the interface between such a mailing list and its MTA 680 is not well-defined, it is important that DSNs NOT be issued by both the 681 MTA (to report successful delivery to the list), and the list (to report 682 message rejection using a "failure" DSN.) 684 However, even if a "delivered" DSN was issued by the MTA, a mailing 685 list which rejects a message submission MAY notify the sender that the 686 message was rejected using an ordinary message instead of a DSN. 688 Whenever a message is redistributed to an mailing list, 690 (a) The envelope return address is rewritten to point to the list 691 maintainer. This address MAY be that of a process that recognizes 692 DSNs and processes them automatically, but it MUST forward 693 unrecognized messages to the human responsible for the list. 695 (b) The ENVID, NOTIFY, RET, and ORCPT parameters which accompany the 696 redistributed message MUST NOT be derived from those of the original 697 message. 699 (c) The NOTIFY and RET parameters MAY be specified by the local 700 postmaster or the list administrator. If ORCPT parameters are 701 supplied during redistribution to the list subscribers, they SHOULD 702 contain the addresses of the list subscribers in the format used by 703 the mailing list. 705 7.2.7.2 single-recipient aliases 707 Under normal circumstances, when a message arrives for an "alias" 708 which has a single forwarding address, a DSN SHOULD NOT be issued. Any 709 ENVID, NOTIFY, RET, or ORCPT parameters SHOULD be propagated with the 710 message as it is redistributed to the forwarding address. 712 7.2.7.3 multiple-recipient aliases 714 An "alias" with multiple recipient addresses may be handled in any of 715 the following ways: 717 (a) Any ENVID, NOTIFY, RET, or ORCPT parameters are NOT propagated when 718 relaying the message to any of the forwarding addresses. If the 719 NOTIFY parameter for the alias contained the SUCCESS keyword, the 720 MTA issues a "relayed" DSN. (In effect, the MTA treats the message 721 as if it were being relayed into an environment that does not 722 support DSNs.) 724 (b) Any ENVID, NOTIFY, RET, or ORCPT parameters (or the equivalent 725 requests if the message is gatewayed) are propagated to EXACTLY one 726 of the forwarding addresses. No DSN is issued. (This is 727 appropriate when aliasing is used to forward a message to a 728 "vacation" auto-responder program in addition to the local mailbox.) 730 (c) Any ENVID, RET, or ORCPT parameters are propagated to all forwarding 731 addresses associated with that alias. The NOTIFY parameter is 732 propagated to the forwarding addresses, except that it any SUCCESS 733 keyword is removed. If the original NOTIFY parameter for the alias 734 contained the SUCCESS keyword, an "expanded" DSN is issued for the 735 alias. If the NOTIFY parameter for the alias did not contain the 736 SUCCESS keyword, no DSN is issued for the alias. 738 7.2.7.4 confidential forwarding addresses 740 If it is desired to maintain the confidentiality of a recipient's 741 forwarding address, the forwarding may be treated as if it were a 742 mailing list. A DSN will be issued, if appropriate, upon "delivery" to 743 the recipient address specified by the sender. When the message is 744 forwarded it will have a new envelope return address. Any DSNs which 745 result from delivery failure of the forwarded message will not be 746 returned to the original sender of the message and thus not expose the 747 recipient's forwarding address. 749 7.2.8 DSNs describing delivery to multiple recipients 751 A single DSN may describe attempts to deliver a message to multiple 752 recipients of that message. If a DSN is issued for some recipients in 753 an SMTP transaction and not for others according to the rules above, the 754 DSN SHOULD NOT contain information for recipients for whom DSNs would 755 not otherwise have been issued. 757 7.3 Handling of messages from other sources 759 For messages which originated from "local" users (whatever that 760 means), the specifications under which DSNs should be generated can be 761 communicated to the MTA via any protocol agreed on between the sender's 762 mail composer (user agent) and the MTA. The local MTA can then either 763 relay the message, or issue appropriate delivery status notifications. 764 However, if such requests are transmitted within the message itself (for 765 example in the message headers), the requests MUST be removed from the 766 message before it is transmitted via SMTP. 768 For messages gatewayed from non-SMTP sources and further relayed by 769 SMTP, the gateway SHOULD, using the SMTP extensions described here, 770 attempt to provide the delivery reporting conditions expected by the 771 source mail environment. If appropriate, any DSNs returned to the 772 source environment SHOULD be translated into the format expected in that 773 environment. 775 7.4 Implementation limits 777 A conforming MTA MUST accept ESMTP parameters of at least the 778 following sizes: 780 (a) ENVID parameter: 100 characters. 782 (b) NOTIFY parameter: 28 characters. 784 (c) ORCPT parameter: 500 characters. 786 (d) RET parameter: 8 characters. 788 The maximum sizes for the ENVID and ORCPT parameters are intended to 789 be adequate for the transmission of "foreign" envelope identifier and 790 original recipient addresses. However, user agents which use SMTP as a 791 message submission protocol SHOULD NOT generate ENVID parameters which 792 are longer than 38 characters in length. 794 A conforming MTA MUST be able to accept SMTP command-lines which are 795 at least 1036 characters long (530 characters for the ORCPT and NOTIFY 796 parameters of the RCPT command, in addition to the 512 characters 797 required by [1]). If other SMTP extensions are supported by the MTA, 798 the MTA MUST be able to accept a command-line large enough for each SMTP 799 command and any combination of ESMTP parameters which may be used with 800 that command. 802 8. Format of delivery notifications 804 The format of delivery status notifications is defined in [5], which 805 uses the framework defined in [8]. Delivery status notifications are to 806 be returned to the sender of the original message as outlined below. 808 8.1 SMTP Envelope to be used with delivery status notifications 810 The DSN sender address (in the SMTP MAIL command) MUST be a null 811 reverse-path ("<>"), as required by section 5.3.3 of [9]. The DSN 812 recipient address (in the RCPT command) is copied from the MAIL command 813 which accompanied the message for which the DSN is being issued. When 814 transmitting a DSN via SMTP, the RET parameter MUST NOT be used. The 815 NOTIFY parameter MAY be used, but its value MUST be NEVER. The ENVID 816 parameter (with a newly generated envelope-id) and/or ORCPT parameter 817 MAY be used. 819 8.2 Contents of the DSN 821 A DSN is transmitted as a MIME message with a top-level content-type 822 of multipart/report (as defined in [5]). 824 The multipart/report content-type may be used for any of several 825 kinds of reports generated by the mail system. When multipart/report is 826 used to convey a DSN, the report-type parameter of the multipart/report 827 content-type is "delivery-status". 829 As described in [8], the first component of a multipart/report 830 content-type is a human readable explanation of the report. For a DSN, 831 the second component of the multipart/report is of content-type 832 message/delivery-status (defined in [5]). The third component of the 833 multipart/report consists of the original message or some portion 834 thereof. When the value of the RET parameter is FULL, the full message 835 SHOULD be returned for any DSN which conveys notification of delivery 836 failure. (However, if the length of the message is greater than some 837 implementation-specified length, the MTA MAY return only the headers 838 even if the RET parameter specified FULL.) If a DSN contains no 839 notifications of delivery failure, the MTA SHOULD return only the 840 headers. 842 The third component must have an appropriate content-type label. 843 Issues concerning selection of the content-type are discussed in [8]. 845 8.3 Message/delivery-status fields 847 The message/delivery-status content-type defines a number of fields, 848 with general specifications for their contents. The following 849 requirements for any DSNs generated in response to a message received by 850 the SMTP protocol by a conforming SMTP server, are in addition to the 851 requirements defined in [5] for the message/delivery-status type. 853 When generating a DSN for a message which was received via the SMTP 854 protocol, a conforming MTA will generate the following fields of the 855 message/delivery-status body part: 857 (a) if an ENVID parameter was present on the MAIL command, an Original- 858 Envelope-ID field MUST be supplied, and the value associated with 859 the ENVID parameter must appear in that field. If the message was 860 received via SMTP with no ENVID parameter, the Original-Envelope-ID 861 field MUST NOT be supplied. 863 Since the ENVID parameter is encoded as xtext, but the Original- 864 Envelope-ID header is NOT encoded as xtext, the MTA must decode the 865 xtext encoding when copying the ENVID value to the Original- 866 Envelope-ID field. 868 (b) The Reporting-MTA field MUST be supplied. It SHOULD contain the 869 domain name of the SMTP server which is actually issuing this 870 notification. The MTA-name-type subfield MUST be "dns". 872 (c) Other per-message fields as defined in [5] MAY be supplied as 873 appropriate. 875 (d) If the ORCPT parameter was provided for this recipient, the 876 Original-Recipient field MUST be supplied, with its value taken from 877 the ORCPT parameter. If no ORCPT parameter was provided for this 878 recipient, the Original-Recipient field MUST NOT appear. 880 (e) The Final-Recipient field MUST be supplied. It MUST contain the 881 recipient address from the message envelope. If the message was 882 received via SMTP, the address-type will be "rfc822". 884 (f) The Action field MUST be supplied. 886 (g) The Status field MUST be supplied, using a status-code from [10]. 887 If there is no specific code which suitably describes a delivery 888 failure, either 4.0.0 (temporary failure), or 5.0.0 (permanent 889 failure) MUST be used. 891 (h) For DSNs resulting from attempts to relay a message to one or more 892 recipients via SMTP, the Remote-MTA field MUST be supplied for each 893 of those recipients. The mta-name-type subfields of those Remote- 894 MTA fields will be "dns". 896 (i) For DSNs resulting from attempts to relay a message to one or more 897 recipients via SMTP, the Diagnostic-Code MUST be supplied for each 898 of those recipients. The diagnostic-type subfield will be "smtp". 899 See section 10.2(a) of this document for a description of the "smtp" 900 diagnostic-code. 902 (j) For DSNs resulting from attempts to relay a message to one or more 903 recipients via SMTP, an SMTP-Remote-Recipient extension field MAY be 904 supplied for each recipient, which contains the address of that 905 recpient which was presented to the remote SMTP server. 907 (k) Other per-recipient fields defined in [5] MAY appear, as 908 appropriate. 910 9. Acknowledgments 912 The author wishes to thank Eric Allman, Harald Alvestrand, Jim 913 Conklin, Bryan Costales, Peter Cowen, Dave Crocker, Roger Fajman, Ned 914 Freed, Marko Kaittola, Steve Kille, John Klensin, Anastasios Kotsikonas, 915 John Gardiner Myers, Julian Onions, Jacob Palme, Marshall Rose, Greg 916 Vaudreuil, and Klaus Weide for their suggestions for improvement of this 917 document. 919 10. Appendix - Type-Name Definitions 921 The following type names are defined for use in DSN fields generated 922 by conforming SMTP-based MTAs: 924 10.1 "rfc822" address-type 926 The "rfc822" address-type is to be used when reporting Internet 927 electronic mail address in the Original-Recipient and Final-Recipient 928 DSN fields. 930 (a) address-type name: rfc822 931 (b) syntax for mailbox addresses 933 RFC822 mailbox addresses are generally expected to be of the form 935 [route] addr-spec 937 where "route" and "addr-spec" are defined in [2], and the "domain" 938 portions of both "route" and "addr-spec" are fully-qualified domain 939 names that are registered in the DNS. However, an MTA MUST NOT 940 modify an address obtained from the message envelope to force it to 941 conform to syntax rules. 943 (c) If addresses of this type are not composed entirely of graphic 944 characters from the US-ASCII repertoire, a specification for how they 945 are to be encoded as graphic US-ASCII characters in a DSN Original- 946 Recipient or Final-Recipient DSN field. 948 RFC822 addresses consist entirely of graphic characters from the US- 949 ASCII repertoire, so no translation is necessary. 951 10.2 "smtp" diagnostic-type 953 The "smtp" diagnostic-type is to be used when reporting SMTP reply- 954 codes in Diagnostic-Code DSN fields. 956 (a) diagnostic-type name: SMTP 958 (b) A description of the syntax to be used for expressing diagnostic 959 codes of this type as graphic characters from the US-ASCII repertoire. 961 An SMTP diagnostic-code is of the form 963 *( 3*DIGIT "-" *text ) 3*DIGIT SPACE *text 965 For a single-line SMTP reply to an SMTP command, the diagnostic-code 966 SHOULD be an exact transcription of the reply. For multi-line SMTP 967 replies, it is necessary to insert a SPACE before each line after 968 the first. For example, an SMTP reply of: 970 550-mailbox unavailable 971 550 user has moved with no forwarding address 973 could appear as follows in a Diagnostic-Code DSN field: 975 Diagnostic-Code: smtp ; 550-mailbox unavailable 976 550 user has moved with no forwarding address 978 (c) A list of valid diagnostic codes of this type and the meaning of 979 each code. 981 SMTP reply-codes are currently defined in [1], [4], and [9]. 982 Additional codes may be defined by other RFCs. 984 10.3 "dns" MTA-name-type 986 The "dns" MTA-name-type should be used in the Reporting-MTA field. 987 An MTA-name of type "dns" is a fully-qualified domain name. The name 988 must be registered in the DNS, and the address Postmaster@{mta-name} 989 must be valid. 991 (a) MTA-name-type name: dns 993 (b) A description of the syntax of MTA names of this type, using BNF, 994 regular expressions, ASN.1, or other non-ambiguous language. 996 MTA names of type "dns" SHOULD be valid Internet domain names. If 997 such domain names are not available, a domain-literal containing the 998 internet protocol address is acceptable. Such domain names 999 generally conform to the following syntax: 1001 domain = real-domain / domain-literal 1003 real-domain = sub-domain *("." sub-domain) 1005 sub-domain = atom 1007 domain-literal = "[" 1*3DIGIT 3("." 1*3DIGIT) "]" 1009 where "atom" and "DIGIT" are defined in [2]. 1011 (c) If MTA names of this type do not consist entirely of graphic 1012 characters from the US-ASCII repertoire, a specification for how an MTA 1013 name of this type should be expressed as a sequence of graphic US-ASCII 1014 characters. 1016 MTA names of type "dns" consist entirely of graphic US-ASCII 1017 characters, so no translation is needed. 1019 11. Appendix - Example 1021 This example traces the flow of a single message addressed to 1022 multiple recipients. The message is sent by Alice@Pure-Heart.ORG to 1023 Bob@Big-Bucks.COM, Carol@Ivory.EDU, Dana@Ivory.EDU, Eric@Bombs.AF.MIL, 1024 Fred@Bombs.AF.MIL, and George@Tax-ME.GOV, with a variety of per- 1025 recipient options. The message is successfully delivered to Bob, Dana 1026 (via a gateway), Eric, and Fred. Delivery fails for Carol and George. 1028 NOTE: Formatting rules for RFCs require that no line be longer than 1029 72 characters. Therefore, in the following examples, some SMTP commands 1030 longer than 72 characters are printed on two lines, with the first line 1031 ending in "\". In an actual SMTP transaction, such a command would be 1032 sent as a single line (i.e. with no embedded CRLFs), and without the "\" 1033 character that appears in these examples. 1035 11.1 Submission 1037 Alice's user agent sends the message to the SMTP server at Pure- 1038 Heart.ORG. Note that while this example uses SMTP as a mail submission 1039 protocol, other protocols could also be used. 1041 <<< 220 Pure-Heart.ORG SMTP server here 1042 >>> EHLO Pure-Heart.ORG 1043 <<< 250-Pure-Heart.ORG 1044 <<< 250-DSN 1045 <<< 250-EXPN 1046 <<< 250 SIZE 1047 >>> MAIL FROM: RET=HDRS ENVID=QQ314159 1048 <<< 250 sender ok 1049 >>> RCPT TO: NOTIFY=SUCCESS \ 1050 ORCPT=rfc822;Bob@Big-Bucks.COM 1051 <<< 250 recipient ok 1052 >>> RCPT TO: NOTIFY=FAILURE \ 1053 ORCPT=rfc822;Carol@Ivory.EDU 1054 <<< 250 recipient ok 1055 >>> RCPT TO: NOTIFY=SUCCESS,FAILURE \ 1056 ORCPT=rfc822;Dana@Ivory.EDU 1057 <<< 250 recipient ok 1058 >>> RCPT TO: NOTIFY=FAILURE \ 1059 ORCPT=rfc822;Eric@Bombs.AF.MIL 1060 <<< 250 recipient ok 1061 >>> RCPT TO: NOTIFY=NEVER 1062 <<< 250 recipient ok 1063 >>> RCPT TO: NOTIFY=FAILURE \ 1064 ORCPT=rfc822;George@Tax-ME.GOV 1065 <<< 250 recipient ok 1066 >>> DATA 1067 <<< 354 okay, send message 1068 >>> (message goes here) 1069 >>> . 1070 <<< 250 message accepted 1071 >>> QUIT 1072 <<< 221 goodbye 1073 11.2 Relay to Big-Bucks.COM 1075 The SMTP at Pure-Heart.ORG then relays the message to Big-Bucks.COM. 1076 (For the purpose of this example, mail.Big-Bucks.COM is the primary mail 1077 exchanger for Big-Bucks.COM). 1079 <<< 220 mail.Big-Bucks.COM says hello 1080 >>> EHLO Pure-Heart.ORG 1081 <<< 250-mail.Big-Bucks.COM 1082 <<< 250 DSN 1083 >>> MAIL FROM: RET=HDRS ENVID=QQ314159 1084 <<< 250 sender okay 1085 >>> RCPT TO: NOTIFY=SUCCESS \ 1086 ORCPT=rfc822;Bob@Big-Bucks.COM 1087 <<< 250 recipient okay 1088 >>> DATA 1089 <<< 354 send message 1090 >>> (message goes here) 1091 >>> . 1092 <<< 250 message received 1093 >>> QUIT 1094 <<< 221 bcnu 1095 11.3 Relay to Ivory.EDU 1097 The SMTP at Pure-Heart.ORG relays the message to Ivory.EDU, which (as 1098 it happens) is a gateway to a LAN-based mail system that accepts SMTP 1099 mail and supports the DSN extension. 1101 <<< 220 Ivory.EDU gateway to FooMail(tm) here 1102 >>> EHLO Pure-Heart.ORG 1103 <<< 250-Ivory.EDU 1104 <<< 250 DSN 1105 >>> MAIL FROM: RET=HDRS ENVID=QQ314159 1106 <<< 250 ok 1107 >>> RCPT TO: NOTIFY=FAILURE \ 1108 ORCPT=rfc822;Carol@Ivory.EDU 1109 <<< 550 error - no such recipient 1110 >>> RCPT TO: NOTIFY=SUCCESS,FAILURE \ 1111 ORCPT=rfc822;Dana@Ivory.EDU 1112 <<< 250 recipient ok 1113 >>> DATA 1114 <<< 354 send message, end with '.' 1115 >>> (message goes here) 1116 >>> . 1117 <<< 250 message received 1118 >>> QUIT 1119 <<< 221 bye 1121 Note that since the Ivory.EDU refused to accept mail for 1122 Carol@Ivory.EDU, and the sender specified NOTIFY=FAILURE, the sender- 1123 SMTP (in this case Pure-Heart.ORG) must generate a DSN. 1125 11.4 Relay to Bombs.AF.MIL 1127 The SMTP at Pure-Heart.ORG relays the message to Bombs.AF.MIL, which 1128 does not support the SMTP extension. Because the sender specified 1129 NOTIFY=NEVER for recipient Fred@Bombs.AF.MIL, the SMTP at Pure-Heart.ORG 1130 chooses to send the message for that recipient in a separate transaction 1131 with a reverse-path of <>. 1133 <<< 220-Bombs.AF.MIL reporting for duty. 1134 <<< 220 Electronic mail is to be used for official business only. 1135 >>> EHLO Pure-Heart.ORG 1136 <<< 502 command not implemented 1137 >>> RSET 1138 <<< 250 reset 1139 >>> HELO Pure-Heart.ORG 1140 <<< 250 Bombs.AF.MIL 1141 >>> MAIL FROM: 1142 <<< 250 ok 1143 >>> RCPT TO: 1144 <<< 250 ok 1145 >>> DATA 1146 <<< 354 send message 1147 >>> (message goes here) 1148 >>> . 1149 <<< 250 message accepted 1150 >>> MAIL FROM:<> 1151 <<< 250 ok 1152 >>> RCPT TO: 1153 <<< 250 ok 1154 >>> DATA 1155 <<< 354 send message 1156 >>> (message goes here) 1157 >>> . 1158 <<< 250 message accepted 1159 >>> QUIT 1160 <<< 221 Bombs.AF.MIL closing connection 1161 11.5 Forward from George@Tax-ME.GOV to Sam@Boondoggle.GOV 1163 The SMTP at Pure-Heart.ORG relays the message to Tax-ME.GOV. (this 1164 step is not shown). MTA Tax-ME.GOV then forwards the message to 1165 Sam@Boondoggle.GOV (shown below). Both Tax-ME.GOV and Pure-Heart.ORG 1166 support the SMTP DSN extension. Note that RET, ENVID, and ORCPT all 1167 retain their original values. 1169 <<< 220 BoonDoggle.GOV says hello 1170 >>> EHLO Pure-Heart.ORG 1171 <<< 250-mail.Big-Bucks.COM 1172 <<< 250 DSN 1173 >>> MAIL FROM: RET=HDRS ENVID=QQ314159 1174 <<< 250 sender okay 1175 >>> RCPT TO: NOTIFY=SUCCESS \ 1176 ORCPT=rfc822;George@Tax-ME.GOV 1177 <<< 250 recipient okay 1178 >>> DATA 1179 <<< 354 send message 1180 >>> (message goes here) 1181 >>> . 1182 <<< 250 message received 1183 >>> QUIT 1184 <<< 221 bcnu 1185 11.6 "Delivered" DSN for Bob@Big-Bucks.COM 1187 MTA mail.Big-Bucks.COM successfully delivers the message to Bob@Big- 1188 Bucks.COM. Because the sender specified NOTIFY=SUCCESS, mail.Big- 1189 Bucks.COM issues the following DSN, and sends it to Alice@Pure- 1190 Heart.ORG. 1192 To: Alice@Pure-Heart.ORG 1193 From: postmaster@mail.Big-Bucks.COM 1194 Subject: Delivery Notification (success) for Bob@Big-Bucks.COM 1195 Content-Type: multipart/report; report-type=delivery-status; 1196 boundary=abcde 1197 MIME-Version: 1.0 1199 --abcde 1200 Content-type: text/plain; charset=us-ascii 1202 Your message (id QQ314159) was successfully delivered to 1203 Bob@Big-Bucks.COM. 1205 --abcde 1206 Content-type: message/delivery-status 1208 Reporting-MTA: dns; mail.Big-Bucks.COM 1209 Original-Envelope-ID: QQ314159 1211 Original-Recipient: rfc822;Bob@Big-Bucks.COM 1212 Final-Recipient: rfc822;Bob@Big-Bucks.COM 1213 Action: delivered 1214 Status: 2.0.0 1216 --abcde 1217 Content-type: message/rfc822 1219 (headers of returned message go here) 1221 --abcde-- 1222 11.7 Failed DSN for Carol@Ivory.EDU 1224 Because delivery to Carol failed and the sender specified 1225 NOTIFY=FAILURE for Carol@Ivory.EDU, MTA Pure-Heart.ORG (the SMTP client 1226 to which the failure was reported via SMTP) issues the following DSN. 1228 To: Alice@Pure-Heart.ORG 1229 From: postmaster@Pure-Heart.ORG 1230 Subject: Delivery Notification (failure) for Carol@Ivory.EDU 1231 Content-Type: multipart/report; report-type=delivery-status; 1232 boundary=bcdef 1233 MIME-Version: 1.0 1235 --bcdef 1236 Content-type: text/plain; charset=us-ascii 1238 Your message (id QQ314159) could not be delivered to 1239 Carol@Ivory.EDU. 1241 A transcript of the session follows: 1243 (while talking to Ivory.EDU) 1244 >>> RCPT TO: NOTIFY=FAILURE 1245 <<< 550 error - no such recipient 1247 --bcdef 1248 Content-type: message/delivery-status 1250 Reporting-MTA: dns; Pure-Heart.ORG 1251 Original-Envelope-ID: QQ314159 1253 Original-Recipient: rfc822;Carol@Ivory.EDU 1254 Final-Recipient: rfc822;Carol@Ivory.EDU 1255 SMTP-Remote-Recipient: Carol@Ivory.EDU 1256 Diagnostic-Code: smtp; 550 error - no such recipient 1257 Action: failed 1258 Status: 5.0.0 1260 --bcdef 1261 Content-type: message/rfc822 1263 (headers of returned message go here) 1265 --bcdef-- 1266 11.8 Relayed DSN For Dana@Ivory.EDU 1268 Although the mail gateway Ivory.EDU supports the DSN SMTP extension, 1269 the LAN mail system attached to its other side does not generate 1270 positive delivery confirmations. So Ivory.EDU issues a "relayed" DSN: 1272 To: Alice@Pure-Heart.ORG 1273 From: postmaster@Ivory.EDU 1274 Subject: mail relayed for Dana@Ivory.EDU 1275 Content-Type: multipart/report; report-type=delivery-status; 1276 boundary=cdefg 1277 MIME-Version: 1.0 1279 --cdefg 1280 Content-type: text/plain; charset=us-ascii 1282 Your message (addressed to Dana@Ivory.EDU) was successfully 1283 relayed to: 1285 ymail!Dana 1287 by the FooMail gateway at Ivory.EDU. 1289 Unfortunately, the remote mail system does not support 1290 confirmation of actual delivery. Unless delivery to ymail!Dana 1291 fails, this will be the only delivery status notification sent. 1293 --cdefg 1294 Content-type: message/delivery-status 1296 Reporting-MTA: dns; Ivory.EDU 1297 Original-Envelope-ID: QQ314159 1299 Original-Recipient: rfc822;Dana@Ivory.EDU 1300 Final-Recipient: rfc822;Dana@Ivory.EDU 1301 Action: relayed 1302 Status: 2.0.0 1304 --cdefg 1305 Content-type: message/rfc822 1307 (headers of returned message go here) 1309 --cdefg-- 1310 11.9 Failure notification for Sam@Boondoggle.GOV 1312 The message originally addressed to George@Tax-ME.GOV was forwarded 1313 to Sam@Boondoggle.GOV, but the MTA for Boondoggle.GOV was unable to 1314 deliver the message due to a lack of disk space in Sam's mailbox. After 1315 trying for several days, Boondoggle.GOV returned the following DSN: 1317 To: Alice@BigHeart.ORG 1318 From: Postmaster@Boondoggle.GOV 1319 Subject: Delivery failure for Sam@Boondoggle.GOV 1320 Content-Type: multipart/report; report-type=delivery-status; 1321 boundary=defgh 1322 MIME-Version: 1.0 1324 --defgh 1325 Your message, originally addressed to George@Tax-ME.GOV, and forwarded 1326 from there to Sam@Boondoggle.GOV could not be delivered, for the 1327 following reason: 1329 write error to mailbox, disk quota exceeded 1331 --defgh 1332 Content-type: message/delivery-status 1334 Reporting-MTA: Boondoggle.GOV 1335 Original-Envelope-ID: QQ314159 1337 Original-Recipient: rfc822;George@Tax-ME.GOV 1338 Final-Recipient: rfc822;Sam@Boondoggle.GOV 1339 Action: failed 1340 Status: 4.2.2 (disk quota exceeded) 1342 --defgh 1343 Content-type: message/rfc822 1345 (headers of returned message go here) 1347 --defgh-- 1348 12. References 1350 [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, 1351 USC/Information Sciences Institute, August 1982. 1353 [2] Crocker, D., "Standard for the Format of ARPA Internet Text 1354 Messages", STD 11, RFC 822, UDEL, August 1982. 1356 [3] Westine, A., Postel, J. "Problems with the Maintenance of Large 1357 Mailing Lists.", RFC 1211, USC/Information Sciences Institute, March 1358 1991. 1360 [4] Klensin, J., Freed, N., Rose, M., Stefferud, E., Crocker., D. "SMTP 1361 Service Extensions", RFC 1651, MCI, Innosoft, Dover Beach 1362 Consulting, Inc., Network Management Associates, Inc., Silicon 1363 Graphics, Inc., July 1994. 1365 [5] Moore, K., Vaudreuil, G. "An Extensible Message Format for Delivery 1366 Status Notifications", Internet-Draft draft-ietf-notary-mime- 1367 delivery-05.txt, 21 June 1995. 1369 [6] Crispin, M. "Internet Message Access Protocol - Version 4", RFC 1370 1730, University of Washington, 20 December 1994. 1372 [7] Myers, J., Rose, M. "Post Office Protocol - Version 3", RFC 1725, 1373 Carnegie Mellon, Dover Beach Consulting, 23 November 1994. 1375 [8] Vaudreuil, G. "The Multipart/Report Content Type for the Reporting 1376 of Mail System Administrative Messages". Internet-Draft draft-ietf- 1377 notary-mime-report-04.txt, 5 May 1995. 1379 [9] Braden, R. (ed). Requirements for Internet Hosts - Application and 1380 Support, RFC 1123, IETF, October 1989. 1382 [10] Vaudreuil, G. "Enhanced Mail System Status Codes". Internet-Draft 1383 draft-ietf-notary-status-04.txt, 14 June 1995. 1385 13. Author's address 1387 Keith Moore 1388 University of Tennessee 1389 107 Ayres Hall 1390 Knoxville, TN 37996-1301 1391 USA 1393 email: moore@cs.utk.edu