draft-ietf-uta-smtp-tlsrpt-08.txt   draft-ietf-uta-smtp-tlsrpt-09.txt 
Using TLS in Applications D. Margolis Using TLS in Applications D. Margolis
Internet-Draft Google, Inc Internet-Draft Google, Inc
Intended status: Standards Track A. Brotman Intended status: Standards Track A. Brotman
Expires: February 16, 2018 Comcast, Inc Expires: March 9, 2018 Comcast, Inc
B. Ramakrishnan B. Ramakrishnan
Yahoo!, Inc Yahoo!, Inc
J. Jones J. Jones
Microsoft, Inc Microsoft, Inc
M. Risher M. Risher
Google, Inc Google, Inc
August 15, 2017 September 5, 2017
SMTP TLS Reporting SMTP TLS Reporting
draft-ietf-uta-smtp-tlsrpt-08 draft-ietf-uta-smtp-tlsrpt-09
Abstract Abstract
A number of protocols exist for establishing encrypted channels A number of protocols exist for establishing encrypted channels
between SMTP Mail Transfer Agents, including STARTTLS [RFC3207], DANE between SMTP Mail Transfer Agents, including STARTTLS [RFC3207], DANE
[RFC6698], and MTA-STS (TODO: Add ref). These protocols can fail due [RFC6698], and MTA-STS (TODO: Add ref). These protocols can fail due
to misconfiguration or active attack, leading to undelivered messages to misconfiguration or active attack, leading to undelivered messages
or delivery over unencrypted or unauthenticated channels. This or delivery over unencrypted or unauthenticated channels. This
document describes a reporting mechanism and format by which sending document describes a reporting mechanism and format by which sending
systems can share statistics and specific information about potential systems can share statistics and specific information about potential
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 February 16, 2018. This Internet-Draft will expire on March 9, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 37 skipping to change at page 2, line 37
3.1.1. Report using MAILTO . . . . . . . . . . . . . . . . . 6 3.1.1. Report using MAILTO . . . . . . . . . . . . . . . . . 6
3.1.2. Report using HTTPS . . . . . . . . . . . . . . . . . 6 3.1.2. Report using HTTPS . . . . . . . . . . . . . . . . . 6
4. Reporting Schema . . . . . . . . . . . . . . . . . . . . . . 6 4. Reporting Schema . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Report Time-frame . . . . . . . . . . . . . . . . . . . . 7 4.1. Report Time-frame . . . . . . . . . . . . . . . . . . . . 7
4.2. Delivery Summary . . . . . . . . . . . . . . . . . . . . 7 4.2. Delivery Summary . . . . . . . . . . . . . . . . . . . . 7
4.2.1. Success Count . . . . . . . . . . . . . . . . . . . . 7 4.2.1. Success Count . . . . . . . . . . . . . . . . . . . . 7
4.2.2. Failure Count . . . . . . . . . . . . . . . . . . . . 7 4.2.2. Failure Count . . . . . . . . . . . . . . . . . . . . 7
4.3. Result Types . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Result Types . . . . . . . . . . . . . . . . . . . . . . 7
4.3.1. Negotiation Failures . . . . . . . . . . . . . . . . 7 4.3.1. Negotiation Failures . . . . . . . . . . . . . . . . 7
4.3.2. Policy Failures . . . . . . . . . . . . . . . . . . . 8 4.3.2. Policy Failures . . . . . . . . . . . . . . . . . . . 8
4.3.3. General Failures . . . . . . . . . . . . . . . . . . 8 4.3.3. General Failures . . . . . . . . . . . . . . . . . . 9
4.3.4. Transient Failures . . . . . . . . . . . . . . . . . 9 4.3.4. Transient Failures . . . . . . . . . . . . . . . . . 9
4.4. JSON Report Schema . . . . . . . . . . . . . . . . . . . 9 4.4. JSON Report Schema . . . . . . . . . . . . . . . . . . . 9
5. Report Delivery . . . . . . . . . . . . . . . . . . . . . . . 11 5. Report Delivery . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 11 5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 12
5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 12 5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 13
5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 12 5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 13
5.3.1. Example Report . . . . . . . . . . . . . . . . . . . 14 5.3.1. Example Report . . . . . . . . . . . . . . . . . . . 14
5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 14 5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 15
5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 15 5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 16
5.6. Metadata Variances . . . . . . . . . . . . . . . . . . . 15 5.6. Metadata Variances . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6.1. Message headers . . . . . . . . . . . . . . . . . . . . . 15 6.1. Message headers . . . . . . . . . . . . . . . . . . . . . 16
6.2. Report Type . . . . . . . . . . . . . . . . . . . . . . . 15 6.2. Report Type . . . . . . . . . . . . . . . . . . . . . . . 16
6.3. application/tlsrpt+json Media Type . . . . . . . . . . . 16 6.3. application/tlsrpt+json Media Type . . . . . . . . . . . 17
6.4. application/tlsrpt+gzip Media Type . . . . . . . . . . . 17 6.4. application/tlsrpt+gzip Media Type . . . . . . . . . . . 18
6.5. STARTTLS Validation Result Types . . . . . . . . . . . . 18 6.5. STARTTLS Validation Result Types . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. Appendix 1: Example Reporting Policy . . . . . . . . . . . . 19 8. Appendix 1: Example Reporting Policy . . . . . . . . . . . . 20
8.1. Report using MAILTO . . . . . . . . . . . . . . . . . . . 19 8.1. Report using MAILTO . . . . . . . . . . . . . . . . . . . 20
8.2. Report using HTTPS . . . . . . . . . . . . . . . . . . . 19 8.2. Report using HTTPS . . . . . . . . . . . . . . . . . . . 20
9. Appendix 2: Example JSON Report . . . . . . . . . . . . . . . 19 9. Appendix 2: Example JSON Report . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . 21 10.1. Normative References . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . 22 10.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and
hosts to establish secure SMTP sessions over TLS. The protocol hosts to establish secure SMTP sessions over TLS. The protocol
design is based on "Opportunistic Security" (OS) [RFC7435], which design is based on "Opportunistic Security" (OS) [RFC7435], which
maintains interoperability with clients that do not support STARTTLS maintains interoperability with clients that do not support STARTTLS
but means that any attacker who can delete parts of the SMTP session but means that any attacker who can delete parts of the SMTP session
(such as the "250 STARTTLS" response) or redirect the entire SMTP (such as the "250 STARTTLS" response) or redirect the entire SMTP
session (perhaps by overwriting the resolved MX record of the session (perhaps by overwriting the resolved MX record of the
skipping to change at page 5, line 20 skipping to change at page 5, line 20
specified email address ([RFC6068]). When sending failure reports specified email address ([RFC6068]). When sending failure reports
via SMTP, sending MTAs MUST deliver reports despite any TLS- via SMTP, sending MTAs MUST deliver reports despite any TLS-
related failures. This may mean that the reports are delivered in related failures. This may mean that the reports are delivered in
the clear. Additionally, reports sent via SMTP MUST contain a the clear. Additionally, reports sent via SMTP MUST contain a
valid DKIM [RFC6376] signature by the reporting domain. Reports valid DKIM [RFC6376] signature by the reporting domain. Reports
lacking such a signature MUST be ignored by the recipient. lacking such a signature MUST be ignored by the recipient.
The formal definition of the "_smtp-tlsrpt" TXT record, defined using The formal definition of the "_smtp-tlsrpt" TXT record, defined using
[RFC5234], is as follows: [RFC5234], is as follows:
tlsrpt-record = tlsrpt-version *WSP field-delim *WSP tlsrpt-rua tlsrpt-record = tlsrpt-version 1*(field-delim tlsrpt-field)
[field-delim [tlsrpt-extensions]] [field-delim]
field-delim = %x3B ; ";" field-delim = *WSP ";" *WSP
tlsrpt-version = %x76 *WSP "=" *WSP %x54 %x4C %x53 %x52 tlsrpt-field = tlsrpt-rua / ; Note that the tlsrpt-rua
%x50 %x54 %x76 %x31 ; "v=TLSRPTv1" tlsrpt-extension ; record is required.
tlsrpt-rua = %x72 %x75 %x61 *WSP "=" *WSP tlsrpt-version = %s"v=TLSRPTv1"
tlsrpt-uri *(*WSP "," *WSP tlsrpt-uri) ; "rua=..."
tlsrpt-rua = %s"rua="
tlsrpt-uri *(*WSP "," *WSP tlsrpt-uri)
tlsrpt-uri = URI tlsrpt-uri = URI
; "URI" is imported from [@!RFC3986]; commas (ASCII ; "URI" is imported from [@!RFC3986]; commas (ASCII
; 0x2C) and exclamation points (ASCII 0x21) ; 0x2C) and exclamation points (ASCII 0x21)
; MUST be encoded; the numeric portion MUST fit ; MUST be encoded
; within an unsigned 64-bit integer
tlsrpt-extensions = tlsrpt-extension *(field-delim tlsrpt-extension)
[field-delim]
; extension fields
tlsrpt-extension = tlsrpt-ext-name *WSP "=" *WSP tlsrpt-ext-value tlsrpt-extension = tlsrpt-ext-name "=" tlsrpt-ext-value
tlsrpt-ext-name = (ALPHA / DIGIT) *31(ALPHA / DIGIT / "_" / "-" / ".") tlsrpt-ext-name = (ALPHA / DIGIT) *31(ALPHA / DIGIT / "_" / "-" / ".")
tlsrpt-ext-value = 1*(%x21-3A / %x3C / %x3E-7E) ; chars excluding tlsrpt-ext-value = 1*(%x21-3A / %x3C / %x3E-7E) ; chars excluding
; "=", ";", SP, and ; "=", ";", SP, and
; control chars ; control chars
If multiple TXT records for "_smtp-tlsrpt" are returned by the If multiple TXT records for "_smtp-tlsrpt" are returned by the
resolver, records which do not begin with "v=TLSRPTv1;" are resolver, records which do not begin with "v=TLSRPTv1;" are
discarded. If the number of resulting records is not one, senders discarded. If the number of resulting records is not one, senders
MUST assume the recipient domain does not implement TLSRPT. Parsers MUST assume the recipient domain does not implement TLSRPT. If the
MUST accept TXT records which are syntactically valid (i.e. valid resulting TXT record contains multiple strings, then the record MUST
key-value pairs seprated by semi-colons) and implementing a superset be treated as if those strings are concatenated together without
of this specification, in which case unknown fields SHALL be ignored. adding spaces.
Parsers MUST accept TXT records which are syntactically valid (i.e.
valid key-value pairs separated by semi-colons) and implementing a
superset of this specification, in which case unknown fields SHALL be
ignored.
3.1. Example Reporting Policy 3.1. Example Reporting Policy
3.1.1. Report using MAILTO 3.1.1. Report using MAILTO
_smtp-tlsrpt.example.com. IN TXT \ _smtp-tlsrpt.example.com. IN TXT \
"v=TLSRPTv1;rua=mailto:reports@example.com" "v=TLSRPTv1;rua=mailto:reports@example.com"
3.1.2. Report using HTTPS 3.1.2. Report using HTTPS
_smtp-tlsrpt.example.com. IN TXT \ _smtp-tlsrpt.example.com. IN TXT \
"v=TLSRPTv1; \ "v=TLSRPTv1; \
rua=https://reporting.example.com/v1/tlsrpt" rua=https://reporting.example.com/v1/tlsrpt"
4. Reporting Schema 4. Reporting Schema
The report is composed as a plain text file encoded in the I-JSON The report is composed as a plain text file encoded in the I-JSON
format ([RFC7493]). format ([RFC7493]).
Aggregate reports contain the following fields: Aggregate reports contain the following fields:
o Report metadata: o Report metadata:
skipping to change at page 15, line 5 skipping to change at page 15, line 47
Note that, when sending failure reports via SMTP, sending MTAs MUST Note that, when sending failure reports via SMTP, sending MTAs MUST
NOT honor MTA-STS or DANE TLSA failures. NOT honor MTA-STS or DANE TLSA failures.
5.4. HTTPS Transport 5.4. HTTPS Transport
The report MAY be delivered by POST to HTTPS. If compressed, the The report MAY be delivered by POST to HTTPS. If compressed, the
report SHOULD use the media type "application/tlsrpt+gzip", and report SHOULD use the media type "application/tlsrpt+gzip", and
"application/tlsrpt+json" otherwise (see section Section 6, "IANA "application/tlsrpt+json" otherwise (see section Section 6, "IANA
Considerations"). Considerations").
A reporting entity SHOULD expect a "successful" response from the
accepting HTTPS server, typically a 200 or 201 HTTP code [RFC7231].
Other codes could indicate a delivery failure, and may be retried as
per local policy. The receiving system is not expected to process
reports at receipt time, and MAY store them for processing at a later
time.
5.5. Delivery Retry 5.5. Delivery Retry
In the event of a delivery failure, regardless of the delivery In the event of a delivery failure, regardless of the delivery
method, a sender SHOULD attempt redelivery for up to 24hrs after the method, a sender SHOULD attempt redelivery for up to 24hrs after the
initial attempt. As previously stated the reports are optional, so initial attempt. As previously stated the reports are optional, so
while it is ideal to attempt redelivery, it is not required. If while it is ideal to attempt redelivery, it is not required. If
multiple retries are attempted, ideally they would be on a multiple retries are attempted, ideally they would be on a
logarithmic scale. logarithmic scale.
5.6. Metadata Variances 5.6. Metadata Variances
skipping to change at page 20, line 43 skipping to change at page 21, line 43
report_info?id=5065427c-23d3#StarttlsNotSupported" report_info?id=5065427c-23d3#StarttlsNotSupported"
}, { }, {
"result-type": "validation-failure", "result-type": "validation-failure",
"sending-mta-ip": "47.97.15.2", "sending-mta-ip": "47.97.15.2",
"receiving-mx-hostname": "mx-backup.mail.company-y.com", "receiving-mx-hostname": "mx-backup.mail.company-y.com",
"failed-session-count": 3, "failed-session-count": 3,
"failure-error-code": "X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED" "failure-error-code": "X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED"
}] }]
} }
Figure: Example JSON report for a messages from Company-X to Figure: Example JSON report for a messages from Company-X to Company-
Company-Y, where 100 sessions were attempted to Company Y servers Y, where 100 sessions were attempted to Company Y servers with an
with an expired certificate and 200 sessions were attempted to expired certificate and 200 sessions were attempted to Company Y
Company Y servers that did not successfully respond to the "STARTTLS" servers that did not successfully respond to the "STARTTLS" command.
command. Additionally 3 sessions failed due to Additionally 3 sessions failed due to
"X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED". "X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED".
10. References 10. References
10.1. Normative References 10.1. Normative References
[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, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/ [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
RFC2818, May 2000, DOI 10.17487/RFC2818, May 2000, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc2818>. editor.org/info/rfc2818>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<http://www.rfc-editor.org/info/rfc3339>. <https://www.rfc-editor.org/info/rfc3339>.
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
for Internationalized Domain Names in Applications for Internationalized Domain Names in Applications
(IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003, (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003,
<http://www.rfc-editor.org/info/rfc3492>. <https://www.rfc-editor.org/info/rfc3492>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC Resource Identifier (URI): Generic Syntax", STD 66,
3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ Specifications: ABNF", STD 68, RFC 5234,
RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc5234>. editor.org/info/rfc5234>.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
DOI 10.17487/RFC5321, October 2008, DOI 10.17487/RFC5321, October 2008, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc5321>. editor.org/info/rfc5321>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
10.17487/RFC5322, October 2008, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc5322>. editor.org/info/rfc5322>.
[RFC5891] Klensin, J., "Internationalized Domain Names in [RFC5891] Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/ Applications (IDNA): Protocol", RFC 5891,
RFC5891, August 2010, DOI 10.17487/RFC5891, August 2010, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc5891>. editor.org/info/rfc5891>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, DOI 10.17487/ Address Text Representation", RFC 5952,
RFC5952, August 2010, DOI 10.17487/RFC5952, August 2010, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc5952>. editor.org/info/rfc5952>.
[RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto' [RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010, URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010,
<http://www.rfc-editor.org/info/rfc6068>. <https://www.rfc-editor.org/info/rfc6068>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <http://www.rfc-editor.org/info/rfc6125>. 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76, "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011, RFC 6376, DOI 10.17487/RFC6376, September 2011,
<http://www.rfc-editor.org/info/rfc6376>. <https://www.rfc-editor.org/info/rfc6376>.
[RFC6522] Kucherawy, M., Ed., "The Multipart/Report Media Type for [RFC6522] Kucherawy, M., Ed., "The Multipart/Report Media Type for
the Reporting of Mail System Administrative Messages", STD the Reporting of Mail System Administrative Messages",
73, RFC 6522, DOI 10.17487/RFC6522, January 2012, STD 73, RFC 6522, DOI 10.17487/RFC6522, January 2012,
<http://www.rfc-editor.org/info/rfc6522>. <https://www.rfc-editor.org/info/rfc6522>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS) of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <http://www.rfc-editor.org/info/rfc6698>. 2012, <https://www.rfc-editor.org/info/rfc6698>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <http://www.rfc-editor.org/info/rfc7159>. 2014, <https://www.rfc-editor.org/info/rfc7159>.
[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493,
10.17487/RFC7493, March 2015, DOI 10.17487/RFC7493, March 2015, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc7493>. editor.org/info/rfc7493>.
10.2. Informative References 10.2. Informative References
[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, <http://www.rfc-editor.org/info/rfc3207>. February 2002, <https://www.rfc-editor.org/info/rfc3207>.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
<http://www.rfc-editor.org/info/rfc3501>. <https://www.rfc-editor.org/info/rfc3501>.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
DOI 10.17487/RFC3864, September 2004, DOI 10.17487/RFC3864, September 2004, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc3864>. editor.org/info/rfc3864>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014, <https://www.rfc-
editor.org/info/rfc7231>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, DOI 10.17487/RFC7435, Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
December 2014, <http://www.rfc-editor.org/info/rfc7435>. December 2014, <https://www.rfc-editor.org/info/rfc7435>.
[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April
2015, <http://www.rfc-editor.org/info/rfc7469>. 2015, <https://www.rfc-editor.org/info/rfc7469>.
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
Message Authentication, Reporting, and Conformance Message Authentication, Reporting, and Conformance
(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
<http://www.rfc-editor.org/info/rfc7489>. <https://www.rfc-editor.org/info/rfc7489>.
Authors' Addresses Authors' Addresses
Daniel Margolis Daniel Margolis
Google, Inc Google, Inc
Email: dmargolis (at) google.com Email: dmargolis (at) google.com
Alexander Brotman Alexander Brotman
Comcast, Inc Comcast, Inc
 End of changes. 41 change blocks. 
98 lines changed or deleted 112 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/