Applications Area Neil Joffe
Internet Draft Dan Wing
February 23, 1997 Cisco Systems
Expires August 1998 Larry Masinter
Xerox Corporation
SMTP Service Extension for
Immediate Delivery
draft-ietf-fax-smtp-session-02.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), ftp.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
NOTE: although this work has been discussed in the IETF-FAX
working group, it does not purport to represent the
consensus of the group.
Copyright Notice
Copyright (C) The Internet Society (1997, 1998). All Rights
Reserved.
Abstract
This memo defines an extension to SMTP which provides a mechanism for
requesting immediate message delivery over SMTP instead of store-
and-forward. It also provides a mechanism for querying the
SMTP server if immediate delivery was successful, is still in
progress, or was simply queued as a normal store-and-forward message.
Joffe, Wing, Masinter Expires August 1998 [Page 1]
Internet Draft SMTP Immediate Delivery February 1998
Table of Contents
0. Administrivia
0.1. Changes Since Previous Versions
1. Introduction
1.2. Discussion of This Draft
1.3. Requirements Notation
2. Framework for Immediate Delivery Support
3. Esmtp-keyword SESSION
3.1. Delivery Responsibility
3.2. Fallback to Store and Forward
3.2.1. Non-Session Aware Mailers
3.2.1. Excessive Delays with Multiple MTAs
3.3. Sequence of Events and State Diagrams
3.3.1. Events - Single Remote MTA
3.3.2. Events - Multiple Remote MTAs
3.3.3. State Diagram - SMTP client
3.3.4. State Diagram - SMTP Server
3.3.5. State diagram - MTA relay
4. New SMTP Verb STAT
4.1. Format of STAT Response
4.2. Sequence of Events
4.3. Timing Considerations
5. Security Considerations
5.1. Denial of Service
5.2. Abuse of Immediate Delivery
6. Examples
6.1. Successful Session Delivery to Two Recipients
6.2. Unsuccessful Session Delivery
6.3. SMTP Client Disconnects Before Sending STAT
7. Acknowledgments
8. References
9. Copyright
10. Authors' Addresses
0. Administrivia
0.1. Changes Since Previous Versions
Changes from draft-ietf-fax-smtp-session-01.txt to -02:
* Added sequence of events and state diagram sections
to clarify timing and responsibility issues.
* Server's reply to STAT is now a simple codes instead
of a multipart/report.
* STAT command polls for all recipients that had SESSION
Joffe, Wing, Masinter Expires August 1998 [Page 2]
Internet Draft SMTP Immediate Delivery February 1998
on the RCPT command.
Changes from draft-ietf-fax-smtp-session-00.txt to -01:
* Added copyright notice
* Reference to [FAX-DSN].
Changes from draft-wing-smtp-session-00 to
draft-ietf-fax-smtp-session-00.txt:
* Server's reply to STAT is now a complete multipart/report
* Language clarifications
* Require immediate SMTP server reply after client sends "."
* Specify SMTP server must respond to STAT within 30 seconds
1. Introduction
Historically, SMTP [SMTP] has been used for store and forward
delivery of messages. This memo describes a new SMTP extension
called SESSION. This new extension allows an SMTP client to request
immediate delivery by the SMTP server.
This Session extension was motivated by an analysis of the
requirements for using the Internet to deliver fax messages, and,
coupled with a mechanism for exchanging capabilities and preferences
of sender and recipient, can be used by email<->fax gateway
applications. In addition, the SESSION extension may be useful for
other messaging applications where immediate delivery and
confirmation of immediate delivery are requested.
The LMTP protocol [LMTP] provides immediate delivery, but as
discussed in [LMTP] can aggrevate the duplicate message delivery
problem [DUPLICATE], especially over a WAN. The Session extension
described in this memo is intended to provide immediate delivery
of SMTP messages while avoiding aggrevating the duplicate
message delivery problem.
This extension presumes either a direct connection between sender and
recipient or a chain of session-enabled servers in which each
supports this Session extension.
If an MTA in the SMTP "path" does not support Session, delivery
automatically falls back to normal store and forward, and such
fallback is communicated to the SMTP client, as described in section
Joffe, Wing, Masinter Expires August 1998 [Page 3]
Internet Draft SMTP Immediate Delivery February 1998
3.2.
Unlike the deprecated SAML, SOML and SEND commands (documented in
[SMTP] and deprecated in [DRUMS]) the SESSION extension allows for a
mix of immediate and store & forward delivery recipients.
This memo uses the mechanism described in [SMTP-EXT] to define an
extension to the SMTP protocol for immediate delivery.
1.2. 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.
1.3. Requirements Notation
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 [REQ].
2. 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 determine if immediate
delivery was successful) is defined with this extension, and
is described in section 3;
(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 maximum length of a RCPT TO is increased by 8
characters.
3. Esmtp-keyword SESSION
Upon receiving a RCPT command with the esmtp-keyword SESSION, a
Joffe, Wing, Masinter Expires August 1998 [Page 4]
Internet Draft SMTP Immediate Delivery February 1998
session-enabled server will normally send either a positive (2xx) or
negative (5xx) reply to the SMTP client.
A 250 reply code indicates that the session-enabled server believes
the message will be sent immediately -- that is, that the request for
SESSION delivery will be honored.
If a session-enabled server is aware that it will be unable to
send the message immediately (that is, the request for SESSION will
not be honored), but the session-enabled server is willing to send
the message via its normal SMTP queue, it SHOULD respond with a 252
reply code. The SMTP client can use this information to inform the
user that immediate delivery isn't available, and the SMTP client (or
the user) may decide on a different transmission mechanism.
3.1. Delivery Responsibility
As per normal SMTP, once a sender has received a positive response to
its end of mail data indicator, the receiver has accepted all
responsibility for message delivery.
If an MTA is relaying a message using this Session extension,
and it fails to receive a positive response to its end of mail data
indicator from the next-hop mailer, the Session-enabled MTA MUST
queue the message as a normal SMTP store-and-forward message for
later delivery. This is because the MTA performing the relaying
accepted responsibility for message delivery at this point. See
the section "Sequence of Events" for details.
3.2. Fallback to Store and Forward
This section describes scenarios which would cause immediate delivery
to fallback to normal store-and-forward delivery.
3.2.1. Non-Session Aware Mailers
If an MTA is encountered which does not support the Session
extension, the MTA which detected this SHOULD respond with a 252
response code, and this MTA is responsible for performing normal
store-and-forward mail delivery to the non-Session aware mailer.
3.2.1. Excessive Delays with Multiple MTAs
The cumulative delays of going through many MTAs will cause Session
delivery to fail (by falling back to normal store-and-forward).
Proper configuration and deployment of SMTP servers will prevent this
problem.
Joffe, Wing, Masinter Expires August 1998 [Page 5]
Internet Draft SMTP Immediate Delivery February 1998
Implementors must carefully design session-enabled MTAs to respond
quickly when Session recipients are present to minimize timing
problems. Each MTA is maintaining its own SMTP timeouts
which can't be exceeded by the entire end-to-end delay [RFC1123].
Additionally, Session is not expected to work reliably across
lossy links or with overloaded mailers.
3.3. Sequence of Events and State Diagrams
This section describes the sequence of events for a RCPT command
that contains the esmtp-keyword SESSION, and also includes
State Diagrams for various components.
3.3.1. Events - Single Remote MTA
If the RCPT command contains the esmtp-keyword SESSION, the
SMTP server SHOULD connect to the next-hop mailer prior to
responding to the SMTP client's RCPT command.
+-----+ +--------+ +-------+ +-----------+
| user| => |Original| ==> | MTA-1 | => | receiving | user@host-x
|agent| | MTA | | | | MTA-1 |
+-----+ +--------+ +-------+ +-----------+
(A) (B) (C) (D)
Using the above diagram:
1. the SMTP client (A) would initiate an SMTP transaction with
(B), and send a RCPT command with the esmtp-keyword SESSION to
(B), then
2. (B) would initiate an SMTP transaction with (C) and send the
same RCPT command with the esmtp-keyword SESSION to (C), then
3. (C) would initiate an SMTP transaction with (D) and send the
same RCPT command with the esmtp-keyword to (D), then
4. (D) would send its response to (C), which would send the
response to (B), which would send the response to (A), then
5. (A) would send its next RCPT command (if sending to
multiple recipients), then
6. (A) would indicate it wants to send the message body by
sending the DATA (or BDAT if using [CHUNKING]) command, then
7. (B) would send the DATA (or BDAT) command to (C),
Joffe, Wing, Masinter Expires August 1998 [Page 6]
Internet Draft SMTP Immediate Delivery February 1998
which would send it to (D), which would send its response
code to (C), which is sent to (B), which is sent to
(A), then
8. (A) sends its message body to (B), which SHOULD spool
it to a local disk while sending it to (C), which SHOULD
spool it to a local disk while sending it to (D), which
writes it to the local user's mailstore.
9. (A) sends its end of mail data indicator ("." unless using
[CHUNKING]), then
10. (B) responds to the end of mail data indicator immediately
(and is now responsible for message delivery should it
fail after this point), then (B) sends the end of mail data
indicator to (C), then
11. (C) responds to the end of mail data indicator
immediately (and is now responsible for message delivery
should it fail after this point), then (C) sends the end of
mail data indicator to (D)
12. (D) responds to the end of mail data indicator when it has
finished writing to the user's mailbox.
If there are multiple local recipients and one or more
recipients succeeded, but at least one failed, (D) must issue
a postive response code to prevent duplicate message delivery
[DUPLICATE]. It MUST generate a bounce message for the failed
local recipient(s), and the bounce SHOULD be in the format
of a DSN [DSN].
3.3.2. Events - Multiple Remote MTAs
In the case where there are multiple remote MTAs is a more complex
case than described above, but the same rules apply.
+-----------+
-=> | receiving | user@host-x
/ | MTA-1 |
+-----+ +--------+ / +-----------+
| user| => |Original| =< (C)
|agent| | MTA | \
+-----+ +--------+ \ +-----------+
(A) (B) -=> | receiving | user@host-y
| MTA-2 |
+-----------+
(D)
Joffe, Wing, Masinter Expires August 1998 [Page 7]
Internet Draft SMTP Immediate Delivery February 1998
(B) would have to send the appropriate RCPT command with the
esmtp-keyword SESSION, the appropriate next-hop MTA (C or D) for each
recipient (user@host-x, user@host-y) and echo the responses back to
(A).
When (A) sends its DATA command, (B) would have to send the DATA
command to both MTAs, and reply to (A) if both MTAs have responded
positively.
When (A) sends its end of mail data indicator, (B) must respond
immediately, and then (B) can send the end of mail data indicator
to (C) and (D).
If (B) does not receive a positive (2xx) response from (C) or (D),
(B) must queue the message as a normal store and forward message.
XXX - is all this obvious, or should we describe it?
3.3.3. State Diagram - SMTP client
XXX
3.3.4. State Diagram - SMTP Server
XXX
3.3.5. State diagram - MTA relay
The following state diagram describes the behavior of an MTA relaying
Session connection.
|
V (1)
+---------+ (2) +---------+
| Setup |------>| Connect |
| message |<------| forward |
+---------+ (3) +---------+
|
V (4)
+---------+ (5) +---------+ (6) +---------+ (7) +--------+
| Sending |---->| Waiting |---->| Gather |---->| Query |
| data | | |<----| status |<----| status |
+---------+ +---------+ (9) +---------+ (8) +--------+
|
V (10)
+----------+
| Complete |
+----------+
Joffe, Wing, Masinter Expires August 1998 [Page 8]
Internet Draft SMTP Immediate Delivery February 1998
(1) Event: Incoming MAIL FROM.
Test: -
Action: Prepare to forward message.
(2) Event: incoming RCPT TO
Test:
Action: IF connection to next-hop server for this message does
not already exist then create connection and issue MAIL
FROM command. Issue RCPT TO command to next-hop
server.
(3) Event: Response to RCPT TO command.
Test: -
Action: Respond to incoming RCPT TO.
(4) Event: Incoming DATA/BDAT.
Test: -
Action: Issue DATA/BDAT on forward connections, and
forward data as it is received.
(5) Event: End of data, with confirmation from all downstream MTAs
Test: -
Action: Wait
(6) Event: Incoming STAT command.
Test: -
Action: Start gathering status - straight to (7)
(7) Event: -
Test: There are more downstream MTAs to query.
Action: Issue STAT command on next downstream MTA.
(8) Event: Response to STAT command.
Test: -
Action: Pass back as response to incoming STAT. If status
indicates completion then close the downstream
connection.
(9) Event: -
Test: There are no more downstream MTAs to query.
Action: Wait.
(10) Event: Incoming RSET, MAIL FROM or SMTP connection broken.
Test: -
Action: Close any remaining downstream connections.
4. New SMTP Verb STAT
Joffe, Wing, Masinter Expires August 1998 [Page 9]
Internet Draft SMTP Immediate Delivery February 1998
One new SMTP verb is introduced with this extension. The STAT verb
causes the SMTP server to respond with the Session delivery status of
all Session recipients.
An SMTP client MAY send the STAT command if it used the esmtp-keyword
SESSION on one of its RCPT commands, but the SMTP client is not
required to use the STAT verb. SMTP servers which implement the
SESSION extension MUST implement the STAT verb.
The SMTP client MUST NOT send the STAT command unless all of the
following are true: (1) the SMTP client sent a RCPT command with the
esmtp-keyword SESSION; (2) the SMTP server sent a positive response to
that RCPT command; (3) the SMTP client has finished sending the
message body and sent the end of mail data indicator ("."). If
the SMTP client sends the STAT command when not all of the above
conditions are met, the SMTP server MUST send a response code
of 503.
The syntax of the STAT verb, using the notation described in [ABNF],
is:
stat-cmd = "STAT" CR LF
4.1. Format of STAT Response
The SMTP server's is making a positive response to the STAT command
is a multiline SMTP response. Each line contains information on each
Session recipient, in the order specified by the SMTP client.
If the SMTP server is making a negative response to the STAT command
the response should be a 5xx response code and follow the normal
SMTP rules for multiple line responses. There is no specific
format of 5xx responses.
The syntax of the positive response must be parsable by an SMTP
client. Using the notation described in [ABNF], the syntax is:
stat-response = *( "250-" [status-code SP] resp-line CR LF )
"250 " [status-code SP] resp-line CR LF
resp-line = forward-path SP session-status
[SP "by" SP mta-hostname]
session-status = "delivered" /
"in-progress" SP prog-value /
"queued"
prog-value = sent-count "/" total-count
Joffe, Wing, Masinter Expires August 1998 [Page 10]
Internet Draft SMTP Immediate Delivery February 1998
sent-count = 1*DIGIT
total-count = 1*DIGIT
mta-hostname = *( ALPHA / DIGIT / "." / "-" / "_" )
trans-id = *( ALPHA / DIGIT / "." / "-" / "_" )
status-code = <as defined in [SMTP-ENH-ERR]>
forward-path = <forward-path as specified in the RCPT command,
including "<" and ">" characters>
The <session-status> can be spelled in any combination of uppercase
and lowercase letters. The meaning of the various values are
as follows:
"delivered" Session delivery was successful. Message was
delivered to the recipient immediately. This is a
terminal value.
"in-progress" Session delivery has not yet completed. A STAT
command issued later will show final status of this
message. This is the only non-terminal value.
"queued" Session delivery failed for some reason, but the MTA
was able to successfully queue the message using
normal SMTP store-and-forward. One cause of this
status is when the session-enabled server forwards the
message to a non-session-enabled server. This is a
terminal value.
The two values of the <prog-value> element can be page numbers, byte
counts, disk blocks, or any other useful count of the progress of
this transaction, as determined by the SMTP server. The values
can be displayed by the MUA to the user as-is, or the MUA can use the
values to calculate the percentage of completion for presentation
to the user.
If an SMTP client sends a STAT command and the SMTP server has
already informed the SMTP client (in the response to a previous
STAT command) that all recipients had a terminal values, the SMTP
server MAY return a 503 reply.
4.2. Sequence of Events
The STAT command has a similar sequence of events as described
in section 3.3, above.
Joffe, Wing, Masinter Expires August 1998 [Page 11]
Internet Draft SMTP Immediate Delivery February 1998
XXX - we should probably describe behavior of STAT in more
detail
Note that the STAT command can only be issued in the same
SMTP transaction. There is no provision for an SMTP client to
start a new SMTP transaction and query the status of Session
delivery for a previous SMTP transaction.
4.3. Timing Considerations
The SMTP server SHOULD respond to a STAT command no later than 60
seconds after a STAT command is received. After 120 seconds an SMTP
client MAY assume the connection to the SMTP server is broken.
To prevent excessive network activity by an SMTP client querying
delivery status "too often", the SMTP server may delay responding to
a client's STAT command. Such a delay MUST NOT exceed 10 seconds.
Due to the delays inherent with establishing connections with each
MTA in the SMTP "path", SMTP servers that implement the Session
extension SHOULD also implement [SMTP-PIPE], and SMTP clients
SHOULD use pipelining if available.
5. Security Considerations
This section describes new security vulnerabilities that are
introduced with this SMTP extension. Security vulnerabilities
that are inherient to SMTP itself are not described.
5.1. Denial of Service
As Session consumes more resources on MTAs, denial of service attacks
against MTAs may be more effective.
XXX - more verbage
5.2. Abuse of Immediate Delivery
This is some concern that users will always choose the 'deliver
immediately' button or mailer option in their MUA. As immediate
delivery requires more resources on MTAs, this is indeed a
concern.
To alleviate such concerns, ISPs could charge extra for immediate
delivery involving their mailers, offering immediate delivery
as a value-add service, not accept Session messages during periods of
high usage, or limit the total number of Session connections or
Joffe, Wing, Masinter Expires August 1998 [Page 12]
Internet Draft SMTP Immediate Delivery February 1998
the number of Session connections to/from certain hosts or
domains.
6. Examples
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively. If such lines are wrapped without a new "C:" or
"S:" label, then the wrapping is for editorial clarity and is not
part of the command.
6.1. Successful Session Delivery to Two Recipients
This example shows a successful Session delivery with two recipients.
The first recipient, masinter@parc.xerox.com, was still being queued
when the first STAT command was sent by the client, but a subsequent
STAT command shows the final status.
S: 220 mailer.cisco.com ESMTP service ready
C: EHLO pc.cisco.com
S: 250-mailer.cisco.com says hello
S: 250 SESSION
C: MAIL FROM:<dwing@cisco.com>
S: 250 <dwing@cisco.com> Sender ok
C: RCPT TO:<bill@fuggles.com> SESSION
S: 250 <bill@fuggles.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: From: Dan Wing <dwing@cisco.com>
C: To: njoffe@cisco.com, bill@fuggles.com
C: Date: Mon, 6 Oct 1997 12:42:32 -0700
C: Subject: Palo Alto Coffee shops
C:
C: What is a good coffee shop in Palo Alto?
C: .
S: 250 message accepted
C: STAT
S: 250-<bill@fuggles.com> in-progress by fwall.cisco.com 5/184
S: 250 <njoffe@cisco.com> delivered by popstore.cisco.com 184/184
C: STAT
S: 250-<bill@fuggles.com> delivered by popmusic.xerox.com 184/184
S: 250 <njoffe@cisco.com> delivered by popstore.cisco.com 184/184
C: QUIT
S: 221 Goodbye
6.2. Unsuccessful Session Delivery
Joffe, Wing, Masinter Expires August 1998 [Page 13]
Internet Draft SMTP Immediate Delivery February 1998
This example shows the client wanted to send the message
immediately, and the server responded with a "250" (indicating
it believed the message could be sent immediately), but a problem
occurred forcing the mailer at pea.com to deliver the message
using store-and-forward.
S: 220 mailer.cisco.com ESMTP service ready
C: EHLO pc.cisco.com
S: 250-mailer.cisco.com says hello
S: 250 SESSION
C: MAIL FROM:<dwing@cisco.com>
S: 250 <dwing@cisco.com> Sender ok
C: RCPT TO:<greengiant@peas.com> SESSION
S: 250 <greengiant@peas.com> and options ok
C: DATA
S: 354 Enter your data
C: From: Dan Wing <dwing@cisco.com>
C: To: "Jolly" <greengiant@peas.com>
C: Date: Mon, 6 Oct 1997 12:42:32 -0700
C: Subject: Veggies
C:
C: Veggies are good for you, but from a can?
C: .
S: 250 message accepted
C: STAT
S: 250 <greengiant@peas.com> queued by pea.com 158/158
C: QUIT
S: 221 Goodbye
6.3. SMTP Client Disconnects Before Sending STAT
The SMTP client is not required to query the success/failure
of immediate message delivery. The following transaction
is legal.
S: 220 mailer.cisco.com ESMTP service ready
C: EHLO pc.cisco.com
S: 250-mailer.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: DATA
S: 354 Enter your data
C: From: Dan Wing <dwing@cisco.com>
C: To: masinter@parc.xerox.com
Joffe, Wing, Masinter Expires August 1998 [Page 14]
Internet Draft SMTP Immediate Delivery February 1998
C: Date: Mon, 6 Oct 1997 12:42:32 -0700
C: Subject: Palo Alto Coffee shops
C:
C: How does this look?
C: .
S: 250 message accepted
C: QUIT
S: 221 Goodbye
7. 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 Ned Freed (Innosoft), Graham Klyne
(Integralis), Keith Moore (University of Tennessee), and Greg
Vaudreuil (Lucent) for their contributions to this work.
8. References
[ABNF] D. Crocker, P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[CHUNKING] G. Vaudreuil, "SMTP Service Extensions for Transmission of
Large and Binary MIME Messages", RFC 1830 (Experimental), August
1995.
[DSN] K. Moore, G. Vaudreuil, "An Extensible Message Format for
Delivery Status Notifications", RFC 1894, January 1996.
[DRUMS] J. Klensin, D. Mann, "Simple Mail Transfer Protocol",
Internet Draft, Work in Progress, draft-ietf-drums-smtpupd-??.txt.
[DUPLICATE] C. Partridge, "DUPLICATE MESSAGES AND SMTP", RFC 1047,
February 1988.
[] J. Palme, "Common Internet Message Headers", RFC 2076,
February 1997.
[LMTP] J. Myers, "Local Mail Transfer Protocol", RFC 2033, October
1996.
[REQ] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", BCP-14, RFC 2119, March 1997.
[RFC1123] R. Braden, "Requirements for Internet Hosts -- Application
and Support", RFC 1123, October 1989.
Joffe, Wing, Masinter Expires August 1998 [Page 15]
Internet Draft SMTP Immediate Delivery February 1998
[SMTP] J. Postel, "Simple Mail Transfer Protocol", STD-10, RFC 821,
August 1982.
[SMTP-ENH-ERR] N. Freed, "SMTP Service Extension for Returning
Enhanced Error Codes", RFC 2034, October 1996.
[SMTP-EXT] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker,
"SMTP Service Extensions", STD-10, RFC 1869, November 1995.
[SMTP-PIPE] N. Freed, "SMTP Service Extension for Command
Pipelining", RFC 2197, September 1997. .in -5
9. Copyright
Copyright (C) The Internet Society (1997, 1998). 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 implmentation 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.
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.
10. Authors' Addresses
Dan Wing
Cisco Systems, Inc.
101 Cooper Street
Santa Cruz, CA 95060 USA
Joffe, Wing, Masinter Expires August 1998 [Page 16]
Internet Draft SMTP Immediate Delivery February 1998
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
Joffe, Wing, Masinter Expires August 1998 [Page 17]