idnits 2.17.1 draft-ietf-fax-timely-delivery-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 38 longer pages, the longest (page 1) being 68 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (8 February 2001) is 8478 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) == Unused Reference: '1' is defined on line 1529, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1564, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1579, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2542 (ref. '1') ** Obsolete normative reference: RFC 821 (ref. '2') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 1651 (ref. '3') (Obsoleted by RFC 1869) ** Obsolete normative reference: RFC 1891 (ref. '4') (Obsoleted by RFC 3461) == Outdated reference: A later version (-05) exists of draft-ietf-fax-content-negotiation-03 ** Obsolete normative reference: RFC 2234 (ref. '7') (Obsoleted by RFC 4234) -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Downref: Normative reference to an Unknown state RFC: RFC 1047 (ref. '9') ** Obsolete normative reference: RFC 974 (ref. '10') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 1894 (ref. '12') (Obsoleted by RFC 3464) ** Obsolete normative reference: RFC 1893 (ref. '13') (Obsoleted by RFC 3463) ** Obsolete normative reference: RFC 2298 (ref. '14') (Obsoleted by RFC 3798) Summary: 12 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF fax WG G. Klyne, Baltimore Technologies 3 Internet draft D. Crocker, Brandenburg Consulting 4 8 February 2001 5 Expires: August 2001 7 Timely Completion for Internet Messaging Services 8 10 Status of this memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC 2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as "work in 24 progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 To view the entire list of current Internet-Drafts, please check 33 the "1id-abstracts.txt" listing contained in the Internet-Drafts 34 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 35 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 36 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US 37 West Coast). 39 Copyright Notice 41 Copyright (C) The Internet Society 2001. All Rights Reserved. 43 Abstract 45 This proposal describes a way to request timely completion for 46 Internet email, for services such as facsimile and voice messaging. 47 It provides a deterministic service quality response, while 48 preserving the traditional roles and responsibiltiies of the agents 49 involved in e-mail transfers. 51 It is essentially a profile of the DSN and DELIVERBY extentions for 52 ESMTP, and a TIMELY option to DELIVERBY with a new deterministic 53 service quality response. 55 Timely Completion for Internet Messaging 8 February 2001 56 58 Discussion of this document 60 Please send comments to: . 62 To subscribe: send a message with the body 'subscribe' to 63 . The mailing list archive is at 64 . 66 Timely Completion for Internet Messaging 8 February 2001 67 69 Table of contents 71 1. Introduction.............................................4 72 1.1 Structure of this document ...........................4 73 1.2 Document terminology and conventions .................4 74 2. Background and goals.....................................5 75 2.1 Background ...........................................6 76 2.2 Basis for timely completion ..........................6 77 2.2.1 The SMTP "contract"..............................7 78 2.2.2 Framework for timely delivery....................7 79 2.3 What does the TIMELY option add? .....................8 80 2.3.1 DELIVERBY and timely disposition.................9 81 2.4 Goals for timely completion ..........................9 82 3. Mechanisms for timely completion.........................10 83 3.1 Transmitting a message for timely completion .........11 84 3.2 Relaying a message ...................................12 85 3.3 Accepting a message by the final MTA .................13 86 3.3.1 Disposition timing...............................13 87 3.4 Reporting failures ...................................14 88 3.5 Timely confirmation ..................................15 89 4. Timely extension to ESMTP Deliver By extension...........17 90 4.1 Framework for TIMELY extension to DELIVERBY.............17 91 4.2 Extension to EHLO DELIVERBY keyword.....................17 92 4.3 MAIL FROM: TIMELY parameter.............................18 93 5. DSN reporting extensions.................................18 94 5.1 New extended mail system status codes ................18 95 5.2 'Retry-count' per-recipient DSN header ...............19 96 6. Implementation notes.....................................19 97 6.1 Message state management .............................19 98 6.2 Retransmission timing issues .........................21 99 6.3 Delivery timing granularity ..........................22 100 6.4 Partial success ......................................22 101 6.5 Routing TIMELY and non-TIMELY messages ...............23 102 6.6 Expediting message handling ..........................23 103 7. Examples.................................................23 104 7.1 Timely delivery and confirmation .....................23 105 7.2 Timely delivery achieved, no timely disposition ......26 106 7.3 Timely delivery achieved, disposition delayed ........27 107 7.4 Timely delivery could not be achieved ................28 108 7.5 Timely delivery feature not supported ................30 109 8. IANA Considerations......................................31 110 9. Internationalization considerations......................32 111 10. Security considerations.................................32 112 11. Acknowledgements........................................32 113 12. References..............................................32 114 13. Authors' addresses......................................34 115 Appendix A: Amendment history...............................35 116 Full copyright statement....................................37 117 Timely Completion for Internet Messaging 8 February 2001 118 120 1. Introduction 122 RFC 1891 [4] defines an ESMTP extension for delivery status 123 notifications, and RFC 2852 [5] defines one for requesting delivery 124 of a message within a given interval. This memo describes how to 125 use those specifications, with some small extensions, to achieve 126 timely completion of message delivery. 128 1.1 Structure of this document 130 Section 2 gives the background, principal ideas and goals of this 131 specification. 133 Section 3 describes the mechanisms used, and how they are combined 134 to achieve the timely delivery goals. 136 Section 4 describes an addition to the ESMTP "Deliver by" extension 137 which is one of the mechanisms used to achieve timely delivery. 139 Section 5 describes extensions to the DSN reporting format and 140 status codes used to report conditions related to timely delivery 141 requests. 143 Section 6 contains some non-normative discussion of implementation 144 issues related to this specification. 146 Section 7 contains some examples uses of this specification. 148 1.2 Document terminology and conventions 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 152 this document are to be interpreted as described in RFC 2119 [11]. 154 Timely delivery 155 means a message is delivered to a recipient's MTA within a 156 specified time interval. 158 Timely disposition 159 means a message is delivered to and processed by a recipient's 160 user agent within a specified time interval. 162 Timely completion 163 means that notification of a requested timely disposition or 164 timely delivery is received by the sender of a message within 165 a determined time interval. Non-receipt of notification 166 within that interval is indicative of failure. 168 Timely Completion for Internet Messaging 8 February 2001 169 171 Delivery interval 172 A period of time, measured in seconds, allowed for completion 173 of message delivery and disposition. 175 Best efforts 176 Indicating that a system will ensure that an assigned task is 177 successfully completed under all but the most catastrophic of 178 failure circumstances. Common failure modes, such as power 179 failures, should not prevent eventual completion of a task. 181 Reasonable efforts 182 Indicating that a while system will try to complete an 183 assigned task, it may also indulge in behaviours, or make 184 operational decisions, that significantly reduce the certainty 185 that an action will be completed in the face of disruptive 186 circumstances. 188 MTA, Mail Transfer Agent 189 An email system component whose role is to receive and 190 transfer a message. 192 MUA, Mail User Agent 193 An email system component whose role is to prepare and send, 194 or to receive and process, a message. MUAs are the endpoints 195 between which emails are sent; MTAs are relays on the path 196 from a sending MUA to a receiving MUA. 198 Delivery MTA 199 In the context of a particular email transfer, the MTA that 200 accepts the message and passes it to the receiving MUA. 202 NOTE: Comments like this provide additional nonessential 203 information about the rationale behind this document. 204 Such information is not needed for building a conformant 205 implementation, but may help those who wish to understand 206 the design in greater depth. 208 [[[Editorial comments and questions about outstanding issues are 209 provided in triple brackets like this. These working comments 210 should be resolved and removed prior to final publication.]]] 212 2. Background and goals 214 RFC 2852 [5] provides a mechanism to request timely delivery of a 215 message using SMTP. While this is helpful, it falls short for some 216 usage profiles, such as timely processing of fax messages. These 217 profiles are determined, in part, by the capabilities of 218 traditional facsimile [8]. 220 Timely Completion for Internet Messaging 8 February 2001 221 223 2.1 Background 225 Traditional e-mail [2] is open-loop. The sender of a message 226 normally has no certainty if or when a message is delivered. (A 227 separate memo [6] contains a discussion of some open- and closed- 228 loop issues in e-mail.) 230 To be more than just a hint to the message transfer system, timely 231 completion requires a deterministic confirmation mechanism, to 232 close the loop. This is provided by DSN [4]. 234 Four kinds of timeliness can be identified: 236 (a) timely delivery to the recipient 238 (b) timely delivery to and processing by the recipient 240 (c) timely notification to the sender of delivery 242 (d) timely notification to the sender that the message has been 243 delivered to and processed by the recipient 245 From the sender's point of view, timely confirmation of delivery 246 and processing is the most desirable requirement. 248 2.2 Basis for timely completion 250 A key premise of this proposal is that timeliness CAN be achieved 251 using existing protocols, with appropriate software design and 252 operational management. But the sender and receiver do not control 253 all the relays used: 255 o The real issue is lack of determinism: a message might be 256 delivered quickly, or it might take hours or even days, or it 257 might not be delivered at all; the sender has little knowledge 258 and no control. 260 o A second issue is post-delivery handling: will the receiving 261 user agent process the message in timely fashion? 263 One challenge to achieving this is dealing with uncertain transit 264 times of the confirmation message over the return path (which is 265 not necessarily the same as the forward path). 267 Timely Completion for Internet Messaging 8 February 2001 268 270 2.2.1 The SMTP "contract" 272 On accepting a message, a normal SMTP message transfer agent (MTA) 273 accepts responsibility to: 275 (a) use best efforts to ensure ultimate delivery of the message, 276 or 278 (b) provide notification that delivery could not be achieved. 280 This memo introduces mechanisms to allow this contract to be 281 modified. A timely-completion MTA accepts responsibility to: 283 (a) use reasonable efforts to ensure delivery and disposition 284 within a specified time, and to provide timely confirmation of 285 this, or 287 (b) provide timely notification that delivery and disposition were 288 not achieved. 290 The sender can then decide a recovery strategy 292 2.2.2 Framework for timely delivery 294 The diagram shows typical SMTP message delivery and delivery status 295 notification (DSN) paths. Note that the confirmation path is not 296 necessarily the same as the message delivery path. 298 Outbound message --> 300 +-------+ +-----+ +-----+ +---------+ 301 |Sending|-->--|Relay| >>> |Relay|-->--|Receiving| 302 | MTA | | MTA | | MTA | | MTA | 303 +-------+ +-----+ +-----+ +---------+ 304 | | | 305 ^ | v 306 | | | 307 +-------+ | +---------+ 308 |Sending| | |Receiving| 309 | UA |-<------------- <<< ------------- | UA | 310 +-------+ +---------+ 311 <-- Return confirmation 312 Timely Completion for Internet Messaging 8 February 2001 313 315 As well as requesting timely delivery of a message, this proposal 316 needs to take account of the possibly varying characteristics of 317 relays of the outbound and return message paths. Practically, it 318 is possible to require that every relay on the outbound path 319 recognizes timely completion semantics (using the ESMTP extension 320 framework), but it is not possible to require this of every relay 321 on the return path. Thus, it may be necessary to make some 322 assumptions about the confirmation return path. 324 NOTE: The uncertainty about return path characteristics 325 might be removed by requiring an MTA to send any timely 326 delivery notifcation to the MTA from which it was 327 received, but this goes against trends in SMTP design and 328 deployment. This might also raise state maintenance and 329 hence scalability concerns. 331 The other issue apparent from the diagram is that providing timely 332 delivery through the SMTP message relays does not ensure that the 333 receiving UA will process the message in a timely fashion. If the 334 receiving MTA delivers to a POP mailbox, there is currently no way 335 that it can guarantee timely disposition. 337 2.3 What does the TIMELY option add? 339 The TIMELY option adds three elements to the DELIVERBY extension: 341 o it modifies the SMTP contract, permitting an MTA to commute its 342 responsibility for delivering the message from "best effort" to 343 "reasonable effort", with notification of outcome. 345 o it extends the reach of the timeliness constraint to cover the 346 disposition step (see below). 348 o it establishes a basis for determining the allowable time 349 interval for certain behaviours initiated by the receiver of a 350 message (i.e. DELIVERBY interval for delivery status responses, 351 and how long to wait for possible duplicate message 352 transmissions). 354 This is all consistent with the fundamental strategy of giving the 355 sender control over the whole process: if an MTA or the disposing 356 agent cannot communicate the required guarantee, delivery is not 357 completed and the sender is duly notified. 359 Timely Completion for Internet Messaging 8 February 2001 360 362 2.3.1 DELIVERBY and timely disposition 364 Timely completion of delivery is handled by the DELIVERYBY ESMTP 365 extension base specification [5]. However its scope ends with 366 final delivery by SMTP, not covering receipt and processing 367 disposition. The TIMELY option modifies the DELIVERBY semantics to 368 cover the additional step needed to reach the recipient and process 369 the message. 371 Consider the following scenario: 373 +------+ +-----+ +---------+ ------- +---------+ 374 |Sender|-->--|Relay|-->--|Receiving|->-(Message)->-|Disposing| 375 | MTA | | MTA | | MTA | ( store ) | agent | 376 +------+ +-----+ +---------+ ------- +---------+ 378 <------SMTP-------> <-------?-------> 380 The base DELIVERBY specification concerns itself with only 381 participants in the SMTP transfers. But for the purposes of timely 382 completion of disposition, the sender must be able to specify the 383 timeliness constraint to include this extra step. 385 The TIMELY option requires that the receiving MTA communicates with 386 the disposing agent (in some unspecified way), and that it confirms 387 final delivery of the message only if the disposing agent confirms 388 that it will deal with the message in timely fashion, or that it 389 will return an indication to the receiving MTA if it fails to do 390 so. Simply putting the message into a POP mailbox would not meet 391 this criterion. 393 2.4 Goals for timely completion 395 The primary goal is to allow consenting parties to establish a 396 relationship that carries a guarantee of message disposition a 397 within a specified time, or timely notification that the 398 disposition was not achieved. 400 Further goals are: 402 o Provide "while-you-wait" delivery of messages by e-mail (where 403 available infrastructure and connectivity permit). 405 o Deterministic behaviour. A sender who requests timely completion 406 should be able to determine with reasonable certainty, and in 407 reasonable time, whether or not that request was successful. 409 Timely Completion for Internet Messaging 8 February 2001 410 412 o If the message cannot be delivered as requested, it should not be 413 delivered at all. This means that a sender can choose other 414 strategies for message delivery (e.g. if timely delivery by email 415 does not succeed, to resend the message as a traditional 416 facsimile; in such circumstances it is preferable that multiple 417 copies of the message are not delivered. 419 o Operates within the existing ESMTP extension framework [3], using 420 existing facilities where available. 422 3. Mechanisms for timely completion 424 Deterministic timely completion is achieved through a number of 425 ESMTP extensions used in concert: 427 o Delivery Status Notification ("DSN"), per RFC 1891 [4]. 429 o Deliver-by ("DELIVERBY"), per RFC 2852 [5] 431 o A new TIMELY extension to DELIVERBY, that serves to modify the 432 SMTP contract and also to establish that the receiving user agent 433 can process the message in timely fashion as required, or provide 434 timely notification of its failure to do so 436 The confirmation loop for succesful delivery looks something like 437 this: 439 +-----------+ +--------+ +--------+ +---------+ 440 |Originating|-->--|Relaying| ... |Relaying|-->--|Receiving| 441 | MTA | | MTA | | MTA | --| MTA | 442 +-----------+ +--------+ +--------+ | +---------+ 443 | | | 444 +-------------+ | +---------+ 445 | Originating |--<-- ... .... ... --<-- |Receiving| 446 | MUA | | MUA | 447 +-------------+ +---------+ 449 The path through MTAs taken by the confirmation response is not 450 defined, and may be different than the forward path of the original 451 message. 453 Timely Completion for Internet Messaging 8 February 2001 454 456 3.1 Transmitting a message for timely completion 458 A transmitted message for which timely completion is required MUST 459 include the following: 461 o an 'ENVID' parameter on the MAIL FROM command, per DSN [4] 463 o an 'ORCPT' parameter on the corresponding RCPT TO command(s), per 464 DSN [4]. (This is to allow the sender to tell exactly which 465 recipients were succesfully delivered.) 467 o a 'NOTIFY=SUCCESS,FAILURE' parameter on the corresponding RCPT TO 468 command(s), per DSN [4] 470 o a 'BY' parameter on the MAIL FROM command, per [5], with a 'by- 471 mode' value of 'R'. 473 o a 'TIMELY' parameter on the MAIL FROM command, as described 474 below, initially having the same time interval as specified for 475 'BY'. 477 The message MUST NOT be transmitted to any MTA that does not 478 indicate support for all of these extensions in its response to the 479 EHLO command. In this case, a negative delivery status report MUST 480 be generated, which SHOULD indicate the non-compliant MTA, the 481 extensions that it does not support, and the name of the reporting 482 MTA (per DSN, using the non-compliance reporting extensions noted 483 later). 485 Standard DNS MX-based message routing, per RFC 974, SHOULD be used 486 when sending or relaying the message. 488 NOTE: Any strategies that vary standard MX routing 489 should be used with care, and only with the goal of 490 improving network transit times and timing consistency. 491 These comments about mail routing apply especially to the 492 handling of DSN responses. 494 Ideally, there will be no intermediate relay between the 495 sending and receiving MTAs, and in any case the number of 496 such relays should be minimized to reduce timing 497 variabilities on the transfer path. 499 Timely Completion for Internet Messaging 8 February 2001 500 502 3.2 Relaying a message 504 An MTA that relays a message for timely completion MUST support all 505 of the ESMTP extensions noted above, otherwise it should not be 506 given the message in the first place. When a relaying MTA accepts 507 a message (by its 2xx status response to receipt of the message 508 data), it becomes responsible for its onward delivery, including 509 satisfying all of the options associated with the message. 511 In order to relay such a message, an MTA MUST note when the message 512 was received, and the time when the attempt to transmit the message 513 to the next MTA is initiated, and reduce accordingly the time 514 interval used for the BY parameter. 516 If the DELIVERBY time interval is reduced to less than zero, (or 517 less than some system-configurable value indicating that delivery 518 within the indicated interval is unlikely to be achieved) then the 519 message MUST NOT be relayed. Instead, a negative delivery status 520 report MUST be generated indicating that the time for delivery of 521 the message has expired, and the reporting MTA (per DSN, using the 522 deliver-by extensions and/or non-compliance reporting extensions 523 noted below). 525 The above behaviour is as specified for the DELIVERBY ESMTP 526 extension; see RFC 2852 [5] for a definitive description of how to 527 handle relaying of such messages. The following additional 528 considerations are applicable when the TIMELY option is used: 530 The TIMELY parameter, in the MAIL FROM command of a message in 531 transit, is is copied unchanged when the message is retransmitted. 532 Thus, any originally specified time interval is conveyed to the 533 final MTA. 535 Standard DNS MX-based message routing, per RFC 974, SHOULD be used 536 when relaying the message. (See note at end of previous section.) 538 If the first attempt to relay a message fails, the relaying MTA MAY 539 assume that delivery within the desired time will not be achieved, 540 and immediately indicate a delivery failure, indicating the name of 541 the next-hop MTA. Alternatively, the relaying MTA may wait and 542 retry the transmission, provided that the retry attempt will be 543 performed within the remaining delivery period; if the 544 transmission cannot be completed after one or more such retries 545 then a negative DSN MUST be generated as noted above. 547 Any negative DSN generated should indicate the number of retries 548 attempted (where 0 means no retries). 550 Timely Completion for Internet Messaging 8 February 2001 551 553 The choice to retry or not retry is installation dependent. 554 Effectively, when a relay does not retry, any reposibility for 555 overcoming the delivery failure is passed back to the original 556 sender. This strategy may be appropriate for cases where very 557 rapid delivery is required or expected. 559 NOTE: The presence of a 'TIMELY' option may cause a 560 relay to abandon a message that it would otherwise retry 561 (even given a 'by-mode' value of 'R'). One purpose of 562 this option is to establish that responsiveness to the 563 sender is more important than getting the message 564 through. An effect of this may be to severely constrain 565 the number and frequency of retry attempts. 567 3.3 Accepting a message by the final MTA 569 The MTA that accepts final delivery of a message has responsibility 570 for passing the message to a Mail User Agent. The exact mechanism 571 by which this is achieved is a local matter, and not defined here 572 or by the Internet email specifications. The final MTA is also 573 responsible for generating any successful DSN message. 575 Before generating a success DSN message, the final MTA must ensure 576 that all of the conditions for delivery of the message have been 577 achieved. Specifically, when the TIMELY option is used, it should 578 ensure that final delivery to the MUA will be completed within the 579 delivery interval indicated. 581 Final delivery to an MUA is expected to include some guarantee of 582 timely processing. Exactly what this constitutes may depend 583 somewhat on the circumstances: in a simple case, depositing the 584 message in a local mailbox and immediately notifying the recipient 585 probably constitutes final delivery. A more complex case would be 586 that of a fax offramp, where final delivery may be completion of a 587 successful outdial and transmission of the fax. 589 3.3.1 Disposition timing 591 In the presence of a TIMELY option, final delivery should not be 592 indicated unless the delivery MTA can establish that the receiving 593 MUA will deal with the message promptly. Here "promptly" means a 594 reasonable waiting time for a human; e.g. that the message (or at 595 least the start of the message) will be available to its intended 596 final recipient within a period of, say, 30 seconds. 598 Timely Completion for Internet Messaging 8 February 2001 599 601 The relationship between the delivery MTA and receiving MUA can 602 work in one of two ways: 604 o the MUA always processes the message promptly, barring 605 exceptional circumstances. Queuing a message to a network 606 printer would constitute such processing -- normally the message 607 will be printed within seconds, even though it might be delayed 608 if the printer runs out of paper. The delivery MTA can generate 609 the final DSN when the MUA has accepted the message. 611 o the MUA attempts to process the message promptly and reports the 612 outcome within the remaining DELIVERBY period. If processing is 613 not performed within the stated period, the message is abandoned 614 and failure is signalled back to the delivery MTA. The delivery 615 MTA must hold off generating the final DSN until the MUA has 616 provided a status report; if no such report is provided within 617 the remaining DELIVERBY interval, it should report failure. 619 3.4 Reporting failures 621 When a relay or receiving MTA determines that a message cannot be 622 delivered as requested to any recipient, a DSN report is sent back 623 to the sender. 625 The following status codes indicated that message delivery has been 626 abandoned, are used with DSN "Action: failed" for reporting 627 conditions that are specific to timely delivery: 629 5.4.7: Delivery time expired -- permanent failure. 630 Message delivery could not be completed within the specified 631 time interval. 633 5.4.8???: MTA cannot honour required timely delivery guarantee. 634 A relay MTA was encountered that did not support the range of 635 capabilities required for timely completion. 637 5.4.1: Next MTA not accepting messages. 638 A relay MTA has been unable to contact a next-hop MTA, and has 639 decided to abandon delivery. (See note in section 3.2 about a 640 relay's options with respect to retries.) This code SHOULD be 641 accompanied by a 'Retry-Count' DSN field. 643 5.3.3: Receiving MTA cannot honour required timely disposition. 644 A message has been delivered to a receiving MTA within the 645 required delivery interval, but that MTA is unable to ensure 646 timely disposition or timely notification of failure to do so. 648 5.2.5???: Message delivered but disposition failed. 649 The message has been delivered but the MUA has reported 650 failure to complete disposition of the message as requested. 652 Timely Completion for Internet Messaging 8 February 2001 653 655 5.2.6???: Message delivered but disposition not completed. 656 The message has been delivered and the process of final 657 disposition has been initiated but has not been completed. 658 This status code signals that the receiving MTA is assuming 659 that the disposition has failed. 661 The following status code is used with DSN "Action: delayed" for 662 reporting delayed message disposition following final delivery: 664 4.2.6???: Message delivered pending final disposition. 665 The message has been delivered and is in the process of final 666 disposition, but that final disposition has not yet been 667 completed. This status code is defined for situations where a 668 receiving MTA has initiated disposition, and has therefore 669 committed to provide a timely confirmation response, but the 670 disposing agent has not signalled completion. 672 For example, a fax dial-out gateway may have been invoked 673 assuming that the outdial leg would complete within a given 674 period, but has failed to do so. 676 A subsequent DSN should be sent when the disposition finally 677 succeeds or fails. 679 3.5 Timely confirmation 681 Fully deterministic behaviour requires that the round-trip time to 682 deliver a message and receive a response is completed within a 683 known time interval. 685 As noted above, it cannot be guaranteed that confirmation of 686 delivery or non-delivery will be transferred in timely fashion, 687 though it seems reasonable to assume that return path transit times 688 will normally be comparable with forward path times. Use of the 689 DELIVERBY extension for a message MAY serve to expedite its 690 forwarding. 692 Further, it is likely that perfect determinism can never be 693 achieved using SMTP; e.g. see RFC 1047 [9]. Repeat deliveries are 694 considered less harmful than lost messages, but even these should 695 be minimized. 697 The following behaviour is followed to achieve near-deterministic 698 timely confirmation: 700 o Always fail forward delivery if a non-TIMELY MTA is encountered. 702 o A return DSN does not itself request delivery notification and 703 has an empty return path (as required for DSN). 705 Timely Completion for Internet Messaging 8 February 2001 706 708 o Do NOT use the TIMELY option on any DSN return, so that 709 notification delivery does not fail if a non-DELIVERBY or 710 non-TIMELY MTA is encountered on the return path. 712 o Use the DELIVERBY option to request timely delivery for any DSN 713 return, using a delivery interval 2 times the original forward 714 path DELIVERBY time (taken from the received TIMELY parameter), 715 specifying a 'by-mode' value of 'R'. (The lack of a return path 716 on the DSN response will mean that neither success or failure 717 notification will be generated: if thbe DSN cannot be returned 718 within the time given, it is silently dropped.) 720 o The sender may assume that the message is lost after 3 times the 721 original DELIVERBY interval has passed without notificaton. 723 NOTE: The above timings are based on a working assumption 724 that normal transit times do not vary by more than a 725 factor of two. There is nothing scientific about this 726 choice of value, but laying down some assumption provides 727 a basis for defining some operational parameters used by 728 cooperating parties, which in turn provides some basis 729 for deterministic behaviour. 731 The purpose of this specification is to give the sender control 732 over the recovery strategy to be used if timely delivery does not 733 succeed. It is therefore beyond its scope to set out exactly what 734 recovery action the sender should take. One possible action is to 735 retry the transmission, in which case the following additional 736 considerations apply: 738 o Retries should be used very sparingly, as the likely cause of 739 failure is either a permanent network condition or network 740 congestion. In the case of congestion, retries are likely to 741 make things worse. (The design of the TCP protocol takes account 742 of many lessons about network behaviour that have been learned 743 over the years. A particularly important strategy used is 744 exponential back-off when retransmitting.) 746 o The sender is required to provide envelope ID with message. If 747 it re-tries, it should use same envelope ID and should do so 748 within a reasonable period of determining the original message 749 has not been delivered. 751 o The receiver of a TIMELY message is strongly encouraged to keep 752 note of received envelope ID for some period, for the purpose of 753 weeding out duplicates. 755 Timely Completion for Internet Messaging 8 February 2001 756 758 4. Timely extension to ESMTP Deliver By extension 760 The purpose of this extension is to allow a message sender to 761 require that timely delivery semantics, described in this memo, be 762 supported all along the path from message sender to recipient, in 763 addition to the existing semantics of DELIVERBY. 765 4.1 Framework for TIMELY extension to DELIVERBY 767 This extends the framework template for DELIVERBY, given in RFC 768 2852 [5]: 770 (1) ESMTP extension name: 771 "Deliver by", extended for "timely completion" 773 (2) EHLO keyword: 774 DELIVERBY, extended as described below 776 (3) EHLO keyword parameters: 777 TIMELY (see 4.2 below) 779 (4) SMTP command parameters: 780 MAIL FROM: TIMELY (see 4.3 below) 782 (5) The maximum length of a MAIL FROM command line is increased by 783 a further 17 characters for the TIMELY parameter (this being in 784 addition to the 17 character extension for the basic DELIVERBY 785 extension. 787 (6) Additional SMTP commands: 788 (none) 790 4.2 Extension to EHLO DELIVERBY keyword 792 This specification defines an extension token for timely 793 completion. The extension token syntax (from RFC 2852 [5]) is 794 extended thus: 796 extension-token /= "TIMELY" 798 An ESMTP server that supports this timely completion extension MUST 799 also support the delivery status notification (DSN) ESMTP 800 extension. 802 Support for the timely completion extension indicates support for 803 the MAIL FROM: TIMELY parameter, described below, and for all the 804 associated processing semantics. 806 Timely Completion for Internet Messaging 8 February 2001 807 809 4.3 MAIL FROM: TIMELY parameter 811 The MAIL FROM command TIMELY parameter MUST be used in conjunction 812 with a BY parameter. Its use imposes requirements on the receiving 813 server's handling of the message that are in addition to those 814 imposed by the BY parameter. 816 TIMELY parameter syntax: 818 timely-parameter = "TIMELY=" interval 819 interval = 1*9DIGIT 821 The 'interval' is specified by the original sender of a message to 822 be the same as the corresponding BY parameter value. 824 A mail relay copies the received TIMELY value to the retransmitted 825 message, unchanged. In this way, the originally specified delivery 826 interval is available to all MTAs that handle the message. 828 The effect of a TIMELY parameter is to require that message 829 processing is performed in accordance with the timely completion 830 mechanisms described in section 3 above. 832 5. DSN reporting extensions 834 This specification defines some DSN reporting extensions to allow 835 additional status information to be returned, which a sending 836 system might use in choosing a recovery strategy. 838 5.1 New extended mail system status codes 840 This memo defines the following additional enhanced mail system 841 status codes, extending the range of those defined by RFC 1893 842 [13]: 844 5.4.8???: MTA cannot honour required timely delivery guarantee. 846 5.2.5???: Message delivered but disposition failed. 848 5.2.6???: Message delivered but disposition not completed. 850 4.2.6???: Message delivered pending final disposition. 852 See section 3.4 for more detailed descriptions. 854 Timely Completion for Internet Messaging 8 February 2001 855 857 5.2 'Retry-count' per-recipient DSN header 859 This memo defines an additional per-recipient DSN report field 860 'Retry-count': 862 retry-count-field = "Retry-Count" ":" 1*3DIGIT 864 This field is used in conjunction with status code 5.4.1 to 865 indicate the number of retries attempted before delivery was 866 abandoned. A value of "0" means that no retries were attempted. 867 The purpose of this is to provide information to the sender that 868 can be used in deciding a recovery strategy. 870 NOTE: It is in the nature of timely completion that 871 retries, if performed, would need to be more closely 872 spaced than is normal for SMTP retries; thus it may be 873 necessary to reduce the number of retries to avoid 874 overloading a relay. Some relays may choose not attempt 875 any retries for messages sent with the TIMELY option. In 876 such circumstances, a sender may wish to retry before 877 attempting transmission by some alternative means. 879 6. Implementation notes 881 This section is not a normative part of this specification. 883 The timely completion mechanism is a response to requests for 884 improved performance in certain uses of email. 886 Ultimately, achieving the desired performance levels is dependent 887 on quality of implementation and operational deployment factors. 888 If a system capable of handling 1000 messages-per-hour is subjected 889 to periods of demand for 2000 messages-per-hour throughput, then 890 the performance goals are bound to be substantially under-achieved, 891 whatever the protocol specification may demand. 893 The rest of this section discusses some of the implementation 894 issues and choices raised by this memo, and indicates some ways in 895 which the performance goals can be addressed. 897 6.1 Message state management 899 All requirements for extended-term state rentention are in the 900 sending and receiving MTAs -- at or close to the edge of the 901 network. Ideally, these would be the the only MTAs involved, so 902 provisioning of the service would be entirely under the control of 903 the organizations who use (or sell) it. 905 Timely Completion for Internet Messaging 8 February 2001 906 908 Where intermediate relays are used, there is no requirement to 909 maintain information about a message after it has been relayed. 910 Thus there are no scalability problems created by a need for state 911 maintenance; performance comes down to message throughput. The 912 requirement for "reasonable effort" rather than "best effort" 913 delivery for TIMELY messages means that some message handling 914 requirements can be relaxed. Rather than copying message data to 915 disk for re-transmission, it can be held in memory -- it might even 916 be streamed through to the next relay; loss of message data is not 917 critical because reporting failure back to the sender is an allowed 918 option. 920 When a TIMELY MTA is subjected to high load factors, it needs a 921 strategy for dealing with this. 923 The design for timely confirmation to the sender depends on 924 reasonably consistent transit times on the forward and return 925 message paths. Delays on the forward path are picked up and 926 responses can be generated. Delays on the return path will result 927 in loss of confirmation; losing failure responses should not be 928 too damaging as the sender will time out and invoke a recovery 929 strategy. Losing success responses is more harmful, as it may 930 cause unnecessary additional network traffic. 932 In view of the above, the following message handling strategy is 933 suggested: 935 o Give top priority to forwarding timely status notifications; 936 i.e. messages with a BY parameter and no return path address. 938 o Give next priority to receiving new messages. Under conditions 939 of excessively high load, incoming messages with the TIMELY 940 option should be rejected immediately; e.g. SMTP [2] response 941 [[[421???]]] to any incoming MAIL FROM command with a TIMELY 942 parameter. Non-TIMELY messages can be moved to persistent 943 storage for later attention. 945 o Give next priority to processing accepted messages using the 946 TIMELY option. 948 o Give next priority yto forwarding messages using the DELIVERBY 949 option. 951 o Finally, forward ordinary messages 952 Timely Completion for Internet Messaging 8 February 2001 953 955 If confirmation for a message sent using the TIMELY option is not 956 received within the expected interval, the sender should be very 957 copnservative about simply retrying. The reason for non-receipt of 958 confirmation is probably: 960 (a) because of mail system congestion, in which case 961 retransmission will just make things worse, or 963 (b) some other network problem, in which case a retry won't help. 965 Since the motivation for this proposal is to provide message 966 delivery while the sender waits, a reasonable approach would be to 967 give the sender an option to retry later, send by regular email or 968 use some other delivery mechanism. 970 6.2 Retransmission timing issues 972 Even allowing for the caution stated above about the problems of 973 simply retransmitting a failed message, it may be that some limited 974 retransmission is appropriate as part of a recovery strategy. 976 In order not to exacerbate congestion of intermediate relays, the 977 following approach is suggested: 979 o A first retry should not be attempted before 4x the original 980 DELIVERBY interval has expired. 982 o Subsequent retry attempts should be attempted at exponentially 983 increasing intervals; e.g. 8x original interval for the 2nd 984 retry, 16x for the 3rd retry, etc. 986 o The requested delivery interval should be increased exponentially 987 for each retry. 989 o The total number of retries attempted should be kept reasonably 990 small; e.g. a maximum of 3-4 retries. 992 o The receiver of a message should keep a record of the received 993 message identifier for some period of time, at least 8 times the 994 original DELIVERBY interval, for the purpose of weeding out 995 duplicates. It is not possible to state an absolute upper bound 996 on this period, but it should be as long as the receiver can 997 reasonably manage, but probably no more than a few days. 999 More specific recommendations for retransmission strategies may 1000 emerge from deployment experience with this protocol. The basic 1001 approach outlined above uses lessons learned from TCP, notably that 1002 exponential back-off is important to avoid exacerbating congestion 1003 conditions that may be the reason for failure in the first place. 1005 Timely Completion for Internet Messaging 8 February 2001 1006 1008 6.3 Delivery timing granularity 1010 This proposal uses seconds for its time interval values. The best 1011 possible timing resolution for each relay is a whole number of 1012 seconds. Careless handling of these time intervals could lead to 1013 timing errors of a second or worse at each relay. 1015 In general, it is expected that delivery time intervals will be of 1016 the order of 10s of seconds, not less than 10 seconds. The effects 1017 of cummulative timing errors should not be significant if the 1018 number of MTAs involved is kept small (e.g. no more than 2 1019 intermediate relays). 1021 The following procedure is suggested for dealing with timing 1022 through relay MTAs: 1024 o On receipt of a MAIL FROM command, note the time at which it was 1025 received, preferably with a sub-second granularity. 1027 o When the message is subsequently forwarded, note the time 1028 immediately prior to generating the new MAIL FROM command, and 1029 use the difference from time of receipt to calculate the transit 1030 delay. The calculated transit delay should be rounded up to a 1031 whole number of seconds. 1033 o Generate a new MAIL FROM command with the BY parameter 'by-time' 1034 value decreased by the transit delay value. 1036 Rounding up the transit delay should mean that the BY interval is 1037 always decreased by at least 1 when passing through a relay. This 1038 should mean that if many relays are involved, the overall timing 1039 becomes more conservative. This is consistent with the idea that 1040 responsiveness to the sender is considered more important than 1041 actually achieving delivery. 1043 6.4 Partial success 1045 Messages sent to more than one recipient using the TIMELY option 1046 may succeed or fail independently. 1048 Systems must be designed to handle this possibility. E.g. a 1049 sending agent that gives the user an option to resend, or send by 1050 another route, should be capable of recognizing (and reporting) 1051 that some messages have been transferred successfully, and only 1052 attempt an alternative transfer for those that did not (unless, of 1053 course, the user directs otherwise). 1055 Timely Completion for Internet Messaging 8 February 2001 1056 1058 6.5 Routing TIMELY and non-TIMELY messages 1060 The use of MX mail routing means that TIMELY and non-TIMELY 1061 messages to the same domain will be routed via the same servers. 1062 It may be desirable to use separate servers for TIMELY messages. 1063 One way to achieve this operationally would be to use a different 1064 email domain for TIMELY messages, but this may not be ideal from te 1065 users' view of the service. 1067 6.6 Expediting message handling 1069 Invoking the DELIVERBY extension for a given message may be used by 1070 an MTA as a signal to expedite message delivery. But note that 1071 status reports are part of the timely completion cycle, and while 1072 these are sent using the DELIVERBY extension, they do not use the 1073 TIMELY option. Unlike forward-path delays, any delays on the 1074 return path may directly result in the silent loss of a message 1075 status report. 1077 This means that return path messages should be processed at least 1078 as expeditiously as the original message. Hence messages sent 1079 using the TIMELY option should not be given a higher priority than 1080 messages 1082 7. Examples 1084 In the following examples, 'C:' prefixes commands sent from the 1085 SMTP client to the server in a mail transaction, and 'S:' prefixes 1086 responses from the server back to the client. 1088 The notation '\' at the end of a command example indicates that it 1089 continues on the next line. The actual SMTP command must be 1090 presented on a single line. 1092 7.1 Timely delivery and confirmation 1094 This example is of a successful timely delivery and confirmation. 1096 +----------+ +----------+ +----------+ 1097 |Lemas.com |-->--|Benden.net|-->--|Harper.org| 1098 +----------+ +----------+ +----------+ 1100 First hop transfer: 1102 S: 220 Benden.net ESMTP server 1103 C: EHLO Lemas.com 1104 S: 250-Benden.net 1105 S: 250-DELIVERBY 10,TIMELY 1106 S: 250 DSN 1107 Timely Completion for Internet Messaging 8 February 2001 1108 1110 C: MAIL FROM: BY=20;R TIMELY=20 \ 1111 ENVID=EE271828 RET=HDRS 1112 S: 250 OK to attempt delivery within 20 seconds 1113 C: RCPT TO: NOTIFY=SUCCESS,FALURE \ 1114 ORCPT=rfc822;Robinton@Harper.org 1115 S: 250 OK 1116 C: DATA 1117 S: 354 Send data 1118 C: (message data goes here) 1119 : 1120 . 1121 S: 250 Message received 1123 At this point, the receiving server Benden.net has accepted 1124 responsibility to deliver the message to its destination or send a 1125 failure report back to the sender. Assuming that the next hop is 1126 initiated after a delay of 4 seconds, it may look like this: 1128 S: 220 Harper.org ESMTP server 1129 C: EHLO Benden.net 1130 S: 250-Harper.org 1131 S: 250-DELIVERBY 10,TIMELY 1132 S: 250 DSN 1133 C: MAIL FROM: BY=16;R TIMELY=20 \ 1134 ENVID=EE271828 RET=HDRS 1135 S: 250 OK 1136 C: RCPT TO: NOTIFY=SUCCESS,FALURE \ 1137 ORCPT=rfc822;Robinton@Harper.org 1138 S: 250 OK 1139 C: DATA 1140 S: 354 Send data 1141 C: (message data goes here) 1142 : 1143 . 1144 S: 250 Message received 1145 Timely Completion for Internet Messaging 8 February 2001 1146 1148 At this point, the delivery MTA Harper.org has accepted 1149 responsibility to achieve message disposition or to report a 1150 failure. This will depend on some kind of cooperation with the 1151 receiving user agent. When disposition is completed within the 1152 specified interval, a DSN report is sent in the following fashion: 1154 S: 220 Benden.net ESMTP server 1155 C: EHLO Harper.org 1156 S: 250-Benden.net 1157 S: 250-DELIVERBY 10,TIMELY 1158 S: 250 DSN 1159 C: MAIL FROM:<> BY=40;R 1160 S: 250 OK 1161 C: RCPT TO: NOTIFY=NEVER 1162 S: 250 OK 1163 C: DATA 1164 S: 354 Send data 1165 C: To: Asgenar@Lemas.com 1166 From: Message-handling@Harper.org 1167 Subject: Disposition OK for Robinton@Harper.org 1168 Content-type: multipart/report; boundary=next; 1169 report-type=delivery-status 1170 MIME-version: 1.0 1172 --next 1173 Content-type: text/plain; charset=US-ASCII 1175 Your message (EE271828) to was processed 1176 --next 1177 Content-type: message/delivery-status 1179 reporting-MTA: dns; mail-receiver.Harper.org 1180 Original-Envelope-ID: EE271828 1182 Original-recipient: rfc822;Robinton@Harper.org 1183 Final-recipient: rfc822;Robinton@Harper.org 1184 Action: delivered 1185 Status: 2.0.0 1186 --next-- 1187 . 1188 S: 250 Message received 1190 On receipt of this confirmation message, the sender's user agent 1191 will be able to correlate with the original using the 'Original- 1192 Envelope-ID' and 'Original-recipient' values, and confirm to the 1193 sender that the message has been delivered and processed. 1195 Timely Completion for Internet Messaging 8 February 2001 1196 1198 7.2 Timely delivery achieved, no timely disposition 1200 This example follows the same sequence as the previous one, up to 1201 the point that the delivery MTA Harper.org has accepted 1202 responsibility to achieve message disposition or to report a 1203 failure. In this case, having accepted the message for delivery, 1204 disposition cannot be achieved in the desired interval so a failure 1205 DSN must be sent: 1207 S: 220 Benden.net ESMTP server 1208 C: EHLO Harper.org 1209 S: 250-Benden.net 1210 S: 250-DELIVERBY 10,TIMELY 1211 S: 250 DSN 1212 C: MAIL FROM:<> BY=40;R 1213 S: 250 OK 1214 C: RCPT TO: NOTIFY=NEVER 1215 S: 250 OK 1216 C: DATA 1217 S: 354 Send data 1218 C: To: Asgenar@Lemas.com 1219 From: Message-handling@Harper.org 1220 Subject: Disposition failed for Robinton@Harper.org 1221 Content-type: multipart/report; boundary=next; 1222 report-type=delivery-status 1223 MIME-version: 1.0 1225 --next 1226 Content-type: text/plain; charset=US-ASCII 1228 Your message (EE271828) to could not 1229 be processed within the requested time. 1230 --next 1231 Content-type: message/delivery-status 1233 reporting-MTA: dns; mail-receiver.Harper.org 1234 Original-Envelope-ID: EE271828 1236 Original-recipient: rfc822;Robinton@Harper.org 1237 Final-recipient: rfc822;Robinton@Harper.org 1238 Action: failed 1239 Status: 5.2.5??? 1240 --next-- 1241 . 1242 S: 250 Message received 1244 Because this is a specific failure condition being sent to a source 1245 that has used the timely delivery extension, and the message can be 1246 correlated with the original by means of the 'Original-Envelope-ID' 1247 Timely Completion for Internet Messaging 8 February 2001 1248 1250 and 'Original-Recipient' values, no part of the original message is 1251 returned with the DSN report. 1253 7.3 Timely delivery achieved, disposition delayed 1255 This example is similar to the previous one, except that 1256 disposition is in progress but its completion is delayed. In this 1257 case, the message cannot be recalled, so a notification report is 1258 sent to the sender indicating, within the requested delivery 1259 period, indicating that the message is delivered and in 1260 disposition. Later, a final delivery status message will be sent. 1262 S: 220 Benden.net ESMTP server 1263 C: EHLO Harper.org 1264 S: 250-Benden.net 1265 S: 250-DELIVERBY 10,TIMELY 1266 S: 250 DSN 1267 C: MAIL FROM:<> BY=40;R 1268 S: 250 OK 1269 C: RCPT TO: NOTIFY=NEVER 1270 S: 250 OK 1271 C: DATA 1272 S: 354 Send data 1273 C: To: Asgenar@Lemas.com 1274 From: Message-handling@Harper.org 1275 Subject: Disposition delayed for Robinton@Harper.org 1276 Content-type: multipart/report; boundary=next; 1277 report-type=delivery-status 1278 MIME-version: 1.0 1280 --next 1281 Content-type: text/plain; charset=US-ASCII 1283 Your message (EE271828) to is being 1284 processed but not completed within the requested time. 1285 --next 1286 Content-type: message/delivery-status 1288 reporting-MTA: dns; mail-receiver.Harper.org 1289 Original-Envelope-ID: EE271828 1291 Original-recipient: rfc822;Robinton@Harper.org 1292 Final-recipient: rfc822;Robinton@Harper.org 1293 Action: delayed 1294 Status: 4.2.6??? 1295 --next-- 1296 . 1297 S: 250 Message received 1298 Timely Completion for Internet Messaging 8 February 2001 1299 1301 7.4 Timely delivery could not be achieved 1303 This example is of a failed attempt to achieve timely delivery 1304 because the message could not be forwarded within the requested 1305 interval. 1307 +----------+ +----------+ +----------+ 1308 |Ruatha.com|-->--|Fort.net |-->--|Harper.org| 1309 +----------+ +----------+ +----------+ 1311 First hop transfer: 1313 S: 220 Fort.net ESMTP server 1314 C: EHLO Ruatha.com 1315 S: 250-Fort.net 1316 S: 250-DELIVERBY 15,TIMELY 1317 S: 250 DSN 1318 C: MAIL FROM: BY=20;R TIMELY=20 \ 1319 ENVID=EE271828 RET=HDRS 1320 S: 250 OK to attempt delivery within 20 seconds 1321 C: RCPT TO: NOTIFY=SUCCESS,FALURE \ 1322 ORCPT=rfc822;Sebell@Harper.org 1323 S: 250 OK 1324 C: DATA 1325 S: 354 Send data 1326 C: (message data goes here) 1327 : 1328 . 1329 S: 250 Message received 1331 After a delay of 12 seconds (with 8 seconds of the original 1332 delivery interval remaining), the server Fort.net attempts to relay 1333 the message: 1335 S: 220 Harper.org ESMTP server 1336 C: EHLO Fort.net 1337 S: 250-Harper.org 1338 S: 250-DELIVERBY 10,TIMELY 1339 S: 250 DSN 1340 C: QUIT 1341 S: 221 closing channel 1342 Timely Completion for Internet Messaging 8 February 2001 1343 1345 The minimum delivery interval declared by the server Harper.org is 1346 greater than the time remaining to complete delivery, so Fort.net 1347 does not even attempt to send the message. Instead, it returns a 1348 failure report back to Ruatha.com: 1350 S: 220 Ruatha.com ESMTP server 1351 C: EHLO Fort.net 1352 S: 250-Ruatha.com 1353 S: 250-DELIVERBY 10,TIMELY 1354 S: 250 DSN 1355 C: MAIL FROM:<> BY=40;R 1356 S: 250 OK 1357 C: RCPT TO: NOTIFY=NEVER 1358 S: 250 OK 1359 C: DATA 1360 S: 354 Send data 1361 C: To: Jaxom@Ruatha.com 1362 From: Message-handling@Fort.net 1363 Subject: Delivery failed for Sebell@Harper.org 1364 Content-type: multipart/report; boundary=next; 1365 report-type=delivery-status 1366 MIME-version: 1.0 1368 --next 1369 Content-type: text/plain; charset=US-ASCII 1371 Your message (EE271828) to could not be 1372 delivered within the requested time. 1373 --next 1374 Content-type: message/delivery-status 1376 reporting-MTA: dns; mail-relay.Fort.net 1377 Original-Envelope-ID: EE271828 1379 Original-recipient: rfc822;Sebell@Harper.org 1380 Final-recipient: rfc822;Sebell@Harper.org 1381 Action: failed 1382 Status: 5.4.7 1383 Retry-count: 0 1384 --next-- 1385 . 1386 S: 250 Message received 1388 The retry count value is returned to give the sender an indication 1389 about whether it might retry this path before switching to an 1390 alternative delivery strategy. 1392 Timely Completion for Internet Messaging 8 February 2001 1393 1395 7.5 Timely delivery feature not supported 1397 This final example shows failure of a timely delivery request 1398 because a receiving MTA does not support the capability: 1400 +----------+ +----------+ +----------+ 1401 |Lemas.com |-->--|Benden.net|-->--|Miners.org| 1402 +----------+ +----------+ +----------+ 1404 First hop transfer: 1406 S: 220 Benden.net ESMTP server 1407 C: EHLO Lemas.com 1408 S: 250-Benden.net 1409 S: 250-DELIVERBY 10,TIMELY 1410 S: 250 DSN 1411 C: MAIL FROM: BY=20;R TIMELY=20 \ 1412 ENVID=EE271828 RET=HDRS 1413 S: 250 OK to attempt delivery within 20 seconds 1414 C: RCPT TO: NOTIFY=SUCCESS,FALURE \ 1415 ORCPT=rfc822;Nicat@Miners.org 1416 S: 250 OK 1417 C: DATA 1418 S: 354 Send data 1419 C: (message data goes here) 1420 : 1421 . 1422 S: 250 Message received 1424 Five seconds later, Benden.net attempts to forward the message: 1426 S: 220 Minbers.org ESMTP server 1427 C: EHLO Benden.net 1428 S: 250-Harper.org 1429 S: 250-DELIVERBY 60 1430 S: 250 DSN 1431 C: QUIT 1432 S: 221 closing channel 1433 Timely Completion for Internet Messaging 8 February 2001 1434 1436 The Miners.org server does not support timely delivery, so 1437 Benden.net does not attempt to send the message. Instead, it sends 1438 a failure report back to Lemas.com: 1440 S: 220 Lemas.com ESMTP server 1441 C: EHLO Benden.net 1442 S: 250-Lemas.com 1443 S: 250-DELIVERBY 10,TIMELY 1444 S: 250 DSN 1445 C: MAIL FROM:<> BY=40;R 1446 S: 250 OK 1447 C: RCPT TO: NOTIFY=NEVER 1448 S: 250 OK 1449 C: DATA 1450 S: 354 Send data 1451 C: To: Asgenar@Lemas.com 1452 From: Message-handling@Benden.net 1453 Subject: Delivery failed for Nicat@Miners.org 1454 Content-type: multipart/report; boundary=next; 1455 report-type=delivery-status 1456 MIME-version: 1.0 1458 --next 1459 Content-type: text/plain; charset=US-ASCII 1461 Your message (EE271828) to could not be 1462 delivered within the requested time. 1463 --next 1464 Content-type: message/delivery-status 1466 reporting-MTA: dns; mail-relay.Benden.net 1467 Original-Envelope-ID: EE271828 1469 Original-recipient: rfc822;Nicat@Miners.org 1470 Final-recipient: rfc822;Nicat@Miners.org 1471 Action: failed 1472 Status: 5.4.8??? 1473 --next-- 1474 . 1475 S: 250 Message received 1477 8. IANA Considerations 1479 This specification introduces some new protocol elements for which 1480 IANA registration be required or desirable: 1482 o Extension to DELIVERBY ESMTP extension: see section 4. 1484 o New extended mail system status codes: see section 5.1. 1486 Timely Completion for Internet Messaging 8 February 2001 1487 1489 o New DSN report per-recipient field: see section 5.2. 1491 [[[What to do about these?]]] 1493 9. Internationalization considerations 1495 This specification introduces no new internationalization 1496 considerations other than those already present in DSN, which, 1497 through MIME, provides for charset identification and language 1498 tagging of the human readable part of a DSN report. 1500 10. Security considerations 1502 See also RFC 1894 [12], RFC 2852 [5]. 1504 To offer timely handling of messages may require some dedication of 1505 resource. It is conceivable that systems supporting this feature 1506 may be more susceptible to denial of service attacks from a flood 1507 of messages requesting timely completion. (See also section 6.1.) 1509 There is a distant possibility that responses to time-sensitive 1510 requests may disclose information about the loading or topology of 1511 the network accessed. This is unlikely to be any worse than for 1512 web acces protocols (but note that HTTP has been shown to allow 1513 certain kinds of timing attack on private information about a 1514 client's network activities.). 1516 Systems that depend on the physical presence of a user to achieve 1517 timely disposition should not accept a message for such disposition 1518 without the user's explicit permission (c.f. automated generation 1519 of MDN responses in RFC 2998 [14]). 1521 11. Acknowledgements 1523 The authors thank Hiroshi Tamura-san for undertaking the task of 1524 reviewing a very rough, early draft and making several pertinent 1525 observations. 1527 12. References 1529 [1] RFC 2542, "Terminology and Goals for Internet Fax" 1530 L. Masinter, Xerox Corporation 1531 March 1999. 1533 Timely Completion for Internet Messaging 8 February 2001 1534 1536 [2] RFC 821, "Simple Mail Transfer Protocol" 1537 Jonathan B. Postel, ISI/USC 1538 August 1982. 1540 [3] RFC 1651, "SMTP Service Extensions" 1541 J. Klensin, MCI 1542 N. Freed, Innosoft 1543 M. Rose, Dover Beach Consulting, Inc. 1544 E. Stefferud, Network Management Associates, Inc. 1545 D. Crocker, Silicon Graphics, Inc. 1546 July 1994. 1548 [4] RFC 1891, "SMTP Service Extension for Delivery Status 1549 Notifications" 1550 K. Moore, University of Tennessee 1551 January 1996. 1553 [5] RFC 2852, "Deliver By SMTP Service Extension" 1554 D. Newman, Sun Microsystems 1555 June 2000 1557 [6] "Content Negotiation for Internet Messaging Services" 1558 G. Klyne, Baltimore Technologies 1559 R.Iwazaki, Toshiba TEC 1560 D. Crocker, Brandenburg Consulting 1561 Internet draft: draft-ietf-fax-content-negotiation-03.txt 1562 Work in progress: January 2001. 1564 [7] RFC 2234, "Augmented BNF for Syntax Specifications: ABNF" 1565 D. Crocker (editor), Internet Mail Consortium 1566 P. Overell, Demon Internet Ltd. 1567 November 1997. 1569 [8] "Procedures for document facsimile transmission in the general 1570 switched telephone network" 1571 ITU-T Recommendation T.30 (1996), including Amendment 1 (1997), 1572 Amendment 2 (1997), Amendment 3 (1998) and Amendment 4 (1999) 1573 International Telecommunications Union. 1575 [9] RFC 1047, "Duplicate messages and SMTP" 1576 C. Partridge 1577 February 1988. 1579 [10] RFC 974, "Mail routing and the domain system" 1580 C. Partridge 1581 January 1986. 1583 Timely Completion for Internet Messaging 8 February 2001 1584 1586 [11] RFC 2119, "Key words for use in RFCs to Indicate Requirement 1587 Levels" 1588 S. Bradner, Harvard University 1589 March 1997. 1591 [12] RFC 1894, "An Extensible Format for Delivery Status 1592 Notifications" 1593 K. Moore, University of Tennessee 1594 G. Vaudreuil, Octel Network Services 1595 January 1996. 1597 [13] RFC 1893, "Enhanced Mail System Status Codes" 1598 G. Vaudreuil, Octel Network Services 1599 January 1996. 1601 [14] RFC 2298, "An Extensible Message Format for Message Disposition 1602 Notifications" 1603 R. Fajman, National Institutes of Health 1604 March 1998. 1606 13. Authors' addresses 1608 Graham Klyne (editor) 1609 Baltimore Technologies - Content Security Group, 1610 1220 Parkview, 1611 Arlington Business Park 1612 Theale 1613 Reading, RG7 4SA 1614 United Kingdom. 1615 Telephone: +44 118 930 1300 1616 Facsimile: +44 118 930 1301 1617 E-mail: GK@ACM.ORG 1619 David H. Crocker 1620 Brandenburg Consulting 1621 675 Spruce Drive 1622 Sunnyvale 1623 CA 94086 1624 USA. 1625 Telephone: +1 408 246 8253 1626 Facsimile: +1 408 273 6464 1627 E-mail: dcrocker@brandenburg.com 1628 Timely Completion for Internet Messaging 8 February 2001 1629 1631 Appendix A: Amendment history 1633 00a 22-Oct-1999 Memo initially created. 1635 01a 13-Sep-1999 Incorporate review comments. Update references. 1636 Changed title. Incorporate material from IETF 1637 meeting presentations. 1639 02a 25-Jan-2001 Update author details. Simplify COMPLIANCE 1640 extension to a TIMELY extension of DELIVERBY. Add 1641 original interval parameter to TIMELY option. 1642 Strengthen description of mechanism for timely 1643 confirmation. Add template decsription for TIMELY 1644 extension. Refer to the goal of this 1645 specification as "timely completion" rather than 1646 just "timely delivery" (to clearly distinguish 1647 from basic DELIVERBY). Added subsection dealing 1648 with final MTA/MUA interaction. Defined DSN 1649 extension header and status codes for reporting 1650 timely delivery failures. Drafted some 1651 implementation notes. 1653 02b 30-Jan-2001 Add examples. Update some references. Other 1654 editorial drafting. 1656 02c 31-Jan-2001 Fold in review comments. Added implementation 1657 note about using DELIVERBY to expedite message 1658 handling (6.5). 1660 02d 01-Feb-2001 More editorial changes. 1662 02e 01-Feb-2001 Revised text dealing with time-out; move 1663 discussion of retries to implementation notes. 1665 TODO: 1667 o Need to define a mechanism to allow a MAIL FROM with TIMELY 1668 option to be rejected immediately, for congestion control. 1670 o Finalize status codes 1672 REVIEW CHECKLIST: 1674 (Points to be checked or considered more widely on or before final 1675 review.) 1677 o Are there any deployed mechanisms that MTAs may use to recognize 1678 expedited message relay? 1679 Timely Completion for Internet Messaging 8 February 2001 1680 1682 o Possible minor revision to DELIVERBY spec? If a DELIVERBY MTA 1683 fails message delivery because the delivery time has expired, AND 1684 the message has an empty SMTP sender address/return path, the 1685 message should be siletly discarded (c.f. RFC 1891, section 6.2; 1686 I think the considerations noted there seem less applicable.). 1687 If this doesn't work, try next... 1689 o Consider addition of new 'by-mode' value for return DSNs; e.g. 1690 'E' for expedite: try to deliver within interval given, or 1691 abandon delivery, but don't notify success or failure. 1692 (Currently specify 'R' without return-path.) A notification 1693 should not be abandoned if a non-DELIVERBY MTA is encountered. 1695 o Try to model system behaviour under high-load/backlog conditions. 1696 Especially w.r.t. section 3.5. 1698 o What lessons to learn from IP QoS efforts? 1700 o Query use of enhanced status codes 4.x.x and 5.x.x; Use by 1701 DELIVERBY seems at odds with RFC 1893. 1703 o Note use of status 5.4.1 not in line with expectations of RFC 1704 1893. 1706 o Use new code instead of 5.3.3? 1708 o Special considerations for fax offramp gateay? How to deal with 1709 uncertain dial-out times. 1711 o Check new status code values (currently n???). Should there be 1712 an IANA registry for Enhanced Mail System Status codes (RFC 1713 1893)? 1715 o Apparently, DSN extension fields must be registered with IANA, 1716 but there appears to be no registry for them. 1718 o Use of alternative port? (e.g. like message submission). 1720 o Allow MTAs to impose size limit on messages for timely delivery? 1722 o Allow for separate delivery and disposition times? (e.g. 10 1723 second transfer + 60 second disposition would leave a sender 1724 waiting for a long time to determine failure.) 1726 o Operational issues surrounding selection of delivery interval? 1728 o DISCUSS: In environments where the timing of final delivery of 1729 the message is outside the control of the final MTA (e.g. the 1730 time required for an outdial, or waiting for a client to collect 1731 the message), an interim DSN report may be generated indicating 1732 Timely Completion for Internet Messaging 8 February 2001 1733 1735 that the message has been received pending final delivery. This 1736 report should be clear whether final delivery is dependent on the 1737 receiving user (e.g. mail collection) or some other unknown 1738 infrastructure delay (e.g. fax out-dial or external e-mail 1739 environment). 1741 This is covered somewhat by section 3.3.1: is this adequate? 1743 o MX configuration -- uniform routing for TIMELY/non-TIMELY. Is a 1744 differential routing option required; e.g. SRV records? 1746 o Can use of ORCPT be relaxed? If partial success occurs for 1747 multiple recipients, it is important to be able to tell which 1748 were successful and which were not. 1750 o When a timely-delivery failure message is sent back, it is 1751 addressed to the sender of the original message; thus it becomes 1752 the sender UA responsibility to handle the failure of timely 1753 delivery -- does this cause any problems? 1755 o Check examples. (Should relays declare mail-domain or host name? 1756 Does it matter? Should the From: header for DSNs always be 1757 'postmaster', or is any appropriate mailbox OK?) 1759 Full copyright statement 1761 Copyright (C) The Internet Society 2001. All Rights Reserved. 1763 This document and translations of it may be copied and furnished to 1764 others, and derivative works that comment on or otherwise explain 1765 it or assist in its implementation may be prepared, copied, 1766 published and distributed, in whole or in part, without restriction 1767 of any kind, provided that the above copyright notice and this 1768 paragraph are included on all such copies and derivative works. 1769 However, this document itself may not be modified in any way, such 1770 as by removing the copyright notice or references to the Internet 1771 Society or other Internet organizations, except as needed for the 1772 purpose of developing Internet standards in which case the 1773 procedures for copyrights defined in the Internet Standards process 1774 must be followed, or as required to translate it into languages 1775 other than English. 1777 The limited permissions granted above are perpetual and will not be 1778 revoked by the Internet Society or its successors or assigns. 1780 Timely Completion for Internet Messaging 8 February 2001 1781 1783 This document and the information contained herein is provided on 1784 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1785 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1786 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1787 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1788 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.