Internet Draft: Message Submission R. Gellens
Document: draft-gellens-submit-08.txt QUALCOMM
Expires: 2 December 1998 J. Klensin
MCI
2 June 1998
Message Submission
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. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a
"working draft" or "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), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast).
A version of this draft document will be submitted to the RFC editor
as a Best Current Practice for the Internet Community. Discussion
and suggestions for improvement are requested. Public comments
should be sent to the IETF Submit mailing list,
<ietf-submit@imc.org>. To subscribe, send a message containing
SUBSCRIBE to <ietf-submit-request@imc.org>. Private comments can be
sent to the authors.
Copyright Notice
Copyright (C) The Internet Society 1998. All Rights Reserved.
Table of Contents
1. Abstract. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Document Information . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Definitions of Terms Used in this Memo. . . . . . . . . . . . . 3
2.2. Conventions Used in this Document . . . . . . . . . . . . . . . 4
3. Message Submission. . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Submission Identification . . . . . . . . . . . . . . . . . . . 4
3.2. Message Rejection and Bouncing. . . . . . . . . . . . . . . . . 4
3.3 Authorized Submission . . . . . . . . . . . . . . . . . . . . . . 5
Gellens & Klensin Expires December 1998 [Page 1]
Internet Draft Message Submission June 1998
3.4. Reply Codes . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Mandatory Actions . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. General Submission Rejection Code . . . . . . . . . . . . . . . 6
4.2. Ensure All Domains are Fully-Qualified . . . . . . . . . . . . . 7
5. Recommended Actions . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Enforce Address Syntax . . . . . . . . . . . . . . . . . . . . . 7
5.2. Log Errors. . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Optional Actions . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Enforce Submission Rights . . . . . . . . . . . . . . . . . . . 8
6.2. Require Authentication . . . . . . . . . . . . . . . . . . . . . 8
6.3. Enforce Permissions . . . . . . . . . . . . . . . . . . . . . . 8
6.4. Check Message Data . . . . . . . . . . . . . . . . . . . . . . . 8
7. Interaction with SMTP Extensions. . . . . . . . . . . . . . . . . 8
8. Message Modifications . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Add 'Sender' . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.2. Add 'Date' . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.3. Add 'Message-ID' . . . . . . . . . . . . . . . . . . . . . . . 10
8.4. Transfer Encode . . . . . . . . . . . . . . . . . . . . . . . . 10
8.5. Sign the Message . . . . . . . . . . . . . . . . . . . . . . . 10
8.6. Encrypt the Message . . . . . . . . . . . . . . . . . . . . . . 10
8.7. Resolve Aliases. . . . . . . . . . . . . . . . . . . . . . . . 10
8.8. Header Rewriting . . . . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations. . . . . . . . . . . . . . . . . . . . . 11
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 11
11. References. . . . . . . . . . . . . . . . . . . . . . . . . . . 12
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 13
13. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . 14
1. Abstract
SMTP was defined as a message *transfer* protocol, that is, a means
to route (if needed) and deliver finished (complete) messages.
Message Transfer Agents (MTAs) are not supposed to alter the message
text, except to add 'Received', 'Return-Path', and other header
fields as required by [SMTP-MTA].
However, SMTP is now also widely used as a message *submission*
protocol, that is, a means for message user agents (MUAs) to
introduce new messages into the MTA routing network. The process
which accepts message submissions from MUAs is termed a Message
Submission Agent (MSA).
Messages being submitted are in some cases finished (complete)
messages, and in other cases are unfinished (incomplete) in some
aspect or other. Unfinished messages need to be completed to ensure
they conform to [MESSAGE-FORMAT], and later requirements. For
example, the message may lack proper 'Date' or 'Message-ID' header
fields, and domains might not be fully qualified. In some cases,
the MUA may be unable to generate finished messages (for example, it
might not know its time zone). Even when submitted messages are
complete, local site policy may dictate that the message text be
Gellens & Klensin Expires December 1998 [Page 2]
Internet Draft Message Submission June 1998
examined or modified in some way. Such completions or modifications
have been shown to cause harm when performed by downstream MTAs --
that is, MTAs after the first-hop submission MTA -- and are in
general considered to be outside the province of standardized MTA
functionality.
Separating messages into submissions and transfers allows developers
and network administrators to more easily:
* Implement security policies and guard against unauthorized mail
relaying or injection of unsolicited bulk mail
* Implement authenticated submission, including off-site
submission by authorized users such as travelers
* Separate the relevant software code differences, thereby making
each code base more straightforward and allowing for
different programs for relay and submission
* Detect configuration problems with a site's mail clients
* Provide a basis for adding enhanced submission services in the
future
This memo describes a low cost, deterministic means for messages to
be identified as submissions, and specifies what actions are to be
taken by a submission server.
2. Document Information
2.1. Definitions of Terms Used in this Memo
Fully-Qualified
Containing or consisting of a domain which can be globally resolved
using the global Domain Name Service; that is, not a local alias or
partial specification.
Message Submission Agent (MSA)
A process which conforms to this specification, which acts as a
submission server to accept messages from MUAs, and either delivers
them or acts as an SMTP client to relay them to an MTA.
Message Transfer Agent (MTA)
A process which conforms to [SMTP-MTA], which acts as an SMTP server
to accept messages from an MSA or another MTA, and either delivers
them or acts as an SMTP client to relay them to another MTA.
Gellens & Klensin Expires December 1998 [Page 3]
Internet Draft Message Submission June 1998
Message User Agent (MUA)
A process which acts (usually on behalf of a user) to compose and
submit new messages, and process delivered messages. In the
split-MUA model, POP or IMAP is used to access delivered messages.
2.2. Conventions Used in this Document
In examples, "C:" is used to indicate lines sent by the client, and
"S:" indicates those sent by the server. Line breaks within a
command example are for editorial purposes only.
All example domains use "gork" as the top-level domain.
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
in this document are to be interpreted as defined in [KEYWORDS].
3. Message Submission
3.1. Submission Identification
Port 587 is reserved for email message submission as specified in
this document. Messages received on this port are defined to be
submissions. The protocol used is ESMTP [SMTP-MTA, ESMTP], with
additional restrictions as specified here.
While most email clients and servers can be configured to use port
587 instead of 25, there are cases where this is not possible or
convenient. A site MAY choose to use port 25 for message
submission, by designating some hosts to be MUAs and others to be
MTAs.
3.2. Message Rejection and Bouncing
MTAs and MSAs MAY implement message rejection rules that rely in
part on whether the message is a submission or a relay.
For example, some sites might configure their MTA to reject all RCPT
TOs for messages that do not reference local users, and configure
their MSA to reject all message submissions that do not come from
authorized users, based on IP address, or authenticated identity.
When a problem with a message is detected, and the MSA has no rule
specifically configured for that problem, the MSA SHOULD reject the
message rather than attempt to fix it.
NOTE: It is better to reject a message than to risk sending one
that is damaged. This is especially true for problems that are
correctable by the MUA, for example, an invalid 'From' field.
Gellens & Klensin Expires December 1998 [Page 4]
Internet Draft Message Submission June 1998
If an MSA is not able to determine a return path to the submitting
user, from a valid MAIL FROM, a valid source IP address, or based on
authenticated identity, then the MSA SHOULD immediately reject the
message. A message can be immediately rejected by returning a 5xx
code to the MAIL FROM command or after receiving the DATA command.
Note that a null return path, that is, MAIL FROM <>, is permitted
and MUST be accepted. (MUAs need to generate null return-path
messages for a variety of reasons, including disposition
notifications.)
Except in the case where the MSA is unable to determine a valid
return path for the message being submitted, text in this
specification which instructs an MSA to issue a rejection code MAY
be complied with by accepting the message and subsequently
generating a bounce message.
NOTE: In the normal case of message submission, immediately
rejecting the message is preferred, as it gives the user and MUA
direct feedback. To properly handle delayed bounces the client MUA
must maintain a queue of messages it has submitted, and match
bounces to them.
3.3 Authorized Submission
Numerous methods have been used to ensure that only authorized users
are able to submit messages. These methods include authenticated
SMTP, IP address restrictions, secure IP, and prior POP
authentication.
Authenticated SMTP [SMTP-AUTH] SHOULD be supported if possible. It
allows the MSA to determine an authorization identity for the
message submission, which is not tied to other protocols.
IP address restrictions are very widely implemented, but do not
allow for travellers and similar situations, and can be spoofed.
Secure IP [IPSEC] is a useful method for some situations.
Requiring a POP [POP3] authentication (from the same IP address)
within some amount of time (for example, 20 minutes) prior to the
start of a message submission session has also been used, but this
does impose restrictions on clients as well as servers which may
cause difficulties. Specifically, the client must do a POP
authentication before an SMTP submission session, and not all
clients are capable and configured for this. Also, the MSA must
coordinate with the POP server, which may be difficult. There is
also a window during which an unauthorized user can submit messages
and appear to be a prior authorized user.
Gellens & Klensin Expires December 1998 [Page 5]
Internet Draft Message Submission June 1998
3.4. Reply Codes
This memo adds several reply codes to those defined in [SMTP-MTA].
The reply codes used in this document are:
250 Requested action okay, completed.
501 Syntax error in parameters or arguments.
502 Command not implemented.
503 Bad sequence of commands.
505 Authentication required. Site policy requires
authentication before issuing this command.
554 Transaction Failed. (Various errors in contents of
MAIL FROM, RCPT TO, or DATA).
555 Bad domain or address. Invalid or improper domain or address
in MAIL FROM, RCPT TO, or DATA.
556 Not a submission. The message appears to have been submitted
earlier.
560 Not allowed. The address in MAIL FROM appears to have
insufficient submission rights, or is invalid, or is not
authorized with the authentication used; the address in a
RCPT TO command is inconsistent with the permissions given
to the user; the message data is rejected based on the
submitting user.
561 Site policy. The message appears to violate site policy in
some way.
An implementation MAY include a configuration option to generate 554
instead of 560, to avoid revealing information about
security-related rejections.
4. Mandatory Actions
An MSA MUST do all of the following:
4.1. General Submission Rejection Code
Unless covered by a more precise response code, response code 554
MUST be used to reject a MAIL FROM, RCPT TO, or DATA command that
contains something improper.
Gellens & Klensin Expires December 1998 [Page 6]
Internet Draft Message Submission June 1998
4.2. Ensure All Domains are Fully-Qualified
The MSA MUST ensure that all domains in the envelope are
fully-qualified.
If the MSA examines or alters the message text in way, except to add
'Received' header fields, it MUST ensure that all domains in address
header fields are fully-qualified.
Reply code 555 is to be used to reject a MAIL FROM, RCPT TO, or DATA
command which contains improper domains references.
NOTE: A frequent local convention is to accept single-level domains
(for example, 'sales') and then to expand the reference by adding
the remaining portion of the domain name (for example, to
'sales.foo.gork'). It is strongly advised that local conventions
that permit single-level domains reject, rather than expand,
multi-level domains, since such expansion is particularly risky.
5. Recommended Actions
The MSA SHOULD do all of the following:
5.1. Enforce Address Syntax
An MSA SHOULD reject messages with illegal syntax in a sender or
recipient envelope address.
If the MSA examines or alters the message text in way, except to add
'Received' header fields, it SHOULD reject messages with illegal
address syntax in address header fields.
Reply code 501 is to be used to reject a MAIL FROM or RCPT TO
command that contains a detectably improper address.
When addresses are resolved after submission of the message body,
reply code 555 is to be used after end- of-data, if the message
contains invalid addresses in the header.
5.2. Log Errors
The MSA SHOULD log message errors, especially apparent
misconfigurations of client software.
Note: It can be very helpful to notify the administrator when
problems are detected with local mail clients. This is another
advantage of distinguishing submission from relay: system
administrators might be interested in local configuration problems,
Gellens & Klensin Expires December 1998 [Page 7]
Internet Draft Message Submission June 1998
but not in client problems at other sites.
6. Optional Actions
The MSA MAY do any of the following:
6.1. Enforce Submission Rights
The MSA MAY issue an error response to the MAIL FROM command if the
address in MAIL FROM appears to have insufficient submission rights,
or is invalid, or is not authorized with the authentication used (if
the session has been authenticated).
Reply code 560 is used for this purpose.
6.2. Require Authentication
The MSA MAY issue an error response to the MAIL FROM command if the
session has not been authenticated.
Section 3.3 discusses authentication mechanisms.
Reply code 503 is used for this purpose.
6.3. Enforce Permissions
The MSA MAY issue an error response to the RCPT TO command if
inconsistent with the permissions given to the user (if the session
has been authenticated).
Reply code 560 is used for this purpose.
6.4. Check Message Data
The MSA MAY issue an error response to the DATA command or send a
failure result after end-of-data if the submitted message is
syntactically invalid, or seems inconsistent with permissions given
to the user (if known), or violates site policy in some way.
Reply code 554 is used for syntactic problems in the data. Reply
code 501 is used if the command itself is not syntactically valid.
Reply code 560 is used to reject based on the submitting user.
Reply code 561 is used if the message violates site policy.
7. Interaction with SMTP Extensions
Gellens & Klensin Expires December 1998 [Page 8]
Internet Draft Message Submission June 1998
The following table lists the current standards-track and
Experimental SMTP extensions. Listed are the RFC, name, status, an
indication as to the extension's use on the submit port, and a
reference:
RFC Name Status Submission Reference
---- --------------- ------ ---------- ------------------
2197 Pipelining DS SHOULD [PIPELINING]
2034 Error Codes PS SHOULD [CODES-EXTENSION]
1985 ETRN PS MUST NOT [ETRN]
1893 Extended Codes PS SHOULD [SMTP-CODES]
1891 DSN PS MAY [DSN]
1870 Size S MAY [SIZE]
1846 521 E MUST NOT [521REPLY]
1845 Checkpoint E MAY [Checkpoint]
1830 Binary E MAY [CHUNKING]
1652 8-bit MIME DS SHOULD [8BITMIME]
---- Authentication -- SHOULD [SMTP-AUTH]
Future SMTP extensions should explicitly specify if they are valid
on the Submission port.
Some SMTP extensions are especially useful for message submission:
Extended Status Codes [SMTP-CODES], SHOULD be supported and used
according to [CODES-EXTENSION]. This permits the MSA to notify the
client of specific configuration or other problems in more detail
than the response codes listed in this memo. Because some
rejections are related to a site's security policy, care should be
used not to expose more detail than is needed to correct the
problem.
[PIPELINING] SHOULD be supported by the MSA.
[SMTP-AUTH] SHOULD be supported is possible. It allows the MSA to
validate the authority and determine the identity of the submitting
user.
Any references to the DATA command in this memo also refer to any
substitutes for DATA, such as the BDAT command used with [CHUNKING].
8. Message Modifications
Sites MAY modify submissions to ensure compliance with standards,
and/or site policy. This section describes a number of such
modifications that are often considered useful.
NOTE: As a matter of guidance for local decisions to implement
message modification, a paramount rule is to limit such actions to
remedies for specific problems that have clear solutions. This is
Gellens & Klensin Expires December 1998 [Page 9]
Internet Draft Message Submission June 1998
especially true with address elements. For example,
indiscriminately appending a domain to an address or element which
lacks one typically results in more broken addresses. An
unqualified address must be verified to be a valid local part in the
domain before the domain can be safely added.
8.1. Add 'Sender'
The MSA could add or replace the 'Sender' field, if the identity of
the sender is known and this is not given in the 'From' field.
The MSA MUST ensure that any address it places in a 'Sender' field
is in fact a valid mail address.
8.2. Add 'Date'
The MSA could add a 'Date' field to the submitted message, if it
lacks it, or correct the 'Date' field if it does not conform to
[MESSAGE-FORMAT] syntax.
8.3. Add 'Message-ID'
The MSA could add or replace the 'Message-ID' field, if it lacks it,
or it is not valid syntax (as defined by [MESSAGE-FORMAT]).
8.4. Transfer Encode
The MSA could apply transfer encoding to the message according to
MIME conventions, if needed and not harmful to the MIME type.
8.5. Sign the Message
The MSA could (digitally) sign or otherwise add authentication
information to the message.
8.6. Encrypt the Message
The MSA could encrypt the message for transport to reflect
organizational policies.
8.7. Resolve Aliases
The MSA could resolve aliases (CNAME records) for domain names, in
the envelope and optionally in address fields of the header, subject
to local policy.
Gellens & Klensin Expires December 1998 [Page 10]
Internet Draft Message Submission June 1998
Note: unconditionally resolving aliases could be harmful. For
example, if www.ab.gork and ftp.ab.gork are both aliases for
mail.ab.gork, rewriting them could lose useful information.
8.8. Header Rewriting
The MSA MAY rewrite local parts and/or domains, in the envelope and
optionally in address fields of the header, according to local
policy. For example, a site may prefer to rewrite 'JRU' as
'J.Random.User' in order to hide logon names, and/or to rewrite
'squeeky.sales.xyz.gork' as 'zyx.gork' to hide machine names and
make it easier to move users.
However, only addresses, local-parts, or domains which match
specific local MSA configuration settings should be altered. It
would be very dangerous for the MSA to apply data-independent
rewriting rules, such as always deleting the first element of a
domain name. So, for example, a rule which strips the left-most
element of the domain if the complete domain matches
'*.foo.bar.gork' would be acceptable.
9. Security Considerations
Separation of submission and relay of messages can allow a site to
implement different policies for the two types of services,
including requiring use of additional security mechanisms for one or
both. It can do this in a way which is simpler, both technically
and administratively. This increases the likelihood that policies
will be applied correctly.
Separation also can aid in tracking and preventing unsolicited bulk
email.
For example, a site could configure its MSA to require
authentication before accepting a message, and could configure its
MTA to reject all RCPT TOs for non-local users. This can be an
important element in a site's total email security policy.
If a site fails to require any form of authorization for message
submissions (as discussed in 3.3 ), it is allowing open use of its
resources and name, since unsolicited bulk email can be injected
using its facilities.
10. Acknowledgments
This updated draft has been revised in part based on comments and
discussions which took place on and off the IETF-Submit mailing
list. The help of those who took the time to review the draft and
Gellens & Klensin Expires December 1998 [Page 11]
Internet Draft Message Submission June 1998
make suggestions is appreciated, especially that of Dave Crocker,
Ned Freed, Keith Moore, John Myers, and Chris Newman.
Special thanks to Harald Alvestrand, who got this effort started.
11. References
[521REPLY] A. Durand, and F. Dupont, "SMTP 521 Reply Code",
September 1995, <ftp://ftp.isi.edu/in-notes/rfc1846.txt>
[8BITMIME] J. Klensin, N. Freed, M. Rose, E. Stefferud, and D.
Crocker, "SMTP Service Extension for 8bit-MIMEtransport", July 1994,
<ftp://ftp.isi.edu/in-notes/rfc1652.txt>
[ABNF] D. Crocker, Ed., P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", November 1997,
<ftp://ftp.isi.edu/in-notes/rfc2234.txt>
[CHECKPOINT] D. Crocker, N. Freed, and A. Cargille, "SMTP Service
Extension for Checkpoint/Restart, September 1995,
<ftp://ftp.isi.edu/in-notes/rfc1845.txt>
[CHUNKING] G. Vaudreuil, "SMTP Service Extensions for Transmission
of Large and Binary MIME Messages", August 1995,
<ftp://ftp.isi.edu/in-notes/rfc1830.txt>
[CODES-EXTENSION] N. Freed, "SMTP Service Extension for Returning
Enhanced Error Codes", RFC 2034, October 1996,
<ftp://ftp.isi.edu/in-notes/rfc2034.txt>
[DSN] K. Moore, "SMTP Service Extension for Delivery Status
Notifications, January 1996,
<ftp://ftp.isi.edu/in-notes/rfc1891.txt>
[ESMTP] J. Klensin, N. Freed, M. Rose, E. Stefferud, and D.
Crocker, "SMTP Service Extensions", STD 10, RFC 1869, November 1995,
<ftp://ftp.isi.edu/in-notes/rfc1869.txt>
[ETRN] J. De Winter, "SMTP Service Extension for Remote Message
Queue Starting", August 1996,
<ftp://ftp.isi.edu/in-notes/rfc1985.txt>
[] J. Palme, "Common Internet Message Headers", RFC 2076,
February 1997, <ftp://ftp.isi.edu/in-notes/rfc2076.txt>
[IPSEC] R. Atkinson, "Security Architecture for the Internet
Protocol", RFC 1825, August 1995,
<ftp://ftp.isi.edu/in-notes/rfc1825.txt>
[KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
Gellens & Klensin Expires December 1998 [Page 12]
Internet Draft Message Submission June 1998
<ftp://ftp.isi.edu/in-notes/rfc2119.txt>
[MESSAGE-FORMAT] D. Crocker, "Standard for the format of ARPA
Internet text messages", STD 11, RFC 822, August 1982,
<ftp://ds.internic.net/rfc/rfc822.txt>; R. Braden, Editor,
"Requirements for Internet Hosts -- Application and Support", STD 3,
RFC 1123, October 1989, <ftp://ftp.isi.edu/in-notes/rfc1123.txt>
[PIPELINING] N. Freed, "SMTP Service Extension for Command
Pipelining", RFC 2197, September 1997,
<ftp://ftp.isi.edu/in-notes/rfc2197.txt>
[POP3] J. Myers, M. Rose, "Post Office Protocol -- Version 3", STD
53, RFC 1939, May 1996, <ftp://ftp.isi.edu/in-notes/rfc1939.txt>
[SIZE] J. Klensin, N. Freed, and K. Moore, "SMTP Service
Extension for Message Size Declaration, November 1995,
<ftp://ftp.isi.edu/in-notes/rfc1870.txt>
[SMTP-AUTH] J. Myers, "SMTP Service Extension for Authentication",
work in progress,
<ftp://ftp.ietf.org/internet-drafts/draft-myers-smtp-auth-11.txt>
[SMTP-CODES] G. Vaudreuil, "Enhanced Mail System Status Codes", RFC
1893, January 1996, <ftp://ftp.isi.edu/in-notes/rfc1893.txt>
[SMTP-MTA] J. Postel, "Simple Mail Transfer Protocol", STD 10, RFC
821, August 1982, <ftp://ds.internic.net/rfc/rfc821.txt>; C.
Partridge, "Mail Routing and the Domain System", STD 14, RFC 974,
January 1986, <ftp://ds.internic.net/rfc/rfc974.txt>; R. Braden,
Editor, "Requirements for Internet Hosts -- Application and
Support", STD 3, RFC 1123, October 1989,
<ftp://ftp.isi.edu/in-notes/rfc1123.txt>
12. Full Copyright Statement
Copyright (C) The Internet Society 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 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.
Gellens & Klensin Expires December 1998 [Page 13]
Internet Draft Message Submission June 1998
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.
13. Authors' Addresses
Randall Gellens +1 619 651 5115
QUALCOMM Incorporated +1 619 651 5334 (fax)
6455 Lusk Blvd. Randy@Qualcomm.Com
San Diego, CA 92121-2779
U.S.A.
John C. Klensin +1 617 960 1011
MCI Telecommunications klensin@mci.net
800 Boylston St, 7th floor
Boston, MA 02199
USA
Gellens & Klensin Expires December 1998 [Page 14]