One document matched: draft-ietf-fax-timely-delivery-02.txt
Differences from draft-ietf-fax-timely-delivery-01.txt
IETF fax WG G. Klyne, Baltimore Technologies
Internet draft D. Crocker, Brandenburg Consulting
8 February 2001
Expires: August 2001
Timely Completion for Internet Messaging Services
<draft-ietf-fax-timely-delivery-02.txt>
Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US
West Coast).
Copyright Notice
Copyright (C) The Internet Society 2001. All Rights Reserved.
Abstract
This proposal describes a way to request timely completion for
Internet email, for services such as facsimile and voice messaging.
It provides a deterministic service quality response, while
preserving the traditional roles and responsibiltiies of the agents
involved in e-mail transfers.
It is essentially a profile of the DSN and DELIVERBY extentions for
ESMTP, and a TIMELY option to DELIVERBY with a new deterministic
service quality response.
Klyne & Crocker Internet draft [Page 1]
Timely Completion for Internet Messaging 8 February 2001
<draft-ietf-fax-timely-delivery-02.txt>
Discussion of this document
Please send comments to: <ietf-fax@imc.org>.
To subscribe: send a message with the body 'subscribe' to
<ietf-fax-request@imc.org>. The mailing list archive is at
<http://www.imc.org/ietf-fax/>.
Klyne & Crocker Internet draft [Page 2]
Timely Completion for Internet Messaging 8 February 2001
<draft-ietf-fax-timely-delivery-02.txt>
Table of contents
1. Introduction.............................................4
1.1 Structure of this document ...........................4
1.2 Document terminology and conventions .................4
2. Background and goals.....................................5
2.1 Background ...........................................6
2.2 Basis for timely completion ..........................6
2.2.1 The SMTP "contract"..............................7
2.2.2 Framework for timely delivery....................7
2.3 What does the TIMELY option add? .....................8
2.3.1 DELIVERBY and timely disposition.................9
2.4 Goals for timely completion ..........................9
3. Mechanisms for timely completion.........................10
3.1 Transmitting a message for timely completion .........11
3.2 Relaying a message ...................................12
3.3 Accepting a message by the final MTA .................13
3.3.1 Disposition timing...............................13
3.4 Reporting failures ...................................14
3.5 Timely confirmation ..................................15
4. Timely extension to ESMTP Deliver By extension...........17
4.1 Framework for TIMELY extension to DELIVERBY.............17
4.2 Extension to EHLO DELIVERBY keyword.....................17
4.3 MAIL FROM: TIMELY parameter.............................18
5. DSN reporting extensions.................................18
5.1 New extended mail system status codes ................18
5.2 'Retry-count' per-recipient DSN header ...............19
6. Implementation notes.....................................19
6.1 Message state management .............................19
6.2 Retransmission timing issues .........................21
6.3 Delivery timing granularity ..........................22
6.4 Partial success ......................................22
6.5 Routing TIMELY and non-TIMELY messages ...............23
6.6 Expediting message handling ..........................23
7. Examples.................................................23
7.1 Timely delivery and confirmation .....................23
7.2 Timely delivery achieved, no timely disposition ......26
7.3 Timely delivery achieved, disposition delayed ........27
7.4 Timely delivery could not be achieved ................28
7.5 Timely delivery feature not supported ................30
8. IANA Considerations......................................31
9. Internationalization considerations......................32
10. Security considerations.................................32
11. Acknowledgements........................................32
12. References..............................................32
13. Authors' addresses......................................34
Appendix A: Amendment history...............................35
Full copyright statement....................................37
Klyne & Crocker Internet draft [Page 3]
Timely Completion for Internet Messaging 8 February 2001
<draft-ietf-fax-timely-delivery-02.txt>
1. Introduction
RFC 1891 [4] defines an ESMTP extension for delivery status
notifications, and RFC 2852 [5] defines one for requesting delivery
of a message within a given interval. This memo describes how to
use those specifications, with some small extensions, to achieve
timely completion of message delivery.
1.1 Structure of this document
Section 2 gives the background, principal ideas and goals of this
specification.
Section 3 describes the mechanisms used, and how they are combined
to achieve the timely delivery goals.
Section 4 describes an addition to the ESMTP "Deliver by" extension
which is one of the mechanisms used to achieve timely delivery.
Section 5 describes extensions to the DSN reporting format and
status codes used to report conditions related to timely delivery
requests.
Section 6 contains some non-normative discussion of implementation
issues related to this specification.
Section 7 contains some examples uses of this specification.
1.2 Document terminology and conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119 [11].
Timely delivery
means a message is delivered to a recipient's MTA within a
specified time interval.
Timely disposition
means a message is delivered to and processed by a recipient's
user agent within a specified time interval.
Timely completion
means that notification of a requested timely disposition or
timely delivery is received by the sender of a message within
a determined time interval. Non-receipt of notification
within that interval is indicative of failure.
Klyne & Crocker Internet draft [Page 4]
Timely Completion for Internet Messaging 8 February 2001
<draft-ietf-fax-timely-delivery-02.txt>
Delivery interval
A period of time, measured in seconds, allowed for completion
of message delivery and disposition.
Best efforts
Indicating that a system will ensure that an assigned task is
successfully completed under all but the most catastrophic of
failure circumstances. Common failure modes, such as power
failures, should not prevent eventual completion of a task.
Reasonable efforts
Indicating that a while system will try to complete an
assigned task, it may also indulge in behaviours, or make
operational decisions, that significantly reduce the certainty
that an action will be completed in the face of disruptive
circumstances.
MTA, Mail Transfer Agent
An email system component whose role is to receive and
transfer a message.
MUA, Mail User Agent
An email system component whose role is to prepare and send,
or to receive and process, a message. MUAs are the endpoints
between which emails are sent; MTAs are relays on the path
from a sending MUA to a receiving MUA.
Delivery MTA
In the context of a particular email transfer, the MTA that
accepts the message and passes it to the receiving MUA.
NOTE: Comments like this provide additional nonessential
information about the rationale behind this document.
Such information is not needed for building a conformant
implementation, but may help those who wish to understand
the design in greater depth.
[[[Editorial comments and questions about outstanding issues are
provided in triple brackets like this. These working comments
should be resolved and removed prior to final publication.]]]
2. Background and goals
RFC 2852 [5] provides a mechanism to request timely delivery of a
message using SMTP. While this is helpful, it falls short for some
usage profiles, such as timely processing of fax messages. These
profiles are determined, in part, by the capabilities of
traditional facsimile [8].
Klyne & Crocker Internet draft [Page 5]
Timely Completion for Internet Messaging 8 February 2001
<draft-ietf-fax-timely-delivery-02.txt>
2.1 Background
Traditional e-mail [2] is open-loop. The sender of a message
normally has no certainty if or when a message is delivered. (A
separate memo [6] contains a discussion of some open- and closed-
loop issues in e-mail.)
To be more than just a hint to the message transfer system, timely
completion requires a deterministic confirmation mechanism, to
close the loop. This is provided by DSN [4].
Four kinds of timeliness can be identified:
(a) timely delivery to the recipient
(b) timely delivery to and processing by the recipient
(c) timely notification to the sender of delivery
(d) timely notification to the sender that the message has been
delivered to and processed by the recipient
From the sender's point of view, timely confirmation of delivery
and processing is the most desirable requirement.
2.2 Basis for timely completion
A key premise of this proposal is that timeliness CAN be achieved
using existing protocols, with appropriate software design and
operational management. But the sender and receiver do not control
all the relays used:
o The real issue is lack of determinism: a message might be
delivered quickly, or it might take hours or even days, or it
might not be delivered at all; the sender has little knowledge
and no control.
o A second issue is post-delivery handling: will the receiving
user agent process the message in timely fashion?
One challenge to achieving this is dealing with uncertain transit
times of the confirmation message over the return path (which is
not necessarily the same as the forward path).
Klyne & Crocker Internet draft [Page 6]
Timely Completion for Internet Messaging 8 February 2001
<draft-ietf-fax-timely-delivery-02.txt>
2.2.1 The SMTP "contract"
On accepting a message, a normal SMTP message transfer agent (MTA)
accepts responsibility to:
(a) use best efforts to ensure ultimate delivery of the message,
or
(b) provide notification that delivery could not be achieved.
This memo introduces mechanisms to allow this contract to be
modified. A timely-completion MTA accepts responsibility to:
(a) use reasonable efforts to ensure delivery and disposition
within a specified time, and to provide timely confirmation of
this, or
(b) provide timely notification that delivery and disposition were
not achieved.
The sender can then decide a recovery strategy
2.2.2 Framework for timely delivery
The diagram shows typical SMTP message delivery and delivery status
notification (DSN) paths. Note that the confirmation path is not
necessarily the same as the message delivery path.
Outbound message -->
+-------+ +-----+ +-----+ +---------+
|Sending|-->--|Relay| >>> |Relay|-->--|Receiving|
| MTA | | MTA | | MTA | | MTA |
+-------+ +-----+ +-----+ +---------+
| | |
^ | v
| | |
+-------+ | +---------+
|Sending| | |Receiving|
| UA |-<------------- <<< ------------- | UA |
+-------+ +---------+
<-- Return confirmation
Klyne & Crocker Internet draft [Page 7]
Timely Completion for Internet Messaging 8 February 2001
<draft-ietf-fax-timely-delivery-02.txt>
As well as requesting timely delivery of a message, this proposal
needs to take account of the possibly varying characteristics of
relays of the outbound and return message paths. Practically, it
is possible to require that every relay on the outbound path
recognizes timely completion semantics (using the ESMTP extension
framework), but it is not possible to require this of every relay
on the return path. Thus, it may be necessary to make some
assumptions about the confirmation return path.
NOTE: The uncertainty about return path characteristics
might be removed by requiring an MTA to send any timely
delivery notifcation to the MTA from which it was
received, but this goes against trends in SMTP design and
deployment. This might also raise state maintenance and
hence scalability concerns.
The other issue apparent from the diagram is that providing timely
delivery through the SMTP message relays does not ensure that the
receiving UA will process the message in a timely fashion. If the
receiving MTA delivers to a POP mailbox, there is currently no way
that it can guarantee timely disposition.
2.3 What does the TIMELY option add?
The TIMELY option adds three elements to the DELIVERBY extension:
o it modifies the SMTP contract, permitting an MTA to commute its
responsibility for delivering the message from "best effort" to
"reasonable effort", with notification of outcome.
o it extends the reach of the timeliness constraint to cover the
disposition step (see below).
o it establishes a basis for determining the allowable time
interval for certain behaviours initiated by the receiver of a
message (i.e. DELIVERBY interval for delivery status responses,
and how long to wait for possible duplicate message
transmissions).
This is all consistent with the fundamental strategy of giving the
sender control over the whole process: if an MTA or the disposing
agent cannot communicate the required guarantee, delivery is not
completed and the sender is duly notified.
Klyne & Crocker Internet draft [Page 8]
Timely Completion for Internet Messaging 8 February 2001
<draft-ietf-fax-timely-delivery-02.txt>
2.3.1 DELIVERBY and timely disposition
Timely completion of delivery is handled by the DELIVERYBY ESMTP
extension base specification [5]. However its scope ends with
final delivery by SMTP, not covering receipt and processing
disposition. The TIMELY option modifies the DELIVERBY semantics to
cover the additional step needed to reach the recipient and process
the message.
Consider the following scenario:
+------+ +-----+ +---------+ ------- +---------+
|Sender|-->--|Relay|-->--|Receiving|->-(Message)->-|Disposing|
| MTA | | MTA | | MTA | ( store ) | agent |
+------+ +-----+ +---------+ ------- +---------+
<------SMTP-------> <-------?------->
The base DELIVERBY specification concerns itself with only
participants in the SMTP transfers. But for the purposes of timely
completion of disposition, the sender must be able to specify the
timeliness constraint to include this extra step.
The TIMELY option requires that the receiving MTA communicates with
the disposing agent (in some unspecified way), and that it confirms
final delivery of the message only if the disposing agent confirms
that it will deal with the message in timely fashion, or that it
will return an indication to the receiving MTA if it fails to do
so. Simply putting the message into a POP mailbox would not meet
this criterion.
2.4 Goals for timely completion
The primary goal is to allow consenting parties to establish a
relationship that carries a guarantee of message disposition a
within a specified time, or timely notification that the
disposition was not achieved.
Further goals are:
o Provide "while-you-wait" delivery of messages by e-mail (where
available infrastructure and connectivity permit).
o Deterministic behaviour. A sender who requests timely completion
should be able to determine with reasonable certainty, and in
reasonable time, whether or not that request was successful.
Klyne & Crocker Internet draft [Page 9]
Timely Completion for Internet Messaging 8 February 2001
<draft-ietf-fax-timely-delivery-02.txt>
o If the message cannot be delivered as requested, it should not be
delivered at all. This means that a sender can choose other
strategies for message delivery (e.g. if timely delivery by email
does not succeed, to resend the message as a traditional
facsimile; in such circumstances it is preferable that multiple
copies of the message are not delivered.
o Operates within the existing ESMTP extension framework [3], using
existing facilities where available.
3. Mechanisms for timely completion
Deterministic timely completion is achieved through a number of
ESMTP extensions used in concert:
o Delivery Status Notification ("DSN"), per RFC 1891 [4].
o Deliver-by ("DELIVERBY"), per RFC 2852 [5]
o A new TIMELY extension to DELIVERBY, that serves to modify the
SMTP contract and also to establish that the receiving user agent
can process the message in timely fashion as required, or provide
timely notification of its failure to do so
The confirmation loop for succesful delivery looks something like
this:
+-----------+ +--------+ +--------+ +---------+
|Originating|-->--|Relaying| ... |Relaying|-->--|Receiving|
| MTA | | MTA | | MTA | --| MTA |
+-----------+ +--------+ +--------+ | +---------+
| | |
+-------------+ | +---------+
| Originating |--<-- ... .... ... --<-- |Receiving|
| MUA | | MUA |
+-------------+ +---------+
The path through MTAs taken by the confirmation response is not
defined, and may be different than the forward path of the original
message.
Klyne & Crocker Internet draft [Page 10]
Timely Completion for Internet Messaging 8 February 2001
<draft-ietf-fax-timely-delivery-02.txt>
3.1 Transmitting a message for timely completion
A transmitted message for which timely completion is required MUST
include the following:
o an 'ENVID' parameter on the MAIL FROM command, per DSN [4]
o an 'ORCPT' parameter on the corresponding RCPT TO command(s), per
DSN [4]. (This is to allow the sender to tell exactly which
recipients were succesfully delivered.)
o a 'NOTIFY=SUCCESS,FAILURE' parameter on the corresponding RCPT TO
command(s), per DSN [4]
o a 'BY' parameter on the MAIL FROM command, per [5], with a 'by-
mode' value of 'R'.
o a 'TIMELY' parameter on the MAIL FROM command, as described
below, initially having the same time interval as specified for
'BY'.
The message MUST NOT be transmitted to any MTA that does not
indicate support for all of these extensions in its response to the
EHLO command. In this case, a negative delivery status report MUST
be generated, which SHOULD indicate the non-compliant MTA, the
extensions that it does not support, and the name of the reporting
MTA (per DSN, using the non-compliance reporting extensions noted
later).
Standard DNS MX-based message routing, per RFC 974, SHOULD be used
when sending or relaying the message.
NOTE: Any strategies that vary standard MX routing
should be used with care, and only with the goal of
improving network transit times and timing consistency.
These comments about mail routing apply especially to the
handling of DSN responses.
Ideally, there will be no intermediate relay between the
sending and receiving MTAs, and in any case the number of
such relays should be minimized to reduce timing
variabilities on the transfer path.
Klyne & Crocker Internet draft [Page 11]
Timely Completion for Internet Messaging 8 February 2001
<draft-ietf-fax-timely-delivery-02.txt>
3.2 Relaying a message
An MTA that relays a message for timely completion MUST support all
of the ESMTP extensions noted above, otherwise it should not be
given the message in the first place. When a relaying MTA accepts
a message (by its 2xx status response to receipt of the message
data), it becomes responsible for its onward delivery, including
satisfying all of the options associated with the message.
In order to relay such a message, an MTA MUST note when the message
was received, and the time when the attempt to transmit the message
to the next MTA is initiated, and reduce accordingly the time
interval used for the BY parameter.
If the DELIVERBY time interval is reduced to less than zero, (or
less than some system-configurable value indicating that delivery
within the indicated interval is unlikely to be achieved) then the
message MUST NOT be relayed. Instead, a negative delivery status
report MUST be generated indicating that the time for delivery of
the message has expired, and the reporting MTA (per DSN, using the
deliver-by extensions and/or non-compliance reporting extensions
noted below).
The above behaviour is as specified for the DELIVERBY ESMTP
extension; see RFC 2852 [5] for a definitive description of how to
handle relaying of such messages. The following additional
considerations are applicable when the TIMELY option is used:
The TIMELY parameter, in the MAIL FROM command of a message in
transit, is is copied unchanged when the message is retransmitted.
Thus, any originally specified time interval is conveyed to the
final MTA.
Standard DNS MX-based message routing, per RFC 974, SHOULD be used
when relaying the message. (See note at end of previous section.)
If the first attempt to relay a message fails, the relaying MTA MAY
assume that delivery within the desired time will not be achieved,
and immediately indicate a delivery failure, indicating the name of
the next-hop MTA. Alternatively, the relaying MTA may wait and
retry the transmission, provided that the retry attempt will be
performed within the remaining delivery period; if the
transmission cannot be completed after one or more such retries
then a negative DSN MUST be generated as noted above.
Any negative DSN generated should indicate the number of retries
attempted (where 0 means no retries).
Klyne & Crocker Internet draft [Page 12]
Timely Completion for Internet Messaging 8 February 2001
<draft-ietf-fax-timely-delivery-02.txt>
The choice to retry or not retry is installation dependent.
Effectively, when a relay does not retry, any reposibility for
overcoming the delivery failure is passed back to the original
sender. This strategy may be appropriate for cases where very
rapid delivery is required or expected.
NOTE: The presence of a 'TIMELY' option may cause a
relay to abandon a message that it would otherwise retry
(even given a 'by-mode' value of 'R'). One purpose of
this option is to establish that responsiveness to the
sender is more important than getting the message
through. An effect of this may be to severely constrain
the number and frequency of retry attempts.
3.3 Accepting a message by the final MTA
The MTA that accepts final delivery of a message has responsibility
for passing the message to a Mail User Agent. The exact mechanism
by which this is achieved is a local matter, and not defined here
or by the Internet email specifications. The final MTA is also
responsible for generating any successful DSN message.
Before generating a success DSN message, the final MTA must ensure
that all of the conditions for delivery of the message have been
achieved. Specifically, when the TIMELY option is used, it should
ensure that final delivery to the MUA will be completed within the
delivery interval indicated.
Final delivery to an MUA is expected to include some guarantee of
timely processing. Exactly what this constitutes may depend
somewhat on the circumstances: in a simple case, depositing the
message in a local mailbox and immediately notifying the recipient
probably constitutes final delivery. A more complex case would be
that of a fax offramp, where final delivery may be completion of a
successful outdial and transmission of the fax.
3.3.1 Disposition timing
In the presence of a TIMELY option, final delivery should not be
indicated unless the delivery MTA can establish that the receiving
MUA will deal with the message promptly. Here "promptly" means a
reasonable waiting time for a human; e.g. that the message (or at
least the start of the message) will be available to its intended
final recipient within a period of, say, 30 seconds.
Klyne & Crocker Internet draft [Page 13]
Timely Completion for Internet Messaging 8 February 2001
<draft-ietf-fax-timely-delivery-02.txt>
The relationship between the delivery MTA and receiving MUA can
work in one of two ways:
o the MUA always processes the message promptly, barring
exceptional circumstances. Queuing a message to a network
printer would constitute such processing -- normally the message
will be printed within seconds, even though it might be delayed
if the printer runs out of paper. The delivery MTA can generate
the final DSN when the MUA has accepted the message.
o the MUA attempts to process the message promptly and reports the
outcome within the remaining DELIVERBY period. If processing is
not performed within the stated period, the message is abandoned
and failure is signalled back to the delivery MTA. The delivery
MTA must hold off generating the final DSN until the MUA has
provided a status report; if no such report is provided within
the remaining DELIVERBY interval, it should report failure.
3.4 Reporting failures
When a relay or receiving MTA determines that a message cannot be
delivered as requested to any recipient, a DSN report is sent back
to the sender.
The following status codes indicated that message delivery has been
abandoned, are used with DSN "Action: failed" for reporting
conditions that are specific to timely delivery:
5.4.7: Delivery time expired -- permanent failure.
Message delivery could not be completed within the specified
time interval.
5.4.8???: MTA cannot honour required timely delivery guarantee.
A relay MTA was encountered that did not support the range of
capabilities required for timely completion.
5.4.1: Next MTA not accepting messages.
A relay MTA has been unable to contact a next-hop MTA, and has
decided to abandon delivery. (See note in section 3.2 about a
relay's options with respect to retries.) This code SHOULD be
accompanied by a 'Retry-Count' DSN field.
5.3.3: Receiving MTA cannot honour required timely disposition.
A message has been delivered to a receiving MTA within the
required delivery interval, but that MTA is unable to ensure
timely disposition or timely notification of failure to do so.
5.2.5???: Message delivered but disposition failed.
The message has been delivered but the MUA has reported
failure to complete disposition of the message as requested.
Klyne & Crocker Internet draft [Page 14]
Timely Completion for Internet Messaging 8 February 2001
<draft-ietf-fax-timely-delivery-02.txt>
5.2.6???: Message delivered but disposition not completed.
The message has been delivered and the process of final
disposition has been initiated but has not been completed.
This status code signals that the receiving MTA is assuming
that the disposition has failed.
The following status code is used with DSN "Action: delayed" for
reporting delayed message disposition following final delivery:
4.2.6???: Message delivered pending final disposition.
The message has been delivered and is in the process of final
disposition, but that final disposition has not yet been
completed. This status code is defined for situations where a
receiving MTA has initiated disposition, and has therefore
committed to provide a timely confirmation response, but the
disposing agent has not signalled completion.
For example, a fax dial-out gateway may have been invoked
assuming that the outdial leg would complete within a given
period, but has failed to do so.
A subsequent DSN should be sent when the disposition finally
succeeds or fails.
3.5 Timely confirmation
Fully deterministic behaviour requires that the round-trip time to
deliver a message and receive a response is completed within a
known time interval.
As noted above, it cannot be guaranteed that confirmation of
delivery or non-delivery will be transferred in timely fashion,
though it seems reasonable to assume that return path transit times
will normally be comparable with forward path times. Use of the
DELIVERBY extension for a message MAY serve to expedite its
forwarding.
Further, it is likely that perfect determinism can never be
achieved using SMTP; e.g. see RFC 1047 [9]. Repeat deliveries are
considered less harmful than lost messages, but even these should
be minimized.
The following behaviour is followed to achieve near-deterministic
timely confirmation:
o Always fail forward delivery if a non-TIMELY MTA is encountered.
o A return DSN does not itself request delivery notification and
has an empty return path (as required for DSN).
Klyne & Crocker Internet draft [Page 15]
Timely Completion for Internet Messaging 8 February 2001
<draft-ietf-fax-timely-delivery-02.txt>
o Do NOT use the TIMELY option on any DSN return, so that
notification delivery does not fail if a non-DELIVERBY or
non-TIMELY MTA is encountered on the return path.
o Use the DELIVERBY option to request timely delivery for any DSN
return, using a delivery interval 2 times the original forward
path DELIVERBY time (taken from the received TIMELY parameter),
specifying a 'by-mode' value of 'R'. (The lack of a return path
on the DSN response will mean that neither success or failure
notification will be generated: if thbe DSN cannot be returned
within the time given, it is silently dropped.)
o The sender may assume that the message is lost after 3 times the
original DELIVERBY interval has passed without notificaton.
NOTE: The above timings are based on a working assumption
that normal transit times do not vary by more than a
factor of two. There is nothing scientific about this
choice of value, but laying down some assumption provides
a basis for defining some operational parameters used by
cooperating parties, which in turn provides some basis
for deterministic behaviour.
The purpose of this specification is to give the sender control
over the recovery strategy to be used if timely delivery does not
succeed. It is therefore beyond its scope to set out exactly what
recovery action the sender should take. One possible action is to
retry the transmission, in which case the following additional
considerations apply:
o Retries should be used very sparingly, as the likely cause of
failure is either a permanent network condition or network
congestion. In the case of congestion, retries are likely to
make things worse. (The design of the TCP protocol takes account
of many lessons about network behaviour that have been learned
over the years. A particularly important strategy used is
exponential back-off when retransmitting.)
o The sender is required to provide envelope ID with message. If
it re-tries, it should use same envelope ID and should do so
within a reasonable period of determining the original message
has not been delivered.
o The receiver of a TIMELY message is strongly encouraged to keep
note of received envelope ID for some period, for the purpose of
weeding out duplicates.
Klyne & Crocker Internet draft [Page 16]
Timely Completion for Internet Messaging 8 February 2001
<draft-ietf-fax-timely-delivery-02.txt>
4. Timely extension to ESMTP Deliver By extension
The purpose of this extension is to allow a message sender to
require that timely delivery semantics, described in this memo, be
supported all along the path from message sender to recipient, in
addition to the existing semantics of DELIVERBY.
4.1 Framework for TIMELY extension to DELIVERBY
This extends the framework template for DELIVERBY, given in RFC
2852 [5]:
(1) ESMTP extension name:
"Deliver by", extended for "timely completion"
(2) EHLO keyword:
DELIVERBY, extended as described below
(3) EHLO keyword parameters:
TIMELY (see 4.2 below)
(4) SMTP command parameters:
MAIL FROM: TIMELY (see 4.3 below)
(5) The maximum length of a MAIL FROM command line is increased by
a further 17 characters for the TIMELY parameter (this being in
addition to the 17 character extension for the basic DELIVERBY
extension.
(6) Additional SMTP commands:
(none)
4.2 Extension to EHLO DELIVERBY keyword
This specification defines an extension token for timely
completion. The extension token syntax (from RFC 2852 [5]) is
extended thus:
extension-token /= "TIMELY"
An ESMTP server that supports this timely completion extension MUST
also support the delivery status notification (DSN) ESMTP
extension.
Support for the timely completion extension indicates support for
the MAIL FROM: TIMELY parameter, described below, and for all the
associated processing semantics.
Klyne & Crocker Internet draft [Page 17]
Timely Completion for Internet Messaging 8 February 2001
<draft-ietf-fax-timely-delivery-02.txt>
4.3 MAIL FROM: TIMELY parameter
The MAIL FROM command TIMELY parameter MUST be used in conjunction
with a BY parameter. Its use imposes requirements on the receiving
server's handling of the message that are in addition to those
imposed by the BY parameter.
TIMELY parameter syntax:
timely-parameter = "TIMELY=" interval
interval = 1*9DIGIT
The 'interval' is specified by the original sender of a message to
be the same as the corresponding BY parameter value.
A mail relay copies the received TIMELY value to the retransmitted
message, unchanged. In this way, the originally specified delivery
interval is available to all MTAs that handle the message.
The effect of a TIMELY parameter is to require that message
processing is performed in accordance with the timely completion
mechanisms described in section 3 above.
5. DSN reporting extensions
This specification defines some DSN reporting extensions to allow
additional status information to be returned, which a sending
system might use in choosing a recovery strategy.
5.1 New extended mail system status codes
This memo defines the following additional enhanced mail system
status codes, extending the range of those defined by RFC 1893
[13]:
5.4.8???: MTA cannot honour required timely delivery guarantee.
5.2.5???: Message delivered but disposition failed.
5.2.6???: Message delivered but disposition not completed.
4.2.6???: Message delivered pending final disposition.
See section 3.4 for more detailed descriptions.
Klyne & Crocker Internet draft [Page 18]
Timely Completion for Internet Messaging 8 February 2001
<draft-ietf-fax-timely-delivery-02.txt>
5.2 'Retry-count' per-recipient DSN header
This memo defines an additional per-recipient DSN report field
'Retry-count':
retry-count-field = "Retry-Count" ":" 1*3DIGIT
This field is used in conjunction with status code 5.4.1 to
indicate the number of retries attempted before delivery was
abandoned. A value of "0" means that no retries were attempted.
The purpose of this is to provide information to the sender that
can be used in deciding a recovery strategy.
NOTE: It is in the nature of timely completion that
retries, if performed, would need to be more closely
spaced than is normal for SMTP retries; thus it may be
necessary to reduce the number of retries to avoid
overloading a relay. Some relays may choose not attempt
any retries for messages sent with the TIMELY option. In
such circumstances, a sender may wish to retry before
attempting transmission by some alternative means.
6. Implementation notes
This section is not a normative part of this specification.
The timely completion mechanism is a response to requests for
improved performance in certain uses of email.
Ultimately, achieving the desired performance levels is dependent
on quality of implementation and operational deployment factors.
If a system capable of handling 1000 messages-per-hour is subjected
to periods of demand for 2000 messages-per-hour throughput, then
the performance goals are bound to be substantially under-achieved,
whatever the protocol specification may demand.
The rest of this section discusses some of the implementation
issues and choices raised by this memo, and indicates some ways in
which the performance goals can be addressed.
6.1 Message state management
All requirements for extended-term state rentention are in the
sending and receiving MTAs -- at or close to the edge of the
network. Ideally, these would be the the only MTAs involved, so
provisioning of the service would be entirely under the control of
the organizations who use (or sell) it.
Klyne & Crocker Internet draft [Page 19]
Timely Completion for Internet Messaging 8 February 2001
<draft-ietf-fax-timely-delivery-02.txt>
Where intermediate relays are used, there is no requirement to
maintain information about a message after it has been relayed.
Thus there are no scalability problems created by a need for state
maintenance; performance comes down to message throughput. The
requirement for "reasonable effort" rather than "best effort"
delivery for TIMELY messages means that some message handling
requirements can be relaxed. Rather than copying message data to
disk for re-transmission, it can be held in memory -- it might even
be streamed through to the next relay; loss of message data is not
critical because reporting failure back to the sender is an allowed
option.
When a TIMELY MTA is subjected to high load factors, it needs a
strategy for dealing with this.
The design for timely confirmation to the sender depends on
reasonably consistent transit times on the forward and return
message paths. Delays on the forward path are picked up and
responses can be generated. Delays on the return path will result
in loss of confirmation; losing failure responses should not be
too damaging as the sender will time out and invoke a recovery
strategy. Losing success responses is more harmful, as it may
cause unnecessary additional network traffic.
In view of the above, the following message handling strategy is
suggested:
o Give top priority to forwarding timely status notifications;
i.e. messages with a BY parameter and no return path address.
o Give next priority to receiving new messages. Under conditions
of excessively high load, incoming messages with the TIMELY
option should be rejected immediately; e.g. SMTP [2] response
[[[421???]]] to any incoming MAIL FROM command with a TIMELY
parameter. Non-TIMELY messages can be moved to persistent
storage for later attention.
o Give next priority to processing accepted messages using the
TIMELY option.
o Give next priority yto forwarding messages using the DELIVERBY
option.
o Finally, forward ordinary messages
Klyne & Crocker Internet draft [Page 20]
Timely Completion for Internet Messaging 8 February 2001
<draft-ietf-fax-timely-delivery-02.txt>
If confirmation for a message sent using the TIMELY option is not
received within the expected interval, the sender should be very
copnservative about simply retrying. The reason for non-receipt of
confirmation is probably:
(a) because of mail system congestion, in which case
retransmission will just make things worse, or
(b) some other network problem, in which case a retry won't help.
Since the motivation for this proposal is to provide message
delivery while the sender waits, a reasonable approach would be to
give the sender an option to retry later, send by regular email or
use some other delivery mechanism.
6.2 Retransmission timing issues
Even allowing for the caution stated above about the problems of
simply retransmitting a failed message, it may be that some limited
retransmission is appropriate as part of a recovery strategy.
In order not to exacerbate congestion of intermediate relays, the
following approach is suggested:
o A first retry should not be attempted before 4x the original
DELIVERBY interval has expired.
o Subsequent retry attempts should be attempted at exponentially
increasing intervals; e.g. 8x original interval for the 2nd
retry, 16x for the 3rd retry, etc.
o The requested delivery interval should be increased exponentially
for each retry.
o The total number of retries attempted should be kept reasonably
small; e.g. a maximum of 3-4 retries.
o The receiver of a message should keep a record of the received
message identifier for some period of time, at least 8 times the
original DELIVERBY interval, for the purpose of weeding out
duplicates. It is not possible to state an absolute upper bound
on this period, but it should be as long as the receiver can
reasonably manage, but probably no more than a few days.
More specific recommendations for retransmission strategies may
emerge from deployment experience with this protocol. The basic
approach outlined above uses lessons learned from TCP, notably that
exponential back-off is important to avoid exacerbating congestion
conditions that may be the reason for failure in the first place.
Klyne & Crocker Internet draft [Page 21]
Timely Completion for Internet Messaging 8 February 2001
<draft-ietf-fax-timely-delivery-02.txt>
6.3 Delivery timing granularity
This proposal uses seconds for its time interval values. The best
possible timing resolution for each relay is a whole number of
seconds. Careless handling of these time intervals could lead to
timing errors of a second or worse at each relay.
In general, it is expected that delivery time intervals will be of
the order of 10s of seconds, not less than 10 seconds. The effects
of cummulative timing errors should not be significant if the
number of MTAs involved is kept small (e.g. no more than 2
intermediate relays).
The following procedure is suggested for dealing with timing
through relay MTAs:
o On receipt of a MAIL FROM command, note the time at which it was
received, preferably with a sub-second granularity.
o When the message is subsequently forwarded, note the time
immediately prior to generating the new MAIL FROM command, and
use the difference from time of receipt to calculate the transit
delay. The calculated transit delay should be rounded up to a
whole number of seconds.
o Generate a new MAIL FROM command with the BY parameter 'by-time'
value decreased by the transit delay value.
Rounding up the transit delay should mean that the BY interval is
always decreased by at least 1 when passing through a relay. This
should mean that if many relays are involved, the overall timing
becomes more conservative. This is consistent with the idea that
responsiveness to the sender is considered more important than
actually achieving delivery.
6.4 Partial success
Messages sent to more than one recipient using the TIMELY option
may succeed or fail independently.
Systems must be designed to handle this possibility. E.g. a
sending agent that gives the user an option to resend, or send by
another route, should be capable of recognizing (and reporting)
that some messages have been transferred successfully, and only
attempt an alternative transfer for those that did not (unless, of
course, the user directs otherwise).
Klyne & Crocker Internet draft [Page 22]
Timely Completion for Internet Messaging 8 February 2001
<draft-ietf-fax-timely-delivery-02.txt>
6.5 Routing TIMELY and non-TIMELY messages
The use of MX mail routing means that TIMELY and non-TIMELY
messages to the same domain will be routed via the same servers.
It may be desirable to use separate servers for TIMELY messages.
One way to achieve this operationally would be to use a different
email domain for TIMELY messages, but this may not be ideal from te
users' view of the service.
6.6 Expediting message handling
Invoking the DELIVERBY extension for a given message may be used by
an MTA as a signal to expedite message delivery. But note that
status reports are part of the timely completion cycle, and while
these are sent using the DELIVERBY extension, they do not use the
TIMELY option. Unlike forward-path delays, any delays on the
return path may directly result in the silent loss of a message
status report.
This means that return path messages should be processed at least
as expeditiously as the original message. Hence messages sent
using the TIMELY option should not be given a higher priority than
messages
7. Examples
In the following examples, 'C:' prefixes commands sent from the
SMTP client to the server in a mail transaction, and 'S:' prefixes
responses from the server back to the client.
The notation '\' at the end of a command example indicates that it
continues on the next line. The actual SMTP command must be
presented on a single line.
7.1 Timely delivery and confirmation
This example is of a successful timely delivery and confirmation.
+----------+ +----------+ +----------+
|Lemas.com |-->--|Benden.net|-->--|Harper.org|
+----------+ +----------+ +----------+
First hop transfer:
S: 220 Benden.net ESMTP server
C: EHLO Lemas.com
S: 250-Benden.net
S: 250-DELIVERBY 10,TIMELY
S: 250 DSN
Klyne & Crocker Internet draft [Page 23]
Timely Completion for Internet Messaging 8 February 2001
<draft-ietf-fax-timely-delivery-02.txt>
C: MAIL FROM:<Asgenar@Lemas.com> BY=20;R TIMELY=20 \
ENVID=EE271828 RET=HDRS
S: 250 OK to attempt delivery within 20 seconds
C: RCPT TO:<Robinton@Harper.org> NOTIFY=SUCCESS,FALURE \
ORCPT=rfc822;Robinton@Harper.org
S: 250 OK
C: DATA
S: 354 Send data
C: (message data goes here)
:
.
S: 250 Message received
At this point, the receiving server Benden.net has accepted
responsibility to deliver the message to its destination or send a
failure report back to the sender. Assuming that the next hop is
initiated after a delay of 4 seconds, it may look like this:
S: 220 Harper.org ESMTP server
C: EHLO Benden.net
S: 250-Harper.org
S: 250-DELIVERBY 10,TIMELY
S: 250 DSN
C: MAIL FROM:<Asgenar@Lemas.com> BY=16;R TIMELY=20 \
ENVID=EE271828 RET=HDRS
S: 250 OK
C: RCPT TO:<Robinton@Harper.org> NOTIFY=SUCCESS,FALURE \
ORCPT=rfc822;Robinton@Harper.org
S: 250 OK
C: DATA
S: 354 Send data
C: (message data goes here)
:
.
S: 250 Message received
Klyne & Crocker Internet draft [Page 24]
Timely Completion for Internet Messaging 8 February 2001
<draft-ietf-fax-timely-delivery-02.txt>
At this point, the delivery MTA Harper.org has accepted
responsibility to achieve message disposition or to report a
failure. This will depend on some kind of cooperation with the
receiving user agent. When disposition is completed within the
specified interval, a DSN report is sent in the following fashion:
S: 220 Benden.net ESMTP server
C: EHLO Harper.org
S: 250-Benden.net
S: 250-DELIVERBY 10,TIMELY
S: 250 DSN
C: MAIL FROM:<> BY=40;R
S: 250 OK
C: RCPT TO:<Asgenar@Lemas.com> NOTIFY=NEVER
S: 250 OK
C: DATA
S: 354 Send data
C: To: Asgenar@Lemas.com
From: Message-handling@Harper.org
Subject: Disposition OK for Robinton@Harper.org
Content-type: multipart/report; boundary=next;
report-type=delivery-status
MIME-version: 1.0
--next
Content-type: text/plain; charset=US-ASCII
Your message (EE271828) to <Robinton@Harper.org> was processed
--next
Content-type: message/delivery-status
reporting-MTA: dns; mail-receiver.Harper.org
Original-Envelope-ID: EE271828
Original-recipient: rfc822;Robinton@Harper.org
Final-recipient: rfc822;Robinton@Harper.org
Action: delivered
Status: 2.0.0
--next--
.
S: 250 Message received
On receipt of this confirmation message, the sender's user agent
will be able to correlate with the original using the 'Original-
Envelope-ID' and 'Original-recipient' values, and confirm to the
sender that the message has been delivered and processed.
Klyne & Crocker Internet draft [Page 25]
Timely Completion for Internet Messaging 8 February 2001
<draft-ietf-fax-timely-delivery-02.txt>
7.2 Timely delivery achieved, no timely disposition
This example follows the same sequence as the previous one, up to
the point that the delivery MTA Harper.org has accepted
responsibility to achieve message disposition or to report a
failure. In this case, having accepted the message for delivery,
disposition cannot be achieved in the desired interval so a failure
DSN must be sent:
S: 220 Benden.net ESMTP server
C: EHLO Harper.org
S: 250-Benden.net
S: 250-DELIVERBY 10,TIMELY
S: 250 DSN
C: MAIL FROM:<> BY=40;R
S: 250 OK
C: RCPT TO:<Asgenar@Lemas.com> NOTIFY=NEVER
S: 250 OK
C: DATA
S: 354 Send data
C: To: Asgenar@Lemas.com
From: Message-handling@Harper.org
Subject: Disposition failed for Robinton@Harper.org
Content-type: multipart/report; boundary=next;
report-type=delivery-status
MIME-version: 1.0
--next
Content-type: text/plain; charset=US-ASCII
Your message (EE271828) to <Robinton@Harper.org> could not
be processed within the requested time.
--next
Content-type: message/delivery-status
reporting-MTA: dns; mail-receiver.Harper.org
Original-Envelope-ID: EE271828
Original-recipient: rfc822;Robinton@Harper.org
Final-recipient: rfc822;Robinton@Harper.org
Action: failed
Status: 5.2.5???
--next--
.
S: 250 Message received
Because this is a specific failure condition being sent to a source
that has used the timely delivery extension, and the message can be
correlated with the original by means of the 'Original-Envelope-ID'
Klyne & Crocker Internet draft [Page 26]
Timely Completion for Internet Messaging 8 February 2001
<draft-ietf-fax-timely-delivery-02.txt>
and 'Original-Recipient' values, no part of the original message is
returned with the DSN report.
7.3 Timely delivery achieved, disposition delayed
This example is similar to the previous one, except that
disposition is in progress but its completion is delayed. In this
case, the message cannot be recalled, so a notification report is
sent to the sender indicating, within the requested delivery
period, indicating that the message is delivered and in
disposition. Later, a final delivery status message will be sent.
S: 220 Benden.net ESMTP server
C: EHLO Harper.org
S: 250-Benden.net
S: 250-DELIVERBY 10,TIMELY
S: 250 DSN
C: MAIL FROM:<> BY=40;R
S: 250 OK
C: RCPT TO:<Asgenar@Lemas.com> NOTIFY=NEVER
S: 250 OK
C: DATA
S: 354 Send data
C: To: Asgenar@Lemas.com
From: Message-handling@Harper.org
Subject: Disposition delayed for Robinton@Harper.org
Content-type: multipart/report; boundary=next;
report-type=delivery-status
MIME-version: 1.0
--next
Content-type: text/plain; charset=US-ASCII
Your message (EE271828) to <Robinton@Harper.org> is being
processed but not completed within the requested time.
--next
Content-type: message/delivery-status
reporting-MTA: dns; mail-receiver.Harper.org
Original-Envelope-ID: EE271828
Original-recipient: rfc822;Robinton@Harper.org
Final-recipient: rfc822;Robinton@Harper.org
Action: delayed
Status: 4.2.6???
--next--
.
S: 250 Message received
Klyne & Crocker Internet draft [Page 27]
Timely Completion for Internet Messaging 8 February 2001
<draft-ietf-fax-timely-delivery-02.txt>
7.4 Timely delivery could not be achieved
This example is of a failed attempt to achieve timely delivery
because the message could not be forwarded within the requested
interval.
+----------+ +----------+ +----------+
|Ruatha.com|-->--|Fort.net |-->--|Harper.org|
+----------+ +----------+ +----------+
First hop transfer:
S: 220 Fort.net ESMTP server
C: EHLO Ruatha.com
S: 250-Fort.net
S: 250-DELIVERBY 15,TIMELY
S: 250 DSN
C: MAIL FROM:<Jaxom@Ruatha.com> BY=20;R TIMELY=20 \
ENVID=EE271828 RET=HDRS
S: 250 OK to attempt delivery within 20 seconds
C: RCPT TO:<Sebell@Harper.org> NOTIFY=SUCCESS,FALURE \
ORCPT=rfc822;Sebell@Harper.org
S: 250 OK
C: DATA
S: 354 Send data
C: (message data goes here)
:
.
S: 250 Message received
After a delay of 12 seconds (with 8 seconds of the original
delivery interval remaining), the server Fort.net attempts to relay
the message:
S: 220 Harper.org ESMTP server
C: EHLO Fort.net
S: 250-Harper.org
S: 250-DELIVERBY 10,TIMELY
S: 250 DSN
C: QUIT
S: 221 <Harper.org> closing channel
Klyne & Crocker Internet draft [Page 28]
Timely Completion for Internet Messaging 8 February 2001
<draft-ietf-fax-timely-delivery-02.txt>
The minimum delivery interval declared by the server Harper.org is
greater than the time remaining to complete delivery, so Fort.net
does not even attempt to send the message. Instead, it returns a
failure report back to Ruatha.com:
S: 220 Ruatha.com ESMTP server
C: EHLO Fort.net
S: 250-Ruatha.com
S: 250-DELIVERBY 10,TIMELY
S: 250 DSN
C: MAIL FROM:<> BY=40;R
S: 250 OK
C: RCPT TO:<Jaxom@Ruatha.com> NOTIFY=NEVER
S: 250 OK
C: DATA
S: 354 Send data
C: To: Jaxom@Ruatha.com
From: Message-handling@Fort.net
Subject: Delivery failed for Sebell@Harper.org
Content-type: multipart/report; boundary=next;
report-type=delivery-status
MIME-version: 1.0
--next
Content-type: text/plain; charset=US-ASCII
Your message (EE271828) to <Sebell@Harper.org> could not be
delivered within the requested time.
--next
Content-type: message/delivery-status
reporting-MTA: dns; mail-relay.Fort.net
Original-Envelope-ID: EE271828
Original-recipient: rfc822;Sebell@Harper.org
Final-recipient: rfc822;Sebell@Harper.org
Action: failed
Status: 5.4.7
Retry-count: 0
--next--
.
S: 250 Message received
The retry count value is returned to give the sender an indication
about whether it might retry this path before switching to an
alternative delivery strategy.
Klyne & Crocker Internet draft [Page 29]
Timely Completion for Internet Messaging 8 February 2001
<draft-ietf-fax-timely-delivery-02.txt>
7.5 Timely delivery feature not supported
This final example shows failure of a timely delivery request
because a receiving MTA does not support the capability:
+----------+ +----------+ +----------+
|Lemas.com |-->--|Benden.net|-->--|Miners.org|
+----------+ +----------+ +----------+
First hop transfer:
S: 220 Benden.net ESMTP server
C: EHLO Lemas.com
S: 250-Benden.net
S: 250-DELIVERBY 10,TIMELY
S: 250 DSN
C: MAIL FROM:<Asgenar@Lemas.com> BY=20;R TIMELY=20 \
ENVID=EE271828 RET=HDRS
S: 250 OK to attempt delivery within 20 seconds
C: RCPT TO:<Nicat@Miners.org> NOTIFY=SUCCESS,FALURE \
ORCPT=rfc822;Nicat@Miners.org
S: 250 OK
C: DATA
S: 354 Send data
C: (message data goes here)
:
.
S: 250 Message received
Five seconds later, Benden.net attempts to forward the message:
S: 220 Minbers.org ESMTP server
C: EHLO Benden.net
S: 250-Harper.org
S: 250-DELIVERBY 60
S: 250 DSN
C: QUIT
S: 221 <Miners.org> closing channel
Klyne & Crocker Internet draft [Page 30]
Timely Completion for Internet Messaging 8 February 2001
<draft-ietf-fax-timely-delivery-02.txt>
The Miners.org server does not support timely delivery, so
Benden.net does not attempt to send the message. Instead, it sends
a failure report back to Lemas.com:
S: 220 Lemas.com ESMTP server
C: EHLO Benden.net
S: 250-Lemas.com
S: 250-DELIVERBY 10,TIMELY
S: 250 DSN
C: MAIL FROM:<> BY=40;R
S: 250 OK
C: RCPT TO:<Asgenar@Lemas.com> NOTIFY=NEVER
S: 250 OK
C: DATA
S: 354 Send data
C: To: Asgenar@Lemas.com
From: Message-handling@Benden.net
Subject: Delivery failed for Nicat@Miners.org
Content-type: multipart/report; boundary=next;
report-type=delivery-status
MIME-version: 1.0
--next
Content-type: text/plain; charset=US-ASCII
Your message (EE271828) to <Nicat@Miners.org> could not be
delivered within the requested time.
--next
Content-type: message/delivery-status
reporting-MTA: dns; mail-relay.Benden.net
Original-Envelope-ID: EE271828
Original-recipient: rfc822;Nicat@Miners.org
Final-recipient: rfc822;Nicat@Miners.org
Action: failed
Status: 5.4.8???
--next--
.
S: 250 Message received
8. IANA Considerations
This specification introduces some new protocol elements for which
IANA registration be required or desirable:
o Extension to DELIVERBY ESMTP extension: see section 4.
o New extended mail system status codes: see section 5.1.
Klyne & Crocker Internet draft [Page 31]
Timely Completion for Internet Messaging 8 February 2001
<draft-ietf-fax-timely-delivery-02.txt>
o New DSN report per-recipient field: see section 5.2.
[[[What to do about these?]]]
9. Internationalization considerations
This specification introduces no new internationalization
considerations other than those already present in DSN, which,
through MIME, provides for charset identification and language
tagging of the human readable part of a DSN report.
10. Security considerations
See also RFC 1894 [12], RFC 2852 [5].
To offer timely handling of messages may require some dedication of
resource. It is conceivable that systems supporting this feature
may be more susceptible to denial of service attacks from a flood
of messages requesting timely completion. (See also section 6.1.)
There is a distant possibility that responses to time-sensitive
requests may disclose information about the loading or topology of
the network accessed. This is unlikely to be any worse than for
web acces protocols (but note that HTTP has been shown to allow
certain kinds of timing attack on private information about a
client's network activities.).
Systems that depend on the physical presence of a user to achieve
timely disposition should not accept a message for such disposition
without the user's explicit permission (c.f. automated generation
of MDN responses in RFC 2998 [14]).
11. Acknowledgements
The authors thank Hiroshi Tamura-san for undertaking the task of
reviewing a very rough, early draft and making several pertinent
observations.
12. References
[1] RFC 2542, "Terminology and Goals for Internet Fax"
L. Masinter, Xerox Corporation
March 1999.
Klyne & Crocker Internet draft [Page 32]
Timely Completion for Internet Messaging 8 February 2001
<draft-ietf-fax-timely-delivery-02.txt>
[2] RFC 821, "Simple Mail Transfer Protocol"
Jonathan B. Postel, ISI/USC
August 1982.
[3] RFC 1651, "SMTP Service Extensions"
J. Klensin, MCI
N. Freed, Innosoft
M. Rose, Dover Beach Consulting, Inc.
E. Stefferud, Network Management Associates, Inc.
D. Crocker, Silicon Graphics, Inc.
July 1994.
[4] RFC 1891, "SMTP Service Extension for Delivery Status
Notifications"
K. Moore, University of Tennessee
January 1996.
[5] RFC 2852, "Deliver By SMTP Service Extension"
D. Newman, Sun Microsystems
June 2000
[6] "Content Negotiation for Internet Messaging Services"
G. Klyne, Baltimore Technologies
R.Iwazaki, Toshiba TEC
D. Crocker, Brandenburg Consulting
Internet draft: draft-ietf-fax-content-negotiation-03.txt
Work in progress: January 2001.
[7] RFC 2234, "Augmented BNF for Syntax Specifications: ABNF"
D. Crocker (editor), Internet Mail Consortium
P. Overell, Demon Internet Ltd.
November 1997.
[8] "Procedures for document facsimile transmission in the general
switched telephone network"
ITU-T Recommendation T.30 (1996), including Amendment 1 (1997),
Amendment 2 (1997), Amendment 3 (1998) and Amendment 4 (1999)
International Telecommunications Union.
[9] RFC 1047, "Duplicate messages and SMTP"
C. Partridge
February 1988.
[10] RFC 974, "Mail routing and the domain system"
C. Partridge
January 1986.
Klyne & Crocker Internet draft [Page 33]
Timely Completion for Internet Messaging 8 February 2001
<draft-ietf-fax-timely-delivery-02.txt>
[11] RFC 2119, "Key words for use in RFCs to Indicate Requirement
Levels"
S. Bradner, Harvard University
March 1997.
[12] RFC 1894, "An Extensible Format for Delivery Status
Notifications"
K. Moore, University of Tennessee
G. Vaudreuil, Octel Network Services
January 1996.
[13] RFC 1893, "Enhanced Mail System Status Codes"
G. Vaudreuil, Octel Network Services
January 1996.
[14] RFC 2298, "An Extensible Message Format for Message Disposition
Notifications"
R. Fajman, National Institutes of Health
March 1998.
13. Authors' addresses
Graham Klyne (editor)
Baltimore Technologies - Content Security Group,
1220 Parkview,
Arlington Business Park
Theale
Reading, RG7 4SA
United Kingdom.
Telephone: +44 118 930 1300
Facsimile: +44 118 930 1301
E-mail: GK@ACM.ORG
David H. Crocker
Brandenburg Consulting
675 Spruce Drive
Sunnyvale
CA 94086
USA.
Telephone: +1 408 246 8253
Facsimile: +1 408 273 6464
E-mail: dcrocker@brandenburg.com
Klyne & Crocker Internet draft [Page 34]
Timely Completion for Internet Messaging 8 February 2001
<draft-ietf-fax-timely-delivery-02.txt>
Appendix A: Amendment history
00a 22-Oct-1999 Memo initially created.
01a 13-Sep-1999 Incorporate review comments. Update references.
Changed title. Incorporate material from IETF
meeting presentations.
02a 25-Jan-2001 Update author details. Simplify COMPLIANCE
extension to a TIMELY extension of DELIVERBY. Add
original interval parameter to TIMELY option.
Strengthen description of mechanism for timely
confirmation. Add template decsription for TIMELY
extension. Refer to the goal of this
specification as "timely completion" rather than
just "timely delivery" (to clearly distinguish
from basic DELIVERBY). Added subsection dealing
with final MTA/MUA interaction. Defined DSN
extension header and status codes for reporting
timely delivery failures. Drafted some
implementation notes.
02b 30-Jan-2001 Add examples. Update some references. Other
editorial drafting.
02c 31-Jan-2001 Fold in review comments. Added implementation
note about using DELIVERBY to expedite message
handling (6.5).
02d 01-Feb-2001 More editorial changes.
02e 01-Feb-2001 Revised text dealing with time-out; move
discussion of retries to implementation notes.
TODO:
o Need to define a mechanism to allow a MAIL FROM with TIMELY
option to be rejected immediately, for congestion control.
o Finalize status codes
REVIEW CHECKLIST:
(Points to be checked or considered more widely on or before final
review.)
o Are there any deployed mechanisms that MTAs may use to recognize
expedited message relay?
Klyne & Crocker Internet draft [Page 35]
Timely Completion for Internet Messaging 8 February 2001
<draft-ietf-fax-timely-delivery-02.txt>
o Possible minor revision to DELIVERBY spec? If a DELIVERBY MTA
fails message delivery because the delivery time has expired, AND
the message has an empty SMTP sender address/return path, the
message should be siletly discarded (c.f. RFC 1891, section 6.2;
I think the considerations noted there seem less applicable.).
If this doesn't work, try next...
o Consider addition of new 'by-mode' value for return DSNs; e.g.
'E' for expedite: try to deliver within interval given, or
abandon delivery, but don't notify success or failure.
(Currently specify 'R' without return-path.) A notification
should not be abandoned if a non-DELIVERBY MTA is encountered.
o Try to model system behaviour under high-load/backlog conditions.
Especially w.r.t. section 3.5.
o What lessons to learn from IP QoS efforts?
o Query use of enhanced status codes 4.x.x and 5.x.x; Use by
DELIVERBY seems at odds with RFC 1893.
o Note use of status 5.4.1 not in line with expectations of RFC
1893.
o Use new code instead of 5.3.3?
o Special considerations for fax offramp gateay? How to deal with
uncertain dial-out times.
o Check new status code values (currently n???). Should there be
an IANA registry for Enhanced Mail System Status codes (RFC
1893)?
o Apparently, DSN extension fields must be registered with IANA,
but there appears to be no registry for them.
o Use of alternative port? (e.g. like message submission).
o Allow MTAs to impose size limit on messages for timely delivery?
o Allow for separate delivery and disposition times? (e.g. 10
second transfer + 60 second disposition would leave a sender
waiting for a long time to determine failure.)
o Operational issues surrounding selection of delivery interval?
o DISCUSS: In environments where the timing of final delivery of
the message is outside the control of the final MTA (e.g. the
time required for an outdial, or waiting for a client to collect
the message), an interim DSN report may be generated indicating
Klyne & Crocker Internet draft [Page 36]
Timely Completion for Internet Messaging 8 February 2001
<draft-ietf-fax-timely-delivery-02.txt>
that the message has been received pending final delivery. This
report should be clear whether final delivery is dependent on the
receiving user (e.g. mail collection) or some other unknown
infrastructure delay (e.g. fax out-dial or external e-mail
environment).
This is covered somewhat by section 3.3.1: is this adequate?
o MX configuration -- uniform routing for TIMELY/non-TIMELY. Is a
differential routing option required; e.g. SRV records?
o Can use of ORCPT be relaxed? If partial success occurs for
multiple recipients, it is important to be able to tell which
were successful and which were not.
o When a timely-delivery failure message is sent back, it is
addressed to the sender of the original message; thus it becomes
the sender UA responsibility to handle the failure of timely
delivery -- does this cause any problems?
o Check examples. (Should relays declare mail-domain or host name?
Does it matter? Should the From: header for DSNs always be
'postmaster', or is any appropriate mailbox OK?)
Full copyright statement
Copyright (C) The Internet Society 2001. All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice and this
paragraph are included on all such copies and derivative works.
However, this document itself may not be modified in any way, such
as by removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the
purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards process
must be followed, or as required to translate it into languages
other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
Klyne & Crocker Internet draft [Page 37]
Timely Completion for Internet Messaging 8 February 2001
<draft-ietf-fax-timely-delivery-02.txt>
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Klyne & Crocker Internet draft [Page 38]
| PAFTECH AB 2003-2026 | 2026-04-22 15:18:33 |