draft-ietf-uta-smtp-tlsrpt-17.txt   draft-ietf-uta-smtp-tlsrpt-18.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: September 6, 2018 Comcast, Inc Expires: October 6, 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
March 5, 2018 April 4, 2018
SMTP TLS Reporting SMTP TLS Reporting
draft-ietf-uta-smtp-tlsrpt-17 draft-ietf-uta-smtp-tlsrpt-18
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 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 September 6, 2018. This Internet-Draft will expire on October 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
(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 26 skipping to change at page 2, line 26
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
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . 7
3.1.1. Report using MAILTO . . . . . . . . . . . . . . . . . 6 3.1.1. Report using MAILTO . . . . . . . . . . . . . . . . . 7
3.1.2. Report using HTTPS . . . . . . . . . . . . . . . . . 7 3.1.2. Report using HTTPS . . . . . . . . . . . . . . . . . 7
4. Reporting Schema . . . . . . . . . . . . . . . . . . . . . . 7 4. Reporting Schema . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Report Time-frame . . . . . . . . . . . . . . . . . . . . 8 4.1. Report Time-frame . . . . . . . . . . . . . . . . . . . . 8
4.2. Delivery Summary . . . . . . . . . . . . . . . . . . . . 8 4.2. Delivery Summary . . . . . . . . . . . . . . . . . . . . 8
4.2.1. Success Count . . . . . . . . . . . . . . . . . . . . 8 4.2.1. Success Count . . . . . . . . . . . . . . . . . . . . 8
4.2.2. Failure Count . . . . . . . . . . . . . . . . . . . . 8 4.2.2. Failure Count . . . . . . . . . . . . . . . . . . . . 8
4.3. Result Types . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Result Types . . . . . . . . . . . . . . . . . . . . . . 8
4.3.1. Negotiation Failures . . . . . . . . . . . . . . . . 8 4.3.1. Negotiation Failures . . . . . . . . . . . . . . . . 9
4.3.2. Policy Failures . . . . . . . . . . . . . . . . . . . 9 4.3.2. Policy Failures . . . . . . . . . . . . . . . . . . . 9
4.3.3. General Failures . . . . . . . . . . . . . . . . . . 9 4.3.3. General Failures . . . . . . . . . . . . . . . . . . 10
4.3.4. Transient Failures . . . . . . . . . . . . . . . . . 10 4.3.4. Transient Failures . . . . . . . . . . . . . . . . . 10
4.4. JSON Report Schema . . . . . . . . . . . . . . . . . . . 10 4.4. JSON Report Schema . . . . . . . . . . . . . . . . . . . 10
4.5. Policy Samples . . . . . . . . . . . . . . . . . . . . . 13 4.5. Policy Samples . . . . . . . . . . . . . . . . . . . . . 13
5. Report Delivery . . . . . . . . . . . . . . . . . . . . . . . 14 5. Report Delivery . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 14 5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 14
5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 15 5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 15
5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 15 5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 15
5.3.1. Example Report . . . . . . . . . . . . . . . . . . . 16 5.3.1. Example Report . . . . . . . . . . . . . . . . . . . 16
5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 17 5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 17
5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 18 5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 18
skipping to change at page 3, line 20 skipping to change at page 3, line 20
Appendix A. Example Reporting Policy . . . . . . . . . . . . . . 25 Appendix A. Example Reporting Policy . . . . . . . . . . . . . . 25
A.1. Report using MAILTO . . . . . . . . . . . . . . . . . . . 26 A.1. Report using MAILTO . . . . . . . . . . . . . . . . . . . 26
A.2. Report using HTTPS . . . . . . . . . . . . . . . . . . . 26 A.2. Report using HTTPS . . . . . . . . . . . . . . . . . . . 26
Appendix B. Example JSON Report . . . . . . . . . . . . . . . . 26 Appendix B. Example JSON Report . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
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 uses an approach that has come to be known as "Opportunistic
maintains interoperability with clients that do not support STARTTLS Security" (OS) [RFC7435], which maintains interoperability with
but means that any attacker who can delete parts of the SMTP session clients that do not support STARTTLS but means that any attacker who
(such as the "250 STARTTLS" response) or redirect the entire SMTP can delete parts of the SMTP session (such as the "250 STARTTLS"
session (perhaps by overwriting the resolved MX record of the response) or redirect the entire SMTP session (perhaps by overwriting
delivery domain) can perform a downgrade or interception attack. the resolved MX record of the delivery domain) can perform a
downgrade or interception attack.
Because such "downgrade attacks" are not necessarily apparent to the Because such "downgrade attacks" are not necessarily apparent to the
receiving MTA, this document defines a mechanism for sending domains receiving MTA, this document defines a mechanism for sending domains
to report on failures at multiple stages of the MTA-to-MTA to report on failures at multiple stages of the MTA-to-MTA
conversation. conversation.
Recipient domains may also use the mechanisms defined by MTA-STS Recipient domains may also use the mechanisms defined by MTA-STS
[I-D.ietf-uta-mta-sts] or DANE [RFC6698] to publish additional [I-D.ietf-uta-mta-sts] or DANE [RFC6698] to publish additional
encryption and authentication requirements; this document defines a encryption and authentication requirements; this document defines a
mechanism for sending domains that are compatible with MTA-STS or mechanism for sending domains that are compatible with MTA-STS or
DANE to share success and failure statistics with recipient domains. DANE to share success and failure statistics with recipient domains.
Specifically, this document defines a reporting schema that covers Specifically, this document defines a reporting schema that covers
failures in routing, DNS resolution, STARTTLS negotiation, and both failures in routing, DNS resolution, STARTTLS negotiation, and both
DANE [RFC6698] and MTA-STS [I-D.ietf-uta-mta-sts] policy validation DANE [RFC6698] and MTA-STS [I-D.ietf-uta-mta-sts] policy validation
errors, and a standard TXT record that recipient domains can use to errors, and a standard TXT record that recipient domains can use to
indicate where reports in this format should be sent. indicate where reports in this format should be sent. The report can
also serve as a heartbeat that systems are successfully negotiating
TLS during sessions as expected.
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 [I-D.ietf-uta-mta-sts], as well as SMTP MTA Strict Transport Security [I-D.ietf-uta-mta-sts], as well as
adds reporting abilities for those implementing DANE [RFC7672]. adds reporting abilities for those implementing DANE [RFC7672].
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 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].
skipping to change at page 4, line 45 skipping to change at page 4, line 45
o SMTP-TLSRPT defines a mechanism for sending domains that are o SMTP-TLSRPT defines a mechanism for sending domains that are
compatible with MTA-STS or DANE to share success and failure compatible with MTA-STS or DANE to share success and failure
statistics with recipient domains. DANE is defined in [RFC6698] statistics with recipient domains. DANE is defined in [RFC6698]
and MTA-STS is defined in [I-D.ietf-uta-mta-sts]. and MTA-STS is defined in [I-D.ietf-uta-mta-sts].
3. Reporting Policy 3. Reporting Policy
A domain publishes a record to its DNS indicating that it wishes to A domain publishes a record to its DNS indicating that it wishes to
receive reports. These SMTP TLSRPT policies are distributed via DNS receive reports. These SMTP TLSRPT policies are distributed via DNS
from the Policy Domain's zone, as TXT records (similar to DMARC from the Policy Domain's zone, as TXT records (similar to DMARC
policies) under the name "_smtp-tlsrpt". For example, for the Policy policies) under the name "_smtp._tls". For example, for the Policy
Domain "example.com", the recipient's TLSRPT policy can be retrieved Domain "example.com", the recipient's TLSRPT policy can be retrieved
from "_smtp-tlsrpt.example.com". from "_smtp._tls.example.com".
Policies consist of the following directives: Policies consist of the following directives:
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
skipping to change at page 5, line 27 skipping to change at page 5, line 27
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 and SHOULD NOT include this SMTP session in the related failures and SHOULD NOT include this SMTP session in the
next report. This may mean that the reports are delivered in the next report. This may mean that the reports are delivered in the
clear. Additionally, reports sent via SMTP MUST contain a valid clear. Additionally, reports sent via SMTP MUST contain a valid
DKIM [RFC6376] signature by the reporting domain. Reports lacking DKIM [RFC6376] signature by the reporting domain. Reports lacking
such a signature MUST be ignored by the recipient. DKIM 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._tls" 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
tlsrpt-field = tlsrpt-rua / ; Note that the tlsrpt-field = tlsrpt-rua / ; Note that the
tlsrpt-extension ; tlsrpt-rua record is tlsrpt-extension ; tlsrpt-rua record is
; required. ; required.
tlsrpt-version = %s"v=TLSRPTv1" tlsrpt-version = %s"v=TLSRPTv1"
tlsrpt-rua = %s"rua=" tlsrpt-rua = %s"rua="
tlsrpt-uri *(*WSP "," *WSP tlsrpt-uri) tlsrpt-uri *(*WSP "," *WSP tlsrpt-uri)
tlsrpt-uri = URI tlsrpt-uri = URI
; "URI" is imported from [RFC3986]; ; "URI" is imported from [RFC3986];
; commas (ASCII 0x2C) and exclamation ; commas (ASCII 0x2C), exclamation
; points (ASCII 0x21) MUST be encoded ; points (ASCII 0x21), and semicolons
; (ASCII 0x3B) MUST be encoded
tlsrpt-extension = tlsrpt-ext-name "=" tlsrpt-ext-value tlsrpt-extension = tlsrpt-ext-name "=" tlsrpt-ext-value
tlsrpt-ext-name = (ALPHA / DIGIT) *31(ALPHA / tlsrpt-ext-name = (ALPHA / DIGIT) *31(ALPHA /
DIGIT / "_" / "-" / ".") DIGIT / "_" / "-" / ".")
tlsrpt-ext-value = 1*(%x21-3A / %x3C / %x3E-7E) tlsrpt-ext-value = 1*(%x21-3A / %x3C / %x3E-7E)
; chars excluding "=", ";", SP, and control ; chars excluding "=", ";", SP, and control
; chars ; chars
If multiple TXT records for "_smtp-tlsrpt" are returned by the If multiple TXT records for "_smtp._tls" 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. If the MUST assume the recipient domain does not implement TLSRPT. If the
resulting TXT record contains multiple strings, then the record MUST resulting TXT record contains multiple strings, then the record MUST
be treated as if those strings are concatenated together without be treated as if those strings are concatenated together without
adding spaces. adding spaces.
The record supports the abillity to declare more than one rua, and if
there exists more than one, the reporter MAY attempt to deliver to
each of the supported rua destinations. A receiver MAY opt to only
attempt delivery to one of the endpoints, however the report SHOULD
NOT be considered successfully delivered until one of the endpoints
accepts delivery of the report. If the reporter does not support one
of the report mechanisms, then it SHOULD NOT attempt delivery to
those rua destinations.
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._tls.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._tls.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:
skipping to change at page 8, line 5 skipping to change at page 8, line 15
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. Reporters may report multiple attempt encountered multiple errors. Reporters may report multiple
applied policies (for example, an MTA-STS policy and a DANE TLSA 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 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 single policy was applied, the "policies" field of the report body
MUST be an array and not a singular value. MUST be an array and not a singular value.
In the case of multiple failure types, the "failure-details" array
would contain multiple entries. Each entry would have its own set of
infomation pertaining to that failure type.
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
4.2.1. Success Count 4.2.1. Success Count
o "success-count": This indicates that the sending MTA was able to o "total-successful-session-count": This indicates that the sending
successfully negotiate a policy-compliant TLS connection, and MTA was able to successfully negotiate a policy-compliant TLS
serves to provide a "heartbeat" to receiving domains that connection, and serves to provide a "heartbeat" to receiving
reporting is functional and tabulating correctly. This field domains that reporting is functional and tabulating correctly.
contains an aggregate count of successful connections for the This field contains an aggregate count of successful connections
reporting system. for the reporting system.
4.2.2. Failure Count 4.2.2. Failure Count
o "failure-count": This indicates that the sending MTA was unable to o "total-failure-session-count": This indicates that the sending MTA
successfully establish a connection with the receiving platform. was unable to successfully establish a connection with the
Section 4.3, "Result Types", will elaborate on the failed receiving platform. Section 4.3, "Result Types", will elaborate
negotiation attempts. This field contains an aggregate count of on the failed negotiation attempts. This field contains an
failed connections. aggregate count of failed connections.
4.3. Result Types 4.3. Result Types
The list of result types will start with the minimal set below, and The list of result types will start with the minimal set below, and
is expected to grow over time based on real-world experience. The is expected to grow over time based on real-world experience. The
initial set is: initial set is:
4.3.1. Negotiation Failures 4.3.1. Negotiation Failures
o "starttls-not-supported": This indicates that the recipient MX did o "starttls-not-supported": This indicates that the recipient MX did
skipping to change at page 13, line 40 skipping to change at page 13, line 40
Part of the report body includes the policy that is applied when Part of the report body includes the policy that is applied when
attemping relay to the destination. attemping relay to the destination.
For DANE TLSA policies, a JSON array of strings each representing the For DANE TLSA policies, a JSON array of strings each representing the
RDATA of a single TLSA resource record as a space-separated list of RDATA of a single TLSA resource record as a space-separated list of
its four TLSA fields; the fields are in presentation format (defined its four TLSA fields; the fields are in presentation format (defined
in RFC6698 Section 2.2) with no internal spaces or grouping in RFC6698 Section 2.2) with no internal spaces or grouping
parentheses: parentheses:
[ [ "3 0 1
"3 0 1 1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513D747D1D085D", 1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513D747D1D085D", "3
"3 0 1 12350A337E6DB9C6123522D136A475638CC43E1ED424F8EEC8513D747D1D1234" 0 1 12350A337E6DB9C6123522D136A475638CC43E1ED424F8EEC8513D747D1D1234"
] ]
For the MTA-STS policy, an array of JSON strings that represents the For the MTA-STS policy, an array of JSON strings that represents the
policy that is declared by the receiving site, including any errors policy that is declared by the receiving site, including any errors
that may be present. Note that where there are multiple "mx" values, that may be present. Note that where there are multiple "mx" values,
they must be listed as separate "mx" elements in the policy array, they must be listed as separate "mx" elements in the policy array,
rather as a single nested "mx" sub-array. rather as a single nested "mx" sub-array.
[ [ "version: STSv1", "mode: report", "mx: mx1.example.com", "mx:
"version: STSv1", mx2.example.com", "mx: mx.backup-example.com", "max_age: 12345678" ]
"mode: report",
"mx: mx1.example.com",
"mx: mx2.example.com",
"mx: mx.backup-example.com",
"max_age: 12345678"
]
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.
5.1. Report Filename 5.1. Report Filename
The filename is RECOMMENDED to be constructed using the following The filename is RECOMMENDED to be constructed using the following
ABNF: ABNF:
skipping to change at page 26, line 6 skipping to change at page 26, line 6
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>.
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._tls.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._tls.mail.example.com. IN TXT \
"v=TLSRPTv1; \ "v=TLSRPTv1; \
rua=https://reporting.example.com/v1/tlsrpt" rua=https://reporting.example.com/v1/tlsrpt"
Appendix B. Example JSON Report Appendix B. Example JSON Report
Below is an example JSON report for messages from Company-X to Below is an example JSON report for messages from Company-X to
Company-Y, where 100 sessions were attempted to Company Y servers Company-Y, where 100 sessions were attempted to Company Y servers
with an expired certificate and 200 sessions were attempted to with an expired certificate and 200 sessions were attempted to
Company Y servers that did not successfully respond to the "STARTTLS" Company Y servers that did not successfully respond to the "STARTTLS"
command. Additionally 3 sessions failed due to command. Additionally 3 sessions failed due to
 End of changes. 24 change blocks. 
47 lines changed or deleted 58 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/