Update to Message Submission for Mail

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.¶

Table of Contents

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,¶

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.¶

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).¶

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¶

8. Acknowledgments

We thank John Klensin, Pete Resnick, and TBD for helpful comments.¶

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