File: rfc8689.html

package info (click to toggle)
doc-rfc 20230121-1
links: PTS, VCS
area: non-free
in suites: bookworm, forky, sid, trixie
size: 1,609,944 kB
file content (2090 lines) | stat: -rw-r--r-- 93,852 bytes
parent folder | download | duplicates (2)
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 8689: SMTP Require TLS Option</title>
<meta content="Jim Fenton" name="author">
<meta content="
       The SMTP STARTTLS option, used in negotiating transport-level
     encryption of SMTP connections, is not as 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 or by requesting
     that recipient-side policy mechanisms such as MTA-STS and DNS-Based
     Authentication of Named Entities (DANE) be
     ignored when relaying a message for which security is
     unimportant. 
    " name="description">
<meta content="xml2rfc 2.35.0" name="generator">
<meta content="SMTP" name="keyword">
<meta content="8689" name="rfc.number">
<link href="rfc8689.xml" type="application/rfc+xml" rel="alternate">
<link href="#copyright" rel="license">
<style type="text/css">/*

  NOTE: Changes at the bottom of this file overrides some earlier settings.

  Once the style has stabilized and has been adopted as an official RFC style,
  this can be consolidated so that style settings occur only in one place, but
  for now the contents of this file consists first of the initial CSS work as
  provided to the RFC Formatter (xml2rfc) work, followed by itemized and
  commented changes found necssary during the development of the v3
  formatters.

*/

/* fonts */
@import url('https://fonts.googleapis.com/css?family=Noto+Sans'); /* Sans-serif */
@import url('https://fonts.googleapis.com/css?family=Noto+Serif'); /* Serif (print) */
@import url('https://fonts.googleapis.com/css?family=Roboto+Mono'); /* Monospace */

@viewport {
  zoom: 1.0;
  width: extend-to-zoom;
}
@-ms-viewport {
  width: extend-to-zoom;
  zoom: 1.0;
}
/* general and mobile first */
html {
}
body {
  max-width: 90%;
  margin: 1.5em auto;
  color: #222;
  background-color: #fff;
  font-size: 14px;
  font-family: 'Noto Sans', Arial, Helvetica, sans-serif;
  line-height: 1.6;
  scroll-behavior: smooth;
}
.ears {
  display: none;
}

/* headings */
#title, h1, h2, h3, h4, h5, h6 {
  margin: 1em 0 0.5em;
  font-weight: bold;
  line-height: 1.3;
}
#title {
  clear: both;
  border-bottom: 1px solid #ddd;
  margin: 0 0 0.5em 0;
  padding: 1em 0 0.5em;
}
.author {
  padding-bottom: 4px;
}
h1 {
  font-size: 26px;
  margin: 1em 0;
}
h2 {
  font-size: 22px;
  margin-top: -20px;  /* provide offset for in-page anchors */
  padding-top: 33px;
}
h3 {
  font-size: 18px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h4 {
  font-size: 16px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h5, h6 {
  font-size: 14px;
}
#n-copyright-notice {
  border-bottom: 1px solid #ddd;
  padding-bottom: 1em;
  margin-bottom: 1em;
}
/* general structure */
p {
  padding: 0;
  margin: 0 0 1em 0;
  text-align: left;
}
div, span {
  position: relative;
}
div {
  margin: 0;
}
.alignRight.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignRight.art-text pre {
  padding: 0;
}
.alignRight {
  margin: 1em 0;
}
.alignRight > *:first-child {
  border: none;
  margin: 0;
  float: right;
  clear: both;
}
.alignRight > *:nth-child(2) {
  clear: both;
  display: block;
  border: none;
}
svg {
  display: block;
}
.alignCenter.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignCenter.art-text pre {
  padding: 0;
}
.alignCenter {
  margin: 1em 0;
}
.alignCenter > *:first-child {
  border: none;
  /* this isn't optimal, but it's an existence proof.  PrinceXML doesn't
     support flexbox yet.
  */
  display: table;
  margin: 0 auto;
}

/* lists */
ol, ul {
  padding: 0;
  margin: 0 0 1em 2em;
}
ol ol, ul ul, ol ul, ul ol {
  margin-left: 1em;
}
li {
  margin: 0 0 0.25em 0;
}
.ulCompact li {
  margin: 0;
}
ul.empty, .ulEmpty {
  list-style-type: none;
}
ul.empty li, .ulEmpty li {
  margin-top: 0.5em;
}
ul.compact, .ulCompact,
ol.compact, .olCompact {
  line-height: 100%;
  margin: 0 0 0 2em;
}

/* definition lists */
dl {
}
dl > dt {
  float: left;
  margin-right: 1em;
}
/* 
dl.nohang > dt {
  float: none;
}
*/
dl > dd {
  margin-bottom: .8em;
  min-height: 1.3em;
}
dl.compact > dd, .dlCompact > dd {
  margin-bottom: 0em;
}
dl > dd > dl {
  margin-top: 0.5em;
  margin-bottom: 0em;
}

/* links */
a {
  text-decoration: none;
}
a[href] {
  color: #22e; /* Arlen: WCAG 2019 */
}
a[href]:hover {
  background-color: #f2f2f2;
}
figcaption a[href],
a[href].selfRef {
  color: #222;
}
/* XXX probably not this:
a.selfRef:hover {
  background-color: transparent;
  cursor: default;
} */

/* Figures */
tt, code, pre, code {
  background-color: #f9f9f9;
  font-family: 'Roboto Mono', monospace;
}
pre {
  border: 1px solid #eee;
  margin: 0;
  padding: 1em;
}
img {
  max-width: 100%;
}
figure {
  margin: 0;
}
figure blockquote {
  margin: 0.8em 0.4em 0.4em;
}
figcaption {
  font-style: italic;
  margin: 0 0 1em 0;
}
@media screen {
  pre {
    overflow-x: auto;
    max-width: 100%;
    max-width: calc(100% - 22px);
  }
}

/* aside, blockquote */
aside, blockquote {
  margin-left: 0;
  padding: 1.2em 2em;
}
blockquote {
  background-color: #f9f9f9;
  color: #111; /* Arlen: WCAG 2019 */
  border: 1px solid #ddd;
  border-radius: 3px;
  margin: 1em 0;
}
cite {
  display: block;
  text-align: right;
  font-style: italic;
}

/* tables */
table {
  width: 100%;
  margin: 0 0 1em;
  border-collapse: collapse;
  border: 1px solid #eee;
}
th, td {
  text-align: left;
  vertical-align: top;
  padding: 0.5em 0.75em;
}
th {
  text-align: left;
  background-color: #e9e9e9;
}
tr:nth-child(2n+1) > td {
  background-color: #f5f5f5;
}
table caption {
  font-style: italic;
  margin: 0;
  padding: 0;
  text-align: left;
}
table p {
  /* XXX to avoid bottom margin on table row signifiers. If paragraphs should
     be allowed within tables more generally, it would be far better to select on a class. */
  margin: 0;
}

/* pilcrow */
a.pilcrow {
  color: #666; /* Arlen: AHDJ 2019 */
  text-decoration: none;
  visibility: hidden;
  user-select: none;
  -ms-user-select: none;
  -o-user-select:none;
  -moz-user-select: none;
  -khtml-user-select: none;
  -webkit-user-select: none;
  -webkit-touch-callout: none;
}
@media screen {
  aside:hover > a.pilcrow,
  p:hover > a.pilcrow,
  blockquote:hover > a.pilcrow,
  div:hover > a.pilcrow,
  li:hover > a.pilcrow,
  pre:hover > a.pilcrow {
    visibility: visible;
  }
  a.pilcrow:hover {
    background-color: transparent;
  }
}

/* misc */
hr {
  border: 0;
  border-top: 1px solid #eee;
}
.bcp14 {
  font-variant: small-caps;
}

.role {
  font-variant: all-small-caps;
}

/* info block */
#identifiers {
  margin: 0;
  font-size: 0.9em;
}
#identifiers dt {
  width: 3em;
  clear: left;
}
#identifiers dd {
  float: left;
  margin-bottom: 0;
}
#identifiers .authors .author {
  display: inline-block;
  margin-right: 1.5em;
}
#identifiers .authors .org {
  font-style: italic;
}

/* The prepared/rendered info at the very bottom of the page */
.docInfo {
  color: #666; /* Arlen: WCAG 2019 */
  font-size: 0.9em;
  font-style: italic;
  margin-top: 2em;
}
.docInfo .prepared {
  float: left;
}
.docInfo .prepared {
  float: right;
}

/* table of contents */
#toc  {
  padding: 0.75em 0 2em 0;
  margin-bottom: 1em;
}
nav.toc ul {
  margin: 0 0.5em 0 0;
  padding: 0;
  list-style: none;
}
nav.toc li {
  line-height: 1.3em;
  margin: 0.75em 0;
  padding-left: 1.2em;
  text-indent: -1.2em;
}
/* references */
.references dt {
  text-align: right;
  font-weight: bold;
  min-width: 7em;
}
.references dd {
  margin-left: 8em;
  overflow: auto;
}

.refInstance {
  margin-bottom: 1.25em;
}

.references .ascii {
  margin-bottom: 0.25em;
}

/* index */
.index ul {
  margin: 0 0 0 1em;
  padding: 0;
  list-style: none;
}
.index ul ul {
  margin: 0;
}
.index li {
  margin: 0;
  text-indent: -2em;
  padding-left: 2em;
  padding-bottom: 5px;
}
.indexIndex {
  margin: 0.5em 0 1em;
}
.index a {
  font-weight: 700;
}
/* make the index two-column on all but the smallest screens */
@media (min-width: 600px) {
  .index ul {
    -moz-column-count: 2;
    -moz-column-gap: 20px;
  }
  .index ul ul {
    -moz-column-count: 1;
    -moz-column-gap: 0;
  }
}

/* authors */
address.vcard {
  font-style: normal;
  margin: 1em 0;
}

address.vcard .nameRole {
  font-weight: 700;
  margin-left: 0;
}
address.vcard .label {
  font-family: "Noto Sans",Arial,Helvetica,sans-serif;
  margin: 0.5em 0;
}
address.vcard .type {
  display: none;
}
.alternative-contact {
  margin: 1.5em 0 1em;
}
hr.addr {
  border-top: 1px dashed;
  margin: 0;
  color: #ddd;
  max-width: calc(100% - 16px);
}

/* temporary notes */
.rfcEditorRemove::before {
  position: absolute;
  top: 0.2em;
  right: 0.2em;
  padding: 0.2em;
  content: "The RFC Editor will remove this note";
  color: #9e2a00; /* Arlen: WCAG 2019 */
  background-color: #ffd; /* Arlen: WCAG 2019 */
}
.rfcEditorRemove {
  position: relative;
  padding-top: 1.8em;
  background-color: #ffd; /* Arlen: WCAG 2019 */
  border-radius: 3px;
}
.cref {
  background-color: #ffd; /* Arlen: WCAG 2019 */
  padding: 2px 4px;
}
.crefSource {
  font-style: italic;
}
/* alternative layout for smaller screens */
@media screen and (max-width: 1023px) {
  body {
    padding-top: 2em;
  }
  #title {
    padding: 1em 0;
  }
  h1 {
    font-size: 24px;
  }
  h2 {
    font-size: 20px;
    margin-top: -18px;  /* provide offset for in-page anchors */
    padding-top: 38px;
  }
  #identifiers dd {
    max-width: 60%;
  }
  #toc {
    position: fixed;
    z-index: 2;
    top: 0;
    right: 0;
    padding: 0;
    margin: 0;
    background-color: inherit;
    border-bottom: 1px solid #ccc;
  }
  #toc h2 {
    margin: -1px 0 0 0;
    padding: 4px 0 4px 6px;
    padding-right: 1em;
    min-width: 190px;
    font-size: 1.1em;
    text-align: right;
    background-color: #444;
    color: white;
    cursor: pointer;
  }
  #toc h2::before { /* css hamburger */
    float: right;
    position: relative;
    width: 1em;
    height: 1px;
    left: -164px;
    margin: 6px 0 0 0;
    background: white none repeat scroll 0 0;
    box-shadow: 0 4px 0 0 white, 0 8px 0 0 white;
    content: "";
  }
  #toc nav {
    display: none;
    padding: 0.5em 1em 1em;
    overflow: auto;
    height: calc(100vh - 48px);
    border-left: 1px solid #ddd;
  }
}

/* alternative layout for wide screens */
@media screen and (min-width: 1024px) {
  body {
    max-width: 724px;
    margin: 42px auto;
    padding-left: 1.5em;
    padding-right: 29em;
  }
  #toc {
    position: fixed;
    top: 42px;
    right: 42px;
    width: 25%;
    margin: 0;
    padding: 0 1em;
    z-index: 1;
  }
  #toc h2 {
    border-top: none;
    border-bottom: 1px solid #ddd;
    font-size: 1em;
    font-weight: normal;
    margin: 0;
    padding: 0.25em 1em 1em 0;
  }
  #toc nav {
    display: block;
    height: calc(90vh - 84px);
    bottom: 0;
    padding: 0.5em 0 0;
    overflow: auto;
  }
  img { /* future proofing */
    max-width: 100%;
    height: auto;
  }
}

/* pagination */
@media print {
  body {

    width: 100%;
  }
  p {
    orphans: 3;
    widows: 3;
  }
  #n-copyright-notice {
    border-bottom: none;
  }
  #toc, #n-introduction {
    page-break-before: always;
  }
  #toc {
    border-top: none;
    padding-top: 0;
  }
  figure, pre {
    page-break-inside: avoid;
  }
  figure {
    overflow: scroll;
  }
  h1, h2, h3, h4, h5, h6 {
    page-break-after: avoid;
  }
  h2+*, h3+*, h4+*, h5+*, h6+* {
    page-break-before: avoid;
  }
  pre {
    white-space: pre-wrap;
    word-wrap: break-word;
    font-size: 10pt;
  }
  table {
    border: 1px solid #ddd;
  }
  td {
    border-top: 1px solid #ddd;
  }
}

/* This is commented out here, as the string-set: doesn't
   pass W3C validation currently */
/*
.ears thead .left {
  string-set: ears-top-left content();
}

.ears thead .center {
  string-set: ears-top-center content();
}

.ears thead .right {
  string-set: ears-top-right content();
}

.ears tfoot .left {
  string-set: ears-bottom-left content();
}

.ears tfoot .center {
  string-set: ears-bottom-center content();
}

.ears tfoot .right {
  string-set: ears-bottom-right content();
}
*/

@page :first {
  padding-top: 0;
  @top-left {
    content: normal;
    border: none;
  }
  @top-center {
    content: normal;
    border: none;
  }
  @top-right {
    content: normal;
    border: none;
  }
}

@page {
  size: A4;
  margin-bottom: 45mm;
  padding-top: 20px;
  /* The follwing is commented out here, but set appropriately by in code, as
     the content depends on the document */
  /*
  @top-left {
    content: 'Internet-Draft';
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-left {
    content: string(ears-top-left);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-center {
    content: string(ears-top-center);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-right {
    content: string(ears-top-right);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @bottom-left {
    content: string(ears-bottom-left);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-center {
    content: string(ears-bottom-center);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-right {
      content: '[Page ' counter(page) ']';
      vertical-align: top;
      border-top: solid 1px #ccc;
  }
  */

}

/* Changes introduced to fix issues found during implementation */
/* Make sure links are clickable even if overlapped by following H* */
a {
  z-index: 2;
}
/* Separate body from document info even without intervening H1 */
section {
  clear: both;
}


/* Top align author divs, to avoid names without organization dropping level with org names */
.author {
  vertical-align: top;
}

/* Leave room in document info to show Internet-Draft on one line */
#identifiers dt {
  width: 8em;
}

/* Don't waste quite as much whitespace between label and value in doc info */
#identifiers dd {
  margin-left: 1em;
}

/* Give floating toc a background color (needed when it's a div inside section */
#toc {
  background-color: white;
}

/* Make the collapsed ToC header render white on gray also when it's a link */
@media screen and (max-width: 1023px) {
  #toc h2 a,
  #toc h2 a:link,
  #toc h2 a:focus,
  #toc h2 a:hover,
  #toc a.toplink,
  #toc a.toplink:hover {
    color: white;
    background-color: #444;
    text-decoration: none;
  }
}

/* Give the bottom of the ToC some whitespace */
@media screen and (min-width: 1024px) {
  #toc {
    padding: 0 0 1em 1em;
  }
}

/* Style section numbers with more space between number and title */
.section-number {
  padding-right: 0.5em;
}

/* prevent monospace from becoming overly large */
tt, code, pre, code {
  font-size: 95%;
}

/* Fix the height/width aspect for ascii art*/
pre.sourcecode,
.art-text pre {
  line-height: 1.12;
}


/* Add styling for a link in the ToC that points to the top of the document */
a.toplink {
  float: right;
  margin-right: 0.5em;
}

/* Fix the dl styling to match the RFC 7992 attributes */
dl > dt,
dl.dlParallel > dt {
  float: left;
  margin-right: 1em;
}
dl.dlNewline > dt {
  float: none;
}

/* Provide styling for table cell text alignment */
table td.text-left,
table th.text-left {
  text-align: left;
}
table td.text-center,
table th.text-center {
  text-align: center;
}
table td.text-right,
table th.text-right {
  text-align: right;
}

/* Make the alternative author contact informatio look less like just another
   author, and group it closer with the primary author contact information */
.alternative-contact {
  margin: 0.5em 0 0.25em 0;
}
address .non-ascii {
  margin: 0 0 0 2em;
}

/* With it being possible to set tables with alignment
  left, center, and right, { width: 100%; } does not make sense */
table {
  width: auto;
}

/* Avoid reference text that sits in a block with very wide left margin,
   because of a long floating dt label.*/
.references dd {
  overflow: visible;
}

/* Control caption placement */
caption {
  caption-side: bottom;
}

/* Limit the width of the author address vcard, so names in right-to-left
   script don't end up on the other side of the page. */

address.vcard {
  max-width: 30em;
  margin-right: auto;
}

/* For address alignment dependent on LTR or RTL scripts */
address div.left {
  text-align: left;
}
address div.right {
  text-align: right;
}

/* Provide table alignment support.  We can't use the alignX classes above
   since they do unwanted things with caption and other styling. */
table.right {
 margin-left: auto;
 margin-right: 0;
}
table.center {
 margin-left: auto;
 margin-right: auto;
}
table.left {
 margin-left: 0;
 margin-right: auto;
}

/* Give the table caption label the same styling as the figcaption */
caption a[href] {
  color: #222;
}

@media print {
  .toplink {
    display: none;
  }

  /* avoid overwriting the top border line with the ToC header */
  #toc {
    padding-top: 1px;
  }

  /* Avoid page breaks inside dl and author address entries */
  .vcard {
    page-break-inside: avoid;
  }

}
/* Avoid wrapping of URLs in references */
@media screen {
  .references a {
    white-space: nowrap;
  }
}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin: 0 0 0.25em 0;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .sourcecode {
    margin-bottom: 1em;
  }
}</style>
<link href="rfc-local.css" type="text/css" rel="stylesheet">
<link href="https://dx.doi.org/10.17487/rfc8689" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-uta-smtp-require-tls-09" rel="prev">
  </head>
<body>
<script src="https://www.rfc-editor.org/js/metadata.min.js"></script>
<table class="ears">
<thead><tr>
<td class="left">RFC 8689</td>
<td class="center">SMTP Require TLS Option</td>
<td class="right">November 2019</td>
</tr></thead>
<tfoot><tr>
<td class="left">Fenton</td>
<td class="center">Standards Track</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Internet Engineering Task Force (IETF)</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc8689" class="eref">8689</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Standards Track</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2019-11" class="published">November 2019</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Author:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">J. Fenton</div>
<div class="org">Altmode Networks</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8689</h1>
<h1 id="title">SMTP Require TLS Option</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">The SMTP STARTTLS option, used in negotiating transport-level
     encryption of SMTP connections, is not as 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 or by requesting
     that recipient-side policy mechanisms such as MTA-STS and DNS-Based
     Authentication of Named Entities (DANE) be
     ignored when relaying a message for which security is
     unimportant.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This is an Internet Standards Track document.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <span><a href="https://www.rfc-editor.org/info/rfc8689">https://www.rfc-editor.org/info/rfc8689</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2019 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) 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 Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.1.2.1">
                <p id="section-toc.1-1.1.2.1.1"><a href="#section-1.1" class="xref">1.1</a>.  <a href="#name-requirements-language" class="xref">Requirements Language</a><a href="#section-toc.1-1.1.2.1.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-the-requiretls-service-exte" class="xref">The REQUIRETLS Service Extension</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-the-tls-required-header-fie" class="xref">The TLS-Required Header Field</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-requiretls-semantics" class="xref">REQUIRETLS Semantics</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.4.2.1">
                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-requiretls-receipt-requirem" class="xref">REQUIRETLS Receipt Requirements</a><a href="#section-toc.1-1.4.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.4.2.2">
                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-requiretls-sender-requireme" class="xref">REQUIRETLS Sender Requirements</a><a href="#section-toc.1-1.4.2.2.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.4.2.2.2.1">
                    <p id="section-toc.1-1.4.2.2.2.1.1"><a href="#section-4.2.1" class="xref">4.2.1</a>.  <a href="#name-sending-with-tls-required" class="xref">Sending with TLS Required</a><a href="#section-toc.1-1.4.2.2.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc ulEmpty" id="section-toc.1-1.4.2.2.2.2">
                    <p id="section-toc.1-1.4.2.2.2.2.1"><a href="#section-4.2.2" class="xref">4.2.2</a>.  <a href="#name-sending-with-tls-optional" class="xref">Sending with TLS Optional</a><a href="#section-toc.1-1.4.2.2.2.2.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.4.2.3">
                <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-requiretls-submission" class="xref">REQUIRETLS Submission</a><a href="#section-toc.1-1.4.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.4.2.4">
                <p id="section-toc.1-1.4.2.4.1"><a href="#section-4.4" class="xref">4.4</a>.  <a href="#name-delivery-of-requiretls-mess" class="xref">Delivery of REQUIRETLS messages</a><a href="#section-toc.1-1.4.2.4.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-non-delivery-message-handli" class="xref">Non-delivery Message Handling</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-reorigination-consideration" class="xref">Reorigination Considerations</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.8.2.1">
                <p id="section-toc.1-1.8.2.1.1"><a href="#section-8.1" class="xref">8.1</a>.  <a href="#name-passive-attacks" class="xref">Passive Attacks</a><a href="#section-toc.1-1.8.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.8.2.2">
                <p id="section-toc.1-1.8.2.2.1"><a href="#section-8.2" class="xref">8.2</a>.  <a href="#name-active-attacks" class="xref">Active Attacks</a><a href="#section-toc.1-1.8.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.8.2.3">
                <p id="section-toc.1-1.8.2.3.1"><a href="#section-8.3" class="xref">8.3</a>.  <a href="#name-bad-actor-mtas" class="xref">Bad-Actor MTAs</a><a href="#section-toc.1-1.8.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.8.2.4">
                <p id="section-toc.1-1.8.2.4.1"><a href="#section-8.4" class="xref">8.4</a>.  <a href="#name-policy-conflicts" class="xref">Policy Conflicts</a><a href="#section-toc.1-1.8.2.4.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-references" class="xref">References</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.9.2.1">
                <p id="section-toc.1-1.9.2.1.1"><a href="#section-9.1" class="xref">9.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.9.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.9.2.2">
                <p id="section-toc.1-1.9.2.2.1"><a href="#section-9.2" class="xref">9.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.9.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-appendix.a" class="xref">Appendix A</a>.  <a href="#name-examples" class="xref">Examples</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.10.2.1">
                <p id="section-toc.1-1.10.2.1.1"><a href="#section-a.1" class="xref">A.1</a>.  <a href="#name-requiretls-smtp-option" class="xref">REQUIRETLS SMTP Option</a><a href="#section-toc.1-1.10.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.10.2.2">
                <p id="section-toc.1-1.10.2.2.1"><a href="#section-a.2" class="xref">A.2</a>.  <a href="#name-tls-required-header-field" class="xref">TLS-Required Header Field</a><a href="#section-toc.1-1.10.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#section-appendix.c" class="xref"></a><a href="#name-authors-address" class="xref">Author's Address</a><a href="#section-toc.1-1.12.1" class="pilcrow">¶</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">The <span><a href="#RFC5321" class="xref">SMTP</a> [<a href="#RFC5321" class="xref">RFC5321</a>]</span> <span><a href="#RFC3207" class="xref">STARTTLS service extension</a> [<a href="#RFC3207" class="xref">RFC3207</a>]</span> 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.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">Policy mechanisms such as <span><a href="#RFC7672" class="xref">DANE</a> [<a href="#RFC7672" class="xref">RFC7672</a>]</span>
     and <span><a href="#RFC8461" class="xref">MTA-STS</a> [<a href="#RFC8461" class="xref">RFC8461</a>]</span> 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 and which ones are less sensitive and
     ought to be relayed even if TLS cannot be negotiated
     successfully.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">The default opportunistic nature of SMTP TLS enables several
     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 <a href="#Security" class="xref">Security Considerations</a> section
     of this
     document.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">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
     <span class="bcp14">MUST</span> 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.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">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.<a href="#section-1-5" class="pilcrow">¶</a></p>
<section id="section-1.1">
        <h3 id="name-requirements-language">
<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-requirements-language" class="section-name selfRef">Requirements Language</a>
        </h3>
<p id="section-1.1-1">
    The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>",
    "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>", "<span class="bcp14">SHALL NOT</span>", "<span class="bcp14">SHOULD</span>", "<span class="bcp14">SHOULD NOT</span>",
    "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>",
    "<span class="bcp14">MAY</span>", and "<span class="bcp14">OPTIONAL</span>" in this document are
    to be interpreted as described in BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span>
          <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> when, and only when, they appear in all capitals,
    as shown here.<a href="#section-1.1-1" class="pilcrow">¶</a></p>
<p id="section-1.1-2">The formal syntax uses the Augmented Backus-Naur Form (ABNF)
       <span>[<a href="#RFC5234" class="xref">RFC5234</a>]</span>, including the core rules defined in
       Appendix B of that document.<a href="#section-1.1-2" class="pilcrow">¶</a></p>
</section>
</section>
<div id="service_extension">
<section id="section-2">
      <h2 id="name-the-requiretls-service-exte">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-the-requiretls-service-exte" class="section-name selfRef">The REQUIRETLS Service Extension</a>
      </h2>
<p id="section-2-1">The REQUIRETLS SMTP service extension has the following characteristics:<a href="#section-2-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal" id="section-2-2">
        <li id="section-2-2.1">The textual name of the extension is "Require TLS".<a href="#section-2-2.1" class="pilcrow">¶</a>
</li>
        <li id="section-2-2.2">The EHLO keyword value associated with this extension is
       "REQUIRETLS".<a href="#section-2-2.2" class="pilcrow">¶</a>
</li>
        <li id="section-2-2.3">No additional SMTP verbs are defined by this extension.<a href="#section-2-2.3" class="pilcrow">¶</a>
</li>
        <li id="section-2-2.4">One optional parameter ("REQUIRETLS") is added to the MAIL
       FROM command by this extension. No value is associated with
       this parameter.<a href="#section-2-2.4" class="pilcrow">¶</a>
</li>
        <li id="section-2-2.5">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.<a href="#section-2-2.5" class="pilcrow">¶</a>
</li>
        <li id="section-2-2.6">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 support
       the REQUIRETLS extension.<a href="#section-2-2.6" class="pilcrow">¶</a>
</li>
        <li id="section-2-2.7">The REQUIRETLS extension is valid for message relay <span>[<a href="#RFC5321" class="xref">RFC5321</a>]</span>, submission <span>[<a href="#RFC6409" class="xref">RFC6409</a>]</span>, and the Local Mail Transfer Protocol
       (LMTP) <span>[<a href="#RFC2033" class="xref">RFC2033</a>]</span>.<a href="#section-2-2.7" class="pilcrow">¶</a>
</li>
        <li id="section-2-2.8">
          <p id="section-2-2.8.1">The ABNF syntax for the MAIL FROM parameter is as follows:<a href="#section-2-2.8.1" class="pilcrow">¶</a></p>
<div id="section-2-2.8.2">
<pre class="sourcecode lang-abnf">
requiretls-param  = "REQUIRETLS"
                ; where requiretls-param is an instance of an
                ; esmtp-param used in Mail-parameters in
                ; RFC 5321, Section 4.1.2. There is no esmtp-value
                ; associated with requiretls-param. </pre><a href="#section-2-2.8.2" class="pilcrow">¶</a>
</div>
</li>
      </ol>
<p id="section-2-3">In order to specify REQUIRETLS treatment for a given message,
     the REQUIRETLS option is specified in the MAIL FROM command when
     that message is transmitted. This option <span class="bcp14">MUST</span> only be specified in the
     context of an SMTP session meeting the security requirements of
     REQUIRETLS:<a href="#section-2-3" class="pilcrow">¶</a></p>
<ul>
<li id="section-2-4.1">The session itself <span class="bcp14">MUST</span> employ TLS transmission.<a href="#section-2-4.1" class="pilcrow">¶</a>
</li>
        <li id="section-2-4.2">If the SMTP server to which the message is being transmitted
       is identified through an MX record lookup, its name
       <span class="bcp14">MUST</span> be validated via a DNSSEC signature on the recipient
       domain's MX record, or the MX hostname <span class="bcp14">MUST</span> be
       validated by an MTA-STS policy as described in <span><a href="https://www.rfc-editor.org/rfc/rfc8461#section-4.1" class="relref">Section 4.1</a> of [<a href="#RFC8461" class="xref">RFC8461</a>]</span>. DNSSEC is defined
       in <span>[<a href="#RFC4033" class="xref">RFC4033</a>]</span>,
       <span>[<a href="#RFC4034" class="xref">RFC4034</a>]</span>, and
       <span>[<a href="#RFC4035" class="xref">RFC4035</a>]</span>.<a href="#section-2-4.2" class="pilcrow">¶</a>
</li>
        <li id="section-2-4.3">The certificate presented by the SMTP server either <span class="bcp14">MUST</span>
       be verified successfully by a trust chain leading to a certificate
       trusted by the SMTP client, or it <span class="bcp14">MUST</span> be verified successfully using
       DANE, as specified in <span>[<a href="#RFC7672" class="xref">RFC7672</a>]</span>. For trust chains, the
       choice of trusted (root) certificates is at the discretion of
       the SMTP client.<a href="#section-2-4.3" class="pilcrow">¶</a>
</li>
        <li id="section-2-4.4">Following the negotiation of STARTTLS, the SMTP server <span class="bcp14">MUST</span>
       advertise in the subsequent EHLO response that it supports REQUIRETLS.<a href="#section-2-4.4" class="pilcrow">¶</a>
</li>
      </ul>
</section>
</div>
<div id="header_field">
<section id="section-3">
      <h2 id="name-the-tls-required-header-fie">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-the-tls-required-header-fie" class="section-name selfRef">The TLS-Required Header Field</a>
      </h2>
<p id="section-3-1">One new message header field <span>[<a href="#RFC5322" class="xref">RFC5322</a>]</span>,
     TLS-Required, is defined by this
     specification. It is used for messages for which the originator
     requests that the recipient
     TLS policy (including <span><a href="#RFC8461" class="xref">MTA-STS</a> [<a href="#RFC8461" class="xref">RFC8461</a>]</span> and
     <span><a href="#RFC7672" class="xref">DANE</a> [<a href="#RFC7672" class="xref">RFC7672</a>]</span>) be ignored. This might be
     done, for example, to report a misconfigured mail server, such as
     an expired TLS certificate.<a href="#section-3-1" class="pilcrow">¶</a></p>
<p id="section-3-2">The TLS-Required header field has a single <span class="bcp14">REQUIRED</span> parameter:<a href="#section-3-2" class="pilcrow">¶</a></p>
<ul>
<li id="section-3-3.1">No - The SMTP client <span class="bcp14">SHOULD</span> 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 <span class="bcp14">SHOULD</span> negotiate
      STARTTLS with the server if available.<a href="#section-3-3.1" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-3-4">More than one instance of the TLS-Required header field <span class="bcp14">MUST NOT</span> appear in a given message.<a href="#section-3-4" class="pilcrow">¶</a></p>
<p id="section-3-5">The ABNF syntax for the TLS-Required header field is as
     follows:<a href="#section-3-5" class="pilcrow">¶</a></p>
<div id="section-3-6">
<pre class="sourcecode lang-abnf">
requiretls-field = "TLS-Required:" [FWS] "No" CRLF
        ; where requiretls-field in an instance of an
        ; optional-field defined in RFC 5322, Section 3.6.8.
FWS = &lt;as defined in RFC 5322&gt;
CRLF = &lt;as defined in RFC 5234&gt; </pre><a href="#section-3-6" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="semantics">
<section id="section-4">
      <h2 id="name-requiretls-semantics">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-requiretls-semantics" class="section-name selfRef">REQUIRETLS Semantics</a>
      </h2>
<div id="receipt">
<section id="section-4.1">
        <h3 id="name-requiretls-receipt-requirem">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-requiretls-receipt-requirem" class="section-name selfRef">REQUIRETLS Receipt Requirements</a>
        </h3>
<p id="section-4.1-1">Upon receipt of the REQUIRETLS option on a MAIL FROM command
       during the receipt of a message, an SMTP server <span class="bcp14">MUST</span> tag that
       message as needing REQUIRETLS handling.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<p id="section-4.1-2">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 <span class="bcp14">MUST</span> 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
       <span class="bcp14">MUST</span> be ignored but <span class="bcp14">MAY</span> be included in the onward relay of the
       message.<a href="#section-4.1-2" class="pilcrow">¶</a></p>
<p id="section-4.1-3">The manner in which the above tagging takes place is
       implementation dependent. If the message is being locally
       aliased and redistributed to multiple addresses, all instances
       of the message <span class="bcp14">MUST</span> be tagged in the same manner.<a href="#section-4.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sender">
<section id="section-4.2">
        <h3 id="name-requiretls-sender-requireme">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-requiretls-sender-requireme" class="section-name selfRef">REQUIRETLS Sender Requirements</a>
        </h3>
<div id="yestls">
<section id="section-4.2.1">
          <h4 id="name-sending-with-tls-required">
<a href="#section-4.2.1" class="section-number selfRef">4.2.1. </a><a href="#name-sending-with-tls-required" class="section-name selfRef">Sending with TLS Required</a>
          </h4>
<p id="section-4.2.1-1">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 <span class="bcp14">MUST</span>:<a href="#section-4.2.1-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal" id="section-4.2.1-2">
            <li id="section-4.2.1-2.1">Look up the SMTP server to which the message is to be sent,
  as described in <span>[<a href="#RFC5321" class="xref">RFC5321</a>], <a href="https://www.rfc-editor.org/rfc/rfc5321#section-5.1" class="relref">Section 5.1</a></span>.<a href="#section-4.2.1-2.1" class="pilcrow">¶</a>
</li>
            <li id="section-4.2.1-2.2">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 <span class="bcp14">MUST</span> also validate the SMTP
  server name using MTA-STS, as described in
         <span>[<a href="#RFC8461" class="xref">RFC8461</a>], <a href="https://www.rfc-editor.org/rfc/rfc8461#section-4.1" class="relref">Section 4.1</a></span>.<a href="#section-4.2.1-2.2" class="pilcrow">¶</a>
</li>
            <li id="section-4.2.1-2.3">Open an SMTP session with the peer SMTP server using the
  EHLO verb.<a href="#section-4.2.1-2.3" class="pilcrow">¶</a>
</li>
            <li id="section-4.2.1-2.4">Establish a TLS-protected SMTP session with its peer SMTP
  server and authenticate the server's certificate as specified
  in <span>[<a href="#RFC6125" class="xref">RFC6125</a>]</span> or <span>[<a href="#RFC7672" class="xref">RFC7672</a>]</span>, 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) <span class="bcp14">MUST</span> match the DNS-ID
   or CN-ID of the certificate presented by the server.<a href="#section-4.2.1-2.4" class="pilcrow">¶</a>
</li>
            <li id="section-4.2.1-2.5">Ensure that the response to the subsequent EHLO following
  establishment of the TLS protection advertises the REQUIRETLS
  capability.<a href="#section-4.2.1-2.5" class="pilcrow">¶</a>
</li>
          </ol>
<p id="section-4.2.1-3">The SMTP client <span class="bcp14">SHOULD</span> follow the recommendations in <span>[<a href="#RFC7525" class="xref">RFC7525</a>]</span> or its successor with respect to
       negotiation of the TLS session.<a href="#section-4.2.1-3" class="pilcrow">¶</a></p>
<p id="section-4.2.1-4">If any of the above steps fail, the client <span class="bcp14">MUST</span> 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 <span class="bcp14">MAY</span>
       send other, 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 <span class="bcp14">MUST NOT</span> transmit the message to the domain.<a href="#section-4.2.1-4" class="pilcrow">¶</a></p>
<p id="section-4.2.1-5">Following such a failure, the SMTP client <span class="bcp14">MUST</span> send a
       non-delivery notification to the reverse-path of the failed
       message, as described in <span><a href="https://www.rfc-editor.org/rfc/rfc5321#section-3.6" class="relref">Section 3.6</a> of [<a href="#RFC5321" class="xref">RFC5321</a>]</span>. The
       following <span><a href="#RFC5248" class="xref">status codes</a> [<a href="#RFC5248" class="xref">RFC5248</a>]</span> <span class="bcp14">SHOULD</span> be used:<a href="#section-4.2.1-5" class="pilcrow">¶</a></p>
<ul>
<li id="section-4.2.1-6.1">REQUIRETLS not supported by server: 5.7.30 REQUIRETLS
  support required<a href="#section-4.2.1-6.1" class="pilcrow">¶</a>
</li>
            <li id="section-4.2.1-6.2">Unable to establish TLS-protected SMTP session: 5.7.10
  Encryption needed<a href="#section-4.2.1-6.2" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-4.2.1-7">Refer to <a href="#errors" class="xref">Section 5</a> for further requirements regarding
       non-delivery messages.<a href="#section-4.2.1-7" class="pilcrow">¶</a></p>
<p id="section-4.2.1-8">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.<a href="#section-4.2.1-8" class="pilcrow">¶</a></p>
</section>
</div>
<div id="maytls">
<section id="section-4.2.2">
          <h4 id="name-sending-with-tls-optional">
<a href="#section-4.2.2" class="section-number selfRef">4.2.2. </a><a href="#name-sending-with-tls-optional" class="section-name selfRef">Sending with TLS Optional</a>
          </h4>
<p id="section-4.2.2-1">Messages tagged "TLS-Required: No" are handled as
  follows. When sending such a message, the sending (client)
  MTA <span class="bcp14">MUST</span>:<a href="#section-4.2.2-1" class="pilcrow">¶</a></p>
<ul>
<li id="section-4.2.2-2.1">Look up the SMTP server to which the message is to be
    sent, as described in <span>[<a href="#RFC5321" class="xref">RFC5321</a>], <a href="https://www.rfc-editor.org/rfc/rfc5321#section-5.1" class="relref">Section 5.1</a></span>.<a href="#section-4.2.2-2.1" class="pilcrow">¶</a>
</li>
            <li id="section-4.2.2-2.2">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.<a href="#section-4.2.2-2.2" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-4.2.2-3">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 <span class="bcp14">MUST</span> be
  returned to the sender if message relay fails due to an
  inability to negotiate STARTTLS when required by the
  server.<a href="#section-4.2.2-3" class="pilcrow">¶</a></p>
<p id="section-4.2.2-4">Since messages tagged with "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.<a href="#section-4.2.2-4" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="submission">
<section id="section-4.3">
        <h3 id="name-requiretls-submission">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-requiretls-submission" class="section-name selfRef">REQUIRETLS Submission</a>
        </h3>
<p id="section-4.3-1">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 <span class="bcp14">MUST</span> do so by negotiating STARTTLS
       and REQUIRETLS and including the REQUIRETLS option on the MAIL
       FROM command, as is done for message relay.<a href="#section-4.3-1" class="pilcrow">¶</a></p>
<p id="section-4.3-2">When TLS is not to be required, the sender <span class="bcp14">MUST</span> include the
       TLS-Required header field in the message. SMTP servers
       implementing this specification <span class="bcp14">MUST</span> interpret this header
       field as described in <a href="#receipt" class="xref">Section 4.1</a>.<a href="#section-4.3-2" class="pilcrow">¶</a></p>
<p id="section-4.3-3">In either case, the decision whether to specify REQUIRETLS
       <span class="bcp14">MAY</span> 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 and is beyond
       the scope of this specification.<a href="#section-4.3-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="delivery">
<section id="section-4.4">
        <h3 id="name-delivery-of-requiretls-mess">
<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-delivery-of-requiretls-mess" class="section-name selfRef">Delivery of REQUIRETLS messages</a>
        </h3>
<p id="section-4.4-1">Messages are usually retrieved by end users using protocols
       other than SMTP such as <span><a href="#RFC3501" class="xref">IMAP</a> [<a href="#RFC3501" class="xref">RFC3501</a>]</span>,
       <span><a href="#RFC1939" class="xref">POP</a> [<a href="#RFC1939" class="xref">RFC1939</a>]</span>, or Web mail systems. Mail
       delivery agents supporting the REQUIRETLS SMTP option <span class="bcp14">SHOULD</span>
       observe the guidelines in <span>[<a href="#RFC8314" class="xref">RFC8314</a>]</span>.<a href="#section-4.4-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="errors">
<section id="section-5">
      <h2 id="name-non-delivery-message-handli">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-non-delivery-message-handli" class="section-name selfRef">Non-delivery Message Handling</a>
      </h2>
<p id="section-5-1">Non-delivery ("bounce") messages usually contain important
       metadata about the message to which they refer, including the
       original message header. They therefore <span class="bcp14">MUST</span> 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 issue, <span class="bcp14">MUST</span>
   also specify the REQUIRETLS SMTP option unless redacted as described below.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">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.<a href="#section-5-2" class="pilcrow">¶</a></p>
<p id="section-5-3">If a REQUIRETLS message is bounced, the server <span class="bcp14">MUST</span> behave
       as if RET=HDRS was present, as described in <span>[<a href="#RFC3461" class="xref">RFC3461</a>]</span>. If both RET=FULL and REQUIRETLS are
       present, the RET=FULL <span class="bcp14">MUST</span> be disregarded. The SMTP client for a
       REQUIRETLS bounce message uses an empty MAIL FROM
       return-path, as required by <span>[<a href="#RFC5321" class="xref">RFC5321</a>]</span>. When
       the MAIL FROM return-path is empty, the REQUIRETLS parameter
       <span class="bcp14">SHOULD NOT</span> cause a bounce message to be discarded even if the
       next-hop relay does not advertise REQUIRETLS.<a href="#section-5-3" class="pilcrow">¶</a></p>
<p id="section-5-4">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 and that some information
       could be leaked if a bounce message is not able to be
       transmitted with REQUIRETLS.<a href="#section-5-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="reorigination">
<section id="section-6">
      <h2 id="name-reorigination-consideration">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-reorigination-consideration" class="section-name selfRef">Reorigination Considerations</a>
      </h2>
<p id="section-6-1">In a number of situations, a <span><a href="#RFC5598" class="xref">mediator</a> [<a href="#RFC5598" class="xref">RFC5598</a>]</span>
      originates a new message as a result of an incoming message. These
      situations include but are not limited to mailing lists (including
      administrative traffic such as message approval requests),
      <span><a href="#RFC5228" class="xref">Sieve</a> [<a href="#RFC5228" class="xref">RFC5228</a>]</span>, "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.<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">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.<a href="#section-6-2" class="pilcrow">¶</a></p>
<p id="section-6-3">User-side mediators (such as use of Sieve rules on a user agent)
      typically do not have access to the SMTP 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.<a href="#section-6-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="IANA">
<section id="section-7">
      <h2 id="name-iana-considerations">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-7-1">Per this document, IANA has added
     the following keyword to the "SMTP Service Extensions" subregistry of the
      <span><a href="#MailParams" class="xref">"Mail Parameters" registry</a> [<a href="#MailParams" class="xref">MailParams</a>]</span>:<a href="#section-7-1" class="pilcrow">¶</a></p>
<ul class="ulEmpty">
<li class="ulEmpty" id="section-7-2.1">
          <dl class="dlParallel dlCompact" id="section-7-2.1.1">
            <dt id="section-7-2.1.1.1">EHLO Keyword:</dt>
            <dd style="margin-left: 15.0em" id="section-7-2.1.1.2">REQUIRETLS<a href="#section-7-2.1.1.2" class="pilcrow">¶</a>
</dd>
<dt id="section-7-2.1.1.3">Description:</dt>
            <dd style="margin-left: 15.0em" id="section-7-2.1.1.4">Require TLS<a href="#section-7-2.1.1.4" class="pilcrow">¶</a>
</dd>
<dt id="section-7-2.1.1.5">Syntax and parameters:</dt>
            <dd style="margin-left: 15.0em" id="section-7-2.1.1.6">(no parameters)<a href="#section-7-2.1.1.6" class="pilcrow">¶</a>
</dd>
<dt id="section-7-2.1.1.7">Additional SMTP verbs:</dt>
            <dd style="margin-left: 15.0em" id="section-7-2.1.1.8">none<a href="#section-7-2.1.1.8" class="pilcrow">¶</a>
</dd>
<dt id="section-7-2.1.1.9">MAIL and RCPT parameters:</dt>
            <dd style="margin-left: 15.0em" id="section-7-2.1.1.10">REQUIRETLS parameter on MAIL<a href="#section-7-2.1.1.10" class="pilcrow">¶</a>
</dd>
<dt id="section-7-2.1.1.11">Behavior:</dt>
            <dd style="margin-left: 15.0em" id="section-7-2.1.1.12">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.<a href="#section-7-2.1.1.12" class="pilcrow">¶</a>
</dd>
<dt id="section-7-2.1.1.13">Command length increment:</dt>
            <dd style="margin-left: 15.0em" id="section-7-2.1.1.14">11 characters<a href="#section-7-2.1.1.14" class="pilcrow">¶</a>
</dd>
</dl>
</li>
      </ul>
<p id="section-7-3">Per this document, IANA has added an
     entry to the "Enumerated Status Codes" subregistry of the <span><a href="#SMTPStatusCodes" class="xref">"Simple Mail Transfer Protocol (SMTP) Enhanced Status
     Codes Registry"</a> [<a href="#SMTPStatusCodes" class="xref">SMTPStatusCodes</a>]</span>:<a href="#section-7-3" class="pilcrow">¶</a></p>
<ul class="ulEmpty">
<li class="ulEmpty" id="section-7-4.1">
          <dl class="dlParallel dlCompact" id="section-7-4.1.1">
            <dt id="section-7-4.1.1.1">Code:</dt>
            <dd style="margin-left: 15.0em" id="section-7-4.1.1.2">X.7.30<a href="#section-7-4.1.1.2" class="pilcrow">¶</a>
</dd>
<dt id="section-7-4.1.1.3">Sample Text:</dt>
            <dd style="margin-left: 15.0em" id="section-7-4.1.1.4">REQUIRETLS support required<a href="#section-7-4.1.1.4" class="pilcrow">¶</a>
</dd>
<dt id="section-7-4.1.1.5">Associated basic status code:</dt>
            <dd style="margin-left: 15.0em" id="section-7-4.1.1.6">550<a href="#section-7-4.1.1.6" class="pilcrow">¶</a>
</dd>
<dt id="section-7-4.1.1.7">Description:</dt>
            <dd style="margin-left: 15.0em" id="section-7-4.1.1.8">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.<a href="#section-7-4.1.1.8" class="pilcrow">¶</a>
</dd>
<dt id="section-7-4.1.1.9">Reference:</dt>
            <dd style="margin-left: 15.0em" id="section-7-4.1.1.10">RFC 8689<a href="#section-7-4.1.1.10" class="pilcrow">¶</a>
</dd>
<dt id="section-7-4.1.1.11">Submitter:</dt>
            <dd style="margin-left: 15.0em" id="section-7-4.1.1.12">J. Fenton<a href="#section-7-4.1.1.12" class="pilcrow">¶</a>
</dd>
<dt id="section-7-4.1.1.13">Change Controller:</dt>
            <dd style="margin-left: 15.0em" id="section-7-4.1.1.14">IESG<a href="#section-7-4.1.1.14" class="pilcrow">¶</a>
</dd>
</dl>
</li>
      </ul>
<p id="section-7-5">Per this document, IANA has added
     an entry to the "Permanent Message Header Field
     Names" subregistry of the <span><a href="#MessageHeaders" class="xref">"Message Headers" registry</a> [<a href="#MessageHeaders" class="xref">MessageHeaders</a>]</span> as follows:<a href="#section-7-5" class="pilcrow">¶</a></p>
<ul class="ulEmpty">
<li class="ulEmpty" id="section-7-6.1">
          <dl class="dlParallel dlCompact" id="section-7-6.1.1">
            <dt id="section-7-6.1.1.1">Header field name:</dt>
            <dd style="margin-left: 15.0em" id="section-7-6.1.1.2">TLS-Required<a href="#section-7-6.1.1.2" class="pilcrow">¶</a>
</dd>
<dt id="section-7-6.1.1.3">Applicable protocol:</dt>
            <dd style="margin-left: 15.0em" id="section-7-6.1.1.4">mail<a href="#section-7-6.1.1.4" class="pilcrow">¶</a>
</dd>
<dt id="section-7-6.1.1.5">Status:</dt>
            <dd style="margin-left: 15.0em" id="section-7-6.1.1.6">standard<a href="#section-7-6.1.1.6" class="pilcrow">¶</a>
</dd>
<dt id="section-7-6.1.1.7">Author/change controller:</dt>
            <dd style="margin-left: 15.0em" id="section-7-6.1.1.8">IETF<a href="#section-7-6.1.1.8" class="pilcrow">¶</a>
</dd>
<dt id="section-7-6.1.1.9">Specification document:</dt>
            <dd style="margin-left: 15.0em" id="section-7-6.1.1.10">RFC 8689<a href="#section-7-6.1.1.10" class="pilcrow">¶</a>
</dd>
</dl>
</li>
      </ul>
</section>
</div>
<div id="Security">
<section id="section-8">
      <h2 id="name-security-considerations">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-8-1">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.<a href="#section-8-1" class="pilcrow">¶</a></p>
<p id="section-8-2">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.<a href="#section-8-2" class="pilcrow">¶</a></p>
<div id="Passive">
<section id="section-8.1">
        <h3 id="name-passive-attacks">
<a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-passive-attacks" class="section-name selfRef">Passive Attacks</a>
        </h3>
<p id="section-8.1-1">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.<a href="#section-8.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="Active">
<section id="section-8.2">
        <h3 id="name-active-attacks">
<a href="#section-8.2" class="section-number selfRef">8.2. </a><a href="#name-active-attacks" class="section-name selfRef">Active Attacks</a>
        </h3>
<p id="section-8.2-1">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 href="#section-8.2-1" class="pilcrow">¶</a></p>
<p id="section-8.2-2">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.<a href="#section-8.2-2" class="pilcrow">¶</a></p>
<p id="section-8.2-3">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.<a href="#section-8.2-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="badactor">
<section id="section-8.3">
        <h3 id="name-bad-actor-mtas">
<a href="#section-8.3" class="section-number selfRef">8.3. </a><a href="#name-bad-actor-mtas" class="section-name selfRef">Bad-Actor MTAs</a>
        </h3>
<p id="section-8.3-1">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.<a href="#section-8.3-1" class="pilcrow">¶</a></p>
<p id="section-8.3-2">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 <span class="bcp14">MUST</span> be sent using end-to-end content encryption
  such as <span><a href="#RFC4880" class="xref">OpenPGP</a> [<a href="#RFC4880" class="xref">RFC4880</a>]</span> or <span><a href="#RFC8551" class="xref">S/MIME</a> [<a href="#RFC8551" class="xref">RFC8551</a>]</span>.<a href="#section-8.3-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="conflicts">
<section id="section-8.4">
        <h3 id="name-policy-conflicts">
<a href="#section-8.4" class="section-number selfRef">8.4. </a><a href="#name-policy-conflicts" class="section-name selfRef">Policy Conflicts</a>
        </h3>
<p id="section-8.4-1">In some cases, the use of the TLS-Required header field may conflict
with a recipient domain policy expressed through the <span><a href="#RFC7672" class="xref">DANE</a> [<a href="#RFC7672" class="xref">RFC7672</a>]</span> or <span><a href="#RFC8461" class="xref">MTA-STS</a> [<a href="#RFC8461" class="xref">RFC8461</a>]</span> 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.<a href="#section-8.4-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<section id="section-9">
      <h2 id="name-references">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-9.1">
        <h3 id="name-normative-references">
<a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="MailParams">[MailParams]</dt>
        <dd>
<span class="refAuthor">IANA</span>, <span class="refTitle">"Mail Parameters"</span>, <span>&lt;<a href="http://www.iana.org/assignments/mail-parameters">http://www.iana.org/assignments/mail-parameters</a>&gt;</span>. </dd>
<dt id="MessageHeaders">[MessageHeaders]</dt>
        <dd>
<span class="refAuthor">IANA</span>, <span class="refTitle">"Permanent Message Header Field Names"</span>, <span>&lt;<a href="https://www.iana.org/assignments/message-headers">https://www.iana.org/assignments/message-headers</a>&gt;</span>. </dd>
<dt id="RFC2119">[RFC2119]</dt>
        <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dt id="RFC3207">[RFC3207]</dt>
        <dd>
<span class="refAuthor">Hoffman, P.</span>, <span class="refTitle">"SMTP Service Extension for Secure SMTP over Transport Layer Security"</span>, <span class="seriesInfo">RFC 3207</span>, <span class="seriesInfo">DOI 10.17487/RFC3207</span>, <time datetime="2002-02">February 2002</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3207">https://www.rfc-editor.org/info/rfc3207</a>&gt;</span>. </dd>
<dt id="RFC3461">[RFC3461]</dt>
        <dd>
<span class="refAuthor">Moore, K.</span>, <span class="refTitle">"Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)"</span>, <span class="seriesInfo">RFC 3461</span>, <span class="seriesInfo">DOI 10.17487/RFC3461</span>, <time datetime="2003-01">January 2003</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3461">https://www.rfc-editor.org/info/rfc3461</a>&gt;</span>. </dd>
<dt id="RFC4033">[RFC4033]</dt>
        <dd>
<span class="refAuthor">Arends, R.</span><span class="refAuthor">, Austein, R.</span><span class="refAuthor">, Larson, M.</span><span class="refAuthor">, Massey, D.</span><span class="refAuthor">, and S. Rose</span>, <span class="refTitle">"DNS Security Introduction and Requirements"</span>, <span class="seriesInfo">RFC 4033</span>, <span class="seriesInfo">DOI 10.17487/RFC4033</span>, <time datetime="2005-03">March 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4033">https://www.rfc-editor.org/info/rfc4033</a>&gt;</span>. </dd>
<dt id="RFC4034">[RFC4034]</dt>
        <dd>
<span class="refAuthor">Arends, R.</span><span class="refAuthor">, Austein, R.</span><span class="refAuthor">, Larson, M.</span><span class="refAuthor">, Massey, D.</span><span class="refAuthor">, and S. Rose</span>, <span class="refTitle">"Resource Records for the DNS Security Extensions"</span>, <span class="seriesInfo">RFC 4034</span>, <span class="seriesInfo">DOI 10.17487/RFC4034</span>, <time datetime="2005-03">March 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4034">https://www.rfc-editor.org/info/rfc4034</a>&gt;</span>. </dd>
<dt id="RFC4035">[RFC4035]</dt>
        <dd>
<span class="refAuthor">Arends, R.</span><span class="refAuthor">, Austein, R.</span><span class="refAuthor">, Larson, M.</span><span class="refAuthor">, Massey, D.</span><span class="refAuthor">, and S. Rose</span>, <span class="refTitle">"Protocol Modifications for the DNS Security Extensions"</span>, <span class="seriesInfo">RFC 4035</span>, <span class="seriesInfo">DOI 10.17487/RFC4035</span>, <time datetime="2005-03">March 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4035">https://www.rfc-editor.org/info/rfc4035</a>&gt;</span>. </dd>
<dt id="RFC5234">[RFC5234]</dt>
        <dd>
<span class="refAuthor">Crocker, D., Ed.</span><span class="refAuthor"> and P. Overell</span>, <span class="refTitle">"Augmented BNF for Syntax Specifications: ABNF"</span>, <span class="seriesInfo">STD 68</span>, <span class="seriesInfo">RFC 5234</span>, <span class="seriesInfo">DOI 10.17487/RFC5234</span>, <time datetime="2008-01">January 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5234">https://www.rfc-editor.org/info/rfc5234</a>&gt;</span>. </dd>
<dt id="RFC5248">[RFC5248]</dt>
        <dd>
<span class="refAuthor">Hansen, T.</span><span class="refAuthor"> and J. Klensin</span>, <span class="refTitle">"A Registry for SMTP Enhanced Mail System Status Codes"</span>, <span class="seriesInfo">BCP 138</span>, <span class="seriesInfo">RFC 5248</span>, <span class="seriesInfo">DOI 10.17487/RFC5248</span>, <time datetime="2008-06">June 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5248">https://www.rfc-editor.org/info/rfc5248</a>&gt;</span>. </dd>
<dt id="RFC5321">[RFC5321]</dt>
        <dd>
<span class="refAuthor">Klensin, J.</span>, <span class="refTitle">"Simple Mail Transfer Protocol"</span>, <span class="seriesInfo">RFC 5321</span>, <span class="seriesInfo">DOI 10.17487/RFC5321</span>, <time datetime="2008-10">October 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5321">https://www.rfc-editor.org/info/rfc5321</a>&gt;</span>. </dd>
<dt id="RFC5322">[RFC5322]</dt>
        <dd>
<span class="refAuthor">Resnick, P., Ed.</span>, <span class="refTitle">"Internet Message Format"</span>, <span class="seriesInfo">RFC 5322</span>, <span class="seriesInfo">DOI 10.17487/RFC5322</span>, <time datetime="2008-10">October 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5322">https://www.rfc-editor.org/info/rfc5322</a>&gt;</span>. </dd>
<dt id="RFC6125">[RFC6125]</dt>
        <dd>
<span class="refAuthor">Saint-Andre, P.</span><span class="refAuthor"> and J. Hodges</span>, <span class="refTitle">"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)"</span>, <span class="seriesInfo">RFC 6125</span>, <span class="seriesInfo">DOI 10.17487/RFC6125</span>, <time datetime="2011-03">March 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6125">https://www.rfc-editor.org/info/rfc6125</a>&gt;</span>. </dd>
<dt id="RFC7525">[RFC7525]</dt>
        <dd>
<span class="refAuthor">Sheffer, Y.</span><span class="refAuthor">, Holz, R.</span><span class="refAuthor">, and P. Saint-Andre</span>, <span class="refTitle">"Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)"</span>, <span class="seriesInfo">BCP 195</span>, <span class="seriesInfo">RFC 7525</span>, <span class="seriesInfo">DOI 10.17487/RFC7525</span>, <time datetime="2015-05">May 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7525">https://www.rfc-editor.org/info/rfc7525</a>&gt;</span>. </dd>
<dt id="RFC7672">[RFC7672]</dt>
        <dd>
<span class="refAuthor">Dukhovni, V.</span><span class="refAuthor"> and W. Hardaker</span>, <span class="refTitle">"SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)"</span>, <span class="seriesInfo">RFC 7672</span>, <span class="seriesInfo">DOI 10.17487/RFC7672</span>, <time datetime="2015-10">October 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7672">https://www.rfc-editor.org/info/rfc7672</a>&gt;</span>. </dd>
<dt id="RFC8174">[RFC8174]</dt>
        <dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
<dt id="RFC8314">[RFC8314]</dt>
        <dd>
<span class="refAuthor">Moore, K.</span><span class="refAuthor"> and C. Newman</span>, <span class="refTitle">"Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access"</span>, <span class="seriesInfo">RFC 8314</span>, <span class="seriesInfo">DOI 10.17487/RFC8314</span>, <time datetime="2018-01">January 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8314">https://www.rfc-editor.org/info/rfc8314</a>&gt;</span>. </dd>
<dt id="RFC8461">[RFC8461]</dt>
        <dd>
<span class="refAuthor">Margolis, D.</span><span class="refAuthor">, Risher, M.</span><span class="refAuthor">, Ramakrishnan, B.</span><span class="refAuthor">, Brotman, A.</span><span class="refAuthor">, and J. Jones</span>, <span class="refTitle">"SMTP MTA Strict Transport Security (MTA-STS)"</span>, <span class="seriesInfo">RFC 8461</span>, <span class="seriesInfo">DOI 10.17487/RFC8461</span>, <time datetime="2018-09">September 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8461">https://www.rfc-editor.org/info/rfc8461</a>&gt;</span>. </dd>
<dt id="SMTPStatusCodes">[SMTPStatusCodes]</dt>
      <dd>
<span class="refAuthor">IANA</span>, <span class="refTitle">"Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes Registry"</span>, <span>&lt;<a href="https://www.iana.org/assignments/smtp-enhanced-status-codes">https://www.iana.org/assignments/smtp-enhanced-status-codes</a>&gt;</span>. </dd>
</dl>
</section>
<section id="section-9.2">
        <h3 id="name-informative-references">
<a href="#section-9.2" class="section-number selfRef">9.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="RFC1939">[RFC1939]</dt>
        <dd>
<span class="refAuthor">Myers, J.</span><span class="refAuthor"> and M. Rose</span>, <span class="refTitle">"Post Office Protocol - Version 3"</span>, <span class="seriesInfo">STD 53</span>, <span class="seriesInfo">RFC 1939</span>, <span class="seriesInfo">DOI 10.17487/RFC1939</span>, <time datetime="1996-05">May 1996</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1939">https://www.rfc-editor.org/info/rfc1939</a>&gt;</span>. </dd>
<dt id="RFC2033">[RFC2033]</dt>
        <dd>
<span class="refAuthor">Myers, J.</span>, <span class="refTitle">"Local Mail Transfer Protocol"</span>, <span class="seriesInfo">RFC 2033</span>, <span class="seriesInfo">DOI 10.17487/RFC2033</span>, <time datetime="1996-10">October 1996</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2033">https://www.rfc-editor.org/info/rfc2033</a>&gt;</span>. </dd>
<dt id="RFC3501">[RFC3501]</dt>
        <dd>
<span class="refAuthor">Crispin, M.</span>, <span class="refTitle">"INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1"</span>, <span class="seriesInfo">RFC 3501</span>, <span class="seriesInfo">DOI 10.17487/RFC3501</span>, <time datetime="2003-03">March 2003</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3501">https://www.rfc-editor.org/info/rfc3501</a>&gt;</span>. </dd>
<dt id="RFC4880">[RFC4880]</dt>
        <dd>
<span class="refAuthor">Callas, J.</span><span class="refAuthor">, Donnerhacke, L.</span><span class="refAuthor">, Finney, H.</span><span class="refAuthor">, Shaw, D.</span><span class="refAuthor">, and R. Thayer</span>, <span class="refTitle">"OpenPGP Message Format"</span>, <span class="seriesInfo">RFC 4880</span>, <span class="seriesInfo">DOI 10.17487/RFC4880</span>, <time datetime="2007-11">November 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4880">https://www.rfc-editor.org/info/rfc4880</a>&gt;</span>. </dd>
<dt id="RFC5228">[RFC5228]</dt>
        <dd>
<span class="refAuthor">Guenther, P., Ed.</span><span class="refAuthor"> and T. Showalter, Ed.</span>, <span class="refTitle">"Sieve: An Email Filtering Language"</span>, <span class="seriesInfo">RFC 5228</span>, <span class="seriesInfo">DOI 10.17487/RFC5228</span>, <time datetime="2008-01">January 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5228">https://www.rfc-editor.org/info/rfc5228</a>&gt;</span>. </dd>
<dt id="RFC5598">[RFC5598]</dt>
        <dd>
<span class="refAuthor">Crocker, D.</span>, <span class="refTitle">"Internet Mail Architecture"</span>, <span class="seriesInfo">RFC 5598</span>, <span class="seriesInfo">DOI 10.17487/RFC5598</span>, <time datetime="2009-07">July 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5598">https://www.rfc-editor.org/info/rfc5598</a>&gt;</span>. </dd>
<dt id="RFC6409">[RFC6409]</dt>
        <dd>
<span class="refAuthor">Gellens, R.</span><span class="refAuthor"> and J. Klensin</span>, <span class="refTitle">"Message Submission for Mail"</span>, <span class="seriesInfo">STD 72</span>, <span class="seriesInfo">RFC 6409</span>, <span class="seriesInfo">DOI 10.17487/RFC6409</span>, <time datetime="2011-11">November 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6409">https://www.rfc-editor.org/info/rfc6409</a>&gt;</span>. </dd>
<dt id="RFC8551">[RFC8551]</dt>
      <dd>
<span class="refAuthor">Schaad, J.</span><span class="refAuthor">, Ramsdell, B.</span><span class="refAuthor">, and S. Turner</span>, <span class="refTitle">"Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification"</span>, <span class="seriesInfo">RFC 8551</span>, <span class="seriesInfo">DOI 10.17487/RFC8551</span>, <time datetime="2019-04">April 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8551">https://www.rfc-editor.org/info/rfc8551</a>&gt;</span>. </dd>
</dl>
</section>
</section>
<section id="section-appendix.a">
      <h2 id="name-examples">
<a href="#section-appendix.a" class="section-number selfRef">Appendix A. </a><a href="#name-examples" class="section-name selfRef">Examples</a>
      </h2>
<p id="section-appendix.a-1">This section is informative.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
<section id="section-a.1">
        <h2 id="name-requiretls-smtp-option">
<a href="#section-a.1" class="section-number selfRef">A.1. </a><a href="#name-requiretls-smtp-option" class="section-name selfRef">REQUIRETLS SMTP Option</a>
        </h2>
<p id="section-a.1-1">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.<a href="#section-a.1-1" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-a.1-2">
<pre>
 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
</pre><a href="#section-a.1-2" class="pilcrow">¶</a>
</div>
<p id="section-a.1-3">(at this point TLS negotiation takes place. The remainder of this
 session occurs within TLS.)<a href="#section-a.1-3" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-a.1-4">
<pre>
 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&gt; REQUIRETLS
 S: 250 OK
 C: RCPT TO:&lt;editor@example.net&gt;
 S: 250 Accepted
 C: DATA
 S: 354 Enter message, ending with "." on a line by itself
</pre><a href="#section-a.1-4" class="pilcrow">¶</a>
</div>
<p id="section-a.1-5">(message follows)<a href="#section-a.1-5" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-a.1-6">
<pre>
 C: .
 S: 250 OK
 C: QUIT
</pre><a href="#section-a.1-6" class="pilcrow">¶</a>
</div>
</section>
<section id="section-a.2">
        <h2 id="name-tls-required-header-field">
<a href="#section-a.2" class="section-number selfRef">A.2. </a><a href="#name-tls-required-header-field" class="section-name selfRef">TLS-Required Header Field</a>
        </h2>
<p id="section-a.2-1">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:<a href="#section-a.2-1" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-a.2-2">
<pre>
 From: Roger Reporter &lt;roger@example.org&gt;
 To: Andy Admin &lt;admin@example.com&gt;
 Subject: Certificate problem?
 TLS-Required: No
 Date: Fri, 18 Jan 2019 10:26:55 -0800
 Message-ID: &lt;5c421a6f79c0e_d153ff8286d45c468473@mail.example.org&gt;

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

 Roger         </pre><a href="#section-a.2-2" class="pilcrow">¶</a>
</div>
</section>
</section>
<div id="acknowledgements">
<section id="section-appendix.b">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="section-appendix.b-1">
   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.<a href="#section-appendix.b-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="section-appendix.c">
      <h2 id="name-authors-address">
<a href="#name-authors-address" class="section-name selfRef">Author's Address</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Jim Fenton</span></div>
<div dir="auto" class="left"><span class="org">Altmode Networks</span></div>
<div dir="auto" class="left">
<span class="locality">Los Altos</span>, <span class="region">California</span> <span class="postal-code">94024</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:fenton@bluepopcorn.net" class="email">fenton@bluepopcorn.net</a>
</div>
</address>
</section>
</div>
<script>var toc = document.getElementById("toc");
var tocToggle = toc.querySelector("h2");
var tocNav = toc.querySelector("nav");

// mobile menu toggle
tocToggle.onclick = function(event) {
    if (window.innerWidth < 1024) {
 var tocNavDisplay = tocNav.currentStyle ? tocNav.currentStyle.display : getComputedStyle(tocNav, null).display;
 if (tocNavDisplay == "none") {
     tocNav.style.display = "block";
 } else {
     tocNav.style.display = "none";
 }
    }
}

// toc anchor scroll to anchor
tocNav.addEventListener("click", function (event) {
    event.preventDefault();
    if (event.target.nodeName == 'A') {
 if (window.innerWidth < 1024) {
     tocNav.style.display = "none";
 }
 var href = event.target.getAttribute("href");
 var anchorId = href.substr(1);
 var anchor =  document.getElementById(anchorId);
 anchor.scrollIntoView(true);
 window.history.pushState("","",href);
    }
});

// switch toc mode when window resized
window.onresize = function () {
    if (window.innerWidth < 1024) {
 tocNav.style.display = "none";
    } else {
 tocNav.style.display = "block";
    }
}
</script>
</body>
</html>