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]