Application Area Neil Joffe
Internet Draft Dan Wing
November 19, 1997 Cisco Systems
Expires May 1998 Larry Masinter
draft-ietf-fax-smtp-session-01.txt Xerox Corporation
SMTP Service Extension for Immediate Delivery
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. All Rights Reserved.
0. Administrivia
0.1. Open design issues
0.1.1. Server's response to STAT
The authors feel that message/delivery-status allows for all sorts of
delivery information to be conveyed, including necessary
Wing, Joffe, Masinter Expires April 1998 [Page 1]
Internet Draft SMTP Immediate Delivery November 1997
transformations which might be necessary for some deliveries, such as
fax.
It was suggested to us in private email to expand this to be
multipart/report, which allows non-parsable data to be sent to the
SMTP client. As the examples below show, this data can be a audio or
a fax (tiff-f) image. However, this may be too unwieldy for many
uses of Session.
Another idea is a one-line response that indicates Session delivery
status as in-progress or completed, which makes combining responses
easier as well.
0.1.2. STAT for each recipient or all recipients
The authors have been asked to create a single command to query
delivery status for all recipients (instead of requiring a separate
STAT command for each recipient, as this memo is currently written).
If we use DSNs, this is not possible unless we send multiple
multipart/reports (or multiple message/delivery-status) because DSNs
aren't designed to be coalesced.
0.2. Notes and unresolved issues
More verbage needed for security section
Add example showing DSN (NOTIFY=blah) in conjunction with SESSION
0.3. Changes since previous versions
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 "."
Wing, Joffe, Masinter Expires April 1998 [Page 2]
Internet Draft SMTP Immediate Delivery November 1997
* Specify SMTP server must respond to STAT within 30 seconds
1. Abstract
This memo defines an extension to SMTP which provides a mechanism for
requesting and verifying immediate message delivery over SMTP.
2. 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.
The SESSION extension allows for immediate delivery of mail; it
presumes either a direct connection between sender and recipient or a
chain of session-enabled servers in which each supports the 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
4.1.
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.
The 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 are requested.
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.
Wing, Joffe, Masinter Expires April 1998 [Page 3]
Internet Draft SMTP Immediate Delivery November 1997
2.2. Conventions used in this document
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.
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].
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 retreive an in-line DSN), is
defined with this extension, and is described in section 6;
(5) one optional parameter is added to the RCPT command, using the
esmtp-keyword SESSION, and is described in section 5,
no parameters are added to the MAIL FROM command;
(6) the maximum length of a RCPT TO is increased by 8 characters.
4. Esmtp-keyword SESSION
Upon receiving a RCPT command with the esmtp-keyword SESSION, a
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. Note that SESSION delivery can
subsequently fail due to disk space exhaustion, disk quotas, failure
of a remote MTA, loss of connectivity to a remote MTA, or other
reasons. The MTA that detected the failure may attempt to deliver
the message via store-and-forward -- the SMTP client may use the STAT
command to determine the delivery status of the message.
Wing, Joffe, Masinter Expires April 1998 [Page 4]
Internet Draft SMTP Immediate Delivery November 1997
If a session-enabled server is unable to send a message immediately
(that is, the request for SESSION will not be honored), but the
session-enabled server is willing to send the message via store-and-
forward, it MUST 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 to abort the
SMTP transaction.
5. New SMTP verb STAT
One new SMTP verb is introduced with the Session extension. The STAT
verb allows a client to query the session delivery status for all
recipients in this mail transaction.
The STAT command, and the server's reply to STAT, are sent along the
SMTP "path". Using the diagram in section 4, the SMTP client (A)
would send a STAT command to (B), and (B) would forward the STAT
command to (C), which forwards it to (D). (D) generates the reply to
STAT which is echoed back through the MTAs until it is finally sent
by (B) to (A).
The syntax of the STAT verb, using the notation described in [ABNF],
is:
stat-cmd = "STAT" SP <forward-path> CR LF
The reply to the STAT command is called an ``in-line Delivery Status
Notification'', or ``in-line DSN''.
The SMTP server MUST 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.
5.1. Format of in-line Delivery Status Notification
The reply to STAT is a multipart/report as defined in [MIME-RPT].
However, note that this Session extension does NOT require the
session-enabled SMTP server also implement Delivery Status
Notifications [SMTP-DSN].
Each line of the multipart/report is sent following the rules for
SMTP replies. In the notation described in [ABNF]:
inline-dsn = *( "250-" [status-code SP] dsn-line CR LF )
"250 " [status-code SP] dsn-line CR LF
Wing, Joffe, Masinter Expires April 1998 [Page 5]
Internet Draft SMTP Immediate Delivery November 1997
dsn-line = <each line of the multipart/report from [MIME-
RPT]>
status-code = <This is <status-code> of section 4 of [SMTP-
ENH-ERR] if SMTP server implements [SMTP-ENH-
ERR]>
text = <any CHAR except CTL>
Note that the information returned can include extension fields, such
as those defined in [FAX-DSN].
5.2. Per-recipient DSN extension
[DSN] permits extension fields to be defined. The following new
per-recipient DSN extension is defined for each recipient that had
the esmtp-keyword SESSION. In the notation described in [ABNF]:
extension-field = "Session-Delivery" *WSP ":" *WSP
session-status
session-status = "delivered" / "in-progress" / "queued"
The <extension-field> and <session-status> can be spelled in any
combination of uppercase and lowercase letters.
"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.
Once a terminal value in-line DSN has been sent for a specific
forward-path, the SMTP server does not need to include that forward-
path in subsequent STAT replies. If an SMTP client sends a STAT
command and the SMTP server has already informed the SMTP client that
all recipients had a terminal values, the SMTP server should return a
503 reply.
Wing, Joffe, Masinter Expires April 1998 [Page 6]
Internet Draft SMTP Immediate Delivery November 1997
5.3. Delivery notifications and STAT
During normal store and forward operation and in the absence of
special RFC822 headers (such as Return-Receipt-To, Generate-
Delivery-Report described in [HEADERS]), only a delivery failure
causes a message to be generated (commonly called a `bounce').
If an SMTP server implments [SMTP-DSN], the SMTP client may request a
delivery status notification, and such a request may be for actions
other than delivery failure (such as SUCCESS or DELAY).
XXX A session-enabled server SHOULD NOT send such a `bounce' (or DSN)
message if the recipient included the esmtp-keyword SESSION, and the
SMTP server can be positive that the SMTP client has already received
the same information from the in-line delivery status notification.
For example, if the SMTP client sends a QUIT command after the SMTP
server has sent the in-line delivery status notification, the SMTP
server knows the SMTP client has successfully received the in-line
delivery status notification.
XXX - bzzt: pipelining allows the "." and QUIT commands to be sent at
the same time. How should we resolve this problem?
If the RCPT command included the esmtp-keyword SESSION, any DSN
generated must include the DSN per-recipient extension defined in
section 5.2 -- omission of this extension implies "Session-Delivery:
queued" (because the message was sent through an MTA that doesn't
support SESSION).
5.4. Usage of [DSN] fields
For Session recipients, the <will-retry-until-field>, described in
[DSN], can be used to indicate when the SMTP server will stop
attempting to deliver the Session message. Note it is not possible
to determine if the Delivery-Status will be "queued" or "delivered"
except by querying via another STAT command.
XXX - Is this going to be sufficient for our FAX needs? We could add
more things, like bytes, pages, seconds-to-completion for in-
progress. Would another extension be useful to indicate how
long it took to send the fax (for billing)?
6. Behavior with multiple hop delivery
Both the esmtp-keyword SESSION and the new SMTP verb STAT require
Wing, Joffe, Masinter Expires April 1998 [Page 7]
Internet Draft SMTP Immediate Delivery November 1997
special behavior when dealing with multiple-hop delivery. Multiple-
hop delivery occurs when the sending mailer isn't communicating
directly with the receiving mailer -- that is, there are intervening
mail transfer agents (MTAs) between the sending mailer and the
receiving mailer.
6.1. esmtp-keyword SESSION
The following sections describe the behavior of the SMTP server when
a RCPT command contains the esmtp-keyword SESSION.
6.1.1. SESSION local delivery
In the case of a local delivery, the SESSION keyword causes the
session-enabled server to attempt immediate delivery of the message
to the local user's mailbox.
6.1.2. SESSION relayed delivery
The following diagram is used to help describe the relayed delivery
behavior. The diagram depicts a user agent sending mail to two
recipients with the esmtp-keyword SESSION, and each recipient has a
different MTA.
+-------+ +-----------+
-=> | MTA-1 | => | receiving | user@host-x
/ | | | MTA-1 |
+-----+ +--------+ / +-------+ +-----------+
| user| => |Original| =< (C) (D)
|agent| | MTA | \
+-----+ +--------+ \ +-------+ +-----------+
(A) (B) -=> | MTA-2 | => | receiving | user@host-y
| | | MTA-2 |
+-------+ +-----------+
(E) (F)
In the case of several MTAs in the SMTP 'path', as in the above
diagram, the RCPT command with the esmtp-keyword SESSION is forwarded
to the next MTA (before the current MTA responds to the RCPT command)
until finally the RCPT command is sent to the 'last' MTA which
actually sends a reply. The reply is then echoed back along the SMTP
'path'.
Thus in the above diagram, if (A) issued two RCPT commands, the order
of processing is as follows:
Wing, Joffe, Masinter Expires April 1998 [Page 8]
Internet Draft SMTP Immediate Delivery November 1997
(1) A>B: ... normal SMTP initiation sequence...
(2) A>B: RCPT TO:<user@host-x> SESSION
(3) B>C: ... normal SMTP initiation sequence...
(4) B>C: RCPT TO:<user@host-x> SESSION
(5) C>D: ... normal SMTP initiation sequence...
(6) C>D: RCPT TO:<user@host-x> SESSION
(7) D>C: 220 <user@host-x> okay
(8) C>B: 220 <user@host-x> okay
(9) B>A: 220 <user@host-x> okay
(10) A>B: RCPT TO:<user@host-y> SESSION
(11) B>E: ... normal SMTP initiation sequence...
(12) B>E: RCPT TO:<user@host-y> SESSION
(13) E>F: ... normal SMTP initiation sequence...
(14) E>F: RCPT TO:<user@host-y> SESSION
(15) F>E: 220 <user@host-y> okay
(16) E>B: 220 <user@host-y> okay
(17) B>A: 220 <user@host-y> okay
The DATA command is also handled in a parallel function, such that a
single DATA command from (A) is transmitted to (B), which then sends
a DATA command to both (C) and (E). During mail data transfer, each
MTA is expected to stream the network data to the next MTA (or to the
local user's mailbox, as appropriate) -- that is, the data should be
sent from the MTA while it is being received.
When (B) receives the end-of-mail indicator, it must reply to (A) as
soon as possible to prevent duplicate messages as described in
[DUPLICATE].
The MTA at (C) and (D) must likewise reply to the end-of-mail
indicator as soon as possible.
6.1.3. 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.
Implementors must carefully design session-enabled MTAs to respond
quickly when Session recipients are present to minimize timing
problems.
7. Implementation notes
Wing, Joffe, Masinter Expires April 1998 [Page 9]
Internet Draft SMTP Immediate Delivery November 1997
7.1. SMTP server reply to STAT
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.
7.2. PIPELINING implementation recommendation
Due to the delays inherent with establishing connections with each
MTA in the SMTP "path", SMTP servers that implement this SESSION
extension SHOULD also implement [SMTP-PIPE]. This permits the SMTP
client to send the STAT command immediately after the end-of-mail-
data indicator, without waiting for the SMTP server's reply to the
end-of-mail-data indicator.
8. Security Considerations
Denial of service attacks are possible with SESSION.
XXX - more verbage
9. Examples
9.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.
Note also that the in-line DSN for njoffe@cisco.com includes a both a
TIFF (fax format) and audio reply, which may be used directly by some
mail user agents. This is merely an example to show how in-line DSNs
might be useful for low-end SMTP clients; a good SMTP server
implementation would only special content-types if it had reason to
believe the SMTP client could use them.
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
Wing, Joffe, Masinter Expires April 1998 [Page 10]
Internet Draft SMTP Immediate Delivery November 1997
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: From: Dan Wing <dwing@cisco.com>
C: To: njoffe@cisco.com, masinter@parc.xerox.com
C: Date: Mon, 6 Oct 1997 12:42:32 -0700
C: Subject: Palo Alto Coffee shops
C:
C: Please let me know your favorite coffee shop in Palo Alto.
C: .
S: 250 message accepted
C: STAT <masinter@parc.xerox.com>
S: 250-Content-type: multipart/report;boundary="MessageBoundary"
S: 250-
S: 250---MessageBoundary
S: 250-Content-type: text/plain
S: 250-
S: 250-Your message is still being sent to:
S: 250-
S: 250-Recipient address: masinter@parc.xerox.com
S: 250-Reason: Still writing 32 bytes to remote system
S: 250-
S: 250---MessageBoundary
S: 250-Content-type: message/delivery-status
S: 250-
S: 250-Original-envelope-id: 01IOHGLWJLHE8X2IDT@Cisco.COM
S: 250-Reporting-MTA: dns; parc-1.xerox.com
S: 250-
S: 250-Action: delivered
S: 250-Status: 2.0.0
S: 250-Final-recipient: rfc822;masinter
S: 250-Session-Delivery: in-progress
S: 250-
S: 250 --MessageBoundary--
C: STAT <njoffe@cisco.com>
S: 250-Content-type: multipart/report;boundary="MessageBoundary"
S: 250-
S: 250---MessageBoundary
S: 250-Content-type: multipart/alternative;boundary="AltBoundary"
S: 250-
S: 250---AltBoundary
S: 250-Content-type: text/plain
S: 250-
S: 250-Your message was successfully delivered to these recipients:
S: 250-
S: 250-Recipient address: njoffe@cisco.com
Wing, Joffe, Masinter Expires April 1998 [Page 11]
Internet Draft SMTP Immediate Delivery November 1997
S: 250-Reason: Successfully delivered immediately to local user.
S: 250-
S: 250---AltBoundary
S: 250-Content-type: audio/basic
S: 250-Content-Transfer-Encoding: base64
S: 250-
S: 250-ABCDEF01234567890ABCDEF01234567890ABCDEF01234567890ABCDEF
S: 250-ABCDEF01234567890ABCDEF01234567890ABCDEF01234567890ABCDEF
S: 250-ABCDEF01234567890ABCDEF01234567890ABCDEF01234567890ABCDEF
S: 250-
S: 250---AltBoundary
S: 250-Content-type: tiff; application=f
S: 250-Content-Transfer-Encoding: base64
S: 250-
S: 250-01234567890ABCDEF01234567890ABCDEF01234567890ABCDEF012345
S: 250-01234567890ABCDEF01234567890ABCDEF01234567890ABCDEF012345
S: 250-01234567890ABCDEF01234567890ABCDEF01234567890ABCDEF012345
S: 250-
S: 250---AltBoundary--
S: 250-
S: 250---MessageBoundary
S: 250-Content-type: message/delivery-status
S: 250-
S: 250-Original-envelope-id: 01IOHGLWJLHE8X2IDT@Cisco.COM
S: 250-Reporting-MTA: dns; lint.cisco.com
S: 250-
S: 250-Action: delivered
S: 250-Status: 2.0.0 (Delivered immediately to local user)
S: 250-Final-recipient: rfc822;njoffe
S: 250-Session-Delivery: delivered
S: 250-
S: 250 --MessageBoundary--
C: STAT <masinter@parc.xerox.com>
S: 250-Content-type: MULTIPART/REPORT;BOUNDARY="MessageBoundary"
S: 250-
S: 250---MessageBoundary
S: 250-Content-type: text/plain
S: 250-
S: 250-Your message was successfully delivered to these recipients:
S: 250-
S: 250-Recipient address: masinter@parc.xerox.com
S: 250-Reason: Successfully delivered immediately to local user.
S: 250-
S: 250---MessageBoundary
S: 250-Content-type: message/delivery-status
S: 250-
S: 250-Original-envelope-id: 01IOHGLWJLHE8X2IDT@Cisco.COM
S: 250-Reporting-MTA: dns; parc-1.xerox.com
Wing, Joffe, Masinter Expires April 1998 [Page 12]
Internet Draft SMTP Immediate Delivery November 1997
S: 250-
S: 250-Action: delivered
S: 250-Status: 2.0.0
S: 250-Final-recipient: rfc822;masinter
S: 250-Session-Delivery: delivered
S: 250-
S: 250 --MessageBoundary--
C: QUIT
S: 221 Goodbye
9.2 XXX - other examples?
10. 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.
11. 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.
[FAX-DSN] D. Wing, "Extensions to Delivery Status Notifications for
Fax", Internet Draft, Work in Progress, draft-ietf-fax-dsn-
extensions-??.txt.
[] J. Palme, "Common Internet Message Headers", RFC 2076,
February 1997.
Wing, Joffe, Masinter Expires April 1998 [Page 13]
Internet Draft SMTP Immediate Delivery November 1997
[MIME-RPT] G. Vaudreuil, "The Multipart/Report Content Type for the
Reporting of Mail System Administrative Messages", RFC 1892,
January 1996.
[REQ] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", BCP-14, RFC 2119, March 1997.
[SMTP] J. Postel, "Simple Mail Transfer Protocol", STD-10, RFC 821,
August 1982.
[SMTP-DSN] K. Moore, "SMTP Service Extension for Delivery Status
Notifications", RFC 1891, January 1996.
[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.
12. Copyright
Copyright (C) The Internet Society 1997. 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
Wing, Joffe, Masinter Expires April 1998 [Page 14]
Internet Draft SMTP Immediate Delivery November 1997
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
13. Authors' Addresses
Dan Wing
Cisco Systems, Inc.
101 Cooper Street
Santa Cruz, CA 95060 USA
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
Wing, Joffe, Masinter Expires April 1998 [Page 15]
