YAM R. Gellens Internet-Draft QUALCOMM Incorporated Obsoletes: 4409 (if approved) J. Klensin Intended status: Standards Track May 6, 2011 Expires: November 7, 2011 Message Submission for Mail draft-ietf-yam-rfc4409bis-00 Abstract This memo splits message submission from message relay, allowing each service to operate according to its own rules (for security, policy, etc.), and specifies what actions are to be taken by a submission server. Message relay is unaffected, and continues to use SMTP [SMTP-MTA] over port 25. When conforming to this document, message submission uses the protocol specified here, normally over port 587. This separation of function offers a number of benefits, including the ability to apply specific security or policy requirements. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 7, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. Gellens & Klensin Expires November 7, 2011 [Page 1]
Internet-Draft Message Submission for Mail May 2011 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Gellens & Klensin Expires November 7, 2011 [Page 2]
Internet-Draft Message Submission for Mail May 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Discussion List . . . . . . . . . . . . . . . . . . . . . 5 1.2. Note to IESG and/or Document Shepherd . . . . . . . . . . 5 2. Document Information . . . . . . . . . . . . . . . . . . . . . 5 2.1. Definitions of Terms Used in This Memo . . . . . . . . . . 6 2.2. Conventions Used in This Document . . . . . . . . . . . . 6 3. Message Submission . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Submission Identification . . . . . . . . . . . . . . . . 7 3.2. Message Rejection and Bouncing . . . . . . . . . . . . . . 7 3.3. Authorized Submission . . . . . . . . . . . . . . . . . . 8 4. Mandatory Actions . . . . . . . . . . . . . . . . . . . . . . 8 4.1. General Submission Rejection Code . . . . . . . . . . . . 9 4.2. Ensure All Domains Are Fully-Qualified . . . . . . . . . . 9 4.3. Require Authentication . . . . . . . . . . . . . . . . . . 9 5. Recommended Actions . . . . . . . . . . . . . . . . . . . . . 9 5.1. Enforce Address Syntax . . . . . . . . . . . . . . . . . . 9 5.2. Log Errors . . . . . . . . . . . . . . . . . . . . . . . . 10 5.3. Apply Shorter Timeouts . . . . . . . . . . . . . . . . . . 10 6. Optional Actions . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Enforce Submission Rights . . . . . . . . . . . . . . . . 10 6.2. Enforce Permissions . . . . . . . . . . . . . . . . . . . 11 6.3. Check Message Data . . . . . . . . . . . . . . . . . . . . 11 6.4. Support for the Postmaster Address . . . . . . . . . . . . 11 6.5. Adjust Character Encodings . . . . . . . . . . . . . . . . 11 7. Interaction with SMTP Extensions . . . . . . . . . . . . . . . 12 8. Message Modifications . . . . . . . . . . . . . . . . . . . . 13 8.1. Add 'Sender' . . . . . . . . . . . . . . . . . . . . . . . 13 8.2. Add 'Date' . . . . . . . . . . . . . . . . . . . . . . . . 14 8.3. Add 'Message-ID' . . . . . . . . . . . . . . . . . . . . . 14 8.4. Transfer Encode . . . . . . . . . . . . . . . . . . . . . 14 8.5. Sign the Message . . . . . . . . . . . . . . . . . . . . . 14 8.6. Encrypt the Message . . . . . . . . . . . . . . . . . . . 14 8.7. Resolve Aliases . . . . . . . . . . . . . . . . . . . . . 14 8.8. Header Rewriting . . . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 12.1. Normative References . . . . . . . . . . . . . . . . . . . 16 12.2. Informative References . . . . . . . . . . . . . . . . . . 17 Appendix A. Major Changes from RFC 4409 . . . . . . . . . . . . . 19 Appendix B. Note on References . . . . . . . . . . . . . . . . . 19 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 19 C.1. Changes between RFC 4409 and version-00 of this document . . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Gellens & Klensin Expires November 7, 2011 [Page 3]
Internet-Draft Message Submission for Mail May 2011 1. Introduction 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 that accepts message submissions from MUAs is termed a Message Submission Agent (MSA). In order to permit unconstrained communications, SMTP is not often authenticated during message relay. Authentication and authorization of initial submissions have become increasingly important, driven by changes in security requirements and rising expectations that submission servers take responsibility for the message traffic they originate. For example, due to the prevalence of machines that have worms, viruses, or other malicious software that generate large amounts of spam, many sites now prohibit outbound traffic on the standard SMTP port (port 25), funneling all mail submissions through submission servers. In addition to authentication and authorization issues, messages being submitted are in some cases finished (complete) messages, and in other cases are unfinished (incomplete) in one or more aspects. Unfinished messages may need to be completed to ensure they conform to the Message Format specification [MESSAGE-FORMAT], and related 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 (e.g., 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, e.g., to conceal local name or address spaces. 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 do the following: o Implement security policies and guard against unauthorized mail relaying or injection of unsolicited bulk mail Gellens & Klensin Expires November 7, 2011 [Page 4]
Internet-Draft Message Submission for Mail May 2011 o Implement authenticated submission, including off-site submission by authorized users such as travelers o Separate the relevant software code differences, thereby making each code base more straightforward and allowing for different programs for relay and submission o Detect configuration problems with a site's mail clients o 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. 1.1. Discussion List [[anchor3: RFC Editor: Please remove this section before publication.]] This document is being discussed in the IETF YAM Working Group. 1.2. Note to IESG and/or Document Shepherd [[anchor5: RFC Editor: Please remove this section before publication.]] RFC 4409 was published in April 2006, so the "time in place" requirement of RFC 2026 has been satisfied. Message Submission on port 587 has seen significant deployment over the past 8-10 years, becoming widespread in the past 2-3 years. There are several reasons for this, such as decisions by many ISPs and organizations in general to block outbound port 25 (except by their own border MTAs), and consequently to support 587 with authentication, as well as recognition of the need to apply different policies to submission and relay. The effort required to reissue and process this document is justified by the need to update and clarify several references and by additional clarifying text to support email internationalization work. 2. Document Information Gellens & Klensin Expires November 7, 2011 [Page 5]
Internet-Draft Message Submission for Mail May 2011 2.1. Definitions of Terms Used in This Memo Many of the concepts and terms used in this document are defined in [SMTP-MTA]; familiarity with those documents is assumed here. Fully-Qualified Containing or consisting of a domain that can be globally resolved using the Domain Name Service; that is, not a local alias or partial specification. Message Submission Agent (MSA) A process that conforms to this specification. An MSA 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 that conforms to [SMTP-MTA]. An MTA 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 that acts (often on behalf of a user and with a user interface) to compose and submit new messages, and process delivered messages. For delivered messages, the receiving MUA may obtain and process the message according to local conventions or, in what is commonly referred to as a split-MUA model, Post Office Protocol [POP3] or IMAP [IMAP4] is used to access delivered messages, whereas the protocol defined here (or SMTP) is used to submit messages. 2.2. Conventions Used in This Document In examples, "C:" is used to indicate lines sent by the client, and "S:" indicates those sent by the server. Line breaks within a command example are for editorial purposes only. 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]. Gellens & Klensin Expires November 7, 2011 [Page 6]
Internet-Draft Message Submission for Mail May 2011 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], with additional restrictions or allowances as specified here. Although 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 MTAs to reject all RCPT commands for messages that do not reference local users, and configure their MSA to reject all message submissions that do not come from authorized users, with authorization based either on authenticated identity or the submitting endpoint being within a protected IP environment. 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 command. Note that a null return path, that is, MAIL FROM:<>, is permitted and MUST NOT in itself be cause for rejecting a message. (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 that 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 Gellens & Klensin Expires November 7, 2011 [Page 7]
Internet-Draft Message Submission for Mail May 2011 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 needs to maintain a queue of messages it has submitted, and match bounces to them. Note that many contemporary MUAs do not have this capability. 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 other tunnels, and prior POP authentication. Authenticated SMTP [SMTP-AUTH] has seen widespread deployment. It allows the MSA to determine an authorization identity for the message submission, one that is not tied to other protocols. IP address restrictions are very widely implemented, but do not allow for travelers and similar situations, and can be easily spoofed unless all transport paths between the MUA and MSA are trustworthy. Secure IP [IPSEC], and other encrypted and authenticated tunneling techniques, can also be used and provide additional benefits of protection against eavesdropping and traffic analysis. Requiring a POP [POP3] authentication (from the same IP address) within some amount of time (e.g., 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 previously authorized user. Since it is dependent on the MUA's IP addresses, this technique is substantially as subject to IP address spoofing as validation based on known IP addresses alone (see above). 4. Mandatory Actions An MSA MUST do all of the following: Gellens & Klensin Expires November 7, 2011 [Page 8]
Internet-Draft Message Submission for Mail May 2011 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, RCPT, or DATA command that contains something improper. 4.2. Ensure All Domains Are Fully-Qualified The MSA MUST ensure that all domains in the SMTP envelope are fully- qualified. If the MSA examines or alters the message text in any 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, RCPT, or DATA command that contains improper domain references. A frequent local convention is to accept single-level domains (e.g., 'sales') and then to expand the reference by adding the remaining portion of the domain name (e.g., to 'sales.example.net'). Local conventions that permit single-level domains SHOULD reject, rather than expand, incomplete multi-level domains (e.g., 'squeaky.sales'), since such expansion is particularly risky. 4.3. Require Authentication The MSA MUST by default issue an error response to the MAIL command if the session has not been authenticated using [SMTP-AUTH], unless it has already independently established authentication or authorization (such as being within a protected subnetwork). Section 3.3 discusses authentication mechanisms. Reply code 530 [SMTP-AUTH] is used for this purpose. 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 SMTP 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 Gellens & Klensin Expires November 7, 2011 [Page 9]
Internet-Draft Message Submission for Mail May 2011 syntax in address header fields. Reply code 501 is to be used to reject a MAIL or RCPT command that contains a detectably improper address. When addresses are resolved after submission of the message body, reply code 554 (with a suitable enhanced status code from [SMTP-CODES]) is 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. 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. Note that it is important to impose limits on such logging to prevent certain forms of denial of service (DoS) attacks. 5.3. Apply Shorter Timeouts The timeouts specified in Section 4.5.3.2 of RFC 5321 [SMTP-MTA] are designed to deal with the many types of situations that can be encountered on the public Internet. The relationship among clients and servers corresponding to this specification is typically much closer and more predictable. Submission clients behave differently from relay client in some areas, especially tolerance for time- outs. In practice, message submission clients tend to have short time-outs (perhaps 2-5 minutes for a reply to any command). Submission servers SHOULD respond to any command (even DATA) in fewer than 2 minutes. 6. Optional Actions The MSA MAY do any of the following: 6.1. Enforce Submission Rights The MSA MAY issue an error response to a MAIL 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). Gellens & Klensin Expires November 7, 2011 [Page 10]
Internet-Draft Message Submission for Mail May 2011 Reply code 550 with an appropriate enhanced status code per [SMTP-CODES], such as 5.7.1, is used for this purpose. 6.2. Enforce Permissions The MSA MAY issue an error response to a RCPT command if inconsistent with the permissions given to the user (if the session has been authenticated). Reply code 550 with an appropriate enhanced status code per [SMTP-CODES], such as 5.7.1, is used for this purpose. 6.3. 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 an appropriate enhanced status code per [SMTP-CODES] (such as 5.7.1) is used to reject based on the submitting user. Reply code 550 with an appropriate enhanced status code (such as 5.7.0) is used if the message violates site policy. 6.4. Support for the Postmaster Address If appropriate under local conditions and to facilitate conformance with the "postmaster" requirements of [SMTP-MTA], the MSA MAY permit a reduced degree of authentication for mail addressed to the "postmaster" (or one of its alternate spelling forms, see [SMTP-MTA]), in one or more domains, as compared to requirements enforced for other addresses. Among other benefits, this provides an address of last resort that can be used by authorized users to report problems that otherwise prevent them from submitting mail. 6.5. Adjust Character Encodings Subject to limits imposed by other protocols and specifications, the MSA MAY convert among character sets or string encodings to improve message usefulness, likelihood of delivery, or conformance with other specifications or recommendations. Such conversions MAY include, when necessary, replacement of addresses whose encoding does not conform to RFC 5321 with ones that do, using information available out of band. Gellens & Klensin Expires November 7, 2011 [Page 11]
Internet-Draft Message Submission for Mail May 2011 7. Interaction with SMTP Extensions The following table lists standards-track and Experimental SMTP extensions whose documents do not explicitly specify their applicability to this protocol. Listed are the EHLO keyword, name, an indication as to the use of the extension on the submit port, and a reference: +------------------+------------------+-----------+-----------------+ | Keyword | Name | Submissio | Reference | | | | n | | +------------------+------------------+-----------+-----------------+ | PIPELINING | Pipelining | SHOULD | [PIPELINING] | | ENHANCEDSTATUSCO | Enhanced Status | SHOULD | [CODES-EXTENSIO | | DES | Codes | | N] | | ETRN | Extended Turn | MUST NOT | [ETRN] | | ... | Extended Codes | SHOULD | [SMTP-CODES] | | DSN | Delivery Status | SHOULD | [DSN] | | | Notification | | | | SIZE | Message size | MAY | [SIZE] | | ... | 521 reply code | MUST NOT | [REPLY-521] | | CHECKPOINT | Checkpoint/Resta | MAY | [CHECKPOINT] | | | rt | | | | BINARYMIME | Binary MIME | MAY | [CHUNKING] | | CHUNKING | Chunking | MAY | [CHUNKING] | | 8BITMIME | Use 8-bit data | SHOULD | [RFC6152] | | AUTH | Authentication | MUST | [SMTP-AUTH] | | STARTTLS | Start TLS | MAY | [Start-TLS] | | NO-SOLICITING | Notification of | MAY | [RFC3865] | | | no soliciting | | | | MTRK | Message Tracking | MAY | [Msg-Track] | | ATRN | On-Demand Relay | MUST NOT | [RFC2645] | | DELIVERBY | Deliver By | MAY | [RFC2852] | | CONPERM | Content | MAY | [RFC4141] | | | Conversion | | | | | Permission | | | | CONNEG | Content | MAY | [RFC4141] | | | Conversion | | | | | Negotiation | | | +------------------+------------------+-----------+-----------------+ Table 1 Future SMTP extensions SHOULD explicitly specify if they are valid on the Submission port. Some SMTP extensions are especially useful for message submission: Gellens & Klensin Expires November 7, 2011 [Page 12]
Internet-Draft Message Submission for Mail May 2011 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 to unauthenticated senders than is needed [PIPELINING] SHOULD be supported by the MSA. [SMTP-AUTH] allows the MSA to validate the authority and determine the identity of the submitting user and MUST be supported by the MSA. 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 that 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. Any message forwarded or delivered by the MSA MUST conform to the requirements of [SMTP-MTA] and [MESSAGE-FORMAT] or the requirements permited by extensions that are supported by the MSA and accepted by the next-hop server. If an incoming message includes a DKIM [RFC4871][RFC5672], PGP [RFC4880], S/MIME [RFC5751], or other signature, sites SHOULD consider what effect message modifications will have on the validity of the signature, and MAY use the presence or absence of a signature as a criterion when deciding what, if any, modifications to make. 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 Gellens & Klensin Expires November 7, 2011 [Page 13]
Internet-Draft Message Submission for Mail May 2011 in fact a valid mail address. 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 SHOULD add or replace the 'Message-ID' field, if it lacks it, or it is not valid syntax (as defined by [MESSAGE-FORMAT]). Note that a number of clients still do not generate Message-ID fields. 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, for example, 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 SMTP 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. Gellens & Klensin Expires November 7, 2011 [Page 14]
Internet-Draft Message Submission for Mail May 2011 8.8. Header Rewriting The MSA MAY rewrite local parts and/or domains in the SMTP envelope, and optionally in address fields of the header, according to local policy. For example, a site may prefer to rewrite 'JRU' as 'J.Random.User' in order to hide login names, and/or to rewrite 'squeaky.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 that strips the left-most element of the domain, if the complete domain matches '*.foo.example.net', would be acceptable. The MSA MUST NOT rewrite a forward-pointing (destination) address in a way that violates the constraints of [SMTP-MTA] on modifications of local-parts. Addressing and encoding changes carried out in conjunction with the action of Section 6.5 do not violate this principle if the MSA has sufficient information available to successfully and accurately apply the substitution. 9. Security Considerations Separation of submission and relay of messages allows 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 mail servers such that the MSA requires authentication before accepting a message, and the MTA rejects all RCPT commands 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. Section 3 includes further discussion of issues with some authentication methods. Gellens & Klensin Expires November 7, 2011 [Page 15]
Internet-Draft Message Submission for Mail May 2011 Section 5.2 includes a cautionary note that unlimited logging can enable certain forms of denial of service attacks. 10. IANA Considerations The table in Table 1 has been corrected (reference for NO-SOLICITING) and extended (ATRN, DELIVERBY, CONPEM, and CONNEG). The registry should be updated to reflect the changed and new entries. Entries in the registry that do not appear in the table above are correct and should not be altered. [[anchor32: Note to RFC Editor: please change "should be updated" to "has been updated" after this change is made.]] 11. Acknowledgments The preparation and development of the current version of this specification was stimulated by discussions in the IETF YAM and EAI Working Groups. Nathaniel Borenstein and Barry Leiba were instrumental in the development of this update to RFC 2476. The original memo (RFC 2476) was developed 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 that document 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. 12. References 12.1. Normative References [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [SMTP-AUTH] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service Extension for Authentication", RFC 4954, July 2007. [SMTP-MTA] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, Gellens & Klensin Expires November 7, 2011 [Page 16]
Internet-Draft Message Submission for Mail May 2011 October 2008. 12.2. Informative References [CHECKPOINT] Crocker, D., Freed, N., and Cargille, A., "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 3030, December 2000. [CODES-EXTENSION] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996. [DSN] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461. [ETRN] De Winter, J., "SMTP Service Extension for Remote Message Queue Starting", RFC 1985, August 1996. [IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003. [IPSEC] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [MESSAGE-FORMAT] ResnicK, P., Ed., "Internet Message Format", RFC 5322, October 2008. An update to RFC 5322 is in progress. This document should be checked just before publication to be sure that references are up-to-date and/or this comment modified as needed. [Msg-Track] Allman, E. and T. Hansen, "SMTP Service Extension for Message Tracking", RFC 3885, September 2004. [PIPELINING] Freed, N., "SMTP Service Extension for Command Pipelining", RFC 2920, STD 60, September 2000. Gellens & Klensin Expires November 7, 2011 [Page 17]
Internet-Draft Message Submission for Mail May 2011 [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", RFC 1939, May 1996. [REPLY-521] Durand, A. and F. Dupont, "SMTP 521 Reply Code", RFC 1846, September 1995. [RFC2645] Gellens, R., "ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP Addresses", RFC 2645, August 1999. [RFC2852] Newman, D., "Deliver By SMTP Service Extension", RFC 2852, June 2000. [RFC3865] Malamud, C., "A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension", RFC 3865, September 2004. [RFC4141] Toyoda, K. and D. Crocker, "SMTP and MIME Extensions for Content Conversion", RFC 4141, November 2005. [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007. [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007. [RFC5672] Crocker, D., "RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update", RFC 5672, August 2009. [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010. [RFC6152] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extension for 8-bit MIME transport", RFC 6152, March 2011. [SIZE] Klensin, J., Freed, N., and K. Moore, "SMTP Service Extension for Message Size Declaration", RFC 1870, STD 10, November 1995. [SMTP-CODES] Vaudreuil, G,., "Enhanced Mail System Status Codes", RFC 3463, January 2003. [Start-TLS] Hoffman, P,., "SMTP Service Extension for Secure SMTP over Gellens & Klensin Expires November 7, 2011 [Page 18]
Internet-Draft Message Submission for Mail May 2011 Transport Layer Security", RFC 3207, February 2002. Appendix A. Major Changes from RFC 4409 The protocol specified by this document is not substantively different from that of RFC 4409. However, the present specification contains several clarifications and updates to reflect changes and revisions to other documents subsequent to the publication of RFC 4409. The following specific changes may be of interest to some readers. o Updated several references to reflect more recent versions of the various specifications. As part of this, reclassified RFC 4954 to a normative reference (SMTP AUTH is a MUST for 4409 and this specification). o Updated the text in Section 7 to reflect the existence and partial population of the registry and the included table (Table 1) to correct one entry and add others. See Section 10 for more information. o Added new text (Section 5.3 to clarify that Submission Servers should respond quickly. o Added text to make it explicit that character encoding changes are permitted. o Added text to make it clear that modifications to signed messages may cause problems and that they should be carefully considered. Appendix B. Note on References RFC 4897 statement/ disclaimer follows. [[anchor37: RFC Editor: please seek advice from the IESG as to whether the statement should be removed for publication.]] RFCs 4954, 5321, and 5322 are not Full Standards, so their use in citations from this document are downward references. The protocols that they describe are widely-deployed, interoperable, stable, and successful, so the references are justified. Appendix C. Change Log RFC Editor: Please remove this Section Gellens & Klensin Expires November 7, 2011 [Page 19]
Internet-Draft Message Submission for Mail May 2011 C.1. Changes between RFC 4409 and version-00 of this document This subsection identifies changes from RFC 4409 to the first posted version of this document that are of an editorial or procedural nature insufficient to justify inclusion in Appendix A or that may need clarification for the WG. o Changed reference identifiers in 4409 that started with numbers to other forms. Xml2rfc doesn't like leading numbers. o Added an RFC 4897 downgrade statement as an appendix just in case this goes through on a three-step standards process. o Started on upgrade of Acknowledgments section. o Added clarifying language to the first part and last paragraph of Section 8 to be sure that no one thinks the use of an MSA prevents the use of SMTP extensions that extend various permitted properties of messages, or that address rewriting to make message syntax conform to RFC 5321 (or whatever is permitted at the next hop) is prohibited. Authors' Addresses Randall QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121-2779 USA Email: rg+ietf@qualcomm.com John C Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA Phone: +1 617 491 5735 Email: john-ietf@jck.com Gellens & Klensin Expires November 7, 2011 [Page 20]
