draft-ietf-uta-smtp-require-tls-08.txt | draft-ietf-uta-smtp-require-tls-09.txt | |||
---|---|---|---|---|
Internet Engineering Task Force J. Fenton | Internet Engineering Task Force J. Fenton | |||
Internet-Draft Altmode Networks | Internet-Draft Altmode Networks | |||
Intended status: Standards Track April 22, 2019 | Intended status: Standards Track August 2, 2019 | |||
Expires: October 24, 2019 | Expires: February 3, 2020 | |||
SMTP Require TLS Option | SMTP Require TLS Option | |||
draft-ietf-uta-smtp-require-tls-08 | 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 message | |||
header field, TLS-Required. If the REQUIRETLS option or TLS-Required | header field, TLS-Required. If the REQUIRETLS option or TLS-Required | |||
message header field is used when sending a message, it asserts a | message header field is used when sending a message, it asserts a | |||
skipping to change at page 1, line 41 ¶ | skipping to change at page 1, line 41 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on October 24, 2019. | This Internet-Draft will expire on February 3, 2020. | |||
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 | |||
skipping to change at page 2, line 34 ¶ | skipping to change at page 2, line 34 ¶ | |||
4.4. Delivery of REQUIRETLS messages . . . . . . . . . . . . . 8 | 4.4. Delivery of REQUIRETLS messages . . . . . . . . . . . . . 8 | |||
5. Non-delivery message handling . . . . . . . . . . . . . . . . 8 | 5. Non-delivery message handling . . . . . . . . . . . . . . . . 8 | |||
6. Reorigination considerations . . . . . . . . . . . . . . . . 9 | 6. Reorigination considerations . . . . . . . . . . . . . . . . 9 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | |||
8.1. Passive attacks . . . . . . . . . . . . . . . . . . . . . 11 | 8.1. Passive attacks . . . . . . . . . . . . . . . . . . . . . 11 | |||
8.2. Active attacks . . . . . . . . . . . . . . . . . . . . . 11 | 8.2. Active attacks . . . . . . . . . . . . . . . . . . . . . 11 | |||
8.3. Bad Actor MTAs . . . . . . . . . . . . . . . . . . . . . 12 | 8.3. Bad Actor MTAs . . . . . . . . . . . . . . . . . . . . . 12 | |||
8.4. Policy Conflicts . . . . . . . . . . . . . . . . . . . . 12 | 8.4. Policy Conflicts . . . . . . . . . . . . . . . . . . . . 12 | |||
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 | 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 | |||
10. Revision History . . . . . . . . . . . . . . . . . . . . . . 12 | 10. Revision History . . . . . . . . . . . . . . . . . . . . . . 13 | |||
10.1. Changes since -07 Draft . . . . . . . . . . . . . . . . 12 | 10.1. Changes since -08 Draft . . . . . . . . . . . . . . . . 13 | |||
10.2. Changes since -06 Draft . . . . . . . . . . . . . . . . 13 | 10.2. Changes since -07 Draft . . . . . . . . . . . . . . . . 13 | |||
10.3. Changes since -05 Draft . . . . . . . . . . . . . . . . 13 | 10.3. Changes since -06 Draft . . . . . . . . . . . . . . . . 13 | |||
10.4. Changes since -04 Draft . . . . . . . . . . . . . . . . 13 | 10.4. Changes since -05 Draft . . . . . . . . . . . . . . . . 14 | |||
10.5. Changes since -03 Draft . . . . . . . . . . . . . . . . 14 | 10.5. Changes since -04 Draft . . . . . . . . . . . . . . . . 14 | |||
10.6. Changes since -02 Draft . . . . . . . . . . . . . . . . 14 | 10.6. Changes since -03 Draft . . . . . . . . . . . . . . . . 14 | |||
10.7. Changes since -01 Draft . . . . . . . . . . . . . . . . 14 | 10.7. Changes since -02 Draft . . . . . . . . . . . . . . . . 14 | |||
10.8. Changes since -00 Draft . . . . . . . . . . . . . . . . 14 | 10.8. Changes since -01 Draft . . . . . . . . . . . . . . . . 14 | |||
10.9. Changes since fenton-03 Draft . . . . . . . . . . . . . 14 | 10.9. Changes since -00 Draft . . . . . . . . . . . . . . . . 15 | |||
10.10. Changes Since -02 Draft . . . . . . . . . . . . . . . . 15 | 10.10. Changes since fenton-03 Draft . . . . . . . . . . . . . 15 | |||
10.11. Changes Since -01 Draft . . . . . . . . . . . . . . . . 15 | 10.11. Changes Since -02 Draft . . . . . . . . . . . . . . . . 15 | |||
10.12. Changes Since -00 Draft . . . . . . . . . . . . . . . . 15 | 10.12. Changes Since -01 Draft . . . . . . . . . . . . . . . . 15 | |||
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 | 10.13. Changes Since -00 Draft . . . . . . . . . . . . . . . . 15 | |||
11.1. Normative References . . . . . . . . . . . . . . . . . . 15 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
11.2. Informative References . . . . . . . . . . . . . . . . . 17 | 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 | |||
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 18 | 11.2. Informative References . . . . . . . . . . . . . . . . . 18 | |||
A.1. REQUIRETLS SMTP Option . . . . . . . . . . . . . . . . . 18 | Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 19 | |||
A.2. TLS-Required Header Field . . . . . . . . . . . . . . . . 19 | A.1. REQUIRETLS SMTP Option . . . . . . . . . . . . . . . . . 19 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 | 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 | |||
skipping to change at page 7, line 7 ¶ | skipping to change at page 7, line 7 ¶ | |||
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 RFC 8461 [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. | [RFC6125] or [RFC7672] as applicable. The hostname from the MX | |||
record lookup (or the domain name in the absence of an MX record | ||||
where an A record is used directly) MUST match the DNS-ID or CN- | ||||
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 | |||
skipping to change at page 8, line 18 ¶ | skipping to change at page 8, line 23 ¶ | |||
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 to | |||
SMTP servers not supporting REQUIRETLS, that option will not be | 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 | An MUA or other agent making the initial introduction of a message | |||
has authority to decide whether to require TLS. When TLS is to be | has the option to decide whether to require TLS. If TLS is to be | |||
required, it MUST do so by negotiating STARTTLS and REQUIRETLS and | required, it MUST do so by negotiating STARTTLS and REQUIRETLS and | |||
include the REQUIRETLS option on the MAIL FROM command, as is done | include the REQUIRETLS option on the MAIL FROM command, as is done | |||
for message relay. | 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 | |||
skipping to change at page 12, line 19 ¶ | skipping to change at page 12, line 24 ¶ | |||
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 [RFC5751]. | 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 availability of TLS, the use | |||
of "TLS-Required: No" header field represents an explicit decision on | of "TLS-Required: No" header field represents an explicit decision on | |||
the part of the sender not to require the use of TLS, such as to | the part of the sender not to require the use of TLS, such as to | |||
overcome a configuration error. The recipient domain has the | overcome a configuration error. The recipient domain has the | |||
skipping to change at page 12, line 47 ¶ | skipping to change at page 13, line 9 ¶ | |||
The author would like to acknowledge many helpful suggestions on the | The author would like to acknowledge many helpful suggestions on the | |||
ietf-smtp and uta mailing lists, in particular those of Viktor | ietf-smtp and uta mailing lists, in particular those of Viktor | |||
Dukhovni, Chris Newman, Tony Finch, Jeremy Harris, Arvel Hathcock, | Dukhovni, Chris Newman, Tony Finch, Jeremy Harris, Arvel Hathcock, | |||
John Klensin, Barry Leiba, John Levine, Rolf Sonneveld, and Per | John Klensin, Barry Leiba, John Levine, Rolf Sonneveld, and Per | |||
Thorsheim. | Thorsheim. | |||
10. Revision History | 10. Revision History | |||
To be removed by RFC Editor upon publication as an RFC. | To be removed by RFC Editor upon publication as an RFC. | |||
10.1. Changes since -07 Draft | 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: | 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 Change associated status code for 5.7.YYY from 530 to 550. | |||
o Correct textual name of extension in IANA Considerations for | o Correct textual name of extension in IANA Considerations for | |||
consistency with the rest of the document. | consistency with the rest of the document. | |||
o Remove special handling of bounce messages in Section 4.1. | o Remove special handling of bounce messages in Section 4.1. | |||
skipping to change at page 13, line 21 ¶ | skipping to change at page 13, line 44 ¶ | |||
make capitalization of parameter consistent. | make capitalization of parameter consistent. | |||
o Remove mention of transforming RET=FULL to RET=HDRS on relay in | o Remove mention of transforming RET=FULL to RET=HDRS on relay in | |||
Section 5. | Section 5. | |||
o Replace Section 6 dealing with mailing lists with a more general | o Replace Section 6 dealing with mailing lists with a more general | |||
section on reorigination by mediators. | section on reorigination by mediators. | |||
o Add security considerations section on policy conflicts. | o Add security considerations section on policy conflicts. | |||
10.2. Changes since -06 Draft | 10.3. Changes since -06 Draft | |||
Various changes in response to AD review: | Various changes in response to AD review: | |||
o Reference RFC 7525 for TLS negotiation recommendations. | o Reference RFC 7525 for TLS negotiation recommendations. | |||
o Make reference to requested 5.7.YYY error code consistent. | o Make reference to requested 5.7.YYY error code consistent. | |||
o Clarify applicability to LMTP and submission. | o Clarify applicability to LMTP and submission. | |||
o Provide ABNF for syntax of SMTP option and header field and | o Provide ABNF for syntax of SMTP option and header field and | |||
examples in Appendix A. | examples in Appendix A. | |||
o Correct use of normative language in Section 5. | o Correct use of normative language in Section 5. | |||
o Clarify case where REQUIRETLS option is used on bounce messages. | o Clarify case where REQUIRETLS option is used on bounce messages. | |||
o Improve Security Requirements wording to be incusive of both SMTP | o Improve Security Requirements wording to be inclusive of both SMTP | |||
option and header field. | option and header field. | |||
10.3. Changes since -05 Draft | 10.4. Changes since -05 Draft | |||
Corrected IANA Permanent Message Header Fields Registry request. | Corrected IANA Permanent Message Header Fields Registry request. | |||
10.4. Changes since -04 Draft | 10.5. Changes since -04 Draft | |||
Require validation of SMTP server hostname via DNSSEC or MTA-STS | Require validation of SMTP server hostname via DNSSEC or MTA-STS | |||
policy when TLS is required. | policy when TLS is required. | |||
10.5. Changes since -03 Draft | 10.6. Changes since -03 Draft | |||
Working Group Last Call changes, including: | Working Group Last Call changes, including: | |||
o Correct reference for SMTP DANE | o Correct reference for SMTP DANE | |||
o Clarify that RequireTLS: NO applies to both MTA-STS and DANE | o Clarify that RequireTLS: NO applies to both MTA-STS and DANE | |||
policies | policies | |||
o Correct newly-defined status codes | o Correct newly-defined status codes | |||
o Update MTA-STS references to RFC | o Update MTA-STS references to RFC | |||
10.6. Changes since -02 Draft | 10.7. Changes since -02 Draft | |||
o More complete documentation for IANA registration requests. | o More complete documentation for IANA registration requests. | |||
o Changed bounce handling to use RET parameters of [RFC3461], along | o Changed bounce handling to use RET parameters of [RFC3461], along | |||
with slightly more liberal transmission of bounces even if | with slightly more liberal transmission of bounces even if | |||
REQUIRETLS can't be negotiated. | REQUIRETLS can't be negotiated. | |||
10.7. Changes since -01 Draft | 10.8. Changes since -01 Draft | |||
o Converted DEEP references to RFC 8314. | o Converted DEEP references to RFC 8314. | |||
o Removed REQUIRETLS options: CHAIN, DANE, and DNSSEC. | o Removed REQUIRETLS options: CHAIN, DANE, and DNSSEC. | |||
o Editorial corrections, notably making the header field name | o Editorial corrections, notably making the header field name | |||
consistent (RequireTLS rather than Require-TLS). | consistent (RequireTLS rather than Require-TLS). | |||
10.8. Changes since -00 Draft | 10.9. Changes since -00 Draft | |||
o Created new header field, Require-TLS, for use by "NO" option. | o Created new header field, Require-TLS, for use by "NO" option. | |||
o Removed "NO" option from SMTP service extension. | o Removed "NO" option from SMTP service extension. | |||
o Recommend DEEP requirements for delivery of messages requiring | o Recommend DEEP requirements for delivery of messages requiring | |||
TLS. | TLS. | |||
o Assorted copy edits | o Assorted copy edits | |||
10.9. Changes since fenton-03 Draft | 10.10. Changes since fenton-03 Draft | |||
o Wording improvements from Rolf Sonneveld review 22 July 2017 | o Wording improvements from Rolf Sonneveld review 22 July 2017 | |||
o A few copy edits | o A few copy edits | |||
o Conversion from individual to UTA WG draft | o Conversion from individual to UTA WG draft | |||
10.10. Changes Since -02 Draft | 10.11. Changes Since -02 Draft | |||
o Incorporation of "MAY TLS" functionality as REQUIRETLS=NO per | o Incorporation of "MAY TLS" functionality as REQUIRETLS=NO per | |||
suggestion on UTA WG mailing list. | suggestion on UTA WG mailing list. | |||
o Additional guidance on bounce messages | o Additional guidance on bounce messages | |||
10.11. Changes Since -01 Draft | 10.12. Changes Since -01 Draft | |||
o Specified retries when multiple MX hosts exist for a given domain. | o Specified retries when multiple MX hosts exist for a given domain. | |||
o Clarified generation of non-delivery messages | o Clarified generation of non-delivery messages | |||
o Specified requirements for application of REQUIRETLS to mail | o Specified requirements for application of REQUIRETLS to mail | |||
forwarders and mailing lists. | forwarders and mailing lists. | |||
o Clarified DNSSEC requirements to include MX lookup only. | o Clarified DNSSEC requirements to include MX lookup only. | |||
o Corrected terminology regarding message retrieval vs. delivery. | o Corrected terminology regarding message retrieval vs. delivery. | |||
o Changed category to standards track. | o Changed category to standards track. | |||
10.12. Changes Since -00 Draft | 10.13. Changes Since -00 Draft | |||
o Conversion of REQUIRETLS from an SMTP verb to a MAIL FROM | o Conversion of REQUIRETLS from an SMTP verb to a MAIL FROM | |||
parameter to better associate REQUIRETLS requirements with | parameter to better associate REQUIRETLS requirements with | |||
transmission of individual messages. | transmission of individual messages. | |||
o Addition of an option to require DNSSEC lookup of the remote mail | o Addition of an option to require DNSSEC lookup of the remote mail | |||
server, since this affects the common name of the certificate that | server, since this affects the common name of the certificate that | |||
is presented. | is presented. | |||
o Clarified the wording to more clearly state that TLS sessions must | o Clarified the wording to more clearly state that TLS sessions must | |||
skipping to change at page 18, line 26 ¶ | skipping to change at page 19, line 5 ¶ | |||
<https://www.rfc-editor.org/info/rfc4880>. | <https://www.rfc-editor.org/info/rfc4880>. | |||
[RFC5228] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email | [RFC5228] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email | |||
Filtering Language", RFC 5228, DOI 10.17487/RFC5228, | Filtering Language", RFC 5228, DOI 10.17487/RFC5228, | |||
January 2008, <https://www.rfc-editor.org/info/rfc5228>. | January 2008, <https://www.rfc-editor.org/info/rfc5228>. | |||
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, | [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, | |||
DOI 10.17487/RFC5598, July 2009, | DOI 10.17487/RFC5598, July 2009, | |||
<https://www.rfc-editor.org/info/rfc5598>. | <https://www.rfc-editor.org/info/rfc5598>. | |||
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet | ||||
Mail Extensions (S/MIME) Version 3.2 Message | ||||
Specification", RFC 5751, DOI 10.17487/RFC5751, January | ||||
2010, <https://www.rfc-editor.org/info/rfc5751>. | ||||
[RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", | [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", | |||
STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, | STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, | |||
<https://www.rfc-editor.org/info/rfc6409>. | <https://www.rfc-editor.org/info/rfc6409>. | |||
[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ | ||||
Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 | ||||
Message Specification", RFC 8551, DOI 10.17487/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 intent of the | |||
sender that the associated message be relayed using TLS. In the | sender that the associated message be 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 | |||
skipping to change at page 19, line 41 ¶ | skipping to change at page 20, line 41 ¶ | |||
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 of the message | The TLS-Required header field is used when the sender requests that | |||
wants to override the default policy of the recipient domain to | the mail system not heed a default policy of the recipient domain | |||
require 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: | |||
From: Roger Reporter <roger@example.org> | From: Roger Reporter <roger@example.org> | |||
To: Andy Admin <admin@example.com> | To: Andy Admin <admin@example.com> | |||
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 | |||
End of changes. 23 change blocks. | ||||
48 lines changed or deleted | 65 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/ |