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/