idnits 2.17.1 draft-ietf-notary-smtp-drpt-04.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-19) 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 192: '...hile parentheses MAY appear within an ...' RFC 2119 keyword, line 215: '... MAY be encoded as itself. (A CHAR i...' RFC 2119 keyword, line 226: '...used, it MUST have an associated esmtp...' RFC 2119 keyword, line 235: '..., separated by commas, MAY appear in a...' RFC 2119 keyword, line 236: '...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 (29 May 1995) is 10553 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-03 Summary: 18 errors (**), 0 flaws (~~), 4 warnings (==), 2 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: 29 November 1995 29 May 1995 5 SMTP Service Extension 6 for Delivery Status Notifications 8 draft-ietf-notary-smtp-drpt-04.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 2. Abstract 30 This memo defines an extension to the SMTP service, which allows an 31 SMTP client to specify (a) that delivery status notifications (DSNs) 32 should be generated under certain conditions, (b) whether such 33 notifications should return the contents of the message, and (c) 34 additional information, to be returned with a DSN, that allows the 35 sender to identify both the recipient(s) for which the DSN was issued, 36 and the transaction in which the original message was sent. 38 3. Introduction 40 The SMTP protocol [1] requires that an SMTP server provide 41 notification of delivery failure, if it determines that a message cannot 42 be delivered to one or more recipients. Traditionally, such 43 notification consists of an ordinary Internet mail message (format 44 defined by [2]), sent to the envelope sender address (the argument of 45 the SMTP MAIL command), containing an explanation of the error and at 46 least the headers of the failed message. 48 Experience with large mail distribution lists [3] indicates that such 49 messages are often insufficient to diagnose problems, or even to 50 determine at which host or for which recipients a problem occurred. In 51 addition, the lack of a standardized format for delivery notifications 52 in Internet mail makes it difficult to exchange such notifications with 53 other message handling systems. 55 Such experience has demonstrated a need for a delivery status 56 notification service for Internet electronic mail, which: 58 (a) is reliable, in the sense that any DSN request will either be 59 honored at the time of final delivery, or result in a response that 60 indicates that the request cannot be honored, 62 (b) when both success and failure notifications are requested, provides 63 an unambiguous and nonconflicting indication of whether delivery of 64 a message to a recipient succeeded or failed, 66 (c) is stable, in that a failed attempt to deliver a DSN should never 67 result in the transmission of another DSN over the network, 69 (d) preserves sufficient information to allow the sender to identify 70 both the mail transaction and the recipient address which caused the 71 notification, even when mail is forwarded or gatewayed to foreign 72 environments, and 74 (e) interfaces acceptably with non-SMTP and non-822-based mail systems, 75 both so that notifications returned from foreign mail systems may be 76 useful to Internet users, and so that the notification requests from 77 foreign environments may be honored. Among the requirements implied 78 by this goal are the ability to request non-return-of-content, and 79 the ability to specify whether positive delivery notifications, 80 negative delivery notifications, both, or neither, should be issued. 82 In an attempt to provide such a service, this memo uses the mechanism 83 defined in [4] to define an extension to the SMTP protocol. Using this 84 mechanism, an SMTP client may request that an SMTP server issue or not 85 issue a delivery status notification (DSN) under certain conditions. 86 The format of a DSN is defined in [5]. 88 4. Framework for the Delivery Status Notification Extension 90 The following service extension is therefore defined: 92 (1) The name of the SMTP service extension is "Delivery Status 93 Notification"; 95 (2) the EHLO keyword value associated with this extension is "DSN", the 96 meaning of which is defined in section 5 of this memo; 98 (3) no parameters are allowed with this EHLO keyword value; 100 (4) two optional parameters are added to the RCPT command, and two 101 optional parameters are added to the MAIL command: 103 An optional parameter for the RCPT command, using the esmtp-keyword 104 "NOTIFY", (to specify the conditions under which a delivery status 105 notification should be generated), is defined in section 6.1, 107 An optional parameter for the RCPT command, using the esmtp-keyword 108 "ORCPT", (used to convey the "original" (sender-specified) recipient 109 address), is defined in section 6.2, and 111 An optional parameter for the MAIL command, using the esmtp-keyword 112 "RET", (to request that DSNs containing an indication of delivery 113 failure either return the entire contents of a message or only the 114 message headers), is defined in section 6.3, 116 An optional parameter for the MAIL command, using the esmtp-keyword 117 "ENVID", (used to propagate an identifier for this message 118 transmission envelope, which is also known to the sender and will, 119 if present, be returned in any DSNs issued for this transmission), 120 is defined in section 6.4; 122 (5) no additional SMTP verbs are defined by this extension. 124 The remainder of this memo specifies how support for the extension 125 affects the behavior of a message transfer agent. 127 5. The Delivery Status Notification service extension 129 An SMTP client wishing to request a DSN for a message may issue the 130 EHLO command to start an SMTP session, to determine if the server 131 supports any of several service extensions. If the server responds with 132 code 250 to the EHLO command, and the response includes the EHLO keyword 133 DSN, then the Delivery Status Notification extension (as described in 134 this memo) is supported. 136 Ordinarily, when an SMTP server returns a positive (2xx) reply code 137 in response to a RCPT command, it agrees to accept responsibility for 138 either delivering the message to the named recipient, or sending a 139 notification to the sender of the message indicating that delivery has 140 failed. However, an extended SMTP ("ESMTP") server which implements 141 this service extension will accept an optional NOTIFY parameter with the 142 RCPT command. If present, the NOTIFY parameter alters the conditions for 143 generation of delivery status notifications from the default (issue 144 notifications only on failure) specified in [1]. The ESMTP client may 145 also request (via the RET parameter) whether the entire contents of the 146 original message should be returned (as opposed to just the headers of 147 that message), along with the DSN. 149 In general, an ESMTP server which implements this service extension 150 will propagate delivery status notification requests when relaying mail 151 to other SMTP-based MTAs which also support this extension, and make a 152 "best effort" to ensure that such requests are honored when messages are 153 passed into other environments. 155 In order that any delivery status notifications thus generated will 156 be meaningful to the sender, any ESMTP server which supports this 157 extension will attempt to propagate the following information to any 158 other MTAs that are used to relay the message, for use in generating 159 DSNs: 161 (a) for each recipient, a copy of the original recipient address, as 162 used by the sender of the message. 164 This address need not be the same as the mailbox specified in the 165 RCPT command. For example, if a message was originally addressed to 166 A@B.C and later forwarded to A@D.E, after such forwarding has taken 167 place, the RCPT command will specify a mailbox of A@D.E. However, 168 the original recipient address remains A@B.C. 170 Also, if the message originated from an environment which does not 171 use Internet-style user@domain addresses, and was gatewayed into 172 SMTP, the original recipient address will preserve the original form 173 of the recipient address. 175 (b) for the entire SMTP transaction, an envelope identification string, 176 which may be used by the sender to associate any delivery status 177 notifications with the transaction used to send the original 178 message. 180 6. Additional parameters for RCPT and MAIL commands 182 The extended RCPT and MAIL commands are issued by a client when it 183 wishes to request a DSN from the server, under certain conditions, for a 184 particular recipient. The extended RCPT and MAIL commands are identical 185 to the RCPT and MAIL commands defined in [1], except that one or more of 186 the following parameters appear after the sender or recipient address, 187 respectively. The general syntax for extended SMTP commands is defined 188 in [4]. 190 NOTE: Although RFC 822 ABNF is used to describe the syntax of these 191 parameters, they are not, in the language of that document, "structured 192 field bodies". Therefore, while parentheses MAY appear within an emstp- 193 value, they are not recognized as comment delimiters. 195 The syntax for "esmtp-value" in [4] does not allow SP, "=", control 196 characters, or characters outside the traditional ASCII range of 1-127 197 decimal to be transmitted in an esmtp-value. Because the ENVID and 198 ORCPT parameters may need to convey values outside this range, the 199 esmtp-values for these parameters are encoded as "xtext". "xtext" is 200 formally defined as follows: 202 xtext = *( xchar / hexchar ) 203 xchar = any ASCII CHAR between "!" (33) and "~" (126) inclusive, 204 except for "+" and "=". 206 ; "hexchar"s are intended to encode octets that cannot appear 207 ; as ASCII characters within an esmtp-value. 209 hexchar = ASCII "+" immediately followed by two upper case 210 hexadecimal digits 212 When encoding an octet sequence as xtext: 214 + Any ASCII CHAR between "!" and "~" inclusive, except for "+" and "=", 215 MAY be encoded as itself. (A CHAR in this range MAY instead be 216 encoded as a "hexchar", at the implementor's discretion.) 218 + ASCII CHARs that fall outside the range above must be encoded as 219 "hexchar". 221 6.1 The NOTIFY parameter of the ESMTP RCPT command 223 A RCPT command issued by a client may contain the optional esmtp- 224 keyword "NOTIFY", to specify the conditions under which the SMTP server 225 should generate DSNs for that recipient. If the NOTIFY esmtp-keyword is 226 used, it MUST have an associated esmtp-value, formatted according to the 227 following rules, using the ABNF of RFC 822: 229 notify-esmtp-value = "NEVER" / 1#notify-list-element 231 notify-list-element = "SUCCESS" / "FAILURE" / "DELAY" 233 Notes: 235 a. Multiple notify-list-elements, separated by commas, MAY appear in a 236 NOTIFY parameter; however, the NEVER keyword MUST appear by itself. 238 b. Any of the keywords NEVER, SUCCESS, FAILURE, or DELAY may be spelled 239 in any combination of upper and lower case letters. 241 The meaning of the NOTIFY parameter values is generally as follows: 243 + A NOTIFY parameter value of "NEVER" requests that a DSN not be 244 returned to the sender under any conditions. 246 + A NOTIFY parameter value containing the "SUCCESS" or "FAILURE" 247 keywords requests that a DSN be issued on successful delivery or 248 delivery failure, respectively. 250 + A NOTIFY parameter value containing the keyword "DELAY" indicates the 251 sender's willingness to receive "delayed" DSNs. Delayed DSNs may be 252 issued if delivery of a message has been delayed for an unusual amount 253 of time (as determined by the MTA at which the message is delayed), 254 but the final delivery status (whether successful or failure) cannot 255 be determined. The absence of the DELAY keyword in a NOTIFY parameter 256 requests that a "delayed" DSN NOT be issued under any conditions. 258 The actual rules governing interpretation of the NOTIFY parameter are 259 given in section 7. 261 For compatibility with SMTP clients that do not use the NOTIFY facility, 262 the absence of a NOTIFY parameter in a RCPT command may be interpreted 263 as either NOTIFY=FAILURE or NOTIFY=FAILURE,DELAY. 265 6.2 The ORCPT parameter to the ESMTP RCPT command 267 The ORCPT esmtp-keyword of the RCPT command is used to specify an 268 "original" recipient address that corresponds to the actual recipient to 269 which the message is to be delivered. If the ORCPT esmtp-keyword is 270 used, it MUST have an associated esmtp-value, which consists of the 271 original recipient address, encoded according to the rules below. The 272 ABNF for the ORCPT parameter is: 274 orcpt-parameter = "ORCPT=" original-recipient-address 276 original-recipient-address = addr-type ";" xtext 278 The "addr-type" portion MUST be an IANA-registered electronic mail 279 address-type (as defined in [5]), while the "xtext" portion contains an 280 encoded representation of the original recipient address using the rules 281 in section 6 of this document. The entire ORCPT parameter MAY be up to 282 500 characters in length. 284 When initially submitting a message via SMTP, if the ORCPT parameter 285 is used, it MUST contain the same address as the RCPT TO address (unlike 286 the RCPT TO address, the ORCPT parameter will be encoded as xtext). 287 Likewise, when a mailing list submits a message via SMTP to be 288 distributed to the list subscribers, if ORCPT is used, the ORCPT 289 parameter MUST match the new RCPT TO address of each recipient, not the 290 address specified by the original sender of the message.) 292 The "addr-type" portion of the original-recipient-address is used to 293 indicate the "type" of the address which appears in the ORCPT parameter 294 value. However, the address associated with the ORCPT keyword is NOT 295 constrained to conform to the syntax rules for that "addr-type". 297 Ideally, the "xtext" portion of the original-recipient-address should 298 contain, in encoded form, the same sequence of characters that the 299 sender used to specify the recipient. However, for a message gatewayed 300 from an environment (such as X.400) in which a recipient address is not 301 a simple string of printable characters, the representation of recipient 302 address must be defined by a specification for gatewaying between DSNs 303 and that environment. 305 6.3 The RET parameter of the ESMTP MAIL command 307 The RET esmtp-keyword on the extended MAIL command specifies whether 308 or not the message should be included in any failed DSN issued for this 309 message transmission. If the RET esmtp-keyword is used, it MUST have an 310 associated esmtp-value, which is one of the following keywords: 312 FULL requests that the entire message be returned in any "failed" 313 delivery status notification issued for this recipient. 315 HDRS requests that only the headers of the message be returned. 317 The FULL and HDRS keywords may be spelled in any combination of upper 318 and lower case letters. 320 If no RET parameter is supplied, the MTA MAY return either the 321 headers of the message or the entire message for any DSN containing 322 indication of failed deliveries. 324 Note that the RET parameter only applies to DSNs that indicate 325 delivery failure for at least one recipient. If a DSN contains no 326 indications of delivery failure, only the headers of the message should 327 be returned. 329 6.4 The ENVID parameter to the ESMTP MAIL command 331 The ENVID esmtp-keyword of the SMTP MAIL command is used to specify 332 an "envelope identifier" to be transmitted along with the message and 333 included in any DSNs issued for any of the recipients named in this SMTP 334 transaction. The purpose of the envelope identifier is to allow the 335 sender of a message to identify the transaction for which the DSN was 336 issued. 338 The ABNF for the ENVID parameter is: 340 envid-parameter = "ENVID=" xtext 342 The ENVID esmtp-keyword MUST have an associated esmtp-value. No 343 meaning is assigned by the mail system to the presence or absence of 344 this parameter or to any esmtp-value associated with this parameter; the 345 information is used only by the sender or his user agent. The ENVID 346 parameter MAY be up to 100 characters in length. 348 6.5 Restrictions on the use of Delivery Status Notification parameters 350 The RET and ENVID parameters MUST NOT appear more than once each in 351 any single MAIL command. If more than one of either of these parameters 352 appears in a MAIL command, the ESMTP server SHOULD respond with "501 353 syntax error in parameters or arguments". 355 The NOTIFY and ORCPT parameters MUST NOT appear more than once in any 356 RCPT command. If more than one of either of these parameters appears in 357 a RCPT command, the ESMTP server SHOULD respond with "501 syntax error 358 in parameters or arguments". 360 7. Conformance requirements 362 The Simple Mail Transfer Protocol (SMTP) is used by Message Transfer 363 Agents (MTAs) when accepting, relaying, or gatewaying mail, as well as 364 User Agents (UAs) when submitting mail to the mail transport system. 365 The DSN extension to SMTP may be used to allow UAs to convey the 366 sender's requests as to when DSNs should be issued. A UA which claims 367 to conform to this specification must meet certain requirements as 368 described below. 370 Typically, a message transfer agent (MTA) which supports SMTP will 371 assume, at different times, both the role of a SMTP client and an SMTP 372 server, and may also provide local delivery, gatewaying to foreign 373 environments, forwarding, and mailing list expansion. An MTA which, 374 when acting as an SMTP server, issues the DSN keyword in response to the 375 EHLO command, MUST obey the rules below for a "conforming SMTP client" 376 when acting as a client, and a "conforming SMTP server" when acting as a 377 server. The term "conforming MTA" refers to an MTA which conforms to 378 this specification, independent of its role of client or server. 380 7.1 SMTP protocol interactions 382 The following rules apply to SMTP transactions in which any of the 383 ENVID, NOTIFY, RET, or ORCPT keywords are used: 385 (a) If an SMTP client issues a MAIL command containing a valid ENVID 386 parameter and associated esmtp-value and/or a valid RET parameter 387 and associated esmtp-value, a conforming SMTP server MUST return the 388 same reply-code as it would to the same MAIL command without the 389 ENVID and/or RET parameters. A conforming SMTP server MUST NOT 390 refuse a MAIL command based on the absence or presence of valid 391 ENVID or RET parameters, or on their associated esmtp-values. 393 However, if the associated esmtp-value is not valid (i.e. contains 394 illegal characters), or if there is more than one ENVID or RET 395 parameter in a particular MAIL command, the server MUST issue the 396 reply-code 501 with an appropriate message (e.g. "syntax error in 397 parameter"). 399 (b) If an SMTP client issues a RCPT command containing any valid NOTIFY 400 and/or ORCPT parameters, a conforming SMTP server MUST return the 401 same response as it would to the same RCPT command without those 402 NOTIFY and/or ORCPT parameters. A conforming SMTP server MUST NOT 403 refuse a RCPT command based on the presence or absence of any of 404 these parameters. 406 However, if any of the associated esmtp-values are not valid, or if 407 there is more than one of any of these parameters in a particular 408 RCPT command, the server SHOULD issue the response "501 syntax error 409 in parameter". 411 7.2 Handling of messages received via SMTP 413 This section describes how a conforming MTA should handle any 414 messages received via SMTP. 416 NOTE: A DSN MUST NOT be returned to the sender for any message for 417 which the return address from the SMTP MAIL command was NULL ("<>"), 418 even if the sender's address is available from other sources (e.g. the 419 message header). However, the MTA which would otherwise issue a DSN 420 SHOULD inform the local postmaster of delivery failures through some 421 appropriate mechanism that will not itself result in the generation of 422 DSNs. 424 DISCUSSION: RFC 1123, section 2.3.3 requires error notifications to 425 be sent with a NULL return address ("reverse-path"). This creates an 426 interesting situation when a message arrives with one or more 427 nonfunctional recipient addresses in addition to a nonfunctional return 428 address. When delivery to one of the recipient addresses fails, the MTA 429 will attempt to send a nondelivery notification to the return address, 430 setting the return address on the notification to NULL. When the 431 delivery of this notification fails, the MTA attempting delivery of that 432 notification sees a NULL return address. If that MTA were not to inform 433 anyone of the situation, the original message would be silently lost. 434 Furthermore, a nonfunctional return address is often indicative of a 435 configuration problem in the sender's MTA. Reporting the condition to 436 the local postmaster may help to speed correction of such errors. 438 7.2.1 Relay of messages to other conforming SMTP servers 440 The following rules govern the behavior of a conforming MTA, when 441 relaying a message which was received via the SMTP protocol, to an SMTP 442 server that supports the Delivery Status Notification service extension: 444 (a) Any ENVID parameter included in the MAIL command when a message was 445 received, MUST also appear on the MAIL command with which the 446 message is relayed, with the same associated esmtp-value. If no 447 ENVID parameter was included in the MAIL command when the message 448 was received, the ENVID parameter MUST NOT be supplied when the 449 message is relayed. 451 (b) Any RET parameter included in the MAIL command when a message was 452 received, MUST also appear on the MAIL command with which the 453 message is relayed, with the same associated esmtp-value. If no RET 454 parameter was included in the MAIL command when the message was 455 received, the RET parameter MUST NOT supplied when the message is 456 relayed. 458 (c) If the NOTIFY parameter was supplied for a recipient when the 459 message was received, the RCPT command issued when the message is 460 relayed MUST also contain the NOTIFY parameter along with its 461 associated esmtp-value. If the NOTIFY parameter was not supplied 462 for a recipient when the message was received, the NOTIFY parameter 463 MUST NOT be supplied for that recipient when the message is relayed. 465 (d) If any ORCPT parameter was present in the RCPT command for a 466 recipient when the message was received, an ORCPT parameter with the 467 identical original-recipient-address MUST appear in the RCPT command 468 issued for that recipient when relaying the message. (For example, 469 the MTA therefore MUST NOT change the case of any alphabetic 470 characters in an ORCPT parameter.) 472 If no ORCPT parameter was present in the RCPT command when the 473 message was received, an ORCPT parameter MAY be added to the RCPT 474 command when the message is relayed. If an ORCPT parameter is added 475 by the relaying MTA, it MUST contain the recipient address from the 476 RCPT command used when the message was received by that MTA. 478 7.2.2 Relay of messages to non-conforming SMTP servers 480 The following rules govern the behavior of a conforming MTA (in the 481 role of client), when relaying a message which was received via the SMTP 482 protocol, to an SMTP server that does not support the Delivery Status 483 Notification service extension: 485 (a) ENVID, NOTIFY, RET, or ORCPT parameters MUST NOT be issued when 486 relaying the message. 488 (b) If the NOTIFY parameter was supplied for a recipient, with an esmtp- 489 value containing the keyword SUCCESS, and the SMTP server returns a 490 success (2xx) reply-code in response to the RCPT command, the client 491 MUST issue a "relayed" DSN for that recipient. 493 (c) If the NOTIFY parameter was supplied for a recipient with an esmtp- 494 value containing the keyword FAILURE, and the SMTP server returns a 495 permanent failure (5xx) reply-code in response to the RCPT command, 496 the client MUST issue a "failed" DSN for that recipient. 498 (d) If the NOTIFY parameter was supplied for a recipient with an esmtp- 499 value of NEVER, the client MUST NOT issue a DSN for that recipient, 500 regardless of the reply-code returned by the SMTP server. However, 501 if the server returned a failure (5xx) reply-code, the client MAY 502 inform the local postmaster of the delivery failure via an 503 appropriate mechanism that will not itself result in the generation 504 of DSNs. 506 When attempting to relay a message to an SMTP server that does not 507 support this extension, and if NOTIFY=NEVER was specified for some 508 recipients of that message, a conforming SMTP client MAY relay the 509 message for those recipients in a separate SMTP transaction, using 510 an empty reverse-path in the MAIL command. This will prevent DSNs 511 from being issued for those recipients by MTAs that conform to [1]. 513 (e) If a NOTIFY parameter was not supplied for a recipient, and the SMTP 514 server returns a success (2xx) reply-code in response to a RCPT 515 command, the client MUST NOT issue any DSN for that recipient. 517 (f) If a NOTIFY parameter was not supplied for a recipient, and the SMTP 518 server returns a permanent failure (5xx) reply-code in response to a 519 RCPT command, the client MUST issue a "failed" DSN for that 520 recipient. 522 7.2.3 Local delivery of messages 524 The following rules govern the behavior of a conforming MTA upon 525 successful delivery of a message that was received via the SMTP 526 protocol, to a local recipient's mailbox: 528 "Delivery" means that the message has been placed in the recipient's 529 mailbox. For messages which are transmitted to a mailbox for later 530 retrieval via IMAP [6], POP [7] or a similar message access protocol, 531 "delivery" occurs when the message is made available to the IMAP (POP, 532 etc.) service, rather than when the message is retrieved by the 533 recipient's user agent. 535 Similarly, for a recipient address which corresponds to a mailing 536 list exploder, "delivery" occurs when the message is made available to 537 that list exploder, even though the list exploder might refuse to 538 deliver that message to the list recipients. 540 (a) If the NOTIFY parameter was supplied for that recipient, with an 541 esmtp-value containing the SUCCESS keyword, the MTA MUST issue a 542 "delivered" DSN for that recipient. 544 (b) If the NOTIFY parameter was supplied for that recipient which did 545 not contain the SUCCESS keyword, the MTA MUST NOT issue a DSN for 546 that recipient. 548 (c) If the NOTIFY parameter was not supplied for that recipient, the MTA 549 MUST NOT issue a DSN. 551 7.2.4 Gatewaying a message into a foreign environment 553 The following rules govern the behavior of a conforming MTA, when 554 gatewaying a message that was received via the SMTP protocol, into a 555 foreign (non-SMTP) environment: 557 (a) If the the foreign environment is capable of issuing appropriate 558 notifications under the conditions requested by the NOTIFY 559 parameter, and the conforming MTA can ensure that any notification 560 thus issued will be translated into a DSN and delivered to the 561 original sender, then the MTA SHOULD gateway the message into the 562 foreign environment, requesting notification under the desired 563 conditions, without itself issuing a DSN. 565 (b) If a NOTIFY parameter was supplied with the SUCCESS keyword, but the 566 destination environment cannot return an appropriate notification on 567 successful delivery, the MTA SHOULD issue a "relayed" DSN for that 568 recipient. 570 (c) If a NOTIFY parameter was supplied with an esmtp-keyword of NEVER, a 571 DSN MUST NOT be issued. If possible, the MTA SHOULD direct the 572 destination environment to not issue delivery notifications for that 573 recipient. 575 (d) If the NOTIFY parameter was not supplied for a particular recipient, 576 a DSN SHOULD NOT be issued by the gateway. The gateway SHOULD 577 attempt to ensure that appropriate notification will be provided by 578 the foreign mail environment if eventual delivery failure occurs, 579 and that no notification will be issued on successful delivery. 581 (e) When gatewaying a message into a foreign environment, the return-of- 582 content conditions specified by any RET parameter are nonbinding; 583 however, the MTA SHOULD attempt to honor the request using whatever 584 mechanisms exist in the foreign environment. 586 7.2.5 Delays in delivery 588 If a conforming MTA receives a message via the SMTP protocol, and is 589 unable to deliver or relay the message to one or more recipients for an 590 extended length of time (to be determined by the MTA), it MAY issue a 591 "delayed" DSN for those recipients, subject to the following conditions: 593 (a) If the NOTIFY parameter was supplied for a recipient and its value 594 included the DELAY keyword, a "delayed" DSN MAY be issued. 596 (b) If the NOTIFY parameter was not supplied for a recipient, a 597 "delayed" DSN MAY be issued. 599 (c) If the NOTIFY parameter was supplied which did not contain the DELAY 600 keyword, a "delayed" DSN MUST NOT be issued. 602 NOTE: Although delay notifications are common in present-day electronic 603 mail, a conforming MTA is never required to issue "delayed" DSNs. The 604 DELAY keyword of the NOTIFY parameter is provided to allow the SMTP 605 client to specifically request (by omitting the DELAY parameter) that 606 "delayed" DSNs NOT be issued. 608 7.2.6 Failure of a conforming MTA to deliver a message 610 The following rules govern the behavior of a conforming MTA which 611 received a message via the SMTP protocol, and is unable to deliver a 612 message to a recipient specified in the SMTP transaction: 614 (a) If a NOTIFY parameter was supplied for the recipient with an esmtp- 615 keyword containing the value FAILURE, a "failed" DSN MUST be issued 616 by the MTA. 618 (b) If a NOTIFY parameter was supplied for the recipient which did not 619 contain the value FAILURE, a DSN MUST NOT be issued for that 620 recipient. However, the MTA MAY inform the local postmaster of the 621 delivery failure via some appropriate mechanism which does not 622 itself result in the generation of DSNs. 624 (c) If no NOTIFY parameter was supplied for the recipient, a "failed" 625 DSN MUST be issued. 627 NOTE: Some MTAs are known to forward undeliverable messages to the 628 local postmaster or "dead letter" mailbox. This is still considered 629 delivery failure, and does not diminish the requirement to issue a 630 "failed" DSN under the conditions defined elsewhere in this memo. If a 631 DSN is issued for such a recipient, the Action value MUST be "failed". 633 7.2.7 Forwarding, aliases, and mailing lists 635 Delivery of a message to a local email address usually causes the 636 message to be stored in the recipient's mailbox. However, MTAs commonly 637 provide a facility where a local email address can be designated as an 638 "alias" or "mailing list"; delivery to that address then causes the 639 message to be forwarded to each of the (local or remote) recipient 640 addresses associated with the alias or list. It is also common to allow 641 a user to optionally "forward" her mail to one or more alternate 642 addresses. If this feature is enabled, her mail is redistributed to 643 those addresses instead of being deposited in her mailbox. 645 Following the example of [9] (section 5.3.6), this document defines 646 the difference between an "alias" and "mailing list" as follows: When 647 forwarding a message to the addresses associated with an "alias", the 648 envelope return address (e.g. SMTP MAIL FROM) remains intact. However, 649 when forwarding a message to the addresses associated with a "mailing 650 list", the envelope return address is changed to that of the 651 administrator of the mailing list. This causes DSNs and other 652 nondelivery reports resulting from delivery to the list members to be 653 sent to the list administrator rather than the sender of the original 654 message. 656 The DSN processing for aliases and mailing lists is as follows: 658 7.2.7.1 mailing lists 660 When a message is delivered to a list submission address (i.e. placed 661 in the list's mailbox for incoming mail, or accepted by the process that 662 redistributes the message to the list subscribers), this is considered 663 final delivery for the original message. If the NOTIFY parameter for 664 the list submission address contained the SUCCESS keyword, a "delivered" 665 DSN MUST be returned to the sender of the original message. 667 NOTE: Some mailing lists are able to reject message submissions, 668 based on the content of the message, the sender's address, or some other 669 criteria. While the interface between such a mailing list and its MTA 670 is not well-defined, it is important that DSNs NOT be issued by both the 671 MTA (to report successful delivery to the list), and the list (to report 672 message rejection using a "failure" DSN.) 674 However, even if a "delivered" DSN was issued by the MTA, a mailing 675 list which rejects a message submission MAY notify the sender that the 676 message was rejected using an ordinary message instead of a DSN. 678 Whenever a message is redistributed to an mailing list, 680 (a) The envelope return address is rewritten to point to the list 681 maintainer. This address MAY be that of a process that recognizes 682 DSNs and processes them automatically, but it MUST forward 683 unrecognized messages to the human responsible for the list. 685 (b) The ENVID, NOTIFY, RET, and ORCPT parameters which accompany the 686 redistributed message MUST NOT be derived from those of the original 687 message. 689 (c) The NOTIFY and RET parameters MAY be specified by the local 690 postmaster or the list administrator. If ORCPT parameters are 691 supplied during redistribution to the list subscribers, they SHOULD 692 contain the addresses of the list subscribers in the format used by 693 the mailing list. 695 7.2.7.2 single-recipient aliases 697 Under normal circumstances, when a message arrives for an "alias" 698 which has a single forwarding address, a DSN SHOULD NOT be issued. Any 699 ENVID, NOTIFY, RET, or ORCPT parameters SHOULD be propagated with the 700 message as it is redistributed to the forwarding address. 702 7.2.7.3 multiple-recipient aliases 704 An "alias" with multiple recipient addresses may be handled in any of 705 the following ways: 707 (a) Any ENVID, NOTIFY, RET, or ORCPT parameters are NOT propagated when 708 relaying the message to any of the forwarding addresses. If the 709 NOTIFY parameter for the alias contained the SUCCESS keyword, the 710 MTA issues a "relayed" DSN. (In effect, the MTA treats the message 711 as if it were being relayed into an environment that does not 712 support DSNs.) 714 (b) Any ENVID, NOTIFY, RET, or ORCPT parameters (or the equivalent 715 requests if the message is gatewayed) are propagated to EXACTLY one 716 of the forwarding addresses. No DSN is issued. (This is 717 appropriate when aliasing is used to forward a message to a 718 "vacation" auto-responder program in addition to the local mailbox.) 720 (c) Any ENVID, RET, or ORCPT parameters are propagated to all forwarding 721 addresses associated with that alias. The NOTIFY parameter is 722 propagated to the forwarding addresses, except that it any SUCCESS 723 keyword is removed. If the original NOTIFY parameter for the alias 724 contained the SUCCESS keyword, no DSN is issued for the alias. If 725 the NOTIFY parameter for the alias did not contain the SUCCESS 726 keyword, an "expanded" DSN is issued for the alias. 728 7.2.7.4 confidential forwarding addresses 730 If it is desired to maintain the confidentiality of a recipient's 731 forwarding address, the forwarding may be treated as if it were a 732 mailing list. A DSN will be issued, if appropriate, upon "delivery" to 733 the recipient address specified by the sender. When the message is 734 forwarded it will have a new envelope return address. Any DSNs which 735 result from delivery failure of the forwarded message will not be 736 returned to the original sender of the message and thus not expose the 737 recipient's forwarding address. 739 7.2.8 DSNs describing delivery to multiple recipients 741 A single DSN may describe attempts to deliver a message to multiple 742 recipients of that message. If a DSN is issued for some recipients in 743 an SMTP transaction and not for others according to the rules above, the 744 DSN SHOULD NOT contain information for recipients for whom DSNs would 745 not otherwise have been issued. 747 7.3 Handling of messages from other sources 749 For messages which originated from "local" users (whatever that 750 means), the specifications under which DSNs should be generated can be 751 communicated to the MTA via any protocol agreed on between the sender's 752 mail composer (user agent) and the MTA. The local MTA can then either 753 relay the message, or issue appropriate delivery status notifications. 754 However, if such requests are transmitted within the message itself (for 755 example in the message headers), the requests MUST be removed from the 756 message before it is transmitted via SMTP. 758 For messages gatewayed from non-SMTP sources and further relayed by 759 SMTP, the gateway SHOULD, using the SMTP extensions described here, 760 attempt to provide the delivery reporting conditions expected by the 761 source mail environment. If appropriate, any DSNs returned to the 762 source environment SHOULD be translated into the format expected in that 763 environment. 765 7.4 Implementation limits 767 A conforming MTA MUST accept ESMTP parameters of at least the 768 following sizes: 770 (a) ENVID parameter: 100 characters. 772 (b) NOTIFY parameter: 28 characters. 774 (c) ORCPT parameter: 500 characters. 776 (d) RET parameter: 8 characters. 778 The maximum sizes for the ENVID and ORCPT parameters are intended to 779 be adequate for the transmission of "foreign" envelope identifier and 780 original recipient addresses. However, user agents which use SMTP as a 781 message submission protocol SHOULD NOT generate ENVID parameters which 782 are longer than 38 characters in length. 784 A conforming MTA MUST be able to accept SMTP command-lines which are 785 at least 1036 characters long (530 characters for the ORCPT and NOTIFY 786 parameters of the RCPT command, in addition to the 512 characters 787 required by [1]). If other SMTP extensions are supported by the MTA, 788 the MTA MUST be able to accept a command-line large enough for each SMTP 789 command and any combination of ESMTP parameters which may be used with 790 that command. 792 8. Format of delivery notifications 794 The format of delivery status notifications is defined in [5], which 795 uses the framework defined in [8]. Delivery status notifications are to 796 be returned to the sender of the original message as outlined below. 798 8.1 SMTP Envelope to be used with delivery status notifications 800 The DSN sender address (in the SMTP MAIL command) MUST be a null 801 reverse-path ("<>"), as required by section 5.3.3 of [9]. The DSN 802 recipient address (in the RCPT command) is copied from the MAIL command 803 which accompanied the message for which the DSN is being issued. When 804 transmitting a DSN via SMTP, the RET parameter MUST NOT be used. The 805 NOTIFY parameter MAY be used, but its value MUST be NEVER. The ENVID 806 parameter (with a newly generated envelope-id) and/or ORCPT parameter 807 MAY be used. 809 8.2 Contents of the DSN 811 A DSN is transmitted as a MIME message with a top-level content-type 812 of multipart/report (as defined in [5]). 814 The multipart/report content-type may be used for any of several 815 kinds of reports generated by the mail system. When multipart/report is 816 used to convey a DSN, the report-type parameter of the multipart/report 817 content-type is "delivery-status". 819 As described in [8], the first component of a multipart/report 820 content-type is a human readable explanation of the report. For a DSN, 821 the second component of the multipart/report is of content-type 822 message/delivery-status (defined in [5]). The third component of the 823 multipart/report consists of the original message or some portion 824 thereof. When the value of the RET parameter is FULL, the full message 825 SHOULD be returned for any DSN which conveys notification of delivery 826 failure. (However, if the length of the message is greater than some 827 implementation-specified length, the MTA MAY return only the headers 828 even if the RET parameter specified FULL.) If a DSN contains no 829 notifications of delivery failure, the MTA SHOULD return only the 830 headers. 832 The third component must have an appropriate content-type label. 833 Issues concerning selection of the content-type are discussed in [8]. 835 8.3 Message/delivery-status fields 837 The message/delivery-status content-type defines a number of fields, 838 with general specifications for their contents. The following 839 requirements for any DSNs generated in response to a message received by 840 the SMTP protocol by a conforming SMTP server, are in addition to the 841 requirements defined in [5] for the message/delivery-status type. 843 When generating a DSN for a message which was received via the SMTP 844 protocol, a conforming MTA will generate the following fields of the 845 message/delivery-status body part: 847 (a) if an ENVID parameter was present on the MAIL command, an Original- 848 Envelope-ID field MUST be supplied, and the value associated with 849 the ENVID parameter must appear in that field. If the message was 850 received via SMTP with no ENVID parameter, the Original-Envelope-ID 851 field MUST NOT be supplied. 853 Since the ENVID parameter is encoded as xtext, but the Original- 854 Envelope-ID header is NOT encoded as xtext, the MTA must decode the 855 xtext encoding when copying the ENVID value to the Original- 856 Envelope-ID field. 858 (b) The Reporting-MTA field MUST be supplied. It SHOULD contain the 859 domain name of the SMTP server which is actually issuing this 860 notification. The MTA-name-type subfield MUST be "dns". 862 (c) Other per-message fields as defined in [5] MAY be supplied as 863 appropriate. 865 (d) If the ORCPT parameter was provided for this recipient, the 866 Original-Recipient field MUST be supplied, with its value taken from 867 the ORCPT parameter. If no ORCPT parameter was provided for this 868 recipient, the Original-Recipient field MUST NOT appear. 870 (e) The Final-Recipient field MUST be supplied. It MUST contain the 871 recipient address from the message envelope. If the message was 872 received via SMTP, the address-type will be "rfc822". 874 (f) The Action field MUST be supplied. 876 (g) The Status field MUST be supplied, using a status-code from [10]. 877 If there is no specific code which suitably describes a delivery 878 failure, either 4.0.0 (temporary failure), or 5.0.0 (permanent 879 failure) MUST be used. 881 (h) For DSNs resulting from attempts to relay a message to one or more 882 recipients via SMTP, the Remote-MTA field MUST be supplied for each 883 of those recipients. The mta-name-type subfields of those Remote- 884 MTA fields will be "dns". 886 (i) For DSNs resulting from attempts to relay a message to one or more 887 recipients via SMTP, the Diagnostic-Code MUST be supplied for each 888 of those recipients. The diagnostic-type subfield will be "smtp". 889 See section 10.2(a) of this document for a description of the "smtp" 890 diagnostic-code. 892 (j) For DSNs resulting from attempts to relay a message to one or more 893 recipients via SMTP, an SMTP-Remote-Recipient extension field MAY be 894 supplied for each recipient, which contains the address of that 895 recpient which was presented to the remote SMTP server. 897 (k) Other per-recipient fields defined in [5] MAY appear, as 898 appropriate. 900 9. Acknowledgments 902 The author wishes to thank Eric Allman, Harald Alvestrand, Jim 903 Conklin, Peter Cowen, Dave Crocker, Roger Fajman, Ned Freed, Marko 904 Kaittola, Steve Kille, John Klensin, Anastasios Kotsikonas, John 905 Gardiner Myers, Julian Onions, Jacob Palme, Marshall Rose, and Greg 906 Vaudreuil for their suggestions for improvement of this document. 908 10. Appendix - Type-Name Definitions 910 The following type names are defined for use in DSN fields generated 911 by conforming SMTP-based MTAs: 913 10.1 "rfc822" address-type 915 The "rfc822" address-type is to be used when reporting Internet 916 electronic mail address in the Original-Recipient and Final-Recipient 917 DSN fields. 919 (a) address-type name: rfc822 921 (b) syntax for mailbox addresses 923 RFC822 mailbox addresses are generally expected to be of the form 925 [route] addr-spec 927 where "route" and "addr-spec" are defined in [2], and the "domain" 928 portions of both "route" and "addr-spec" are fully-qualified domain 929 names that are registered in the DNS. However, an MTA MUST NOT 930 modify an address obtained from the message envelope to force it to 931 conform to syntax rules. 933 (c) If addresses of this type are not composed entirely of graphic 934 characters from the US-ASCII repertoire, a specification for how they 935 are to be encoded as graphic US-ASCII characters in a DSN Original- 936 Recipient or Final-Recipient DSN field. 938 RFC822 addresses consist entirely of graphic characters from the US- 939 ASCII repertoire, so no translation is necessary. 941 10.2 "smtp" diagnostic-type 943 The "smtp" diagnostic-type is to be used when reporting SMTP reply- 944 codes in Diagnostic-Code DSN fields. 946 (a) diagnostic-type name: SMTP 948 (b) A description of the syntax to be used for expressing diagnostic 949 codes of this type as graphic characters from the US-ASCII repertoire. 951 An SMTP diagnostic-code is of the form 953 *( 3*DIGIT "-" *text ) 3*DIGIT SPACE *text 955 For a single-line SMTP reply to an SMTP command, the diagnostic-code 956 SHOULD be an exact transcription of the reply. For multi-line SMTP 957 replies, it is necessary to insert a SPACE before each line after 958 the first. For example, an SMTP reply of: 960 550-mailbox unavailable 961 550 user has moved with no forwarding address 963 could appear as follows in a Diagnostic-Code DSN field: 965 Diagnostic-Code: smtp ; 550-mailbox unavailable 966 550 user has moved with no forwarding address 968 (c) A list of valid diagnostic codes of this type and the meaning of 969 each code. 971 SMTP reply-codes are currently defined in [1], [4], and [9]. 972 Additional codes may be defined by other RFCs. 974 10.3 "dns" MTA-name-type 976 The "dns" MTA-name-type should be used in the Reporting-MTA field. 977 An MTA-name of type "dns" is a fully-qualified domain name. The name 978 must be registered in the DNS, and the address Postmaster@{mta-name} 979 must be valid. 981 (a) MTA-name-type name: dns 983 (b) A description of the syntax of MTA names of this type, using BNF, 984 regular expressions, ASN.1, or other non-ambiguous language. 986 MTA names of type "dns" SHOULD be valid Internet domain names. If 987 such domain names are not available, a domain-literal containing the 988 internet protocol address is acceptable. Such domain names 989 generally conform to the following syntax: 991 domain = real-domain / domain-literal 993 real-domain = sub-domain *("." sub-domain) 995 sub-domain = atom 997 domain-literal = "[" 1*3DIGIT 3("." 1*3DIGIT) "]" 999 where "atom" and "DIGIT" are defined in [2]. 1001 (c) If MTA names of this type do not consist entirely of graphic 1002 characters from the US-ASCII repertoire, a specification for how an MTA 1003 name of this type should be expressed as a sequence of graphic US-ASCII 1004 characters. 1006 MTA names of type "dns" consist entirely of graphic US-ASCII 1007 characters, so no translation is needed. 1009 11. Appendix - Example 1011 This example traces the flow of a single message addressed to 1012 multiple recipients. The message is sent by Alice@Pure-Heart.ORG to 1013 Bob@Big-Bucks.COM, Carol@Ivory.EDU, Dana@Ivory.EDU, Eric@Bombs.AF.MIL, 1014 Fred@Bombs.AF.MIL, and George@Tax-ME.GOV, with a variety of per- 1015 recipient options. The message is successfully delivered to Bob, Dana 1016 (via a gateway), Eric, and Fred. Delivery fails for Carol and George. 1018 11.1 Submission 1020 Alice's user agent sends the message to the SMTP server at Pure- 1021 Heart.ORG. Note that while this example uses SMTP as a mail submission 1022 protocol, other protocols could also be used. 1024 <<< 220 Pure-Heart.ORG SMTP server here 1025 >>> EHLO Pure-Heart.ORG 1026 <<< 250-Pure-Heart.ORG 1027 <<< 250-DSN 1028 <<< 250-EXPN 1029 <<< 250 SIZE 1030 >>> MAIL FROM: RET=HDRS ENVID=QQ314159 1031 <<< 250 sender ok 1032 >>> RCPT TO: NOTIFY=SUCCESS ORCPT=Bob@Big-Bucks.COM 1033 <<< 250 recipient ok 1034 >>> RCPT TO: NOTIFY=FAILURE ORCPT=Carol@Ivory.EDU 1035 <<< 250 recipient ok 1036 >>> RCPT TO: NOTIFY=SUCCESS,FAILURE ORCPT=Dana@Ivory.EDU 1037 <<< 250 recipient ok 1038 >>> RCPT TO: NOTIFY=FAILURE ORCPT=Eric@Bombs.AF.MIL 1039 <<< 250 recipient ok 1040 >>> RCPT TO: NOTIFY=NEVER 1041 <<< 250 recipient ok 1042 >>> RCPT TO: NOTIFY=FAILURE ORCPT=George@Tax-ME.GOV 1043 <<< 250 recipient ok 1044 >>> DATA 1045 <<< 354 okay, send message 1046 >>> (message goes here) 1047 >>> . 1048 <<< 250 message accepted 1049 >>> QUIT 1050 <<< 221 goodbye 1051 11.2 Relay to Big-Bucks.COM 1053 The SMTP at Pure-Heart.ORG then relays the message to Big-Bucks.COM. 1054 (For the purpose of this example, mail.Big-Bucks.COM is the primary mail 1055 exchanger for Big-Bucks.COM). 1057 <<< 220 mail.Big-Bucks.COM says hello 1058 >>> EHLO Pure-Heart.ORG 1059 <<< 250-mail.Big-Bucks.COM 1060 <<< 250 DSN 1061 >>> MAIL FROM: RET=HDRS ENVID=QQ314159 1062 <<< 250 sender okay 1063 >>> RCPT TO: NOTIFY=SUCCESS ORCPT=Bob@Big-Bucks.COM 1064 <<< 250 recipient okay 1065 >>> DATA 1066 <<< 354 send message 1067 >>> (message goes here) 1068 >>> . 1069 <<< 250 message received 1070 >>> QUIT 1071 <<< 221 bcnu 1072 11.3 Relay to Ivory.EDU 1074 The SMTP at Pure-Heart.ORG relays the message to Ivory.EDU, which (as 1075 it happens) is a gateway to a LAN-based mail system that accepts SMTP 1076 mail and supports the DSN extension. 1078 <<< 220 Ivory.EDU gateway to FooMail(tm) here 1079 >>> EHLO Pure-Heart.ORG 1080 <<< 250-Ivory.EDU 1081 <<< 250 DSN 1082 >>> MAIL FROM: RET=HDRS ENVID=QQ314159 1083 <<< 250 ok 1084 >>> RCPT TO: NOTIFY=FAILURE ORCPT=Carol@Ivory.EDU 1085 <<< 550 error - no such recipient 1086 >>> RCPT TO: NOTIFY=SUCCESS,FAILURE ORCPT=Dana@Ivory.EDU 1087 <<< 250 recipient ok 1088 >>> DATA 1089 <<< 354 send message, end with '.' 1090 >>> (message goes here) 1091 >>> . 1092 <<< 250 message received 1093 >>> QUIT 1094 <<< 221 bye 1096 Note that since the Ivory.EDU refused to accept mail for 1097 Carol@Ivory.EDU, and the sender specified NOTIFY=FAILURE, the sender- 1098 SMTP (in this case Pure-Heart.ORG) must generate a DSN. 1100 11.4 Relay to Bombs.AF.MIL 1102 The SMTP at Pure-Heart.ORG relays the message to Bombs.AF.MIL, which 1103 does not support the SMTP extension. Because the sender specified 1104 NOTIFY=NEVER for recipient Fred@Bombs.AF.MIL, the SMTP at Pure-Heart.ORG 1105 chooses to send the message for that recipient in a separate transaction 1106 with a reverse-path of <>. 1108 <<< 220-Bombs.AF.MIL reporting for duty. 1109 <<< 220 Electronic mail is to be used for official business only. 1110 >>> EHLO Pure-Heart.ORG 1111 <<< 502 command not implemented 1112 >>> RSET 1113 <<< 250 reset 1114 >>> HELO Pure-Heart.ORG 1115 <<< 250 Bombs.AF.MIL 1116 >>> MAIL FROM: 1117 <<< 250 ok 1118 >>> RCPT TO: 1119 <<< 250 ok 1120 >>> DATA 1121 <<< 354 send message 1122 >>> (message goes here) 1123 >>> . 1124 <<< 250 message accepted 1125 >>> MAIL FROM:<> 1126 <<< 250 ok 1127 >>> RCPT TO: 1128 <<< 250 ok 1129 >>> DATA 1130 <<< 354 send message 1131 >>> (message goes here) 1132 >>> . 1133 <<< 250 message accepted 1134 >>> QUIT 1135 <<< 221 Bombs.AF.MIL closing connection 1136 11.5 Forward from George@Tax-ME.GOV to Sam@Boondoggle.GOV 1138 The SMTP at Pure-Heart.ORG relays the message to Tax-ME.GOV. (this 1139 step is not shown). MTA Tax-ME.GOV then forwards the message to 1140 Sam@Boondoggle.GOV (shown below). Both Tax-ME.GOV and Pure-Heart.ORG 1141 support the SMTP DSN extension. Note that RET, ENVID, and ORCPT all 1142 retain their original values. 1144 <<< 220 BoonDoggle.GOV says hello 1145 >>> EHLO Pure-Heart.ORG 1146 <<< 250-mail.Big-Bucks.COM 1147 <<< 250 DSN 1148 >>> MAIL FROM: RET=HDRS ENVID=QQ314159 1149 <<< 250 sender okay 1150 >>> RCPT TO: NOTIFY=SUCCESS ORCPT=George@Tax-ME.GOV 1151 <<< 250 recipient okay 1152 >>> DATA 1153 <<< 354 send message 1154 >>> (message goes here) 1155 >>> . 1156 <<< 250 message received 1157 >>> QUIT 1158 <<< 221 bcnu 1159 11.6 "Delivered" DSN for Bob@Big-Bucks.COM 1161 MTA mail.Big-Bucks.COM successfully delivers the message to Bob@Big- 1162 Bucks.COM. Because the sender specified NOTIFY=SUCCESS, mail.Big- 1163 Bucks.COM issues the following DSN, and sends it to Alice@Pure- 1164 Heart.ORG. 1166 To: Alice@Pure-Heart.ORG 1167 From: postmaster@mail.Big-Bucks.COM 1168 Subject: Delivery Notification (success) for Bob@Big-Bucks.COM 1169 Content-Type: multipart/report; report-type=delivery-status; 1170 boundary=abcde 1171 MIME-Version: 1.0 1173 --abcde 1174 Content-type: text/plain; charset=us-ascii 1176 Your message (id QQ314159) was successfully delivered to 1177 Bob@Big-Bucks.COM. 1179 --abcde 1180 Content-type: message/delivery-status 1182 Reporting-MTA: dns; mail.Big-Bucks.COM 1183 Original-Envelope-ID: QQ314159 1185 Original-Recipient: rfc822; Bob@Big-Bucks.COM 1186 Final-Recipient: rfc822; Bob@Big-Bucks.COM 1187 Action: delivered 1188 Status: 2.0.0 1190 --abcde 1191 Content-type: message/rfc822 1193 (headers of returned message go here) 1195 --abcde-- 1196 11.7 Failed DSN for Carol@Ivory.EDU 1198 Because delivery to Carol failed and the sender specified 1199 NOTIFY=FAILURE for Carol@Ivory.EDU, MTA Pure-Heart.ORG (the SMTP client 1200 to which the failure was reported via SMTP) issues the following DSN. 1202 To: Alice@Pure-Heart.ORG 1203 From: postmaster@Pure-Heart.ORG 1204 Subject: Delivery Notification (failure) for Carol@Ivory.EDU 1205 Content-Type: multipart/report; report-type=delivery-status; 1206 boundary=bcdef 1207 MIME-Version: 1.0 1209 --bcdef 1210 Content-type: text/plain; charset=us-ascii 1212 Your message (id QQ314159) could not be delivered to 1213 Carol@Ivory.EDU. 1215 A transcript of the session follows: 1217 (while talking to Ivory.EDU) 1218 >>> RCPT TO: NOTIFY=FAILURE 1219 <<< 550 error - no such recipient 1221 --bcdef 1222 Content-type: message/delivery-status 1224 Reporting-MTA: dns; Pure-Heart.ORG 1225 Original-Envelope-ID: QQ314159 1227 Original-Recipient: rfc822; Carol@Ivory.EDU 1228 Final-Recipient: rfc822; Carol@Ivory.EDU 1229 SMTP-Remote-Recipient: Carol@Ivory.EDU 1230 Diagnostic-Code: smtp; 550 error - no such recipient 1231 Action: failed 1232 Status: 5.0.0 1234 --bcdef 1235 Content-type: message/rfc822 1237 (headers of returned message go here) 1239 --bcdef-- 1240 11.8 Relayed DSN For Dana@Ivory.EDU 1242 Although the mail gateway Ivory.EDU supports the DSN SMTP extension, 1243 the LAN mail system attached to its other side does not generate 1244 positive delivery confirmations. So Ivory.EDU issues a "relayed" DSN: 1246 To: Alice@Pure-Heart.ORG 1247 From: postmaster@Ivory.EDU 1248 Subject: mail relayed for Dana@Ivory.EDU 1249 Content-Type: multipart/report; report-type=delivery-status; 1250 boundary=cdefg 1251 MIME-Version: 1.0 1253 --cdefg 1254 Content-type: text/plain; charset=us-ascii 1256 Your message (addressed to Dana@Ivory.EDU) was successfully 1257 relayed to: 1259 ymail!Dana 1261 by the FooMail gateway at Ivory.EDU. 1263 Unfortunately, the remote mail system does not support 1264 confirmation of actual delivery. Unless delivery to ymail!Dana 1265 fails, this will be the only delivery status notification sent. 1267 --cdefg 1268 Content-type: message/delivery-status 1270 Reporting-MTA: dns; Ivory.EDU 1271 Original-Envelope-ID: QQ314159 1273 Original-Recipient: rfc822; Dana@Ivory.EDU 1274 Final-Recipient: rfc822; Dana@Ivory.EDU 1275 Action: relayed 1276 Status: 2.0.0 1278 --cdefg 1279 Content-type: message/rfc822 1281 (headers of returned message go here) 1283 --cdefg-- 1284 11.9 Failure notification for Sam@Boondoggle.GOV 1286 The message originally addressed to George@Tax-ME.GOV was forwarded 1287 to Sam@Boondoggle.GOV, but the MTA for Boondoggle.GOV was unable to 1288 deliver the message due to a lack of disk space in Sam's mailbox. After 1289 trying for several days, Boondoggle.GOV returned the following DSN: 1291 To: Alice@BigHeart.ORG 1292 From: Postmaster@Boondoggle.GOV 1293 Subject: Delivery failure for Sam@Boondoggle.GOV 1294 Content-Type: multipart/report; report-type=delivery-status; 1295 boundary=defgh 1296 MIME-Version: 1.0 1298 --defgh 1299 Your message, originally addressed to George@Tax-ME.GOV, and forwarded 1300 from there to Sam@Boondoggle.GOV could not be delivered, for the 1301 following reason: 1303 write error to mailbox, disk quota exceeded 1305 --defgh 1306 Content-type: message/delivery-status 1308 Reporting-MTA: Boondoggle.GOV 1309 Original-Envelope-ID: QQ314159 1311 Original-Recipient: rfc822; George@Tax-ME.GOV 1312 Final-Recipient: rfc822; Sam@Boondoggle.GOV 1313 Action: failed 1314 Status: 4.2.2 (disk quota exceeded) 1316 --defgh 1317 Content-type: message/rfc822 1319 (headers of returned message go here) 1321 --defgh-- 1322 12. References 1324 [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, 1325 USC/Information Sciences Institute, August 1982. 1327 [2] Crocker, D., "Standard for the Format of ARPA Internet Text 1328 Messages", STD 11, RFC 822, UDEL, August 1982. 1330 [3] Westine, A., Postel, J. "Problems with the Maintenance of Large 1331 Mailing Lists.", RFC 1211, USC/Information Sciences Institute, March 1332 1991. 1334 [4] Klensin, J., Freed, N., Rose, M., Stefferud, E., Crocker., D. "SMTP 1335 Service Extensions", RFC 1651, MCI, Innosoft, Dover Beach 1336 Consulting, Inc., Network Management Associates, Inc., Silicon 1337 Graphics, Inc., July 1994. 1339 [5] Moore, K., Vaudreuil, G. "An Extensible Message Format for Delivery 1340 Status Notifications", Internet-Draft draft-ietf-notary-mime- 1341 delivery-05.txt, 29 May 1995. 1343 [6] Crispin, M. "Internet Message Access Protocol - Version 4", RFC 1344 1730, University of Washington, 20 December 1994. 1346 [7] Myers, J., Rose, M. "Post Office Protocol - Version 3", RFC 1725, 1347 Carnegie Mellon, Dover Beach Consulting, 23 November 1994. 1349 [8] Vaudreuil, G. "The Multipart/Report Content Type for the Reporting 1350 of Mail System Administrative Messages". Internet-Draft draft-ietf- 1351 notary-mime-report-03.txt, 5 May 1995. 1353 [9] Braden, R. (ed). Requirements for Internet Hosts - Application and 1354 Support, RFC 1123, IETF, October 1989. 1356 [10] Vaudreuil, G. "Enhanced Mail System Status Codes". Internet-Draft 1357 draft-ietf-notary-status-03.txt, 5 May 1995. 1359 13. Author's address 1361 Keith Moore 1362 University of Tennessee 1363 107 Ayres Hall 1364 Knoxville, TN 37996-1301 1365 USA 1367 email: moore@cs.utk.edu