<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
    which is available here: http://xml.resource.org. --> version='1.0' encoding='US-ASCII'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
    There has to be one entity for each item to be referenced.
    An alternate method (rfc include) is described in the references. -->

<!-- [rfced] updated by Chris /08/29/19 -->

<!ENTITY RFC2033 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2033.xml">
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3461 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3461.xml">
<!ENTITY RFC4033 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY RFC4034 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4034.xml">
<!ENTITY RFC4035 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4035.xml">
<!ENTITY RFC4880 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4880.xml">
<!ENTITY RFC5228 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5228.xml">
<!ENTITY RFC5234 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml">
<!ENTITY RFC5248 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5248.xml">
<!ENTITY RFC5321 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5321.xml">
<!ENTITY RFC5322 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5322.xml">
<!ENTITY RFC5598 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5598.xml">
<!ENTITY RFC3207 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3207.xml">
<!ENTITY RFC6125 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6125.xml">
<!ENTITY RFC6409 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6409.xml">
<!ENTITY RFC7525 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7525.xml">
<!ENTITY RFC7672 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7672.xml">
<!ENTITY RFC1939 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1939.xml">
<!ENTITY RFC3501 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3501.xml">
<!ENTITY RFC8174 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC8314 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8314.xml">
<!ENTITY RFC8461 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8461.xml">
<!ENTITY RFC8551 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8551.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
    please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
    (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
    (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions --> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
     category="std" consensus="yes" number="XXXX" ipr="trust200902">

 <!-- category values: std, bcp, info, exp, and historic
    ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
       or pre5378Trust200902
    you can add the attributes updates="NNNN" and obsoletes="NNNN"
    they will automatically be output with "(if approved)" --> consensus="true" number="8689" ipr="trust200902"
     obsoletes="" updates="" xml:lang="en" tocInclude="true" symRefs="true"
     sortRefs="true" version="3" docName="draft-ietf-uta-smtp-require-tls-09">

  <!-- ***** FRONT MATTER ***** xml2rfc v2v3 conversion 2.30.0 -->
  <front>
    <title>SMTP Require TLS Option</title>

   <!-- add 'role="editor"' below for the editors if appropriate -->
    <seriesInfo name="RFC" value="8689"/>

    <author fullname="Jim Fenton" initials="J.L." initials="J." surname="Fenton">
      <organization>Altmode Networks</organization>
      <address>
        <postal>
          <street> </street>
          <city>Los Altos</city>
          <region>California</region>
          <code>94024</code>
         <country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>fenton@bluepopcorn.net</email>

       <!-- uri and facsimile elements may also be added -->
      </address>
    </author>
    <date year="2019" month="August" />

   <!-- If the month and year are both specified and are the current ones, xml2rfc will fill
        in the current day for you. If only the current year is specified, xml2rfc will fill
	 in the current day and month for you. If the year is not the current one, it is
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to
	 specify just the year. -->

   <!-- Meta-data Declarations --> month="November"/>
    <area>General</area>
    <workgroup>Internet Engineering Task Force</workgroup>

   <!-- WG name at the upperleft corner
    <keyword>SMTP</keyword>
    <abstract>
      <t>The SMTP STARTTLS option, used in negotiating transport-level
     encryption of the doc,
        IETF is fine for individual submissions.
	 If this element SMTP connections, is not present, the default is "Network Working Group",
        which is used by the RFC Editor as a nod to the history of the IETF. -->

   <keyword>SMTP</keyword>

   <!-- Keywords will be incorporated into HTML output
        files in a meta tag but they have no effect on text or nroff
        output. If you submit your draft to the RFC Editor, the
        keywords will be used for the search engine. -->

   <abstract>
     <t>The SMTP STARTTLS option, used in negotiating transport-level
     encryption of SMTP connections, is not as useful from useful from a security
     standpoint as it might be because of its opportunistic nature;
     message delivery is, by default, prioritized over security. This
     document describes an SMTP service extension, REQUIRETLS, and
     a message header field, TLS-Required. If the REQUIRETLS option or
     TLS-Required message header field is used when sending a message,
     it asserts a request on the part of the message sender to
     override the default negotiation of TLS, either by requiring that
     TLS be negotiated when the message is relayed, relayed or by requesting
     that recipient-side policy mechanisms such as MTA-STS and DANE DNS-Based
     Authentication of Named Entities (DANE) be
     ignored when relaying a message for which security is
     unimportant.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>The <xref target="RFC5321">SMTP</xref> target="RFC5321" format="default">SMTP</xref> <xref
     target="RFC3207">STARTTLS target="RFC3207" format="default">STARTTLS service extension</xref> provides a
     means by which an SMTP server and client can establish a
     Transport Layer Security (TLS) protected session for the
     transmission of email messages. By default, TLS is used only upon
     mutual agreement (successful negotiation) of STARTTLS between the
     client and server; if this is not possible, the message is sent
     without transport encryption. Furthermore, it is common practice
     for the client to negotiate TLS even if the SMTP server's
     certificate is invalid.</t>
      <t>Policy mechanisms such as <xref target="RFC7672">DANE</xref> target="RFC7672" format="default">DANE</xref>
     and <xref target="RFC8461">MTA-STS</xref> target="RFC8461" format="default">MTA-STS</xref> may
     impose requirements for the use of TLS for email destined for
     some domains. However, such policies do not allow the sender to
     specify which messages are more sensitive and require
     transport-level encryption, encryption and which ones are less sensitive and
     ought to be relayed even if TLS cannot be negotiated
     successfully.</t>
     <t>The default opportunistic nature of SMTP TLS enables several
     "on the wire"
     on-the-wire attacks on SMTP security between MTAs. These
     include passive eavesdropping on connections for which TLS is not
     used, interference in the SMTP protocol to prevent TLS from being
     negotiated (presumably accompanied by eavesdropping), and insertion
     of a man-in-the-middle attacker exploiting the lack of
     server authentication by the client. Attacks are described
     in more detail in the Security Considerations <xref target="Security" format="title" /> section
     of this
     document.</t>
      <t>REQUIRETLS consists of two mechanisms: an SMTP service
     extension and a message header field. The service extension is
     used to specify that a given message sent during a particular session
     MUST
     <bcp14>MUST</bcp14> be sent over a TLS-protected session with specified security
     characteristics. It also requires that the SMTP server advertise
     that it supports REQUIRETLS, in effect promising that it
     will honor the requirement to enforce TLS transmission and
     REQUIRETLS support for onward transmission of those messages.</t>
      <t>The TLS-Required message header field is used to convey a
     request to ignore recipient-side policy mechanisms such as
     MTA-STS and DANE, thereby prioritizing delivery over ability to
     negotiate TLS. Unlike the service extension, the TLS-Required
     header field allows the message to transit through one or more
     MTAs that do not support REQUIRETLS.</t>
      <section title="Requirements Language">
       <t>The numbered="true" toc="default">
        <name>Requirements Language</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
       "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
       RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119" /> target="RFC2119"/>
    <xref target="RFC8174" /> target="RFC8174"/> when, and only when, they appear in all capitals,
    as shown here.</t> here.
        </t>
        <t>The formal syntax uses the Augmented Backus-Naur Form (ABNF)
       <xref target="RFC5234" /> format="default"/>, including the core rules defined in
       Appendix B of that document.</t>
      </section>
    </section>
    <section anchor="service_extension" title="The numbered="true" toc="default">
      <name>The REQUIRETLS Service Extension">
     <t><list style="numbers"> Extension</name>

<t>The REQUIRETLS SMTP service extension has the following characteristics:</t>

      <ol spacing="normal" type="1">
        <li>The textual name of the extension is "Require TLS".</t>
       <t>The TLS".</li>
        <li>The EHLO keyword value associated with this extension is
       "REQUIRETLS".</t>

       <t>No
       "REQUIRETLS".</li>
        <li>No additional SMTP verbs are defined by this extension.</t>

       <t>One extension.</li>
        <li>One optional parameter ("REQUIRETLS") is added to the MAIL
       FROM command by this extension. No value is associated with
       this parameter.</t>

       <t>The parameter.</li>
        <li>The maximum length of a MAIL FROM command line is increased
       by 11 octets by the possible addition of a space and the
       REQUIRETLS keyword.</t>

       <t>One keyword.</li>
        <li>One new SMTP status code is defined by this extension to
       convey an error condition resulting from failure of the client to
       send data to a server that does not also supporting support
       the REQUIRETLS extension.</t>

       <t>The extension.</li>
        <li>The REQUIRETLS extension is valid for message relay <xref
       target="RFC5321"></xref>, target="RFC5321" format="default"/>, submission <xref
       target="RFC6409"></xref>, target="RFC6409" format="default"/>, and the Local Mail Transfer Protocol
       (LMTP) <xref target="RFC2033"></xref></t> target="RFC2033" format="default"/>.</li>
        <li>
          <t>The ABNF syntax for the MAIL FROM parameter is as follows:
       <figure>
	 <artwork>
          </t>
          <sourcecode type="abnf"><![CDATA[
requiretls-param  = "REQUIRETLS"
                ; where requiretls-param is an instance of an
                ; esmtp-param used in Mail-parameters in
                ; RFC 5321 5321, Section 4.1.2. There is no esmtp-value
                ; associated with requiretls-param.
         </artwork>
       </figure>
     </t>
     </list></t> ]]></sourcecode>
        </li>
      </ol>
      <t>In order to specify REQUIRETLS treatment for a given message,
     the REQUIRETLS option is specified on in the MAIL FROM command when
     that message is transmitted. This option MUST <bcp14>MUST</bcp14> only be specified in the
     context of an SMTP session meeting the security requirements of
     REQUIRETLS:
     <list style="symbols">
       <t>The
      </t>
      <ul spacing="normal">
        <li>The session itself MUST <bcp14>MUST</bcp14> employ TLS transmission.</t>
       <t>If transmission.</li>
        <li>If the SMTP server to which the message is being transmitted
       is identified through an MX record lookup, its name
       MUST
       <bcp14>MUST</bcp14> be validated via a DNSSEC signature on the recipient
       domain's MX record, or the MX hostname MUST <bcp14>MUST</bcp14> be
       validated by an MTA-STS policy as described in Section 4.1 of <xref target="RFC8461">RFC&nbsp;8461</xref>. target="RFC8461"
       sectionFormat="of" section="4.1" />. DNSSEC is defined
       in <xref target="RFC4033">RFC&nbsp;4033</xref>, target="RFC4033" format="default" />,
       <xref target="RFC4034">RFC&nbsp;4034</xref>, target="RFC4034" format="default" />, and
       <xref target="RFC4035">RFC&nbsp;4035</xref>.</t>
       <t>The target="RFC4035" format="default" />.</li>

        <li>The certificate presented by the SMTP server MUST either
       verify <bcp14>MUST</bcp14>
       be verified successfully in by a trust chain leading to a certificate
       trusted by the SMTP client client, or it MUST verify <bcp14>MUST</bcp14> be verified successfully using
       DANE
       DANE, as specified in <xref
       target="RFC7672">RFC&nbsp;7672</xref>. target="RFC7672" format="default" />. For trust chains, the
       choice of trusted (root) certificates is at the discretion of
       the SMTP client.</t>
       <t>Following client.</li>
        <li>Following the negotiation of STARTTLS, the SMTP server MUST <bcp14>MUST</bcp14>
       advertise in the subsequent EHLO response that it supports REQUIRETLS.</t>
     </list>
     </t> REQUIRETLS.</li>
      </ul>
    </section>
    <section anchor="header_field" title="The numbered="true" toc="default">
      <name>The TLS-Required Header Field"> Field</name>
      <t>One new message header field <xref target="RFC5322" />, format="default"/>,
     TLS-Required, is defined by this
     specification. It is used for messages for which the originator
     requests that the recipient
     TLS policy (including <xref target="RFC8461">MTA-STS</xref> target="RFC8461" format="default">MTA-STS</xref> and
     <xref target="RFC7672">DANE</xref>) target="RFC7672" format="default">DANE</xref>) be ignored. This might be
     done, for example, to report a misconfigured mail server, such as
     an expired TLS certificate.</t>
      <t>The TLS-Required header field has a single REQUIRED <bcp14>REQUIRED</bcp14> parameter:</t>

     <t><list style="symbols">
      <t>No
      <ul spacing="normal">
        <li>No - The SMTP client SHOULD <bcp14>SHOULD</bcp14> attempt to send the message
      regardless of its ability to negotiate STARTTLS with the SMTP
      server, ignoring policy-based mechanisms (including MTA-STS and
      DANE), if any, asserted by
      the recipient domain. Nevertheless, the client SHOULD <bcp14>SHOULD</bcp14> negotiate
      STARTTLS with the server if available.</t>
     </list></t> available.</li>
      </ul>
      <t>More than one instance of the TLS-Required header field MUST
     NOT <bcp14>MUST
     NOT</bcp14> appear in a given message.</t>
      <t>The ABNF syntax for the TLS-Required header field is as
     follows:</t>
     <figure>
       <artwork>
      <sourcecode type="abnf"><![CDATA[
requiretls-field = "TLS-Required:" [FWS] "No" CRLF
        ; where requiretls-field in an instance of an
        ; optional-field defined in RFC 5322 5322, Section
              ; 3.6.8.
FWS = &lt;as <as defined in RFC 5322>
CRLF = &lt;as <as defined in RFC 5322>
       </artwork>
     </figure> ]]></sourcecode>
    </section>
    <section anchor="semantics" title="REQUIRETLS Semantics"> numbered="true" toc="default">
      <name>REQUIRETLS Semantics</name>
      <section anchor="receipt" title="REQUIRETLS numbered="true" toc="default">
        <name>REQUIRETLS Receipt Requirements"> Requirements</name>
        <t>Upon receipt of the REQUIRETLS option on a MAIL FROM command
       during the receipt of a message, an SMTP server MUST <bcp14>MUST</bcp14> tag that
       message as needing REQUIRETLS handling.</t>
        <t>Upon receipt of a message not specifying the REQUIRETLS
       option on its MAIL FROM command but containing the TLS-Required
       header field in its message header, an SMTP server implementing
       this specification MUST <bcp14>MUST</bcp14> tag that message with the option
       specified in the TLS-Required header field. If the REQUIRETLS
       MAIL FROM parameter is specified, the TLS-Required header field
       MUST
       <bcp14>MUST</bcp14> be ignored but MAY <bcp14>MAY</bcp14> be included in the onward relay of the
       message.</t>
        <t>The manner in which the above tagging takes place is
       implementation-dependent.
       implementation dependent. If the message is being locally
       aliased and redistributed to multiple addresses, all instances
       of the message MUST <bcp14>MUST</bcp14> be tagged in the same manner.</t>
      </section>
      <section anchor="sender" title="REQUIRETLS numbered="true" toc="default">
        <name>REQUIRETLS Sender Requirements"> Requirements</name>
        <section anchor="yestls" title="Sending numbered="true" toc="default">
          <name>Sending with TLS Required"> Required</name>
          <t>When sending a message tagged as requiring TLS for which the
       MAIL FROM return-path is not empty (an empty MAIL FROM
       return-path indicating a bounce message), the sending
       (client) MTA MUST:

       <list style="numbers">

	 <t>Look <bcp14>MUST</bcp14>:

          </t>
          <ol spacing="normal" type="1">
            <li>Look up the SMTP server to which the message is to be sent sent,
	 as described in <xref target="RFC5321"></xref> Section
	 5.1.</t>

	 <t>If target="RFC5321" sectionFormat="comma"
	 section="5.1" />.</li>
            <li>If the server lookup is accomplished via the recipient
	 domain's MX record (the usual case) and is not accompanied by a valid
	 DNSSEC signature, the client MUST <bcp14>MUST</bcp14> also validate the SMTP
	 server name using MTA-STS MTA-STS, as described in
         <xref target="RFC8461">RFC&nbsp;8461</xref> Section 4.1.</t>

	 <t>Open target="RFC8461" sectionFormat="comma" section="4.1"/>.</li>
            <li>Open an SMTP session with the peer SMTP server using the
	 EHLO verb.</t>

	 <t>Establish verb.</li>
            <li>Establish a TLS-protected SMTP session with its peer SMTP
	 server and authenticate the server's certificate as specified
	 in <xref target="RFC6125"></xref> target="RFC6125" format="default"/> or <xref
	 target="RFC7672"></xref> target="RFC7672" format="default"/>, as applicable. The hostname from the
   MX record lookup (or the domain name in the absence of an MX
   record where an A record is used directly) MUST <bcp14>MUST</bcp14> match the DNS-ID
   or CN-ID of the certificate presented by the server.</t>

	 <t>Ensure server.</li>
            <li>Ensure that the response to the subsequent EHLO following
	 establishment of the TLS protection advertises the REQUIRETLS
	 capability.</t>

       </list></t>
	 capability.</li>
          </ol>
          <t>The SMTP client SHOULD <bcp14>SHOULD</bcp14> follow the recommendations in <xref
       target="RFC7525"></xref> target="RFC7525" format="default"/> or its successor with respect to
       negotiation of the TLS session.</t>

          <t>If any of the above steps fail, the client MUST <bcp14>MUST</bcp14> issue a QUIT
       to the server and repeat steps 2-5 with each host on the
       recipient domain's list of MX hosts in an attempt to find a
       mail path that meets the sender's requirements. The client MAY <bcp14>MAY</bcp14>
       send other, unprotected, unprotected messages to that server if it has any
       such messages prior to issuing the QUIT. If there are no more MX hosts, the
       client MUST NOT <bcp14>MUST NOT</bcp14> transmit the message to the domain. </t>
          <t>Following such a failure, the SMTP client MUST <bcp14>MUST</bcp14> send a
       non-delivery notification to the reverse-path of the failed
       message
       message, as described in section 3.6 of <xref target="RFC5321" />.
       sectionFormat="of" section="3.6"/>. The
       following <xref target="RFC5248">status target="RFC5248" format="default">status codes</xref> SHOULD <bcp14>SHOULD</bcp14> be used:

       <list style="symbols">
	 <t>REQUIRETLS
          </t>

          <ul spacing="normal">
            <li>REQUIRETLS not supported by server: 5.7.YYY 5.7.30 REQUIRETLS
	 needed</t>
	 <t>Unable
	 support required</li>
            <li>Unable to establish TLS-protected SMTP session: 5.7.10
	 Encryption needed</t>
       </list></t> needed</li>
          </ul>
          <t>Refer to <xref target="errors" /> format="default"/> for further requirements regarding
       non-delivery messages.</t>
          <t>If all REQUIRETLS requirements have been met, transmit the
       message, issuing the REQUIRETLS option on the MAIL FROM command
       with the required option(s), if any.</t>
        </section>
        <section anchor="maytls" title="Sending numbered="true" toc="default">
          <name>Sending with TLS Optional"> Optional</name>
          <t>Messages tagged TLS-Required: No "TLS-Required: No" are handled as
	 follows. When sending such a message, the sending (client)
	 MTA MUST:
	 <list style="symbols">
	   <t>Look <bcp14>MUST</bcp14>:
          </t>
          <ul spacing="normal">
            <li>Look up the SMTP server to which the message is to be
	   sent
	   sent, as described in <xref target="RFC5321"></xref> Section
	   5.1.</t>

	   <t>Open target="RFC5321" sectionFormat="comma" section="5.1"/>.</li>
            <li>Open an SMTP session with the peer SMTP server using the
	   EHLO verb. Attempt to negotiate STARTTLS if possible, and
	   follow any policy published by the recipient domain, but do
	   not fail if this is unsuccessful.</t>

	 </list>
	 </t> unsuccessful.</li>
          </ul>
          <t>Some SMTP servers may be configured to require STARTTLS
	 connections as a matter of policy and not accept messages in
	 the absence of STARTTLS. A non-delivery notification MUST <bcp14>MUST</bcp14> be
	 returned to the sender if message relay fails due to an
	 inability to negotiate STARTTLS when required by the
	 server.</t>
          <t>Since messages tagged with TLS-Required: No "TLS-Required: No" will sometimes
	 be sent to SMTP servers not supporting REQUIRETLS, that
	 option will not be uniformly observed by all SMTP relay
	 hops.</t>
        </section>
      </section>
      <section anchor="submission" title="REQUIRETLS Submission">
       <t>An MUA numbered="true" toc="default">
        <name>REQUIRETLS Submission</name>

        <t>A Mail User Agent (MUA) or other agent making the initial introduction of a
       message has the option to decide whether to require TLS. If
       TLS is to be required, it MUST <bcp14>MUST</bcp14> do so by negotiating STARTTLS
       and REQUIRETLS and include including the REQUIRETLS option on the MAIL
       FROM command, as is done for message relay.</t>
        <t>When TLS is not to be required, the sender MUST <bcp14>MUST</bcp14> include the
       TLS-Required header field in the message. SMTP servers
       implementing this specification MUST <bcp14>MUST</bcp14> interpret this header
       field as described in <xref target="receipt" />.</t> format="default"/>.</t>
        <t>In either case, the decision whether to specify REQUIRETLS
       MAY
       <bcp14>MAY</bcp14> be done based on a user interface selection or based on a
       ruleset or other policy. The manner in which the decision to
       require TLS is made is implementation-dependent implementation dependent and is beyond
       the scope of this specification.</t>
      </section>
      <section anchor="delivery" title="Delivery numbered="true" toc="default">
        <name>Delivery of REQUIRETLS messages"> messages</name>
        <t>Messages are usually retrieved by end users using protocols
       other than SMTP such as <xref target="RFC3501">IMAP</xref>, target="RFC3501" format="default">IMAP</xref>,
       <xref target="RFC1939">POP</xref>, target="RFC1939" format="default">POP</xref>, or web Web mail systems. Mail
       delivery agents supporting the REQUIRETLS SMTP option SHOULD <bcp14>SHOULD</bcp14>
       observe the guidelines in <xref target="RFC8314" />.</t> format="default"/>.</t>
      </section>
    </section>
    <section anchor="errors" title="Non-delivery message handling"> numbered="true" toc="default">
      <name>Non-delivery Message Handling</name>

      <t>Non-delivery ("bounce") messages usually contain important
       metadata about the message to which they refer, including the
       original message header. They therefore MUST <bcp14>MUST</bcp14> be protected in
       the same manner as the original message.
   All non-delivery messages resulting from messages with the REQUIRETLS SMTP
   option, whether resulting from a REQUIRETLS error or some
       other, MUST other issue, <bcp14>MUST</bcp14>
   also specify the REQUIRETLS SMTP option unless redacted as described below.</t> below.
</t>
      <t>The path from the origination of an error bounce message
       back to the MAIL FROM address may not share the same REQUIRETLS
       support as the forward path. Therefore, users requiring TLS are
       advised to make sure that they are capable of receiving mail
       using REQUIRETLS as well. Otherwise, such non-delivery messages
       will be lost.</t>
      <t>If a REQUIRETLS message is bounced, the server MUST <bcp14>MUST</bcp14> behave
       as if RET=HDRS was present present, as described in <xref
       target="RFC3461"></xref>. target="RFC3461" format="default"/>. If both RET=FULL and REQUIRETLS are
       present, the RET=FULL MUST <bcp14>MUST</bcp14> be disregarded. The SMTP client for a
       REQUIRETLS bounce message uses an empty MAIL FROM
       return-path
       return-path, as required by <xref target="RFC5321"></xref>. target="RFC5321" format="default"/>. When
       the MAIL FROM return-path is empty, the REQUIRETLS parameter
       SHOULD NOT
       <bcp14>SHOULD NOT</bcp14> cause a bounce message to be discarded even if the
       next-hop relay does not advertise REQUIRETLS.</t>
      <t>Senders of messages requiring TLS are advised to consider
       the possibility that bounce messages will be lost as a result
       of REQUIRETLS return path failure, failure and that some information
       could be leaked if a bounce message is not able to be
       transmitted with REQUIRETLS.</t>
    </section>
    <section anchor="reorigination" title="Reorigination considerations"> numbered="true" toc="default">
      <name>Reorigination Considerations</name>
      <t>In a number of situations, a <xref target="RFC5598">mediator</xref> target="RFC5598" format="default">mediator</xref>
      originates a new message as a result of an incoming message. These
      situations include, include but are not limited to, to mailing lists (including
      administrative traffic such as message approval requests),
      <xref target="RFC5228">Sieve</xref>, target="RFC5228" format="default">Sieve</xref>, "vacation" responders, and other
      filters to which incoming
      messages may be piped. These newly originated messages may essentially
      be copies of the incoming message, such as with a forwarding service
      or a mailing list expander.  In other cases, such as with a vacation
      message or a delivery notification, they will be different but might
      contain parts of the original message or other information for which
      the original message sender wants to influence the requirement to use
      TLS transmission.</t>
      <t>Mediators that reoriginate messages should apply REQUIRETLS requirements
      in incoming messages (both requiring TLS transmission and requesting
      that TLS not be required) to the reoriginated messages to the extent
      feasible.  A limitation to this might be that for a message requiring
      TLS, redistribution to multiple addresses while retaining the TLS
      requirement could result in the message not being delivered to some of
      the intended recipients.</t>
      <t>User-side mediators (such as use of Sieve rules on a user agent)
      typically do not have access to the SMTP details, details and therefore may
      not be aware of the REQUIRETLS requirement on a delivered message.
      Recipients that expect sensitive traffic should avoid the use of
      user-side mediators. Alternatively, if operationally feasible (such as when
      forwarding to a specific, known address), they should apply REQUIRETLS
      to all reoriginated messages that do not contain the "TLS-Required: No" header
      field.</t>
    </section>

   <!-- Possibly a 'Contributors' section ... -->

    <section anchor="IANA" title="IANA Considerations">
     <t>If published as an RFC, numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>Per this draft requests the addition of document, IANA has added
     the following keyword to the <xref target="MailParams">SMTP "SMTP Service Extensions Registry</xref>:</t>

     <figure align="left"><artwork align="left">
Textual name:               Require TLS
EHLO keyword value:         REQUIRETLS
Syntax and parameters:      (no parameters)
Additional Extensions" subregistry of the
      <xref target="MailParams" format="default">"Mail Parameters" registry</xref>:</t>

<ul empty="true"><li>
<dl newline="false" spacing="compact" indent="30">
<dt>EHLO Keyword:</dt><dd>REQUIRETLS</dd>
<dt>Description:</dt><dd>Require TLS</dd>
<dt>Syntax and parameters:</dt><dd>(no parameters)</dd>
<dt>Additional SMTP verbs:      none
MAIL verbs:</dt><dd>none</dd>
<dt>MAIL and RCPT parameters:   REQUIRETLS parameters:</dt><dd>REQUIRETLS parameter on MAIL
Behavior:                   Use MAIL</dd>
<dt>Behavior:</dt><dd>Use of the REQUIRETLS parameter on the MAIL verb causes
that message to require the use of TLS and tagging with REQUIRETLS for all onward relay.
Command relay.</dd>
<dt>Command length increment:   11 characters
       </artwork></figure>

      <t>If published as an RFC, increment:</dt><dd>11 characters</dd>
</dl>
</li>
</ul>
      <t>Per this draft requests the addition of document, IANA has added an
     entry to the "Enumerated Status Codes" subregistry of the <xref
     target="SMTPStatusCodes">Simple target="SMTPStatusCodes" format="default">"Simple Mail Transfer Protocol (SMTP) Enhanced Status
     Codes Registry</xref>:</t>

     <figure align="left"><artwork align="left">
Code:                       5.7.YYY
Sample Text:                REQUIRETLS Registry"</xref>:</t>
<ul empty="true"><li>
<dl newline="false" spacing="compact" indent="30">
<dt>Code:</dt><dd>X.7.30</dd>
<dt>Sample Text:</dt><dd>REQUIRETLS support required
Associated required</dd>
<dt>Associated basic status code:  550
Description:                This code:</dt><dd>550</dd>
<dt>Description:</dt><dd>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:                  (this document)
Submitter:                  J. Fenton
Change controller:          IESG
       </artwork></figure>

     <t>If published as an RFC, support.</dd>
<dt>Reference:</dt><dd>RFC 8689</dd>
<dt>Submitter:</dt><dd>J. Fenton</dd>
<dt>Change Controller:</dt><dd>IESG</dd>
</dl>
</li>
</ul>
      <t>Per this draft requests the addition of document, IANA has added
     an entry to the <xref
     target="PermMessageHeaderFields">Permanent "Permanent Message Header Field
     Names Registry</xref>:</t>

     <figure align="left"><artwork align="left">
Header field name:          TLS-Required
Applicable protocol:        mail
Status:                     standard
Author/change controller:   IETF
Specification document:     (this document)
     </artwork></figure>

     <t>This section is to be updated for publication by
     Names" subregistry of the RFC Editor.</t> <xref target="MessageHeaders"
     format="default">"Message Headers" registry</xref> as follows:</t>
<ul empty="true"><li>
<dl newline="false" spacing="compact" indent="30">
<dt>Header field name:</dt><dd>TLS-Required</dd>
<dt>Applicable protocol:</dt><dd>mail</dd>
<dt>Status:</dt><dd>standard</dd>
<dt>Author/change controller:</dt><dd>IETF</dd>
<dt>Specification document:</dt><dd>RFC 8689</dd>
</dl>
</li>
</ul>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>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 over the wire" wire or explicitly indicating that transport
     encryption is not required if it cannot be successfully
     negotiated.</t>
      <t>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.</t>
      <section anchor="Passive" title="Passive attacks"> numbered="true" toc="default">
        <name>Passive Attacks</name>
        <t>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.</t>
      </section>
      <section anchor="Active" title="Active attacks"> numbered="true" toc="default">
        <name>Active Attacks</name>
        <t>Active attacks against TLS encrypted 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.</t>
        <t>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.</t>
        <t>Another active attack involves the spoofing of DNS MX
	 records of the recipient domain. An attacker having 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.</t>
      </section>
      <section anchor="badactor" title="Bad Actor MTAs"> numbered="true" toc="default">
        <name>Bad-Actor MTAs</name>
        <t>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.</t>
        <t>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 <xref target="RFC4880">OpenPGP</xref> or <xref
	 target="RFC8551">S/MIME</xref>.</t>
       </section>

       <section anchor="conflicts" title="Policy Conflicts">

        <t>In some cases, the use of the TLS-Required header field may conflict
with a recipient domain policy expressed through the <xref
target="RFC7672">DANE</xref> or <xref target="RFC8461">MTA-STS</xref> protocols.
Although these protocols encourage the use of TLS transport by advertising
availability of TLS, the use of "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 nor MTA-STS.</t>
      </section>
    </section>

   <section anchor="acknowledgements" title="Acknowledgements">
     <t>The author would like to acknowledge many helpful suggestions
     on the ietf-smtp and uta mailing lists, in particular those of
     Viktor Dukhovni, Chris Newman, Tony Finch, Jeremy Harris, Arvel
     Hathcock, John Klensin, Barry Leiba, John Levine, Rolf Sonneveld,
     and Per Thorsheim.</t>

   </section>

     <section anchor="history" title="Revision History">

       <t>To be removed by RFC Editor upon publication as an RFC.</t>

       <section title="Changes since -08 Draft">
      <t>Additional changes in response to IESG review:</t>
      <t><list style="symbols">
        <t>Unify wording describing TLS-Required in Appendix A.2.</t>
        <t>Add specifics on verification of mail server hostnames with
          certificates.</t>
        <t>Wording tweak in 4.3 to emphasize optional nature of REQUIRETLS.</t>
        <t>Update S/MIME reference from RFC 5751 to 8551</t>
      </list></t></section>

       <section title="Changes since -07 Draft">
	 <t>Changes in response to IESG review and IETF Last Call comments:</t>
	 <t><list style="symbols">
	   <t>Change associated status code for 5.7.YYY from 530 to
	   550.</t>
	   <t>Correct textual name of extension in IANA Considerations
	   for consistency with the rest of the document.</t>
	   <t>Remove special handling of bounce messages in Section
	   4.1.</t>
	   <t>Change name of header field from RequireTLS to
	   TLS-Required and make capitalization of parameter
	   consistent.</t>
	   <t>Remove mention of transforming RET=FULL to RET=HDRS on
	   relay in Section 5.</t>
     <t>Replace Section 6 dealing with mailing lists with a more
      general section on reorigination by mediators.</t>
      <t>Add security considerations section on policy conflicts.</t>

	 </list></t>
       </section>

       <section title="Changes since -06 Draft">
	 <t>Various changes in response to AD review:</t>

	 <t><list style="symbols">
	   <t>Reference RFC 7525 for TLS negotiation
	   recommendations.</t>
	   <t>Make reference to requested 5.7.YYY error code
	   consistent.</t>
	   <t>Clarify applicability to LMTP and submission.</t>
	   <t>Provide ABNF for syntax of SMTP option and header field
	   and examples in Appendix A.</t>
	   <t>Correct use of normative language in Section 5.</t>
	   <t>Clarify case where REQUIRETLS option is used on bounce
	   messages.</t>
	   <t>Improve Security Requirements wording to be inclusive of
	   both SMTP option and header field.</t>
	 </list></t>
       </section>

       <section title="Changes since -05 Draft">
	 <t>Corrected IANA Permanent Message Header Fields Registry
	 request.</t>
       </section>

       <section title="Changes since -04 Draft">
	 <t>Require validation of SMTP server hostname via DNSSEC or
	 MTA-STS policy when TLS is required.</t>
       </section>

       <section title="Changes since -03 Draft">
	 <t>Working Group Last Call changes, including:</t>
	 <t><list style="symbols">
	   <t>Correct reference for SMTP DANE</t>
	   <t>Clarify that RequireTLS: NO applies to both MTA-STS and
	   DANE policies</t>
	   <t>Correct newly-defined status codes</t>
	   <t>Update MTA-STS references to RFC</t>
	 </list></t>
       </section>

       <section title="Changes since -02 Draft">
	 <t><list style="symbols">
	   <t>More complete documentation for IANA registration requests.</t>
	   <t>Changed bounce handling to use RET parameters of <xref
     target="RFC3461"></xref>, along with slightly more liberal transmission of
	   bounces even if REQUIRETLS can't be negotiated.</t>
	 </list></t>
       </section>

       <section title="Changes since -01 Draft">
	 <t><list style="symbols">
	   <t>Converted DEEP references to RFC 8314.</t>
	   <t>Removed REQUIRETLS options: CHAIN, DANE, and DNSSEC.</t>
	   <t>Editorial corrections, notably making the header field
	   name consistent (RequireTLS rather than Require-TLS).</t>
	 </list></t>
       </section>

       <section title="Changes since -00 Draft">
	 <t><list style="symbols">
	   <t>Created new header field, Require-TLS, for use by "NO"
	   option.</t>
	   <t>Removed "NO" option from SMTP service extension.</t>
	   <t>Recommend DEEP requirements for delivery of messages
	   requiring TLS.</t>
	   <t>Assorted copy edits</t>
	 </list></t>
       </section>

       <section title="Changes since fenton-03 Draft">
	 <t><list style="symbols">
	   <t>Wording improvements from Rolf Sonneveld review 22 July
	   2017</t>
	   <t>A few copy edits</t>
	   <t>Conversion from individual to UTA WG draft</t>
	 </list></t>
       </section>

       <section title="Changes Since -02 Draft">
	 <t><list style="symbols">
	   <t>Incorporation of "MAY TLS" functionality as
	   REQUIRETLS=NO per suggestion on UTA WG mailing list.</t>
	   <t>Additional guidance on bounce messages</t>
	 </list></t>
       </section>

       <section title="Changes Since -01 Draft">
	 <t><list style="symbols">
	   <t>Specified retries when multiple MX hosts exist for a
	   given domain.</t>
	   <t>Clarified generation of non-delivery messages</t>
	   <t>Specified requirements for application of REQUIRETLS to mail forwarders
	   and mailing lists.</t>
	   <t>Clarified DNSSEC requirements to include MX lookup only.</t>
	   <t>Corrected terminology regarding message retrieval
	   vs. delivery.</t>
	   <t>Changed category to standards track.</t>

	 </list></t>
       </section>
       <section title="Changes Since -00 Draft">

	 <t><list style="symbols">
	 <t>Conversion of REQUIRETLS from an SMTP verb to a MAIL FROM
	 parameter to better associate REQUIRETLS requirements with
	 transmission of individual messages.</t>

	 <t>Addition of an option to require DNSSEC lookup of the
	 remote mail server, since this affects the common name of the
	 certificate that is presented.</t>

	 <t>Clarified the wording to more clearly state that TLS
	 sessions must be established and not simply that STARTTLS is
	 negotiated.</t>

	 <t>Introduced need for minimum encryption standards (key
	 lengths and algorithms)</t>

	 <t>Substantially rewritten Security Considerations section</t>

       </list></t>

     </section>

   </section>

 </middle>

 <!--  *****BACK MATTER ***** -->

 <back>
   <!-- References split into informative are not encrypted end-to-end and normative -->

   <!-- There are 2 ways visible to insert reference entries from
	 MTAs that are part of the citation libraries:
    1. define an ENTITY at message delivery path. Messages
	 containing sensitive information that MTAs should not have
	 access to <bcp14>MUST</bcp14> be sent using end-to-end content encryption
	 such as <xref target="RFC4880" format="default">OpenPGP</xref> or <xref target="RFC8551" format="default">S/MIME</xref>.</t>
      </section>
      <section anchor="conflicts" numbered="true" toc="default">
        <name>Policy Conflicts</name>
        <t>In some cases, the top, and use "ampersand character"RFC2629; here (as shown)
    2. simply use of the TLS-Required header field may conflict
with a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
       (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

    Both are cited textually in recipient domain policy expressed through the same manner: <xref target="RFC7672" format="default">DANE</xref> or <xref target="RFC8461" format="default">MTA-STS</xref> protocols.
Although these protocols encourage the use of TLS transport by using xref elements.
    If you advertising
the availability of TLS, the use of the PI option, xml2rfc will, by default, try to find included files in "TLS-Required: No" header field represents an
explicit decision on the same
    directory as part of the including file. You can also define sender not to require the XML_LIBRARY environment variable
    with a value containing a set use of directories TLS, such
as to search.  These can be either in overcome a configuration error. The recipient domain has the local
    filing system or remote ones accessed ultimate
ability to require TLS by http (http://domain/dir/... ).-->

   <references title="Normative References">
     <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
     &RFC2119;
     &RFC3207;
     &RFC4033;
     &RFC4034;
     &RFC4035;
     &RFC3461;
     &RFC5234;
     &RFC5248;
     &RFC5321;
     &RFC5322;
     &RFC6125;
     &RFC7525;
     &RFC7672;
     &RFC8174;
     &RFC8314;
     &RFC8461;

<!-- [rfced] [MailParams] This URL not accepting messages when STARTTLS has not been
negotiated; otherwise, "TLS-Required: No" is correct --> effectively directing the client
MTA to behave as if it does not support DANE or MTA-STS.</t>
      </section>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3207.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4034.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4035.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3461.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5248.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5321.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5322.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6125.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7525.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7672.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8314.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8461.xml"/>

        <reference anchor="MailParams" target="http://www.iana.org/assignments/mail-parameters">
          <front>
         <title>IANA Mail
            <title>Mail Parameters</title>
            <author>
           <organization>Internet Assigned Numbers Authority (IANA)</organization>
              <organization>IANA</organization>
            </author>

         <date year="2007" />
          </front>
        </reference>

<!-- [rfced] [SMTPStatusCodes] This URL is correct -->

        <reference anchor="SMTPStatusCodes"
                target="http://www.iana.org/assignments/smtp-enhanced-status-codes"> target="https://www.iana.org/assignments/smtp-enhanced-status-codes">
          <front>
            <title>Simple Mail Transfer Protocol (SMTP) Enhanced Status
	 Codes Registry</title>
            <author>
           <organization>Internet Assigned Numbers Authority (IANA)</organization>
              <organization>IANA</organization>
            </author>

         <date year="2008" />
          </front>
        </reference>

<!-- [rfced] [PermMessageHeaderFields] This URL is correct -->

        <reference anchor="PermMessageHeaderFields"
                target="https://www.iana.org/assignments/message-headers/message-headers.xhtml#perm-headers"> anchor="MessageHeaders" target="https://www.iana.org/assignments/message-headers">
          <front>
            <title>Permanent Message Header Field Names Registry</title> Names</title>
            <author>
           <organization>Internet Assigned Numbers Authority (IANA)</organization>
              <organization>IANA</organization>
            </author>

         <date year="2004" />
          </front>
        </reference>
      </references>

   <references title="Informative References">
     <!-- Here we use entities that we defined at the beginning. -->

     &RFC1939;
     &RFC2033;
     &RFC3501;
     &RFC4880;
     &RFC5228;
     &RFC5598;
     &RFC6409;
     &RFC8551;
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1939.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2033.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3501.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4880.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5228.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5598.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6409.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8551.xml"/>
      </references>
    </references>

    <section title="Examples"> numbered="true" toc="default">
      <name>Examples</name>
      <t>This section is informative.</t>
      <section title="REQUIRETLS numbered="true" toc="default">
        <name>REQUIRETLS SMTP Option"> Option</name>
        <t>The TLS-Required SMTP option is used to express the intent intention of
       the sender that to have the associated message be relayed using TLS. In
       the following example, lines beginning with C: "C:" are transmitted
       from the SMTP client to the server, and lines beginning with S: "S:"
       are transmitted in the opposite direction.</t>
       <figure>
         <artwork>
        <artwork name="" type="" align="left" alt=""><![CDATA[
 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
]]></artwork>
<t>(at this point TLS negotiation takes place. The remainder of this
 session occurs within TLS.) TLS.)</t>

        <artwork name="" type="" align="left" alt=""><![CDATA[
 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:&lt;roger@example.org> FROM:<roger@example.org> REQUIRETLS
 S: 250 OK
 C: RCPT TO:&lt;editor@example.net> TO:<editor@example.net>
 S: 250 Accepted
 C: DATA
 S: 354 Enter message, ending with "." on a line by itself

 (message follows)
]]></artwork>

<t>(message follows)</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
 C: .
 S: 250 OK
 C: QUIT
         </artwork>
       </figure>
]]></artwork>
      </section>
      <section title="TLS-Required numbered="true" toc="default">
        <name>TLS-Required Header Field"> Field</name>
        <t>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:</t>
       <figure>
	 <artwork>
        <artwork name="" type="" align="left" alt=""><![CDATA[
 From: Roger Reporter &lt;roger@example.org> <roger@example.org>
 To: Andy Admin &lt;admin@example.com> <admin@example.com>
 Subject: Certificate problem?
 TLS-Required: No
 Date: Fri, 18 Jan 2019 10:26:55 -0800
 Message-ID: &lt;5c421a6f79c0e_d153ff8286d45c468473@mail.example.org> <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
         </artwork>
       </figure>         ]]></artwork>
      </section>
    </section>

    <section anchor="acknowledgements" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>
   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.
      </t>
    </section>
  </back>
</rfc>