view Side-By-Side changes
Date: Tue, 09 Apr 2002 00:04:37 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Sat, 05 Sep 1998 01:34:00 GMT ETag: "2e9a0b-797b-35f09508" Accept-Ranges: bytes Content-Length: 31099 Connection: close Content-Type: text/plain Internet Draft: Message Submission Network Working Group R. GellensDocument: draft-gellens-submit-12.txtRequest for Comments: 2476 QUALCOMMExpires: 4 March 1999Category: Standards Track J. Klensin MCI4 SeptemberDecember 1998 Message Submission Status of thisMemo:Memo This documentisspecifies an InternetDraft. Internet Drafts are working documents ofstandards track protocol for the InternetEngineering Task Force (IETF), its Areas,community, andits Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents validrequests discussion and suggestions fora 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 orimprovements. Please refer tocite them other than as a "working draft" or "work in progress." To learnthe currentstatusedition ofany 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). Comments: Public comments should be sent totheIETF Submit mailing list, <ietf-submit@imc.org>. To subscribe, send a message containing SUBSCRIBE to <ietf-submit-request@imc.org>. This list will remain active after publication. Private comments may be sent to"Internet Official Protocol Standards" (STD 1) for theauthors.standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society1998.(1998). All Rights Reserved.Gellens & Klensin Expires March 1999 [Page 1] Internet Draft Message Submission September 1998Table 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' . . . . . . . . . . . . . . . . . . . . . .109 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 . . . . . . . . . . . . . . . . . . .1110 9. Security Considerations . . . . . . . . . . . . . . . . . . 11 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 12.Full Copyright StatementAuthors' Addresses . . . . . . . . . . . . . . . . .13 13. Authors' Addresses. . . . 14 13. Full Copyright Statement . . . . . . . . . . . . . . . . .1415 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).Gellens & Klensin Expires March 1999 [Page 2] Internet Draft Message Submission September 1998Messages 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 deliversGellens & Klensin Expires March 1999 [Page 3] Internet Draft Message Submission September 1998them 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 thesplit-MUAsplit- 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.All example domainsExamples use"gork" asthetop-level'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.Gellens & Klensin Expires March 1999 [Page 4] Internet Draft Message Submission September 1998NOTE: 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, MAILFROM <>,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]SHOULD be supported.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 mayGellens & Klensin Expires March 1999 [Page 5] Internet Draft Message Submission September 1998cause 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 arefully-qualified.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.Gellens & Klensin Expires March 1999 [Page 6] Internet Draft Message Submission September 1998Reply 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'sales.foo.gork').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:Gellens & Klensin Expires March 1999 [Page 7] Internet Draft Message Submission September 19986.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,status,an indication as to theextension'suse of the extension on the submit port, and a reference:Gellens & Klensin Expires March 1999 [Page 8] Internet Draft Message Submission September 1998RFC NameStatusSubmission Reference ---- ------------------------------- ------------------ 2197 PipeliningDSSHOULD [PIPELINING] 2034 Error CodesPSSHOULD [CODES-EXTENSION] 1985 ETRNPSMUST NOT [ETRN] 1893 Extended CodesPSSHOULD [SMTP-CODES] 1891 DSNPSSHOULD [DSN] 1870 SizeSMAY [SIZE] 1846 521EMUST NOT [521REPLY] 1845 CheckpointEMAY [Checkpoint] Gellens & Klensin Standards Track [Page 8] RFC 2476 Message Submission December 1998 1830 BinaryEMAY [CHUNKING] 1652 8-bit MIMEDSSHOULD [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. Itallows 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.Gellens & Klensin Expires March 1999 [Page 9] Internet Draft Message Submission September 19988.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][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.Gellens & Klensin Expires March 1999 [Page 10] Internet Draft Message Submission September 1998NOTE: Unconditionally resolving aliases could be harmful. For example, ifwww.ab.gorkwww.example.net andftp.ab.gorkftp.example.net are both aliases formail.ab.gork,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'J.Random.User'' 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.xyz.gork'' squeeky.sales.example.net' as'zyx.gork''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.bar.gork''*.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 updateddraftmemo 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,Gellens & Klensin Expires March 1999 [Page 11] Internet Draft Message Submission September 1998Ned 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]A.Durand, A. and F. Dupont, "SMTP 521 Reply Code", RFC 1846, September1995, <ftp://ftp.isi.edu/in-notes/rfc1846.txt>1995. [8BITMIME]J.Klensin,N.J., Freed,M.N., Rose,E.M., Stefferud, E. and D. Crocker, "SMTP Service Extension for8bit-MIMEtransport",8bit- MIMEtransport", RFC 1652, July1994, <ftp://ftp.isi.edu/in-notes/rfc1652.txt>1994. [ABNF]D.Crocker,Ed.,D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November1997, <ftp://ftp.isi.edu/in-notes/rfc2234.txt>1997. [CHECKPOINT]D.Crocker,N.D., Freed, N. and A. Cargille, "SMTP Service Extension forCheckpoint/Restart,Checkpoint/Restart", RFC 1845, September1995, <ftp://ftp.isi.edu/in-notes/rfc1845.txt>1995. [CHUNKING]G.Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 1830, August1995, <ftp://ftp.isi.edu/in-notes/rfc1830.txt>1995. [CODES-EXTENSION]N.Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October1996, <ftp://ftp.isi.edu/in-notes/rfc2034.txt>1996. [DSN]K.Moore, K., "SMTP Service Extension for Delivery StatusNotifications,Notifications", RFC 1891, January1996, <ftp://ftp.isi.edu/in-notes/rfc1891.txt>1996. [ESMTP]J.Klensin,N.J., Freed,M.N., Rose,E.M., Stefferud, E. and D. Crocker, "SMTP Service Extensions", STD 10, RFC 1869, November1995, <ftp://ftp.isi.edu/in-notes/rfc1869.txt>1995. [ETRN]J.De Winter, J., "SMTP Service Extension for Remote Message Queue Starting", RFC 1985, August1996, <ftp://ftp.isi.edu/in-notes/rfc1985.txt>1996. [HEADERS]J.Palme, J., "Common Internet Message Headers", RFC 2076, February1997, <ftp://ftp.isi.edu/in-notes/rfc2076.txt>1997. [IPSEC]R.Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, August1995, <ftp://ftp.isi.edu/in-notes/rfc1825.txt>1995. [KEYWORDS]S.Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March1997, <ftp://ftp.isi.edu/in-notes/rfc2119.txt>1997. Gellens & KlensinExpires March 1999Standards Track [Page 12]Internet DraftRFC 2476 Message SubmissionSeptemberDecember 1998 [MESSAGE-FORMAT]D.Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August1982, <ftp://ds.internic.net/rfc/rfc822.txt>; R.1982; Braden, R., Editor, "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October1989, <ftp://ftp.isi.edu/in-notes/rfc1123.txt>1989. [PIPELINING]N.Freed, N., "SMTP Service Extension for Command Pipelining", RFC 2197, September1997, <ftp://ftp.isi.edu/in-notes/rfc2197.txt>1997. [POP3]J.Myers, J. and M. Rose, "Post Office Protocol -- Version 3", STD 53, RFC 1939, May1996, <ftp://ftp.isi.edu/in-notes/rfc1939.txt>1996. [SIZE]J.Klensin,N.J., Freed, N. and K. Moore, "SMTP Service Extension for Message SizeDeclaration,Declaration", STD 10, RFC 1870, November1995, <ftp://ftp.isi.edu/in-notes/rfc1870.txt>1995. [SMTP-AUTH]J.Myers, J., "SMTP Service Extension for Authentication",workWork inprogress, <ftp://ftp.ietf.org/internet-drafts/draft-myers-smtp-auth-11.txt>Progress. [SMTP-CODES]G.Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, January1996, <ftp://ftp.isi.edu/in-notes/rfc1893.txt>1996. [SMTP-MTA]J.Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August1982, <ftp://ds.internic.net/rfc/rfc821.txt>; C.1982. Partridge, C., "Mail Routing and the Domain System", STD 14, RFC 974, January1986, <ftp://ds.internic.net/rfc/rfc974.txt>; R.1986. Braden, R., Editor, "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October1989, <ftp://ftp.isi.edu/in-notes/rfc1123.txt>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 Society1998.(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 March 1999 [Page 13] Internet Draft Message Submission September 1998The 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 USAGellens & KlensinExpires March 1999Standards Track [Page14]15] ----