Internet-Draft 6409 update November 2023
Levine Expires 22 May 2024 [Page]
Network Working Group
6409 (if approved)
Intended Status:
Standards Track
J. Levine
Standcore LLC

Update to Message Submission for Mail


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

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.

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

Table 1: Recent SMTP extensions applicable to submission
Keyword Name Submission Reference
MT-PRIORITY Priority Message Handling MAY [RFC6710]
SMTPUTF8 Internationalized email address SHOULD [RFC6531]
RRVS Require Recipient Valid Since MAY [RFC7293]

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

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.

9. Normative References

Resnick, P., "Internet Message Format", Work in Progress, Internet-Draft, draft-ietf-emailcore-rfc5322bis-08, , <>.
Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, DOI 10.17487/RFC6409, , <>.

10. Informative References

Klensin, J. C., "Simple Mail Transfer Protocol", Work in Progress, Internet-Draft, draft-ietf-emailcore-rfc5321bis-20, , <>.
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Yao, J. and W. Mao, "SMTP Extension for Internationalized Email", RFC 6531, DOI 10.17487/RFC6531, , <>.
Melnikov, A. and K. Carlberg, "Simple Mail Transfer Protocol Extension for Message Transfer Priorities", RFC 6710, DOI 10.17487/RFC6710, , <>.
Mills, W. and M. Kucherawy, "The Require-Recipient-Valid-Since Header Field and SMTP Service Extension", RFC 7293, DOI 10.17487/RFC7293, , <>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <>.
Fenton, J., "SMTP Require TLS Option", RFC 8689, DOI 10.17487/RFC8689, , <>.

Appendix A. Major Changes to RFC 6409

Author's Address

John Levine
Standcore LLC