From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2476.txt | 843 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 843 insertions(+) create mode 100644 doc/rfc/rfc2476.txt (limited to 'doc/rfc/rfc2476.txt') diff --git a/doc/rfc/rfc2476.txt b/doc/rfc/rfc2476.txt new file mode 100644 index 0000000..0c5c17d --- /dev/null +++ b/doc/rfc/rfc2476.txt @@ -0,0 +1,843 @@ + + + + + + +Network Working Group R. Gellens +Request for Comments: 2476 QUALCOMM +Category: Standards Track J. Klensin + MCI + December 1998 + + + Message Submission + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +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 + 3.4. Enhanced Status Codes . . . . . . . . . . . . . . . . . 6 + 4. Mandatory Actions . . . . . . . . . . . . . . . . . . . . . 6 + 4.1. General Submission Rejection Code . . . . . . . . . . . 6 + 4.2. Ensure All Domains are Fully-Qualified . . . . . . . . 6 + 5. Recommended Actions . . . . . . . . . . . . . . . . . . . . 7 + 5.1. Enforce Address Syntax . . . . . . . . . . . . . . . . 7 + 5.2. Log Errors . . . . . . . . . . . . . . . . . . . . . . . 7 + 6. Optional Actions . . . . . . . . . . . . . . . . . . . . . 7 + 6.1. Enforce Submission Rights . . . . . . . . . . . . . . . 7 + 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' . . . . . . . . . . . . . . . . . . . . . . 9 + 8.2. Add 'Date' . . . . . . . . . . . . . . . . . . . . . . 10 + 8.3. Add 'Message-ID' . . . . . . . . . . . . . . . . . . . . 10 + + + +Gellens & Klensin Standards Track [Page 1] + +RFC 2476 Message Submission December 1998 + + + 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 . . . . . . . . . . . . . . . . . . . 10 + 9. Security Considerations . . . . . . . . . . . . . . . . . . 11 + 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 11 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14 + 13. Full Copyright Statement . . . . . . . . . . . . . . . . . 15 + +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 a proper 'Date' header field, 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 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 + + + + +Gellens & Klensin Standards Track [Page 2] + +RFC 2476 Message Submission December 1998 + + + * 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. + + Public comments should be sent to the IETF Submit mailing list, + . To subscribe, send a message containing + SUBSCRIBE to . Private comments may be + sent to the authors. + +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. + + 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. + + + + + + +Gellens & Klensin Standards Track [Page 3] + +RFC 2476 Message Submission December 1998 + + +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. + + Examples use the 'example.net' 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 MSAs 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. + + 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. + + 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 550 + code to the MAIL FROM command. + + + + + + + +Gellens & Klensin Standards Track [Page 4] + +RFC 2476 Message Submission December 1998 + + + 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. (That is, if the MSA is going to reject a message for + any reason except being unable to determine a return path, it can + optionally do an immediate rejection or accept the message and then + mail a bounce.) + + 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] has been proposed. 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] can also be used, and provides additional benefits + of protection against eavesdropping and traffic analysis. + + 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 Standards Track [Page 5] + +RFC 2476 Message Submission December 1998 + + +3.4. Enhanced Status Codes + + This memo suggests several enhanced status codes [SMTP-CODES] for + submission-specific rejections. The specific codes used are: + + 5.6.0 Bad content. The content of the header or text is + improper. + + 5.6.2 Bad domain or address. Invalid or improper domain or address + in MAIL FROM, RCPT TO, or DATA. + + 5.7.1 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. + + 5.7.0 Site policy. The message appears to violate site policy in + some way. + +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 is + to be used to reject a MAIL FROM, RCPT TO, or DATA command that + contains something improper. Enhanced status code 5.6.0 is to be + used if no other code is more specific. + +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 + trace header fields [SMTP-MTA], it MUST ensure that all domains in + address header fields are fully-qualified. + + Reply code 554 is to be used to reject a MAIL FROM, RCPT TO, or DATA + command which contains improper domain 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 + + + + +Gellens & Klensin Standards Track [Page 6] + +RFC 2476 Message Submission December 1998 + + + 'sales.example.net'). Local conventions that permit single-level + domains SHOULD reject, rather than expand, incomplete 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 + trace 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 554 with enhanced status code 5.6.2 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, + 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 not authorized with the authentication used (if the session has + been authenticated). + + Reply code 550 with enhanced status code 5.7.1 is used for this + purpose. + + + +Gellens & Klensin Standards Track [Page 7] + +RFC 2476 Message Submission December 1998 + + +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 530 [SMTP-AUTH] 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 550 with enhanced status code 5.7.1 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 550 with enhanced status code 5.7.1 is used to reject + based on the submitting user. Reply code 550 with enhanced status + code 5.7.0 is used if the message violates site policy. + +7. Interaction with SMTP Extensions + + The following table lists the current standards-track and + Experimental SMTP extensions. Listed are the RFC, name, an + indication as to the use of the extension on the submit port, and a + reference: + + RFC Name Submission Reference + ---- --------------- ---------- ------------------ + 2197 Pipelining SHOULD [PIPELINING] + 2034 Error Codes SHOULD [CODES-EXTENSION] + 1985 ETRN MUST NOT [ETRN] + 1893 Extended Codes SHOULD [SMTP-CODES] + 1891 DSN SHOULD [DSN] + 1870 Size MAY [SIZE] + 1846 521 MUST NOT [521REPLY] + 1845 Checkpoint MAY [Checkpoint] + + + +Gellens & Klensin Standards Track [Page 8] + +RFC 2476 Message Submission December 1998 + + + 1830 Binary MAY [CHUNKING] + 1652 8-bit MIME SHOULD [8BITMIME] + ---- Authentication ------ [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] 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 + 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 + 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 MAY 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. + + + + + +Gellens & Klensin Standards Track [Page 9] + +RFC 2476 Message Submission December 1998 + + +8.2. Add 'Date' + + The MSA MAY 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 MAY 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 MAY 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 MAY (digitally) sign or otherwise add authentication + information to the message. + +8.6. Encrypt the Message + + The MSA MAY encrypt the message for transport to reflect + organizational policies. + + NOTE: To be useful, the addition of a signature and/or encryption by + the MSA generally implies that the connection between the MUA and MSA + must itself be secured in some other way, e.g., by operating inside + of a secure environment, by securing the submission connection at the + transport layer, or by using an [SMTP-AUTH] mechanism that provides + for session integrity. + +8.7. Resolve Aliases + + The MSA MAY resolve aliases (CNAME records) for domain names, in the + envelope and optionally in address fields of the header, subject to + local policy. + + NOTE: Unconditionally resolving aliases could be harmful. For + example, if www.example.net and ftp.example.net are both aliases for + mail.example.net, 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 ' + + + +Gellens & Klensin Standards Track [Page 10] + +RFC 2476 Message Submission December 1998 + + + J.Random.User' in order to hide logon names, and/or to rewrite ' + squeeky.sales.example.net' as 'zyx.example.net' 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.example.net' 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 (see section 3.3 for discussion), it is allowing open use + of its resources and name; unsolicited bulk email can be injected + using its facilities. + +10. Acknowledgments + + This updated memo 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 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. + + + + + + + + + +Gellens & Klensin Standards Track [Page 11] + +RFC 2476 Message Submission December 1998 + + +11. References + + [521REPLY] Durand, A. and F. Dupont, "SMTP 521 Reply Code", + RFC 1846, September 1995. + + [8BITMIME] Klensin, J., Freed, N., Rose, M., Stefferud, E. and + D. Crocker, "SMTP Service Extension for 8bit- + MIMEtransport", RFC 1652, July 1994. + + [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for + Syntax Specifications: ABNF", RFC 2234, November + 1997. + + [CHECKPOINT] Crocker, D., Freed, N. and A. Cargille, "SMTP + Service Extension for Checkpoint/Restart", RFC + 1845, September 1995. + + [CHUNKING] Vaudreuil, G., "SMTP Service Extensions for + Transmission of Large and Binary MIME Messages", + RFC 1830, August 1995. + + [CODES-EXTENSION] Freed, N., "SMTP Service Extension for Returning + Enhanced Error Codes", RFC 2034, October 1996. + + [DSN] Moore, K., "SMTP Service Extension for Delivery + Status Notifications", RFC 1891, January 1996. + + [ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E. and + D. Crocker, "SMTP Service Extensions", STD 10, RFC + 1869, November 1995. + + [ETRN] De Winter, J., "SMTP Service Extension for Remote + Message Queue Starting", RFC 1985, August 1996. + + [HEADERS] Palme, J., "Common Internet Message Headers", RFC + 2076, February 1997. + + [IPSEC] Atkinson, R., "Security Architecture for the + Internet Protocol", RFC 1825, August 1995. + + [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + + + + + + + + +Gellens & Klensin Standards Track [Page 12] + +RFC 2476 Message Submission December 1998 + + + [MESSAGE-FORMAT] Crocker, D., "Standard for the format of ARPA + Internet text messages", STD 11, RFC 822, August + 1982; + + Braden, R., Editor, "Requirements for Internet + Hosts -- Application and Support", STD 3, RFC 1123, + October 1989. + + [PIPELINING] Freed, N., "SMTP Service Extension for Command + Pipelining", RFC 2197, September 1997. + + [POP3] Myers, J. and M. Rose, "Post Office Protocol -- + Version 3", STD 53, RFC 1939, May 1996. + + [SIZE] Klensin, J., Freed, N. and K. Moore, "SMTP Service + Extension for Message Size Declaration", STD 10, + RFC 1870, November 1995. + + [SMTP-AUTH] Myers, J., "SMTP Service Extension for + Authentication", Work in Progress. + + [SMTP-CODES] Vaudreuil, G., "Enhanced Mail System Status Codes", + RFC 1893, January 1996. + + [SMTP-MTA] Postel, J., "Simple Mail Transfer Protocol", STD + 10, RFC 821, August 1982. + + Partridge, C., "Mail Routing and the Domain + System", STD 14, RFC 974, January 1986. + + Braden, R., Editor, "Requirements for Internet + Hosts -- Application and Support", STD 3, RFC 1123, + October 1989. + + + + + + + + + + + + + + + + + + +Gellens & Klensin Standards Track [Page 13] + +RFC 2476 Message Submission December 1998 + + +12. Authors' Addresses + + Randall Gellens + QUALCOMM Incorporated + 6455 Lusk Blvd. + San Diego, CA 92121-2779 + U.S.A. + + Phone: +1 619 651 5115 + Fax: +1 619 651 5334 + EMail: Randy@Qualcomm.Com + + + John C. Klensin + MCI Telecommunications + 800 Boylston St, 7th floor + Boston, MA 02199 + USA + + Phone: +1 617 960 1011 + EMail: klensin@mci.net + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gellens & Klensin Standards Track [Page 14] + +RFC 2476 Message Submission December 1998 + + +13. 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. + + 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. + + + + + + + + + + + + + + + + + + + + + + + + +Gellens & Klensin Standards Track [Page 15] + -- cgit v1.2.3