SMTP Require TLS Option
RFC 8689

quot; subregistry of the "Simple Mail Transfer Protocol (SMTP)
   Enhanced Status Codes Registry" [SMTPStatusCodes]:

      Code:                         X.7.30
      Sample Text:                  REQUIRETLS support required
      Associated basic status code:  550
      Description:                  This indicates that the message was
                                    not able to be forwarded because it
                                    was received with a REQUIRETLS
                                    requirement and none of the SMTP
                                    servers to which the message should
                                    be forwarded provide this support.
      Reference:                    RFC 8689
      Submitter:                    J.  Fenton
      Change Controller:            IESG

   Per this document, IANA has added an entry to the "Permanent Message
   Header Field Names" subregistry of the "Message Headers" registry
   [MessageHeaders] as follows:

      Header field name:            TLS-Required
      Applicable protocol:          mail
      Status:                       standard
      Author/change controller:     IETF
      Specification document:       RFC 8689

8.  Security Considerations

   The purpose of REQUIRETLS is to give the originator of a message
   control over the security of email they send, either by conveying an
   expectation that it will be transmitted in an encrypted form over the
   wire or explicitly indicating that transport encryption is not
   required if it cannot be successfully negotiated.

   The following considerations apply to the REQUIRETLS service
   extension but not the TLS-Required header field, since messages
   specifying the header field are less concerned with transport
   security.

8.1.  Passive Attacks

   REQUIRETLS is generally effective against passive attackers who are
   merely trying to eavesdrop on an SMTP exchange between an SMTP client
   and server.  This assumes, of course, the cryptographic integrity of
   the TLS connection being used.

8.2.  Active Attacks

   Active attacks against TLS-encrypted SMTP connections can take many
   forms.  One such attack is to interfere in the negotiation by
   changing the STARTTLS command to something illegal such as XXXXXXXX.
   This causes TLS negotiation to fail and messages to be sent in the
   clear, where they can be intercepted.  REQUIRETLS detects the failure
   of STARTTLS and declines to send the message rather than send it
   insecurely.

   A second form of attack is a man-in-the-middle attack where the
   attacker terminates the TLS connection rather than the intended SMTP
   server.  This is possible when, as is commonly the case, the SMTP
   client either does not verify the server's certificate or establishes
   the connection even when the verification fails.  REQUIRETLS requires
   successful certificate validation before sending the message.

   Another active attack involves the spoofing of DNS MX records of the
   recipient domain.  An attacker with this capability could potentially
   cause the message to be redirected to a mail server under the
   attacker's own control, which would presumably have a valid
   certificate.  REQUIRETLS requires that the recipient domain's MX
   record lookup be validated either using DNSSEC or via a published
   MTA-STS policy that specifies the acceptable SMTP server hostname(s)
   for the recipient domain.

8.3.  Bad-Actor MTAs

   A bad-actor MTA along the message transmission path could
   misrepresent its support of REQUIRETLS and/or actively strip
   REQUIRETLS tags from messages it handles.  However, since
   intermediate MTAs are already trusted with the cleartext of messages
   they handle, and are not part of the threat model for transport-layer
   security, they are also not part of the threat model for REQUIRETLS.

   It should be reemphasized that since SMTP TLS is a transport-layer
   security protocol, messages sent using REQUIRETLS are not encrypted
   end-to-end and are visible to MTAs that are part of the message
   delivery path.  Messages containing sensitive information that MTAs
   should not have access to MUST be sent using end-to-end content
   encryption such as OpenPGP [RFC4880] or S/MIME [RFC8551].

8.4.  Policy Conflicts

   In some cases, the use of the TLS-Required header field may conflict
   with a recipient domain policy expressed through the DANE [RFC7672]
   or MTA-STS [RFC8461] protocols.  Although these protocols encourage
   the use of TLS transport by advertising the availability of TLS, the
   use of the "TLS-Required: No" header field represents an explicit
   decision on the part of the sender not to require the use of TLS,
   such as to overcome a configuration error.  The recipient domain has
   the ultimate ability to require TLS by not accepting messages when
   STARTTLS has not been negotiated; otherwise, "TLS-Required: No" is
   effectively directing the client MTA to behave as if it does not
   support DANE or MTA-STS.

9.  References

9.1.  Normative References

   [MailParams]
              IANA, "Mail Parameters",
              <http://www.iana.org/assignments/mail-parameters>.

   [MessageHeaders]
              IANA, "Permanent Message Header Field Names",
              <https://www.iana.org/assignments/message-headers>.

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

   [RFC3207]  Hoffman, P., "SMTP Service Extension for Secure SMTP over
              Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207,
              February 2002, <https://www.rfc-editor.org/info/rfc3207>.

   [RFC3461]  Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
              Extension for Delivery Status Notifications (DSNs)",
              RFC 3461, DOI 10.17487/RFC3461, January 2003,
              <https://www.rfc-editor.org/info/rfc3461>.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, DOI 10.17487/RFC4033, March 2005,
              <https://www.rfc-editor.org/info/rfc4033>.

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, DOI 10.17487/RFC4034, March 2005,
              <https://www.rfc-editor.org/info/rfc4034>.

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
              <https://www.rfc-editor.org/info/rfc4035>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <https://www.rfc-editor.org/info/rfc5234>.

   [RFC5248]  Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced
              Mail System Status Codes", BCP 138, RFC 5248,
              DOI 10.17487/RFC5248, June 2008,
              <https://www.rfc-editor.org/info/rfc5248>.

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              DOI 10.17487/RFC5321, October 2008,
              <https://www.rfc-editor.org/info/rfc5321>.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              DOI 10.17487/RFC5322, October 2008,
              <https://www.rfc-editor.org/info/rfc5322>.

   [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
              Verification of Domain-Based Application Service Identity
              within Internet Public Key Infrastructure Using X.509
              (PKIX) Certificates in the Context of Transport Layer
              Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
              2011, <https://www.rfc-editor.org/info/rfc6125>.

   [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
              2015, <https://www.rfc-editor.org/info/rfc7525>.

   [RFC7672]  Dukhovni, V. and W. Hardaker, "SMTP Security via
              Opportunistic DNS-Based Authentication of Named Entities
              (DANE) Transport Layer Security (TLS)", RFC 7672,
              DOI 10.17487/RFC7672, October 2015,
              <https://www.rfc-editor.org/info/rfc7672>.

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

   [RFC8314]  Moore, K. and C. Newman, "Cleartext Considered Obsolete:
              Use of Transport Layer Security (TLS) for Email Submission
              and Access", RFC 8314, DOI 10.17487/RFC8314, January 2018,
              <https://www.rfc-editor.org/info/rfc8314>.

   [RFC8461]  Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A.,
              and J. Jones, "SMTP MTA Strict Transport Security (MTA-
              STS)", RFC 8461, DOI 10.17487/RFC8461, September 2018,
              <https://www.rfc-editor.org/info/rfc8461>.

   [SMTPStatusCodes]
              IANA, "Simple Mail Transfer Protocol (SMTP) Enhanced
              Status Codes Registry", <https://www.iana.org/assignments/
              smtp-enhanced-status-codes>.

9.2.  Informative References

   [RFC1939]  Myers, J. and M. Rose, "Post Office Protocol - Version 3",
              STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996,
              <https://www.rfc-editor.org/info/rfc1939>.

   [RFC2033]  Myers, J., "Local Mail Transfer Protocol", RFC 2033,
              DOI 10.17487/RFC2033, October 1996,
              <https://www.rfc-editor.org/info/rfc2033>.

   [RFC3501]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
              4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
              <https://www.rfc-editor.org/info/rfc3501>.

   [RFC4880]  Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
              Thayer, "OpenPGP Message Format", RFC 4880,
              DOI 10.17487/RFC4880, November 2007,
              <https://www.rfc-editor.org/info/rfc4880>.

   [RFC5228]  Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email
              Filtering Language", RFC 5228, DOI 10.17487/RFC5228,
              January 2008, <https://www.rfc-editor.org/info/rfc5228>.

   [RFC5598]  Crocker, D., "Internet Mail Architecture", RFC 5598,
              DOI 10.17487/RFC5598, July 2009,
              <https://www.rfc-editor.org/info/rfc5598>.

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

   [RFC8551]  Schaad, J., Ramsdell, B., and S. Turner, "Secure/
              Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
              Message Specification", RFC 8551, DOI 10.17487/RFC8551,
              April 2019, <https://www.rfc-editor.org/info/rfc8551>.

Appendix A.  Examples

   This section is informative.

A.1.  REQUIRETLS SMTP Option

   The TLS-Required SMTP option is used to express the intention of the
   sender to have the associated message relayed using TLS.  In the
   following example, lines beginning with "C:" are transmitted from the
   SMTP client to the server, and lines beginning with "S:" are
   transmitted in the opposite direction.

    S: 220 mail.example.net ESMTP
    C: EHLO mail.example.org
    S: 250-mail.example.net Hello example.org [192.0.2.1]
    S: 250-SIZE 52428800
    S: 250-8BITMIME
    S: 250-PIPELINING
    S: 250-STARTTLS
    S: 250 HELP
    C: STARTTLS
    S: TLS go ahead

   (at this point TLS negotiation takes place.  The remainder of this
   session occurs within TLS.)

    S: 220 mail.example.net ESMTP
    C: EHLO mail.example.org
    S: 250-mail.example.net Hello example.org [192.0.2.1]
    S: 250-SIZE 52428800
    S: 250-8BITMIME
    S: 250-PIPELINING
    S: 250-REQUIRETLS
    S: 250 HELP
    C: MAIL FROM:<roger@example.org> REQUIRETLS
    S: 250 OK
    C: RCPT TO:<editor@example.net>
    S: 250 Accepted
    C: DATA
    S: 354 Enter message, ending with "." on a line by itself

   (message follows)

    C: .
    S: 250 OK
    C: QUIT

A.2.  TLS-Required Header Field

   The TLS-Required header field is used when the sender requests that
   the mail system not heed a default policy of the recipient domain
   requiring TLS.  It might be used, for example, to allow problems with
   the recipient domain's TLS certificate to be reported:

    From: Roger Reporter <roger@example.org>
    To: Andy Admin <admin@example.com>
    Subject: Certificate problem?
    TLS-Required: No
    Date: Fri, 18 Jan 2019 10:26:55 -0800
    Message-ID: <5c421a6f79c0e_d153ff8286d45c468473@mail.example.org>

    Andy, there seems to be a problem with the TLS certificate
    on your mail server. Are you aware of this?

    Roger

Acknowledgements

   The author would like to acknowledge many helpful suggestions on the
   ietf-smtp and uta mailing lists, in particular those of Viktor
   Dukhovni, Tony Finch, Jeremy Harris, Arvel Hathcock, John Klensin,
   Barry Leiba, John Levine, Chris Newman, Rolf Sonneveld, and Per
   Thorsheim.

Author's Address

   Jim Fenton
   Altmode Networks
   Los Altos, California 94024
   United States of America

   Email: fenton@bluepopcorn.net