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/