summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2476.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2476.txt')
-rw-r--r--doc/rfc/rfc2476.txt843
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]
+