idnits 2.17.1 draft-newman-deliver-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-24) 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 the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction 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. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([6]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A message for which a by-mode of "R" was specified MUST not be relayed to a SMTP server which does not support the Deliver By SMTP service extension. Moreover, the server to which it is relayed MUST not have a fixed minimum by-time which is greater than the time remaining in which the message is to be delivered. The fixed minimum by-time is expressed by the optional deliverby-param discussed in Section 3. -- 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 (January 1999) is 9231 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 2234 (ref. '2') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 1869 (ref. '4') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 1891 (ref. '5') (Obsoleted by RFC 3461) ** Obsolete normative reference: RFC 1894 (ref. '6') (Obsoleted by RFC 3464) Summary: 16 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Dan Newman, Innosoft 3 INTERNET DRAFT January 1999 4 Updates: RFC 1894 5 Category: Standards Track 7 Deliver By SMTP Service Extension 8 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are 13 working documents of the Internet Engineering Task Force 14 (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum 19 of six months and may be updated, replaced, or obsoleted 20 by other documents at any time. It is inappropriate to 21 use Internet-Drafts as reference material or to cite them 22 other than as "work in progress." 24 To view the entire list of current Internet-Drafts, 25 please check the "1id-abstracts.txt" listing contained in 26 the Internet-Drafts Shadow Directories on ftp.is.co.za 27 (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific 28 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US 29 West Coast). 31 1. Abstract 33 This memo defines a mechanism whereby a SMTP client can request, when 34 transmitting a message to a SMTP server, that the server deliver the 35 message within a prescribed period of time. A client making such a 36 request also specifies the message handling which is to occur if the 37 message cannot be delivered within the specified time period: either the 38 message is to be returned as undeliverable with no further processing, 39 or a 'delayed' delivery status notification (DSN) [6] is to be issued. 41 This extension should not be viewed as a vehicle for requesting 42 'priority' processing. A receiving SMTP server may assign whatever 43 processing priority it wishes to a message transmitted with a Deliver By 44 request. A Deliver By request serves to express a message's urgency and 45 to provide an additional degree of determinancy in its processing. An 46 indication of an urgent message's status within a given time period may 47 be requested and will be honored. Moreover, the message may be 48 withdrawn if not delivered within that time period. 50 2. Definitions 52 Throughout this document, the term "deliver" is taken to mean the act of 53 transmitting a message to its "final" destination by a message transport 54 agent (MTA). Usually, but not always, this means storing or otherwise 55 handing off the message to the recipient's mailbox. Thus, an MTA which 56 accepts a message to be delivered within a specified time period is 57 agreeing to store or handoff the message to the recipient's mailbox 58 within the specified time period. Outside the scope of the term 59 "deliver" are any user-specified actions which might take place after 60 the MTA stores or hands off the message; e.g., user-programmed filters 61 which, often unbeknownst to the MTA, resend the message to some other 62 location. 64 The key words "MUST" and "SHOULD" in this document are to be interpreted 65 as described in RFC 2119 [7]. 67 3. Framework for the Deliver By SMTP service extension 69 The Deliver By SMTP service extension uses the SMTP service extension 70 mechanism described in [4]. The following SMTP service extension is 71 therefore defined: 73 (1) The name of the SMTP service extension is "Deliver By". 75 (2) The EHLO keyword value associated with this service extension is 76 "DELIVERBY". 78 (3) One optional parameter is allowed with this EHLO keyword value, a 79 decimal integer indicating the fixed minimum by-time that the 80 server will accept when a by-mode of "R" is specified as per 81 Section 5. The syntax of the parameter is as follows, using the 82 augmented BNF notation of RFC 822 [2]: 84 deliverby-param = [1*9DIGIT] 86 If the parameter is omitted, no information is conveyed about the 87 server's fixed minimum by-time. 89 (4) One optional parameter using the keyword "BY" is added to the MAIL 90 FROM command. 92 (5) The maximum length of a MAIL FROM command line is increased by 17 93 characters by the possible addition of the BY keyword and value. 95 (6) No additional SMTP verbs are defined by this extension. 97 4. The Deliver By SMTP service extension 99 A SMTP client wishing to use the Deliver By SMTP service extension may 100 issue the EHLO command to start a SMTP session and to determine if the 101 SMTP server supports the service extension. If the server responds with 102 code 250 to the EHLO command, and the response includes the EHLO keyword 103 DELIVERBY, then the Deliver By SMTP service extension is supported by 104 the server. 106 If a numeric parameter follows the DELIVERBY keyword value of the EHLO 107 response then that parameter indicates the minimum value allowed for the 108 by-time when a by-mode of "R" is specified with the extended MAIL FROM 109 command as described in Section 5. Any attempt by a client to specify a 110 by-mode of "R" and a by-time strictly less than this limit will be 111 rejected with a permanent failure (55z) reply code. 113 A SMTP server that supports the Deliver By SMTP service extension will 114 accept the extended version of the MAIL FROM command described in 115 Section 5. When supported by the server, a SMTP client may use the 116 extended MAIL FROM command (instead of the MAIL FROM command described 117 in [1]) to request that the message be delivered within the specified 118 time period. The server may then return an appropriate error code if it 119 determines that the request cannot be honored. Note that this may not 120 be apparent to the server until either presentation of the recipient 121 addresses with RCPT TO commands or completion of the transfer of the 122 message data with the dot (.) command. As such, the server may send to 123 the client a success response to the MAIL FROM command only to later 124 return an error response to the RCPT TO, DATA, or dot command. 126 5. The extended MAIL FROM command 128 The extended MAIL FROM command is issued by a SMTP client when it wishes 129 to inform a SMTP server that a message is to be delivered within a 130 specified period of time and further what action to take should the 131 message prove undeliverable within that time period. The extended MAIL 132 FROM command is identical to the MAIL FROM command as defined in RFC 821 133 [1], except that a BY parameter appears after the address. 135 The complete syntax of this extended command is defined in [4]. The 136 esmtp-keyword is "BY" and the syntax for the esmtp-value is given by the 137 syntax for by-value shown below. In the augmented BNF of RFC 2234 [2], 138 the syntax for the BY esmtp-parameter is 140 by-parameter = "BY="by-value 141 by-value = by-time";"by-mode[by-trace] 142 by-time = ["-" / "+"]1*9digit ; a negative or zero value is not 143 ; allowed with a by-mode of "R" 144 by-mode = "N" / "R" ; "Notify" or "Return" 145 by-trace = "T" ; "Trace" 147 Note that the BY esmtp-keyword MUST have an associated esmtp-value. The 148 by-time is a decimal representation of the number of seconds within 149 which the message should be delivered and has the range 151 -999,999,999 seconds <= by-time <= +999,999,999 seconds 153 and is thus sufficient to represent a time anywhere from approximately 154 31.6 years in the past to 31.6 years in the future. 156 As described in Section 5.1, the by-mode indicates the action the SMTP 157 server must take should it not be possible to transmit the message 158 within by-time seconds. 160 Note that by-time is a delta time: the number of seconds within which to 161 deliver the message. A delta time is used so as to prevent problems 162 associated with differences in system clocks between clients and 163 servers. Servers in receipt of a valid by-parameter are expected to 164 convert the by-time into a locale-specific absolute time called the 165 deliver-by-time. This is done by adding the by-time upon receipt to the 166 current locale-specific time and thereby arriving at a locale-specific 167 absolute time which is by-time seconds in the future or past, depending 168 upon the arithmetic sign of by-time. The message is then to be 169 delivered by the deliver-by-time. The sending client and receiving 170 server should assume the transmission time of the MAIL FROM command to 171 be instantaneous. Clearly, it will not be and network latency will 172 introduce an error, the nature of which will be to extend slightly the 173 effective by-time. The more hops the message takes, the more pronounced 174 the effect will be owing to the cumulative nature of this latency- 175 induced error. 177 In the case of a by-mode of "N", it is possible that by-time may be zero 178 or negative. This is not an error and should not be rejected as such. 179 It indicates a message for which the deliver-by-time occurred -(by-time) 180 seconds in the past. [Here, "-(by-time)" represents the arithmetic 181 negation of the by-time value.] Zero and negative values are allowed so 182 as to preserve information about any requested delivery time information 183 -- information which the delivering MTA may wish to include with the 184 delivered message for the benefit of the recipient or to show in a DSN 185 or NDN (non delivery notification). 187 In the case of a by-mode of "R", a zero or negative by-time is a syntax 188 error. In such a case, the SMTP server should return a permanent 189 failure (501) reply code in response to the extended MAIL FROM command. 191 5.1. Server behavior upon receipt of the extended MAIL FROM command 193 Upon receipt of an extended MAIL FROM command containing a valid BY 194 parameter, a SMTP server and associated MTA must handle the message in 195 accord with the following subsections, Sections 5.1.1-5.1.5. Delivery 196 status notifications generated in response to processing a message with 197 a Deliver By request should include both the optional Arrival-Date DSN 198 field as well as the new Deliver-By-Date DSN field described in Section 199 6 of this memo. 201 5.1.1. Successful delivery 203 If the message is delivered before deliver-by-time, no special action 204 need be taken. If the SMTP server or MTA also supports the Delivery 205 Status Notification SMTP service extension [5] and a NOTIFY parameter 206 including "SUCCESS" was specified, a "delivered" DSN with appropriate 207 status must be returned as per [5]. 209 5.1.2. Unsuccessful delivery; deliver-by-time not yet reached 211 If deliver-by-time has not yet passed and the message has proved 212 undeliverable for temporary reasons, then the SMTP server or MTA should 213 continue delivery or relay attempts as per the site's message handling 214 policy. However, the message MUST still be handled in accord with 215 Sections 5.1.1-5.1.5. 217 If deliver-by-time has not yet passed and the message cannot be 218 delivered for permanent reasons, then the SMTP server or MTA MUST return 219 a "failed" DSN with an appropriate status for each recipient address 220 with either no NOTIFY parameter specified or for which the NOTIFY 221 parameter includes "FAILURE". 223 5.1.3. Time has expired; deliver-by-time reached or passed 225 If the message is not delivered or relayed before deliver-by-time and a 226 by-mode of "R" was specified, no further delivery attempts may be made 227 for the message. The server or MTA MUST issue a "failed" DSN with 228 status 5.4.7, "delivery time expired", for each recipient address with 229 either no NOTIFY parameter specified or for which the NOTIFY parameter 230 includes "FAILURE". 232 If the message is not delivered or relayed before deliver-by-time and a 233 by-mode of "N" was specified, the server or MTA should continue attempts 234 to deliver or relay the message using the site's message handling 235 policy. In addition, the server or MTA MUST issue a "delayed" DSN with 236 status 4.4.7, "delivery time expired", for each recipient address with 237 either no NOTIFY parameter specified or for which the NOTIFY parameter 238 includes "DELAY". 240 5.1.4. Relaying to another SMTP server 242 Sections 5.1.4.1 and 5.1.4.2 below describe when a message with a 243 Deliver By request may be relayed to another SMTP server and what 244 additional actions, if any, should or must be taken. In addition to 245 that discussed in those sections, the following must also be observed 246 when relaying is permitted. 248 If the message is relayed to a SMTP server that supports the Deliver By 249 extension, a new BY parameter MUST be relayed specifying a by-time value 250 indicating the number of seconds remaining until deliver-by-time. The 251 new by-time value should be computed as close to the time the MAIL FROM 252 command is transmitted by the relaying SMTP client as is reasonably 253 possible. Note that if deliver-by-time has passed, the relayed by-time 254 will be a negative value indicating how may seconds has elapsed since 255 delivery-by-time. Such a case -- relay of a message for which deliver- 256 by-time has just arrived or passed -- may only happen with a message 257 that has a by-mode of "N". 259 When a message with a by-trace field with value "T" is relayed, a 260 "relayed" DSN SHOULD be generated by the relaying SMTP client for each 261 recipient which either did not specify a NOTIFY parameter or the NOTIFY 262 parameter does not have the value "NEVER". 264 Note that these "relayed" DSNs are generated regardless of whether 265 success notifications were explicitly requested with a NOTIFY=SUCCESS 266 parameter. Note further that the "relayed" DSNs discussed here are not 267 terminal notifications: downstream SMTP servers and MTAs may still 268 support [5] and as such additional notifications may still result. 270 5.1.4.1. Relaying a message with a by-mode of "R" 272 A message for which a by-mode of "R" was specified MUST not be relayed 273 to a SMTP server which does not support the Deliver By SMTP service 274 extension. Moreover, the server to which it is relayed MUST not have a 275 fixed minimum by-time which is greater than the time remaining in which 276 the message is to be delivered. The fixed minimum by-time is expressed 277 by the optional deliverby-param discussed in Section 3. 279 If the message requires relaying in order to be delivered yet cannot be 280 relayed, then the message is deemed to be undeliverable for permanent 281 reasons and Section 5.1.2 should be applied. 283 5.1.4.2. Relaying a message with a by-mode of "N" 285 A message with a by-mode of "N" may be relayed to another server 286 regardless of whether or not the SMTP server to which it is relayed 287 supports the Deliver By extension. 289 If the message is relayed before deliver-by-time to a SMTP server that 290 does not support the Deliver By extension, then the relaying SMTP client 291 MUST issue a "relayed" DSN for each recipient which either did not 292 specify a NOTIFY parameter or the NOTIFY parameter does not have the 293 value "NEVER". Further, if the SMTP server being relayed to supports the 294 Delivery Status Notification SMTP service extension [5] then for each 295 recipient: if no NOTIFY parameter was supplied, "NOTIFY=FAILURE,DELAY" 296 SHOULD be requested; if a NOTIFY parameter was specified and does not 297 have the value "NEVER", "DELAY" SHOULD be added to the list of notify- 298 list-element values if not already present. Note that this explicitly 299 overrides the "MUST NOT" wording of Section 6.2.1(c) of [5]. 301 5.1.5. Relaying to a foreign mail system 303 If the foreign mail system supports semantics similar to the Deliver By 304 SMTP service extension described in this memo, then convey the Deliver 305 By request to that system. Otherwise, relay the message as if relaying 306 to a SMTP server which does not support the Deliver By extension. 308 6. Delivery status notifications and extension 310 The format of delivery status notifications (DSNs) is specified in [6]. 311 DSNs generated in response to a Deliver By request should include an 312 Arrival-Date DSN field. This memo also extends the per-message-fields 313 of [6] to include a new DSN field, Deliver-By-Date, indicating the 314 deliver-by-time as computed by the MTA or SMTP server generating the 315 DSN. In the augmented BNF of RFC 822 [2], per-message-fields is 316 therefore extended as follows: 318 per-message-fields = 319 [ original-envelope-id-field CRLF ] 320 reporting-mta-field CRLF 321 [ dsn-gateway-field CRLF ] 322 [ received-from-mta-field CRLF ] 323 [ arrival-date-field CRLF ] 324 [ deliver-by-date-field CRLF ] 325 *( extension-field CRLF ) 326 deliver-by-date-field = "Deliver-by-date" ":" date-time 328 where date-time is a RFC 822 [2] date-time field as ammended by RFC 1123 329 [3]. 331 7. Examples 333 In the following sample SMTP dialog, the SMTP client requests that a 334 message from be delivered to 335 within 2 minutes (120 seconds) and returned otherwise. This request 336 takes the form of a BY parameter on the MAIL FROM line of "BY=120;R" as 337 shown below: 339 S: 220 acme.net SMTP server here 340 C: EHLO bigbiz.com 341 S: 250-acme.net 342 S: 250 DELIVERBY 343 C: MAIL FROM: BY=120;R 344 S: 250 sender ok 345 C: RCPT TO: 346 S: 250 recipient ok 348 Suppose now that the receiving SMTP server in the above example needs to 349 relay the message to another SMTP server, mail.other.com. Owing to the 350 original by-mode of "R", the message may only be relayed to another SMTP 351 server which supports the Deliver By extension (Section 5.1.4). 352 Further, when relaying the message, the Deliver By request must be 353 relayed. With this in mind, consider the following SMTP dialog: 355 S: 220 mail.other.com ESMTP server at your service 356 C: EHLO acme.net 357 S: 250-mail.other.com 358 S: 250 DELIVERBY 240 359 C: QUIT 361 In the above dialog, the relaying SMTP server, acme.net, connects to 362 mail.other.com and issues an EHLO command. It then learns that the 363 Deliver By extension is supported but that the minimum by-time for a 364 by-mode of "R" is 4 minutes (240 seconds). This value exceeds the 365 message's original by-time and therefore necessarily exceeds the 366 remaining by-time. The relaying SMTP server thus ends the SMTP session 367 after which it must either attempt to follow any other MX records or, if 368 there are no more MX records to follow, must return the message as 369 undeliverable. Similar behavior would result if the EHLO command was 370 met with an error or did not include the DELIVERBY keyword. 372 Consider instead, the relaying SMTP session: 374 S: 220 mail.other.com ESMTP server at your service 375 C: EHLO acme.net 376 S: 250-mail.other.com 377 S: 250 DELIVERBY 30 378 C: MAIL FROM: BY=98;R 379 S: 250 Sender okay 380 C: RCPT TO: 381 S: 250 Recipient okay 383 In the above, the relaying SMTP client relays the BY parameter with the 384 by-mode preserved and the by-time computed to be the remaining number of 385 seconds at the approximate time that the MAIL FROM command was 386 transmitted from the relaying SMTP client (acme.net) to the receiving 387 SMTP server (mail.other.com). In this example, 22 seconds have elapsed 388 since acme.net received the MAIL FROM line from the original sending 389 client and relayed the Deliver By request to mail.other.com. 391 8. Security considerations 393 Implemention of Deliver By allows tracing of a mail transport system. 394 The by-trace field "T" explicitly requests that a trace be generated. 395 Moreover, even when the by-trace field is not used, a crude trace may be 396 generated by entering a series of messages into the transport system, 397 each with successively increasing by-time values; e.g., "BY=0;R", 398 "BY=1;R", "BY=2;R". Probing, and in some cases tracing, can be 399 accomplished through other means: querying the visible SMTP servers, 400 investigating Received: header lines in bounced messages, and using 401 utilities such as "traceroute". 403 9. Other considerations 405 SMTP servers which support the Deliver By SMTP service extension as well 406 as their associated MTAs are not required to assign any special 407 processing priority to messages with Deliver By requests. Of course, 408 some SMTP servers and MTAs may do so if they desire. Moreover, delivery 409 status notifications generated in response to messages with Deliver By 410 requests are not required to receive any special processing. 411 Consequently, users of this service should not, in general, expect 412 expedited processing of their messages. Moreover, just because a 413 message is sent with a "BY=60;R" parameter does not guarantee that the 414 sender will learn of a delivery failure within any specified time period 415 as the DSN will not necessarily be expedited back to sender. 417 10. Acknowledgments 419 The author wishes to thank Keith Moore for providing much of the initial 420 impetus for this document as well as the basic ideas embodied within it. 421 Further thanks are due to Ned Freed and Chris Newman for their reviews 422 of this document and suggestions for improvement. 424 11. References 425 [1] Postel, Jonathan B., "Simple Mail Transfer Protocol", RFC 821, 426 August 1982. 428 [2] Crocker, D. (editor), Overell, P., "Augmented BNF for Syntax 429 Specifications: ABNF", RFC 2234, November 1997. 431 [3] Braden, R. (editor), "Requirements for Internet Hosts -- 432 Application and Support", RFC 1123, October 1989. 434 [4] Rose, M., Stefferud, E., Crocker, D., Klensin, J. (chair), & Freed, 435 N. (editor), "SMTP Service Extensions", RFC 1869, November 1995. 437 [5] Moore, K., "SMTP Service Extension for Delivery Status 438 Notifications", RFC 1891, January 1996. 440 [6] Moore, K. & Vaudreuil, G., "An Extensible Message Format for 441 Delivery Status Notifications", RFC 1894, January 1996. 443 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement 444 Levels", RFC 2119, March 1997. 446 12. Author's Address 448 Dan Newman 449 Innosoft International, Inc. 450 1050 Lakes Drive 451 West Covina, CA 91790 452 USA 454 Telephone: +1 626 919 3600 455 Fax: +1 626 919 3614