Commit
Author: Kevin Schoon [me@kevinschoon.com]
Hash: 593bcf8c3fa3ee7c99b247d7707c14843349b8a7
Timestamp: Sun, 22 Sep 2024 21:48:42 +0000 (3 months ago)

+762 -0 +/-2 browse
add placeholder for REQUIRETLS
1diff --git a/README.md b/README.md
2index 991838a..2c3a4a0 100644
3--- a/README.md
4+++ b/README.md
5 @@ -66,6 +66,7 @@ for _absolutely nothing_ that is important.
6 | ETRN | ❌ | [RFC1985](rfcs/rfc1985.txt) |
7 | ATRN | ❌ | RFC2645 |
8 | BURL | ❌ | RFC4468 |
9+ | REQUIRETLS | TODO | [RFC8689](rfcs/rfc8689.txt) |
10
11 ### Authentication Extensions
12
13 diff --git a/rfcs/rfc8689.txt b/rfcs/rfc8689.txt
14new file mode 100644
15index 0000000..eab6ff7
16--- /dev/null
17+++ b/rfcs/rfc8689.txt
18 @@ -0,0 +1,761 @@
19+ 
20+
21+
22+
23+ Internet Engineering Task Force (IETF) J. Fenton
24+ Request for Comments: 8689 Altmode Networks
25+ Category: Standards Track November 2019
26+ ISSN: 2070-1721
27+
28+
29+ SMTP Require TLS Option
30+
31+ Abstract
32+
33+ The SMTP STARTTLS option, used in negotiating transport-level
34+ encryption of SMTP connections, is not as useful from a security
35+ standpoint as it might be because of its opportunistic nature;
36+ message delivery is, by default, prioritized over security. This
37+ document describes an SMTP service extension, REQUIRETLS, and a
38+ message header field, TLS-Required. If the REQUIRETLS option or TLS-
39+ Required message header field is used when sending a message, it
40+ asserts a request on the part of the message sender to override the
41+ default negotiation of TLS, either by requiring that TLS be
42+ negotiated when the message is relayed or by requesting that
43+ recipient-side policy mechanisms such as MTA-STS and DNS-Based
44+ Authentication of Named Entities (DANE) be ignored when relaying a
45+ message for which security is unimportant.
46+
47+ Status of This Memo
48+
49+ This is an Internet Standards Track document.
50+
51+ This document is a product of the Internet Engineering Task Force
52+ (IETF). It represents the consensus of the IETF community. It has
53+ received public review and has been approved for publication by the
54+ Internet Engineering Steering Group (IESG). Further information on
55+ Internet Standards is available in Section 2 of RFC 7841.
56+
57+ Information about the current status of this document, any errata,
58+ and how to provide feedback on it may be obtained at
59+ https://www.rfc-editor.org/info/rfc8689.
60+
61+ Copyright Notice
62+
63+ Copyright (c) 2019 IETF Trust and the persons identified as the
64+ document authors. All rights reserved.
65+
66+ This document is subject to BCP 78 and the IETF Trust's Legal
67+ Provisions Relating to IETF Documents
68+ (https://trustee.ietf.org/license-info) in effect on the date of
69+ publication of this document. Please review these documents
70+ carefully, as they describe your rights and restrictions with respect
71+ to this document. Code Components extracted from this document must
72+ include Simplified BSD License text as described in Section 4.e of
73+ the Trust Legal Provisions and are provided without warranty as
74+ described in the Simplified BSD License.
75+
76+ Table of Contents
77+
78+ 1. Introduction
79+ 1.1. Requirements Language
80+ 2. The REQUIRETLS Service Extension
81+ 3. The TLS-Required Header Field
82+ 4. REQUIRETLS Semantics
83+ 4.1. REQUIRETLS Receipt Requirements
84+ 4.2. REQUIRETLS Sender Requirements
85+ 4.2.1. Sending with TLS Required
86+ 4.2.2. Sending with TLS Optional
87+ 4.3. REQUIRETLS Submission
88+ 4.4. Delivery of REQUIRETLS messages
89+ 5. Non-delivery Message Handling
90+ 6. Reorigination Considerations
91+ 7. IANA Considerations
92+ 8. Security Considerations
93+ 8.1. Passive Attacks
94+ 8.2. Active Attacks
95+ 8.3. Bad-Actor MTAs
96+ 8.4. Policy Conflicts
97+ 9. References
98+ 9.1. Normative References
99+ 9.2. Informative References
100+ Appendix A. Examples
101+ A.1. REQUIRETLS SMTP Option
102+ A.2. TLS-Required Header Field
103+ Acknowledgements
104+ Author's Address
105+
106+ 1. Introduction
107+
108+ The SMTP [RFC5321] STARTTLS service extension [RFC3207] provides a
109+ means by which an SMTP server and client can establish a Transport
110+ Layer Security (TLS) protected session for the transmission of email
111+ messages. By default, TLS is used only upon mutual agreement
112+ (successful negotiation) of STARTTLS between the client and server;
113+ if this is not possible, the message is sent without transport
114+ encryption. Furthermore, it is common practice for the client to
115+ negotiate TLS even if the SMTP server's certificate is invalid.
116+
117+ Policy mechanisms such as DANE [RFC7672] and MTA-STS [RFC8461] may
118+ impose requirements for the use of TLS for email destined for some
119+ domains. However, such policies do not allow the sender to specify
120+ which messages are more sensitive and require transport-level
121+ encryption and which ones are less sensitive and ought to be relayed
122+ even if TLS cannot be negotiated successfully.
123+
124+ The default opportunistic nature of SMTP TLS enables several on-the-
125+ wire attacks on SMTP security between MTAs. These include passive
126+ eavesdropping on connections for which TLS is not used, interference
127+ in the SMTP protocol to prevent TLS from being negotiated (presumably
128+ accompanied by eavesdropping), and insertion of a man-in-the-middle
129+ attacker exploiting the lack of server authentication by the client.
130+ Attacks are described in more detail in the Security Considerations
131+ section of this document.
132+
133+ REQUIRETLS consists of two mechanisms: an SMTP service extension and
134+ a message header field. The service extension is used to specify
135+ that a given message sent during a particular session MUST be sent
136+ over a TLS-protected session with specified security characteristics.
137+ It also requires that the SMTP server advertise that it supports
138+ REQUIRETLS, in effect promising that it will honor the requirement to
139+ enforce TLS transmission and REQUIRETLS support for onward
140+ transmission of those messages.
141+
142+ The TLS-Required message header field is used to convey a request to
143+ ignore recipient-side policy mechanisms such as MTA-STS and DANE,
144+ thereby prioritizing delivery over ability to negotiate TLS. Unlike
145+ the service extension, the TLS-Required header field allows the
146+ message to transit through one or more MTAs that do not support
147+ REQUIRETLS.
148+
149+ 1.1. Requirements Language
150+
151+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
152+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
153+ "OPTIONAL" in this document are to be interpreted as described in
154+ BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
155+ capitals, as shown here.
156+
157+ The formal syntax uses the Augmented Backus-Naur Form (ABNF)
158+ [RFC5234], including the core rules defined in Appendix B of that
159+ document.
160+
161+ 2. The REQUIRETLS Service Extension
162+
163+ The REQUIRETLS SMTP service extension has the following
164+ characteristics:
165+
166+ 1. The textual name of the extension is "Require TLS".
167+
168+ 2. The EHLO keyword value associated with this extension is
169+ "REQUIRETLS".
170+
171+ 3. No additional SMTP verbs are defined by this extension.
172+
173+ 4. One optional parameter ("REQUIRETLS") is added to the MAIL FROM
174+ command by this extension. No value is associated with this
175+ parameter.
176+
177+ 5. The maximum length of a MAIL FROM command line is increased by 11
178+ octets by the possible addition of a space and the REQUIRETLS
179+ keyword.
180+
181+ 6. One new SMTP status code is defined by this extension to convey
182+ an error condition resulting from failure of the client to send
183+ data to a server that does not also support the REQUIRETLS
184+ extension.
185+
186+ 7. The REQUIRETLS extension is valid for message relay [RFC5321],
187+ submission [RFC6409], and the Local Mail Transfer Protocol (LMTP)
188+ [RFC2033].
189+
190+ 8. The ABNF syntax for the MAIL FROM parameter is as follows:
191+
192+ requiretls-param = "REQUIRETLS"
193+ ; where requiretls-param is an instance of an
194+ ; esmtp-param used in Mail-parameters in
195+ ; RFC 5321, Section 4.1.2. There is no esmtp-value
196+ ; associated with requiretls-param.
197+
198+ In order to specify REQUIRETLS treatment for a given message, the
199+ REQUIRETLS option is specified in the MAIL FROM command when that
200+ message is transmitted. This option MUST only be specified in the
201+ context of an SMTP session meeting the security requirements of
202+ REQUIRETLS:
203+
204+ * The session itself MUST employ TLS transmission.
205+
206+ * If the SMTP server to which the message is being transmitted is
207+ identified through an MX record lookup, its name MUST be validated
208+ via a DNSSEC signature on the recipient domain's MX record, or the
209+ MX hostname MUST be validated by an MTA-STS policy as described in
210+ Section 4.1 of [RFC8461]. DNSSEC is defined in [RFC4033],
211+ [RFC4034], and [RFC4035].
212+
213+ * The certificate presented by the SMTP server either MUST be
214+ verified successfully by a trust chain leading to a certificate
215+ trusted by the SMTP client, or it MUST be verified successfully
216+ using DANE, as specified in [RFC7672]. For trust chains, the
217+ choice of trusted (root) certificates is at the discretion of the
218+ SMTP client.
219+
220+ * Following the negotiation of STARTTLS, the SMTP server MUST
221+ advertise in the subsequent EHLO response that it supports
222+ REQUIRETLS.
223+
224+ 3. The TLS-Required Header Field
225+
226+ One new message header field [RFC5322], TLS-Required, is defined by
227+ this specification. It is used for messages for which the originator
228+ requests that the recipient TLS policy (including MTA-STS [RFC8461]
229+ and DANE [RFC7672]) be ignored. This might be done, for example, to
230+ report a misconfigured mail server, such as an expired TLS
231+ certificate.
232+
233+ The TLS-Required header field has a single REQUIRED parameter:
234+
235+ * No - The SMTP client SHOULD attempt to send the message regardless
236+ of its ability to negotiate STARTTLS with the SMTP server,
237+ ignoring policy-based mechanisms (including MTA-STS and DANE), if
238+ any, asserted by the recipient domain. Nevertheless, the client
239+ SHOULD negotiate STARTTLS with the server if available.
240+
241+ More than one instance of the TLS-Required header field MUST NOT
242+ appear in a given message.
243+
244+ The ABNF syntax for the TLS-Required header field is as follows:
245+
246+ requiretls-field = "TLS-Required:" [FWS] "No" CRLF
247+ ; where requiretls-field in an instance of an
248+ ; optional-field defined in RFC 5322, Section 3.6.8.
249+ FWS = <as defined in RFC 5322>
250+ CRLF = <as defined in RFC 5234>
251+
252+ 4. REQUIRETLS Semantics
253+
254+ 4.1. REQUIRETLS Receipt Requirements
255+
256+ Upon receipt of the REQUIRETLS option on a MAIL FROM command during
257+ the receipt of a message, an SMTP server MUST tag that message as
258+ needing REQUIRETLS handling.
259+
260+ Upon receipt of a message not specifying the REQUIRETLS option on its
261+ MAIL FROM command but containing the TLS-Required header field in its
262+ message header, an SMTP server implementing this specification MUST
263+ tag that message with the option specified in the TLS-Required header
264+ field. If the REQUIRETLS MAIL FROM parameter is specified, the TLS-
265+ Required header field MUST be ignored but MAY be included in the
266+ onward relay of the message.
267+
268+ The manner in which the above tagging takes place is implementation
269+ dependent. If the message is being locally aliased and redistributed
270+ to multiple addresses, all instances of the message MUST be tagged in
271+ the same manner.
272+
273+ 4.2. REQUIRETLS Sender Requirements
274+
275+ 4.2.1. Sending with TLS Required
276+
277+ When sending a message tagged as requiring TLS for which the MAIL
278+ FROM return-path is not empty (an empty MAIL FROM return-path
279+ indicating a bounce message), the sending (client) MTA MUST:
280+
281+ 1. Look up the SMTP server to which the message is to be sent, as
282+ described in [RFC5321], Section 5.1.
283+
284+ 2. If the server lookup is accomplished via the recipient domain's
285+ MX record (the usual case) and is not accompanied by a valid
286+ DNSSEC signature, the client MUST also validate the SMTP server
287+ name using MTA-STS, as described in [RFC8461], Section 4.1.
288+
289+ 3. Open an SMTP session with the peer SMTP server using the EHLO
290+ verb.
291+
292+ 4. Establish a TLS-protected SMTP session with its peer SMTP server
293+ and authenticate the server's certificate as specified in
294+ [RFC6125] or [RFC7672], as applicable. The hostname from the MX
295+ record lookup (or the domain name in the absence of an MX record
296+ where an A record is used directly) MUST match the DNS-ID or CN-
297+ ID of the certificate presented by the server.
298+
299+ 5. Ensure that the response to the subsequent EHLO following
300+ establishment of the TLS protection advertises the REQUIRETLS
301+ capability.
302+
303+ The SMTP client SHOULD follow the recommendations in [RFC7525] or its
304+ successor with respect to negotiation of the TLS session.
305+
306+ If any of the above steps fail, the client MUST issue a QUIT to the
307+ server and repeat steps 2-5 with each host on the recipient domain's
308+ list of MX hosts in an attempt to find a mail path that meets the
309+ sender's requirements. The client MAY send other, unprotected
310+ messages to that server if it has any such messages prior to issuing
311+ the QUIT. If there are no more MX hosts, the client MUST NOT
312+ transmit the message to the domain.
313+
314+ Following such a failure, the SMTP client MUST send a non-delivery
315+ notification to the reverse-path of the failed message, as described
316+ in Section 3.6 of [RFC5321]. The following status codes [RFC5248]
317+ SHOULD be used:
318+
319+ * REQUIRETLS not supported by server: 5.7.30 REQUIRETLS support
320+ required
321+
322+ * Unable to establish TLS-protected SMTP session: 5.7.10 Encryption
323+ needed
324+
325+ Refer to Section 5 for further requirements regarding non-delivery
326+ messages.
327+
328+ If all REQUIRETLS requirements have been met, transmit the message,
329+ issuing the REQUIRETLS option on the MAIL FROM command with the
330+ required option(s), if any.
331+
332+ 4.2.2. Sending with TLS Optional
333+
334+ Messages tagged "TLS-Required: No" are handled as follows. When
335+ sending such a message, the sending (client) MTA MUST:
336+
337+ * Look up the SMTP server to which the message is to be sent, as
338+ described in [RFC5321], Section 5.1.
339+
340+ * Open an SMTP session with the peer SMTP server using the EHLO
341+ verb. Attempt to negotiate STARTTLS if possible, and follow any
342+ policy published by the recipient domain, but do not fail if this
343+ is unsuccessful.
344+
345+ Some SMTP servers may be configured to require STARTTLS connections
346+ as a matter of policy and not accept messages in the absence of
347+ STARTTLS. A non-delivery notification MUST be returned to the sender
348+ if message relay fails due to an inability to negotiate STARTTLS when
349+ required by the server.
350+
351+ Since messages tagged with "TLS-Required: No" will sometimes be sent
352+ to SMTP servers not supporting REQUIRETLS, that option will not be
353+ uniformly observed by all SMTP relay hops.
354+
355+ 4.3. REQUIRETLS Submission
356+
357+ A Mail User Agent (MUA) or other agent making the initial
358+ introduction of a message has the option to decide whether to require
359+ TLS. If TLS is to be required, it MUST do so by negotiating STARTTLS
360+ and REQUIRETLS and including the REQUIRETLS option on the MAIL FROM
361+ command, as is done for message relay.
362+
363+ When TLS is not to be required, the sender MUST include the TLS-
364+ Required header field in the message. SMTP servers implementing this
365+ specification MUST interpret this header field as described in
366+ Section 4.1.
367+
368+ In either case, the decision whether to specify REQUIRETLS MAY be
369+ done based on a user interface selection or based on a ruleset or
370+ other policy. The manner in which the decision to require TLS is
371+ made is implementation dependent and is beyond the scope of this
372+ specification.
373+
374+ 4.4. Delivery of REQUIRETLS messages
375+
376+ Messages are usually retrieved by end users using protocols other
377+ than SMTP such as IMAP [RFC3501], POP [RFC1939], or Web mail systems.
378+ Mail delivery agents supporting the REQUIRETLS SMTP option SHOULD
379+ observe the guidelines in [RFC8314].
380+
381+ 5. Non-delivery Message Handling
382+
383+ Non-delivery ("bounce") messages usually contain important metadata
384+ about the message to which they refer, including the original message
385+ header. They therefore MUST be protected in the same manner as the
386+ original message. All non-delivery messages resulting from messages
387+ with the REQUIRETLS SMTP option, whether resulting from a REQUIRETLS
388+ error or some other issue, MUST also specify the REQUIRETLS SMTP
389+ option unless redacted as described below.
390+
391+ The path from the origination of an error bounce message back to the
392+ MAIL FROM address may not share the same REQUIRETLS support as the
393+ forward path. Therefore, users requiring TLS are advised to make
394+ sure that they are capable of receiving mail using REQUIRETLS as
395+ well. Otherwise, such non-delivery messages will be lost.
396+
397+ If a REQUIRETLS message is bounced, the server MUST behave as if
398+ RET=HDRS was present, as described in [RFC3461]. If both RET=FULL
399+ and REQUIRETLS are present, the RET=FULL MUST be disregarded. The
400+ SMTP client for a REQUIRETLS bounce message uses an empty MAIL FROM
401+ return-path, as required by [RFC5321]. When the MAIL FROM return-
402+ path is empty, the REQUIRETLS parameter SHOULD NOT cause a bounce
403+ message to be discarded even if the next-hop relay does not advertise
404+ REQUIRETLS.
405+
406+ Senders of messages requiring TLS are advised to consider the
407+ possibility that bounce messages will be lost as a result of
408+ REQUIRETLS return path failure and that some information could be
409+ leaked if a bounce message is not able to be transmitted with
410+ REQUIRETLS.
411+
412+ 6. Reorigination Considerations
413+
414+ In a number of situations, a mediator [RFC5598] originates a new
415+ message as a result of an incoming message. These situations include
416+ but are not limited to mailing lists (including administrative
417+ traffic such as message approval requests), Sieve [RFC5228],
418+ "vacation" responders, and other filters to which incoming messages
419+ may be piped. These newly originated messages may essentially be
420+ copies of the incoming message, such as with a forwarding service or
421+ a mailing list expander. In other cases, such as with a vacation
422+ message or a delivery notification, they will be different but might
423+ contain parts of the original message or other information for which
424+ the original message sender wants to influence the requirement to use
425+ TLS transmission.
426+
427+ Mediators that reoriginate messages should apply REQUIRETLS
428+ requirements in incoming messages (both requiring TLS transmission
429+ and requesting that TLS not be required) to the reoriginated messages
430+ to the extent feasible. A limitation to this might be that for a
431+ message requiring TLS, redistribution to multiple addresses while
432+ retaining the TLS requirement could result in the message not being
433+ delivered to some of the intended recipients.
434+
435+ User-side mediators (such as use of Sieve rules on a user agent)
436+ typically do not have access to the SMTP details and therefore may
437+ not be aware of the REQUIRETLS requirement on a delivered message.
438+ Recipients that expect sensitive traffic should avoid the use of
439+ user-side mediators. Alternatively, if operationally feasible (such
440+ as when forwarding to a specific, known address), they should apply
441+ REQUIRETLS to all reoriginated messages that do not contain the "TLS-
442+ Required: No" header field.
443+
444+ 7. IANA Considerations
445+
446+ Per this document, IANA has added the following keyword to the "SMTP
447+ Service Extensions" subregistry of the "Mail Parameters" registry
448+ [MailParams]:
449+
450+ EHLO Keyword: REQUIRETLS
451+ Description: Require TLS
452+ Syntax and parameters: (no parameters)
453+ Additional SMTP verbs: none
454+ MAIL and RCPT parameters: REQUIRETLS parameter on MAIL
455+ Behavior: Use of the REQUIRETLS parameter on
456+ the MAIL verb causes that message to
457+ require the use of TLS and tagging
458+ with REQUIRETLS for all onward
459+ relay.
460+ Command length increment: 11 characters
461+
462+ Per this document, IANA has added an entry to the "Enumerated Status
463+ Codes" subregistry of the "Simple Mail Transfer Protocol (SMTP)
464+ Enhanced Status Codes Registry" [SMTPStatusCodes]:
465+
466+ Code: X.7.30
467+ Sample Text: REQUIRETLS support required
468+ Associated basic status code: 550
469+ Description: This indicates that the message was
470+ not able to be forwarded because it
471+ was received with a REQUIRETLS
472+ requirement and none of the SMTP
473+ servers to which the message should
474+ be forwarded provide this support.
475+ Reference: RFC 8689
476+ Submitter: J. Fenton
477+ Change Controller: IESG
478+
479+ Per this document, IANA has added an entry to the "Permanent Message
480+ Header Field Names" subregistry of the "Message Headers" registry
481+ [MessageHeaders] as follows:
482+
483+ Header field name: TLS-Required
484+ Applicable protocol: mail
485+ Status: standard
486+ Author/change controller: IETF
487+ Specification document: RFC 8689
488+
489+ 8. Security Considerations
490+
491+ The purpose of REQUIRETLS is to give the originator of a message
492+ control over the security of email they send, either by conveying an
493+ expectation that it will be transmitted in an encrypted form over the
494+ wire or explicitly indicating that transport encryption is not
495+ required if it cannot be successfully negotiated.
496+
497+ The following considerations apply to the REQUIRETLS service
498+ extension but not the TLS-Required header field, since messages
499+ specifying the header field are less concerned with transport
500+ security.
501+
502+ 8.1. Passive Attacks
503+
504+ REQUIRETLS is generally effective against passive attackers who are
505+ merely trying to eavesdrop on an SMTP exchange between an SMTP client
506+ and server. This assumes, of course, the cryptographic integrity of
507+ the TLS connection being used.
508+
509+ 8.2. Active Attacks
510+
511+ Active attacks against TLS-encrypted SMTP connections can take many
512+ forms. One such attack is to interfere in the negotiation by
513+ changing the STARTTLS command to something illegal such as XXXXXXXX.
514+ This causes TLS negotiation to fail and messages to be sent in the
515+ clear, where they can be intercepted. REQUIRETLS detects the failure
516+ of STARTTLS and declines to send the message rather than send it
517+ insecurely.
518+
519+ A second form of attack is a man-in-the-middle attack where the
520+ attacker terminates the TLS connection rather than the intended SMTP
521+ server. This is possible when, as is commonly the case, the SMTP
522+ client either does not verify the server's certificate or establishes
523+ the connection even when the verification fails. REQUIRETLS requires
524+ successful certificate validation before sending the message.
525+
526+ Another active attack involves the spoofing of DNS MX records of the
527+ recipient domain. An attacker with this capability could potentially
528+ cause the message to be redirected to a mail server under the
529+ attacker's own control, which would presumably have a valid
530+ certificate. REQUIRETLS requires that the recipient domain's MX
531+ record lookup be validated either using DNSSEC or via a published
532+ MTA-STS policy that specifies the acceptable SMTP server hostname(s)
533+ for the recipient domain.
534+
535+ 8.3. Bad-Actor MTAs
536+
537+ A bad-actor MTA along the message transmission path could
538+ misrepresent its support of REQUIRETLS and/or actively strip
539+ REQUIRETLS tags from messages it handles. However, since
540+ intermediate MTAs are already trusted with the cleartext of messages
541+ they handle, and are not part of the threat model for transport-layer
542+ security, they are also not part of the threat model for REQUIRETLS.
543+
544+ It should be reemphasized that since SMTP TLS is a transport-layer
545+ security protocol, messages sent using REQUIRETLS are not encrypted
546+ end-to-end and are visible to MTAs that are part of the message
547+ delivery path. Messages containing sensitive information that MTAs
548+ should not have access to MUST be sent using end-to-end content
549+ encryption such as OpenPGP [RFC4880] or S/MIME [RFC8551].
550+
551+ 8.4. Policy Conflicts
552+
553+ In some cases, the use of the TLS-Required header field may conflict
554+ with a recipient domain policy expressed through the DANE [RFC7672]
555+ or MTA-STS [RFC8461] protocols. Although these protocols encourage
556+ the use of TLS transport by advertising the availability of TLS, the
557+ use of the "TLS-Required: No" header field represents an explicit
558+ decision on the part of the sender not to require the use of TLS,
559+ such as to overcome a configuration error. The recipient domain has
560+ the ultimate ability to require TLS by not accepting messages when
561+ STARTTLS has not been negotiated; otherwise, "TLS-Required: No" is
562+ effectively directing the client MTA to behave as if it does not
563+ support DANE or MTA-STS.
564+
565+ 9. References
566+
567+ 9.1. Normative References
568+
569+ [MailParams]
570+ IANA, "Mail Parameters",
571+ <http://www.iana.org/assignments/mail-parameters>.
572+
573+ [MessageHeaders]
574+ IANA, "Permanent Message Header Field Names",
575+ <https://www.iana.org/assignments/message-headers>.
576+
577+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
578+ Requirement Levels", BCP 14, RFC 2119,
579+ DOI 10.17487/RFC2119, March 1997,
580+ <https://www.rfc-editor.org/info/rfc2119>.
581+
582+ [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
583+ Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207,
584+ February 2002, <https://www.rfc-editor.org/info/rfc3207>.
585+
586+ [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
587+ Extension for Delivery Status Notifications (DSNs)",
588+ RFC 3461, DOI 10.17487/RFC3461, January 2003,
589+ <https://www.rfc-editor.org/info/rfc3461>.
590+
591+ [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
592+ Rose, "DNS Security Introduction and Requirements",
593+ RFC 4033, DOI 10.17487/RFC4033, March 2005,
594+ <https://www.rfc-editor.org/info/rfc4033>.
595+
596+ [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
597+ Rose, "Resource Records for the DNS Security Extensions",
598+ RFC 4034, DOI 10.17487/RFC4034, March 2005,
599+ <https://www.rfc-editor.org/info/rfc4034>.
600+
601+ [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
602+ Rose, "Protocol Modifications for the DNS Security
603+ Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
604+ <https://www.rfc-editor.org/info/rfc4035>.
605+
606+ [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
607+ Specifications: ABNF", STD 68, RFC 5234,
608+ DOI 10.17487/RFC5234, January 2008,
609+ <https://www.rfc-editor.org/info/rfc5234>.
610+
611+ [RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced
612+ Mail System Status Codes", BCP 138, RFC 5248,
613+ DOI 10.17487/RFC5248, June 2008,
614+ <https://www.rfc-editor.org/info/rfc5248>.
615+
616+ [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
617+ DOI 10.17487/RFC5321, October 2008,
618+ <https://www.rfc-editor.org/info/rfc5321>.
619+
620+ [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
621+ DOI 10.17487/RFC5322, October 2008,
622+ <https://www.rfc-editor.org/info/rfc5322>.
623+
624+ [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
625+ Verification of Domain-Based Application Service Identity
626+ within Internet Public Key Infrastructure Using X.509
627+ (PKIX) Certificates in the Context of Transport Layer
628+ Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
629+ 2011, <https://www.rfc-editor.org/info/rfc6125>.
630+
631+ [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
632+ "Recommendations for Secure Use of Transport Layer
633+ Security (TLS) and Datagram Transport Layer Security
634+ (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
635+ 2015, <https://www.rfc-editor.org/info/rfc7525>.
636+
637+ [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via
638+ Opportunistic DNS-Based Authentication of Named Entities
639+ (DANE) Transport Layer Security (TLS)", RFC 7672,
640+ DOI 10.17487/RFC7672, October 2015,
641+ <https://www.rfc-editor.org/info/rfc7672>.
642+
643+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
644+ 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
645+ May 2017, <https://www.rfc-editor.org/info/rfc8174>.
646+
647+ [RFC8314] Moore, K. and C. Newman, "Cleartext Considered Obsolete:
648+ Use of Transport Layer Security (TLS) for Email Submission
649+ and Access", RFC 8314, DOI 10.17487/RFC8314, January 2018,
650+ <https://www.rfc-editor.org/info/rfc8314>.
651+
652+ [RFC8461] Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A.,
653+ and J. Jones, "SMTP MTA Strict Transport Security (MTA-
654+ STS)", RFC 8461, DOI 10.17487/RFC8461, September 2018,
655+ <https://www.rfc-editor.org/info/rfc8461>.
656+
657+ [SMTPStatusCodes]
658+ IANA, "Simple Mail Transfer Protocol (SMTP) Enhanced
659+ Status Codes Registry", <https://www.iana.org/assignments/
660+ smtp-enhanced-status-codes>.
661+
662+ 9.2. Informative References
663+
664+ [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
665+ STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996,
666+ <https://www.rfc-editor.org/info/rfc1939>.
667+
668+ [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033,
669+ DOI 10.17487/RFC2033, October 1996,
670+ <https://www.rfc-editor.org/info/rfc2033>.
671+
672+ [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
673+ 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
674+ <https://www.rfc-editor.org/info/rfc3501>.
675+
676+ [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
677+ Thayer, "OpenPGP Message Format", RFC 4880,
678+ DOI 10.17487/RFC4880, November 2007,
679+ <https://www.rfc-editor.org/info/rfc4880>.
680+
681+ [RFC5228] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email
682+ Filtering Language", RFC 5228, DOI 10.17487/RFC5228,
683+ January 2008, <https://www.rfc-editor.org/info/rfc5228>.
684+
685+ [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
686+ DOI 10.17487/RFC5598, July 2009,
687+ <https://www.rfc-editor.org/info/rfc5598>.
688+
689+ [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail",
690+ STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011,
691+ <https://www.rfc-editor.org/info/rfc6409>.
692+
693+ [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
694+ Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
695+ Message Specification", RFC 8551, DOI 10.17487/RFC8551,
696+ April 2019, <https://www.rfc-editor.org/info/rfc8551>.
697+
698+ Appendix A. Examples
699+
700+ This section is informative.
701+
702+ A.1. REQUIRETLS SMTP Option
703+
704+ The TLS-Required SMTP option is used to express the intention of the
705+ sender to have the associated message relayed using TLS. In the
706+ following example, lines beginning with "C:" are transmitted from the
707+ SMTP client to the server, and lines beginning with "S:" are
708+ transmitted in the opposite direction.
709+
710+ S: 220 mail.example.net ESMTP
711+ C: EHLO mail.example.org
712+ S: 250-mail.example.net Hello example.org [192.0.2.1]
713+ S: 250-SIZE 52428800
714+ S: 250-8BITMIME
715+ S: 250-PIPELINING
716+ S: 250-STARTTLS
717+ S: 250 HELP
718+ C: STARTTLS
719+ S: TLS go ahead
720+
721+ (at this point TLS negotiation takes place. The remainder of this
722+ session occurs within TLS.)
723+
724+ S: 220 mail.example.net ESMTP
725+ C: EHLO mail.example.org
726+ S: 250-mail.example.net Hello example.org [192.0.2.1]
727+ S: 250-SIZE 52428800
728+ S: 250-8BITMIME
729+ S: 250-PIPELINING
730+ S: 250-REQUIRETLS
731+ S: 250 HELP
732+ C: MAIL FROM:<roger@example.org> REQUIRETLS
733+ S: 250 OK
734+ C: RCPT TO:<editor@example.net>
735+ S: 250 Accepted
736+ C: DATA
737+ S: 354 Enter message, ending with "." on a line by itself
738+
739+ (message follows)
740+
741+ C: .
742+ S: 250 OK
743+ C: QUIT
744+
745+ A.2. TLS-Required Header Field
746+
747+ The TLS-Required header field is used when the sender requests that
748+ the mail system not heed a default policy of the recipient domain
749+ requiring TLS. It might be used, for example, to allow problems with
750+ the recipient domain's TLS certificate to be reported:
751+
752+ From: Roger Reporter <roger@example.org>
753+ To: Andy Admin <admin@example.com>
754+ Subject: Certificate problem?
755+ TLS-Required: No
756+ Date: Fri, 18 Jan 2019 10:26:55 -0800
757+ Message-ID: <5c421a6f79c0e_d153ff8286d45c468473@mail.example.org>
758+
759+ Andy, there seems to be a problem with the TLS certificate
760+ on your mail server. Are you aware of this?
761+
762+ Roger
763+
764+ Acknowledgements
765+
766+ The author would like to acknowledge many helpful suggestions on the
767+ ietf-smtp and uta mailing lists, in particular those of Viktor
768+ Dukhovni, Tony Finch, Jeremy Harris, Arvel Hathcock, John Klensin,
769+ Barry Leiba, John Levine, Chris Newman, Rolf Sonneveld, and Per
770+ Thorsheim.
771+
772+ Author's Address
773+
774+ Jim Fenton
775+ Altmode Networks
776+ Los Altos, California 94024
777+ United States of America
778+
779+ Email: fenton@bluepopcorn.net