doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

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,
+   <ietf-submit@imc.org>.  To subscribe, send a message containing
+   SUBSCRIBE to <ietf-submit-request@imc.org>.  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]
+