idnits 2.17.1 draft-ietf-fax-timely-delivery-03.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 67 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 (13 June 2001) is 8353 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 1523, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1557, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1572, 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 13 June 2001 5 Expires: December 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/1id-abstracts.html 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 57 Discussion of this document 59 Please send comments to: . 61 To subscribe: send a message with the body 'subscribe' to 62 . The mailing list archive is at 63 . 65 67 Table of contents 69 1. Introduction.............................................4 70 1.1 Structure of this document ...........................4 71 1.2 Document terminology and conventions .................4 72 2. Background and goals.....................................5 73 2.1 Background ...........................................6 74 2.2 Basis for timely completion ..........................6 75 2.2.1 The SMTP "contract"..............................7 76 2.2.2 Framework for timely delivery....................7 77 2.3 What does the TIMELY option add? .....................8 78 2.3.1 DELIVERBY and timely disposition.................9 79 2.4 Goals for timely completion ..........................9 80 3. Mechanisms for timely completion.........................10 81 3.1 Transmitting a message for timely completion .........11 82 3.2 Relaying a message ...................................12 83 3.3 Accepting a message by the final MTA .................13 84 3.3.1 Disposition timing...............................13 85 3.4 Reporting failures ...................................14 86 3.5 Timely confirmation ..................................15 87 4. Timely extension to ESMTP Deliver By extension...........17 88 4.1 Framework for TIMELY extension to DELIVERBY.............17 89 4.2 Extension to EHLO DELIVERBY keyword.....................17 90 4.3 MAIL FROM: TIMELY parameter.............................18 91 5. DSN reporting extensions.................................18 92 5.1 New extended mail system status codes ................18 93 5.2 'Retry-count' per-recipient DSN header ...............19 94 6. Implementation notes.....................................19 95 6.1 Message state management .............................19 96 6.2 Retransmission timing issues .........................21 97 6.3 Delivery timing granularity ..........................22 98 6.4 Partial success ......................................22 99 6.5 Routing TIMELY and non-TIMELY messages ...............23 100 6.6 Expediting message handling ..........................23 101 7. Examples.................................................23 102 7.1 Timely delivery and confirmation .....................23 103 7.2 Timely delivery achieved, no timely disposition ......26 104 7.3 Timely delivery achieved, disposition delayed ........27 105 7.4 Timely delivery could not be achieved ................28 106 7.5 Timely delivery feature not supported ................30 107 8. IANA Considerations......................................31 108 9. Internationalization considerations......................32 109 10. Security considerations.................................32 110 11. Acknowledgements........................................32 111 12. References..............................................32 112 13. Authors' addresses......................................34 113 Appendix A: Amendment history...............................35 114 Full copyright statement....................................37 115 117 1. Introduction 119 RFC 1891 [4] defines an ESMTP extension for delivery status 120 notifications, and RFC 2852 [5] defines one for requesting delivery 121 of a message within a given interval. This memo describes how to 122 use those specifications, with some small extensions, to achieve 123 timely completion of message delivery. 125 1.1 Structure of this document 127 Section 2 gives the background, principal ideas and goals of this 128 specification. 130 Section 3 describes the mechanisms used, and how they are combined 131 to achieve the timely delivery goals. 133 Section 4 describes an addition to the ESMTP "Deliver by" extension 134 which is one of the mechanisms used to achieve timely delivery. 136 Section 5 describes extensions to the DSN reporting format and 137 status codes used to report conditions related to timely delivery 138 requests. 140 Section 6 contains some non-normative discussion of implementation 141 issues related to this specification. 143 Section 7 contains some examples uses of this specification. 145 1.2 Document terminology and conventions 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 149 this document are to be interpreted as described in RFC 2119 [11]. 151 Timely delivery 152 means a message is delivered to a recipient's MTA within a 153 specified time interval. 155 Timely disposition 156 means a message is delivered to and processed by a recipient's 157 user agent within a specified time interval. 159 Timely completion 160 means that notification of a requested timely disposition or 161 timely delivery is received by the sender of a message within 162 a determined time interval. Non-receipt of notification 163 within that interval is indicative of failure. 165 167 Delivery interval 168 A period of time, measured in seconds, allowed for completion 169 of message delivery and disposition. 171 Best efforts 172 Indicating that a system will ensure that an assigned task is 173 successfully completed under all but the most catastrophic of 174 failure circumstances. Common failure modes, such as power 175 failures, should not prevent eventual completion of a task. 177 Reasonable efforts 178 Indicating that a while system will try to complete an 179 assigned task, it may also indulge in behaviours, or make 180 operational decisions, that significantly reduce the certainty 181 that an action will be completed in the face of disruptive 182 circumstances. 184 MTA, Mail Transfer Agent 185 An email system component whose role is to receive and 186 transfer a message. 188 MUA, Mail User Agent 189 An email system component whose role is to prepare and send, 190 or to receive and process, a message. MUAs are the endpoints 191 between which emails are sent; MTAs are relays on the path 192 from a sending MUA to a receiving MUA. 194 Delivery MTA 195 In the context of a particular email transfer, the MTA that 196 accepts the message and passes it to the receiving MUA. 198 NOTE: Comments like this provide additional nonessential 199 information about the rationale behind this document. 200 Such information is not needed for building a conformant 201 implementation, but may help those who wish to understand 202 the design in greater depth. 204 [[[Editorial comments and questions about outstanding issues are 205 provided in triple brackets like this. These working comments 206 should be resolved and removed prior to final publication.]]] 208 2. Background and goals 210 RFC 2852 [5] provides a mechanism to request timely delivery of a 211 message using SMTP. While this is helpful, it falls short for some 212 usage profiles, such as timely processing of fax messages. These 213 profiles are determined, in part, by the capabilities of 214 traditional facsimile [8]. 216 218 2.1 Background 220 Traditional e-mail [2] is open-loop. The sender of a message 221 normally has no certainty if or when a message is delivered. (A 222 separate memo [6] contains a discussion of some open- and closed- 223 loop issues in e-mail.) 225 To be more than just a hint to the message transfer system, timely 226 completion requires a deterministic confirmation mechanism, to 227 close the loop. This is provided by DSN [4]. 229 Four kinds of timeliness can be identified: 231 (a) timely delivery to the recipient 233 (b) timely delivery to and processing by the recipient 235 (c) timely notification to the sender of delivery 237 (d) timely notification to the sender that the message has been 238 delivered to and processed by the recipient 240 From the sender's point of view, timely confirmation of delivery 241 and processing is the most desirable requirement. 243 2.2 Basis for timely completion 245 A key premise of this proposal is that timeliness CAN be achieved 246 using existing protocols, with appropriate software design and 247 operational management. But the sender and receiver do not control 248 all the relays used: 250 o The real issue is lack of determinism: a message might be 251 delivered quickly, or it might take hours or even days, or it 252 might not be delivered at all; the sender has little knowledge 253 and no control. 255 o A second issue is post-delivery handling: will the receiving 256 user agent process the message in timely fashion? 258 Then, assuming that the infrastructure is generally capable of 259 achieving the desired timely completion, the main thrust of this 260 memo is provide protocol enhancements that put the sender in 261 complete control on those occasions when timeliness is not 262 achieved. 264 One challenge to achieving this is dealing with uncertain transit 265 times of the confirmation message over the return path (which is 266 not necessarily the same as the forward path). 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 314 As well as requesting timely delivery of a message, this proposal 315 needs to take account of the possibly varying characteristics of 316 relays of the outbound and return message paths. Practically, it 317 is possible to require that every relay on the outbound path 318 recognizes timely completion semantics (using the ESMTP extension 319 framework), but it is not possible to require this of every relay 320 on the return path. Thus, it may be necessary to make some 321 assumptions about the confirmation return path. 323 NOTE: The uncertainty about return path characteristics 324 might be removed by requiring an MTA to send any timely 325 delivery notifcation to the MTA from which it was 326 received, but this goes against trends in SMTP design and 327 deployment. This might also raise state maintenance and 328 hence scalability concerns. 330 The other issue apparent from the diagram is that providing timely 331 delivery through the SMTP message relays does not ensure that the 332 receiving UA will process the message in a timely fashion. If the 333 receiving MTA delivers to a POP mailbox, there is currently no way 334 that it can guarantee timely disposition. 336 2.3 What does the TIMELY option add? 338 The TIMELY option adds three elements to the DELIVERBY extension: 340 o it modifies the SMTP contract, permitting an MTA to commute its 341 responsibility for delivering the message from "best effort" to 342 "reasonable effort", with notification of outcome. 344 o it extends the reach of the timeliness constraint to cover the 345 disposition step (see below). 347 o it establishes a basis for determining the allowable time 348 interval for certain behaviours initiated by the receiver of a 349 message (i.e. DELIVERBY interval for delivery status responses, 350 and how long to wait for possible duplicate message 351 transmissions). 353 This is all consistent with the fundamental strategy of giving the 354 sender control over the whole process: if an MTA or the disposing 355 agent cannot communicate the required guarantee, delivery is not 356 completed and the sender is duly notified. 358 2.3.1 DELIVERBY and timely disposition 360 Timely completion of delivery is handled by the DELIVERYBY ESMTP 361 extension base specification [5]. However its scope ends with 362 final delivery by SMTP, not covering receipt and processing 363 disposition. The TIMELY option modifies the DELIVERBY semantics to 364 366 cover the additional step needed to reach the recipient and process 367 the message. 369 Consider the following scenario: 371 +------+ +-----+ +---------+ ------- +---------+ 372 |Sender|-->--|Relay|-->--|Receiving|->-(Message)->-|Disposing| 373 | MTA | | MTA | | MTA | ( store ) | agent | 374 +------+ +-----+ +---------+ ------- +---------+ 376 <------SMTP-------> <-------?-------> 378 The base DELIVERBY specification concerns itself with only 379 participants in the SMTP transfers. But for the purposes of timely 380 completion of disposition, the sender must be able to specify the 381 timeliness constraint to include this extra step. 383 The TIMELY option requires that the receiving MTA communicates with 384 the disposing agent (in some unspecified way), and that it confirms 385 final delivery of the message only if the disposing agent confirms 386 that it will deal with the message in timely fashion, or that it 387 will return an indication to the receiving MTA if it fails to do 388 so. Simply putting the message into a POP mailbox would not meet 389 this criterion. 391 2.4 Goals for timely completion 393 The primary goal is to allow consenting parties to establish a 394 relationship that carries a guarantee of message disposition a 395 within a specified time, or timely notification that the 396 disposition was not achieved. 398 Further goals are: 400 o Provide "while-you-wait" delivery of messages by e-mail (where 401 available infrastructure and connectivity permit). 403 o Deterministic behaviour. A sender who requests timely completion 404 should be able to determine with reasonable certainty, and in 405 reasonable time, whether or not that request was successful. 407 o If the message cannot be delivered as requested, it should not be 408 delivered at all. This means that a sender can choose other 409 strategies for message delivery (e.g. if timely delivery by email 410 does not succeed, to resend the message as a traditional 411 facsimile; in such circumstances it is preferable that multiple 412 copies of the message are not delivered. 414 o Operates within the existing ESMTP extension framework [3], using 415 existing facilities where available. 417 419 3. Mechanisms for timely completion 421 Deterministic timely completion is achieved through a number of 422 ESMTP extensions used in concert: 424 o Delivery Status Notification ("DSN"), per RFC 1891 [4]. 426 o Deliver-by ("DELIVERBY"), per RFC 2852 [5] 428 o A new TIMELY extension to DELIVERBY, that serves to modify the 429 SMTP contract and also to establish that the receiving user agent 430 can process the message in timely fashion as required, or provide 431 timely notification of its failure to do so 433 The confirmation loop for succesful delivery looks something like 434 this: 436 +-----------+ +--------+ +--------+ +---------+ 437 |Originating|-->--|Relaying| ... |Relaying|-->--|Receiving| 438 | MTA | | MTA | | MTA | --| MTA | 439 +-----------+ +--------+ +--------+ | +---------+ 440 | | | 441 +-------------+ | +---------+ 442 | Originating |--<-- ... .... ... --<-- |Receiving| 443 | MUA | | MUA | 444 +-------------+ +---------+ 446 The path through MTAs taken by the confirmation response is not 447 defined, and may be different than the forward path of the original 448 message. 450 3.1 Transmitting a message for timely completion 452 A transmitted message for which timely completion is required MUST 453 include the following: 455 o an 'ENVID' parameter on the MAIL FROM command, per DSN [4] 457 o an 'ORCPT' parameter on the corresponding RCPT TO command(s), per 458 DSN [4]. (This is to allow the sender to tell exactly which 459 recipients were succesfully delivered.) 461 o a 'NOTIFY=SUCCESS,FAILURE' parameter on the corresponding RCPT TO 462 command(s), per DSN [4] 464 o a 'BY' parameter on the MAIL FROM command, per [5], with a 'by- 465 mode' value of 'R'. 467 469 o a 'TIMELY' parameter on the MAIL FROM command, as described 470 below, initially having the same time interval as specified for 471 'BY'. 473 The message MUST NOT be transmitted to any MTA that does not 474 indicate support for all of these extensions in its response to the 475 EHLO command. In this case, a negative delivery status report MUST 476 be generated, which SHOULD indicate the non-compliant MTA, the 477 extensions that it does not support, and the name of the reporting 478 MTA (per DSN, using the non-compliance reporting extensions noted 479 later). 481 Standard DNS MX-based message routing, per RFC 974, SHOULD be used 482 when sending or relaying the message. 484 NOTE: Any strategies that vary standard MX routing 485 should be used with care, and only with the goal of 486 improving network transit times and timing consistency. 487 These comments about mail routing apply especially to the 488 handling of DSN responses. 490 Ideally, there will be no intermediate relay between the 491 sending and receiving MTAs, and in any case the number of 492 such relays should be minimized to reduce timing 493 variabilities on the transfer path. 495 3.2 Relaying a message 497 An MTA that relays a message for timely completion MUST support all 498 of the ESMTP extensions noted above, otherwise it should not be 499 given the message in the first place. When a relaying MTA accepts 500 a message (by its 2xx status response to receipt of the message 501 data), it becomes responsible for its onward delivery, including 502 satisfying all of the options associated with the message. 504 In order to relay such a message, an MTA MUST note when the message 505 was received, and the time when the attempt to transmit the message 506 to the next MTA is initiated, and reduce accordingly the time 507 interval used for the BY parameter. (The time interval should be 508 taken to start with receipt of the MAIL FROM command.) 510 If the DELIVERBY time interval is reduced to less than zero, (or 511 less than some system-configurable value indicating that delivery 512 within the indicated interval is unlikely to be achieved) then the 513 message MUST NOT be relayed. Instead, a negative delivery status 514 report MUST be generated indicating that the time for delivery of 515 the message has expired, and the reporting MTA (per DSN, using the 516 deliver-by extensions and/or non-compliance reporting extensions 517 noted below). 519 521 The above behaviour is as specified for the DELIVERBY ESMTP 522 extension; see RFC 2852 [5] for a definitive description of how to 523 handle relaying of such messages. The following additional 524 considerations are applicable when the TIMELY option is used: 526 The TIMELY parameter in the MAIL FROM command of a message in 527 transit is copied unchanged when the message is retransmitted. 528 Thus, any originally specified time interval is conveyed to the 529 final MTA, to be used as a basis for selecting a delivery interval 530 for returning a timely notification. 532 Standard DNS MX-based message routing, per RFC 974, SHOULD be used 533 when relaying the message. (See note at end of previous section.) 535 If the first attempt to relay a message fails, the relaying MTA MAY 536 assume that delivery within the desired time will not be achieved, 537 and immediately indicate a delivery failure, indicating the name of 538 the next-hop MTA. Alternatively, the relaying MTA may wait and 539 retry the transmission, provided that the retry attempt will be 540 performed within the remaining delivery period; if the 541 transmission cannot be completed after one or more such retries 542 then a negative DSN MUST be generated as noted above. 544 Any negative DSN generated should indicate the number of retries 545 attempted (where 0 means no retries). 547 The choice to retry or not retry is installation dependent. 548 Effectively, when a relay does not retry, any reposibility for 549 overcoming the delivery failure is passed back to the original 550 sender. This strategy may be appropriate for cases where very 551 rapid delivery is required or expected. 553 NOTE: The presence of a 'TIMELY' option may cause a 554 relay to abandon a message that it would otherwise retry 555 (even given a 'by-mode' value of 'R'). One purpose of 556 this option is to establish that responsiveness to the 557 sender is more important than getting the message 558 through. An effect of this may be to severely constrain 559 the number and frequency of retry attempts. 561 3.3 Accepting a message by the final MTA 563 The MTA that accepts final delivery of a message has responsibility 564 for passing the message to a Mail User Agent. The exact mechanism 565 by which this is achieved is a local matter, and not defined here 566 or by the Internet email specifications. The final MTA is also 567 responsible for generating any successful DSN message. 569 Before generating a success DSN message, the final MTA must ensure 570 that all of the conditions for delivery of the message have been 571 573 achieved. Specifically, when the TIMELY option is used, it should 574 ensure that final delivery to and processing by the MUA will be 575 completed within the delivery interval indicated as the value of 576 the BY parameter of the received MAIL FROM command. 578 Final delivery to an MUA is expected to include some guarantee of 579 timely processing. Exactly what this constitutes may depend 580 somewhat on the circumstances: in a simple case, depositing the 581 message in a local mailbox and immediately notifying the recipient 582 probably constitutes final delivery and processing. A more complex 583 case would be that of a fax offramp, where final delivery may be 584 completion of a successful outdial and transmission of the fax. 586 The time interval for completion of final delivery and processing 587 should be taken to start with receipt of the MAIL FROM command. 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 The relationship between the delivery MTA and receiving MUA can 599 work in one of two ways: 601 o the MUA always processes the message promptly, barring 602 exceptional circumstances. Queuing a message to a network 603 printer would constitute such processing -- normally the message 604 will be printed within seconds, even though it might be delayed 605 if the printer runs out of paper. The delivery MTA can generate 606 the final DSN when the MUA has accepted the message. 608 o the MUA attempts to process the message promptly and reports the 609 outcome within the remaining DELIVERBY period. If processing is 610 not performed within the stated period, the message is abandoned 611 and failure is signalled back to the delivery MTA. The delivery 612 MTA must hold off generating the final DSN until the MUA has 613 provided a status report; if no such report is provided within 614 the remaining DELIVERBY interval, it should report failure. 616 3.4 Reporting failures 618 When a relay or receiving MTA determines that a message cannot be 619 delivered as requested to any recipient, a DSN report is sent back 620 to the sender. 622 624 The following status codes indicated that message delivery has been 625 abandoned, are used with DSN "Action: failed" for reporting 626 conditions that are specific to timely delivery: 628 5.4.7: Delivery time expired -- permanent failure. 629 Message delivery could not be completed within the specified 630 time interval. 632 5.4.8???: MTA cannot honour required timely delivery guarantee. 633 A relay MTA was encountered that did not support the range of 634 capabilities required for timely completion. 636 5.4.1: Next MTA not accepting messages. 637 A relay MTA has been unable to contact a next-hop MTA, and has 638 decided to abandon delivery. (See note in section 3.2 about a 639 relay's options with respect to retries.) This code SHOULD be 640 accompanied by a 'Retry-Count' DSN field. 642 5.3.3: Receiving MTA cannot honour required timely disposition. 643 A message has been delivered to a receiving MTA within the 644 required delivery interval, but that MTA is unable to ensure 645 timely disposition or timely notification of failure to do so. 647 5.2.5???: Message delivered but disposition failed. 648 The message has been delivered but the MUA has reported 649 failure to complete disposition of the message as requested. 651 5.2.6???: Message delivered but disposition not completed. 652 The message has been delivered and the process of final 653 disposition has been initiated but has not been completed. 654 This status code signals that the receiving MTA is assuming 655 that the disposition has failed. 657 The following status code is used with DSN "Action: delayed" for 658 reporting delayed message disposition following final delivery: 660 4.2.6???: Message delivered pending final disposition. 661 The message has been delivered and is in the process of final 662 disposition, but that final disposition has not yet been 663 completed. This status code is defined for situations where a 664 receiving MTA has initiated disposition, and has therefore 665 committed to provide a timely confirmation response, but the 666 disposing agent has not signalled completion. 668 For example, a fax dial-out gateway may have been invoked 669 assuming that the outdial leg would complete within a given 670 period, but has failed to do so. 672 A subsequent DSN should be sent when the disposition finally 673 succeeds or fails. 675 677 3.5 Timely confirmation 679 Fully deterministic behaviour requires that the round-trip time to 680 deliver a message and receive a response is completed within a 681 known time interval. 683 As noted above, it cannot be guaranteed that confirmation of 684 delivery or non-delivery will be transferred in timely fashion, 685 though it seems reasonable to assume that return path transit times 686 will normally be comparable with forward path times. Use of the 687 DELIVERBY extension for a message MAY serve to expedite its 688 forwarding. 690 Further, it is likely that perfect determinism can never be 691 achieved using SMTP; e.g. see RFC 1047 [9]. Repeat deliveries are 692 considered less harmful than lost messages, but even these should 693 be minimized. 695 The following behaviour is followed to achieve near-deterministic 696 timely confirmation: 698 o Always fail forward delivery if a non-TIMELY MTA is encountered. 700 o A return DSN does not itself request delivery notification and 701 has an empty return path (as required for DSN). 703 o Do NOT use the TIMELY option on any DSN return, so that 704 notification delivery does not fail if a non-DELIVERBY or 705 non-TIMELY MTA is encountered on the return path. 707 o Use the DELIVERBY option to request timely delivery for any DSN 708 return, using a delivery interval 2 times the original forward 709 path DELIVERBY time (taken from the received TIMELY parameter), 710 specifying a 'by-mode' value of 'R'. (The lack of a return path 711 on the DSN response will mean that neither success or failure 712 notification will be generated: if thbe DSN cannot be returned 713 within the time given, it is silently dropped.) 715 o The sender may assume that the message is lost after 3 times the 716 original DELIVERBY interval has passed without notificaton. 718 NOTE: The above timings are based on a working assumption 719 that normal transit times do not vary by more than a 720 factor of two. There is nothing scientific about this 721 choice of value, but laying down some assumption provides 722 a basis for defining some operational parameters used by 723 cooperating parties, which in turn provides some basis 724 for deterministic behaviour. 726 728 The purpose of this specification is to give the sender control 729 over the recovery strategy to be used if timely delivery does not 730 succeed. It is therefore beyond its scope to set out exactly what 731 recovery action the sender should take. One possible action is to 732 retry the transmission, in which case the following additional 733 considerations apply: 735 o Retries should be used very sparingly, as the likely cause of 736 failure is either a permanent network condition or network 737 congestion. In the case of congestion, retries are likely to 738 make things worse. (The design of the TCP protocol takes account 739 of many lessons about network behaviour that have been learned 740 over the years. A particularly important strategy used is 741 exponential back-off when retransmitting.) 743 o The sender is required to provide envelope ID with message. If 744 it re-tries, it should use same envelope ID and should do so 745 within a reasonable period of determining the original message 746 has not been delivered. 748 o The receiver of a TIMELY message is strongly encouraged to keep 749 note of received envelope ID for some period, for the purpose of 750 weeding out duplicates. 752 4. Timely extension to ESMTP Deliver By extension 754 The purpose of this extension is to allow a message sender to 755 require that timely delivery semantics, described in this memo, be 756 supported all along the path from message sender to recipient, in 757 addition to the existing semantics of DELIVERBY. 759 4.1 Framework for TIMELY extension to DELIVERBY 761 This extends the framework template for DELIVERBY, given in RFC 762 2852 [5]: 764 (1) ESMTP extension name: 765 "Deliver by", extended for "timely completion" 767 (2) EHLO keyword: 768 DELIVERBY, extended as described below 770 (3) EHLO keyword parameters: 771 TIMELY (see 4.2 below) 773 (4) SMTP command parameters: 774 MAIL FROM: TIMELY (see 4.3 below) 775 777 (5) The maximum length of a MAIL FROM command line is increased by 778 a further 17 characters for the TIMELY parameter (this being in 779 addition to the 17 character extension for the basic DELIVERBY 780 extension. 782 (6) Additional SMTP commands: 783 (none) 785 4.2 Extension to EHLO DELIVERBY keyword 787 This specification defines an extension token for timely 788 completion. The extension token syntax (from RFC 2852 [5]) is 789 extended thus: 791 extension-token /= "TIMELY" 793 An ESMTP server that supports this timely completion extension MUST 794 also support the delivery status notification (DSN) ESMTP 795 extension. 797 Support for the timely completion extension indicates support for 798 the MAIL FROM: TIMELY parameter, described below, and for all the 799 associated processing semantics. 801 4.3 MAIL FROM: TIMELY parameter 803 The MAIL FROM command TIMELY parameter MUST be used in conjunction 804 with a BY parameter. Its use imposes requirements on the receiving 805 server's handling of the message that are in addition to those 806 imposed by the BY parameter. 808 TIMELY parameter syntax: 810 timely-parameter = "TIMELY=" interval 811 interval = 1*9DIGIT 813 The 'interval' is specified by the original sender of a message to 814 be the same as the corresponding BY parameter value. 816 A mail relay copies the received TIMELY value to the retransmitted 817 message, unchanged. In this way, the originally specified delivery 818 interval is available to all MTAs that handle the message. 820 The effect of a TIMELY parameter is to require that message 821 processing is performed in accordance with the timely completion 822 mechanisms described in section 3 above. 824 826 5. DSN reporting extensions 828 This specification defines some DSN reporting extensions to allow 829 additional status information to be returned, which a sending 830 system might use in choosing a recovery strategy. 832 5.1 New extended mail system status codes 834 This memo defines the following additional enhanced mail system 835 status codes, extending the range of those defined by RFC 1893 836 [13]: 838 5.4.8???: MTA cannot honour required timely delivery guarantee. 840 5.2.5???: Message delivered but disposition failed. 842 5.2.6???: Message delivered but disposition not completed. 844 4.2.6???: Message delivered pending final disposition. 846 See section 3.4 for more detailed descriptions. 848 5.2 'Retry-count' per-recipient DSN header 850 This memo defines an additional per-recipient DSN report field 851 'Retry-count': 853 retry-count-field = "Retry-Count" ":" 1*3DIGIT 855 This field is used in conjunction with status code 5.4.1 to 856 indicate the number of retries attempted before delivery was 857 abandoned. A value of "0" means that no retries were attempted. 858 The purpose of this is to provide information to the sender that 859 can be used in deciding a recovery strategy. 861 NOTE: It is in the nature of timely completion that 862 retries, if performed, would need to be more closely 863 spaced than is normal for SMTP retries; thus it may be 864 necessary to reduce the number of retries to avoid 865 overloading a relay. Some relays may choose not attempt 866 any retries for messages sent with the TIMELY option. In 867 such circumstances, a sender may wish to retry before 868 attempting transmission by some alternative means. 870 872 6. Implementation notes 874 This section is not a normative part of this specification. 876 The timely completion mechanism is a response to requests for 877 improved performance in certain uses of email. 879 Ultimately, achieving the desired performance levels is dependent 880 on quality of implementation and operational deployment factors. 881 If a system capable of handling 1000 messages-per-hour is subjected 882 to periods of demand for 2000 messages-per-hour throughput, then 883 the performance goals are bound to be substantially under-achieved, 884 whatever the protocol specification may demand. 886 The rest of this section discusses some of the implementation 887 issues and choices raised by this memo, and indicates some ways in 888 which the performance goals can be addressed. 890 6.1 Message state management 892 All requirements for extended-term state rentention are in the 893 sending and receiving MTAs -- at or close to the edge of the 894 network. Ideally, these would be the the only MTAs involved, so 895 provisioning of the service would be entirely under the control of 896 the organizations who use (or sell) it. 898 Where intermediate relays are used, there is no requirement to 899 maintain information about a message after it has been relayed. 900 Thus there are no scalability problems created by a need for state 901 maintenance; performance comes down to message throughput. The 902 requirement for "reasonable effort" rather than "best effort" 903 delivery for TIMELY messages means that some message handling 904 requirements can be relaxed. Rather than copying message data to 905 disk for re-transmission, it can be held in memory -- it might even 906 be streamed through to the next relay; loss of message data is not 907 critical because reporting failure back to the sender is an allowed 908 option. 910 When a TIMELY MTA is subjected to high load factors, it needs a 911 strategy for dealing with this. 913 The design for timely confirmation to the sender depends on 914 reasonably consistent transit times on the forward and return 915 message paths. Delays on the forward path are picked up and 916 responses can be generated. Delays on the return path will result 917 in loss of confirmation; losing failure responses should not be 918 too damaging as the sender will time out and invoke a recovery 919 strategy. Losing success responses is more harmful, as it may 920 cause unnecessary additional network traffic. 922 924 In view of the above, the following message handling strategy is 925 suggested: 927 o Give top priority to forwarding timely status notifications; 928 i.e. messages with a BY parameter and no return path address. 930 o Give next priority to receiving new messages. Under conditions 931 of excessively high load, incoming messages with the TIMELY 932 option should be rejected immediately; e.g. SMTP [2] response 933 [[[421???]]] to any incoming MAIL FROM command with a TIMELY 934 parameter. Non-TIMELY messages can be moved to persistent 935 storage for later attention. 937 o Give next priority to processing accepted messages using the 938 TIMELY option. 940 o Give next priority yto forwarding messages using the DELIVERBY 941 option. 943 o Finally, forward ordinary messages 945 If confirmation for a message sent using the TIMELY option is not 946 received within the expected interval, the sender should be very 947 copnservative about simply retrying. The reason for non-receipt of 948 confirmation is probably: 950 (a) because of mail system congestion, in which case 951 retransmission will just make things worse, or 953 (b) some other network problem, in which case a retry won't help. 955 Since the motivation for this proposal is to provide message 956 delivery while the sender waits, a reasonable approach would be to 957 give the sender an option to retry later, send by regular email or 958 use some other delivery mechanism. 960 6.2 Retransmission timing issues 962 Even allowing for the caution stated above about the problems of 963 simply retransmitting a failed message, it may be that some limited 964 retransmission by the original sender is appropriate as part of a 965 recovery strategy. 967 NOTE: this section draws on some well-known TCP 968 strategies, but the primary intent is different. TCP 969 specifies a retransmission strategy to achieve 970 reliability. This specification aims for deterministic 971 behaviour as far as the sender is concerned, and limits 972 on retransmission to reduce congestion and duplicate 973 delivery. 975 977 In order not to exacerbate congestion of intermediate relays, the 978 following approach is suggested: 980 o A first retry should not be attempted before 4x the original 981 DELIVERBY interval has expired. 983 o Subsequent retry attempts should be attempted at exponentially 984 increasing intervals; e.g. 8x original interval for the 2nd 985 retry, 16x for the 3rd retry, etc. 987 o The requested delivery interval should be increased exponentially 988 for each retry. 990 o The total number of retries attempted should be kept reasonably 991 small; e.g. a maximum of 3-4 retries. If a timely delivery is 992 not achieved within a few attempts, it is probably not achievable 993 at all within a reasonable time. 995 o The receiver of a message should keep a record of the received 996 message identifier for some period of time, at least 8 times the 997 original DELIVERBY interval, for the purpose of weeding out 998 duplicates. It is not possible to state an absolute upper bound 999 on this period, but it should be as long as the receiver can 1000 reasonably manage, but probably no more than a few days. 1002 More specific recommendations for retransmission strategies may 1003 emerge from deployment experience with this protocol. The basic 1004 approach outlined above uses lessons learned from TCP, notably that 1005 exponential back-off is important to avoid exacerbating congestion 1006 conditions that may be the reason for failure in the first place. 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 1029 o When the message is subsequently forwarded, note the time 1030 immediately prior to generating the new MAIL FROM command, and 1031 use the difference from time of receipt to calculate the transit 1032 delay. The calculated transit delay should be rounded up to a 1033 whole number of seconds. 1035 o Generate a new MAIL FROM command with the BY parameter 'by-time' 1036 value decreased by the transit delay value. 1038 Rounding up the transit delay should mean that the BY interval is 1039 always decreased by at least 1 when passing through a relay. This 1040 should mean that if many relays are involved, the overall timing 1041 becomes more conservative. This is consistent with the idea that 1042 responsiveness to the sender is considered more important than 1043 actually achieving delivery. 1045 6.4 Partial success 1047 Messages sent to more than one recipient using the TIMELY option 1048 may succeed or fail independently. 1050 Systems must be designed to handle this possibility. E.g. a 1051 sending agent that gives the user an option to resend, or send by 1052 another route, should be capable of recognizing (and reporting) 1053 that some messages have been transferred successfully, and only 1054 attempt an alternative transfer for those that did not (unless, of 1055 course, the user directs otherwise). 1057 6.5 Routing TIMELY and non-TIMELY messages 1059 The use of MX mail routing means that TIMELY and non-TIMELY 1060 messages to the same domain will be routed via the same servers. 1061 It may be desirable to use separate servers for TIMELY messages. 1062 One way to achieve this operationally would be to use a different 1063 email domain for TIMELY messages, but this may not be ideal from te 1064 users' view of the service. 1066 6.6 Expediting message handling 1068 Invoking the DELIVERBY extension for a given message may be used by 1069 an MTA as a signal to expedite message delivery. But note that 1070 status reports are part of the timely completion cycle, and while 1071 these are sent using the DELIVERBY extension, they do not use the 1072 TIMELY option. Unlike forward-path delays, any delays on the 1073 return path may directly result in the silent loss of a message 1074 status report. 1076 This means that return path messages should be processed at least 1077 as expeditiously as the original message. Hence messages sent 1078 1080 using the TIMELY option should not be given a higher priority than 1081 messages 1083 7. Examples 1085 In the following examples, 'C:' prefixes commands sent from the 1086 SMTP client to the server in a mail transaction, and 'S:' prefixes 1087 responses from the server back to the client. 1089 The notation '\' at the end of a command example indicates that it 1090 continues on the next line. The actual SMTP command must be 1091 presented on a single line. 1093 7.1 Timely delivery and confirmation 1095 This example is of a successful timely delivery and confirmation. 1097 +----------+ +----------+ +----------+ 1098 |Lemas.com |-->--|Benden.net|-->--|Harper.org| 1099 +----------+ +----------+ +----------+ 1101 First hop transfer: 1103 S: 220 Benden.net ESMTP server 1104 C: EHLO Lemas.com 1105 S: 250-Benden.net 1106 S: 250-DELIVERBY 10,TIMELY 1107 S: 250 DSN 1108 C: MAIL FROM: BY=20;R TIMELY=20 \ 1109 ENVID=EE271828 RET=HDRS 1110 S: 250 OK to attempt delivery within 20 seconds 1111 C: RCPT TO: NOTIFY=SUCCESS,FALURE \ 1112 ORCPT=rfc822;Robinton@Harper.org 1113 S: 250 OK 1114 C: DATA 1115 S: 354 Send data 1116 C: (message data goes here) 1117 : 1118 . 1119 S: 250 Message received 1120 1122 At this point, the receiving server Benden.net has accepted 1123 responsibility to deliver the message to its destination or send a 1124 failure report back to the sender. Assuming that the next hop is 1125 initiated after a delay of 4 seconds, it may look like this: 1127 S: 220 Harper.org ESMTP server 1128 C: EHLO Benden.net 1129 S: 250-Harper.org 1130 S: 250-DELIVERBY 10,TIMELY 1131 S: 250 DSN 1132 C: MAIL FROM: BY=16;R TIMELY=20 \ 1133 ENVID=EE271828 RET=HDRS 1134 S: 250 OK 1135 C: RCPT TO: NOTIFY=SUCCESS,FALURE \ 1136 ORCPT=rfc822;Robinton@Harper.org 1137 S: 250 OK 1138 C: DATA 1139 S: 354 Send data 1140 C: (message data goes here) 1141 : 1142 . 1143 S: 250 Message received 1145 At this point, the delivery MTA Harper.org has accepted 1146 responsibility to achieve message disposition and report success or 1147 to report a failure within 16 seconds of receiving the MAIL FROM 1148 command. This will depend on some kind of cooperation with the 1149 receiving user agent. When disposition is completed within the 1150 specified interval, a DSN report is sent in the following fashion: 1152 S: 220 Benden.net ESMTP server 1153 C: EHLO Harper.org 1154 S: 250-Benden.net 1155 S: 250-DELIVERBY 10,TIMELY 1156 S: 250 DSN 1157 C: MAIL FROM:<> BY=40;R 1158 S: 250 OK 1159 C: RCPT TO: NOTIFY=NEVER 1160 S: 250 OK 1161 C: DATA 1162 S: 354 Send data 1163 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 7.2 Timely delivery achieved, no timely disposition 1197 This example follows the same sequence as the previous one, up to 1198 the point that the delivery MTA Harper.org has accepted 1199 responsibility to achieve message disposition or to report a 1200 failure. In this case, having accepted the message for delivery, 1201 disposition cannot be achieved in the desired interval so a failure 1202 DSN must be sent: 1204 S: 220 Benden.net ESMTP server 1205 C: EHLO Harper.org 1206 S: 250-Benden.net 1207 S: 250-DELIVERBY 10,TIMELY 1208 S: 250 DSN 1209 C: MAIL FROM:<> BY=40;R 1210 S: 250 OK 1211 C: RCPT TO: NOTIFY=NEVER 1212 S: 250 OK 1213 C: DATA 1214 S: 354 Send data 1215 1217 C: To: Asgenar@Lemas.com 1218 From: Message-handling@Harper.org 1219 Subject: Disposition failed for Robinton@Harper.org 1220 Content-type: multipart/report; boundary=next; 1221 report-type=delivery-status 1222 MIME-version: 1.0 1224 --next 1225 Content-type: text/plain; charset=US-ASCII 1227 Your message (EE271828) to could not 1228 be processed within the requested time. 1229 --next 1230 Content-type: message/delivery-status 1232 reporting-MTA: dns; mail-receiver.Harper.org 1233 Original-Envelope-ID: EE271828 1235 Original-recipient: rfc822;Robinton@Harper.org 1236 Final-recipient: rfc822;Robinton@Harper.org 1237 Action: failed 1238 Status: 5.2.5??? 1239 --next-- 1240 . 1241 S: 250 Message received 1243 Because this is a specific failure condition being sent to a source 1244 that has used the timely delivery extension, and the message can be 1245 correlated with the original by means of the 'Original-Envelope-ID' 1246 and 'Original-Recipient' values, no part of the original message is 1247 returned with the DSN report. 1249 1251 7.3 Timely delivery achieved, disposition delayed 1253 This example is similar to the previous one, except that 1254 disposition is in progress but its completion is delayed. In this 1255 case, the message cannot be recalled, so a notification report is 1256 sent to the sender indicating, within the requested delivery 1257 period, indicating that the message is delivered and in 1258 disposition. Later, a final delivery status message will be sent. 1260 S: 220 Benden.net ESMTP server 1261 C: EHLO Harper.org 1262 S: 250-Benden.net 1263 S: 250-DELIVERBY 10,TIMELY 1264 S: 250 DSN 1265 C: MAIL FROM:<> BY=40;R 1266 S: 250 OK 1267 C: RCPT TO: NOTIFY=NEVER 1268 S: 250 OK 1269 C: DATA 1270 S: 354 Send data 1271 C: To: Asgenar@Lemas.com 1272 From: Message-handling@Harper.org 1273 Subject: Disposition delayed for Robinton@Harper.org 1274 Content-type: multipart/report; boundary=next; 1275 report-type=delivery-status 1276 MIME-version: 1.0 1278 --next 1279 Content-type: text/plain; charset=US-ASCII 1281 Your message (EE271828) to is being 1282 processed but not completed within the requested time. 1283 --next 1284 Content-type: message/delivery-status 1286 reporting-MTA: dns; mail-receiver.Harper.org 1287 Original-Envelope-ID: EE271828 1289 Original-recipient: rfc822;Robinton@Harper.org 1290 Final-recipient: rfc822;Robinton@Harper.org 1291 Action: delayed 1292 Status: 4.2.6??? 1293 --next-- 1294 . 1295 S: 250 Message received 1296 1298 7.4 Timely delivery could not be achieved 1300 This example is of a failed attempt to achieve timely delivery 1301 because the message could not be forwarded within the requested 1302 interval. 1304 +----------+ +----------+ +----------+ 1305 |Ruatha.com|-->--|Fort.net |-->--|Harper.org| 1306 +----------+ +----------+ +----------+ 1308 First hop transfer: 1310 S: 220 Fort.net ESMTP server 1311 C: EHLO Ruatha.com 1312 S: 250-Fort.net 1313 S: 250-DELIVERBY 15,TIMELY 1314 S: 250 DSN 1315 C: MAIL FROM: BY=20;R TIMELY=20 \ 1316 ENVID=EE271828 RET=HDRS 1317 S: 250 OK to attempt delivery within 20 seconds 1318 C: RCPT TO: NOTIFY=SUCCESS,FALURE \ 1319 ORCPT=rfc822;Sebell@Harper.org 1320 S: 250 OK 1321 C: DATA 1322 S: 354 Send data 1323 C: (message data goes here) 1324 : 1325 . 1326 S: 250 Message received 1328 After a delay of 12 seconds (with 8 seconds of the original 1329 delivery interval remaining), the server Fort.net attempts to relay 1330 the message: 1332 S: 220 Harper.org ESMTP server 1333 C: EHLO Fort.net 1334 S: 250-Harper.org 1335 S: 250-DELIVERBY 10,TIMELY 1336 S: 250 DSN 1337 C: QUIT 1338 S: 221 closing channel 1339 1341 The minimum delivery interval declared by the server Harper.org is 1342 greater than the time remaining to complete delivery, so Fort.net 1343 does not even attempt to send the message. Instead, it returns a 1344 failure report back to Ruatha.com: 1346 S: 220 Ruatha.com ESMTP server 1347 C: EHLO Fort.net 1348 S: 250-Ruatha.com 1349 S: 250-DELIVERBY 10,TIMELY 1350 S: 250 DSN 1351 C: MAIL FROM:<> BY=40;R 1352 S: 250 OK 1353 C: RCPT TO: NOTIFY=NEVER 1354 S: 250 OK 1355 C: DATA 1356 S: 354 Send data 1357 C: To: Jaxom@Ruatha.com 1358 From: Message-handling@Fort.net 1359 Subject: Delivery failed for Sebell@Harper.org 1360 Content-type: multipart/report; boundary=next; 1361 report-type=delivery-status 1362 MIME-version: 1.0 1364 --next 1365 Content-type: text/plain; charset=US-ASCII 1367 Your message (EE271828) to could not be 1368 delivered within the requested time. 1369 --next 1370 Content-type: message/delivery-status 1372 reporting-MTA: dns; mail-relay.Fort.net 1373 Original-Envelope-ID: EE271828 1375 Original-recipient: rfc822;Sebell@Harper.org 1376 Final-recipient: rfc822;Sebell@Harper.org 1377 Action: failed 1378 Status: 5.4.7 1379 Retry-count: 0 1380 --next-- 1381 . 1382 S: 250 Message received 1384 The retry count value is returned to give the sender an indication 1385 about whether it might retry this path before switching to an 1386 alternative delivery strategy. 1388 1390 7.5 Timely delivery feature not supported 1392 This final example shows failure of a timely delivery request 1393 because a receiving MTA does not support the capability: 1395 +----------+ +----------+ +----------+ 1396 |Lemas.com |-->--|Benden.net|-->--|Miners.org| 1397 +----------+ +----------+ +----------+ 1399 First hop transfer: 1401 S: 220 Benden.net ESMTP server 1402 C: EHLO Lemas.com 1403 S: 250-Benden.net 1404 S: 250-DELIVERBY 10,TIMELY 1405 S: 250 DSN 1406 C: MAIL FROM: BY=20;R TIMELY=20 \ 1407 ENVID=EE271828 RET=HDRS 1408 S: 250 OK to attempt delivery within 20 seconds 1409 C: RCPT TO: NOTIFY=SUCCESS,FALURE \ 1410 ORCPT=rfc822;Nicat@Miners.org 1411 S: 250 OK 1412 C: DATA 1413 S: 354 Send data 1414 C: (message data goes here) 1415 : 1416 . 1417 S: 250 Message received 1419 Five seconds later, Benden.net attempts to forward the message: 1421 S: 220 Minbers.org ESMTP server 1422 C: EHLO Benden.net 1423 S: 250-Harper.org 1424 S: 250-DELIVERBY 60 1425 S: 250 DSN 1426 C: QUIT 1427 S: 221 closing channel 1428 1430 The Miners.org server does not support timely delivery, so 1431 Benden.net does not attempt to send the message. Instead, it sends 1432 a failure report back to Lemas.com: 1434 S: 220 Lemas.com ESMTP server 1435 C: EHLO Benden.net 1436 S: 250-Lemas.com 1437 S: 250-DELIVERBY 10,TIMELY 1438 S: 250 DSN 1439 C: MAIL FROM:<> BY=40;R 1440 S: 250 OK 1441 C: RCPT TO: NOTIFY=NEVER 1442 S: 250 OK 1443 C: DATA 1444 S: 354 Send data 1445 C: To: Asgenar@Lemas.com 1446 From: Message-handling@Benden.net 1447 Subject: Delivery failed for Nicat@Miners.org 1448 Content-type: multipart/report; boundary=next; 1449 report-type=delivery-status 1450 MIME-version: 1.0 1452 --next 1453 Content-type: text/plain; charset=US-ASCII 1455 Your message (EE271828) to could not be 1456 delivered within the requested time. 1457 --next 1458 Content-type: message/delivery-status 1460 reporting-MTA: dns; mail-relay.Benden.net 1461 Original-Envelope-ID: EE271828 1463 Original-recipient: rfc822;Nicat@Miners.org 1464 Final-recipient: rfc822;Nicat@Miners.org 1465 Action: failed 1466 Status: 5.4.8??? 1467 --next-- 1468 . 1469 S: 250 Message received 1471 8. IANA Considerations 1473 This specification introduces some new protocol elements for which 1474 IANA registration be required or desirable: 1476 o Extension to DELIVERBY ESMTP extension: see section 4. 1478 o New extended mail system status codes: see section 5.1. 1480 1482 o New DSN report per-recipient field: see section 5.2. 1484 [[[What to do about these?]]] 1486 9. Internationalization considerations 1488 This specification introduces no new internationalization 1489 considerations other than those already present in DSN, which, 1490 through MIME, provides for charset identification and language 1491 tagging of the human readable part of a DSN report. 1493 10. Security considerations 1495 See also RFC 1894 [12], RFC 2852 [5]. 1497 To offer timely handling of messages may require some dedication of 1498 resource. It is conceivable that systems supporting this feature 1499 may be more susceptible to denial of service attacks from a flood 1500 of messages requesting timely completion. (See also section 6.1.) 1502 There is a distant possibility that responses to time-sensitive 1503 requests may disclose information about the loading or topology of 1504 the network accessed. This is unlikely to be any worse than for 1505 web acces protocols (but note that HTTP has been shown to allow 1506 certain kinds of timing attack on private information about a 1507 client's network activities.). 1509 Systems that depend on the physical presence of a user to achieve 1510 timely disposition should not accept a message for such disposition 1511 without the user's explicit permission (c.f. automated generation 1512 of MDN responses in RFC 2998 [14]). 1514 11. Acknowledgements 1516 The authors thank Hiroshi Tamura-san for undertaking the task of 1517 reviewing a very rough, early draft and making several pertinent 1518 observations. The authors also acknowledge helpful comments by Dan 1519 Wing, [[[...]]] 1521 12. References 1523 [1] RFC 2542, "Terminology and Goals for Internet Fax" 1524 L. Masinter, Xerox Corporation 1525 March 1999. 1527 1529 [2] RFC 821, "Simple Mail Transfer Protocol" 1530 Jonathan B. Postel, ISI/USC 1531 August 1982. 1533 [3] RFC 1651, "SMTP Service Extensions" 1534 J. Klensin, MCI 1535 N. Freed, Innosoft 1536 M. Rose, Dover Beach Consulting, Inc. 1537 E. Stefferud, Network Management Associates, Inc. 1538 D. Crocker, Silicon Graphics, Inc. 1539 July 1994. 1541 [4] RFC 1891, "SMTP Service Extension for Delivery Status 1542 Notifications" 1543 K. Moore, University of Tennessee 1544 January 1996. 1546 [5] RFC 2852, "Deliver By SMTP Service Extension" 1547 D. Newman, Sun Microsystems 1548 June 2000 1550 [6] "Content Negotiation for Internet Messaging Services" 1551 G. Klyne, Baltimore Technologies 1552 R.Iwazaki, Toshiba TEC 1553 D. Crocker, Brandenburg Consulting 1554 Internet draft: draft-ietf-fax-content-negotiation-03.txt 1555 Work in progress: January 2001. 1557 [7] RFC 2234, "Augmented BNF for Syntax Specifications: ABNF" 1558 D. Crocker (editor), Internet Mail Consortium 1559 P. Overell, Demon Internet Ltd. 1560 November 1997. 1562 [8] "Procedures for document facsimile transmission in the general 1563 switched telephone network" 1564 ITU-T Recommendation T.30 (1996), including Amendment 1 (1997), 1565 Amendment 2 (1997), Amendment 3 (1998) and Amendment 4 (1999) 1566 International Telecommunications Union. 1568 [9] RFC 1047, "Duplicate messages and SMTP" 1569 C. Partridge 1570 February 1988. 1572 [10] RFC 974, "Mail routing and the domain system" 1573 C. Partridge 1574 January 1986. 1576 1578 [11] RFC 2119, "Key words for use in RFCs to Indicate Requirement 1579 Levels" 1580 S. Bradner, Harvard University 1581 March 1997. 1583 [12] RFC 1894, "An Extensible Format for Delivery Status 1584 Notifications" 1585 K. Moore, University of Tennessee 1586 G. Vaudreuil, Octel Network Services 1587 January 1996. 1589 [13] RFC 1893, "Enhanced Mail System Status Codes" 1590 G. Vaudreuil, Octel Network Services 1591 January 1996. 1593 [14] RFC 2298, "An Extensible Message Format for Message Disposition 1594 Notifications" 1595 R. Fajman, National Institutes of Health 1596 March 1998. 1598 13. Authors' addresses 1600 Graham Klyne (editor) 1601 Baltimore Technologies - Content Security Group, 1602 1220 Parkview, 1603 Arlington Business Park 1604 Theale 1605 Reading, RG7 4SA 1606 United Kingdom. 1607 Telephone: +44 118 930 1300 1608 Facsimile: +44 118 930 1301 1609 E-mail: GK@ACM.ORG 1611 David H. Crocker 1612 Brandenburg Consulting 1613 675 Spruce Drive 1614 Sunnyvale 1615 CA 94086 1616 USA. 1617 Telephone: +1 408 246 8253 1618 Facsimile: +1 408 273 6464 1619 E-mail: dcrocker@brandenburg.com 1620 1622 Appendix A: Amendment history 1624 00a 22-Oct-1999 Memo initially created. 1626 01a 13-Sep-1999 Incorporate review comments. Update references. 1627 Changed title. Incorporate material from IETF 1628 meeting presentations. 1630 02a 25-Jan-2001 Update author details. Simplify COMPLIANCE 1631 extension to a TIMELY extension of DELIVERBY. Add 1632 original interval parameter to TIMELY option. 1633 Strengthen description of mechanism for timely 1634 confirmation. Add template decsription for TIMELY 1635 extension. Refer to the goal of this 1636 specification as "timely completion" rather than 1637 just "timely delivery" (to clearly distinguish 1638 from basic DELIVERBY). Added subsection dealing 1639 with final MTA/MUA interaction. Defined DSN 1640 extension header and status codes for reporting 1641 timely delivery failures. Drafted some 1642 implementation notes. 1644 02b 30-Jan-2001 Add examples. Update some references. Other 1645 editorial drafting. 1647 02c 31-Jan-2001 Fold in review comments. Added implementation 1648 note about using DELIVERBY to expedite message 1649 handling (6.5). 1651 02d 01-Feb-2001 More editorial changes. 1653 02e 01-Feb-2001 Revised text dealing with time-out; move 1654 discussion of retries to implementation notes. 1656 03a 16-Feb-2001 Editorial changes. Added some clarifying text to 1657 introductory section 2.2. 1659 03b 13-Jun-2001 Editorial changes. 1661 TODO: 1663 o Define a mechanism to allow a MAIL FROM with TIMELY option to be 1664 rejected immediately, for congestion control? 1666 o Finalize status codes (look for 'x.x.x???') 1668 REVIEW CHECKLIST: 1670 (Points to be checked or considered more widely on or before final 1671 review.) 1672 1674 o Are there any deployed mechanisms that MTAs may use to recognize 1675 expedited message relay? 1677 o Possible minor revision to DELIVERBY spec? If a DELIVERBY MTA 1678 fails message delivery because the delivery time has expired, AND 1679 the message has an empty SMTP sender address/return path, the 1680 message should be siletly discarded (c.f. RFC 1891, section 6.2; 1681 I think the considerations noted there seem less applicable.). 1682 If this doesn't work, try next... 1684 o Consider addition of new 'by-mode' value for return DSNs; e.g. 1685 'E' for expedite: try to deliver within interval given, or 1686 abandon delivery, but don't notify success or failure. 1687 (Currently specify 'R' without return-path.) A notification 1688 should not be abandoned if a non-DELIVERBY MTA is encountered. 1690 o Try to model system behaviour under high-load/backlog conditions. 1691 Especially w.r.t. section 3.5. 1693 o What lessons to learn from IP QoS efforts? 1695 o Query use of enhanced status codes 4.x.x and 5.x.x; Use by 1696 DELIVERBY seems at odds with RFC 1893. 1698 o Note use of status 5.4.1 not in line with expectations of RFC 1699 1893. 1701 o Use new code instead of 5.3.3? 1703 o Special considerations for fax offramp gateay? How to deal with 1704 uncertain dial-out times. 1706 o Check new status code values (currently n???). Should there be 1707 an IANA registry for Enhanced Mail System Status codes (RFC 1708 1893)? 1710 o Apparently, DSN extension fields must be registered with IANA, 1711 but there appears to be no registry for them. 1713 o Use of alternative port? (e.g. like message submission). 1715 o Allow MTAs to impose size limit on messages for timely delivery? 1717 o Allow for separate delivery and disposition times? (e.g. 10 1718 second transfer + 60 second disposition would leave a sender 1719 waiting for a long time to determine failure.) 1721 o Operational issues surrounding selection of delivery interval? 1722 1724 o DISCUSS: In environments where the timing of final delivery of 1725 the message is outside the control of the final MTA (e.g. the 1726 time required for an outdial, or waiting for a client to collect 1727 the message), an interim DSN report may be generated indicating 1728 that the message has been received pending final delivery. This 1729 report should be clear whether final delivery is dependent on the 1730 receiving user (e.g. mail collection) or some other unknown 1731 infrastructure delay (e.g. fax out-dial or external e-mail 1732 environment). 1734 This is covered somewhat by section 3.3.1: is this adequate? 1736 o MX configuration -- uniform routing for TIMELY/non-TIMELY. Is a 1737 differential routing option required; e.g. SRV records? 1739 o Can use of ORCPT be relaxed? If partial success occurs for 1740 multiple recipients, it is important to be able to tell which 1741 were successful and which were not. 1743 o When a timely-delivery failure message is sent back, it is 1744 addressed to the sender of the original message; thus it becomes 1745 the sender UA responsibility to handle the failure of timely 1746 delivery -- does this cause any problems? 1748 o Check examples. (Should relays declare mail-domain or host name? 1749 Does it matter? Should the From: header for DSNs always be 1750 'postmaster', or is any appropriate mailbox OK?) 1752 Full copyright statement 1754 Copyright (C) The Internet Society 2001. All Rights Reserved. 1756 This document and translations of it may be copied and furnished to 1757 others, and derivative works that comment on or otherwise explain 1758 it or assist in its implementation may be prepared, copied, 1759 published and distributed, in whole or in part, without restriction 1760 of any kind, provided that the above copyright notice and this 1761 paragraph are included on all such copies and derivative works. 1762 However, this document itself may not be modified in any way, such 1763 as by removing the copyright notice or references to the Internet 1764 Society or other Internet organizations, except as needed for the 1765 purpose of developing Internet standards in which case the 1766 procedures for copyrights defined in the Internet Standards process 1767 must be followed, or as required to translate it into languages 1768 other than English. 1770 The limited permissions granted above are perpetual and will not be 1771 revoked by the Internet Society or its successors or assigns. 1773 1775 This document and the information contained herein is provided on 1776 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1777 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1778 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1779 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1780 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.