idnits 2.17.1 draft-ietf-fax-timely-delivery-05.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 39 longer pages, the longest (page 1) being 66 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 (5 November 2001) is 8207 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 1610, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1642, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1660, 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) ** 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) -- No information found for draft-vaudreuil-1983ext - is the name correct? -- Possible downref: Normative reference to a draft: ref. '15' Summary: 12 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF fax WG G. Klyne, MIMEsweeper Group 3 Internet draft D. Crocker, Brandenburg Consulting 4 5 November 2001 5 Expires: May 2002 7 Timely Completion for Internet Messaging Services 8 58 It is essentially a profile of the Delivery Service Notification 59 (DSN) and DELIVERBY extensions for ESMTP, along with a new TIMELY 60 option to DELIVERBY with a new deterministic service quality 61 response. 63 Discussion of this document 65 Please send comments to: . 67 To subscribe: send a message with the body 'subscribe' to 68 . The mailing list archive is at 69 . 71 Table of contents 73 1. Introduction.............................................4 74 1.1 Structure of this document ...........................4 75 1.2 Document conventions .................................5 76 1.3 Terminology ..........................................5 77 2. Background and goals.....................................6 78 2.1 Background ...........................................7 79 2.2 Basis for timely completion ..........................7 80 2.2.1 The SMTP "contract"..............................8 81 2.2.2 Framework for timely delivery....................8 82 2.3 What does the TIMELY option add? .....................9 83 2.3.1 DELIVERBY and timely delivery....................10 84 2.4 Goals for timely completion ..........................10 85 3. Mechanisms for timely completion.........................11 86 3.1 Transmitting a message for timely completion .........11 87 3.2 Relaying a message ...................................12 88 3.3 Delivery MTA message acceptance ......................14 89 3.3.1 Timing of final receipt..........................14 90 3.4 Reporting failures ...................................15 91 3.5 Timely confirmation ..................................16 92 4. Timely extension to ESMTP Deliver By extension...........17 93 4.1 Framework for TIMELY extension to DELIVERBY.............18 94 4.2 Extension to EHLO DELIVERBY keyword.....................18 95 4.3 MAIL FROM: TIMELY parameter.............................18 96 5. DSN reporting extensions.................................19 97 5.1 New extended mail system status codes ................19 98 5.2 'Retry-count' per-recipient DSN header ...............19 99 6. Implementation notes.....................................20 100 6.1 Message state management .............................20 101 6.2 Retransmission timing issues .........................21 102 6.3 Delivery timing granularity ..........................22 103 6.4 Partial success ......................................23 104 6.5 Routing TIMELY and non-TIMELY messages ...............23 105 6.6 Expediting message handling ..........................24 106 Timely Completion for Internet Messaging 5 November 2001 107 109 7. Examples.................................................24 110 7.1 Timely delivery and confirmation .....................24 111 7.2 Received by delivery MTA and timed out ...............26 112 7.3 Timed out with delivery in progress ..................28 113 7.4 Timed out before receipt by delivery MTA .............29 114 7.5 Timely delivery feature not supported ................31 115 8. IANA Considerations......................................33 116 9. Internationalization considerations......................33 117 10. Security considerations.................................33 118 11. Acknowledgements........................................33 119 12. References..............................................34 120 13. Authors' addresses......................................35 121 Appendix A: Amendment history...............................36 122 Full copyright statement....................................39 123 Timely Completion for Internet Messaging 5 November 2001 124 126 1. Introduction 128 Traditional Internet mail uses a _postal_ mail model, with normal 129 delivery placing a message into the recipient's mailbox and the 130 recipient retrieving and processing the message sometime later. 131 For traditional mail, delivery responsibility stops at the mailbox. 132 However some uses of messaging require a service model that 133 confirms receipt by the actual recipient, not just delivery into 134 their mailbox. Also, some uses require delivery within a specified 135 period of time. 137 Timely completion adds this timeliness service feature and extends 138 delivery processing all the way to the recipient. This 139 specification provides a deterministic service quality response, 140 while preserving most of the traditional roles and responsibilities 141 of the agents involved in email transfers. 143 RFC 1891 [4] defines an ESMTP extension for Delivery Service 144 Notification (DSN), and RFC 2852 [5] defines one for requesting 145 delivery of a message within a given interval. Timely Completion 146 is essentially a profile of the DSN and DELIVERBY extensions for 147 ESMTP, along with a new TIMELY option to DELIVERBY with a new 148 deterministic service quality response This memo describes how to 149 use those specifications, along with some small extensions, to 150 achieve timely completion of message delivery. 152 1.1 Structure of this document 154 Section 2 gives the background, principal ideas and goals of this 155 specification. 157 Section 3 describes the mechanisms used, and how they are combined 158 to achieve the timely delivery goals. 160 Section 4 describes an addition to the ESMTP "Deliver by" extension 161 which is one of the mechanisms used to achieve timely delivery. 163 Section 5 describes extensions to the DSN reporting format and 164 status codes used to report conditions related to timely delivery 165 requests. 167 Section 6 contains some non-normative discussion of implementation 168 issues related to this specification. 170 Section 7 contains some examples uses of this specification. 172 Timely Completion for Internet Messaging 5 November 2001 173 175 1.2 Document conventions 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 179 this document are to be interpreted as described in RFC 2119 [11]. 181 NOTE: Comments like this provide additional nonessential 182 information about the rationale behind this document. 183 Such information is not needed for building a conformant 184 implementation, but may help those who wish to understand 185 the design in greater depth. 187 1.3 Terminology 189 Delivery 190 is the process performed by a delivery MTA in attempt to 191 achieve final receipt of a message. 193 Final receipt 194 means a message is accepted by a receiving agent, and is 195 immediately available for disposition (i.e. received by a 196 disposing agent). For example, if mail is received using a 197 protocol like POP or IMAP, final receipt is not deemed to have 198 occurred until the message has been transferred to the 199 recipient's system. The difference between delivery and final 200 receipt is due to the ability have an MTA store a message in a 201 user mailbox, but not be able to notify recipient software of 202 the delivery. Hence there can be arbitrary delay between the 203 time the message is delivered into the mailbox and recipient 204 user's software agent does any processing. 206 Disposition 207 is receipt and processing of a message by a recipient. Timely 208 notification of disposition is problematic to achieve because 209 it is not always possible to determine that disposition has 210 occurred, and in any case may be undesirable for privacy 211 reasons. 213 Best effort 214 indicates that a system will ensure that an assigned task is 215 successfully completed under all but the most catastrophic of 216 failure circumstances. Common failure modes, such as power 217 failures, SHOULD NOT prevent eventual completion of a task. 219 Reasonable effort 220 indicates that while a system will try to complete an assigned 221 task, it MAY also indulge in behaviours, or make operational 222 decisions, that significantly reduce the certainty of an 223 action's being completed in the face of disruptive 224 circumstances. 226 Timely Completion for Internet Messaging 5 November 2001 227 229 Delivery interval 230 a period of time, measured in seconds, allowed for completion 231 of message delivery and/or receipt. 233 Timely delivery 234 means a message is delivered to a recipient's MTA within a 235 specified time interval. 237 Timely delivery 238 means a message is delivered by a recipient's mail transfer 239 agent (MTA) -_ that is, typically, handed to the user's 240 mailbox -- within a specified time interval. 242 Timely receipt 243 means final receipt of a message, by active recipient user 244 software, within a specified time interval. 246 Timely completion 247 means that notification of a requested timely receipt is 248 received by the sender of a message within a determined time 249 interval. Non-receipt of notification within that interval is 250 indicative of failure. 252 MTA, Mail Transfer Agent 253 is an email system component with the roles of receiving, 254 transferring, and delivering messages. 256 MUA, Mail User Agent, disposing agent 257 is an email system component with the role of preparing and 258 sending, and/or receiving and processing, messages. MUAs are 259 the endpoints between which emails are sent; MTAs are relays 260 on the path between a sending MUA and a receiving MUA. 262 Delivery MTA 263 is the final MTA in an MTA relay sequence; it accepts a 264 message and passes it to the receiving MUA. 266 2. Background and goals 268 RFC 2852 [5] provides a mechanism to request timely delivery of a 269 message using SMTP. While this is helpful, it falls short for some 270 usage profiles, such as timely processing of fax messages. These 271 profiles are determined, in part, by the capabilities of 272 traditional facsimile [8]. 274 Timely Completion for Internet Messaging 5 November 2001 275 277 2.1 Background 279 Traditional email [2] is open-loop. The sender of a message 280 normally has no certainty if or when a message is delivered. (A 281 separate memo [6] contains a discussion of some open- and closed- 282 loop issues in email.) 284 To be more than just a hint to the message transfer system, timely 285 completion requires a deterministic confirmation mechanism, to 286 close the loop. This is provided by DSN [4]. 288 Some different levels of timeliness can be identified: 290 (a) timely delivery to the recipient's MTA 292 (b) timely final receipt by the recipient's disposing agent 294 (c) timely disposition (receipt and processing) by the recipient 296 (d) timely notification to the sender of delivery 298 (e) timely notification to the sender of final receipt 300 (f) timely notification to the sender of disposition by the 301 recipient's user agent 303 From the sender's point of view, timely confirmation of disposition 304 is the most desirable requirement. As noted previously this can be 305 problematic, but timely notification of final receipt is 306 practically as useful. 308 2.2 Basis for timely completion 310 A premise of the service specified here is that timeliness CAN be 311 achieved using existing protocols, with appropriate software design 312 and operational management. But the sender and receiver do not 313 control all the relays used: 315 o The real issue is lack of determinism: a message might be 316 delivered quickly, or it might take hours or even days, or it 317 might not be delivered at all; the sender has little knowledge 318 and no control. 320 o A second issue is post-delivery handling: will the recipient's 321 user agent receive the message in timely fashion? 323 Then, assuming that the infrastructure is generally capable of 324 achieving the desired timely completion, the main thrust of this 325 memo is provide protocol enhancements that put the sender in 326 Timely Completion for Internet Messaging 5 November 2001 327 329 complete control on those occasions when timeliness is not 330 achieved. 332 One challenge to achieving this is dealing with uncertain transit 333 times of the confirmation message over the return path (which is 334 not necessarily the same as the forward path). 336 2.2.1 The SMTP "contract" 338 On accepting a message, a normal SMTP message transfer agent (MTA) 339 accepts responsibility to: 341 (a) Use a best effort to ensure ultimate delivery of the message, 342 or 344 (b) Attempt to provide notification that delivery could not be 345 achieved. 347 This memo introduces mechanisms to allow this contract to be 348 modified. A timely-completion MTA accepts responsibility to: 350 (a) Use a reasonable effort to ensure delivery within a specified 351 time, and to provide timely confirmation of this, or 353 (b) Provide timely notification that delivery was not achieved as 354 requested. 356 The sender can then decide a recovery strategy 358 2.2.2 Framework for timely delivery 360 The diagram shows typical SMTP message delivery and delivery status 361 notification (DSN) paths. (The confirmation path is not 362 necessarily the same as the message delivery path.) 364 Outbound message --> 366 +-------+ +-----+ +-----+ +---------+ 367 |Sending|-->--|Relay| >>> |Relay|-->--|Receiving| 368 | MTA | | MTA | | MTA | | MTA | 369 +-------+ +-----+ +-----+ +---------+ 370 | | | 371 ^ | v 372 | | | 373 +-------+ | +---------+ 374 |Sending| | |Receiving| 375 | UA |-<------------- <<< ------------- | UA | 376 +-------+ +---------+ 377 <-- Return confirmation (disposing 378 agent) 379 Timely Completion for Internet Messaging 5 November 2001 380 382 As well as requesting timely delivery of a message, this 383 specification needs to take account of the possibly varying 384 characteristics of relays of the outbound and return message paths. 385 Practically, it is possible to require that every relay on the 386 outbound path recognizes timely completion semantics (using the 387 ESMTP extension framework), but it is not possible to require this 388 of every relay on the return path. Thus, it may be necessary to 389 make some assumptions about the confirmation return path. 391 NOTE: The uncertainty about return path characteristics 392 might be removed by requiring an MTA to send any timely 393 delivery notification to the MTA from which it was 394 received, but this goes against trends in SMTP design and 395 deployment. This might also raise state maintenance and 396 hence scalability concerns. 398 The other issue apparent from the diagram is that providing timely 399 delivery through the SMTP message relays does not ensure that the 400 receiving UA will receive the message in a timely fashion. If the 401 receiving MTA delivers to a POP mailbox, there is currently no way 402 that it can guarantee timely receipt by the disposing agent. 404 2.3 What does the TIMELY option add? 406 The TIMELY option adds three elements to the DELIVERBY extension: 408 o It modifies the SMTP contract, permitting an MTA to commute its 409 responsibility for delivering the message from "best effort" to 410 "reasonable effort", with notification of outcome. 412 o It extends the reach of the timeliness constraint to cover final 413 receipt: i.e. hand-off to a disposing agent (see below). 415 o It establishes a basis for determining the allowable time 416 interval for certain behaviours initiated by the receiver of a 417 message (i.e. DELIVERBY interval for delivery status responses, 418 and how long to wait for possible duplicate message 419 transmissions). 421 This is all consistent with the fundamental strategy of seeking to 422 give the sender control over the whole message transfer process: 423 if an MTA or the receiving agent cannot communicate the required 424 guarantee, delivery is not completed and the sender is duly 425 notified. 427 Timely Completion for Internet Messaging 5 November 2001 428 430 2.3.1 DELIVERBY and timely delivery 432 Timely completion of delivery is handled by the DELIVERBY ESMTP 433 extension base specification [5]. However its scope ends with 434 final delivery by SMTP, not covering final receipt by the disposing 435 agent. The TIMELY option modifies the DELIVERBY semantics to cover 436 the additional step needed for the message to reach the recipient. 438 Consider the following scenario: 440 +------+ +-----+ +---------+ ------- +---------+ 441 |Sender|-->--|Relay|-->--|Receiving|->-(Message)->-|Disposing| 442 | MTA | | MTA | | MTA | ( store ) | agent | 443 +------+ +-----+ +---------+ ------- +---------+ 445 <------SMTP-------> <-------?-------> 447 The base DELIVERBY specification concerns itself with only 448 participants in the SMTP transfers. But for the purposes of timely 449 completion of final receipt, the sender must be able to specify the 450 timeliness constraint to include this extra step. 452 The TIMELY option requires that the receiving MTA communicate with 453 the disposing agent (in some unspecified way), and that it confirm 454 final delivery of the message only if the disposing agent confirms 455 that it will deal with the message in timely fashion, or that it 456 will return an indication to the receiving MTA if it fails to do 457 so. Simply putting the message into a POP mailbox would not meet 458 this criterion. 460 2.4 Goals for timely completion 462 The primary goal is to allow consenting parties to establish a 463 relationship that carries a guarantee of final receipt within a 464 specified time, or timely notification that it was not achieved. 466 Further goals: 468 o Provide "while-you-wait" delivery of messages by email, where 469 available infrastructure and connectivity permit. 471 o Deterministic behaviour, whereby sender who requests timely 472 completion is able to determine with reasonable certainty, and in 473 reasonable time, whether that request was successful. 475 o If the message cannot be delivered as requested, it SHOULD NOT be 476 delivered at all. This means that a sender can choose other 477 strategies for message delivery (e.g. if timely delivery by email 478 does not succeed, to resend the message as a traditional 479 Timely Completion for Internet Messaging 5 November 2001 480 482 facsimile; in such circumstances it is preferable that multiple 483 copies of the message are not delivered). 485 o Operate within the existing ESMTP extension framework [3], using 486 existing facilities where available. 488 3. Mechanisms for timely completion 490 Deterministic timely completion is achieved through a number of 491 ESMTP extensions used in concert: 493 o Delivery Status Notification ("DSN"), per RFC 1891 [4]. 495 o Deliver-by ("DELIVERBY"), per RFC 2852 [5] 497 o A new TIMELY extension to DELIVERBY, that serves to modify the 498 SMTP contract and also to establish that the receiving user agent 499 can process the message in timely fashion as required, or provide 500 timely notification of its failure to do so 502 The confirmation loop for successful delivery looks something like 503 this: 505 +-----------+ +--------+ +--------+ +---------+ 506 |Originating|-->--|Relaying| ... |Relaying|-->--|Receiving| 507 | MTA | | MTA | | MTA | --| MTA | 508 +-----------+ +--------+ +--------+ | +---------+ 509 | | | 510 +-------------+ | +---------+ 511 | Originating |--<-- ... .... ... --<-- |Receiving| 512 | MUA | | MUA | 513 +-------------+ +---------+ 515 The path through MTAs taken by the confirmation response is not 516 defined, and may be different than the forward path of the original 517 message. 519 3.1 Transmitting a message for timely completion 521 A transmitted message for which timely completion is required MUST 522 include the following: 524 o An 'ENVID' parameter on the MAIL FROM command, per DSN [4] 526 o An 'ORCPT' parameter on the corresponding RCPT TO command(s), per 527 DSN [4]. (This is to allow the sender to tell exactly which 528 recipients were successfully delivered.) 529 Timely Completion for Internet Messaging 5 November 2001 530 532 o A 'NOTIFY=SUCCESS,FAILURE' parameter on the corresponding RCPT TO 533 command(s), per DSN [4] 535 o A 'BY' parameter on the MAIL FROM command, per [5], with a 'by- 536 mode' value of 'R'. 538 o A 'TIMELY' parameter on the MAIL FROM command, as described 539 below, initially having the same time interval as specified for 540 'BY'. 542 The message MUST NOT be transmitted to any MTA that does not 543 indicate support for all of these extensions, in its response to 544 the EHLO command. In this case, a negative delivery status report 545 MUST be generated, which SHOULD indicate the non-compliant MTA, the 546 extensions that it does not support, and the name of the reporting 547 MTA (per DSN, using the non-compliance reporting extensions noted 548 later). 550 Standard DNS MX-based message routing, per RFC 974, SHOULD be used 551 when sending or relaying the message. 553 NOTE: Any strategies that vary standard MX routing 554 should be used with care, and only with the goal of 555 improving network transit times and timing consistency. 556 These comments about mail routing apply especially to the 557 handling of DSN responses. 559 Ideally, there will be no intermediate relay between the 560 sending and receiving MTAs, and in any case the number of 561 such relays should be minimized to reduce timing 562 variability on the transfer path. 564 3.2 Relaying a message 566 An MTA that relays a message for timely completion MUST support all 567 of the ESMTP extensions noted above; otherwise it MUST NOT be 568 given the message in the first place. When a relaying MTA accepts 569 a message (by its 2xx status response to receipt of the message 570 data), it becomes responsible for its onward delivery, including 571 satisfying all of the options associated with the message. 573 In order to relay such a message, an MTA MUST note when the message 574 was received, and the time when the attempt to transmit the message 575 to the next MTA is initiated, and reduce accordingly the time 576 interval used for the BY parameter. (The time interval SHOULD be 577 taken to start with receipt of the MAIL FROM command.) 579 If the DELIVERBY time interval is reduced to zero or less (or less 580 than some system-configurable value indicating that delivery within 581 the indicated interval is unlikely to be achieved) then the message 582 Timely Completion for Internet Messaging 5 November 2001 583 585 MUST NOT be relayed. Instead, a negative delivery status report 586 MUST be generated indicating that the time for delivery of the 587 message has expired, and the reporting MTA (per DSN, using the 588 deliver-by extensions and/or non-compliance reporting extensions 589 noted below). 591 The above behaviour is as specified for the DELIVERBY ESMTP 592 extension; see RFC 2852 [5] for a definitive description of how to 593 handle relaying of such messages. The following additional 594 considerations are applicable when the TIMELY option is used: 596 The TIMELY parameter in the MAIL FROM command of a message in 597 transit is copied unchanged when the message is retransmitted. 598 Thus, any originally specified time interval is conveyed to the 599 final MTA, to be used as a basis for selecting a delivery interval 600 for returning a timely notification. 602 Standard DNS MX-based message routing, per RFC 974, SHOULD be used 603 when relaying the message. (See note at end of previous section.) 605 If the first attempt to relay a message fails, the relaying MTA MAY 606 assume that delivery within the desired time will not be achieved, 607 and immediately indicate a delivery failure, indicating the name of 608 the next-hop MTA. Alternatively, the relaying MTA MAY wait and 609 retry the transmission, provided that the retry attempt will be 610 performed within the remaining delivery period; if the 611 transmission cannot be completed after one or more such retries 612 then a negative DSN MUST be generated as noted above. 614 Any negative DSN generated SHOULD indicate the number of retries 615 attempted (where 0 means no retries). 617 The choice to retry or not to retry is installation dependent. 618 Effectively, when a relay does not retry, any responsibility for 619 overcoming the delivery failure is passed back to the original 620 sender. This strategy may be appropriate for cases where very 621 rapid delivery is required or expected. 623 NOTE: The presence of a 'TIMELY' option may cause a 624 relay to abandon a message that it would otherwise retry 625 (even given a 'by-mode' value of 'R'). One purpose of 626 this option is to establish that responsiveness to the 627 sender is more important than getting the message 628 through. An effect of this may be to severely constrain 629 the number and frequency of retry attempts. 631 Timely Completion for Internet Messaging 5 November 2001 632 634 3.3 Delivery MTA message acceptance 636 The MTA that performs final delivery of a message has 637 responsibility for passing the message to a Mail User Agent. The 638 exact mechanism by which this is achieved is a local matter, and is 639 not defined here or by the Internet mail specifications. The 640 delivery MTA, or its agent, is also responsible for generating any 641 successful DSN message. 643 Before generating a success DSN message, the final MTA MUST ensure 644 that all of the conditions for timely completion of the message 645 have been achieved. Specifically, when the TIMELY option is used, 646 it MUST ensure that final delivery to the disposing agent will be 647 completed within the delivery interval indicated as the value of 648 the BY parameter of the received MAIL FROM command. 650 The time interval for completion of final receipt SHOULD be taken 651 to start with receipt of the MAIL FROM command. 653 NOTE: Final receipt by an MUA is expected to include some 654 guarantee of timely processing. Exactly what this 655 constitutes may depend on the circumstances: in a simple 656 case, depositing the message in a local mailbox and 657 immediately notifying the recipient possibly constitutes 658 final receipt. A more complex case would be that of a 659 fax offramp, where final receipt may be completion of a 660 successful outdial and transmission of the fax. 662 3.3.1 Timing of final receipt 664 In the presence of a TIMELY option, final receipt SHOULD NOT be 665 indicated unless the delivery MTA can establish that the receiving 666 MUA will deal with the message promptly. Here "promptly" means a 667 reasonable waiting time for a human; e.g. that the message (or at 668 least the start of the message) will be available to its intended 669 final recipient within a period of, say, 30 seconds. 671 The relationship between the delivery MTA and receiving MUA can 672 work in one of two ways: 674 o The MUA always processes the message promptly, barring 675 exceptional circumstances. Queuing a message to a network 676 printer would constitute such processing -- normally the message 677 will be printed within seconds, even though it might be delayed 678 if the printer runs out of paper. The delivery MTA can generate 679 the final DSN when the MUA has accepted the message. 681 o The MUA attempts to process the message promptly and reports the 682 outcome within the remaining DELIVERBY period. If processing is 683 not performed within the stated period, the message is abandoned 684 Timely Completion for Internet Messaging 5 November 2001 685 687 and failure is signalled back to the delivery MTA. The delivery 688 MTA must hold off generating the final DSN until the MUA has 689 provided a status report; if no such report is provided within 690 the remaining DELIVERBY interval, it SHOULD report failure. 692 3.4 Reporting failures 694 When a relay or receiving MTA determines that a message cannot be 695 delivered as requested to any recipient, a DSN report MUST BE sent 696 back to the sender. 698 The following status codes indicated that message delivery has been 699 abandoned, are used with DSN "Action: failed" for reporting 700 conditions that are specific to timely delivery: 702 4.4.7: Delivery time expired -- failed. 703 Message delivery could not be completed within the specified 704 time interval. This code is also used when the final MTA has 705 accepted the message but has been unable to achieve final 706 receipt within the requested interval. 708 5.4.9: Protocol required for timely delivery not supported. 709 A relay MTA was encountered that did not support the range of 710 capabilities required for timely completion. Defined by [15]. 712 4.4.1: Next MTA not accepting messages. 713 A relay MTA has been unable to contact a next-hop MTA, and has 714 decided to abandon delivery. (See note in section 3.2 about a 715 relay's options with respect to retries.) This code SHOULD be 716 accompanied by a 'Retry-Count' DSN field. 718 4.3.3: Receiving MTA cannot honour required timely receipt. 719 A message has been delivered to a receiving MTA within the 720 required delivery interval, but that MTA is unable to ensure 721 timely receipt or timely notification of failure to do so. 723 The following status code is used with DSN "Action: delayed" for 724 reporting delayed message receipt following delivery: 726 4.4.7: Delivery time expired -- continuing. 727 The message has been received by the delivery MTA and is in 728 the process of final delivery, but that final delivery has not 729 yet been completed. 731 A subsequent DSN SHOULD be sent when the final delivery 732 succeeds or fails. 734 Timely Completion for Internet Messaging 5 November 2001 735 737 This status code is defined for situations where a receiving 738 MTA has handed off the message to another agent for final 739 delivery, and has therefore committed to provide a timely 740 confirmation response, but the delivery agent has not 741 signalled completion. For example, a fax dial-out gateway may 742 have been invoked assuming that the outdial leg would complete 743 within a given period, but has failed to do so. 745 3.5 Timely confirmation 747 Fully deterministic behaviour requires that the round-trip time to 748 deliver a message and receive a confirmation response be within a 749 known time interval. 751 As noted above, it cannot be guaranteed that confirmation of 752 delivery or non-delivery will be transferred in timely fashion, 753 although return path transit times often are comparable with 754 forward path times. Use of the DELIVERBY extension for a message 755 confirmation MAY serve to expedite its forwarding (noting that this 756 is not a required behaviour; see implementation notes section 6.1 757 for further discussion). 759 Further, it is likely that perfect determinism can never be 760 achieved using SMTP; e.g. see RFC 1047 [9]. Repeat deliveries are 761 considered less harmful than lost messages, but even these should 762 be minimized. 764 The following behaviour is followed to achieve near-deterministic 765 timely confirmation: 767 o Always fail forward delivery if a non-TIMELY MTA is encountered. 769 o A return DSN does not itself request delivery notification and 770 has an empty return path (as required for DSN). 772 o Do NOT use the TIMELY option on any DSN return, so that 773 notification delivery does not fail if a non-DELIVERBY or 774 non-TIMELY MTA is encountered on the return path. 776 o Use the DELIVERBY option to request timely delivery for any DSN 777 return, using a delivery interval 2 times the original forward 778 path DELIVERBY time (taken from the received TIMELY parameter), 779 specifying a 'by-mode' value of 'R'. (The lack of a return path 780 on the DSN response will mean that neither success or failure 781 notification will be generated: if the DSN cannot be returned 782 within the time given, it is silently dropped.) 784 o The sender MAY assume that the message is lost after 3 times the 785 original DELIVERBY interval has passed without notification. 787 Timely Completion for Internet Messaging 5 November 2001 788 790 NOTE: The above timings are based on a working assumption 791 that normal transit times do not vary by more than a 792 factor of two. There is nothing scientific about this 793 choice of value, but laying down an assumption provides a 794 basis for defining some operational parameters used by 795 cooperating parties, which in turn provides some basis 796 for deterministic behaviour. 798 The purpose of this specification is to give the sender control 799 over the recovery strategy to be used if timely delivery does not 800 succeed. It is therefore beyond its scope to set out exactly what 801 recovery action the sender should take. One possible action is to 802 retry the transmission, in which case the following additional 803 considerations apply: 805 o Retries should be used very sparingly, as the likely cause of 806 failure is either a permanent network condition or network 807 congestion. In the case of congestion, retries are likely to 808 make things worse. (The design of the TCP protocol takes account 809 of many lessons about network behaviour that have been learned 810 over the years. A particularly important strategy used is 811 exponential back-off when retransmitting.) 813 o The sender is required to provide envelope ID with message. If 814 it re-tries, it MUST use same envelope ID and SHOULD do so within 815 a reasonable period of determining the original message has not 816 been delivered. 818 o The receiver of a TIMELY message SHOULD keep note of the received 819 envelope ID for some period, for the purpose of weeding out 820 duplicates. 822 4. Timely extension to ESMTP Deliver By extension 824 The purpose of this extension is to allow a message sender to 825 require that timely delivery semantics, described in this memo, be 826 supported all along the path from message sender to receiving 827 agent, in addition to the existing semantics of DELIVERBY. 829 Timely Completion for Internet Messaging 5 November 2001 830 832 4.1 Framework for TIMELY extension to DELIVERBY 834 This extends the framework template for DELIVERBY, given in RFC 835 2852 [5]: 837 (1) ESMTP extension name: 838 "Deliver by", extended for "timely completion" 840 (2) EHLO keyword: 841 DELIVERBY, extended as described below 843 (3) EHLO keyword parameters: 844 TIMELY (see 4.2 below) 846 (4) SMTP command parameters: 847 MAIL FROM: TIMELY (see 4.3 below) 849 (5) The maximum length of a MAIL FROM command line is increased by 850 a further 17 characters for the TIMELY parameter (this being in 851 addition to the 17 character extension for the basic DELIVERBY 852 extension. 854 (6) Additional SMTP commands: 855 (none) 857 4.2 Extension to EHLO DELIVERBY keyword 859 This specification defines an extension token for timely 860 completion. The extension token syntax (from RFC 2852 [5]) is 861 extended thus: 863 extension-token /= "TIMELY" 865 An ESMTP server that supports this timely completion extension MUST 866 also support the delivery status notification (DSN) ESMTP 867 extension. 869 Support for the timely completion extension indicates support for 870 the MAIL FROM: TIMELY parameter, described below, and for all the 871 associated processing semantics. 873 4.3 MAIL FROM: TIMELY parameter 875 The MAIL FROM command TIMELY parameter MUST be used in conjunction 876 with a BY parameter. Its use imposes requirements on the receiving 877 server's handling of the message that are in addition to those 878 imposed by the BY parameter. 880 Timely Completion for Internet Messaging 5 November 2001 881 883 TIMELY parameter syntax: 885 timely-parameter = "TIMELY=" interval 886 interval = 1*9DIGIT 888 The 'interval' is specified by the original sender of a message to 889 be the same as the corresponding BY parameter value. 891 A mail relay copies the received TIMELY value to the retransmitted 892 message, unchanged. In this way, the originally specified delivery 893 interval is available to all MTAs that handle the message. The 894 TIMELY value is used when generating a DSN response. 896 The effect of a TIMELY parameter is to require that message 897 processing be performed in accordance with the timely completion 898 mechanisms described in section 3 above. 900 5. DSN reporting extensions 902 This specification defines some DSN reporting extensions to allow 903 additional status information to be returned, which a sending 904 system might use in choosing a recovery strategy. 906 5.1 New extended mail system status codes 908 This specification uses the following additional enhanced mail 909 system status codes, extending the range of those defined by RFC 910 1893 [13]: 912 5.4.9: Protocol required for timely delivery not supported. 913 (Defined by [15].) 915 See section 3.4 for a more detailed description. 917 5.2 'Retry-count' per-recipient DSN header 919 This memo defines an additional per-recipient DSN report field 920 'Retry-count': 922 retry-count-field = "Retry-Count" ":" 1*3DIGIT 924 This field is used in conjunction with status code 4.4.1 to 925 indicate the number of retries attempted before delivery was 926 abandoned. A value of "0" means that no retries were attempted. 927 The purpose of this is to provide information to the sender that 928 can be used in deciding a recovery strategy. 930 Timely Completion for Internet Messaging 5 November 2001 931 933 NOTE: It is in the nature of timely completion that 934 retries, if performed, need to be more closely spaced 935 than is typical for SMTP retries; thus it may be 936 necessary to reduce the number of retries to avoid 937 overloading a relay. Some relays may choose to not 938 attempt any retries for messages with the TIMELY option. 939 In such circumstances, a sender may wish to retry before 940 attempting transmission by alternative means. 942 6. Implementation notes 944 This section is not a normative part of this specification. 946 The timely completion mechanism is a response to requests for 947 improved performance in certain uses of email. 949 Ultimately, achieving the desired performance levels is dependent 950 on quality of implementation and operational deployment factors. 951 If a system capable of handling 1000 messages-per-hour is subjected 952 to periods of demand for 2000 messages-per-hour throughput, then 953 the performance goals are bound to be substantially under-achieved, 954 whatever the protocol specification may demand. 956 The rest of this section discusses some of the implementation 957 issues and choices raised by this memo, and indicates some ways in 958 which the performance goals can be addressed. 960 6.1 Message state management 962 All requirements for extended-term state retention are in the 963 sending and receiving MTAs -- at or close to the edge of the 964 network. Ideally, these would be the only MTAs involved, so 965 provisioning of the service would be entirely under the control of 966 the organizations that use (or sell) it. 968 Where intermediate relays are used, there is no requirement to 969 maintain information about a message after it has been relayed. 970 Thus there are no scalability problems created by a need for state 971 maintenance; performance comes down to message throughput. The 972 requirement for "reasonable effort" rather than "best effort" 973 delivery for TIMELY messages means that some message handling 974 requirements can be relaxed. Rather than copying message data to 975 disk for re-transmission, it can be held in memory -- it might even 976 be streamed through to the next relay; loss of message data is not 977 critical because reporting failure back to the sender is an allowed 978 option. 980 When a TIMELY MTA is subjected to high load factors, it needs a 981 strategy for dealing with this. 983 Timely Completion for Internet Messaging 5 November 2001 984 986 The design for timely confirmation to the sender depends on 987 reasonably consistent transit times on the forward and return 988 message paths. Delays on the forward path are picked up and 989 responses can be generated. Delays on the return path will result 990 in loss of confirmation; losing failure responses should not be 991 too damaging as the sender will time out and invoke a recovery 992 strategy. Losing success responses is more harmful, as it may 993 cause unnecessary additional network traffic. 995 In view of the above, the following message handling strategy is 996 suggested: 998 o Give top priority to forwarding timely status notifications; 999 i.e. messages with a BY parameter and no return path address. 1001 o Give next priority to receiving new messages. 1003 o Give next priority to processing accepted messages using the 1004 TIMELY option. 1006 o Give next priority to forwarding messages using the DELIVERBY 1007 option. 1009 o Finally, forward ordinary messages 1011 If confirmation for a message sent using the TIMELY option is not 1012 received within the expected interval, the sender should be very 1013 conservative about simply retrying. The reason for non-receipt of 1014 confirmation is probably: 1016 (a) Because of mail system congestion, in which case 1017 retransmission will just make things worse, or 1019 (b) Some other network problem, in which case a retry won't help. 1021 Since the motivation for this specification is to provide message 1022 delivery while the sender waits, a reasonable approach would be to 1023 give the sender an option to retry later, send by regular email or 1024 use some other delivery mechanism. 1026 6.2 Retransmission timing issues 1028 Even allowing for the caution stated above about the problems of 1029 simply retransmitting a failed message, it may be that some limited 1030 retransmission by the original sender is appropriate as part of a 1031 recovery strategy. 1033 Timely Completion for Internet Messaging 5 November 2001 1034 1036 NOTE: this section draws on some well-known TCP 1037 strategies, but the primary intent is different. TCP 1038 specifies a retransmission strategy to achieve 1039 reliability. This specification aims for deterministic 1040 behaviour as far as the sender is concerned, and limits 1041 on retransmission to reduce congestion and duplicate 1042 delivery. 1044 In order not to exacerbate congestion of intermediate relays, the 1045 following approach is suggested: 1047 o A first retry should not be attempted before 4x the original 1048 DELIVERBY interval has expired. 1050 o Subsequent retry attempts should be attempted at exponentially 1051 increasing intervals; e.g. 8x original interval for the 2nd 1052 retry, 16x for the 3rd retry, etc. 1054 o The requested delivery interval should be increased exponentially 1055 for each retry. 1057 o The total number of retries attempted should be kept reasonably 1058 small; e.g. a maximum of 3-4 retries. If a timely delivery is 1059 not achieved within a few attempts, it is probably not achievable 1060 at all within a reasonable time. 1062 o The receiver of a message should keep a record of the received 1063 message identifier for some period of time, at least 8 times the 1064 original DELIVERBY interval, for the purpose of weeding out 1065 duplicates. It is not possible to state an absolute upper bound 1066 on this period, but it should be as long as the receiver can 1067 reasonably manage, but probably no more than a few days. 1069 More specific recommendations for retransmission strategies may 1070 emerge from deployment experience with this protocol. The basic 1071 approach outlined above uses lessons learned from TCP, notably that 1072 exponential back-off is important to avoid exacerbating congestion 1073 conditions that may be the reason for failure in the first place. 1075 6.3 Delivery timing granularity 1077 This specification uses seconds for its time interval values. The 1078 best possible timing resolution for each relay is a whole number of 1079 seconds. Careless handling of these time intervals could lead to 1080 timing errors of a second or worse at each relay. 1082 In general, it is expected that delivery time intervals will be of 1083 the order of 10s of seconds, not less than 10 seconds. The effects 1084 of cumulative timing errors should not be significant if the number 1085 Timely Completion for Internet Messaging 5 November 2001 1086 1088 of MTAs involved is kept small (e.g. no more than 2 intermediate 1089 relays). 1091 The following procedure is suggested for dealing with timing 1092 through relay MTAs: 1094 o On receipt of a MAIL FROM command, note the time at which it was 1095 received, preferably with sub-second granularity. 1097 o When the message is subsequently forwarded, note the time 1098 immediately prior to generating the new MAIL FROM command, and 1099 use the difference from time of receipt to calculate the transit 1100 delay. The calculated transit delay should be rounded up to a 1101 whole number of seconds. 1103 o Generate a new MAIL FROM command with the BY parameter 'by-time' 1104 value decreased by the transit delay value. 1106 Rounding up the transit delay should mean that the BY interval is 1107 always decreased by at least 1 when passing through a relay. This 1108 should mean that if many relays are involved, the overall timing 1109 becomes more conservative. This is consistent with the idea that 1110 responsiveness to the sender is considered more important than 1111 actually achieving delivery. 1113 6.4 Partial success 1115 Messages sent to more than one recipient using the TIMELY option 1116 may succeed or fail independently. 1118 Systems must be designed to handle this possibility. E.g. a 1119 sending agent that gives the user an option to resend, or send by 1120 another route, should be capable of recognizing (and reporting) 1121 that some messages have been transferred successfully, and only 1122 attempt an alternative transfer for those that did not (unless, of 1123 course, the user directs otherwise). 1125 6.5 Routing TIMELY and non-TIMELY messages 1127 The use of MX mail routing means that TIMELY and non-TIMELY 1128 messages to the same domain will be routed via the same servers. 1129 It may be desirable to use separate servers for TIMELY messages. 1130 One way to achieve this operationally would be to use a different 1131 email domain for TIMELY messages, but this may not be ideal from 1132 the users' view of the service. 1134 Timely Completion for Internet Messaging 5 November 2001 1135 1137 6.6 Expediting message handling 1139 Invoking the DELIVERBY extension for a given message may be used by 1140 an MTA as a signal to expedite message delivery. But note that 1141 status reports are part of the timely completion cycle, and while 1142 these are sent using the DELIVERBY extension, they do not use the 1143 TIMELY option. Unlike forward-path delays, any delays on the 1144 return path may directly result in the silent loss of a message 1145 status report. 1147 This means that return path messages should be processed at least 1148 as expeditiously as the original message. Hence messages sent 1149 using the TIMELY option should not be given a higher priority than 1150 messages that use just the DELIVERBY option. 1152 7. Examples 1154 In the following examples, 'C:' prefixes commands sent from the 1155 SMTP client to the server in a mail transaction, and 'S:' prefixes 1156 responses from the server back to the client. 1158 The notation '\' at the end of a command example indicates that it 1159 continues on the next line. The actual SMTP command must be 1160 presented on a single line. 1162 7.1 Timely delivery and confirmation 1164 This example is of a successful timely delivery and confirmation. 1166 +----------+ +----------+ +----------+ 1167 |Lemas.com |-->--|Benden.net|-->--|Harper.org| 1168 +----------+ +----------+ +----------+ 1170 First hop transfer: 1172 S: 220 Benden.net ESMTP server 1173 C: EHLO Lemas.com 1174 S: 250-Benden.net 1175 S: 250-DELIVERBY 10,TIMELY 1176 S: 250 DSN 1177 C: MAIL FROM: BY=20;R TIMELY=20 \ 1178 ENVID=EE271828 RET=HDRS 1179 S: 250 OK to attempt delivery within 20 seconds 1180 C: RCPT TO: NOTIFY=SUCCESS,FALURE \ 1181 ORCPT=rfc822;Robinton@Harper.org 1182 S: 250 OK 1183 C: DATA 1184 S: 354 Send data 1185 Timely Completion for Internet Messaging 5 November 2001 1186 1188 C: (message data goes here) 1189 : 1190 . 1191 S: 250 Message received 1193 At this point, the receiving server Benden.net has accepted 1194 responsibility to deliver the message to its destination or send a 1195 failure report back to the sender. Assuming that the next hop is 1196 initiated after a delay of 4 seconds, it may look like this: 1198 S: 220 Harper.org ESMTP server 1199 C: EHLO Benden.net 1200 S: 250-Harper.org 1201 S: 250-DELIVERBY 10,TIMELY 1202 S: 250 DSN 1203 C: MAIL FROM: BY=16;R TIMELY=20 \ 1204 ENVID=EE271828 RET=HDRS 1205 S: 250 OK 1206 C: RCPT TO: NOTIFY=SUCCESS,FALURE \ 1207 ORCPT=rfc822;Robinton@Harper.org 1208 S: 250 OK 1209 C: DATA 1210 S: 354 Send data 1211 C: (message data goes here) 1212 : 1213 . 1214 S: 250 Message received 1216 At this point, the delivery MTA Harper.org has accepted 1217 responsibility to achieve message delivery and report success or to 1218 report a failure within 16 seconds of receiving the MAIL FROM 1219 command. This will depend on some kind of cooperation with the 1220 receiving user agent. When delivery is completed within the 1221 specified interval, a DSN report is sent in the following fashion: 1223 S: 220 Benden.net ESMTP server 1224 C: EHLO Harper.org 1225 S: 250-Benden.net 1226 S: 250-DELIVERBY 10,TIMELY 1227 S: 250 DSN 1228 C: MAIL FROM:<> BY=40;R 1229 S: 250 OK 1230 C: RCPT TO: NOTIFY=NEVER 1231 S: 250 OK 1232 C: DATA 1233 S: 354 Send data 1234 Timely Completion for Internet Messaging 5 November 2001 1235 1237 C: To: Asgenar@Lemas.com 1238 From: Message-handling@Harper.org 1239 Subject: Disposition OK for Robinton@Harper.org 1240 Content-type: multipart/report; boundary=next; 1241 report-type=delivery-status 1242 MIME-version: 1.0 1244 --next 1245 Content-type: text/plain; charset=US-ASCII 1247 Your message (EE271828) to was processed 1248 --next 1249 Content-type: message/delivery-status 1251 reporting-MTA: dns; mail-receiver.Harper.org 1252 Original-Envelope-ID: EE271828 1254 Original-recipient: rfc822;Robinton@Harper.org 1255 Final-recipient: rfc822;Robinton@Harper.org 1256 Action: delivered 1257 Status: 2.0.0 1258 --next-- 1259 . 1260 S: 250 Message received 1262 On receipt of this confirmation message, the sender's user agent 1263 will be able to correlate with the original using the 'Original- 1264 Envelope-ID' and 'Original-recipient' values, and confirm to the 1265 sender that the message has been delivered and processed. 1267 7.2 Received by delivery MTA and timed out 1269 This example follows the same sequence as the previous one, up to 1270 the point that the delivery MTA Harper.org has accepted 1271 responsibility to achieve message delivery or to report a failure. 1272 In this case, having accepted the message, final delivery cannot be 1273 achieved in the desired interval so a failure DSN must be sent: 1275 S: 220 Benden.net ESMTP server 1276 C: EHLO Harper.org 1277 S: 250-Benden.net 1278 S: 250-DELIVERBY 10,TIMELY 1279 S: 250 DSN 1280 C: MAIL FROM:<> BY=40;R 1281 S: 250 OK 1282 C: RCPT TO: NOTIFY=NEVER 1283 S: 250 OK 1284 C: DATA 1285 S: 354 Send data 1286 Timely Completion for Internet Messaging 5 November 2001 1287 1289 C: To: Asgenar@Lemas.com 1290 From: Message-handling@Harper.org 1291 Subject: Disposition failed for Robinton@Harper.org 1292 Content-type: multipart/report; boundary=next; 1293 report-type=delivery-status 1294 MIME-version: 1.0 1296 --next 1297 Content-type: text/plain; charset=US-ASCII 1299 Your message (EE271828) to could not 1300 be processed within the requested time. 1301 --next 1302 Content-type: message/delivery-status 1304 reporting-MTA: dns; mail-receiver.Harper.org 1305 Original-Envelope-ID: EE271828 1307 Original-recipient: rfc822;Robinton@Harper.org 1308 Final-recipient: rfc822;Robinton@Harper.org 1309 Action: failed 1310 Status: 4.4.7 (Timed out during delivery) 1311 --next-- 1312 . 1313 S: 250 Message received 1315 Because this is a specific failure condition being sent to a source 1316 that has used the timely delivery extension, and the message can be 1317 correlated with the original by means of the 'Original-Envelope-ID' 1318 and 'Original-Recipient' values, no part of the original message is 1319 returned with the DSN report. 1321 Timely Completion for Internet Messaging 5 November 2001 1322 1324 7.3 Timed out with delivery in progress 1326 This example is similar to the previous one, except that final 1327 delivery is in progress but its completion is delayed. In this 1328 case, the message cannot be recalled, so a notification report is 1329 sent to the sender, within the requested delivery period, 1330 indicating that the message is delivered and in delivery. Later, a 1331 final delivery status message will be sent. 1333 S: 220 Benden.net ESMTP server 1334 C: EHLO Harper.org 1335 S: 250-Benden.net 1336 S: 250-DELIVERBY 10,TIMELY 1337 S: 250 DSN 1338 C: MAIL FROM:<> BY=40;R 1339 S: 250 OK 1340 C: RCPT TO: NOTIFY=NEVER 1341 S: 250 OK 1342 C: DATA 1343 S: 354 Send data 1344 C: To: Asgenar@Lemas.com 1345 From: Message-handling@Harper.org 1346 Subject: Disposition delayed for Robinton@Harper.org 1347 Content-type: multipart/report; boundary=next; 1348 report-type=delivery-status 1349 MIME-version: 1.0 1351 --next 1352 Content-type: text/plain; charset=US-ASCII 1354 Your message (EE271828) to is being 1355 delivered but not completed within the requested time. 1356 --next 1357 Content-type: message/delivery-status 1359 reporting-MTA: dns; mail-receiver.Harper.org 1360 Original-Envelope-ID: EE271828 1362 Original-recipient: rfc822;Robinton@Harper.org 1363 Final-recipient: rfc822;Robinton@Harper.org 1364 Action: delayed 1365 Status: 4.4.7 (Timed out during delivery) 1366 --next-- 1367 . 1368 S: 250 Message received 1370 The difference between this and the example in section 7.2 is in 1371 the "Action:" field of the delivery status message. 1373 Timely Completion for Internet Messaging 5 November 2001 1374 1376 7.4 Timed out before receipt by delivery MTA 1378 This example is of a failed attempt to achieve timely delivery 1379 because the message could not be forwarded within the requested 1380 interval. 1382 +----------+ +----------+ +----------+ 1383 |Ruatha.com|-->--|Fort.net |-->--|Harper.org| 1384 +----------+ +----------+ +----------+ 1386 First hop transfer: 1388 S: 220 Fort.net ESMTP server 1389 C: EHLO Ruatha.com 1390 S: 250-Fort.net 1391 S: 250-DELIVERBY 15,TIMELY 1392 S: 250 DSN 1393 C: MAIL FROM: BY=20;R TIMELY=20 \ 1394 ENVID=EE271828 RET=HDRS 1395 S: 250 OK to attempt delivery within 20 seconds 1396 C: RCPT TO: NOTIFY=SUCCESS,FALURE \ 1397 ORCPT=rfc822;Sebell@Harper.org 1398 S: 250 OK 1399 C: DATA 1400 S: 354 Send data 1401 C: (message data goes here) 1402 : 1403 . 1404 S: 250 Message received 1406 After a delay of 12 seconds (with 8 seconds of the original 1407 delivery interval remaining), the server Fort.net attempts to relay 1408 the message: 1410 S: 220 Harper.org ESMTP server 1411 C: EHLO Fort.net 1412 S: 250-Harper.org 1413 S: 250-DELIVERBY 10,TIMELY 1414 S: 250 DSN 1415 C: QUIT 1416 S: 221 closing channel 1417 Timely Completion for Internet Messaging 5 November 2001 1418 1420 The minimum delivery interval declared by the server Harper.org is 1421 greater than the time remaining to complete delivery, so Fort.net 1422 does not even attempt to send the message. Instead, it returns a 1423 failure report back to Ruatha.com: 1425 S: 220 Ruatha.com ESMTP server 1426 C: EHLO Fort.net 1427 S: 250-Ruatha.com 1428 S: 250-DELIVERBY 10,TIMELY 1429 S: 250 DSN 1430 C: MAIL FROM:<> BY=40;R 1431 S: 250 OK 1432 C: RCPT TO: NOTIFY=NEVER 1433 S: 250 OK 1434 C: DATA 1435 S: 354 Send data 1436 C: To: Jaxom@Ruatha.com 1437 From: Message-handling@Fort.net 1438 Subject: Delivery failed for Sebell@Harper.org 1439 Content-type: multipart/report; boundary=next; 1440 report-type=delivery-status 1441 MIME-version: 1.0 1443 --next 1444 Content-type: text/plain; charset=US-ASCII 1446 Your message (EE271828) to could not be 1447 delivered within the requested time. 1448 --next 1449 Content-type: message/delivery-status 1451 reporting-MTA: dns; mail-relay.Fort.net 1452 Original-Envelope-ID: EE271828 1454 Original-recipient: rfc822;Sebell@Harper.org 1455 Final-recipient: rfc822;Sebell@Harper.org 1456 Action: failed 1457 Status: 4.4.7 (Timed out during message transfer) 1458 Retry-count: 0 1459 --next-- 1460 . 1461 S: 250 Message received 1463 From the sender's perspective, this is pretty much the same 1464 condition as reported by example 7.2, the difference being that the 1465 time-out has occurred before the message reaches the delivery MTA. 1466 The status code is the same but the reporting MTA is different. 1468 Timely Completion for Internet Messaging 5 November 2001 1469 1471 The retry count value is returned to give the sender an indication 1472 about whether it might retry this path before switching to an 1473 alternative delivery strategy. 1475 7.5 Timely delivery feature not supported 1477 This final example shows failure of a timely delivery request 1478 because a receiving MTA does not support the capability: 1480 +----------+ +----------+ +----------+ 1481 |Lemas.com |-->--|Benden.net|-->--|Miners.org| 1482 +----------+ +----------+ +----------+ 1484 First hop transfer: 1486 S: 220 Benden.net ESMTP server 1487 C: EHLO Lemas.com 1488 S: 250-Benden.net 1489 S: 250-DELIVERBY 10,TIMELY 1490 S: 250 DSN 1491 C: MAIL FROM: BY=20;R TIMELY=20 \ 1492 ENVID=EE271828 RET=HDRS 1493 S: 250 OK to attempt delivery within 20 seconds 1494 C: RCPT TO: NOTIFY=SUCCESS,FALURE \ 1495 ORCPT=rfc822;Nicat@Miners.org 1496 S: 250 OK 1497 C: DATA 1498 S: 354 Send data 1499 C: (message data goes here) 1500 : 1501 . 1502 S: 250 Message received 1504 Five seconds later, Benden.net attempts to forward the message: 1506 S: 220 Miners.org ESMTP server 1507 C: EHLO Benden.net 1508 S: 250-Harper.org 1509 S: 250-DELIVERBY 60 1510 S: 250 DSN 1511 C: QUIT 1512 S: 221 closing channel 1513 Timely Completion for Internet Messaging 5 November 2001 1514 1516 The Miners.org server does not support timely delivery, so 1517 Benden.net does not attempt to send the message. Instead, it sends 1518 a failure report back to Lemas.com: 1520 S: 220 Lemas.com ESMTP server 1521 C: EHLO Benden.net 1522 S: 250-Lemas.com 1523 S: 250-DELIVERBY 10,TIMELY 1524 S: 250 DSN 1525 C: MAIL FROM:<> BY=40;R 1526 S: 250 OK 1527 C: RCPT TO: NOTIFY=NEVER 1528 S: 250 OK 1529 C: DATA 1530 S: 354 Send data 1531 C: To: Asgenar@Lemas.com 1532 From: Message-handling@Benden.net 1533 Subject: Delivery failed for Nicat@Miners.org 1534 Content-type: multipart/report; boundary=next; 1535 report-type=delivery-status 1536 MIME-version: 1.0 1538 --next 1539 Content-type: text/plain; charset=US-ASCII 1541 Your message (EE271828) to could not be 1542 delivered within the requested time. 1543 --next 1544 Content-type: message/delivery-status 1546 reporting-MTA: dns; mail-relay.Benden.net 1547 Original-Envelope-ID: EE271828 1549 Original-recipient: rfc822;Nicat@Miners.org 1550 Final-recipient: rfc822;Nicat@Miners.org 1551 Action: failed 1552 Status: 5.4.9 (Timely delivery not supported by Miners.org) 1553 --next-- 1554 . 1555 S: 250 Message received 1556 Timely Completion for Internet Messaging 5 November 2001 1557 1559 8. IANA Considerations 1561 This specification introduces some new protocol elements for which 1562 IANA registration be required or desirable: 1564 o Extension to DELIVERBY ESMTP extension: see section 4. 1566 o New extended mail system status codes: see section 5.1. 1568 o New DSN report per-recipient field: see section 5.2. 1570 9. Internationalization considerations 1572 This specification introduces no new internationalization 1573 considerations other than those already present in DSN, which, 1574 through MIME, provides for charset identification and language 1575 tagging of the human readable part of a DSN report. 1577 10. Security considerations 1579 See also RFC 1894 [12], RFC 2852 [5]. 1581 To offer timely handling of messages may require some dedication of 1582 resource. It is conceivable that systems supporting this feature 1583 may be more susceptible to denial of service attacks from a flood 1584 of messages requesting timely completion. (See also section 6.1.) 1586 There is a distant possibility that responses to time-sensitive 1587 requests may disclose information about the loading or topology of 1588 the network accessed. This is unlikely to be any worse than for 1589 web access protocols (but note that HTTP has been shown to allow 1590 certain kinds of timing attack on private information about a 1591 client's network activities.). 1593 Systems that depend on the physical presence of a user to achieve 1594 timely receipt SHOULD NOT accept a message for such disposition 1595 without the user's explicit permission (c.f. automated generation 1596 of MDN responses in RFC 2998 [14]). 1598 11. Acknowledgements 1600 The authors thank Hiroshi Tamura-san for undertaking the task of 1601 reviewing a very rough, early draft and making several pertinent 1602 observations. The authors also acknowledge helpful comments by Dan 1603 Wing, Ned Freed and Greg Vaudreuil. 1605 Timely Completion for Internet Messaging 5 November 2001 1606 1608 12. References 1610 [1] RFC 2542, "Terminology and Goals for Internet Fax" 1611 L. Masinter, Xerox Corporation 1612 March 1999. 1614 [2] RFC 821, "Simple Mail Transfer Protocol" 1615 Jonathan B. Postel, ISI/USC 1616 August 1982. 1618 [3] RFC 1651, "SMTP Service Extensions" 1619 J. Klensin, MCI 1620 N. Freed, Innosoft 1621 M. Rose, Dover Beach Consulting, Inc. 1622 E. Stefferud, Network Management Associates, Inc. 1623 D. Crocker, Silicon Graphics, Inc. 1624 July 1994. 1626 [4] RFC 1891, "SMTP Service Extension for Delivery Status 1627 Notifications" 1628 K. Moore, University of Tennessee 1629 January 1996. 1631 [5] RFC 2852, "Deliver By SMTP Service Extension" 1632 D. Newman, Sun Microsystems 1633 June 2000 1635 [6] "Content Negotiation for Internet Messaging Services" 1636 G. Klyne, Baltimore Technologies 1637 R. Iwazaki, Toshiba TEC 1638 D. Crocker, Brandenburg Consulting 1639 Internet draft: draft-ietf-fax-content-negotiation-05.txt 1640 Work in progress: May 2001. 1642 [7] RFC 2234, "Augmented BNF for Syntax Specifications: ABNF" 1643 D. Crocker (editor), Internet Mail Consortium 1644 P. Overell, Demon Internet Ltd. 1645 November 1997. 1647 [8] "Procedures for document facsimile transmission in the general 1648 switched telephone network" 1649 ITU-T Recommendation T.30 (1996), including Amendment 1 (1997), 1650 Amendment 2 (1997), Amendment 3 (1998) and Amendment 4 (1999) 1651 International Telecommunications Union. 1653 [9] RFC 1047, "Duplicate messages and SMTP" 1654 C. Partridge 1655 February 1988. 1657 Timely Completion for Internet Messaging 5 November 2001 1658 1660 [10] RFC 974, "Mail routing and the domain system" 1661 C. Partridge 1662 January 1986. 1664 [11] RFC 2119, "Key words for use in RFCs to Indicate Requirement 1665 Levels" 1666 S. Bradner, Harvard University 1667 March 1997. 1669 [12] RFC 1894, "An Extensible Format for Delivery Status 1670 Notifications" 1671 K. Moore, University of Tennessee 1672 G. Vaudreuil, Octel Network Services 1673 January 1996. 1675 [13] RFC 1893, "Enhanced Mail System Status Codes" 1676 G. Vaudreuil, Octel Network Services 1677 January 1996. 1679 [14] RFC 2298, "An Extensible Message Format for Message Disposition 1680 Notifications" 1681 R. Fajman, National Institutes of Health 1682 March 1998. 1684 [15] G. Vaudreuil, Lucent Technologies, 1685 Extensions to Mail System Status Codes 1686 Internet draft: draft-vaudreuil-1983ext-01.txt 1687 Work-in-progress, November 2001. 1689 13. Authors' addresses 1691 Graham Klyne (editor) 1692 MIMEsweeper Group, 1693 1310 Waterside, 1694 Arlington Business Park 1695 Theale 1696 Reading, RG7 4SA 1697 United Kingdom. 1698 Telephone: +44 118 903 8000 1699 Facsimile: +44 118 903 9000 1700 Email: Graham.Klyne@MIMEsweeper.com 1701 Timely Completion for Internet Messaging 5 November 2001 1702 1704 David H. Crocker 1705 Brandenburg Consulting 1706 675 Spruce Drive 1707 Sunnyvale 1708 CA 94086 1709 USA. 1710 Telephone: +1 408 246 8253 1711 Facsimile: +1 408 273 6464 1712 Email: dcrocker@brandenburg.com 1714 Appendix A: Amendment history 1716 [[[RFC editor: please remove this appendix on publication]]] 1718 00a 22-Oct-1999 Memo initially created. 1720 01a 13-Sep-1999 Incorporate review comments. Update references. 1721 Changed title. Incorporate material from IETF 1722 meeting presentations. 1724 02a 25-Jan-2001 Update author details. Simplify COMPLIANCE 1725 extension to a TIMELY extension of DELIVERBY. Add 1726 original interval parameter to TIMELY option. 1727 Strengthen description of mechanism for timely 1728 confirmation. Add template decsription for TIMELY 1729 extension. Refer to the goal of this 1730 specification as "timely completion" rather than 1731 just "timely delivery" (to clearly distinguish 1732 from basic DELIVERBY). Added subsection dealing 1733 with final MTA/MUA interaction. Defined DSN 1734 extension header and status codes for reporting 1735 timely delivery failures. Drafted some 1736 implementation notes. 1738 02b 30-Jan-2001 Add examples. Update some references. Other 1739 editorial drafting. 1741 02c 31-Jan-2001 Fold in review comments. Added implementation 1742 note about using DELIVERBY to expedite message 1743 handling (6.5). 1745 02d 01-Feb-2001 More editorial changes. 1747 02e 01-Feb-2001 Revised text dealing with time-out; move 1748 discussion of retries to implementation notes. 1750 03a 16-Feb-2001 Editorial changes. Added some clarifying text to 1751 introductory section 2.2. 1753 Timely Completion for Internet Messaging 5 November 2001 1754 1756 03b 13-Jun-2001 Editorial changes. 1758 04a 12-Sep-2001 Rework some descriptions and status codes to be 1759 clear that this document describes an extension of 1760 the mail delivery semantics rather than some 1761 aspect of disposition semantics. As a result, 1762 some status codes have been removed. Removed text 1763 in section 6.1 about immediate rejection of a 1764 message to help avoid exacerbating congestion 1765 conditions. Changed terminology to focus on the 1766 goal of achieving "final receipt" (rather than 1767 "disposition"). Added reference [15]. 1769 04b 13-Sep-2001 Change contact details. Editorial corrections and 1770 refinements. 1772 04c 13-Sep-2001 Changed some section titles; revised examples 1773 commentary and status codes in line with other 1774 changes. 1776 05a 17-Sep-2001 Reworked abstact and introduction to more clearly 1777 place this work in context. Various minor 1778 editorial changes. 1780 06a 05-Nov-2001 Prepare for WG last call. Fixed extended status 1781 code for "protocol not supported". Removed 1782 editorial notes. Fix some spelling errors. 1784 REVIEW CHECKLIST: 1786 (Points to be checked or considered more widely on or before final 1787 review.) 1789 o Are there any deployed mechanisms that MTAs may use to recognize 1790 expedited message relay? 1792 o Possible minor revision to DELIVERBY spec? If a DELIVERBY MTA 1793 fails message delivery because the delivery time has expired, AND 1794 the message has an empty SMTP sender address/return path, the 1795 message should be silently discarded (c.f. RFC 1891, section 6.2; 1796 I think the considerations noted there seem less applicable.). 1797 If this doesn't work, try next... 1799 o Consider addition of new 'by-mode' value for return DSNs; e.g. 1800 'E' for expedite: try to deliver within interval given, or 1801 abandon delivery, but don't notify success or failure. 1802 (Currently specify 'R' without return-path.) A notification 1803 should not be abandoned if a non-DELIVERBY MTA is encountered. 1805 Timely Completion for Internet Messaging 5 November 2001 1806 1808 o Try to model system behaviour under high-load/backlog conditions. 1809 Especially w.r.t. section 3.5. 1811 o What lessons to learn from IP QoS efforts? 1813 o Query use of enhanced status codes 4.x.x and 5.x.x; Use by 1814 DELIVERBY seems at odds with RFC 1893. 1816 o Note use of status 5.4.1 not in line with expectations of RFC 1817 1893. 1819 o Use new code instead of 5.3.3? 1821 o Special considerations for fax offramp gateay? How to deal with 1822 uncertain dial-out times. 1824 o Apparently, DSN extension fields must be registered with IANA, 1825 but there appears to be no registry for them. 1827 o Use of alternative port? (e.g. like message submission). 1829 o Allow MTAs to impose size limit on messages for timely delivery? 1831 o Operational issues surrounding selection of delivery interval? 1833 o DISCUSS: In environments where the timing of final delivery of 1834 the message is outside the control of the final MTA (e.g. the 1835 time required for an outdial, or waiting for a client to collect 1836 the message), an interim DSN report may be generated indicating 1837 that the message has been received pending final delivery. This 1838 report should be clear whether final delivery is dependent on the 1839 receiving user (e.g. mail collection) or some other unknown 1840 infrastructure delay (e.g. fax out-dial or external e-mail 1841 environment). 1843 This is covered somewhat by section 3.3.1: is this adequate? 1845 o MX configuration -- uniform routing for TIMELY/non-TIMELY. Is a 1846 differential routing option required; e.g. SRV records? 1848 o Can use of ORCPT be relaxed? If partial success occurs for 1849 multiple recipients, it is important to be able to tell which 1850 were successful and which were not. 1852 o When a timely-delivery failure message is sent back, it is 1853 addressed to the sender of the original message; thus it becomes 1854 the sender UA responsibility to handle the failure of timely 1855 delivery -- does this cause any problems? 1856 Timely Completion for Internet Messaging 5 November 2001 1857 1859 o Check examples. (Should relays declare mail-domain or host name? 1860 Does it matter? Should the From: header for DSNs always be 1861 'postmaster', or is any appropriate mailbox OK?) 1863 Full copyright statement 1865 Copyright (C) The Internet Society 2001. All Rights Reserved. 1867 This document and translations of it may be copied and furnished to 1868 others, and derivative works that comment on or otherwise explain 1869 it or assist in its implementation may be prepared, copied, 1870 published and distributed, in whole or in part, without restriction 1871 of any kind, provided that the above copyright notice and this 1872 paragraph are included on all such copies and derivative works. 1873 However, this document itself may not be modified in any way, such 1874 as by removing the copyright notice or references to the Internet 1875 Society or other Internet organizations, except as needed for the 1876 purpose of developing Internet standards in which case the 1877 procedures for copyrights defined in the Internet Standards process 1878 must be followed, or as required to translate it into languages 1879 other than English. 1881 The limited permissions granted above are perpetual and will not be 1882 revoked by the Internet Society or its successors or assigns. 1884 This document and the information contained herein is provided on 1885 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1886 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1887 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1888 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1889 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.