Individual E. Burger
Internet-Draft Brooktrout Technology, Inc.
Expires: February 24, 2005 August 26, 2004
SMTP Service Extension for Detached Operation
draft-burger-smtp-deta-00
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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.
This Internet-Draft will expire on February 24, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
The normal operation for the Simple Mail Transfer Protocol (SMTP) is
for the submitting device to wait for all processing to complete and
for the server to return a positive acknowledgement to the client.
However, some devices have very intermittent connectivity, such as
wireless mobile terminals. For such devices, a means to have
processing continue in the case of a dropped connection is desirable.
To this end, this SMTP service extension enables a client to submit a
message and reliably detach from the session, indicating to the
Burger Expires February 24, 2005 [Page 1]
Internet-Draft SMTP DETA August 2004
server to continue in the absence of a connection to the client.
Conventions used in this document
RFC2119 [1] provides the interpretations for the key words "MUST",
"MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" found in this document.
Table of Contents
1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3
2. Formal Description of the Extension . . . . . . . . . . . . . 3
2.1 Extension Definition . . . . . . . . . . . . . . . . . . . 3
2.2 Extension Operation . . . . . . . . . . . . . . . . . . . 4
2.2.1 Server Behavior . . . . . . . . . . . . . . . . . . . 4
2.2.2 Client Behavior . . . . . . . . . . . . . . . . . . . 4
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1 Detached Submit . . . . . . . . . . . . . . . . . . . . . 5
4.2 Piplined Submit . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1 Normative References . . . . . . . . . . . . . . . . . . . . 7
6.2 Informative References . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . 9
Burger Expires February 24, 2005 [Page 2]
Internet-Draft SMTP DETA August 2004
1. Introduction and Overview
There is a class of SMTP [2] clients that have intermittent IP
connectivity. This is a particular problem for devices that wish to
submit objects that have a long processing time requirement at the
server. For example, the object may have be physically large or have
a large number of recipients, both of which may result in a
relatively long processing time at the server.
The RDLV [3] SMTP service extension provides a mechanism for servers
to periodically inform a client that processing on a long delivery
item is in progress. This mechanism periodically emits 120 responses
to the client, to which the client issues the CONT verb to tell the
server that the client is still alive and the server should continue
processing the message.
The Detached Operation SMTP service extension builds upon the RDLV
mechanism, adding the DETA verb as an answer to the 120 response.
When the server receives the DETA verb, it terminates the connection
to the client yet continues processing the message.
This enables the client to definitively know the server has begun
working on the message. Likewise, it lets the server definitively
know the client is aware the server is working on the message.
Of course, the client will not know the immediate disposition of the
message. In particular, the client will not know if the message
submission succeeded. To address this problem, the server has to
support the message disposition notification service extension [6].
If the client needs to know if the submission fails, the client asks
for a DSN. The server issues a DSN in the event of submission
failure, per the rules of RFC3464.
2. Formal Description of the Extension
2.1 Extension Definition
1. The text name of this SMTP service extension is DETA.
2. The EHLO keyword associated with this SMTP service extension is
DETA.
3. The DETA keyword has no parameters.
4. This document defines a new SMTP verb, DETA. The DETA verb
indicates that the server terminates the current session yet
continues the in-process command execution.
5. Servers implementing the Detached Operation SMTP service
extension MUST also support and advertise the following
extensions in addition to other extensions in their EHLO response
the RDLV [3] and DSN [4] service extensions.
Burger Expires February 24, 2005 [Page 3]
Internet-Draft SMTP DETA August 2004
6. This SMTP service extension does not introduce any new parameters
to existing SMTP verbs.
2.2 Extension Operation
2.2.1 Server Behavior
Servers implementing this specification MUST support the RDLV [3] and
DSN [4] SMTP service extensions. Servers MUST advertise RDLV, DSN,
and DETA in their EHLO response.
Upon receiving a RDLV verb followed by another verb, the server MAY
issue a 120 response, per RDLV [3].
Instead of receiving a CONT verb from the client, the server may
receive a DETA verb from the client. In this case, the server MUST
continue processing the request. In addition, the server MUST issue
a 221 response and close the connection, as if it received a QUIT
verb.
DISCUSSION POINT: An alternative to having the server shut down
the session is to let the session continue, so the client could do
other SMTP stuff while the server processes the message. However,
this raises a few problems. The biggest one is the slippery slope
of clients wanting asynchronous notification of submission
completion. If we can punt that issue, then I do not have a
problem with allowing it. Input from server developers
appreciated here.
If the client requested a DSN, and the server is unable to complete
processing the request, the server MUST issue a DSN following the
procedures of RFC3461.
2.2.2 Client Behavior
The client issues a RDLV verb before issuing the submission verb.
This enables the server to return control to an in-process command to
the client. The client then issues the submission verb. When the
server responds with a 120 response after the timeout, the client MAY
issue the DETA verb to instruct the server to continue processing and
detach the session.
The client SHOULD request a DSN so the user can know if the
submission succeeded.
The client MAY use command pipelining [5] if supported and advertised
by the server.
Burger Expires February 24, 2005 [Page 4]
Internet-Draft SMTP DETA August 2004
3. IANA Considerations
Please register the DETA service extension in the Simple Mail
Transfer Protocol (SMTP) Service Extensions table as follows.
Service Extension
Keyword: DETA
Description: Detached Operation
Reference: RFCXXXX
Extension Parameters: none
4. Examples
These examples are informative in nature. For any discrepancies
between behavior here and the normative behavior, the normative
behavior is correct.
4.1 Detached Submit
The client submits a message using BURL [7] and detaches from the
session.
Burger Expires February 24, 2005 [Page 5]
Internet-Draft SMTP DETA August 2004
S: 220 example.net SMTP XYZ Ready
C: EHLO example.com
S: 250-example.net greets example.com
S: 250-8BITMIME
S: 250-BURL imap
S: 250-RDLV mintimer=30
S: 250-DETA
S: 250-DSN
S: 250 HELP
C: MAIL FROM:<smith@example.com>
S: 250 OK
C: RCPT TO:<jones@example.net>
S: 250 OK
C: RDLV maxtimer=30
S: 200 OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: [... lots and lots of data ...]
C: .
[about 30 seconds pass]
S: 120 DATA processing in progress
C: DETA
S: 221 example.net Service closing transmission channel
4.2 Piplined Submit
A client can pipeline the submission commands.
Burger Expires February 24, 2005 [Page 6]
Internet-Draft SMTP DETA August 2004
S: 220 example.net SMTP XYZ Ready
C: EHLO example.com
S: 250-example.net greets example.com
S: 250-8BITMIME
S: 250-PIPELINING
S: 250-BURL imap
S: 250-RDLV mintimer=30
S: 250-DSN
S: 250 HELP
C: MAIL FROM:<handset@example.com> RET=HDRS ENV=A123bzq
C: RCPT TO:<jones@example.net> NOTIFY=FAILURE
ORCPT=rfc822;jones@example.com
C: RDLV maxtimer=30
C: BURL imap://handset@host.example.com/outbox
;uidvalidity=a9j230r932/;uid=32
;authid=fred;urlauth=submit+handset
:internal:91354a473744909de610943775f92038 LAST
S: 250 sender <handset@example.com> OK
S: 250 recipient <jones@example.net> OK
S: 200 reliable delivery OK
[about 30 seconds passes]
S: 120 DATA processing in progress
C: DETA
S: 221 example.net Service closing transmission channel
5. Security Considerations
Malicious clients can amplify server load by issuing a large number
of detached requests. Servers SHOULD implement reasonable policies
to limit the number of concurrent submissions on behalf of a given
sender.
6. References
6.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April
2001.
[3] Burger, E., "SMTP Service Extension for Reliable Submission",
August 2004.
[4] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
Extension for Delivery Status Notifications (DSNs)", RFC 3461,
Burger Expires February 24, 2005 [Page 7]
Internet-Draft SMTP DETA August 2004
January 2003.
[5] Freed, N., "SMTP Service Extension for Command Pipelining", STD
60, RFC 2920, September 2000.
6.2 Informative References
[6] Moore, K. and G. Vaudreuil, "An Extensible Message Format for
Delivery Status Notifications", RFC 3464, January 2003.
[7] Newman, C., "Message Submission BURL Extension", Internet Draft
draft-ietf-lemonade-burl-00.txt, July 2004.
Author's Address
Eric Burger
Brooktrout Technology, Inc.
18 Keewaydin Dr.
Salem, NH 03079
USA
EMail: e.burger@ieee.org
Burger Expires February 24, 2005 [Page 8]
Internet-Draft SMTP DETA August 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Burger Expires February 24, 2005 [Page 9]
Internet-Draft SMTP DETA August 2004
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Burger Expires February 24, 2005 [Page 10]