Network Working Group J. Levine Internet-Draft Standcore LLC Updates: 6409 (if approved) 19 November 2023 Intended status: Standards Track Expires: 22 May 2024 Update to Message Submission for Mail draft-levine-rfc6409bis-02 Abstract This memo adds updated advice for e-mail message submission. This memo also offers guidance to software that constructs a message envelope from a message's headers prior to submission. 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 https://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 22 May 2024. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Levine Expires 22 May 2024 [Page 1] Internet-Draft 6409 update November 2023 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions Used in This Document . . . . . . . . . . . . . . 2 3. Interaction with SMTP Extensions . . . . . . . . . . . . . . 2 4. Message Modifications . . . . . . . . . . . . . . . . . . . . 3 4.1. Adjust Recipient Headers . . . . . . . . . . . . . . . . 3 5. Generating SMTP Commands from Message Header Fields . . . . . 3 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 9. Normative References . . . . . . . . . . . . . . . . . . . . 5 10. Informative References . . . . . . . . . . . . . . . . . . . 5 Appendix A. Major Changes to RFC 6409 . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction Message submission [RFC6409] prepares a message for [I-D.ietf-emailcore-rfc5321bis] SMTP mail transmisson. This memo provides updated advice for submission agents. This memo also offers guidance to software that constructs a message envelope from a message's headers prior to submission. 2. Conventions Used in This Document Examples use the 'example.net' domain. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Interaction with SMTP Extensions The following table lists Standards Track and Experimental SMTP extensions published since [RFC6409] that are applicable to message submission, | Do we need to add anything else to this table? Levine Expires 22 May 2024 [Page 2] Internet-Draft 6409 update November 2023 +=============+===========================+============+===========+ | Keyword | Name | Submission | Reference | +=============+===========================+============+===========+ | MT-PRIORITY | Priority Message Handling | MAY | [RFC6710] | +-------------+---------------------------+------------+-----------+ | SMTPUTF8 | Internationalized email | SHOULD | [RFC6531] | | | address | | | +-------------+---------------------------+------------+-----------+ | RRVS | Require Recipient Valid | MAY | [RFC7293] | | | Since | | | +-------------+---------------------------+------------+-----------+ | REQUIRETLS | Require TLS | MAY | [RFC8689] | +-------------+---------------------------+------------+-----------+ Table 1: Recent SMTP extensions applicable to submission 4. Message Modifications As described in Section 8 of [RFC6409], sites MAY modify submissions to ensure compliance with standards and site policy. This section describes additional modifications that are often considered useful. 4.1. Adjust Recipient Headers If the message contains a Bcc header field, the MSA SHOULD delete it to avoid leaking the address to other recipients. If the message contains neither a To nor a Cc header field, the MSA MAY add a Bcc header field containing no additional information, or containing only an empty address group. While [I-D.ietf-emailcore-rfc5322bis] allows messages that have no recipient headers, MUAs often display them poorly. 5. Generating SMTP Commands from Message Header Fields Some systems extract sender and recipient addresses from a [I-D.ietf-emailcore-rfc5322bis] header section without other information in a mail submission protocol, or otherwise generate SMTP commands from Internet Message Format header fields when such a message is initially created. There are problems with this approach. For example, there have been repeated problems with proper handling of "bcc" copies and redistribution lists when information that conceptually belongs to the mail envelope is not separated early in processing from header field information (and kept separate). Levine Expires 22 May 2024 [Page 3] Internet-Draft 6409 update November 2023 It is recommended that an MUA provide its MSA with an envelope separate from the message itself. However, if the envelope is not supplied, the envelope SHOULD be generated as follows: 1. Each recipient address from a TO, CC, or BCC header field SHOULD be copied to a RCPT command This includes any addresses listed in a [I-D.ietf-emailcore-rfc5322bis] "group". Any BCC header fields SHOULD then be removed from the header section. Once this process is completed, the remaining header fields SHOULD be checked to verify that at least one TO or CC header field remains. If none do, then a BCC header field with no additional information SHOULD be inserted. 2. The return address in the MAIL command SHOULD, if possible, be derived from the system's identity for the submitting (local) user, and the "From:" header field otherwise. If there is a system identity available, it SHOULD also be copied to the Sender header field if it is different from the address in the From header field. (Any Sender header field that was already there SHOULD be removed.) Systems may provide a way for submitters to override the envelope return address, but may want to restrict its use to privileged users. This will not prevent mail forgery, but may lessen its incidence. Submission based on message header field information alone MUST NOT be used to gateway a message from a foreign (non-SMTP) mail system into an SMTP environment. Additional information to construct an envelope must come from some source in the other environment, whether supplemental header fields or the foreign system's envelope. Attempts to gateway messages using only their header "To" and "Cc" fields have repeatedly caused mail loops and other behavior adverse to the proper functioning of the Internet mail environment. These problems have been especially common when the message originates from an Internet mailing list and is distributed into the foreign environment using envelope information. When these messages are then processed by a header-section-only remailer, loops back to the Internet environment (and the mailing list) are almost inevitable. 6. Security Considerations This memo does not change the security considerations in [RFC6409]. 7. IANA Considerations This memo makes no reqeuests to IANA. TBD Levine Expires 22 May 2024 [Page 4] Internet-Draft 6409 update November 2023 8. Acknowledgments We thank John Klensin, Pete Resnick, and TBD for helpful comments. 9. Normative References [I-D.ietf-emailcore-rfc5322bis] Resnick, P., "Internet Message Format", Work in Progress, Internet-Draft, draft-ietf-emailcore-rfc5322bis-08, 20 September 2023, . [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, . 10. Informative References [I-D.ietf-emailcore-rfc5321bis] Klensin, J. C., "Simple Mail Transfer Protocol", Work in Progress, Internet-Draft, draft-ietf-emailcore-rfc5321bis- 20, 16 November 2023, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized Email", RFC 6531, DOI 10.17487/RFC6531, February 2012, . [RFC6710] Melnikov, A. and K. Carlberg, "Simple Mail Transfer Protocol Extension for Message Transfer Priorities", RFC 6710, DOI 10.17487/RFC6710, August 2012, . [RFC7293] Mills, W. and M. Kucherawy, "The Require-Recipient-Valid- Since Header Field and SMTP Service Extension", RFC 7293, DOI 10.17487/RFC7293, July 2014, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Levine Expires 22 May 2024 [Page 5] Internet-Draft 6409 update November 2023 [RFC8689] Fenton, J., "SMTP Require TLS Option", RFC 8689, DOI 10.17487/RFC8689, November 2019, . Appendix A. Major Changes to RFC 6409 * Add extensions SMTPUTF8, MT-PRIORITY, RRVS, REQUIRETLS to Table 1 * Add Section 4.1 * Import Section 5 from RFC 5321 Author's Address John Levine Standcore LLC Email: standards@standcore.com Levine Expires 22 May 2024 [Page 6]