idnits 2.17.1 draft-ietf-notary-smtp-drpt-02.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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 16 longer pages, the longest (page 2) being 60 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 196: '...used, it MUST have an associated esmtp...' RFC 2119 keyword, line 221: '...e keyword "DELAY", a "delayed" DSN MAY...' RFC 2119 keyword, line 225: '... a "delayed" DSN SHOULD NOT be issued ...' RFC 2119 keyword, line 236: '...word is used, it MUST have an associat...' RFC 2119 keyword, line 253: '...used, it MUST have an associated esmtp...' (8 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: and associated esmtp-value, a conforming ESMTP server MUST return the same reply-code as it would to the same MAIL command without the ENVID and/or OMTS parameters. A conforming SMTP server MAY NOT refuse a MAIL command based on the presence or absence of ENVID or OMTS parameters, or on their associated esmtp-values. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: 2. If an SMTP client issues a RCPT command containing any valid NOTIFY, RET, and/or ORCPT parameters, a conforming SMTP server MUST return the same response as it would to the same RCPT command without those NOTIFY, RET, and ORCPT parameters. A conforming SMTP server MAY NOT refuse a RCPT command based on the presence or absence of any of these parameters. -- 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 (November 20, 1994) is 10749 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) -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 15 errors (**), 0 flaws (~~), 4 warnings (==), 5 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: May 20, 1995 November 20, 1994 5 SMTP Service Extension 6 for Delivery Status Notifications 8 draft-ietf-notary-smtp-drpt-02.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 allow 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 and the transaction in which the 36 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 the failed message. 48 Experiences with large mail distribution lists [3] indicates that 49 such 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 SMTP Delivery Status Notifications 20 November 1994 54 in Internet mail makes it difficult to exchange such notifications with 55 other message handling systems. 57 Such experience has demonstrated a need for a delivery status 58 notification service for Internet electronic mail, which: 60 (a) is reliable, in the sense that any DSN request will either be 61 honored at the time of final delivery, or result in a response that 62 indicates that the request cannot be honored, 64 (b) should result in exactly one response for any particular sender- 65 specified recipient, 67 (c) is stable, in that a DSN should never be issued in response to a 68 DSN. 70 (d) preserves sufficient information to allow the sender to identify 71 both the mail transaction and the recipient address which caused the 72 notification, even when mail is forwarded or gatewayed to foreign 73 environments, and 75 (e) interfaces acceptably with non-SMTP and non-822-based mail systems, 76 both so that notifications returned from foreign mail systems may be 77 useful to Internet users, and so that the notification requests from 78 foreign environments may be honored. Among the requirements implied 79 by this goal are the ability to request non-return-of-content, and 80 the ability to specify whether positive or negative delivery 81 notifications, or both, or neither, should be issued. 83 In an attempt to provide such a service, this memo uses the mechanism 84 defined in [4] to define an extension to the SMTP protocol. Using this 85 mechanism, an SMTP client may request that an SMTP server issue or not 86 issue a delivery status notification (DSN) under certain conditions. 87 The format of a DSN is defined in [5]. 89 4. Framework for the Delivery Status Notification Extension 91 The following service extension is therefore defined: 93 (1) The name of the SMTP service extension is "Delivery Status 94 Notification"; 96 (2) the EHLO keyword value associated with this extension is "DSN", the 97 meaning of which is defined in section 5 of this memo; 99 (3) no parameters are allowed with this EHLO keyword value; 101 (4) three optional parameters are added to the RCPT command, and two 102 optional parameters are added to the MAIL command: 104 SMTP Delivery Status Notifications 20 November 1994 106 An optional parameter for the RCPT command, using the esmtp-keyword 107 "NOTIFY", (to specify the conditions under which a delivery status 108 notification should be generated), is defined in section 6.1, 110 An optional parameter for the RCPT command, using the esmtp-keyword 111 "RET", (to request that DSNs either return or not return the 112 contents of a message), is defined in section 6.2, 114 An optional parameter for the RCPT command, using the esmtp-keyword 115 "ORCPT", (used to convey the "original" (sender-specified) recipient 116 address), is defined in section 6.3, and 118 An optional parameter for the MAIL command, using the esmtp-keyword 119 "OMTS", (used to specify the type of message transfer system in 120 which the message originated), is defined in section 6.4, and 122 An optional parameter for the MAIL command, using the esmtp-keyword 123 "ENVID", (used to propagate a sender-specified unique identifier for 124 this envelope, to be returned in a DSN), is defined in section 6.5; 126 (5) no additional SMTP verbs are defined by this extension. 128 The remainder of this memo specifies how support for the extension 129 affects the behavior of a message transfer agent. 131 5. The Delivery Status Notification service extension 133 An SMTP client wishing to request a DSN for a message may issue the 134 EHLO command to start an SMTP session, to determine if the server 135 supports any of several service extensions. If the server responds with 136 code 250 to the EHLO command, and the response includes the EHLO keyword 137 DSN, then the Delivery Status Notification extension (as described in 138 this memo) is supported. 140 Ordinarily, when an SMTP server returns a positive (2xx) reply code 141 in response to a RCPT command, it agrees to accept responsibility for 142 either delivering the message to the named recipient, or sending a 143 notification to the sender of the message indicating that delivery has 144 failed. However, an extended SMTP ("ESMTP") server which implements 145 this service extension will accept an optional NOTIFY parameter with the 146 RCPT command. If present, the NOTIFY parameter alters the default 147 conditions for generation of delivery status notifications from the 148 default (issue notifications only on failure) specified in [1]. The 149 ESMTP client may also request (via the RET parameter) whether the entire 150 contents of the original message should be returned (as opposed to just 151 the headers of that message), along with the DSN. 153 In general, an ESMTP server which implements this service extension 154 will propagate delivery status notification requests when relaying mail 155 to other SMTP-based MTAs which also support this extension, and make a 156 SMTP Delivery Status Notifications 20 November 1994 158 "best effort" to ensure that such requests are honored when messages are 159 passed into other environments. 161 In order that any delivery status notifications thus generated will 162 be meaningful to the sender, any ESMTP server which supports this 163 extension will attempt to propagate the following information to any 164 other MTAs that are used to relay the message, for use in generating 165 DSNs: 167 (a) for each recipient, a copy of the original recipient address, as 168 used by the sender of the message. 170 This address need not be the same as the mailbox specified in the 171 RCPT command. For example, the addresses will be different if the 172 message was forwarded from the sender-specified address to another 173 address, or the message originated in a foreign environment that 174 does not use Internet electronic mail addresses. 176 (b) for the entire SMTP transaction, an envelope identification string, 177 which may be used by the sender to associate any delivery status 178 notifications with the transaction used to send the original 179 message. 181 6. Additional parameters for RCPT and MAIL commands 183 The extended RCPT and MAIL commands are issued by a client when it 184 wishes to request a DSN from the server, under certain conditions, for a 185 particular recipient. The extended RCPT and MAIL commands are identical 186 to the RCPT and MAIL commands defined in [1], except that one or more of 187 the following parameters appear after the sender or recipient address, 188 respectively. The general syntax for extended SMTP commands is defined 189 in [4]. 191 6.1. The NOTIFY parameter of the ESMTP RCPT command 193 A RCPT command issued by a client may contain the optional esmtp- 194 keyword "NOTIFY", to specify the conditions under which the SMTP server 195 should generate DSNs for that recipient. If the NOTIFY esmtp-keyword is 196 used, it MUST have an associated esmtp-value, formatted according to the 197 following rules, using the ABNF of RFC 822: 199 notify-esmtp-value = "NEVER" / 1#notify-list-element 201 notify-list-element = "SUCCESS" / "FAILURE" / "DELAY" 203 Notes: 204 1. Multiple notify-list-elements, separated by commas, may appear in a 205 NOTIFY parameter; however, the NEVER keyword may only appear by 206 itself. 208 SMTP Delivery Status Notifications 20 November 1994 210 2. Any of the keywords NEVER, SUCCESS, FAILURE, or DELAY may be spelled 211 in any combination of upper and lower case letters. 212 3. Although RFC 822 ABNF syntax is used, RFC 822 style comments may not 213 appear in NOTIFY parameter values. 215 The meaning of the NOTIFY parameter values is generally as follows: 216 + If the esmtp-value consists of the keyword "NEVER", a DSN should not 217 be issued under any conditions. 218 + If on the other hand, the esmtp-value contains one or more of the 219 keywords "SUCCESS" or "FAILURE", a DSN should be issued on successful 220 delivery or delivery failure, respectively. 221 + If the esmtp-value contains the keyword "DELAY", a "delayed" DSN MAY 222 be issued if a message cannot be delivered or relayed for an extended 223 period of time, as determined by the MTA at which the message is 224 delayed. The absence of the DELAY keyword in a NOTIFY parameter 225 implies that a "delayed" DSN SHOULD NOT be issued under any 226 conditions. 228 If the NOTIFY parameter is not included in a RCPT command, the SMTP 229 server should issue notifications for that recipient only if the message 230 cannot be delivered, as specified in [1]. 232 6.2 The RET parameter of the ESMTP RCPT command 234 The RET esmtp-keyword on the extended RCPT command specifies whether 235 or not the message should be included in any DSN issued for this 236 recipient. If the RET esmtp-keyword is used, it MUST have an associated 237 esmtp-value, which should contain one of the following keywords: 239 FULL requests that the message be returned in any delivery status 240 notification issued for this recipient. 241 HDRS requests that only the headers of the message not be returned. 243 The RET parameter is optional; it need not be specified to request a 244 DSN. If the RET parameter was not specified for a particular recipient, 245 the MTA issuing the notification may choose to return either the entire 246 content, or only the headers of the original message. 248 6.3 The ORCPT parameter to the ESMTP RCPT command 250 The ORCPT esmtp-keyword of the RCPT command is used to specify an 251 "original" recipient address that corresponds to the actual recipient to 252 which the message is to be delivered. If the ORCPT esmtp-keyword is 253 used, it MUST have an associated esmtp-value, which consists of the 254 original recipient address, encoded according to the rules below. 256 IMPORTANT: Because a message may have originated in a foreign 257 environment that does not use Internet-style electronic mail addresses, 258 the esmtp-value associated with the ORCPT keyword is NOT constrained to 259 SMTP Delivery Status Notifications 20 November 1994 261 conform to syntax rules for Internet addresses. 263 Ideally, the esmtp-value associated with this parameter should 264 contain (in encoded form) the same sequence of characters that the 265 sender used to specify the recipient. However, for a message gatewayed 266 from an environment (such as X.400) in which a recipient address is not 267 a simple string of printable characters, the ORCPT parameter should 268 contain a printable representation of the recipient address that is 269 likely to be recognized by the sender. 271 Any valid esmtp-value (as defined in [4]) may be associated with the 272 ORCPT keyword. However, the syntax for an esmtp-value does not allow 273 the use of certain characters. Since such characters might appear in 274 the original recipient address, the following scheme is used to encode 275 the original recipient address into a valid esmtp-value: 277 1. Any graphic ASCII character (range 32-126 inclusive), except for "=", 278 SP, and "%", may be encoded as itself. 280 2. Any octet value may be encoded using the percent character ("%") 281 followed by two hex digits. 283 The ORCPT parameter is optional. It should not be supplied by the 284 SMTP client if the original recipient address (or a reasonable 285 printable-text representation thereof) is not available to the client. 287 6.4 The OMTS parameter to the ESMTP MAIL command 289 The OMTS esmtp-keywoard of the SMTP MAIL command is used to specify 290 the "original MTS type", which identifies the type of mail system from 291 which the message originated, and will appear in the Original-MTS-Type 292 field in any DSNs generated for this message. 294 The OMTS esmtp-keyword must have an associated esmtp-value. The 295 esmtp-value associated with this parameter must be a legal MTS-type, as 296 defined in [5]. 298 Note: The definition of the MTS-type indicated by the OMTS esmtp- 299 keyword may specify the syntax of recipient addresses to be used in 300 Delivery Status Notifications. Whenever a foreign address does not 301 consist entirely of printable ASCII characters, the definition of the 302 sender's MTS-type (as supplied in the OMTS parameter) governs how such 303 foreign addresses are expressed via the ORCPT parameter as well as in 304 DSNs. 306 The OMTS parameter is optional. It should not be supplied to an SMTP 307 server if the original MTS-type is not known by the client. 309 SMTP Delivery Status Notifications 20 November 1994 311 6.5 The ENVID parameter to the ESMTP MAIL command 313 The ENVID esmtp-keyword of the SMTP MAIL command is used to specify 314 an "envelope identifier" to be transmitted along with the message and 315 included in any DSNs issued for any of the recipients named in this SMTP 316 transaction. The purpose of the envelope identifier is to allow the 317 sender of a message to identify the transaction for which the DSN was 318 issued. 320 The ENVID esmtp-keyword MUST have an associated esmtp-value. No 321 meaning is assigned by the mail system to the presence or absence of 322 this parameter or to any esmtp-value associated with this parameter; the 323 information is used only by the sender or his user agent. 325 Use of the ENVID esmtp-keyword is optional. It need not be specified 326 to request a DSN. 328 6.6. Restrictions on the use of Delivery Status Notification parameters 330 No more than one each of the OMTS and ENVID parameters may appear in 331 a single MAIL command. If more than one of either of these parameters 332 appears in a MAIL command, the ESMTP server should respond with "501 333 syntax error in parameters or arguments". 335 No more than one each of the NOTIFY, RET, and ORCPT parameters may 336 appear in any RCPT command. If multiple occurrences of any of these 337 parameters appear in a RCPT command, the ESMTP server should respond 338 with "501 syntax error in parameters or arguments". 340 7. MTA conformance requirements 342 Typically, a message transfer agent (MTA) which supports SMTP will 343 assume, at different times, both the role of a SMTP client and an SMTP 344 server, and may also provide local delivery, gatewaying to foreign 345 environments, forwarding, and mailing list expansion. An MTA which, (in 346 its role as an SMTP server) issues the DSN keyword in response to the 347 EHLO command, MUST obey the rules below for a "conforming MTA" below. 348 The terms "conforming SMTP client" and "conforming SMTP server" refer to 349 a "conforming MTA" when acting in the role of an SMTP server or client, 350 respectively. 352 7.1 ESMTP protocol interactions 354 The following rules apply to ESMTP transactions in which any of the 355 OMTS, ENVID, NOTIFY, RET, or ORCPT keywords are used: 357 1. If an SMTP client issues a MAIL command containing a valid ENVID 358 parameter and associated esmtp-value and/or a valid OMTS parameter 359 SMTP Delivery Status Notifications 20 November 1994 361 and associated esmtp-value, a conforming ESMTP server MUST return the 362 same reply-code as it would to the same MAIL command without the 363 ENVID and/or OMTS parameters. A conforming SMTP server MAY NOT 364 refuse a MAIL command based on the presence or absence of ENVID or 365 OMTS parameters, or on their associated esmtp-values. 367 However, if the associated esmtp-keyword is not valid (i.e. contains 368 illegal characters), or if there is more than one ENVID or OMTS 369 parameter in a particular MAIL command, the server should issue the 370 response "501 syntax error in parameter". 372 2. If an SMTP client issues a RCPT command containing any valid NOTIFY, 373 RET, and/or ORCPT parameters, a conforming SMTP server MUST return 374 the same response as it would to the same RCPT command without those 375 NOTIFY, RET, and ORCPT parameters. A conforming SMTP server MAY NOT 376 refuse a RCPT command based on the presence or absence of any of 377 these parameters. 379 However, if any of the associated esmtp-keywords are not valid, or if 380 there is more than one of any of these parameters in a particular 381 RCPT command, the server should issue the response "501 syntax error 382 in parameter". 384 7.2. Handling of messages received via SMTP 386 This section describes how a conforming MTA should handle any 387 messages received via SMTP. 389 7.2.1. Relay of messages to other conforming SMTP servers 391 The following rules govern the behavior of a conforming SMTP client, 392 when relaying a message which was received via the SMTP protocol, to an 393 SMTP server that supports the Delivery Status Notification service 394 extension: 396 1. Any ENVID parameter included in the MAIL command when a message was 397 received, must also appear on the MAIL command with which the message 398 is relayed, with the same associated esmtp-value. If no ENVID 399 parameter was included in the MAIL command when the message was 400 received, no ENVID parameter shall be supplied when the message is 401 relayed. 403 2. Any OMTS parameter included in the MAIL command when a message was 404 received, must also appear on the MAIL command with which the message 405 is relayed, with the same associated esmtp-value. If not OMTS 406 parameter was included in the MAIL command when the message was 407 received, no OMTS parameter shall be supplied when the message is 408 relayed. 410 SMTP Delivery Status Notifications 20 November 1994 412 3. If the NOTIFY parameter was supplied for a recipient when the message 413 was received, the RCPT command issued when the message is relayed 414 must also contain the NOTIFY parameter along with its associated 415 esmtp-value. If any RET or ORCPT parameters were present in the RCPT 416 command for this recipient when the message was received, they must 417 also appear in the RCPT command issued when relaying the message. 418 When relaying a message to a particular recipient, no NOTIFY, RET, or 419 ORCPT parameters may be supplied which were not present in the RCPT 420 command for that recipient when the message was received. 422 7.2.2. Relay of messages to non-conforming SMTP servers 424 The following rules govern the behavior of a conforming SMTP client, 425 when relaying a message which was received via the SMTP protocol, to an 426 SMTP server that does not support the Delivery Status Notification 427 service extension: 429 1. No ENVID, OMTS, NOTIFY, RET, or ORCPT parameters may be issued when 430 relaying the message. 432 2. If the NOTIFY parameter was supplied for a recipient, with an esmtp- 433 value containing the keyword SUCCESS, and the SMTP server returns a 434 success (2XX) reply-code in response to the RCPT command, the client 435 must issue a "relayed" DSN for that recipient. 437 3. If the NOTIFY parameter was supplied for a recipient with an esmtp- 438 value containing the keyword FAILURE, and the SMTP server returns a 439 permanent failure (5XX) reply-code in response to the RCPT command, 440 the client must issue a "failed" DSN for that recipient. 442 4. If the NOTIFY parameter was supplied for a recipient with an esmtp- 443 value of NEVER, no DSN is issued, regardless of the reply-code 444 returned by the SMTP server. 446 5. If a NOTIFY parameter was not supplied for a recipient, and the SMTP 447 server returns a success (2xx) reply-code in response to a RCPT 448 command, the client must not issue any DSN for that recipient. 450 6. If a NOTIFY parameter was not supplied for a recipient, and the SMTP 451 server returns a permanent failure (5XX) reply-code in response to a 452 RCPT command, the client must issue a "failed" DSN for that 453 recipient. 455 7.2.3. Local delivery of messages 457 The following rules govern the behavior of a conforming MTA upon 458 successful delivery of a message that was received via the SMTP 459 protocol, to a local recipient's mailbox: 461 SMTP Delivery Status Notifications 20 November 1994 463 1. If the NOTIFY parameter was supplied for that recipient, with an 464 esmtp-value containing the SUCCESS keyword, the MTA must issue a 465 "delivered" DSN for that recipient. 467 2. If the NOTIFY parameter was supplied for that recipient with an 468 esmtp-value of NEVER, no DSN is issued. 470 3. If the NOTIFY parameter was not supplied for that recipient, no DSN 471 is issued. 473 7.2.4. Gatewaying a message into a foreign environment 475 The following rules govern the behavior of a conforming MTA, when 476 gatewaying a message that was received via the SMTP protocol, into a 477 foreign (non-SMTP) environment: 479 1. If the the foreign environment is capable of issuing appropriate 480 notifications under the conditions requested by the NOTIFY parameter, 481 and the conforming MTA can ensure that any notification thus issued 482 will be translated into a DSN and delivered to the original sender, 483 then the MTA should gateway the message into the foreign environment, 484 requesting notification under the desired conditions, without itself 485 issuing a DSN. 487 2. If a NOTIFY parameter was supplied with either or both of the SUCCESS 488 or FAILURE keywords, but the requested conditions specified by the 489 associated esmtp-value cannot be met by the foreign mail environment, 490 the MTA should issue a "relayed" DSN for that recipient. 492 3. If a NOTIFY parameter was supplied with an esmtp-keyword of NEVER, no 493 DSN should be issued. 495 4. If the NOTIFY parameter was not supplied for a particular recipient, 496 no DSN should be issued by the gateway, but the gateway should 497 attempt to ensure that appropriate notification will be provided by 498 the foreign mail environment if eventual delivery failure occurs. 500 5. When gatewaying a message into a foreign environment, the return-of- 501 content conditions specified by any RET parameter are nonbinding; 502 however, the MTA should attempt to honor the request using whatever 503 mechanisms exist in the foreign environment. 505 7.2.5. Delays in delivery 507 A conforming MTA which receives a message via the SMTP protocol which 508 is unable to deliver a message to one or more recipients for an extended 509 length of time (to be determined by the MTA), may issue a "delayed" DSN 510 for those recipients, under the following conditions: 512 SMTP Delivery Status Notifications 20 November 1994 514 1. If the NOTIFY parameter was supplied for a recipient and its value 515 included the DELAY keyword, a "delayed" DSN may be issued. 517 2. If the NOTIFY parameter was not supplied for a recipient, a "delayed" 518 DSN may be issued. 520 3. If the NOTIFY parameter was supplied which did not contain the DELAY 521 keyword, a "delayed" DSN may not be issued. 523 NOTE: Although delay notifications are common in present-day email, a 524 conforming MTA is never required to issue "delayed" DSNs. The DELAY 525 keyword of the NOTIFY parameter is provided to allow the SMTP client to 526 specifically request (by omitting the DELAY parameter) that "delayed" 527 DSNs NOT be issued. 529 7.2.6. Failure of a conforming MTA to deliver a message 531 The following rules govern the behavior of a conforming MTA which 532 received a message via the SMTP protocol, and is unable to deliver a 533 message to a recipient specified in the SMTP transaction: 535 1. If a NOTIFY parameter was supplied for the recipient with an esmtp- 536 keyword containing the value FAILURE, a "failed" DSN should be issued 537 by the MTA. 539 2. If a NOTIFY parameter was supplied for the recipient which did not 540 contain the value FAILURE, no DSN should be issued for that 541 recipient. 543 3. If no NOTIFY parameter was supplied for the recipient, a "failure" 544 DSN should be issued. 546 7.2.7. Recipient-specified mail forwarding 548 If a message intended for a particular recipient address is to be 549 "forwarded" to exactly one recipient address: 551 1. Any envelope-id and original-mts-type included with the message as 552 received, should be propagated in each ESMTP session used to forward 553 the message to a conforming MTA. 555 2. Any NOTIFY, ORCPT, or RET parameters associated with a particular 556 recipient should be propagated, for each of the recipients to which 557 the message is forwarded. 559 However, if the message is to be forwarded to multiple recipient 560 addresses on behalf of a single recipient, a "delivered" DSN should be 561 issued, and the request for a DSN should NOT be propagated to the 562 recipient's forwarding addresses. 564 SMTP Delivery Status Notifications 20 November 1994 566 (NOTE IN DRAFT: this is intended to ensure exactly one notification per 567 request. I'm concerned that DSNs will be difficult to use by mailing 568 list exploders if it's possible to get more than one notification per 569 request, say because a message was forwarded to two recipients, and 570 delivery succeeds for one and fails for the other. On the other hand, 571 it's still possible to get both a "relayed" or "delivered" DSN and 572 afterwards a "failed" DSN for the same recipient, and a foreign mail 573 system might not issue DSNs for forwarded messages and deliveries to 574 lists.) 576 7.2.8. Delivery of a message to a mailing list 578 If a particular recipient address refers to a mailing list, a message 579 is considered to be successfully delivered to that recipient if the MTA 580 determines that the message is eligible to be distributed to the members 581 of the list. If a NOTIFY parameter was supplied with an esmtp-value 582 which contains the value SUCCESS, a "delivered" DSN should be issued. 583 Any envelope-id, original-mts-type, notify-request, return-of-content- 584 request, or original-recipient-address should NOT be propagated when 585 delivering a message to the recipients of that list. 587 If the message is not eligible to be distributed to the list 588 membership (perhaps because the sender is not authorized), and either a 589 NOTIFY parameter was supplied which contained the FAILURE keyword, or no 590 NOTIFY parameter was supplied, a "failed" DSN should be issued. 592 7.3. Handling of messages from other sources 594 For messages which originated from "local" users (whatever that 595 means), the specifications under which DSNs should be generated can be 596 communicated to the MTA via any protocol agreed on between the sender's 597 mail composer (user agent) and the MTA. The local MTA can then either 598 relay the message, or issue appropriate delivery status notifications. 599 However, if such requests are transmitted within the message itself (for 600 example in the headers), the requests MUST be removed from the message 601 before it is transmitted via SMTP. 603 For messages gatewayed from non-SMTP sources and further relayed by 604 SMTP, the gateway should, using the SMTP extensions described here, 605 attempt to provide the delivery reporting conditions expected by the 606 source mail environment. If appropriate, any DSNs returned to the 607 source environment should be translated into the format expected in that 608 environment. 610 8. Format of delivery notifications 612 The format of delivery status notifications is defined in [5], which 613 uses the framework defined in [6]. Delivery status notifications are to 614 SMTP Delivery Status Notifications 20 November 1994 616 be returned to the sender of the original message according as outlined 617 below. 619 8.1. SMTP Envelope to be used with delivery status notifications 621 The sender address (in the SMTP MAIL command) must be an empty 622 string. The recipient address (in the RCPT command) is copied from the 623 MAIL command of the message for which a delivery notification is being 624 issued. The envelope of a delivery notification may not use the DSN 625 option. 627 8.2. Contents of the DSN 629 A DSN is transmitted as a MIME message with a top-level content-type 630 of multipart/report (as defined in [6]). 632 The multipart/report content-type may be used for any of several 633 kinds of reports generated by the mail system. When multipart/report is 634 used to convey a DSN, the report-type parameter of the multipart/report 635 content-type must be "delivery-status". 637 As described in [6], the first component of a multipart/report 638 content-type is a human readable explanation of the report. For a DSN, 639 the second component of the multipart/report is of content-type 640 message/delivery-status (defined in [5]). The third component of the 641 multipart/report consists of the returned message (or only the headers). 643 8.3. Message/delivery-status fields 645 The multipart/delivery-status content-type defines a number of 646 fields, with general specifications for their contents. When generating 647 a DSN for a message which was received via the SMTP protocol, a 648 conforming MTA will generate the per-message fields of the 649 multipart/delivery-status body part as follows: 651 (a) if an ENVID parameter was present on the MAIL command, an Original- 652 Envelope-ID field must be supplied, and the value associated with 653 the ENVID parameter must appear in that field. 655 (b) if an OMTS parameter was present on the MAIL command, an Original- 656 MTS-Type field must be supplied, and the value associated with the 657 OMTS parameter must appear in that field. 659 (c) The Final-MTA field must be supplied, and it must contain the domain 660 name of the SMTP server which is actually issuing this notification. 662 (d) The Final-MTS-Type field must be supplied. For DSNs generated for 663 messages received by SMTP, the Final-MTS-Type will normally be 664 SMTP Delivery Status Notifications 20 November 1994 666 "Internet". 668 (e) Other per-message fields as defined in [5] MAY be supplied. 670 (f) If the ORCPT parameter was provided for this recipient, the 671 Original-Recipient field should appear, with its value taken from 672 the ORCPT parameter. 674 (g) If the OMTS parameter was provided for this recipient, the Original- 675 MTS-Type field must appear, with its value taken from the OMTS 676 paramter. 678 (h) For DSNs resulting from attempts to relay a message to a recipient 679 via SMTP, the Remote-* fields must be supplied. In this case, 680 Remote-MTS-Type will normally be "Internet". 682 (i) Other per-recipient fields defined in [5] may also appear, as 683 appropriate. 685 9. Acknowledgments 687 (fill in this space) 689 10. References 691 [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, 692 USC/Information Sciences Institute, August 1982. 694 [2] Crocker, D., "Standard for the Format of ARPA Internet Text 695 Messages", STD 11, RFC 822, UDEL, August 1982. 697 [3] Westine, A., Postel, J. "Problems with the Maintenance of Large 698 Mailing Lists.", RFC 1211, USC/Information Sciences Institute, March 699 1991. 701 [4] Klensin, J., Freed, N., Rose, M., Stefferud, E., Crocker., D. "SMTP 702 Service Extensions", RFC 1651, MCI, Innosoft, Dover Beach 703 Consulting, Inc., Network Management Associates, Inc., Silicon 704 Graphics, Inc., July 1994. 706 [5] Moore, K., Vaudreuil, G. "An Extensible Message Format for Delivery 707 Status Notifications". Internet-Draft "draft-ietf-notary-mime- 708 delivery-03.txt", 20 November 1994. 710 [6] Vaudreuil, G. "Multipart/Report". Internet-Draft "draft-ietf- 711 notary-mime-report-00.txt", 1 August 1994. 713 SMTP Delivery Status Notifications 20 November 1994 715 11. Author's address 717 Keith Moore 718 University of Tennessee 719 107 Ayres Hall 720 Knoxville, TN 37996-1301 721 USA 723 email: moore@cs.utk.edu 724 SMTP Delivery Status Notifications 20 November 1994 726 APPENDIX: Summary of changes since draft-ietf-notary-smtp-drpt-01.txt 728 1. Added OMTS esmtp-keyword to convey Original-MTS-Type. 729 2. Changed syntax of NOTIFY parameters to be either a comma-separated 730 list from the set SUCCESS, FAILURE, DELAY, or the single keyword 731 NEVER. 732 3. Changed syntax of RET parameter to specify either return of 733 content or return of headers only. 734 4. Updated to reflect the current DSN and multipart/report drafts. 735 5. Updated references.