Commit: 593bcf8c3fa3ee7c99b247d7707c14843349b8a7

Commit

Author:

Hash:

Timestamp:

+762 -0 +/-2 browse

Kevin Schoon [me@kevinschoon.com]

593bcf8c3fa3ee7c99b247d7707c14843349b8a7

Sun, 22 Sep 2024 21:48:42 +0000 (1.1 years ago)

add placeholder for REQUIRETLS

1	diff --git a/README.md b/README.md
2	index 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
14	new file mode 100644
15	index 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