draft-ietf-uta-smtp-tlsrpt-13.txt   draft-ietf-uta-smtp-tlsrpt-14.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: June 7, 2018 Comcast, Inc Expires: July 30, 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
December 4, 2017 January 26, 2018
SMTP TLS Reporting SMTP TLS Reporting
draft-ietf-uta-smtp-tlsrpt-13 draft-ietf-uta-smtp-tlsrpt-14
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, DANE TLSA, and between SMTP Mail Transfer Agents, including STARTTLS, DANE TLSA, and
MTA-STS. These protocols can fail due to misconfiguration or active MTA-STS. These protocols can fail due to misconfiguration or active
attack, leading to undelivered messages or delivery over unencrypted attack, leading to undelivered messages or delivery over unencrypted
or unauthenticated channels. This document describes a reporting or unauthenticated channels. This document describes a reporting
mechanism and format by which sending systems can share statistics mechanism and format by which sending systems can share statistics
and specific information about potential failures with recipient and specific information about potential failures with recipient
skipping to change at page 1, line 39 skipping to change at page 1, line 39
misconfigurations. misconfigurations.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 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 June 7, 2018. This Internet-Draft will expire on July 30, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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 (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
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
skipping to change at page 2, line 45 skipping to change at page 2, line 45
4.3.1. Negotiation Failures . . . . . . . . . . . . . . . . 8 4.3.1. Negotiation Failures . . . . . . . . . . . . . . . . 8
4.3.2. Policy Failures . . . . . . . . . . . . . . . . . . . 8 4.3.2. Policy Failures . . . . . . . . . . . . . . . . . . . 8
4.3.3. General Failures . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . . . 12 5. Report Delivery . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 12 5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 12
5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 13
5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 13 5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 13
5.3.1. Example Report . . . . . . . . . . . . . . . . . . . 15 5.3.1. Example Report . . . . . . . . . . . . . . . . . . . 15
5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 16 5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 15
5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 16 5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 16
5.6. Metadata Variances . . . . . . . . . . . . . . . . . . . 16 5.6. Metadata Variances . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6.1. Message headers . . . . . . . . . . . . . . . . . . . . . 16 6.1. Message headers . . . . . . . . . . . . . . . . . . . . . 16
6.2. Report Type . . . . . . . . . . . . . . . . . . . . . . . 17 6.2. Report Type . . . . . . . . . . . . . . . . . . . . . . . 17
6.3. application/tlsrpt+json Media Type . . . . . . . . . . . 17 6.3. application/tlsrpt+json Media Type . . . . . . . . . . . 17
6.4. application/tlsrpt+gzip Media Type . . . . . . . . . . . 18 6.4. application/tlsrpt+gzip Media Type . . . . . . . . . . . 18
6.5. STARTTLS Validation Result Types . . . . . . . . . . . . 19 6.5. STARTTLS Validation Result Types . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
skipping to change at page 8, line 46 skipping to change at page 8, line 46
4.3.2. Policy Failures 4.3.2. Policy Failures
4.3.2.1. DANE-specific Policy Failures 4.3.2.1. DANE-specific Policy Failures
o "tlsa-invalid": This indicates a validation error in the TLSA o "tlsa-invalid": This indicates a validation error in the TLSA
record associated with a DANE policy. None of the records in the record associated with a DANE policy. None of the records in the
RRset were found to be valid. RRset were found to be valid.
o "dnssec-invalid": This would indicate that no valid records were o "dnssec-invalid": This would indicate that no valid records were
returned from the recursive resolver. The request returned with returned from the recursive resolver. The request returned with
SERVFAIL for the requested TLSA record. It should be noted that SERVFAIL for the requested TLSA record.
if the reporter's systems are having problems resolving
destination DNS records due to DNSSEC failures, it's possible they o "dane-required": This indicates that the sending system is
will also be unable to resolve the TLSRPT record, therefore these configured to require DANE TLSA records for all the MX hosts of
types of reports may be rare. the destination domain, but no DNSSEC-validated TLSA records were
present for the MX host that is the subject of the report.
Mandatory DANE for SMTP is described in section 6 of [RFC7672].
Such policies may be created by mutual agreement between two
organizations that frequently exchange sensitive content via
email.
4.3.2.2. MTA-STS-specific Policy Failures 4.3.2.2. MTA-STS-specific Policy Failures
o "sts-policy-invalid": This indicates a validation error for the o "sts-policy-invalid": This indicates a validation error for the
overall MTA-STS policy. overall MTA-STS policy.
o "sts-webpki-invalid": This indicates that the MTA-STS policy could o "sts-webpki-invalid": This indicates that the MTA-STS policy could
not be authenticated using PKIX validation. not be authenticated using PKIX validation.
4.3.3. General Failures 4.3.3. General Failures
skipping to change at page 11, line 16 skipping to change at page 11, line 16
may use whatever scheme they prefer to generate a unique may use whatever scheme they prefer to generate a unique
identifier. It is provided as a string. identifier. It is provided as a string.
o "policy-type": The type of policy that was applied by the sending o "policy-type": The type of policy that was applied by the sending
domain. Presently, the only three valid choices are "tlsa", domain. Presently, the only three valid choices are "tlsa",
"sts", and the literal string "no-policy-found". It is provided "sts", and the literal string "no-policy-found". It is provided
as a string. as a string.
o "policy-string": A string representation of the policy, whether o "policy-string": A string representation of the policy, whether
TLSA record ([RFC6698] section 2.3) or MTA-STS policy. Examples: TLSA record ([RFC6698] section 2.3) or MTA-STS policy. Examples:
TLSA: ""_25._tcp.mx.example.com. IN TLSA ( 3 0 1 \ TLSA: ""_25._tcp.mx.example.com. 3 0 1 \ 1F850A337E6DB9C609C522D13
1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513D7 47D1D085D 6A475638CC43E1ED424F8EEC8513D747D1D085D)"" MTA-STS: ""version:
)"" MTA-STS: ""version: STSv1\nmode: report\nmx: STSv1\nmode: report\nmx: mx1.example.com\nmx: \
mx1.example.com\nmx: \ mx2.example.com\nmx: mx.backup- mx2.example.com\nmx: mx.backup-example.com\nmax_age: 12345678""
example.com\nmax_age: 12345678""
o "domain": The Policy Domain is the domain against which the MTA- o "domain": The Policy Domain is the domain against which the MTA-
STS or DANE policy is defined. In the case of Internationalized STS or DANE policy is defined. In the case of Internationalized
Domain Names ([RFC5891]), the domain is the Punycode-encoded Domain Names ([RFC5891]), the domain MUST consist of the Punycode-
A-label ([RFC3492]) and not the U-label. encoded A-labels ([RFC3492]) and not the U-labels.
o "mx-host-pattern": The pattern of MX hostnames from the applied o "mx-host-pattern": The pattern of MX hostnames from the applied
policy. It is provided as a string, and is interpreted in the policy. It is provided as a string, and is interpreted in the
same manner as the "Checking of Wildcard Certificates" rules in same manner as the "Checking of Wildcard Certificates" rules in
Section 6.4.3 of [RFC6125]. In the case of Internationalized Section 6.4.3 of [RFC6125]. In the case of Internationalized
Domain Names ([RFC5891]), the domain is the Punycode-encoded Domain Names ([RFC5891]), the domain MUST consist of the Punycode-
A-label ([RFC3492]) and not the U-label. encoded A-labels ([RFC3492]) and not the U-labels.
o "result-type": A value from Section 4.3, "Result Types", above. o "result-type": A value from Section 4.3, "Result Types", above.
o "ip-address": The IP address of the sending MTA that attempted the o "ip-address": The IP address of the sending MTA that attempted the
STARTTLS connection. It is provided as a string representation of STARTTLS connection. It is provided as a string representation of
an IPv4 (see below) or IPv6 ([RFC5952]) address in dot-decimal or an IPv4 (see below) or IPv6 ([RFC5952]) address in dot-decimal or
colon-hexadecimal notation. colon-hexadecimal notation.
o "receiving-mx-hostname": The hostname of the receiving MTA MX o "receiving-mx-hostname": The hostname of the receiving MTA MX
record with which the sending MTA attempted to negotiate a record with which the sending MTA attempted to negotiate a
STARTTLS connection. STARTTLS connection.
o "receiving-mx-helo": (optional) The HELO or EHLO string from the o "receiving-mx-helo": (optional) The HELO or EHLO string from the
banner announced during the reported session. banner announced during the reported session.
o "receiving-ip": The destination IP address that was using when
creating the outbound session. It is provided as a string
representation of an IPv4 (see below) or IPv6 ([RFC5952]) address
in dot-decimal or colon-hexadecimal notation.
o "total-successful-session-count": The aggregate number (integer) o "total-successful-session-count": The aggregate number (integer)
of successfully negotiated TLS-enabled connections to the of successfully negotiated TLS-enabled connections to the
receiving site. receiving site.
o "total-failure-session-count": The aggregate number (integer) of o "total-failure-session-count": The aggregate number (integer) of
failures to negotiate a TLS-enabled connection to the receiving failures to negotiate a TLS-enabled connection to the receiving
site. site.
o "failed-session-count": The number of (attempted) sessions that o "failed-session-count": The number of (attempted) sessions that
match the relevant "result-type" for this section. match the relevant "result-type" for this section.
skipping to change at page 13, line 26 skipping to change at page 13, line 26
begin-timestamp = 1*DIGIT begin-timestamp = 1*DIGIT
; seconds since 00:00:00 UTC January 1, 1970 ; seconds since 00:00:00 UTC January 1, 1970
; indicating start of the time range contained ; indicating start of the time range contained
; in the report ; in the report
end-timestamp = 1*DIGIT end-timestamp = 1*DIGIT
; seconds since 00:00:00 UTC January 1, 1970 ; seconds since 00:00:00 UTC January 1, 1970
; indicating end of the time range contained ; indicating end of the time range contained
; in the report ; in the report
extension = "json" / "json.gz" extension = "json"
The extension MUST be "json" for a plain JSON file, or "json.gz" for
a JSON file compressed using GZIP.
"unique-id" allows an optional unique ID generated by the Sending MTA "unique-id" allows an optional unique ID generated by the Sending MTA
to distinguish among multiple reports generated simultaneously by to distinguish among multiple reports generated simultaneously by
different sources within the same Policy Domain. For example, this different sources within the same Policy Domain. For example, this
is a possible filename for the gzip file of a report to the Policy is a possible filename for the gzip file of a report to the Policy
Domain "example.net" from the Sending MTA "mail.sender.example.com": Domain "example.net" from the Sending MTA "mail.sender.example.com":
"mail.sender.example.com!example.net!1470013207!1470186007!001.json.g "mail.sender.example.com!example.net!1470013207!1470186007!001.json"
z"
5.2. Compression 5.2. Compression
The report SHOULD be subjected to GZIP compression for both email and The report SHOULD be subjected to GZIP compression for both email and
HTTPS transport. Declining to apply compression can cause the report HTTPS transport. Declining to apply compression can cause the report
to be too large for a receiver to process (a commonly observed to be too large for a receiver to process (a commonly observed
receiver limit is ten megabytes); compressing the file increases the receiver limit is ten megabytes); compressing the file increases the
chances of acceptance of the report at some compute cost. chances of acceptance of the report at some compute cost.
5.3. Email Transport 5.3. Email Transport
skipping to change at page 16, line 9 skipping to change at page 16, line 4
------=_NextPart_000_024E_01CC9B0A.AFE54C00-- ------=_NextPart_000_024E_01CC9B0A.AFE54C00--
... ...
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 The report MAY be delivered by POST to HTTPS. When doing so, the
Considerations"). report should use the media-type "application/tlsrpt" (see section
Section 6, "IANA Considerations"). If the reporting entity
compresses the report, that should be noted in the Content-Type
"conversions" field:
Content-Type: application/tlsrpt; conversions=gzip Content-Type:
application/tlsrpt; conversions=none Content-Type: application/tlsrpt
The second and third items in the list are equivalent.
A reporting entity SHOULD expect a "successful" response from the A reporting entity SHOULD expect a "successful" response from the
accepting HTTPS server, typically a 200 or 201 HTTP code [RFC7231]. accepting HTTPS server, typically a 200 or 201 HTTP code [RFC7231].
Other codes could indicate a delivery failure, and may be retried as Other codes could indicate a delivery failure, and may be retried as
per local policy. The receiving system is not expected to process per local policy. The receiving system is not expected to process
reports at receipt time, and MAY store them for processing at a later reports at receipt time, and MAY store them for processing at a later
time. 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 SHOULD be done with
logarithmic scale. exponential backoff.
5.6. Metadata Variances 5.6. Metadata Variances
As stated above, there are a variable number of ways to declare As stated above, there are a variable number of ways to declare
information about the data therein. If it should be the case that information about the data therein. If any of items declared via
these objects were to disagree, then the report data contained within subject or filename disagree with the report, the report MUST be
the JSON body MUST be considered the authoritative source for those considered the authoritative source.
data elements.
6. IANA Considerations 6. IANA Considerations
The following are the IANA considerations discussed in this document. The following are the IANA considerations discussed in this document.
6.1. Message headers 6.1. Message headers
Below is the Internet Assigned Numbers Authority (IANA) Permanent Below is the Internet Assigned Numbers Authority (IANA) Permanent
Message Header Field registration information per [RFC3864]. Message Header Field registration information per [RFC3864].
skipping to change at page 21, line 21 skipping to change at page 21, line 21
a large TTL (reducing the window for successful attacks against DNS a large TTL (reducing the window for successful attacks against DNS
resolution of the record) or to deploy DNSSEC on the deploying zone. resolution of the record) or to deploy DNSSEC on the deploying zone.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-uta-mta-sts] [I-D.ietf-uta-mta-sts]
Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A., 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)", draft-ietf-uta-mta-sts-11 (work in progress), STS)", draft-ietf-uta-mta-sts-14 (work in progress),
November 2017. January 2018.
[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-
<https://www.rfc-editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[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,
<https://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,
<https://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, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://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, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc5234>. editor.org/info/rfc5234>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[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-
<https://www.rfc-editor.org/info/rfc5321>. editor.org/info/rfc5321>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-
<https://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, Applications (IDNA): Protocol", RFC 5891,
DOI 10.17487/RFC5891, August 2010, DOI 10.17487/RFC5891, August 2010, <https://www.rfc-
<https://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, Address Text Representation", RFC 5952,
DOI 10.17487/RFC5952, August 2010, DOI 10.17487/RFC5952, August 2010, <https://www.rfc-
<https://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,
<https://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
skipping to change at page 23, line 12 skipping to change at page 23, line 12
STD 73, RFC 6522, DOI 10.17487/RFC6522, January 2012, STD 73, RFC 6522, DOI 10.17487/RFC6522, January 2012,
<https://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, <https://www.rfc-editor.org/info/rfc6698>. 2012, <https://www.rfc-editor.org/info/rfc6698>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231, Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc7231>. editor.org/info/rfc7231>.
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
RFC 7405, DOI 10.17487/RFC7405, December 2014, RFC 7405, DOI 10.17487/RFC7405, December 2014,
<https://www.rfc-editor.org/info/rfc7405>. <https://www.rfc-editor.org/info/rfc7405>.
[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493,
DOI 10.17487/RFC7493, March 2015, DOI 10.17487/RFC7493, March 2015, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc7493>. editor.org/info/rfc7493>.
8.2. Informative References 8.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, <https://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,
<https://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-
<https://www.rfc-editor.org/info/rfc3864>. editor.org/info/rfc3864>.
[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, <https://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, <https://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,
<https://www.rfc-editor.org/info/rfc7489>. <https://www.rfc-editor.org/info/rfc7489>.
[RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via
Opportunistic DNS-Based Authentication of Named Entities
(DANE) Transport Layer Security (TLS)", RFC 7672,
DOI 10.17487/RFC7672, October 2015, <https://www.rfc-
editor.org/info/rfc7672>.
Appendix A. Example Reporting Policy Appendix A. Example Reporting Policy
A.1. Report using MAILTO A.1. Report using MAILTO
_smtp-tlsrpt.mail.example.com. IN TXT \ _smtp-tlsrpt.mail.example.com. IN TXT \
"v=TLSRPTv1;rua=mailto:reports@example.com" "v=TLSRPTv1;rua=mailto:reports@example.com"
A.2. Report using HTTPS A.2. Report using HTTPS
_smtp-tlsrpt.mail.example.com. IN TXT \ _smtp-tlsrpt.mail.example.com. IN TXT \
skipping to change at page 25, line 33 skipping to change at page 25, line 33
}, },
"failure-details": [{ "failure-details": [{
"result-type": "certificate-expired", "result-type": "certificate-expired",
"sending-mta-ip": "98.136.216.25", "sending-mta-ip": "98.136.216.25",
"receiving-mx-hostname": "mx1.mail.company-y.example", "receiving-mx-hostname": "mx1.mail.company-y.example",
"failed-session-count": 100 "failed-session-count": 100
}, { }, {
"result-type": "starttls-not-supported", "result-type": "starttls-not-supported",
"sending-mta-ip": "98.22.33.99", "sending-mta-ip": "98.22.33.99",
"receiving-mx-hostname": "mx2.mail.company-y.example", "receiving-mx-hostname": "mx2.mail.company-y.example",
"receiving-ip": "192.168.14.72",
"failed-session-count": 200, "failed-session-count": 200,
"additional-information": "https://reports.company-x.example/ "additional-information": "https://reports.company-x.example/
report_info ? id = 5065427 c - 23 d3# StarttlsNotSupported " report_info ? id = 5065427 c - 23 d3# StarttlsNotSupported "
}, { }, {
"result-type": "validation-failure", "result-type": "validation-failure",
"sending-mta-ip": "47.97.15.2", "sending-mta-ip": "47.97.15.2",
"receiving-ip": "10.72.84.12",
"receiving-mx-hostname": "mx-backup.mail.company-y.example", "receiving-mx-hostname": "mx-backup.mail.company-y.example",
"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 Company- Figure: Example JSON report for a messages from Company-X to Company-
Y, where 100 sessions were attempted to Company Y servers with an Y, where 100 sessions were attempted to Company Y servers with an
expired certificate and 200 sessions were attempted to Company Y expired certificate and 200 sessions were attempted to Company Y
skipping to change at page 26, line 4 skipping to change at page 26, line 5
"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 Company- Figure: Example JSON report for a messages from Company-X to Company-
Y, where 100 sessions were attempted to Company Y servers with an Y, where 100 sessions were attempted to Company Y servers with an
expired certificate and 200 sessions were attempted to Company Y expired certificate and 200 sessions were attempted to Company Y
servers that did not successfully respond to the "STARTTLS" command. servers that did not successfully respond to the "STARTTLS" 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".
Authors' Addresses Authors' Addresses
Daniel Margolis Daniel Margolis
Google, Inc Google, Inc
Email: dmargolis (at) google (dot com) Email: dmargolis@google.com
Alexander Brotman Alexander Brotman
Comcast, Inc Comcast, Inc
Email: alex_brotman (at) comcast (dot com) Email: alex_brotman@comcast.com
Binu Ramakrishnan Binu Ramakrishnan
Yahoo!, Inc Yahoo!, Inc
Email: rbinu (at) yahoo-inc (dot com) Email: rbinu@oath.com
Janet Jones Janet Jones
Microsoft, Inc Microsoft, Inc
Email: janet.jones (at) microsoft (dot com) Email: janet.jones@microsoft.com
Mark Risher Mark Risher
Google, Inc Google, Inc
Email: risher (at) google (dot com) Email: risher@google.com
 End of changes. 37 change blocks. 
61 lines changed or deleted 81 lines changed or added

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