draft-ietf-uta-smtp-tlsrpt-10.txt   draft-ietf-uta-smtp-tlsrpt-11.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: April 1, 2018 Comcast, Inc Expires: May 12, 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
September 28, 2017 November 8, 2017
SMTP TLS Reporting SMTP TLS Reporting
draft-ietf-uta-smtp-tlsrpt-10 draft-ietf-uta-smtp-tlsrpt-11
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, DANE TLSA, and
[RFC6698], and MTA-STS (TODO: Add ref). These protocols can fail due MTA-STS. These protocols can fail due to misconfiguration or active
to misconfiguration or active attack, leading to undelivered messages attack, leading to undelivered messages or delivery over unencrypted
or delivery over unencrypted or unauthenticated channels. This or unauthenticated channels. This document describes a reporting
document describes a reporting mechanism and format by which sending mechanism and format by which sending systems can share statistics
systems can share statistics and specific information about potential and specific information about potential failures with recipient
failures with recipient domains. Recipient domains can then use this domains. Recipient domains can then use this information to both
information to both detect potential attackers and diagnose detect potential attackers and diagnose unintentional
unintentional 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 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 April 1, 2018. This Internet-Draft will expire on May 12, 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 34 skipping to change at page 2, line 34
2. Related Technologies . . . . . . . . . . . . . . . . . . . . 4 2. Related Technologies . . . . . . . . . . . . . . . . . . . . 4
3. Reporting Policy . . . . . . . . . . . . . . . . . . . . . . 4 3. Reporting Policy . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Example Reporting Policy . . . . . . . . . . . . . . . . 6 3.1. Example Reporting Policy . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . . . . 14 5.3.1. Example Report . . . . . . . . . . . . . . . . . . . 15
5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. Appendix 1: Example Reporting Policy . . . . . . . . . . . . 20 8. Appendix 1: Example Reporting Policy . . . . . . . . . . . . 21
8.1. Report using MAILTO . . . . . . . . . . . . . . . . . . . 20 8.1. Report using MAILTO . . . . . . . . . . . . . . . . . . . 21
8.2. Report using HTTPS . . . . . . . . . . . . . . . . . . . 20 8.2. Report using HTTPS . . . . . . . . . . . . . . . . . . . 21
9. Appendix 2: Example JSON Report . . . . . . . . . . . . . . . 20 9. Appendix 2: Example JSON Report . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . 22 10.1. Normative References . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . 23 10.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
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 3, line 48 skipping to change at page 3, line 48
failures in routing, STARTTLS negotiation, and both DANE [RFC6698] failures in routing, STARTTLS negotiation, and both DANE [RFC6698]
and MTA-STS (TODO: Add ref) policy validation errors, and a standard and MTA-STS (TODO: Add ref) policy validation errors, and a standard
TXT record that recipient domains can use to indicate where reports TXT record that recipient domains can use to indicate where reports
in this format should be sent. in this format should be sent.
This document is intended as a companion to the specification for This document is intended as a companion to the specification for
SMTP MTA Strict Transport Security (MTA-STS, TODO: Add ref). SMTP MTA Strict Transport Security (MTA-STS, TODO: Add ref).
1.1. Terminology 1.1. Terminology
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document, are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
We also define the following terms for further use in this document: We also define the following terms for further use in this document:
o MTA-STS Policy: A definition of the expected TLS availability, o MTA-STS Policy: A definition of the expected TLS availability,
behavior, and desired actions for a given domain when a sending behavior, and desired actions for a given domain when a sending
MTA encounters problems in negotiating a secure channel. MTA-STS MTA encounters problems in negotiating a secure channel. MTA-STS
is defined in [TODO] is defined in [TODO]
o DANE Policy: A mechanism by which administrators can supply a o DANE Policy: A mechanism by which administrators can supply a
record that can be used to validate the certificate presented by record that can be used to validate the certificate presented by
skipping to change at page 5, line 6 skipping to change at page 5, line 6
o "v": This value MUST be equal to "TLSRPTv1". o "v": This value MUST be equal to "TLSRPTv1".
o "rua": A URI specifying the endpoint to which aggregate o "rua": A URI specifying the endpoint to which aggregate
information about policy validation results should be sent (see information about policy validation results should be sent (see
Section 4, "Reporting Schema", for more information). Two URI Section 4, "Reporting Schema", for more information). Two URI
schemes are supported: "mailto" and "https". As with DMARC schemes are supported: "mailto" and "https". As with DMARC
[RFC7489], the policy domain can specify a comma-separated list of [RFC7489], the policy domain can specify a comma-separated list of
URIs. URIs.
o In the case of "https", reports should be submitted via POST o In the case of "https", reports should be submitted via POST
([RFC2818]) to the specified URI. Report submitters MAY ignore ([RFC7231]) to the specified URI. Report submitters MAY ignore
certificate validation errors when submitting reports via https. certificate validation errors when submitting reports via https.
o In the case of "mailto", reports should be submitted to the o In the case of "mailto", reports should be submitted to the
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 failuresand SHOULD NOT include this SMTP session in the
the clear. Additionally, reports sent via SMTP MUST contain a next report. This may mean that the reports are delivered in the
valid DKIM [RFC6376] signature by the reporting domain. Reports clear. Additionally, reports sent via SMTP MUST contain a valid
lacking such a signature MUST be ignored by the recipient. DKIM DKIM [RFC6376] signature by the reporting domain. Reports lacking
such a signature MUST be ignored by the recipient. DKIM
signatures must not use the "l=" attribute to limit the body signatures must not use the "l=" attribute to limit the body
length used in the signature. length used in the signature.
The formal definition of the "_smtp-tlsrpt" TXT record, defined using The formal definition of the "_smtp-tlsrpt" TXT record, defined using
[RFC5234] & [RFC7405], is as follows: [RFC5234] & [RFC7405], is as follows:
tlsrpt-record = tlsrpt-version 1*(field-delim tlsrpt-field) tlsrpt-record = tlsrpt-version 1*(field-delim tlsrpt-field)
[field-delim] [field-delim]
field-delim = *WSP ";" *WSP field-delim = *WSP ";" *WSP
skipping to change at page 6, line 16 skipping to change at page 6, line 17
Parsers MUST accept TXT records which are syntactically valid (i.e. Parsers MUST accept TXT records which are syntactically valid (i.e.
valid key-value pairs separated by semi-colons) and implementing a valid key-value pairs separated by semi-colons) and implementing a
superset of this specification, in which case unknown fields SHALL be superset of this specification, in which case unknown fields SHALL be
ignored. 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 7, line 15 skipping to change at page 7, line 18
* An identifier for the policy (where applicable) * An identifier for the policy (where applicable)
o Aggregate counts, comprising result type, sending MTA IP, o Aggregate counts, comprising result type, sending MTA IP,
receiving MTA hostname, session count, and an optional additional receiving MTA hostname, session count, and an optional additional
information field containing a URI for recipients to review information field containing a URI for recipients to review
further information on a failure type. further information on a failure type.
Note that the failure types are non-exclusive; an aggregate report Note that the failure types are non-exclusive; an aggregate report
may contain overlapping "counts" of failure types when a single send may contain overlapping "counts" of failure types when a single send
attempt encountered multiple errors. attempt encountered multiple errors. Reporters may report multiple
applied policies (for example, an MTA-STS policy and a DANE TLSA
record for the same domain and MX); even in the case where only a
single policy was applied, the "policies" field of the report body
MUST be an array and not a singular value.
4.1. Report Time-frame 4.1. Report Time-frame
The report SHOULD cover a full day, from 0000-2400 UTC. This should The report SHOULD cover a full day, from 0000-2400 UTC. This should
allow for easier correlation of failure events. To avoid a Denial of allow for easier correlation of failure events. To avoid a Denial of
Service against the system processing the reports, the reports should Service against the system processing the reports, the reports should
be delivered after some delay, perhaps several hours. be delivered after some delay, perhaps several hours.
4.2. Delivery Summary 4.2. Delivery Summary
skipping to change at page 10, line 4 skipping to change at page 10, line 4
4.3.4. Transient Failures 4.3.4. Transient Failures
Transient errors due to too-busy network, TCP timeouts, etc. are not Transient errors due to too-busy network, TCP timeouts, etc. are not
required to be reported. required to be reported.
4.4. JSON Report Schema 4.4. JSON Report Schema
The JSON schema is derived from the HPKP JSON schema [RFC7469] (cf. The JSON schema is derived from the HPKP JSON schema [RFC7469] (cf.
Section 3) Section 3)
{
"organization-name": organization-name, {
"date-range": { "organization-name": organization-name,
"start-datetime": date-time, "date-range": {
"end-datetime": date-time "start-datetime": date-time,
}, "end-datetime": date-time
"contact-info": email-address, },
"report-id": report-id, "contact-info": email-address,
"report-id": report-id,
"policies": [{
"policy": { "policy": {
"policy-type": policy-type, "policy-type": policy-type,
"policy-string": policy-string, "policy-string": policy-string,
"policy-domain": domain, "policy-domain": domain,
"mx-host": mx-host-pattern "mx-host": mx-host-pattern
}, },
"summary": { "summary": {
"total-successful-session-count": total-successful-session-count, "total-successful-session-count": total-successful-session-count,
"total-failure-session-count:" total-failure-session-count "total-failure-session-count": total-failure-session-count
} },
"failure-details": [ "failure-details": [
{ {
"result-type": result-type, "result-type": result-type,
"sending-mta-ip": ip-address, "sending-mta-ip": ip-address,
"receiving-mx-hostname": receiving-mx-hostname, "receiving-mx-hostname": receiving-mx-hostname,
"receiving-mx-helo": receiving-mx-helo, "receiving-mx-helo": receiving-mx-helo,
"failed-session-count": failed-session-count, "failed-session-count": failed-session-count,
"additional-information": additional-info-uri, "additional-information": additional-info-uri,
"failure-reason-code": "failure-reason-code" "failure-reason-code": failure-reason-code
} }
] ]
} }
]
}
JSON Report Format JSON Report Format
o "organization-name": The name of the organization responsible for o "organization-name": The name of the organization responsible for
the report. It is provided as a string. the report. It is provided as a string.
o "date-time": The date-time indicates the start- and end-times for o "date-time": The date-time indicates the start- and end-times for
the report range. It is provided as a string formatted according the report range. It is provided as a string formatted according
to Section 5.6, "Internet Date/Time Format", of [RFC3339]. The to Section 5.6, "Internet Date/Time Format", of [RFC3339]. The
report should be for a full UTC day, 0000-2400. report should be for a full UTC day, 0000-2400.
skipping to change at page 11, line 49 skipping to change at page 12, line 6
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 "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 an 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.
o "additional-info-uri": An optional URI [RFC3986] pointing to o "additional-info-uri": An optional URI [RFC3986] pointing to
additional information around the relevant "result-type". For additional information around the relevant "result-type". For
example, this URI might host the complete certificate chain example, this URI might host the complete certificate chain
presented during an attempted STARTTLS session. presented during an attempted STARTTLS session.
o "failure-reason-code": A text field to include an TLS-related o "failure-reason-code": A text field to include a TLS-related error
error code or error message. code or error message.
For report purposes, an IPv4 Address is defined as: IPv4address = For report purposes, an IPv4 Address is defined as: IPv4address =
dec-octet "." dec-octet "." dec-octet "." dec-octet dec-octet "." dec-octet "." dec-octet "." dec-octet
dec-octet = DIGIT ; 0-9 / %x31-39 DIGIT ; 10-99 / "1" 2DIGIT ; dec-octet = DIGIT ; 0-9 / %x31-39 DIGIT ; 10-99 / "1" 2DIGIT ;
100-199 / "2" %x30-34 DIGIT ; 200-249 / "25" %x30-35 ; 250-255 100-199 / "2" %x30-34 DIGIT ; 200-249 / "25" %x30-35 ; 250-255
5. Report Delivery 5. Report Delivery
Reports can be delivered either as an email message via SMTP or via Reports can be delivered either as an email message via SMTP or via
HTTP POST. HTTP POST.
skipping to change at page 20, line 33 skipping to change at page 20, line 40
DMARC [RFC7489] defines a solution for verifying delegation to DMARC [RFC7489] defines a solution for verifying delegation to
avoid such attacks; the need for this is greater with DMARC, avoid such attacks; the need for this is greater with DMARC,
however, because DMARC allows an attacker to trigger reports to a however, because DMARC allows an attacker to trigger reports to a
target from an innocent third party by sending that third party target from an innocent third party by sending that third party
mail (which triggers a report from the third party to the target). mail (which triggers a report from the third party to the target).
In the case of TLSRPT, the attacker would have to induce the third In the case of TLSRPT, the attacker would have to induce the third
party to send the attacker mail in order to trigger reports from party to send the attacker mail in order to trigger reports from
the third party to the victim; this reduces the risk of such an the third party to the victim; this reduces the risk of such an
attack and the need for a verification mechanism. attack and the need for a verification mechanism.
Finally, because TLSRPT is intended to help administrators discover
man-in-the-middle attacks against transport-layer encryption,
including attacks designed to thwart negotiation of encrypted
connections (by downgrading opportunistic encryption or, in the case
of MTA-STS, preventing discovery of a new MTA-STS policy), we must
also consider the risk that an adversary who can induce such a
downgrade attack can also prevent discovery of the TLSRPT TXT record
(and thus prevent discovery of the successful downgrade attack).
Administrators are thus encouraged to deploy TLSRPT TXT records with
a large TTL (reducing the window for successful attacks against DNS
resolution of the record) or to deploy DNSSEC on the deploying zone.
8. Appendix 1: Example Reporting Policy 8. Appendix 1: Example Reporting Policy
8.1. Report using MAILTO 8.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"
8.2. Report using HTTPS 8.2. Report using HTTPS
_smtp-tlsrpt.mail.example.com. IN TXT \ _smtp-tlsrpt.mail.example.com. IN TXT \
skipping to change at page 21, line 12 skipping to change at page 22, line 12
9. Appendix 2: Example JSON Report 9. Appendix 2: Example JSON Report
{ {
"organization-name": "Company-X", "organization-name": "Company-X",
"date-range": { "date-range": {
"start-datetime": "2016-04-01T00:00:00Z", "start-datetime": "2016-04-01T00:00:00Z",
"end-datetime": "2016-04-01T23:59:59Z" "end-datetime": "2016-04-01T23:59:59Z"
}, },
"contact-info": "sts-reporting@company-x.com", "contact-info": "sts-reporting@company-x.com",
"report-id": "5065427c-23d3-47ca-b6e0-946ea0e8c4be", "report-id": "5065427c-23d3-47ca-b6e0-946ea0e8c4be",
"policy": { "policies": [{
"policy-type": "sts", "policy": {
"policy-string": "{ \"version\": \"STSv1\",\"mode\": \"report\", \"mx\": [\".mail.company-y.com\"], \"max_age\": 86400 }", "policy-type": "sts",
"policy-domain": "company-y.com", "policy-string": "version: STSv1\r\nmode: report\r\nmx: .mail.company-y.com\r\nmax_age: 86400",
"mx-host": ".mail.company-y.com" "policy-domain": "company-y.com",
}, "mx-host": ".mail.company-y.com"
"summary": { },
"total-successful-session-count": 5326, "summary": {
"total-failure-session-count": 303 "total-successful-session-count": 5326,
}, "total-failure-session-count": 303
"failure-details": [{ },
"result-type": "certificate-expired", "failure-details": [{
"sending-mta-ip": "98.136.216.25", "result-type": "certificate-expired",
"receiving-mx-hostname": "mx1.mail.company-y.com", "sending-mta-ip": "98.136.216.25",
"failed-session-count": 100 "receiving-mx-hostname": "mx1.mail.company-y.com",
}, { "failed-session-count": 100
"result-type": "starttls-not-supported", }, {
"sending-mta-ip": "98.22.33.99", "result-type": "starttls-not-supported",
"receiving-mx-hostname": "mx2.mail.company-y.com", "sending-mta-ip": "98.22.33.99",
"failed-session-count": 200, "receiving-mx-hostname": "mx2.mail.company-y.com",
"additional-information": "hxxps://reports.company-x.com/ "failed-session-count": 200,
report_info?id=5065427c-23d3#StarttlsNotSupported" "additional-information": "https://reports.company-x.com/
}, { report_info ? id = 5065427 c - 23 d3# StarttlsNotSupported "
"result-type": "validation-failure", }, {
"sending-mta-ip": "47.97.15.2", "result-type": "validation-failure",
"receiving-mx-hostname": "mx-backup.mail.company-y.com", "sending-mta-ip": "47.97.15.2",
"failed-session-count": 3, "receiving-mx-hostname": "mx-backup.mail.company-y.com",
"failure-error-code": "X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED" "failed-session-count": 3,
"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
Y, where 100 sessions were attempted to Company Y servers with an Company-Y, where 100 sessions were attempted to Company Y servers
expired certificate and 200 sessions were attempted to Company Y with an expired certificate and 200 sessions were attempted to
servers that did not successfully respond to the "STARTTLS" command. Company Y servers that did not successfully respond to the "STARTTLS"
Additionally 3 sessions failed due to command. 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, Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- RFC2119, March 1997,
editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000, <https://www.rfc-
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,
<https://www.rfc-editor.org/info/rfc3339>. <http://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>. <http://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
RFC 3986, DOI 10.17487/RFC3986, January 2005, 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <http://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/
DOI 10.17487/RFC5234, January 2008, <https://www.rfc- RFC5234, January 2008,
editor.org/info/rfc5234>. <http://www.rfc-editor.org/info/rfc5234>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://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, <https://www.rfc- DOI 10.17487/RFC5321, October 2008,
editor.org/info/rfc5321>. <http://www.rfc-editor.org/info/rfc5321>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI
DOI 10.17487/RFC5322, October 2008, <https://www.rfc- 10.17487/RFC5322, October 2008,
editor.org/info/rfc5322>. <http://www.rfc-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/
DOI 10.17487/RFC5891, August 2010, <https://www.rfc- RFC5891, August 2010,
editor.org/info/rfc5891>. <http://www.rfc-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/
DOI 10.17487/RFC5952, August 2010, <https://www.rfc- RFC5952, August 2010,
editor.org/info/rfc5952>. <http://www.rfc-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>. <http://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, <https://www.rfc-editor.org/info/rfc6125>. 2011, <http://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,
<https://www.rfc-editor.org/info/rfc6376>. <http://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", the Reporting of Mail System Administrative Messages", STD
STD 73, RFC 6522, DOI 10.17487/RFC6522, January 2012, 73, RFC 6522, DOI 10.17487/RFC6522, January 2012,
<https://www.rfc-editor.org/info/rfc6522>. <http://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, <http://www.rfc-editor.org/info/rfc6698>.
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
RFC 7405, DOI 10.17487/RFC7405, December 2014, Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI
<https://www.rfc-editor.org/info/rfc7405>. 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/
info/rfc7231>.
[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC
DOI 10.17487/RFC7493, March 2015, <https://www.rfc- 7405, DOI 10.17487/RFC7405, December 2014,
editor.org/info/rfc7493>. <http://www.rfc-editor.org/info/rfc7405>.
[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI
10.17487/RFC7493, March 2015,
<http://www.rfc-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, <https://www.rfc-editor.org/info/rfc3207>. February 2002, <http://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>. <http://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, <https://www.rfc- DOI 10.17487/RFC3864, September 2004,
editor.org/info/rfc3864>. <http://www.rfc-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, <https://www.rfc-editor.org/info/rfc7435>. December 2014, <http://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, <http://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>. <http://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. 45 change blocks. 
139 lines changed or deleted 164 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/