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