Internet DRAFT - draft-wing-smtp-session
draft-wing-smtp-session
HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 12:12:32 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Tue, 26 Aug 1997 15:15:00 GMT
ETag: "3ddc3d-5318-3402f2f4"
Accept-Ranges: bytes
Content-Length: 21272
Connection: close
Content-Type: text/plain
Internet Draft Dan Wing
August 26, 1997 Neil Joffe
Expires February 1998 Cisco Systems, Inc.
Larry Masinter
Xerox Corporation
Immediate Delivery over SMTP
draft-wing-smtp-session-00.txt
Status of this memo
This document is an Internet-Draft. 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."
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet- Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
1. Abstract
This memo defines an extension to SMTP [RFC821] which provides a
mechanism for immediate message delivery over ESMTP, bypassing SMTP's
normal store-and-forward behavior.
2. Introduction
Historically, SMTP [RFC821, RFC822] and [SMTP-EXT] have been used for
store and forward delivery of messages. This draft defines a new
transport mode for ESMTP delivery known as SESSION. When SESSION is
used, the ESMTP server delivers the message before the ESMTP client
disconnects from it.
This feature allows for 'priority' delivery of mail if all MTAs in the
SMTP "path" support SESSION delivery. If any MTA does not support
SESSION, automatic fallback to normal store and forward delivery occurs.
Wing, Joffe, Masinter Expires February 1998 [Page 1]
Internet Draft Immediate Delivery over ESMTP August 1997
Such priority delivery may be useful in certain business environments,
or to more closely emulate behavior of other office equipment (such as
fax machines).
This memo uses the mechanism described in [SMTP-EXT] to define an
extension to the SMTP protocol for immediate delivery.
2.1. Discussion of this draft
This draft is being discussed on the "ietf-fax" mailing list. To
subscribe, send a message to:
ietf-fax-request@imc.org
with the line:
subscribe
in the body of the message. Archives are available from
http://www.imc.org/ietf-fax.
2.2. Requirements notation
This document occasionally uses terms that appear in capital
letters. When the terms "MUST", "SHOULD", "MUST NOT", "SHOULD
NOT", and "MAY" appear capitalized, they are being used to
indicate particular requirements of this specification. A
discussion of the meanings of these terms appears in [REQ].
3. Framework for immediate delivery support
The immediate message delivery is defined as follows:
(1) The name of the immediate extension is Session;
(2) the EHLO keyword value associated with the immediate extension
is SESSION;
(3) no parameter is used with the SESSION EHLO keyword;
(4) one new SMTP verb, STAT, (used to query the status of each
Session recipient), is defined with this extension, and is
described in section 4;
(5) one optional parameter is added to the RCPT command, using the
esmtp-keyword SESSION, and is described in section 4,
no parameters are added to the MAIL FROM command;
(6) the esmtp-keyword SESSION changes the meaning of the terminating
Wing, Joffe, Masinter Expires February 1998 [Page 2]
Internet Draft Immediate Delivery over ESMTP August 1997
"." as described in section 4.2;
(7) the maximum length of a RCPT TO is increased by 8 characters.
4. Behavior of RCPT TO:<forward-path> SESSION
A RCPT command issued by a client may also contain the esmtp-keyword
SESSION. This keyword causes the ESMTP server to attempt immediate
delivery of the message to the local user, or immediate connection with
the next MTA in the ESMTP path. The ESMTP server SHOULD only respond
after it has successfully connected to the next MTA in the ESMTP path
and received the remote ESMTP server's response to the RCPT command.
4.1. Response to esmtp-keyword SESSION
Upon receiving a RCPT command with the esmtp-keyword SESSION, an ESMTP server
MUST respond with a 250 only if:
a) the SMTP server is able to connect to the "next hop" in the SMTP
"path" and after it has received a 250 reply to its RCPT command
(with the esmtp-keyword SESSION) with that "next hop" ESMTP
server,
or
b) the SMTP server is delivering to a local user's mailbox.
If SESSION isn't available for this recipient and the recipient is valid
in all other respects, then the ESMTP server MUST respond with 251 and
deliver the message using normal store-and-forward.
The ESMTP server returns 450 if SESSION mode isn't available due to
resource constraints. The ESMTP client may attempt to send the message
without Session in this transaction, or the ESMTP client may retry
sending the message with Session as a new transaction later.
4.2. Meaning of "250" reply to terminating "." with SESSION
The ESMTP server's response to the end of mail data indication ("." or
BDAT LAST if using [CHUNKING]) only indicates successful receipt of
the mail data -- as with [RFC821] the data could still be spooling to
the recipient(s). However, with SESSION, the ESMTP client MUST use the
STAT verb to determine the success (or failure) of the delivery to each
of the forward-path(s) that used the esmtp-keyword SESSION.
If the ESMTP server has responded with a "250" reply to the end of mail
data indication, but has not successfully completed delivery before the
Wing, Joffe, Masinter Expires February 1998 [Page 3]
Internet Draft Immediate Delivery over ESMTP August 1997
ESMTP client disconnects from the ESMTP server (either by a QUIT command
or a TCP FIN or RST), the ESMTP server SHOULD attempt to continue
deliverying the message(s).
4.3. SESSION-only ESMTP servers that cannot relay mail
A legacy SMTP client (which doesn't support SESSION) may connect to an
ESMTP server that only supports SESSION and cannot relay mail (such as a
printer or fax machine). As the ESMTP client isn't SESSION aware and
won't send STAT commands for each recipient, the ESMTP server cannot
indicate which of several recipients has succeeded or failed. Thus,
only one recipient is permitted.
If a SESSION-only ESMTP server receives a RCPT TO without the
esmtp-keyword SESSION, the ESMTP server MUST:
(1) allow only one valid forward-path, as there is no way to indicate
delivery success/failure to multiple recipients. If the SMTP
client sends more than one valid forward-path in a single SMTP
transaction, the ESMTP server should reject them with a "421"
response.
(2) only respond to the terminating "." after the message has been
successfully or unsuccessfully received by the recipient.
4.4. Behavior of esmtp-keyword SESSION with DSN
If an ESMTP server supports Delivery Status Notification [DSN] and
SESSION, and a RCPT command contains both SESSION and a DSN request
for either SUCCESS or FAILURE, then one of the following scenerios
is possible:
(1) SESSION is successful, in which case a DSN MUST NOT be generated;
(2) SESSION is unsuccessful, and fallback to store and forward
occurred, then the DSN MUST be handled normally (by requesting DSN
from the remote MTA);
(3) SESSION is unsuccessful, and fallback to store and forward did
not occur, and the ESMTP client is informed (in a reply to a STAT
command) that fallback to store and forward did not occur,
a DSN MUST NOT be generated;
(4) SESSION is unsuccessful, and fallback to store and forward did
not occur, and the ESMTP client is not informed (in a reply to
a STAT command, perhaps due to the ESMTP client disconnecting
Wing, Joffe, Masinter Expires February 1998 [Page 4]
Internet Draft Immediate Delivery over ESMTP August 1997
or improperly sending a QUIT command), a DSN MUST be generated
by this MTA.
5. New SMTP verb STAT
One new SMTP verb is introduced with the Session extension. The STAT
verb allows a client to query the success, failure, and progress of
message transmission to any Session mode recipient.
5.1. Usage and syntax of STAT verb
The STAT verb MUST be used by the ESMTP client to determine the success
or failure of a RCPT command that included the esmtp-keyword SESSION.
An ESMTP client MUST NOT send a "STAT <forward-path>" command unless
both of the following conditions are true:
1. the RCPT command for that forward-path included the esmtp-keyword
SESSION, and
2. the ESMTP server responded to that forward-path with a 2xx
(success) reply code.
If the ESMTP client violates one of the above restrictions, the ESMTP
server SHOULD respond with a 501 error code.
The syntax of the STAT verb, using the format described in [ABNF], is:
stat-cmd = "STAT" SP <forward-path> CR LF
5.2. Server reply to STAT
The ESMTP server's reply to STAT must be parsable by the ESMTP client
for possible presentation to the user via a progress indicator. The
replies must adhere to the following [ABNF] format:
stat-int-rsp = rsp-code SP [status-code SP]
<forward-path> SP
cmpl-seconds ";" total-bytes ";" bytes-sent ";" pages-sent
[SP 1*text]
rsp-code = "250" / "251" / "550" / "450"
cmpl-seconds = 1*DIGIT ; estimated seconds to complete,
; 0=completed or fallback occurred
total-bytes = 1*DIGIT
Wing, Joffe, Masinter Expires February 1998 [Page 5]
Internet Draft Immediate Delivery over ESMTP August 1997
bytes-sent = 1*DIGIT
pages-sent = 1*DIGIT ; pages sent. If this is not a
; printable document (where pages
; make sense), the value MUST be 0.
text = <any CHAR except CTL, DIGIT, and ";">
status-code = <`status-code' from section 4 of [ENH-RET]>
If the ESMTP server has completed mail data transfer (either
successfully or unsucessfully), <cmpl-seconds> is zero. In no other
cases shall <cmpl-seconds> be zero.
If fallback to store-and-forward occurred, the ESMTP server MUST respond
with a 251 reply code, and <cmpl-seconds> is 0, <total-bytes> is the
number of bytes that the server intended to send in session mode, and
<bytes-sent> is the number of bytes that were actually sent by the
server when the session delivery failed.
<total-bytes> and <bytes-sent> should both be equal to the number of
bytes that will be sent by the server.
If the attempt at SESSION delivery failed and store and forward
did not occur, the ESMTP server MUST respond with a 550 or 450 reply
code.
Note that <total-bytes>, <bytes-sent>, and <pages-sent> are all
determined by the server. The number of bytes sent by the ESMTP client
may be different than the number of bytes being sent by the ESMTP server,
especially if the ESMTP server is performing any data conversion.
Example responses:
Transmission not yet complete:
250 2.5.0 <masinter@parc.xerox.com> 30;782732;5567;0
250 2.5.0 <masinter@parc.xerox.com> 20;5321;78275;0
250 <+1-303-555-1212@gw.xerox.com> 3;3210;100;0
Transmission complete:
250 <masinter@parc.xerox.com> 0;7828;7828;0
250 2.5.0 <+1-303-555-1212@gw.xerox.com> 0;8891;8891;10
251 <dwing@cisco.com> 0;2131;30158;0 fallback occured
Transmission errors:
550 5.2.0 <dwing@cisco.com> 0;72194;0;0 unable to lock user's mailbox
550 <dwing@cisco.com> 0;81731;0;0 infinite forwarding detected
550 5.2.1 <dwing@cisco.com> 0;87287;0;0 busy
550 5.4.1 <+1-303-555-1212@gw.xerox.com> 0;72831;0;0 no answer
450 4.4.2 <+1-303-555-1212@gw.xerox.com> 0;87513;0;0 no carrier
Wing, Joffe, Masinter Expires February 1998 [Page 6]
Internet Draft Immediate Delivery over ESMTP August 1997
450 <+1-303-555-1212@xerox.com> 0;878821;830131;4 no page confirmation
450 <masinter@parc.xerox.com> 0;893121;830141;0 lost Session connection
6. Examples
6.1. SESSION delivery
6.1.1. Two recipients
S: 220 foo.cisco.com ESMTP service ready
C: EHLO pc.cisco.com
S: 250-foo.cisco.com says hello
S: 250 SESSION
C: MAIL FROM:<dwing@cisco.com>
S: 250 <dwing@cisco.com> Sender ok
C: RCPT TO:<masinter@parc.xerox.com> SESSION
S: 250 <masinter@parc.xerox.com> and options ok
C: RCPT TO:<njoffe@cisco.com> SESSION
S: 250 <njoffe@cisco.com> and options ok
C: DATA
S: 354 Enter your data
C: <... message ...>
C: .
S: 250 message accepted; use STAT to query delivery
C: STAT <masinter@parc.xerox.com>
S: 250 <masinter@parc.xerox.com> 0;88991;88991;0 completed
C: STAT <njoffe@cisco.com>
S: 250 <njoffe@cisco.com> 3;5613;88991;10 still sending data
C: STAT <njoffe@cisco.com>
S: 250 <njoffe@cisco.com> 0;88991;88991;12 completed
C: QUIT
S: 221 Goodbye
6.1.2. Two recipients, one doesn't support SESSION
S: 220 foo.cisco.com ESMTP service ready
C: EHLO pc.cisco.com
S: 250-foo.cisco.com says hello
S: 250 SESSION
C: MAIL FROM:<dwing@cisco.com>
S: 250 <dwing@cisco.com> Sender ok
C: RCPT TO:<masinter@parc.xerox.com> SESSION
S: 250 <masinter@parc.xerox.com> and options ok
C: RCPT TO:<njoffe@cisco.com> SESSION
Wing, Joffe, Masinter Expires February 1998 [Page 7]
Internet Draft Immediate Delivery over ESMTP August 1997
S: 251 <njoffe@cisco.com> and options ok; non-SESSION intermediate MTA
C: DATA
S: 354 Enter your data
C: <... message ...>
C: .
S: 250 message accepted; use STAT to query delivery
C: STAT <masinter@parc.xerox.com>
S: 250 <masinter@parc.xerox.com> 0;891;891;0 completed
C: STAT <njoffe@cisco.com>
S: 251 <njoffe@cisco.com> 0;891;891;0 store and forward at gw.cisco.com
C: QUIT
S: 221 Goodbye
6.2. SESSION with insufficient resources
The client attempts a SESSION delivery, but the ESMTP server has
exceeded its maximum simultaneous Session delivery limit. The ESMTP
client responds by requesting a normal (store-and-forward) delivery for
the same recipient, which is accepted by the ESMTP server.
S: 220 foo.cisco.com ESMTP service ready
C: EHLO pc.cisco.com
S: 250-foo.cisco.com says hello
S: 250 SESSION
C: MAIL FROM:<dwing@cisco.com>
S: 250 <dwing@cisco.com> Sender ok
C: RCPT TO:<masinter@parc.xerox.com> SESSION
S: 450 <masinter@parc.xerox.com> try later - exceeded maximum Session count
C: RCPT TO:<masinter@parc.xerox.com>
S: 250 <masinter@parc.xerox.com> Recipient ok
C: DATA
S: 354 Enter your data
C: <... message ...>
C: .
S: 250 message accepted
C: QUIT
S: 221 Goodbye
6.3. SESSION-only ESMTP servers that cannot store and forward mail
6.3.1. Successful transmission (one recipient)
S: 220 gizmo.cisco.com FAX offramp ESMTP server ready
C: HELO sendmail.cisco.com
S: 250 gizmo.cisco.com; Hi there, sendmail.cisco.com
Wing, Joffe, Masinter Expires February 1998 [Page 8]
Internet Draft Immediate Delivery over ESMTP August 1997
C: MAIL FROM:<dwing@cisco.com>
S: 250 <dwing@cisco.com> Sender ok
C: RCPT TO:<+14084575208@gizmo.cisco.com>
S: 250 <+14084575208@gizmo.cisco.com> Okay
C: DATA
S: 354 Enter your data
C: <... message ...>
C: .
(SMTP server doesn't respond until delivery to
<+14084575208@gizmo.cisco.com> is complete)
S: 250 successful delivery to <+14084575208@gizmo.cisco.com>
C: QUIT
S: 221 Goodbye
6.3.2. ESMTP server cannot relay mail
S: 220 gizmo.cisco.com FAX offramp ESMTP server ready
C: HELO sendmail.cisco.com
S: 250 gizmo.cisco.com; Hi there, sendmail.cisco.com
C: MAIL FROM:<dwing@cisco.com>
S: 250 <dwing@cisco.com> Sender ok
C: RCPT TO:<+14084575208@gw.xerox.com>
S: 550 <+14084575208@gw.xerox.com> relaying not permitted
C: QUIT
S: 221 Goodbye
6.3.3. Only one recipient allowed
S: 220 gizmo.cisco.com FAX offramp ESMTP server ready
C: HELO sendmail.cisco.com
S: 250 gizmo.cisco.com; Hi there, sendmail.cisco.com
C: MAIL FROM:<dwing@cisco.com>
S: 250 <dwing@cisco.com> Sender ok
C: RCPT TO:<+14084575208@gizmo.cisco.com>
S: 250 <+14084575208@gizmo.cisco.com> Okay
C: RCPT TO:<+14158124333@gizmo.xerox.com>
S: 450 <+14158124333@gizmo.xerox.com> Try again later
C: DATA
S: 354 Enter your data
C: <... message ...>
C: .
(SMTP server doesn't respond until fax is delivered)
S: 250 fax delivered to <+14084575208@gizmo.cisco.com>
C: QUIT
S: 221 Goodbye
Wing, Joffe, Masinter Expires February 1998 [Page 9]
Internet Draft Immediate Delivery over ESMTP August 1997
The SMTP client would be responsible for retrying
<+14158124333@gizmo.xerox.com> per its normal retry interval.
7. Security Considerations
Denial of service attacks are possible with SESSION. [%% more verbage]
8. Implementation notes
8.1. ESMTP server response to STAT
To prevent excessive network activity by an ESMTP client querying
the status of a forward-path "too often", the ESMTP server may
delay responding to a client's STAT command. Such a delay should
not exceed 10 seconds or any previously indicated <cmpl-seconds>.
8.2. SESSION and PIPELINING
Due to the delays inherent with establishing connections with each
MTA in the ESMTP path, ESMTP servers that implement SESSION SHOULD also
implement [PIPELINING].
8.3. ESMTP client pipelining STAT commands
The ESMTP client may use [PIPELINING] for its STAT commands. The group
of STAT commands for each of the forward-paths in this transaction may
be considered a pipelined command group. The ESMTP client should wait
for the response to the last STAT for that pipelined command group
before sending other commands.
9. Acknowledgments
Much of this document was produced by work begun in the Internet FAX
Working Group of the IETF.
The authors would like to thank Graham Klyne (Integralis Ltd.) for his
contributions to this work.
10. References
[ABNF]
Wing, Joffe, Masinter Expires February 1998 [Page 10]
Internet Draft Immediate Delivery over ESMTP August 1997
D. Crocker, P. Overell, "Augmented BNF for Syntax Specifications:
ABNF", Internet Draft, Work in Progress,
draft-ietf-drums-abnf-03.txt, July 1997.
[CHUNKING]
G. Vaudreuil, "SMTP Service Extensions for Transmission of Large
and Binary MIME Messages", RFC 1830 (Experimental), August 1995.
[DSN]
K. Moore, "SMTP Service Extension for Delivery Status
Notifications", RFC 1891, January 1996.
[ENH-RET]
N. Freed, "SMTP Service Extension for Returning Enhanced Error
Codes", RFC 2034, October 1996.
[PIPELINING]
N. Freed, A. Cargille, "SMTP Service Extension for Command
Pipelining", RFC 1854, October 1995.
N. Freed, "SMTP Service Extension for Command Pipelining",
Internet Draft, Work in Progress,
draft-freed-smtp-pipeline-02.txt, July 1997.
[REQ]
S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", BCP-14, RFC 2119, March 1997.
[RFC821]
J. Postel, "Simple Mail Transfer Protocol", STD-10, RFC 821,
August 1982.
[RFC822]
D. Crocker, "Standard for the Format of ARPA Internet Text
Messages", STD-11, RFC 822, August 1982.
[SMTP-EXT]
J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, "SMTP
Service Extensions", STD-10, RFC 1869, November 1995.
11. Authors' Addresses
Dan Wing
Cisco Systems, Inc.
101 Cooper Street
Santa Cruz, CA 95060 USA
Wing, Joffe, Masinter Expires February 1998 [Page 11]
Internet Draft Immediate Delivery over ESMTP August 1997
Phone: +1 408 457 5200
Fax: +1 408 457 5208
EMail: dwing@cisco.com
Neil Joffe
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706 USA
Phone: +1 408 526 4000
Email: njoffe@cisco.com
Larry Masinter
Xerox Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, CA 94304 USA
Phone: +1 415 812 4365
Fax: +1 415 812 4333
EMail: masinter@parc.xerox.com
X1. Notes and unresolved issues
X1.1. More verbage needed for security section
X1.2. RFC1123 timeouts may cause problems (5 minutes to the third
MTA hop is greater than 5 minutes for the first MTA hop, so
first MTA hop could timeout)
X1.3. Add example showing DSN in conjunction with SESSION
Wing, Joffe, Masinter Expires February 1998 [Page 12]
