Internet DRAFT - draft-levine-rfc6409bis
draft-levine-rfc6409bis
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, <https://datatracker.ietf.org/doc/html/
draft-ietf-emailcore-rfc5322bis-08>.
[RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail",
STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011,
<https://www.rfc-editor.org/info/rfc6409>.
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,
<https://datatracker.ietf.org/doc/html/draft-ietf-
emailcore-rfc5321bis-20>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized
Email", RFC 6531, DOI 10.17487/RFC6531, February 2012,
<https://www.rfc-editor.org/info/rfc6531>.
[RFC6710] Melnikov, A. and K. Carlberg, "Simple Mail Transfer
Protocol Extension for Message Transfer Priorities",
RFC 6710, DOI 10.17487/RFC6710, August 2012,
<https://www.rfc-editor.org/info/rfc6710>.
[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,
<https://www.rfc-editor.org/info/rfc7293>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
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,
<https://www.rfc-editor.org/info/rfc8689>.
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]
