idnits 2.17.1 draft-ietf-fax-timely-delivery-04.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 39 longer pages, the longest (page 1) being 60 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 September 2001) is 8260 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 1590, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1622, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1640, 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) -- No information found for draft-vaudreuil-1983ext - is the name correct? -- Possible downref: Normative reference to a draft: ref. '15' Summary: 14 errors (**), 0 flaws (~~), 7 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 13 September 2001 5 Expires: March 2002 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 To view the entire list of current Internet-Drafts, please check 27 the "1id-abstracts.txt" listing contained in the Internet-Drafts 28 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 29 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 30 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US 31 West Coast). 33 Copyright Notice 35 Copyright (C) The Internet Society 2001. All Rights Reserved. 37 Abstract 39 This specification provides a way to request timely completion for 40 Internet mail, for services such as facsimile and voice messaging. 41 It provides a deterministic service quality response, while 42 preserving the traditional roles and responsibiltiies of the agents 43 involved in email transfers. 45 It is essentially a profile of the Delivery Service Notification 46 (DSN) and DELIVERBY extentions for ESMTP, along with a new TIMELY 47 option to DELIVERBY with a new deterministic service quality 48 response. 50 Timely Completion for Internet Messaging 13 September 2001 51 53 Discussion of this document 55 Please send comments to: . 57 To subscribe: send a message with the body 'subscribe' to 58 . The mailing list archive is at 59 . 61 Table of contents 63 1. Introduction.............................................4 64 1.1 Structure of this document ...........................4 65 1.2 Document conventions .................................4 66 1.3 Terminology ..........................................5 67 2. Background and goals.....................................6 68 2.1 Background ...........................................6 69 2.2 Basis for timely completion ..........................7 70 2.2.1 The SMTP "contract"..............................8 71 2.2.2 Framework for timely delivery....................8 72 2.3 What does the TIMELY option add? .....................9 73 2.3.1 DELIVERBY and timely delivery....................10 74 2.4 Goals for timely completion ..........................10 75 3. Mechanisms for timely completion.........................11 76 3.1 Transmitting a message for timely completion .........11 77 3.2 Relaying a message ...................................12 78 3.3 Delivery MTA message acceptance ......................14 79 3.3.1 Timing of final receipt..........................14 80 3.4 Reporting failures ...................................15 81 3.5 Timely confirmation ..................................16 82 4. Timely extension to ESMTP Deliver By extension...........17 83 4.1 Framework for TIMELY extension to DELIVERBY.............18 84 4.2 Extension to EHLO DELIVERBY keyword.....................18 85 4.3 MAIL FROM: TIMELY parameter.............................18 86 5. DSN reporting extensions.................................19 87 5.1 New extended mail system status codes ................19 88 5.2 'Retry-count' per-recipient DSN header ...............19 89 6. Implementation notes.....................................20 90 6.1 Message state management .............................20 91 6.2 Retransmission timing issues .........................21 92 6.3 Delivery timing granularity ..........................22 93 6.4 Partial success ......................................23 94 6.5 Routing TIMELY and non-TIMELY messages ...............23 95 6.6 Expediting message handling ..........................24 96 7. Examples.................................................24 97 7.1 Timely delivery and confirmation .....................24 98 7.2 Received by delivery MTA and timed out ...............26 99 7.3 Timed out with delivery in progress ..................28 100 7.4 Timed out before receipt by delivery MTA .............29 101 7.5 Timely delivery feature not supported ................31 102 Timely Completion for Internet Messaging 13 September 2001 103 105 8. IANA Considerations......................................32 106 9. Internationalization considerations......................33 107 10. Security considerations.................................33 108 11. Acknowledgements........................................33 109 12. References..............................................34 110 13. Authors' addresses......................................35 111 Appendix A: Amendment history...............................36 112 Full copyright statement....................................39 113 Timely Completion for Internet Messaging 13 September 2001 114 116 1. Introduction 118 RFC 1891 [4] defines an ESMTP extension for Delivery Service 119 Notification (DSN), and RFC 2852 [5] defines one for requesting 120 delivery of a message within a given interval. This memo describes 121 how to use those specifications, along with some small extensions, 122 to achieve timely completion of message delivery. 124 1.1 Structure of this document 126 Section 2 gives the background, principal ideas and goals of this 127 specification. 129 Section 3 describes the mechanisms used, and how they are combined 130 to achieve the timely delivery goals. 132 Section 4 describes an addition to the ESMTP "Deliver by" extension 133 which is one of the mechanisms used to achieve timely delivery. 135 Section 5 describes extensions to the DSN reporting format and 136 status codes used to report conditions related to timely delivery 137 requests. 139 Section 6 contains some non-normative discussion of implementation 140 issues related to this specification. 142 Section 7 contains some examples uses of this specification. 144 1.2 Document conventions 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 148 this document are to be interpreted as described in RFC 2119 [11]. 150 NOTE: Comments like this provide additional nonessential 151 information about the rationale behind this document. 152 Such information is not needed for building a conformant 153 implementation, but may help those who wish to understand 154 the design in greater depth. 156 [[[Editorial comments and questions about outstanding issues are 157 provided in triple brackets like this. These working comments 158 should be resolved and removed prior to final publication.]]] 159 Timely Completion for Internet Messaging 13 September 2001 160 162 1.3 Terminology 164 Timely delivery 165 means a message is delivered to a recipient's MTA within a 166 specified time interval. 168 Timely delivery 169 means a message is delivered by a recipient's mail transfer 170 agent (MTA) -_ that is, typically, handed to the user's 171 mailbox -- within a specified time interval. 173 Timely receipt 174 means final receipt of a message, by active recipient user 175 software, within a specified time interval. 177 Timely completion 178 means that notification of a requested timely receipt is 179 received by the sender of a message within a determined time 180 interval. Non-receipt of notification within that interval is 181 indicative of failure. 183 Delivery 184 is the process performed by a delivery MTA in attempt to 185 achieve final receipt of a message. 187 Final receipt 188 means a message is accepted by a receiving agent, and is 189 immediately available for disposition (i.e. received by a 190 disposing agent). For example, if mail is received using a 191 protocol like POP or IMAP, final receipt is not deemed to have 192 occurred until the message has been transferred to the 193 recipient's system. The difference between delivery and final 194 receipt is due to the ability have an MTA store a message in a 195 user mailbox, but not be able to notify recipient software of 196 the delivery. Hence there can be arbitrary delay between the 197 time the message is delivered into the mailbox and recipient 198 user's software agent does any processing. 200 Disposition 201 is receipt and processing of a message by a recipient. Timely 202 notification of disposition is problematic to achieve because 203 it is not always possible to determine that disposition has 204 occurred, and in any case may be undesirable for privacy 205 reasons. 207 Delivery interval 208 a period of time, measured in seconds, allowed for completion 209 of message delivery and/or receipt. 211 Timely Completion for Internet Messaging 13 September 2001 212 214 Best efforts 215 indicates that a system will ensure that an assigned task is 216 successfully completed under all but the most catastrophic of 217 failure circumstances. Common failure modes, such as power 218 failures, SHOULD NOT prevent eventual completion of a task. 220 Reasonable efforts 221 indicates that while a system will try to complete an assigned 222 task, it MAY also indulge in behaviours, or make operational 223 decisions, that significantly reduce the certainty of an 224 action's being completed in the face of disruptive 225 circumstances. 227 MTA, Mail Transfer Agent 228 is an email system component with the roles of receiving, 229 transfering, and delivering messages. 231 MUA, Mail User Agent, disposing agent 232 is an email system component with the role of preparing and 233 sending, and/or receiving and processing, messages. MUAs are 234 the endpoints between which emails are sent; MTAs are relays 235 on the path between a sending MUA and a receiving MUA. 237 Delivery MTA 238 is the final MTA in an MTA relay sequence; it accepts a 239 message and passes it to the receiving MUA. 241 2. Background and goals 243 RFC 2852 [5] provides a mechanism to request timely delivery of a 244 message using SMTP. While this is helpful, it falls short for some 245 usage profiles, such as timely processing of fax messages. These 246 profiles are determined, in part, by the capabilities of 247 traditional facsimile [8]. 249 2.1 Background 251 Traditional email [2] is open-loop. The sender of a message 252 normally has no certainty if or when a message is delivered. (A 253 separate memo [6] contains a discussion of some open- and closed- 254 loop issues in email.) 256 To be more than just a hint to the message transfer system, timely 257 completion requires a deterministic confirmation mechanism, to 258 close the loop. This is provided by DSN [4]. 260 Timely Completion for Internet Messaging 13 September 2001 261 263 Some different levels of timeliness can be identified: 265 (a) timely delivery to the recipient's MTA 267 (b) timely final receipt by the recipient's disposing agent 269 (c) timely disposition (receipt and processing) by the recipient 271 (d) timely notification to the sender of delivery 273 (e) timely notification to the sender of final receipt 275 (f) timely notification to the sender of disposition by the 276 recipient's user agent 278 From the sender's point of view, timely confirmation of disposition 279 is the most desirable requirement. As noted previosuly this can be 280 problematic, but timely notification of final receipt is 281 practically as useful. 283 2.2 Basis for timely completion 285 A premise of the service specified here is that timeliness CAN be 286 achieved using existing protocols, with appropriate software design 287 and operational management. But the sender and receiver do not 288 control all the relays used: 290 o The real issue is lack of determinism: a message might be 291 delivered quickly, or it might take hours or even days, or it 292 might not be delivered at all; the sender has little knowledge 293 and no control. 295 o A second issue is post-delivery handling: will the recipent's 296 user agent receive the message in timely fashion? 298 Then, assuming that the infrastructure is generally capable of 299 achieving the desired timely completion, the main thrust of this 300 memo is provide protocol enhancements that put the sender in 301 complete control on those occasions when timeliness is not 302 achieved. 304 One challenge to achieving this is dealing with uncertain transit 305 times of the confirmation message over the return path (which is 306 not necessarily the same as the forward path). 308 Timely Completion for Internet Messaging 13 September 2001 309 311 2.2.1 The SMTP "contract" 313 On accepting a message, a normal SMTP message transfer agent (MTA) 314 accepts responsibility to: 316 (a) Use best efforts to ensure ultimate delivery of the message, 317 or 319 (b) Attempt to provide notification that delivery could not be 320 achieved. 322 This memo introduces mechanisms to allow this contract to be 323 modified. A timely-completion MTA accepts responsibility to: 325 (a) Use reasonable efforts to ensure delivery within a specified 326 time, and to provide timely confirmation of this, or 328 (b) Provide timely notification that delivery was not achieved as 329 requested. 331 The sender can then decide a recovery strategy 333 2.2.2 Framework for timely delivery 335 The diagram shows typical SMTP message delivery and delivery status 336 notification (DSN) paths. (The confirmation path is not 337 necessarily the same as the message delivery path.) 339 Outbound message --> 341 +-------+ +-----+ +-----+ +---------+ 342 |Sending|-->--|Relay| >>> |Relay|-->--|Receiving| 343 | MTA | | MTA | | MTA | | MTA | 344 +-------+ +-----+ +-----+ +---------+ 345 | | | 346 ^ | v 347 | | | 348 +-------+ | +---------+ 349 |Sending| | |Receiving| 350 | UA |-<------------- <<< ------------- | UA | 351 +-------+ +---------+ 352 <-- Return confirmation (disposing 353 agent) 354 Timely Completion for Internet Messaging 13 September 2001 355 357 As well as requesting timely delivery of a message, this 358 specification needs to take account of the possibly varying 359 characteristics of relays of the outbound and return message paths. 360 Practically, it is possible to require that every relay on the 361 outbound path recognizes timely completion semantics (using the 362 ESMTP extension framework), but it is not possible to require this 363 of every relay on the return path. Thus, it may be necessary to 364 make some assumptions about the confirmation return path. 366 NOTE: The uncertainty about return path characteristics 367 might be removed by requiring an MTA to send any timely 368 delivery notification to the MTA from which it was 369 received, but this goes against trends in SMTP design and 370 deployment. This might also raise state maintenance and 371 hence scalability concerns. 373 The other issue apparent from the diagram is that providing timely 374 delivery through the SMTP message relays does not ensure that the 375 receiving UA will receive the message in a timely fashion. If the 376 receiving MTA delivers to a POP mailbox, there is currently no way 377 that it can guarantee timely receipt by the disposing agent. 379 2.3 What does the TIMELY option add? 381 The TIMELY option adds three elements to the DELIVERBY extension: 383 o It modifies the SMTP contract, permitting an MTA to commute its 384 responsibility for delivering the message from "best effort" to 385 "reasonable effort", with notification of outcome. 387 o It extends the reach of the timeliness constraint to cover final 388 receipt: i.e. handoff to a disposing agent (see below). 390 o It establishes a basis for determining the allowable time 391 interval for certain behaviours initiated by the receiver of a 392 message (i.e. DELIVERBY interval for delivery status responses, 393 and how long to wait for possible duplicate message 394 transmissions). 396 This is all consistent with the fundamental strategy of seeking to 397 give the sender control over the whole message transfer process: 398 if an MTA or the receiving agent cannot communicate the required 399 guarantee, delivery is not completed and the sender is duly 400 notified. 402 Timely Completion for Internet Messaging 13 September 2001 403 405 2.3.1 DELIVERBY and timely delivery 407 Timely completion of delivery is handled by the DELIVERYBY ESMTP 408 extension base specification [5]. However its scope ends with 409 final delivery by SMTP, not covering final receipt by the disposing 410 agent. The TIMELY option modifies the DELIVERBY semantics to cover 411 the additional step needed for the message to reach the recipient. 413 Consider the following scenario: 415 +------+ +-----+ +---------+ ------- +---------+ 416 |Sender|-->--|Relay|-->--|Receiving|->-(Message)->-|Disposing| 417 | MTA | | MTA | | MTA | ( store ) | agent | 418 +------+ +-----+ +---------+ ------- +---------+ 420 <------SMTP-------> <-------?-------> 422 The base DELIVERBY specification concerns itself with only 423 participants in the SMTP transfers. But for the purposes of timely 424 completion of final receipt, the sender must be able to specify the 425 timeliness constraint to include this extra step. 427 The TIMELY option requires that the receiving MTA communicate with 428 the disposing agent (in some unspecified way), and that it confirm 429 final delivery of the message only if the disposing agent confirms 430 that it will deal with the message in timely fashion, or that it 431 will return an indication to the receiving MTA if it fails to do 432 so. Simply putting the message into a POP mailbox would not meet 433 this criterion. 435 2.4 Goals for timely completion 437 The primary goal is to allow consenting parties to establish a 438 relationship that carries a guarantee of final receipt within a 439 specified time, or timely notification that it was not achieved. 441 Further goals: 443 o Provide "while-you-wait" delivery of messages by email, where 444 available infrastructure and connectivity permit. 446 o Deterministic behaviour, whereby sender who requests timely 447 completion is able to determine with reasonable certainty, and in 448 reasonable time, whether that request was successful. 450 o If the message cannot be delivered as requested, it SHOULD NOT be 451 delivered at all. This means that a sender can choose other 452 strategies for message delivery (e.g. if timely delivery by email 453 does not succeed, to resend the message as a traditional 454 Timely Completion for Internet Messaging 13 September 2001 455 457 facsimile; in such circumstances it is preferable that multiple 458 copies of the message are not delivered). 460 o Operate within the existing ESMTP extension framework [3], using 461 existing facilities where available. 463 3. Mechanisms for timely completion 465 Deterministic timely completion is achieved through a number of 466 ESMTP extensions used in concert: 468 o Delivery Status Notification ("DSN"), per RFC 1891 [4]. 470 o Deliver-by ("DELIVERBY"), per RFC 2852 [5] 472 o A new TIMELY extension to DELIVERBY, that serves to modify the 473 SMTP contract and also to establish that the receiving user agent 474 can process the message in timely fashion as required, or provide 475 timely notification of its failure to do so 477 The confirmation loop for successful delivery looks something like 478 this: 480 +-----------+ +--------+ +--------+ +---------+ 481 |Originating|-->--|Relaying| ... |Relaying|-->--|Receiving| 482 | MTA | | MTA | | MTA | --| MTA | 483 +-----------+ +--------+ +--------+ | +---------+ 484 | | | 485 +-------------+ | +---------+ 486 | Originating |--<-- ... .... ... --<-- |Receiving| 487 | MUA | | MUA | 488 +-------------+ +---------+ 490 The path through MTAs taken by the confirmation response is not 491 defined, and may be different than the forward path of the original 492 message. 494 3.1 Transmitting a message for timely completion 496 A transmitted message for which timely completion is required MUST 497 include the following: 499 o An 'ENVID' parameter on the MAIL FROM command, per DSN [4] 501 o An 'ORCPT' parameter on the corresponding RCPT TO command(s), per 502 DSN [4]. (This is to allow the sender to tell exactly which 503 recipients were successfully delivered.) 504 Timely Completion for Internet Messaging 13 September 2001 505 507 o A 'NOTIFY=SUCCESS,FAILURE' parameter on the corresponding RCPT TO 508 command(s), per DSN [4] 510 o A 'BY' parameter on the MAIL FROM command, per [5], with a 'by- 511 mode' value of 'R'. 513 o A 'TIMELY' parameter on the MAIL FROM command, as described 514 below, initially having the same time interval as specified for 515 'BY'. 517 The message MUST NOT be transmitted to any MTA that does not 518 indicate support for all of these extensions, in its response to 519 the EHLO command. In this case, a negative delivery status report 520 MUST be generated, which SHOULD indicate the non-compliant MTA, the 521 extensions that it does not support, and the name of the reporting 522 MTA (per DSN, using the non-compliance reporting extensions noted 523 later). 525 Standard DNS MX-based message routing, per RFC 974, SHOULD be used 526 when sending or relaying the message. 528 NOTE: Any strategies that vary standard MX routing 529 should be used with care, and only with the goal of 530 improving network transit times and timing consistency. 531 These comments about mail routing apply especially to the 532 handling of DSN responses. 534 Ideally, there will be no intermediate relay between the 535 sending and receiving MTAs, and in any case the number of 536 such relays should be minimized to reduce timing 537 variabilities on the transfer path. 539 3.2 Relaying a message 541 An MTA that relays a message for timely completion MUST support all 542 of the ESMTP extensions noted above; otherwise it MUST NOT be 543 given the message in the first place. When a relaying MTA accepts 544 a message (by its 2xx status response to receipt of the message 545 data), it becomes responsible for its onward delivery, including 546 satisfying all of the options associated with the message. 548 In order to relay such a message, an MTA MUST note when the message 549 was received, and the time when the attempt to transmit the message 550 to the next MTA is initiated, and reduce accordingly the time 551 interval used for the BY parameter. (The time interval SHOULD be 552 taken to start with receipt of the MAIL FROM command.) 554 If the DELIVERBY time interval is reduced to less than zero (or 555 less than some system-configurable value indicating that delivery 556 within the indicated interval is unlikely to be achieved) then the 557 Timely Completion for Internet Messaging 13 September 2001 558 560 message MUST NOT be relayed. Instead, a negative delivery status 561 report MUST be generated indicating that the time for delivery of 562 the message has expired, and the reporting MTA (per DSN, using the 563 deliver-by extensions and/or non-compliance reporting extensions 564 noted below). 566 The above behaviour is as specified for the DELIVERBY ESMTP 567 extension; see RFC 2852 [5] for a definitive description of how to 568 handle relaying of such messages. The following additional 569 considerations are applicable when the TIMELY option is used: 571 The TIMELY parameter in the MAIL FROM command of a message in 572 transit is copied unchanged when the message is retransmitted. 573 Thus, any originally specified time interval is conveyed to the 574 final MTA, to be used as a basis for selecting a delivery interval 575 for returning a timely notification. 577 Standard DNS MX-based message routing, per RFC 974, SHOULD be used 578 when relaying the message. (See note at end of previous section.) 580 If the first attempt to relay a message fails, the relaying MTA MAY 581 assume that delivery within the desired time will not be achieved, 582 and immediately indicate a delivery failure, indicating the name of 583 the next-hop MTA. Alternatively, the relaying MTA MAY wait and 584 retry the transmission, provided that the retry attempt will be 585 performed within the remaining delivery period; if the 586 transmission cannot be completed after one or more such retries 587 then a negative DSN MUST be generated as noted above. 589 Any negative DSN generated SHOULD indicate the number of retries 590 attempted (where 0 means no retries). 592 The choice to retry or not to retry is installation dependent. 593 Effectively, when a relay does not retry, any reponsibility for 594 overcoming the delivery failure is passed back to the original 595 sender. This strategy may be appropriate for cases where very 596 rapid delivery is required or expected. 598 NOTE: The presence of a 'TIMELY' option may cause a 599 relay to abandon a message that it would otherwise retry 600 (even given a 'by-mode' value of 'R'). One purpose of 601 this option is to establish that responsiveness to the 602 sender is more important than getting the message 603 through. An effect of this may be to severely constrain 604 the number and frequency of retry attempts. 606 Timely Completion for Internet Messaging 13 September 2001 607 609 3.3 Delivery MTA message acceptance 611 The MTA that accepts final delivery of a message has responsibility 612 for passing the message to a Mail User Agent. The exact mechanism 613 by which this is achieved is a local matter, and not defined here 614 or by the Internet mail specifications. The delivery MTA is also 615 responsible for generating any successful DSN message. 617 Before generating a success DSN message, the final MTA MUST ensure 618 that all of the conditions for timely completion of the message 619 have been achieved. Specifically, when the TIMELY option is used, 620 it MUST ensure that final delivery to the disposing agent will be 621 completed within the delivery interval indicated as the value of 622 the BY parameter of the received MAIL FROM command. 624 The time interval for completion of final receipt SHOULD be taken 625 to start with receipt of the MAIL FROM command. 627 NOTE: Final receipt by an MUA is expected to include some 628 guarantee of timely processing. Exactly what this 629 constitutes may depend on the circumstances: in a simple 630 case, depositing the message in a local mailbox and 631 immediately notifying the recipient possibly constitutes 632 final receipt. A more complex case would be that of a 633 fax offramp, where final receipt may be completion of a 634 successful outdial and transmission of the fax. 636 3.3.1 Timing of final receipt 638 In the presence of a TIMELY option, final receipt SHOULD NOT be 639 indicated unless the delivery MTA can establish that the receiving 640 MUA will deal with the message promptly. Here "promptly" means a 641 reasonable waiting time for a human; e.g. that the message (or at 642 least the start of the message) will be available to its intended 643 final recipient within a period of, say, 30 seconds. 645 The relationship between the delivery MTA and receiving MUA can 646 work in one of two ways: 648 o The MUA always processes the message promptly, barring 649 exceptional circumstances. Queuing a message to a network 650 printer would constitute such processing -- normally the message 651 will be printed within seconds, even though it might be delayed 652 if the printer runs out of paper. The delivery MTA can generate 653 the final DSN when the MUA has accepted the message. 655 o The MUA attempts to process the message promptly and reports the 656 outcome within the remaining DELIVERBY period. If processing is 657 not performed within the stated period, the message is abandoned 658 and failure is signalled back to the delivery MTA. The delivery 659 Timely Completion for Internet Messaging 13 September 2001 660 662 MTA must hold off generating the final DSN until the MUA has 663 provided a status report; if no such report is provided within 664 the remaining DELIVERBY interval, it SHOULD report failure. 666 3.4 Reporting failures 668 When a relay or receiving MTA determines that a message cannot be 669 delivered as requested to any recipient, a DSN report MUST BE sent 670 back to the sender. 672 The following status codes indicated that message delivery has been 673 abandoned, are used with DSN "Action: failed" for reporting 674 conditions that are specific to timely delivery: 676 4.4.7: Delivery time expired -- failed. 677 Message delivery could not be completed within the specified 678 time interval. This code is also used when the final MTA has 679 accepted the message but has been unable to achieve final 680 receipt within the requested interval. 682 5.4.8???: Protocol required not supported. 683 A relay MTA was encountered that did not support the range of 684 capabilities required for timely completion. Defined by [15]. 686 [[[look for code in next status draft - draft-vaudreuil-1983ext- 687 00.txt]]] 689 4.4.1: Next MTA not accepting messages. 690 A relay MTA has been unable to contact a next-hop MTA, and has 691 decided to abandon delivery. (See note in section 3.2 about a 692 relay's options with respect to retries.) This code SHOULD be 693 accompanied by a 'Retry-Count' DSN field. 695 4.3.3: Receiving MTA cannot honour required timely receipt. 696 A message has been delivered to a receiving MTA within the 697 required delivery interval, but that MTA is unable to ensure 698 timely receipt or timely notification of failure to do so. 700 The following status code is used with DSN "Action: delayed" for 701 reporting delayed message receipt following delivery: 703 4.4.7: Delivery time expired -- continuing. 704 The message has been received by the delivery MTA and is in 705 the process of final delivery, but that final delivery has not 706 yet been completed. 708 A subsequent DSN SHOULD be sent when the final delivery 709 succeeds or fails. 711 Timely Completion for Internet Messaging 13 September 2001 712 714 This status code is defined for situations where a receiving 715 MTA has handed off the message to another agent for final 716 delivery, and has therefore committed to provide a timely 717 confirmation response, but the delivery agent has not 718 signalled completion. For example, a fax dial-out gateway may 719 have been invoked assuming that the outdial leg would complete 720 within a given period, but has failed to do so. 722 3.5 Timely confirmation 724 Fully deterministic behaviour requires that the round-trip time to 725 deliver a message and receive a response be within a known time 726 interval. 728 As noted above, it cannot be guaranteed that confirmation of 729 delivery or non-delivery will be transferred in timely fashion, 730 though it seems reasonable to assume that return path transit times 731 will normally be comparable with forward path times. Use of the 732 DELIVERBY extension for a message MAY serve to expedite its 733 forwarding. 735 Further, it is likely that perfect determinism can never be 736 achieved using SMTP; e.g. see RFC 1047 [9]. Repeat deliveries are 737 considered less harmful than lost messages, but even these should 738 be minimized. 740 The following behaviour is followed to achieve near-deterministic 741 timely confirmation: 743 o Always fail forward delivery if a non-TIMELY MTA is encountered. 745 o A return DSN does not itself request delivery notification and 746 has an empty return path (as required for DSN). 748 o Do NOT use the TIMELY option on any DSN return, so that 749 notification delivery does not fail if a non-DELIVERBY or 750 non-TIMELY MTA is encountered on the return path. 752 o Use the DELIVERBY option to request timely delivery for any DSN 753 return, using a delivery interval 2 times the original forward 754 path DELIVERBY time (taken from the received TIMELY parameter), 755 specifying a 'by-mode' value of 'R'. (The lack of a return path 756 on the DSN response will mean that neither success or failure 757 notification will be generated: if the DSN cannot be returned 758 within the time given, it is silently dropped.) 760 o The sender MAY assume that the message is lost after 3 times the 761 original DELIVERBY interval has passed without notification. 763 Timely Completion for Internet Messaging 13 September 2001 764 766 NOTE: The above timings are based on a working assumption 767 that normal transit times do not vary by more than a 768 factor of two. There is nothing scientific about this 769 choice of value, but laying down an assumption provides a 770 basis for defining some operational parameters used by 771 cooperating parties, which in turn provides some basis 772 for deterministic behaviour. 774 The purpose of this specification is to give the sender control 775 over the recovery strategy to be used if timely delivery does not 776 succeed. It is therefore beyond its scope to set out exactly what 777 recovery action the sender should take. One possible action is to 778 retry the transmission, in which case the following additional 779 considerations apply: 781 o Retries should be used very sparingly, as the likely cause of 782 failure is either a permanent network condition or network 783 congestion. In the case of congestion, retries are likely to 784 make things worse. (The design of the TCP protocol takes account 785 of many lessons about network behaviour that have been learned 786 over the years. A particularly important strategy used is 787 exponential back-off when retransmitting.) 789 o The sender is required to provide envelope ID with message. If 790 it re-tries, it MUST use same envelope ID and SHOULD do so within 791 a reasonable period of determining the original message has not 792 been delivered. 794 o The receiver of a TIMELY message SHOULD keep note of the received 795 envelope ID for some period, for the purpose of weeding out 796 duplicates. 798 4. Timely extension to ESMTP Deliver By extension 800 The purpose of this extension is to allow a message sender to 801 require that timely delivery semantics, described in this memo, be 802 supported all along the path from message sender to receiving 803 agent, in addition to the existing semantics of DELIVERBY. 805 Timely Completion for Internet Messaging 13 September 2001 806 808 4.1 Framework for TIMELY extension to DELIVERBY 810 This extends the framework template for DELIVERBY, given in RFC 811 2852 [5]: 813 (1) ESMTP extension name: 814 "Deliver by", extended for "timely completion" 816 (2) EHLO keyword: 817 DELIVERBY, extended as described below 819 (3) EHLO keyword parameters: 820 TIMELY (see 4.2 below) 822 (4) SMTP command parameters: 823 MAIL FROM: TIMELY (see 4.3 below) 825 (5) The maximum length of a MAIL FROM command line is increased by 826 a further 17 characters for the TIMELY parameter (this being in 827 addition to the 17 character extension for the basic DELIVERBY 828 extension. 830 (6) Additional SMTP commands: 831 (none) 833 4.2 Extension to EHLO DELIVERBY keyword 835 This specification defines an extension token for timely 836 completion. The extension token syntax (from RFC 2852 [5]) is 837 extended thus: 839 extension-token /= "TIMELY" 841 An ESMTP server that supports this timely completion extension MUST 842 also support the delivery status notification (DSN) ESMTP 843 extension. 845 Support for the timely completion extension indicates support for 846 the MAIL FROM: TIMELY parameter, described below, and for all the 847 associated processing semantics. 849 4.3 MAIL FROM: TIMELY parameter 851 The MAIL FROM command TIMELY parameter MUST be used in conjunction 852 with a BY parameter. Its use imposes requirements on the receiving 853 server's handling of the message that are in addition to those 854 imposed by the BY parameter. 856 Timely Completion for Internet Messaging 13 September 2001 857 859 TIMELY parameter syntax: 861 timely-parameter = "TIMELY=" interval 862 interval = 1*9DIGIT 864 The 'interval' is specified by the original sender of a message to 865 be the same as the corresponding BY parameter value. 867 A mail relay copies the received TIMELY value to the retransmitted 868 message, unchanged. In this way, the originally specified delivery 869 interval is available to all MTAs that handle the message. The 870 TIMELY value is used when generating a DSN response. 872 The effect of a TIMELY parameter is to require that message 873 processing be performed in accordance with the timely completion 874 mechanisms described in section 3 above. 876 5. DSN reporting extensions 878 This specification defines some DSN reporting extensions to allow 879 additional status information to be returned, which a sending 880 system might use in choosing a recovery strategy. 882 5.1 New extended mail system status codes 884 [[[This section to be removed when status code appears in [15].]]] 886 This memo defines the following additional enhanced mail system 887 status codes, extending the range of those defined by RFC 1893 888 [13]: 890 5.4.8???: Protocol required not supported. (To be defined by [15].) 892 See section 3.4 for more detailed descriptions. 894 5.2 'Retry-count' per-recipient DSN header 896 This memo defines an additional per-recipient DSN report field 897 'Retry-count': 899 retry-count-field = "Retry-Count" ":" 1*3DIGIT 901 This field is used in conjunction with status code 4.4.1 to 902 indicate the number of retries attempted before delivery was 903 abandoned. A value of "0" means that no retries were attempted. 904 The purpose of this is to provide information to the sender that 905 can be used in deciding a recovery strategy. 907 Timely Completion for Internet Messaging 13 September 2001 908 910 NOTE: It is in the nature of timely completion that 911 retries, if performed, need to be more closely spaced 912 than is typical for SMTP retries; thus it may be 913 necessary to reduce the number of retries to avoid 914 overloading a relay. Some relays may choose not attempt 915 any retries for messages sent with the TIMELY option. In 916 such circumstances, a sender may wish to retry before 917 attempting transmission by some alternative means. 919 6. Implementation notes 921 This section is not a normative part of this specification. 923 The timely completion mechanism is a response to requests for 924 improved performance in certain uses of email. 926 Ultimately, achieving the desired performance levels is dependent 927 on quality of implementation and operational deployment factors. 928 If a system capable of handling 1000 messages-per-hour is subjected 929 to periods of demand for 2000 messages-per-hour throughput, then 930 the performance goals are bound to be substantially under-achieved, 931 whatever the protocol specification may demand. 933 The rest of this section discusses some of the implementation 934 issues and choices raised by this memo, and indicates some ways in 935 which the performance goals can be addressed. 937 6.1 Message state management 939 All requirements for extended-term state retention are in the 940 sending and receiving MTAs -- at or close to the edge of the 941 network. Ideally, these would be the only MTAs involved, so 942 provisioning of the service would be entirely under the control of 943 the organizations that use (or sell) it. 945 Where intermediate relays are used, there is no requirement to 946 maintain information about a message after it has been relayed. 947 Thus there are no scalability problems created by a need for state 948 maintenance; performance comes down to message throughput. The 949 requirement for "reasonable effort" rather than "best effort" 950 delivery for TIMELY messages means that some message handling 951 requirements can be relaxed. Rather than copying message data to 952 disk for re-transmission, it can be held in memory -- it might even 953 be streamed through to the next relay; loss of message data is not 954 critical because reporting failure back to the sender is an allowed 955 option. 957 When a TIMELY MTA is subjected to high load factors, it needs a 958 strategy for dealing with this. 960 Timely Completion for Internet Messaging 13 September 2001 961 963 The design for timely confirmation to the sender depends on 964 reasonably consistent transit times on the forward and return 965 message paths. Delays on the forward path are picked up and 966 responses can be generated. Delays on the return path will result 967 in loss of confirmation; losing failure responses should not be 968 too damaging as the sender will time out and invoke a recovery 969 strategy. Losing success responses is more harmful, as it may 970 cause unnecessary additional network traffic. 972 In view of the above, the following message handling strategy is 973 suggested: 975 o Give top priority to forwarding timely status notifications; 976 i.e. messages with a BY parameter and no return path address. 978 o Give next priority to receiving new messages. 980 o Give next priority to processing accepted messages using the 981 TIMELY option. 983 o Give next priority to forwarding messages using the DELIVERBY 984 option. 986 o Finally, forward ordinary messages 988 If confirmation for a message sent using the TIMELY option is not 989 received within the expected interval, the sender should be very 990 conservative about simply retrying. The reason for non-receipt of 991 confirmation is probably: 993 (a) Because of mail system congestion, in which case 994 retransmission will just make things worse, or 996 (b) Some other network problem, in which case a retry won't help. 998 Since the motivation for this specification is to provide message 999 delivery while the sender waits, a reasonable approach would be to 1000 give the sender an option to retry later, send by regular email or 1001 use some other delivery mechanism. 1003 6.2 Retransmission timing issues 1005 Even allowing for the caution stated above about the problems of 1006 simply retransmitting a failed message, it may be that some limited 1007 retransmission by the original sender is appropriate as part of a 1008 recovery strategy. 1010 Timely Completion for Internet Messaging 13 September 2001 1011 1013 NOTE: this section draws on some well-known TCP 1014 strategies, but the primary intent is different. TCP 1015 specifies a retransmission strategy to achieve 1016 reliability. This specification aims for deterministic 1017 behaviour as far as the sender is concerned, and limits 1018 on retransmission to reduce congestion and duplicate 1019 delivery. 1021 In order not to exacerbate congestion of intermediate relays, the 1022 following approach is suggested: 1024 o A first retry should not be attempted before 4x the original 1025 DELIVERBY interval has expired. 1027 o Subsequent retry attempts should be attempted at exponentially 1028 increasing intervals; e.g. 8x original interval for the 2nd 1029 retry, 16x for the 3rd retry, etc. 1031 o The requested delivery interval should be increased exponentially 1032 for each retry. 1034 o The total number of retries attempted should be kept reasonably 1035 small; e.g. a maximum of 3-4 retries. If a timely delivery is 1036 not achieved within a few attempts, it is probably not achievable 1037 at all within a reasonable time. 1039 o The receiver of a message should keep a record of the received 1040 message identifier for some period of time, at least 8 times the 1041 original DELIVERBY interval, for the purpose of weeding out 1042 duplicates. It is not possible to state an absolute upper bound 1043 on this period, but it should be as long as the receiver can 1044 reasonably manage, but probably no more than a few days. 1046 More specific recommendations for retransmission strategies may 1047 emerge from deployment experience with this protocol. The basic 1048 approach outlined above uses lessons learned from TCP, notably that 1049 exponential back-off is important to avoid exacerbating congestion 1050 conditions that may be the reason for failure in the first place. 1052 6.3 Delivery timing granularity 1054 This specification uses seconds for its time interval values. The 1055 best possible timing resolution for each relay is a whole number of 1056 seconds. Careless handling of these time intervals could lead to 1057 timing errors of a second or worse at each relay. 1059 In general, it is expected that delivery time intervals will be of 1060 the order of 10s of seconds, not less than 10 seconds. The effects 1061 of cumulative timing errors should not be significant if the number 1062 Timely Completion for Internet Messaging 13 September 2001 1063 1065 of MTAs involved is kept small (e.g. no more than 2 intermediate 1066 relays). 1068 The following procedure is suggested for dealing with timing 1069 through relay MTAs: 1071 o On receipt of a MAIL FROM command, note the time at which it was 1072 received, preferably with sub-second granularity. 1074 o When the message is subsequently forwarded, note the time 1075 immediately prior to generating the new MAIL FROM command, and 1076 use the difference from time of receipt to calculate the transit 1077 delay. The calculated transit delay should be rounded up to a 1078 whole number of seconds. 1080 o Generate a new MAIL FROM command with the BY parameter 'by-time' 1081 value decreased by the transit delay value. 1083 Rounding up the transit delay should mean that the BY interval is 1084 always decreased by at least 1 when passing through a relay. This 1085 should mean that if many relays are involved, the overall timing 1086 becomes more conservative. This is consistent with the idea that 1087 responsiveness to the sender is considered more important than 1088 actually achieving delivery. 1090 6.4 Partial success 1092 Messages sent to more than one recipient using the TIMELY option 1093 may succeed or fail independently. 1095 Systems must be designed to handle this possibility. E.g. a 1096 sending agent that gives the user an option to resend, or send by 1097 another route, should be capable of recognizing (and reporting) 1098 that some messages have been transferred successfully, and only 1099 attempt an alternative transfer for those that did not (unless, of 1100 course, the user directs otherwise). 1102 6.5 Routing TIMELY and non-TIMELY messages 1104 The use of MX mail routing means that TIMELY and non-TIMELY 1105 messages to the same domain will be routed via the same servers. 1106 It may be desirable to use separate servers for TIMELY messages. 1107 One way to achieve this operationally would be to use a different 1108 email domain for TIMELY messages, but this may not be ideal from 1109 the users' view of the service. 1111 Timely Completion for Internet Messaging 13 September 2001 1112 1114 6.6 Expediting message handling 1116 Invoking the DELIVERBY extension for a given message may be used by 1117 an MTA as a signal to expedite message delivery. But note that 1118 status reports are part of the timely completion cycle, and while 1119 these are sent using the DELIVERBY extension, they do not use the 1120 TIMELY option. Unlike forward-path delays, any delays on the 1121 return path may directly result in the silent loss of a message 1122 status report. 1124 This means that return path messages should be processed at least 1125 as expeditiously as the original message. Hence messages sent 1126 using the TIMELY option should not be given a higher priority than 1127 messages that use just the DELIVERBY option. 1129 7. Examples 1131 In the following examples, 'C:' prefixes commands sent from the 1132 SMTP client to the server in a mail transaction, and 'S:' prefixes 1133 responses from the server back to the client. 1135 The notation '\' at the end of a command example indicates that it 1136 continues on the next line. The actual SMTP command must be 1137 presented on a single line. 1139 7.1 Timely delivery and confirmation 1141 This example is of a successful timely delivery and confirmation. 1143 +----------+ +----------+ +----------+ 1144 |Lemas.com |-->--|Benden.net|-->--|Harper.org| 1145 +----------+ +----------+ +----------+ 1147 First hop transfer: 1149 S: 220 Benden.net ESMTP server 1150 C: EHLO Lemas.com 1151 S: 250-Benden.net 1152 S: 250-DELIVERBY 10,TIMELY 1153 S: 250 DSN 1154 C: MAIL FROM: BY=20;R TIMELY=20 \ 1155 ENVID=EE271828 RET=HDRS 1156 S: 250 OK to attempt delivery within 20 seconds 1157 C: RCPT TO: NOTIFY=SUCCESS,FALURE \ 1158 ORCPT=rfc822;Robinton@Harper.org 1159 S: 250 OK 1160 C: DATA 1161 S: 354 Send data 1162 Timely Completion for Internet Messaging 13 September 2001 1163 1165 C: (message data goes here) 1166 : 1167 . 1168 S: 250 Message received 1170 At this point, the receiving server Benden.net has accepted 1171 responsibility to deliver the message to its destination or send a 1172 failure report back to the sender. Assuming that the next hop is 1173 initiated after a delay of 4 seconds, it may look like this: 1175 S: 220 Harper.org ESMTP server 1176 C: EHLO Benden.net 1177 S: 250-Harper.org 1178 S: 250-DELIVERBY 10,TIMELY 1179 S: 250 DSN 1180 C: MAIL FROM: BY=16;R TIMELY=20 \ 1181 ENVID=EE271828 RET=HDRS 1182 S: 250 OK 1183 C: RCPT TO: NOTIFY=SUCCESS,FALURE \ 1184 ORCPT=rfc822;Robinton@Harper.org 1185 S: 250 OK 1186 C: DATA 1187 S: 354 Send data 1188 C: (message data goes here) 1189 : 1190 . 1191 S: 250 Message received 1193 At this point, the delivery MTA Harper.org has accepted 1194 responsibility to achieve message delivery and report success or to 1195 report a failure within 16 seconds of receiving the MAIL FROM 1196 command. This will depend on some kind of cooperation with the 1197 receiving user agent. When delivery is completed within the 1198 specified interval, a DSN report is sent in the following fashion: 1200 S: 220 Benden.net ESMTP server 1201 C: EHLO Harper.org 1202 S: 250-Benden.net 1203 S: 250-DELIVERBY 10,TIMELY 1204 S: 250 DSN 1205 C: MAIL FROM:<> BY=40;R 1206 S: 250 OK 1207 C: RCPT TO: NOTIFY=NEVER 1208 S: 250 OK 1209 C: DATA 1210 S: 354 Send data 1211 Timely Completion for Internet Messaging 13 September 2001 1212 1214 C: To: Asgenar@Lemas.com 1215 From: Message-handling@Harper.org 1216 Subject: Disposition OK for Robinton@Harper.org 1217 Content-type: multipart/report; boundary=next; 1218 report-type=delivery-status 1219 MIME-version: 1.0 1221 --next 1222 Content-type: text/plain; charset=US-ASCII 1224 Your message (EE271828) to was processed 1225 --next 1226 Content-type: message/delivery-status 1228 reporting-MTA: dns; mail-receiver.Harper.org 1229 Original-Envelope-ID: EE271828 1231 Original-recipient: rfc822;Robinton@Harper.org 1232 Final-recipient: rfc822;Robinton@Harper.org 1233 Action: delivered 1234 Status: 2.0.0 1235 --next-- 1236 . 1237 S: 250 Message received 1239 On receipt of this confirmation message, the sender's user agent 1240 will be able to correlate with the original using the 'Original- 1241 Envelope-ID' and 'Original-recipient' values, and confirm to the 1242 sender that the message has been delivered and processed. 1244 7.2 Received by delivery MTA and timed out 1246 This example follows the same sequence as the previous one, up to 1247 the point that the delivery MTA Harper.org has accepted 1248 responsibility to achieve message delivery or to report a failure. 1249 In this case, having accepted the message, final delivery cannot be 1250 achieved in the desired interval so a failure DSN must be sent: 1252 S: 220 Benden.net ESMTP server 1253 C: EHLO Harper.org 1254 S: 250-Benden.net 1255 S: 250-DELIVERBY 10,TIMELY 1256 S: 250 DSN 1257 C: MAIL FROM:<> BY=40;R 1258 S: 250 OK 1259 C: RCPT TO: NOTIFY=NEVER 1260 S: 250 OK 1261 C: DATA 1262 S: 354 Send data 1263 Timely Completion for Internet Messaging 13 September 2001 1264 1266 C: To: Asgenar@Lemas.com 1267 From: Message-handling@Harper.org 1268 Subject: Disposition failed for Robinton@Harper.org 1269 Content-type: multipart/report; boundary=next; 1270 report-type=delivery-status 1271 MIME-version: 1.0 1273 --next 1274 Content-type: text/plain; charset=US-ASCII 1276 Your message (EE271828) to could not 1277 be processed within the requested time. 1278 --next 1279 Content-type: message/delivery-status 1281 reporting-MTA: dns; mail-receiver.Harper.org 1282 Original-Envelope-ID: EE271828 1284 Original-recipient: rfc822;Robinton@Harper.org 1285 Final-recipient: rfc822;Robinton@Harper.org 1286 Action: failed 1287 Status: 4.4.7 (Timed out during delivery) 1288 --next-- 1289 . 1290 S: 250 Message received 1292 Because this is a specific failure condition being sent to a source 1293 that has used the timely delivery extension, and the message can be 1294 correlated with the original by means of the 'Original-Envelope-ID' 1295 and 'Original-Recipient' values, no part of the original message is 1296 returned with the DSN report. 1298 Timely Completion for Internet Messaging 13 September 2001 1299 1301 7.3 Timed out with delivery in progress 1303 This example is similar to the previous one, except that final 1304 delivery is in progress but its completion is delayed. In this 1305 case, the message cannot be recalled, so a notification report is 1306 sent to the sender, within the requested delivery period, 1307 indicating that the message is delivered and in delivery. Later, a 1308 final delivery status message will be sent. 1310 S: 220 Benden.net ESMTP server 1311 C: EHLO Harper.org 1312 S: 250-Benden.net 1313 S: 250-DELIVERBY 10,TIMELY 1314 S: 250 DSN 1315 C: MAIL FROM:<> BY=40;R 1316 S: 250 OK 1317 C: RCPT TO: NOTIFY=NEVER 1318 S: 250 OK 1319 C: DATA 1320 S: 354 Send data 1321 C: To: Asgenar@Lemas.com 1322 From: Message-handling@Harper.org 1323 Subject: Disposition delayed for Robinton@Harper.org 1324 Content-type: multipart/report; boundary=next; 1325 report-type=delivery-status 1326 MIME-version: 1.0 1328 --next 1329 Content-type: text/plain; charset=US-ASCII 1331 Your message (EE271828) to is being 1332 delivered but not completed within the requested time. 1333 --next 1334 Content-type: message/delivery-status 1336 reporting-MTA: dns; mail-receiver.Harper.org 1337 Original-Envelope-ID: EE271828 1339 Original-recipient: rfc822;Robinton@Harper.org 1340 Final-recipient: rfc822;Robinton@Harper.org 1341 Action: delayed 1342 Status: 4.4.7 (Timed out during delivery) 1343 --next-- 1344 . 1345 S: 250 Message received 1347 The difference between this and the example in section 7.2 is in 1348 the "Action:" field of the delivery status message. 1350 Timely Completion for Internet Messaging 13 September 2001 1351 1353 7.4 Timed out before receipt by delivery MTA 1355 This example is of a failed attempt to achieve timely delivery 1356 because the message could not be forwarded within the requested 1357 interval. 1359 +----------+ +----------+ +----------+ 1360 |Ruatha.com|-->--|Fort.net |-->--|Harper.org| 1361 +----------+ +----------+ +----------+ 1363 First hop transfer: 1365 S: 220 Fort.net ESMTP server 1366 C: EHLO Ruatha.com 1367 S: 250-Fort.net 1368 S: 250-DELIVERBY 15,TIMELY 1369 S: 250 DSN 1370 C: MAIL FROM: BY=20;R TIMELY=20 \ 1371 ENVID=EE271828 RET=HDRS 1372 S: 250 OK to attempt delivery within 20 seconds 1373 C: RCPT TO: NOTIFY=SUCCESS,FALURE \ 1374 ORCPT=rfc822;Sebell@Harper.org 1375 S: 250 OK 1376 C: DATA 1377 S: 354 Send data 1378 C: (message data goes here) 1379 : 1380 . 1381 S: 250 Message received 1383 After a delay of 12 seconds (with 8 seconds of the original 1384 delivery interval remaining), the server Fort.net attempts to relay 1385 the message: 1387 S: 220 Harper.org ESMTP server 1388 C: EHLO Fort.net 1389 S: 250-Harper.org 1390 S: 250-DELIVERBY 10,TIMELY 1391 S: 250 DSN 1392 C: QUIT 1393 S: 221 closing channel 1394 Timely Completion for Internet Messaging 13 September 2001 1395 1397 The minimum delivery interval declared by the server Harper.org is 1398 greater than the time remaining to complete delivery, so Fort.net 1399 does not even attempt to send the message. Instead, it returns a 1400 failure report back to Ruatha.com: 1402 S: 220 Ruatha.com ESMTP server 1403 C: EHLO Fort.net 1404 S: 250-Ruatha.com 1405 S: 250-DELIVERBY 10,TIMELY 1406 S: 250 DSN 1407 C: MAIL FROM:<> BY=40;R 1408 S: 250 OK 1409 C: RCPT TO: NOTIFY=NEVER 1410 S: 250 OK 1411 C: DATA 1412 S: 354 Send data 1413 C: To: Jaxom@Ruatha.com 1414 From: Message-handling@Fort.net 1415 Subject: Delivery failed for Sebell@Harper.org 1416 Content-type: multipart/report; boundary=next; 1417 report-type=delivery-status 1418 MIME-version: 1.0 1420 --next 1421 Content-type: text/plain; charset=US-ASCII 1423 Your message (EE271828) to could not be 1424 delivered within the requested time. 1425 --next 1426 Content-type: message/delivery-status 1428 reporting-MTA: dns; mail-relay.Fort.net 1429 Original-Envelope-ID: EE271828 1431 Original-recipient: rfc822;Sebell@Harper.org 1432 Final-recipient: rfc822;Sebell@Harper.org 1433 Action: failed 1434 Status: 4.4.7 (Timed out during message transfer) 1435 Retry-count: 0 1436 --next-- 1437 . 1438 S: 250 Message received 1440 From the sender's perspective, this is pretty much the same 1441 condition as reported by example 7.2, the difference being that the 1442 time-out has occurred before the message reaches the delivery MTA. 1443 The status code is the same but the reporting MTA is different. 1445 Timely Completion for Internet Messaging 13 September 2001 1446 1448 The retry count value is returned to give the sender an indication 1449 about whether it might retry this path before switching to an 1450 alternative delivery strategy. 1452 7.5 Timely delivery feature not supported 1454 This final example shows failure of a timely delivery request 1455 because a receiving MTA does not support the capability: 1457 +----------+ +----------+ +----------+ 1458 |Lemas.com |-->--|Benden.net|-->--|Miners.org| 1459 +----------+ +----------+ +----------+ 1461 First hop transfer: 1463 S: 220 Benden.net ESMTP server 1464 C: EHLO Lemas.com 1465 S: 250-Benden.net 1466 S: 250-DELIVERBY 10,TIMELY 1467 S: 250 DSN 1468 C: MAIL FROM: BY=20;R TIMELY=20 \ 1469 ENVID=EE271828 RET=HDRS 1470 S: 250 OK to attempt delivery within 20 seconds 1471 C: RCPT TO: NOTIFY=SUCCESS,FALURE \ 1472 ORCPT=rfc822;Nicat@Miners.org 1473 S: 250 OK 1474 C: DATA 1475 S: 354 Send data 1476 C: (message data goes here) 1477 : 1478 . 1479 S: 250 Message received 1481 Five seconds later, Benden.net attempts to forward the message: 1483 S: 220 Miners.org ESMTP server 1484 C: EHLO Benden.net 1485 S: 250-Harper.org 1486 S: 250-DELIVERBY 60 1487 S: 250 DSN 1488 C: QUIT 1489 S: 221 closing channel 1490 Timely Completion for Internet Messaging 13 September 2001 1491 1493 The Miners.org server does not support timely delivery, so 1494 Benden.net does not attempt to send the message. Instead, it sends 1495 a failure report back to Lemas.com: 1497 S: 220 Lemas.com ESMTP server 1498 C: EHLO Benden.net 1499 S: 250-Lemas.com 1500 S: 250-DELIVERBY 10,TIMELY 1501 S: 250 DSN 1502 C: MAIL FROM:<> BY=40;R 1503 S: 250 OK 1504 C: RCPT TO: NOTIFY=NEVER 1505 S: 250 OK 1506 C: DATA 1507 S: 354 Send data 1508 C: To: Asgenar@Lemas.com 1509 From: Message-handling@Benden.net 1510 Subject: Delivery failed for Nicat@Miners.org 1511 Content-type: multipart/report; boundary=next; 1512 report-type=delivery-status 1513 MIME-version: 1.0 1515 --next 1516 Content-type: text/plain; charset=US-ASCII 1518 Your message (EE271828) to could not be 1519 delivered within the requested time. 1520 --next 1521 Content-type: message/delivery-status 1523 reporting-MTA: dns; mail-relay.Benden.net 1524 Original-Envelope-ID: EE271828 1526 Original-recipient: rfc822;Nicat@Miners.org 1527 Final-recipient: rfc822;Nicat@Miners.org 1528 Action: failed 1529 Status: 5.4.8??? (Timely delivery not supported by Miners.org) 1530 --next-- 1531 . 1532 S: 250 Message received 1534 8. IANA Considerations 1536 This specification introduces some new protocol elements for which 1537 IANA registration be required or desirable: 1539 o Extension to DELIVERBY ESMTP extension: see section 4. 1541 o New extended mail system status codes: see section 5.1. 1543 Timely Completion for Internet Messaging 13 September 2001 1544 1546 o New DSN report per-recipient field: see section 5.2. 1548 [[[What to do about these?]]] 1550 9. Internationalization considerations 1552 This specification introduces no new internationalization 1553 considerations other than those already present in DSN, which, 1554 through MIME, provides for charset identification and language 1555 tagging of the human readable part of a DSN report. 1557 10. Security considerations 1559 See also RFC 1894 [12], RFC 2852 [5]. 1561 To offer timely handling of messages may require some dedication of 1562 resource. It is conceivable that systems supporting this feature 1563 may be more susceptible to denial of service attacks from a flood 1564 of messages requesting timely completion. (See also section 6.1.) 1566 There is a distant possibility that responses to time-sensitive 1567 requests may disclose information about the loading or topology of 1568 the network accessed. This is unlikely to be any worse than for 1569 web acces protocols (but note that HTTP has been shown to allow 1570 certain kinds of timing attack on private information about a 1571 client's network activities.). 1573 Systems that depend on the physical presence of a user to achieve 1574 timely receipt SHOULD NOT accept a message for such disposition 1575 without the user's explicit permission (c.f. automated generation 1576 of MDN responses in RFC 2998 [14]). 1578 11. Acknowledgements 1580 The authors thank Hiroshi Tamura-san for undertaking the task of 1581 reviewing a very rough, early draft and making several pertinent 1582 observations. The authors also acknowledge helpful comments by Dan 1583 Wing, Ned Freed and Greg Vaudreuil. 1585 Timely Completion for Internet Messaging 13 September 2001 1586 1588 12. References 1590 [1] RFC 2542, "Terminology and Goals for Internet Fax" 1591 L. Masinter, Xerox Corporation 1592 March 1999. 1594 [2] RFC 821, "Simple Mail Transfer Protocol" 1595 Jonathan B. Postel, ISI/USC 1596 August 1982. 1598 [3] RFC 1651, "SMTP Service Extensions" 1599 J. Klensin, MCI 1600 N. Freed, Innosoft 1601 M. Rose, Dover Beach Consulting, Inc. 1602 E. Stefferud, Network Management Associates, Inc. 1603 D. Crocker, Silicon Graphics, Inc. 1604 July 1994. 1606 [4] RFC 1891, "SMTP Service Extension for Delivery Status 1607 Notifications" 1608 K. Moore, University of Tennessee 1609 January 1996. 1611 [5] RFC 2852, "Deliver By SMTP Service Extension" 1612 D. Newman, Sun Microsystems 1613 June 2000 1615 [6] "Content Negotiation for Internet Messaging Services" 1616 G. Klyne, Baltimore Technologies 1617 R.Iwazaki, Toshiba TEC 1618 D. Crocker, Brandenburg Consulting 1619 Internet draft: draft-ietf-fax-content-negotiation-03.txt 1620 Work in progress: January 2001. 1622 [7] RFC 2234, "Augmented BNF for Syntax Specifications: ABNF" 1623 D. Crocker (editor), Internet Mail Consortium 1624 P. Overell, Demon Internet Ltd. 1625 November 1997. 1627 [8] "Procedures for document facsimile transmission in the general 1628 switched telephone network" 1629 ITU-T Recommendation T.30 (1996), including Amendment 1 (1997), 1630 Amendment 2 (1997), Amendment 3 (1998) and Amendment 4 (1999) 1631 International Telecommunications Union. 1633 [9] RFC 1047, "Duplicate messages and SMTP" 1634 C. Partridge 1635 February 1988. 1637 Timely Completion for Internet Messaging 13 September 2001 1638 1640 [10] RFC 974, "Mail routing and the domain system" 1641 C. Partridge 1642 January 1986. 1644 [11] RFC 2119, "Key words for use in RFCs to Indicate Requirement 1645 Levels" 1646 S. Bradner, Harvard University 1647 March 1997. 1649 [12] RFC 1894, "An Extensible Format for Delivery Status 1650 Notifications" 1651 K. Moore, University of Tennessee 1652 G. Vaudreuil, Octel Network Services 1653 January 1996. 1655 [13] RFC 1893, "Enhanced Mail System Status Codes" 1656 G. Vaudreuil, Octel Network Services 1657 January 1996. 1659 [14] RFC 2298, "An Extensible Message Format for Message Disposition 1660 Notifications" 1661 R. Fajman, National Institutes of Health 1662 March 1998. 1664 [15] G. Vaudreuil, Lucent Technologies, 1665 Extensions to Mail System Status Codes 1666 Internet draft: draft-vaudreuil-1983ext-00.txt 1667 Work-in-progress, June 2001. 1669 13. Authors' addresses 1671 Graham Klyne (editor) 1672 MIMEsweeper Group, 1673 1310 Waterside, 1674 Arlington Business Park 1675 Theale 1676 Reading, RG7 4SA 1677 United Kingdom. 1678 Telephone: +44 118 903 8000 1679 Facsimile: +44 118 903 9000 1680 Email: Graham.Klyne@MIMEsweeper.com 1681 Timely Completion for Internet Messaging 13 September 2001 1682 1684 David H. Crocker 1685 Brandenburg Consulting 1686 675 Spruce Drive 1687 Sunnyvale 1688 CA 94086 1689 USA. 1690 Telephone: +1 408 246 8253 1691 Facsimile: +1 408 273 6464 1692 Email: dcrocker@brandenburg.com 1694 Appendix A: Amendment history 1696 00a 22-Oct-1999 Memo initially created. 1698 01a 13-Sep-1999 Incorporate review comments. Update references. 1699 Changed title. Incorporate material from IETF 1700 meeting presentations. 1702 02a 25-Jan-2001 Update author details. Simplify COMPLIANCE 1703 extension to a TIMELY extension of DELIVERBY. Add 1704 original interval parameter to TIMELY option. 1705 Strengthen description of mechanism for timely 1706 confirmation. Add template decsription for TIMELY 1707 extension. Refer to the goal of this 1708 specification as "timely completion" rather than 1709 just "timely delivery" (to clearly distinguish 1710 from basic DELIVERBY). Added subsection dealing 1711 with final MTA/MUA interaction. Defined DSN 1712 extension header and status codes for reporting 1713 timely delivery failures. Drafted some 1714 implementation notes. 1716 02b 30-Jan-2001 Add examples. Update some references. Other 1717 editorial drafting. 1719 02c 31-Jan-2001 Fold in review comments. Added implementation 1720 note about using DELIVERBY to expedite message 1721 handling (6.5). 1723 02d 01-Feb-2001 More editorial changes. 1725 02e 01-Feb-2001 Revised text dealing with time-out; move 1726 discussion of retries to implementation notes. 1728 03a 16-Feb-2001 Editorial changes. Added some clarifying text to 1729 introductory section 2.2. 1731 03b 13-Jun-2001 Editorial changes. 1733 Timely Completion for Internet Messaging 13 September 2001 1734 1736 04a 12-Sep-2001 Rework some descriptions and status codes to be 1737 clear that this document describes an extension of 1738 the mail delivery semantics rather than some 1739 aspect of disposition semantics. As a result, 1740 some status codes have been removed. Removed text 1741 in section 6.1 about immediate rejection of a 1742 message to help avoid exacerbating congestion 1743 conditions. Changed terminology to focus on the 1744 goal of achieving "final receipt" (rather than 1745 "disposition"). Added reference [15]. 1747 04b 13-Sep-2001 Change contact details. Editorial corrections and 1748 refinements. 1750 04c 13-Sep-2001 Changed some section titles; revised examples 1751 commentary and status codes in line with other 1752 changes. 1754 TODO: 1756 o Finalize status codes (look for 'x.x.x???') 1758 o Resolve/remove all [[[...]]] comments 1760 REVIEW CHECKLIST: 1762 (Points to be checked or considered more widely on or before final 1763 review.) 1765 o Are there any deployed mechanisms that MTAs may use to recognize 1766 expedited message relay? 1768 o Possible minor revision to DELIVERBY spec? If a DELIVERBY MTA 1769 fails message delivery because the delivery time has expired, AND 1770 the message has an empty SMTP sender address/return path, the 1771 message should be silently discarded (c.f. RFC 1891, section 6.2; 1772 I think the considerations noted there seem less applicable.). 1773 If this doesn't work, try next... 1775 o Consider addition of new 'by-mode' value for return DSNs; e.g. 1776 'E' for expedite: try to deliver within interval given, or 1777 abandon delivery, but don't notify success or failure. 1778 (Currently specify 'R' without return-path.) A notification 1779 should not be abandoned if a non-DELIVERBY MTA is encountered. 1781 o Try to model system behaviour under high-load/backlog conditions. 1782 Especially w.r.t. section 3.5. 1784 o What lessons to learn from IP QoS efforts? 1785 Timely Completion for Internet Messaging 13 September 2001 1786 1788 o Query use of enhanced status codes 4.x.x and 5.x.x; Use by 1789 DELIVERBY seems at odds with RFC 1893. 1791 o Note use of status 5.4.1 not in line with expectations of RFC 1792 1893. 1794 o Use new code instead of 5.3.3? 1796 o Special considerations for fax offramp gateay? How to deal with 1797 uncertain dial-out times. 1799 o Check new status code values (currently n???). Should there be 1800 an IANA registry for Enhanced Mail System Status codes (RFC 1801 1893)? 1803 o Apparently, DSN extension fields must be registered with IANA, 1804 but there appears to be no registry for them. 1806 o Use of alternative port? (e.g. like message submission). 1808 o Allow MTAs to impose size limit on messages for timely delivery? 1810 o Operational issues surrounding selection of delivery interval? 1812 o DISCUSS: In environments where the timing of final delivery of 1813 the message is outside the control of the final MTA (e.g. the 1814 time required for an outdial, or waiting for a client to collect 1815 the message), an interim DSN report may be generated indicating 1816 that the message has been received pending final delivery. This 1817 report should be clear whether final delivery is dependent on the 1818 receiving user (e.g. mail collection) or some other unknown 1819 infrastructure delay (e.g. fax out-dial or external e-mail 1820 environment). 1822 This is covered somewhat by section 3.3.1: is this adequate? 1824 o MX configuration -- uniform routing for TIMELY/non-TIMELY. Is a 1825 differential routing option required; e.g. SRV records? 1827 o Can use of ORCPT be relaxed? If partial success occurs for 1828 multiple recipients, it is important to be able to tell which 1829 were successful and which were not. 1831 o When a timely-delivery failure message is sent back, it is 1832 addressed to the sender of the original message; thus it becomes 1833 the sender UA responsibility to handle the failure of timely 1834 delivery -- does this cause any problems? 1835 Timely Completion for Internet Messaging 13 September 2001 1836 1838 o Check examples. (Should relays declare mail-domain or host name? 1839 Does it matter? Should the From: header for DSNs always be 1840 'postmaster', or is any appropriate mailbox OK?) 1842 Full copyright statement 1844 Copyright (C) The Internet Society 2001. All Rights Reserved. 1846 This document and translations of it may be copied and furnished to 1847 others, and derivative works that comment on or otherwise explain 1848 it or assist in its implementation may be prepared, copied, 1849 published and distributed, in whole or in part, without restriction 1850 of any kind, provided that the above copyright notice and this 1851 paragraph are included on all such copies and derivative works. 1852 However, this document itself may not be modified in any way, such 1853 as by removing the copyright notice or references to the Internet 1854 Society or other Internet organizations, except as needed for the 1855 purpose of developing Internet standards in which case the 1856 procedures for copyrights defined in the Internet Standards process 1857 must be followed, or as required to translate it into languages 1858 other than English. 1860 The limited permissions granted above are perpetual and will not be 1861 revoked by the Internet Society or its successors or assigns. 1863 This document and the information contained herein is provided on 1864 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1865 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1866 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1867 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1868 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.