draft-ietf-uta-smtp-require-tls-09.txt | rfc8689.txt | |||
---|---|---|---|---|
Internet Engineering Task Force J. Fenton | Internet Engineering Task Force (IETF) J. Fenton | |||
Internet-Draft Altmode Networks | Request for Comments: 8689 Altmode Networks | |||
Intended status: Standards Track August 2, 2019 | Category: Standards Track November 2019 | |||
Expires: February 3, 2020 | ISSN: 2070-1721 | |||
SMTP Require TLS Option | SMTP Require TLS Option | |||
draft-ietf-uta-smtp-require-tls-09 | ||||
Abstract | Abstract | |||
The SMTP STARTTLS option, used in negotiating transport-level | The SMTP STARTTLS option, used in negotiating transport-level | |||
encryption of SMTP connections, is not as useful from a security | encryption of SMTP connections, is not as useful from a security | |||
standpoint as it might be because of its opportunistic nature; | standpoint as it might be because of its opportunistic nature; | |||
message delivery is, by default, prioritized over security. This | message delivery is, by default, prioritized over security. This | |||
document describes an SMTP service extension, REQUIRETLS, and message | document describes an SMTP service extension, REQUIRETLS, and a | |||
header field, TLS-Required. If the REQUIRETLS option or TLS-Required | message header field, TLS-Required. If the REQUIRETLS option or TLS- | |||
message header field is used when sending a message, it asserts a | Required message header field is used when sending a message, it | |||
request on the part of the message sender to override the default | asserts a request on the part of the message sender to override the | |||
negotiation of TLS, either by requiring that TLS be negotiated when | default negotiation of TLS, either by requiring that TLS be | |||
the message is relayed, or by requesting that recipient-side policy | negotiated when the message is relayed or by requesting that | |||
mechanisms such as MTA-STS and DANE be ignored when relaying a | recipient-side policy mechanisms such as MTA-STS and DNS-Based | |||
Authentication of Named Entities (DANE) be ignored when relaying a | ||||
message for which security is unimportant. | message for which security is unimportant. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This is an Internet Standards Track document. | |||
provisions of BCP 78 and BCP 79. | ||||
Internet-Drafts are working documents of the Internet Engineering | ||||
Task Force (IETF). Note that other groups may also distribute | ||||
working documents as Internet-Drafts. The list of current Internet- | ||||
Drafts is at https://datatracker.ietf.org/drafts/current/. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | This document is a product of the Internet Engineering Task Force | |||
and may be updated, replaced, or obsoleted by other documents at any | (IETF). It represents the consensus of the IETF community. It has | |||
time. It is inappropriate to use Internet-Drafts as reference | received public review and has been approved for publication by the | |||
material or to cite them other than as "work in progress." | Internet Engineering Steering Group (IESG). Further information on | |||
Internet Standards is available in Section 2 of RFC 7841. | ||||
This Internet-Draft will expire on February 3, 2020. | Information about the current status of this document, any errata, | |||
and how to provide feedback on it may be obtained at | ||||
https://www.rfc-editor.org/info/rfc8689. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2019 IETF Trust and the persons identified as the | Copyright (c) 2019 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction | |||
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 | 1.1. Requirements Language | |||
2. The REQUIRETLS Service Extension . . . . . . . . . . . . . . 4 | 2. The REQUIRETLS Service Extension | |||
3. The TLS-Required Header Field . . . . . . . . . . . . . . . . 5 | 3. The TLS-Required Header Field | |||
4. REQUIRETLS Semantics . . . . . . . . . . . . . . . . . . . . 6 | 4. REQUIRETLS Semantics | |||
4.1. REQUIRETLS Receipt Requirements . . . . . . . . . . . . . 6 | 4.1. REQUIRETLS Receipt Requirements | |||
4.2. REQUIRETLS Sender Requirements . . . . . . . . . . . . . 6 | 4.2. REQUIRETLS Sender Requirements | |||
4.2.1. Sending with TLS Required . . . . . . . . . . . . . . 6 | 4.2.1. Sending with TLS Required | |||
4.2.2. Sending with TLS Optional . . . . . . . . . . . . . . 7 | 4.2.2. Sending with TLS Optional | |||
4.3. REQUIRETLS Submission . . . . . . . . . . . . . . . . . . 8 | 4.3. REQUIRETLS Submission | |||
4.4. Delivery of REQUIRETLS messages . . . . . . . . . . . . . 8 | 4.4. Delivery of REQUIRETLS messages | |||
5. Non-delivery message handling . . . . . . . . . . . . . . . . 8 | 5. Non-delivery Message Handling | |||
6. Reorigination considerations . . . . . . . . . . . . . . . . 9 | 6. Reorigination Considerations | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | 7. IANA Considerations | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | 8. Security Considerations | |||
8.1. Passive attacks . . . . . . . . . . . . . . . . . . . . . 11 | 8.1. Passive Attacks | |||
8.2. Active attacks . . . . . . . . . . . . . . . . . . . . . 11 | 8.2. Active Attacks | |||
8.3. Bad Actor MTAs . . . . . . . . . . . . . . . . . . . . . 12 | 8.3. Bad-Actor MTAs | |||
8.4. Policy Conflicts . . . . . . . . . . . . . . . . . . . . 12 | 8.4. Policy Conflicts | |||
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 | 9. References | |||
10. Revision History . . . . . . . . . . . . . . . . . . . . . . 13 | 9.1. Normative References | |||
10.1. Changes since -08 Draft . . . . . . . . . . . . . . . . 13 | 9.2. Informative References | |||
10.2. Changes since -07 Draft . . . . . . . . . . . . . . . . 13 | Appendix A. Examples | |||
10.3. Changes since -06 Draft . . . . . . . . . . . . . . . . 13 | A.1. REQUIRETLS SMTP Option | |||
10.4. Changes since -05 Draft . . . . . . . . . . . . . . . . 14 | A.2. TLS-Required Header Field | |||
10.5. Changes since -04 Draft . . . . . . . . . . . . . . . . 14 | Acknowledgements | |||
10.6. Changes since -03 Draft . . . . . . . . . . . . . . . . 14 | Author's Address | |||
10.7. Changes since -02 Draft . . . . . . . . . . . . . . . . 14 | ||||
10.8. Changes since -01 Draft . . . . . . . . . . . . . . . . 14 | ||||
10.9. Changes since -00 Draft . . . . . . . . . . . . . . . . 15 | ||||
10.10. Changes since fenton-03 Draft . . . . . . . . . . . . . 15 | ||||
10.11. Changes Since -02 Draft . . . . . . . . . . . . . . . . 15 | ||||
10.12. Changes Since -01 Draft . . . . . . . . . . . . . . . . 15 | ||||
10.13. Changes Since -00 Draft . . . . . . . . . . . . . . . . 15 | ||||
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 | ||||
11.1. Normative References . . . . . . . . . . . . . . . . . . 16 | ||||
11.2. Informative References . . . . . . . . . . . . . . . . . 18 | ||||
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 19 | ||||
A.1. REQUIRETLS SMTP Option . . . . . . . . . . . . . . . . . 19 | ||||
A.2. TLS-Required Header Field . . . . . . . . . . . . . . . . 20 | ||||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 | ||||
1. Introduction | 1. Introduction | |||
The SMTP [RFC5321] STARTTLS service extension [RFC3207] provides a | The SMTP [RFC5321] STARTTLS service extension [RFC3207] provides a | |||
means by which an SMTP server and client can establish a Transport | means by which an SMTP server and client can establish a Transport | |||
Layer Security (TLS) protected session for the transmission of email | Layer Security (TLS) protected session for the transmission of email | |||
messages. By default, TLS is used only upon mutual agreement | messages. By default, TLS is used only upon mutual agreement | |||
(successful negotiation) of STARTTLS between the client and server; | (successful negotiation) of STARTTLS between the client and server; | |||
if this is not possible, the message is sent without transport | if this is not possible, the message is sent without transport | |||
encryption. Furthermore, it is common practice for the client to | encryption. Furthermore, it is common practice for the client to | |||
negotiate TLS even if the SMTP server's certificate is invalid. | negotiate TLS even if the SMTP server's certificate is invalid. | |||
Policy mechanisms such as DANE [RFC7672] and MTA-STS [RFC8461] may | Policy mechanisms such as DANE [RFC7672] and MTA-STS [RFC8461] may | |||
impose requirements for the use of TLS for email destined for some | impose requirements for the use of TLS for email destined for some | |||
domains. However, such policies do not allow the sender to specify | domains. However, such policies do not allow the sender to specify | |||
which messages are more sensitive and require transport-level | which messages are more sensitive and require transport-level | |||
encryption, and which ones are less sensitive and ought to be relayed | encryption and which ones are less sensitive and ought to be relayed | |||
even if TLS cannot be negotiated successfully. | even if TLS cannot be negotiated successfully. | |||
The default opportunistic nature of SMTP TLS enables several "on the | The default opportunistic nature of SMTP TLS enables several on-the- | |||
wire" attacks on SMTP security between MTAs. These include passive | wire attacks on SMTP security between MTAs. These include passive | |||
eavesdropping on connections for which TLS is not used, interference | eavesdropping on connections for which TLS is not used, interference | |||
in the SMTP protocol to prevent TLS from being negotiated (presumably | in the SMTP protocol to prevent TLS from being negotiated (presumably | |||
accompanied by eavesdropping), and insertion of a man-in-the-middle | accompanied by eavesdropping), and insertion of a man-in-the-middle | |||
attacker exploiting the lack of server authentication by the client. | attacker exploiting the lack of server authentication by the client. | |||
Attacks are described in more detail in the Security Considerations | Attacks are described in more detail in the Security Considerations | |||
section of this document. | section of this document. | |||
REQUIRETLS consists of two mechanisms: an SMTP service extension and | REQUIRETLS consists of two mechanisms: an SMTP service extension and | |||
a message header field. The service extension is used to specify | a message header field. The service extension is used to specify | |||
that a given message sent during a particular session MUST be sent | that a given message sent during a particular session MUST be sent | |||
skipping to change at page 4, line 9 ¶ | skipping to change at line 131 ¶ | |||
ignore recipient-side policy mechanisms such as MTA-STS and DANE, | ignore recipient-side policy mechanisms such as MTA-STS and DANE, | |||
thereby prioritizing delivery over ability to negotiate TLS. Unlike | thereby prioritizing delivery over ability to negotiate TLS. Unlike | |||
the service extension, the TLS-Required header field allows the | the service extension, the TLS-Required header field allows the | |||
message to transit through one or more MTAs that do not support | message to transit through one or more MTAs that do not support | |||
REQUIRETLS. | REQUIRETLS. | |||
1.1. Requirements Language | 1.1. Requirements Language | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in | |||
14 [RFC2119] [RFC8174] when, and only when, they appear in all | BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | capitals, as shown here. | |||
The formal syntax uses the Augmented Backus-Naur Form (ABNF) | The formal syntax uses the Augmented Backus-Naur Form (ABNF) | |||
[RFC5234] including the core rules defined in Appendix B of that | [RFC5234], including the core rules defined in Appendix B of that | |||
document. | document. | |||
2. The REQUIRETLS Service Extension | 2. The REQUIRETLS Service Extension | |||
The REQUIRETLS SMTP service extension has the following | ||||
characteristics: | ||||
1. The textual name of the extension is "Require TLS". | 1. The textual name of the extension is "Require TLS". | |||
2. The EHLO keyword value associated with this extension is | 2. The EHLO keyword value associated with this extension is | |||
"REQUIRETLS". | "REQUIRETLS". | |||
3. No additional SMTP verbs are defined by this extension. | 3. No additional SMTP verbs are defined by this extension. | |||
4. One optional parameter ("REQUIRETLS") is added to the MAIL FROM | 4. One optional parameter ("REQUIRETLS") is added to the MAIL FROM | |||
command by this extension. No value is associated with this | command by this extension. No value is associated with this | |||
parameter. | parameter. | |||
5. The maximum length of a MAIL FROM command line is increased by 11 | 5. The maximum length of a MAIL FROM command line is increased by 11 | |||
octets by the possible addition of a space and the REQUIRETLS | octets by the possible addition of a space and the REQUIRETLS | |||
keyword. | keyword. | |||
6. One new SMTP status code is defined by this extension to convey | 6. One new SMTP status code is defined by this extension to convey | |||
an error condition resulting from failure of the client to send | an error condition resulting from failure of the client to send | |||
to a server not also supporting the REQUIRETLS extension. | data to a server that does not also support the REQUIRETLS | |||
extension. | ||||
7. The REQUIRETLS extension is valid for message relay [RFC5321], | 7. The REQUIRETLS extension is valid for message relay [RFC5321], | |||
submission [RFC6409], and the Local Mail Transfer Protocol (LMTP) | submission [RFC6409], and the Local Mail Transfer Protocol (LMTP) | |||
[RFC2033] | [RFC2033]. | |||
8. The ABNF syntax for the MAIL FROM parameter is as follows: | 8. The ABNF syntax for the MAIL FROM parameter is as follows: | |||
requiretls-param = "REQUIRETLS" | requiretls-param = "REQUIRETLS" | |||
; where requiretls-param is an instance of an | ; where requiretls-param is an instance of an | |||
; esmtp-param used in Mail-parameters in | ; esmtp-param used in Mail-parameters in | |||
; RFC 5321 Section 4.1.2. There is no esmtp-value | ; RFC 5321, Section 4.1.2. There is no esmtp-value | |||
; associated with requiretls-param. | ; associated with requiretls-param. | |||
In order to specify REQUIRETLS treatment for a given message, the | In order to specify REQUIRETLS treatment for a given message, the | |||
REQUIRETLS option is specified on the MAIL FROM command when that | REQUIRETLS option is specified in the MAIL FROM command when that | |||
message is transmitted. This option MUST only be specified in the | message is transmitted. This option MUST only be specified in the | |||
context of an SMTP session meeting the security requirements of | context of an SMTP session meeting the security requirements of | |||
REQUIRETLS: | REQUIRETLS: | |||
o The session itself MUST employ TLS transmission. | * The session itself MUST employ TLS transmission. | |||
o If the SMTP server to which the message is being transmitted is | * If the SMTP server to which the message is being transmitted is | |||
identified through an MX record lookup, its name MUST be validated | identified through an MX record lookup, its name MUST be validated | |||
via a DNSSEC signature on the recipient domain's MX record, or the | via a DNSSEC signature on the recipient domain's MX record, or the | |||
MX hostname MUST be validated by an MTA-STS policy as described in | MX hostname MUST be validated by an MTA-STS policy as described in | |||
Section 4.1 of RFC 8461 [RFC8461]. DNSSEC is defined in RFC 4033 | Section 4.1 of [RFC8461]. DNSSEC is defined in [RFC4033], | |||
[RFC4033], RFC 4034 [RFC4034], and RFC 4035 [RFC4035]. | [RFC4034], and [RFC4035]. | |||
o The certificate presented by the SMTP server MUST either verify | * The certificate presented by the SMTP server either MUST be | |||
successfully in a trust chain leading to a certificate trusted by | verified successfully by a trust chain leading to a certificate | |||
the SMTP client or it MUST verify successfully using DANE as | trusted by the SMTP client, or it MUST be verified successfully | |||
specified in RFC 7672 [RFC7672]. For trust chains, the choice of | using DANE, as specified in [RFC7672]. For trust chains, the | |||
trusted (root) certificates is at the discretion of the SMTP | choice of trusted (root) certificates is at the discretion of the | |||
client. | SMTP client. | |||
o Following the negotiation of STARTTLS, the SMTP server MUST | * Following the negotiation of STARTTLS, the SMTP server MUST | |||
advertise in the subsequent EHLO response that it supports | advertise in the subsequent EHLO response that it supports | |||
REQUIRETLS. | REQUIRETLS. | |||
3. The TLS-Required Header Field | 3. The TLS-Required Header Field | |||
One new message header field [RFC5322], TLS-Required, is defined by | One new message header field [RFC5322], TLS-Required, is defined by | |||
this specification. It is used for messages for which the originator | this specification. It is used for messages for which the originator | |||
requests that recipient TLS policy (including MTA-STS [RFC8461] and | requests that the recipient TLS policy (including MTA-STS [RFC8461] | |||
DANE [RFC7672]) be ignored. This might be done, for example, to | and DANE [RFC7672]) be ignored. This might be done, for example, to | |||
report a misconfigured mail server, such as an expired TLS | report a misconfigured mail server, such as an expired TLS | |||
certificate. | certificate. | |||
The TLS-Required header field has a single REQUIRED parameter: | The TLS-Required header field has a single REQUIRED parameter: | |||
o No - The SMTP client SHOULD attempt to send the message regardless | * No - The SMTP client SHOULD attempt to send the message regardless | |||
of its ability to negotiate STARTTLS with the SMTP server, | of its ability to negotiate STARTTLS with the SMTP server, | |||
ignoring policy-based mechanisms (including MTA-STS and DANE), if | ignoring policy-based mechanisms (including MTA-STS and DANE), if | |||
any, asserted by the recipient domain. Nevertheless, the client | any, asserted by the recipient domain. Nevertheless, the client | |||
SHOULD negotiate STARTTLS with the server if available. | SHOULD negotiate STARTTLS with the server if available. | |||
More than one instance of the TLS-Required header field MUST NOT | More than one instance of the TLS-Required header field MUST NOT | |||
appear in a given message. | appear in a given message. | |||
The ABNF syntax for the TLS-Required header field is as follows: | The ABNF syntax for the TLS-Required header field is as follows: | |||
requiretls-field = "TLS-Required:" [FWS] "No" CRLF | requiretls-field = "TLS-Required:" [FWS] "No" CRLF | |||
; where requiretls-field in an instance of an | ; where requiretls-field in an instance of an | |||
; optional-field defined in RFC 5322 Section | ; optional-field defined in RFC 5322, Section 3.6.8. | |||
; 3.6.8. | FWS = <as defined in RFC 5322> | |||
FWS = <as defined in RFC 5322> | CRLF = <as defined in RFC 5234> | |||
CRLF = <as defined in RFC 5322> | ||||
4. REQUIRETLS Semantics | 4. REQUIRETLS Semantics | |||
4.1. REQUIRETLS Receipt Requirements | 4.1. REQUIRETLS Receipt Requirements | |||
Upon receipt of the REQUIRETLS option on a MAIL FROM command during | Upon receipt of the REQUIRETLS option on a MAIL FROM command during | |||
the receipt of a message, an SMTP server MUST tag that message as | the receipt of a message, an SMTP server MUST tag that message as | |||
needing REQUIRETLS handling. | needing REQUIRETLS handling. | |||
Upon receipt of a message not specifying the REQUIRETLS option on its | Upon receipt of a message not specifying the REQUIRETLS option on its | |||
MAIL FROM command but containing the TLS-Required header field in its | MAIL FROM command but containing the TLS-Required header field in its | |||
message header, an SMTP server implementing this specification MUST | message header, an SMTP server implementing this specification MUST | |||
tag that message with the option specified in the TLS-Required header | tag that message with the option specified in the TLS-Required header | |||
field. If the REQUIRETLS MAIL FROM parameter is specified, the TLS- | field. If the REQUIRETLS MAIL FROM parameter is specified, the TLS- | |||
Required header field MUST be ignored but MAY be included in onward | Required header field MUST be ignored but MAY be included in the | |||
relay of the message. | onward relay of the message. | |||
The manner in which the above tagging takes place is implementation- | The manner in which the above tagging takes place is implementation | |||
dependent. If the message is being locally aliased and redistributed | dependent. If the message is being locally aliased and redistributed | |||
to multiple addresses, all instances of the message MUST be tagged in | to multiple addresses, all instances of the message MUST be tagged in | |||
the same manner. | the same manner. | |||
4.2. REQUIRETLS Sender Requirements | 4.2. REQUIRETLS Sender Requirements | |||
4.2.1. Sending with TLS Required | 4.2.1. Sending with TLS Required | |||
When sending a message tagged as requiring TLS for which the MAIL | When sending a message tagged as requiring TLS for which the MAIL | |||
FROM return-path is not empty (an empty MAIL FROM return-path | FROM return-path is not empty (an empty MAIL FROM return-path | |||
indicating a bounce message), the sending (client) MTA MUST: | indicating a bounce message), the sending (client) MTA MUST: | |||
1. Look up the SMTP server to which the message is to be sent as | 1. Look up the SMTP server to which the message is to be sent, as | |||
described in [RFC5321] Section 5.1. | described in [RFC5321], Section 5.1. | |||
2. If the server lookup is accomplished via the recipient domain's | 2. If the server lookup is accomplished via the recipient domain's | |||
MX record (the usual case) and is not accompanied by a valid | MX record (the usual case) and is not accompanied by a valid | |||
DNSSEC signature, the client MUST also validate the SMTP server | DNSSEC signature, the client MUST also validate the SMTP server | |||
name using MTA-STS as described in RFC 8461 [RFC8461] | name using MTA-STS, as described in [RFC8461], Section 4.1. | |||
Section 4.1. | ||||
3. Open an SMTP session with the peer SMTP server using the EHLO | 3. Open an SMTP session with the peer SMTP server using the EHLO | |||
verb. | verb. | |||
4. Establish a TLS-protected SMTP session with its peer SMTP server | 4. Establish a TLS-protected SMTP session with its peer SMTP server | |||
and authenticate the server's certificate as specified in | and authenticate the server's certificate as specified in | |||
[RFC6125] or [RFC7672] as applicable. The hostname from the MX | [RFC6125] or [RFC7672], as applicable. The hostname from the MX | |||
record lookup (or the domain name in the absence of an MX record | record lookup (or the domain name in the absence of an MX record | |||
where an A record is used directly) MUST match the DNS-ID or CN- | where an A record is used directly) MUST match the DNS-ID or CN- | |||
ID of the certificate presented by the server. | ID of the certificate presented by the server. | |||
5. Ensure that the response to the subsequent EHLO following | 5. Ensure that the response to the subsequent EHLO following | |||
establishment of the TLS protection advertises the REQUIRETLS | establishment of the TLS protection advertises the REQUIRETLS | |||
capability. | capability. | |||
The SMTP client SHOULD follow the recommendations in [RFC7525] or its | The SMTP client SHOULD follow the recommendations in [RFC7525] or its | |||
successor with respect to negotiation of the TLS session. | successor with respect to negotiation of the TLS session. | |||
If any of the above steps fail, the client MUST issue a QUIT to the | If any of the above steps fail, the client MUST issue a QUIT to the | |||
server and repeat steps 2-5 with each host on the recipient domain's | server and repeat steps 2-5 with each host on the recipient domain's | |||
list of MX hosts in an attempt to find a mail path that meets the | list of MX hosts in an attempt to find a mail path that meets the | |||
sender's requirements. The client MAY send other, unprotected, | sender's requirements. The client MAY send other, unprotected | |||
messages to that server if it has any prior to issuing the QUIT. If | messages to that server if it has any such messages prior to issuing | |||
there are no more MX hosts, the client MUST NOT transmit the message | the QUIT. If there are no more MX hosts, the client MUST NOT | |||
to the domain. | transmit the message to the domain. | |||
Following such a failure, the SMTP client MUST send a non-delivery | Following such a failure, the SMTP client MUST send a non-delivery | |||
notification to the reverse-path of the failed message as described | notification to the reverse-path of the failed message, as described | |||
in section 3.6 of [RFC5321]. The following status codes [RFC5248] | in Section 3.6 of [RFC5321]. The following status codes [RFC5248] | |||
SHOULD be used: | SHOULD be used: | |||
o REQUIRETLS not supported by server: 5.7.YYY REQUIRETLS needed | * REQUIRETLS not supported by server: 5.7.30 REQUIRETLS support | |||
required | ||||
o Unable to establish TLS-protected SMTP session: 5.7.10 Encryption | * Unable to establish TLS-protected SMTP session: 5.7.10 Encryption | |||
needed | needed | |||
Refer to Section 5 for further requirements regarding non-delivery | Refer to Section 5 for further requirements regarding non-delivery | |||
messages. | messages. | |||
If all REQUIRETLS requirements have been met, transmit the message, | If all REQUIRETLS requirements have been met, transmit the message, | |||
issuing the REQUIRETLS option on the MAIL FROM command with the | issuing the REQUIRETLS option on the MAIL FROM command with the | |||
required option(s), if any. | required option(s), if any. | |||
4.2.2. Sending with TLS Optional | 4.2.2. Sending with TLS Optional | |||
Messages tagged TLS-Required: No are handled as follows. When | Messages tagged "TLS-Required: No" are handled as follows. When | |||
sending such a message, the sending (client) MTA MUST: | sending such a message, the sending (client) MTA MUST: | |||
o Look up the SMTP server to which the message is to be sent as | * Look up the SMTP server to which the message is to be sent, as | |||
described in [RFC5321] Section 5.1. | described in [RFC5321], Section 5.1. | |||
o Open an SMTP session with the peer SMTP server using the EHLO | * Open an SMTP session with the peer SMTP server using the EHLO | |||
verb. Attempt to negotiate STARTTLS if possible, and follow any | verb. Attempt to negotiate STARTTLS if possible, and follow any | |||
policy published by the recipient domain, but do not fail if this | policy published by the recipient domain, but do not fail if this | |||
is unsuccessful. | is unsuccessful. | |||
Some SMTP servers may be configured to require STARTTLS connections | Some SMTP servers may be configured to require STARTTLS connections | |||
as a matter of policy and not accept messages in the absence of | as a matter of policy and not accept messages in the absence of | |||
STARTTLS. A non-delivery notification MUST be returned to the sender | STARTTLS. A non-delivery notification MUST be returned to the sender | |||
if message relay fails due to an inability to negotiate STARTTLS when | if message relay fails due to an inability to negotiate STARTTLS when | |||
required by the server. | required by the server. | |||
Since messages tagged with TLS-Required: No will sometimes be sent to | Since messages tagged with "TLS-Required: No" will sometimes be sent | |||
SMTP servers not supporting REQUIRETLS, that option will not be | to SMTP servers not supporting REQUIRETLS, that option will not be | |||
uniformly observed by all SMTP relay hops. | uniformly observed by all SMTP relay hops. | |||
4.3. REQUIRETLS Submission | 4.3. REQUIRETLS Submission | |||
An MUA or other agent making the initial introduction of a message | A Mail User Agent (MUA) or other agent making the initial | |||
has the option to decide whether to require TLS. If TLS is to be | introduction of a message has the option to decide whether to require | |||
required, it MUST do so by negotiating STARTTLS and REQUIRETLS and | TLS. If TLS is to be required, it MUST do so by negotiating STARTTLS | |||
include the REQUIRETLS option on the MAIL FROM command, as is done | and REQUIRETLS and including the REQUIRETLS option on the MAIL FROM | |||
for message relay. | command, as is done for message relay. | |||
When TLS is not to be required, the sender MUST include the TLS- | When TLS is not to be required, the sender MUST include the TLS- | |||
Required header field in the message. SMTP servers implementing this | Required header field in the message. SMTP servers implementing this | |||
specification MUST interpret this header field as described in | specification MUST interpret this header field as described in | |||
Section 4.1. | Section 4.1. | |||
In either case, the decision whether to specify REQUIRETLS MAY be | In either case, the decision whether to specify REQUIRETLS MAY be | |||
done based on a user interface selection or based on a ruleset or | done based on a user interface selection or based on a ruleset or | |||
other policy. The manner in which the decision to require TLS is | other policy. The manner in which the decision to require TLS is | |||
made is implementation-dependent and is beyond the scope of this | made is implementation dependent and is beyond the scope of this | |||
specification. | specification. | |||
4.4. Delivery of REQUIRETLS messages | 4.4. Delivery of REQUIRETLS messages | |||
Messages are usually retrieved by end users using protocols other | Messages are usually retrieved by end users using protocols other | |||
than SMTP such as IMAP [RFC3501], POP [RFC1939], or web mail systems. | than SMTP such as IMAP [RFC3501], POP [RFC1939], or Web mail systems. | |||
Mail delivery agents supporting the REQUIRETLS SMTP option SHOULD | Mail delivery agents supporting the REQUIRETLS SMTP option SHOULD | |||
observe the guidelines in [RFC8314]. | observe the guidelines in [RFC8314]. | |||
5. Non-delivery message handling | 5. Non-delivery Message Handling | |||
Non-delivery ("bounce") messages usually contain important metadata | Non-delivery ("bounce") messages usually contain important metadata | |||
about the message to which they refer, including the original message | about the message to which they refer, including the original message | |||
header. They therefore MUST be protected in the same manner as the | header. They therefore MUST be protected in the same manner as the | |||
original message. All non-delivery messages resulting from messages | original message. All non-delivery messages resulting from messages | |||
with the REQUIRETLS SMTP option, whether resulting from a REQUIRETLS | with the REQUIRETLS SMTP option, whether resulting from a REQUIRETLS | |||
error or some other, MUST also specify the REQUIRETLS SMTP option | error or some other issue, MUST also specify the REQUIRETLS SMTP | |||
unless redacted as described below. | option unless redacted as described below. | |||
The path from the origination of an error bounce message back to the | The path from the origination of an error bounce message back to the | |||
MAIL FROM address may not share the same REQUIRETLS support as the | MAIL FROM address may not share the same REQUIRETLS support as the | |||
forward path. Therefore, users requiring TLS are advised to make | forward path. Therefore, users requiring TLS are advised to make | |||
sure that they are capable of receiving mail using REQUIRETLS as | sure that they are capable of receiving mail using REQUIRETLS as | |||
well. Otherwise, such non-delivery messages will be lost. | well. Otherwise, such non-delivery messages will be lost. | |||
If a REQUIRETLS message is bounced, the server MUST behave as if | If a REQUIRETLS message is bounced, the server MUST behave as if | |||
RET=HDRS was present as described in [RFC3461]. If both RET=FULL and | RET=HDRS was present, as described in [RFC3461]. If both RET=FULL | |||
REQUIRETLS are present, the RET=FULL MUST be disregarded. The SMTP | and REQUIRETLS are present, the RET=FULL MUST be disregarded. The | |||
client for a REQUIRETLS bounce message uses an empty MAIL FROM | SMTP client for a REQUIRETLS bounce message uses an empty MAIL FROM | |||
return-path as required by [RFC5321]. When the MAIL FROM return-path | return-path, as required by [RFC5321]. When the MAIL FROM return- | |||
is empty, the REQUIRETLS parameter SHOULD NOT cause a bounce message | path is empty, the REQUIRETLS parameter SHOULD NOT cause a bounce | |||
to be discarded even if the next-hop relay does not advertise | message to be discarded even if the next-hop relay does not advertise | |||
REQUIRETLS. | REQUIRETLS. | |||
Senders of messages requiring TLS are advised to consider the | Senders of messages requiring TLS are advised to consider the | |||
possibility that bounce messages will be lost as a result of | possibility that bounce messages will be lost as a result of | |||
REQUIRETLS return path failure, and that some information could be | REQUIRETLS return path failure and that some information could be | |||
leaked if a bounce message is not able to be transmitted with | leaked if a bounce message is not able to be transmitted with | |||
REQUIRETLS. | REQUIRETLS. | |||
6. Reorigination considerations | 6. Reorigination Considerations | |||
In a number of situations, a mediator [RFC5598] originates a new | In a number of situations, a mediator [RFC5598] originates a new | |||
message as a result of an incoming message. These situations | message as a result of an incoming message. These situations include | |||
include, but are not limited to, mailing lists (including | but are not limited to mailing lists (including administrative | |||
administrative traffic such as message approval requests), Sieve | traffic such as message approval requests), Sieve [RFC5228], | |||
[RFC5228], "vacation" responders, and other filters to which incoming | "vacation" responders, and other filters to which incoming messages | |||
messages may be piped. These newly originated messages may | may be piped. These newly originated messages may essentially be | |||
essentially be copies of the incoming message, such as with a | copies of the incoming message, such as with a forwarding service or | |||
forwarding service or a mailing list expander. In other cases, such | a mailing list expander. In other cases, such as with a vacation | |||
as with a vacation message or a delivery notification, they will be | message or a delivery notification, they will be different but might | |||
different but might contain parts of the original message or other | contain parts of the original message or other information for which | |||
information for which the original message sender wants to influence | the original message sender wants to influence the requirement to use | |||
the requirement to use TLS transmission. | TLS transmission. | |||
Mediators that reoriginate messages should apply REQUIRETLS | Mediators that reoriginate messages should apply REQUIRETLS | |||
requirements in incoming messages (both requiring TLS transmission | requirements in incoming messages (both requiring TLS transmission | |||
and requesting that TLS not be required) to the reoriginated messages | and requesting that TLS not be required) to the reoriginated messages | |||
to the extent feasible. A limitation to this might be that for a | to the extent feasible. A limitation to this might be that for a | |||
message requiring TLS, redistribution to multiple addresses while | message requiring TLS, redistribution to multiple addresses while | |||
retaining the TLS requirement could result in the message not being | retaining the TLS requirement could result in the message not being | |||
delivered to some of the intended recipients. | delivered to some of the intended recipients. | |||
User-side mediators (such as use of Sieve rules on a user agent) | User-side mediators (such as use of Sieve rules on a user agent) | |||
typically do not have access to the SMTP details, and therefore may | typically do not have access to the SMTP details and therefore may | |||
not be aware of the REQUIRETLS requirement on a delivered message. | not be aware of the REQUIRETLS requirement on a delivered message. | |||
Recipients that expect sensitive traffic should avoid the use of | Recipients that expect sensitive traffic should avoid the use of | |||
user-side mediators. Alternatively, if operationally feasible (such | user-side mediators. Alternatively, if operationally feasible (such | |||
as when forwarding to a specific, known address), they should apply | as when forwarding to a specific, known address), they should apply | |||
REQUIRETLS to all reoriginated messages that do not contain the "TLS- | REQUIRETLS to all reoriginated messages that do not contain the "TLS- | |||
Required: No" header field. | Required: No" header field. | |||
7. IANA Considerations | 7. IANA Considerations | |||
If published as an RFC, this draft requests the addition of the | Per this document, IANA has added the following keyword to the "SMTP | |||
following keyword to the SMTP Service Extensions Registry | Service Extensions" subregistry of the "Mail Parameters" registry | |||
[MailParams]: | [MailParams]: | |||
Textual name: Require TLS | EHLO Keyword: REQUIRETLS | |||
EHLO keyword value: REQUIRETLS | Description: Require TLS | |||
Syntax and parameters: (no parameters) | Syntax and parameters: (no parameters) | |||
Additional SMTP verbs: none | Additional SMTP verbs: none | |||
MAIL and RCPT parameters: REQUIRETLS parameter on MAIL | MAIL and RCPT parameters: REQUIRETLS parameter on MAIL | |||
Behavior: Use of the REQUIRETLS parameter on the | Behavior: Use of the REQUIRETLS parameter on | |||
MAIL verb causes that message to require | the MAIL verb causes that message to | |||
the use of TLS and tagging with | require the use of TLS and tagging | |||
REQUIRETLS for all onward relay. | with REQUIRETLS for all onward | |||
Command length increment: 11 characters | relay. | |||
Command length increment: 11 characters | ||||
If published as an RFC, this draft requests the addition of an entry | ||||
to the Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes | ||||
Registry [SMTPStatusCodes]: | ||||
Code: 5.7.YYY | Per this document, IANA has added an entry to the "Enumerated Status | |||
Sample Text: REQUIRETLS support required | Codes" subregistry of the "Simple Mail Transfer Protocol (SMTP) | |||
Associated basic status code: 550 | Enhanced Status Codes Registry" [SMTPStatusCodes]: | |||
Description: This indicates that the message was not | ||||
able to be forwarded because it was | ||||
received with a REQUIRETLS requirement | ||||
and none of the SMTP servers to which | ||||
the message should be forwarded provide | ||||
this support. | ||||
Reference: (this document) | ||||
Submitter: J. Fenton | ||||
Change controller: IESG | ||||
If published as an RFC, this draft requests the addition of an entry | Code: X.7.30 | |||
to the Permanent Message Header Field Names Registry | Sample Text: REQUIRETLS support required | |||
[PermMessageHeaderFields]: | Associated basic status code: 550 | |||
Description: This indicates that the message was | ||||
not able to be forwarded because it | ||||
was received with a REQUIRETLS | ||||
requirement and none of the SMTP | ||||
servers to which the message should | ||||
be forwarded provide this support. | ||||
Reference: RFC 8689 | ||||
Submitter: J. Fenton | ||||
Change Controller: IESG | ||||
Header field name: TLS-Required | Per this document, IANA has added an entry to the "Permanent Message | |||
Applicable protocol: mail | Header Field Names" subregistry of the "Message Headers" registry | |||
Status: standard | [MessageHeaders] as follows: | |||
Author/change controller: IETF | ||||
Specification document: (this document) | ||||
This section is to be updated for publication by the RFC Editor. | Header field name: TLS-Required | |||
Applicable protocol: mail | ||||
Status: standard | ||||
Author/change controller: IETF | ||||
Specification document: RFC 8689 | ||||
8. Security Considerations | 8. Security Considerations | |||
The purpose of REQUIRETLS is to give the originator of a message | The purpose of REQUIRETLS is to give the originator of a message | |||
control over the security of email they send, either by conveying an | control over the security of email they send, either by conveying an | |||
expectation that it will be transmitted in an encrypted form "over | expectation that it will be transmitted in an encrypted form over the | |||
the wire" or explicitly that transport encryption is not required if | wire or explicitly indicating that transport encryption is not | |||
it cannot be successfully negotiated. | required if it cannot be successfully negotiated. | |||
The following considerations apply to the REQUIRETLS service | The following considerations apply to the REQUIRETLS service | |||
extension but not the TLS-Required header field, since messages | extension but not the TLS-Required header field, since messages | |||
specifying the header field are less concerned with transport | specifying the header field are less concerned with transport | |||
security. | security. | |||
8.1. Passive attacks | 8.1. Passive Attacks | |||
REQUIRETLS is generally effective against passive attackers who are | REQUIRETLS is generally effective against passive attackers who are | |||
merely trying to eavesdrop on an SMTP exchange between an SMTP client | merely trying to eavesdrop on an SMTP exchange between an SMTP client | |||
and server. This assumes, of course, the cryptographic integrity of | and server. This assumes, of course, the cryptographic integrity of | |||
the TLS connection being used. | the TLS connection being used. | |||
8.2. Active attacks | 8.2. Active Attacks | |||
Active attacks against TLS encrypted SMTP connections can take many | Active attacks against TLS-encrypted SMTP connections can take many | |||
forms. One such attack is to interfere in the negotiation by | forms. One such attack is to interfere in the negotiation by | |||
changing the STARTTLS command to something illegal such as XXXXXXXX. | changing the STARTTLS command to something illegal such as XXXXXXXX. | |||
This causes TLS negotiation to fail and messages to be sent in the | This causes TLS negotiation to fail and messages to be sent in the | |||
clear, where they can be intercepted. REQUIRETLS detects the failure | clear, where they can be intercepted. REQUIRETLS detects the failure | |||
of STARTTLS and declines to send the message rather than send it | of STARTTLS and declines to send the message rather than send it | |||
insecurely. | insecurely. | |||
A second form of attack is a man-in-the-middle attack where the | A second form of attack is a man-in-the-middle attack where the | |||
attacker terminates the TLS connection rather than the intended SMTP | attacker terminates the TLS connection rather than the intended SMTP | |||
server. This is possible when, as is commonly the case, the SMTP | server. This is possible when, as is commonly the case, the SMTP | |||
client either does not verify the server's certificate or establishes | client either does not verify the server's certificate or establishes | |||
the connection even when the verification fails. REQUIRETLS requires | the connection even when the verification fails. REQUIRETLS requires | |||
successful certificate validation before sending the message. | successful certificate validation before sending the message. | |||
Another active attack involves the spoofing of DNS MX records of the | Another active attack involves the spoofing of DNS MX records of the | |||
recipient domain. An attacker having this capability could | recipient domain. An attacker with this capability could potentially | |||
potentially cause the message to be redirected to a mail server under | cause the message to be redirected to a mail server under the | |||
the attacker's own control, which would presumably have a valid | attacker's own control, which would presumably have a valid | |||
certificate. REQUIRETLS requires that the recipient domain's MX | certificate. REQUIRETLS requires that the recipient domain's MX | |||
record lookup be validated either using DNSSEC or via a published | record lookup be validated either using DNSSEC or via a published | |||
MTA-STS policy that specifies the acceptable SMTP server hostname(s) | MTA-STS policy that specifies the acceptable SMTP server hostname(s) | |||
for the recipient domain. | for the recipient domain. | |||
8.3. Bad Actor MTAs | 8.3. Bad-Actor MTAs | |||
A bad-actor MTA along the message transmission path could | A bad-actor MTA along the message transmission path could | |||
misrepresent its support of REQUIRETLS and/or actively strip | misrepresent its support of REQUIRETLS and/or actively strip | |||
REQUIRETLS tags from messages it handles. However, since | REQUIRETLS tags from messages it handles. However, since | |||
intermediate MTAs are already trusted with the cleartext of messages | intermediate MTAs are already trusted with the cleartext of messages | |||
they handle, and are not part of the threat model for transport-layer | they handle, and are not part of the threat model for transport-layer | |||
security, they are also not part of the threat model for REQUIRETLS. | security, they are also not part of the threat model for REQUIRETLS. | |||
It should be reemphasized that since SMTP TLS is a transport-layer | It should be reemphasized that since SMTP TLS is a transport-layer | |||
security protocol, messages sent using REQUIRETLS are not encrypted | security protocol, messages sent using REQUIRETLS are not encrypted | |||
end-to-end and are visible to MTAs that are part of the message | end-to-end and are visible to MTAs that are part of the message | |||
delivery path. Messages containing sensitive information that MTAs | delivery path. Messages containing sensitive information that MTAs | |||
should not have access to MUST be sent using end-to-end content | should not have access to MUST be sent using end-to-end content | |||
encryption such as OpenPGP [RFC4880] or S/MIME [RFC8551]. | encryption such as OpenPGP [RFC4880] or S/MIME [RFC8551]. | |||
8.4. Policy Conflicts | 8.4. Policy Conflicts | |||
In some cases, the use of the TLS-Required header field may conflict | In some cases, the use of the TLS-Required header field may conflict | |||
with a recipient domain policy expressed through the DANE [RFC7672] | with a recipient domain policy expressed through the DANE [RFC7672] | |||
or MTA-STS [RFC8461] protocols. Although these protocols encourage | or MTA-STS [RFC8461] protocols. Although these protocols encourage | |||
the use of TLS transport by advertising availability of TLS, the use | the use of TLS transport by advertising the availability of TLS, the | |||
of "TLS-Required: No" header field represents an explicit decision on | use of the "TLS-Required: No" header field represents an explicit | |||
the part of the sender not to require the use of TLS, such as to | decision on the part of the sender not to require the use of TLS, | |||
overcome a configuration error. The recipient domain has the | such as to overcome a configuration error. The recipient domain has | |||
ultimate ability to require TLS by not accepting messages when | the ultimate ability to require TLS by not accepting messages when | |||
STARTTLS has not been negotiated; otherwise, "TLS-Required: No" is | STARTTLS has not been negotiated; otherwise, "TLS-Required: No" is | |||
effectively directing the client MTA to behave as if it does not | effectively directing the client MTA to behave as if it does not | |||
support DANE nor MTA-STS. | support DANE or MTA-STS. | |||
9. Acknowledgements | ||||
The author would like to acknowledge many helpful suggestions on the | ||||
ietf-smtp and uta mailing lists, in particular those of Viktor | ||||
Dukhovni, Chris Newman, Tony Finch, Jeremy Harris, Arvel Hathcock, | ||||
John Klensin, Barry Leiba, John Levine, Rolf Sonneveld, and Per | ||||
Thorsheim. | ||||
10. Revision History | ||||
To be removed by RFC Editor upon publication as an RFC. | ||||
10.1. Changes since -08 Draft | ||||
Additional changes in response to IESG review: | ||||
o Unify wording describing TLS-Required in Appendix A.2. | ||||
o Add specifics on verification of mail server hostnames with | ||||
certificates. | ||||
o Wording tweak in 4.3 to emphasize optional nature of REQUIRETLS. | ||||
o Update S/MIME reference from RFC 5751 to 8551 | ||||
10.2. Changes since -07 Draft | ||||
Changes in response to IESG review and IETF Last Call comments: | ||||
o Change associated status code for 5.7.YYY from 530 to 550. | ||||
o Correct textual name of extension in IANA Considerations for | ||||
consistency with the rest of the document. | ||||
o Remove special handling of bounce messages in Section 4.1. | ||||
o Change name of header field from RequireTLS to TLS-Required and | ||||
make capitalization of parameter consistent. | ||||
o Remove mention of transforming RET=FULL to RET=HDRS on relay in | ||||
Section 5. | ||||
o Replace Section 6 dealing with mailing lists with a more general | ||||
section on reorigination by mediators. | ||||
o Add security considerations section on policy conflicts. | ||||
10.3. Changes since -06 Draft | ||||
Various changes in response to AD review: | ||||
o Reference RFC 7525 for TLS negotiation recommendations. | ||||
o Make reference to requested 5.7.YYY error code consistent. | ||||
o Clarify applicability to LMTP and submission. | ||||
o Provide ABNF for syntax of SMTP option and header field and | ||||
examples in Appendix A. | ||||
o Correct use of normative language in Section 5. | ||||
o Clarify case where REQUIRETLS option is used on bounce messages. | ||||
o Improve Security Requirements wording to be inclusive of both SMTP | ||||
option and header field. | ||||
10.4. Changes since -05 Draft | ||||
Corrected IANA Permanent Message Header Fields Registry request. | ||||
10.5. Changes since -04 Draft | ||||
Require validation of SMTP server hostname via DNSSEC or MTA-STS | ||||
policy when TLS is required. | ||||
10.6. Changes since -03 Draft | ||||
Working Group Last Call changes, including: | ||||
o Correct reference for SMTP DANE | ||||
o Clarify that RequireTLS: NO applies to both MTA-STS and DANE | ||||
policies | ||||
o Correct newly-defined status codes | ||||
o Update MTA-STS references to RFC | ||||
10.7. Changes since -02 Draft | ||||
o More complete documentation for IANA registration requests. | ||||
o Changed bounce handling to use RET parameters of [RFC3461], along | ||||
with slightly more liberal transmission of bounces even if | ||||
REQUIRETLS can't be negotiated. | ||||
10.8. Changes since -01 Draft | ||||
o Converted DEEP references to RFC 8314. | ||||
o Removed REQUIRETLS options: CHAIN, DANE, and DNSSEC. | ||||
o Editorial corrections, notably making the header field name | ||||
consistent (RequireTLS rather than Require-TLS). | ||||
10.9. Changes since -00 Draft | ||||
o Created new header field, Require-TLS, for use by "NO" option. | ||||
o Removed "NO" option from SMTP service extension. | ||||
o Recommend DEEP requirements for delivery of messages requiring | ||||
TLS. | ||||
o Assorted copy edits | ||||
10.10. Changes since fenton-03 Draft | ||||
o Wording improvements from Rolf Sonneveld review 22 July 2017 | ||||
o A few copy edits | ||||
o Conversion from individual to UTA WG draft | ||||
10.11. Changes Since -02 Draft | ||||
o Incorporation of "MAY TLS" functionality as REQUIRETLS=NO per | ||||
suggestion on UTA WG mailing list. | ||||
o Additional guidance on bounce messages | ||||
10.12. Changes Since -01 Draft | ||||
o Specified retries when multiple MX hosts exist for a given domain. | ||||
o Clarified generation of non-delivery messages | ||||
o Specified requirements for application of REQUIRETLS to mail | ||||
forwarders and mailing lists. | ||||
o Clarified DNSSEC requirements to include MX lookup only. | ||||
o Corrected terminology regarding message retrieval vs. delivery. | ||||
o Changed category to standards track. | ||||
10.13. Changes Since -00 Draft | ||||
o Conversion of REQUIRETLS from an SMTP verb to a MAIL FROM | ||||
parameter to better associate REQUIRETLS requirements with | ||||
transmission of individual messages. | ||||
o Addition of an option to require DNSSEC lookup of the remote mail | ||||
server, since this affects the common name of the certificate that | ||||
is presented. | ||||
o Clarified the wording to more clearly state that TLS sessions must | ||||
be established and not simply that STARTTLS is negotiated. | ||||
o Introduced need for minimum encryption standards (key lengths and | ||||
algorithms) | ||||
o Substantially rewritten Security Considerations section | ||||
11. References | 9. References | |||
11.1. Normative References | 9.1. Normative References | |||
[MailParams] | [MailParams] | |||
Internet Assigned Numbers Authority (IANA), "IANA Mail | IANA, "Mail Parameters", | |||
Parameters", 2007, | ||||
<http://www.iana.org/assignments/mail-parameters>. | <http://www.iana.org/assignments/mail-parameters>. | |||
[PermMessageHeaderFields] | [MessageHeaders] | |||
Internet Assigned Numbers Authority (IANA), "Permanent | IANA, "Permanent Message Header Field Names", | |||
Message Header Field Names Registry", 2004, | <https://www.iana.org/assignments/message-headers>. | |||
<https://www.iana.org/assignments/message-headers/ | ||||
message-headers.xhtml#perm-headers>. | ||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over | [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over | |||
Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, | Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, | |||
February 2002, <https://www.rfc-editor.org/info/rfc3207>. | February 2002, <https://www.rfc-editor.org/info/rfc3207>. | |||
skipping to change at page 18, line 20 ¶ | skipping to change at line 636 ¶ | |||
Use of Transport Layer Security (TLS) for Email Submission | Use of Transport Layer Security (TLS) for Email Submission | |||
and Access", RFC 8314, DOI 10.17487/RFC8314, January 2018, | and Access", RFC 8314, DOI 10.17487/RFC8314, January 2018, | |||
<https://www.rfc-editor.org/info/rfc8314>. | <https://www.rfc-editor.org/info/rfc8314>. | |||
[RFC8461] Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A., | [RFC8461] Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A., | |||
and J. Jones, "SMTP MTA Strict Transport Security (MTA- | and J. Jones, "SMTP MTA Strict Transport Security (MTA- | |||
STS)", RFC 8461, DOI 10.17487/RFC8461, September 2018, | STS)", RFC 8461, DOI 10.17487/RFC8461, September 2018, | |||
<https://www.rfc-editor.org/info/rfc8461>. | <https://www.rfc-editor.org/info/rfc8461>. | |||
[SMTPStatusCodes] | [SMTPStatusCodes] | |||
Internet Assigned Numbers Authority (IANA), "Simple Mail | IANA, "Simple Mail Transfer Protocol (SMTP) Enhanced | |||
Transfer Protocol (SMTP) Enhanced Status Codes Registry", | Status Codes Registry", <https://www.iana.org/assignments/ | |||
2008, <http://www.iana.org/assignments/ | ||||
smtp-enhanced-status-codes>. | smtp-enhanced-status-codes>. | |||
11.2. Informative References | 9.2. Informative References | |||
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", | [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", | |||
STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, | STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, | |||
<https://www.rfc-editor.org/info/rfc1939>. | <https://www.rfc-editor.org/info/rfc1939>. | |||
[RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, | [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, | |||
DOI 10.17487/RFC2033, October 1996, | DOI 10.17487/RFC2033, October 1996, | |||
<https://www.rfc-editor.org/info/rfc2033>. | <https://www.rfc-editor.org/info/rfc2033>. | |||
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION | [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION | |||
skipping to change at page 19, line 20 ¶ | skipping to change at line 682 ¶ | |||
Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 | Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 | |||
Message Specification", RFC 8551, DOI 10.17487/RFC8551, | Message Specification", RFC 8551, DOI 10.17487/RFC8551, | |||
April 2019, <https://www.rfc-editor.org/info/rfc8551>. | April 2019, <https://www.rfc-editor.org/info/rfc8551>. | |||
Appendix A. Examples | Appendix A. Examples | |||
This section is informative. | This section is informative. | |||
A.1. REQUIRETLS SMTP Option | A.1. REQUIRETLS SMTP Option | |||
The TLS-Required SMTP option is used to express the intent of the | The TLS-Required SMTP option is used to express the intention of the | |||
sender that the associated message be relayed using TLS. In the | sender to have the associated message relayed using TLS. In the | |||
following example, lines beginning with C: are transmitted from the | following example, lines beginning with "C:" are transmitted from the | |||
SMTP client to the server, and lines beginning with S: are | SMTP client to the server, and lines beginning with "S:" are | |||
transmitted in the opposite direction. | transmitted in the opposite direction. | |||
S: 220 mail.example.net ESMTP | S: 220 mail.example.net ESMTP | |||
C: EHLO mail.example.org | C: EHLO mail.example.org | |||
S: 250-mail.example.net Hello example.org [192.0.2.1] | S: 250-mail.example.net Hello example.org [192.0.2.1] | |||
S: 250-SIZE 52428800 | S: 250-SIZE 52428800 | |||
S: 250-8BITMIME | S: 250-8BITMIME | |||
S: 250-PIPELINING | S: 250-PIPELINING | |||
S: 250-STARTTLS | S: 250-STARTTLS | |||
S: 250 HELP | S: 250 HELP | |||
C: STARTTLS | C: STARTTLS | |||
S: TLS go ahead | S: TLS go ahead | |||
(at this point TLS negotiation takes place. The remainder of this | (at this point TLS negotiation takes place. The remainder of this | |||
session occurs within TLS.) | session occurs within TLS.) | |||
S: 220 mail.example.net ESMTP | S: 220 mail.example.net ESMTP | |||
C: EHLO mail.example.org | C: EHLO mail.example.org | |||
S: 250-mail.example.net Hello example.org [192.0.2.1] | S: 250-mail.example.net Hello example.org [192.0.2.1] | |||
S: 250-SIZE 52428800 | S: 250-SIZE 52428800 | |||
S: 250-8BITMIME | S: 250-8BITMIME | |||
S: 250-PIPELINING | S: 250-PIPELINING | |||
S: 250-REQUIRETLS | S: 250-REQUIRETLS | |||
S: 250 HELP | S: 250 HELP | |||
C: MAIL FROM:<roger@example.org> REQUIRETLS | C: MAIL FROM:<roger@example.org> REQUIRETLS | |||
S: 250 OK | S: 250 OK | |||
C: RCPT TO:<editor@example.net> | C: RCPT TO:<editor@example.net> | |||
S: 250 Accepted | S: 250 Accepted | |||
C: DATA | C: DATA | |||
S: 354 Enter message, ending with "." on a line by itself | S: 354 Enter message, ending with "." on a line by itself | |||
(message follows) | (message follows) | |||
C: . | C: . | |||
S: 250 OK | S: 250 OK | |||
C: QUIT | C: QUIT | |||
A.2. TLS-Required Header Field | A.2. TLS-Required Header Field | |||
The TLS-Required header field is used when the sender requests that | The TLS-Required header field is used when the sender requests that | |||
the mail system not heed a default policy of the recipient domain | the mail system not heed a default policy of the recipient domain | |||
requiring TLS. It might be used, for example, to allow problems with | requiring TLS. It might be used, for example, to allow problems with | |||
the recipient domain's TLS certificate to be reported: | the recipient domain's TLS certificate to be reported: | |||
skipping to change at page 21, line 17 ¶ | skipping to change at line 742 ¶ | |||
Subject: Certificate problem? | Subject: Certificate problem? | |||
TLS-Required: No | TLS-Required: No | |||
Date: Fri, 18 Jan 2019 10:26:55 -0800 | Date: Fri, 18 Jan 2019 10:26:55 -0800 | |||
Message-ID: <5c421a6f79c0e_d153ff8286d45c468473@mail.example.org> | Message-ID: <5c421a6f79c0e_d153ff8286d45c468473@mail.example.org> | |||
Andy, there seems to be a problem with the TLS certificate | Andy, there seems to be a problem with the TLS certificate | |||
on your mail server. Are you aware of this? | on your mail server. Are you aware of this? | |||
Roger | Roger | |||
Acknowledgements | ||||
The author would like to acknowledge many helpful suggestions on the | ||||
ietf-smtp and uta mailing lists, in particular those of Viktor | ||||
Dukhovni, Tony Finch, Jeremy Harris, Arvel Hathcock, John Klensin, | ||||
Barry Leiba, John Levine, Chris Newman, Rolf Sonneveld, and Per | ||||
Thorsheim. | ||||
Author's Address | Author's Address | |||
Jim Fenton | Jim Fenton | |||
Altmode Networks | Altmode Networks | |||
Los Altos, California 94024 | Los Altos, California 94024 | |||
USA | United States of America | |||
Email: fenton@bluepopcorn.net | Email: fenton@bluepopcorn.net | |||
End of changes. 72 change blocks. | ||||
387 lines changed or deleted | 212 lines changed or added | |||
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |