draft-ietf-uta-smtp-tlsrpt-13.txt		draft-ietf-uta-smtp-tlsrpt-14.txt
	Using TLS in Applications D. Margolis		Using TLS in Applications D. Margolis
	Internet-Draft Google, Inc		Internet-Draft Google, Inc
	Intended status: Standards Track A. Brotman		Intended status: Standards Track A. Brotman
	Expires: June 7, 2018 Comcast, Inc		Expires: July 30, 2018 Comcast, Inc
	B. Ramakrishnan		B. Ramakrishnan
	Yahoo!, Inc		Yahoo!, Inc
	J. Jones		J. Jones
	Microsoft, Inc		Microsoft, Inc
	M. Risher		M. Risher
	Google, Inc		Google, Inc
	December 4, 2017		January 26, 2018
	SMTP TLS Reporting		SMTP TLS Reporting
	draft-ietf-uta-smtp-tlsrpt-13		draft-ietf-uta-smtp-tlsrpt-14
	Abstract		Abstract
	A number of protocols exist for establishing encrypted channels		A number of protocols exist for establishing encrypted channels
	between SMTP Mail Transfer Agents, including STARTTLS, DANE TLSA, and		between SMTP Mail Transfer Agents, including STARTTLS, DANE TLSA, and
	MTA-STS. These protocols can fail due to misconfiguration or active		MTA-STS. These protocols can fail due to misconfiguration or active
	attack, leading to undelivered messages or delivery over unencrypted		attack, leading to undelivered messages or delivery over unencrypted
	or unauthenticated channels. This document describes a reporting		or unauthenticated channels. This document describes a reporting
	mechanism and format by which sending systems can share statistics		mechanism and format by which sending systems can share statistics
	and specific information about potential failures with recipient		and specific information about potential failures with recipient
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	misconfigurations.		misconfigurations.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on June 7, 2018.		This Internet-Draft will expire on July 30, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2018 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	skipping to change at page 2, line 45 ¶		skipping to change at page 2, line 45 ¶
	4.3.1. Negotiation Failures . . . . . . . . . . . . . . . . 8		4.3.1. Negotiation Failures . . . . . . . . . . . . . . . . 8
	4.3.2. Policy Failures . . . . . . . . . . . . . . . . . . . 8		4.3.2. Policy Failures . . . . . . . . . . . . . . . . . . . 8
	4.3.3. General Failures . . . . . . . . . . . . . . . . . . 9		4.3.3. General Failures . . . . . . . . . . . . . . . . . . 9
	4.3.4. Transient Failures . . . . . . . . . . . . . . . . . 9		4.3.4. Transient Failures . . . . . . . . . . . . . . . . . 9
	4.4. JSON Report Schema . . . . . . . . . . . . . . . . . . . 9		4.4. JSON Report Schema . . . . . . . . . . . . . . . . . . . 9
	5. Report Delivery . . . . . . . . . . . . . . . . . . . . . . . 12		5. Report Delivery . . . . . . . . . . . . . . . . . . . . . . . 12
	5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 12		5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 12
	5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 13		5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 13
	5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 13		5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 13
	5.3.1. Example Report . . . . . . . . . . . . . . . . . . . 15		5.3.1. Example Report . . . . . . . . . . . . . . . . . . . 15
	5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 16		5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 15
	5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 16		5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 16
	5.6. Metadata Variances . . . . . . . . . . . . . . . . . . . 16		5.6. Metadata Variances . . . . . . . . . . . . . . . . . . . 16
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	6.1. Message headers . . . . . . . . . . . . . . . . . . . . . 16		6.1. Message headers . . . . . . . . . . . . . . . . . . . . . 16
	6.2. Report Type . . . . . . . . . . . . . . . . . . . . . . . 17		6.2. Report Type . . . . . . . . . . . . . . . . . . . . . . . 17
	6.3. application/tlsrpt+json Media Type . . . . . . . . . . . 17		6.3. application/tlsrpt+json Media Type . . . . . . . . . . . 17
	6.4. application/tlsrpt+gzip Media Type . . . . . . . . . . . 18		6.4. application/tlsrpt+gzip Media Type . . . . . . . . . . . 18
	6.5. STARTTLS Validation Result Types . . . . . . . . . . . . 19		6.5. STARTTLS Validation Result Types . . . . . . . . . . . . 19
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 20		7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
	skipping to change at page 8, line 46 ¶		skipping to change at page 8, line 46 ¶
	4.3.2. Policy Failures		4.3.2. Policy Failures
	4.3.2.1. DANE-specific Policy Failures		4.3.2.1. DANE-specific Policy Failures
	o "tlsa-invalid": This indicates a validation error in the TLSA		o "tlsa-invalid": This indicates a validation error in the TLSA
	record associated with a DANE policy. None of the records in the		record associated with a DANE policy. None of the records in the
	RRset were found to be valid.		RRset were found to be valid.
	o "dnssec-invalid": This would indicate that no valid records were		o "dnssec-invalid": This would indicate that no valid records were
	returned from the recursive resolver. The request returned with		returned from the recursive resolver. The request returned with
	SERVFAIL for the requested TLSA record. It should be noted that		SERVFAIL for the requested TLSA record.
	if the reporter's systems are having problems resolving
	destination DNS records due to DNSSEC failures, it's possible they		o "dane-required": This indicates that the sending system is
	will also be unable to resolve the TLSRPT record, therefore these		configured to require DANE TLSA records for all the MX hosts of
	types of reports may be rare.		the destination domain, but no DNSSEC-validated TLSA records were
			present for the MX host that is the subject of the report.
			Mandatory DANE for SMTP is described in section 6 of [RFC7672].
			Such policies may be created by mutual agreement between two
			organizations that frequently exchange sensitive content via
			email.
	4.3.2.2. MTA-STS-specific Policy Failures		4.3.2.2. MTA-STS-specific Policy Failures
	o "sts-policy-invalid": This indicates a validation error for the		o "sts-policy-invalid": This indicates a validation error for the
	overall MTA-STS policy.		overall MTA-STS policy.
	o "sts-webpki-invalid": This indicates that the MTA-STS policy could		o "sts-webpki-invalid": This indicates that the MTA-STS policy could
	not be authenticated using PKIX validation.		not be authenticated using PKIX validation.
	4.3.3. General Failures		4.3.3. General Failures
	skipping to change at page 11, line 16 ¶		skipping to change at page 11, line 16 ¶
	may use whatever scheme they prefer to generate a unique		may use whatever scheme they prefer to generate a unique
	identifier. It is provided as a string.		identifier. It is provided as a string.
	o "policy-type": The type of policy that was applied by the sending		o "policy-type": The type of policy that was applied by the sending
	domain. Presently, the only three valid choices are "tlsa",		domain. Presently, the only three valid choices are "tlsa",
	"sts", and the literal string "no-policy-found". It is provided		"sts", and the literal string "no-policy-found". It is provided
	as a string.		as a string.
	o "policy-string": A string representation of the policy, whether		o "policy-string": A string representation of the policy, whether
	TLSA record ([RFC6698] section 2.3) or MTA-STS policy. Examples:		TLSA record ([RFC6698] section 2.3) or MTA-STS policy. Examples:
	TLSA: ""_25._tcp.mx.example.com. IN TLSA ( 3 0 1 \		TLSA: ""_25._tcp.mx.example.com. 3 0 1 \ 1F850A337E6DB9C609C522D13
	1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513D7 47D1D085D		6A475638CC43E1ED424F8EEC8513D747D1D085D)"" MTA-STS: ""version:
	)"" MTA-STS: ""version: STSv1\nmode: report\nmx:		STSv1\nmode: report\nmx: mx1.example.com\nmx: \
	mx1.example.com\nmx: \ mx2.example.com\nmx: mx.backup-		mx2.example.com\nmx: mx.backup-example.com\nmax_age: 12345678""
	example.com\nmax_age: 12345678""
	o "domain": The Policy Domain is the domain against which the MTA-		o "domain": The Policy Domain is the domain against which the MTA-
	STS or DANE policy is defined. In the case of Internationalized		STS or DANE policy is defined. In the case of Internationalized
	Domain Names ([RFC5891]), the domain is the Punycode-encoded		Domain Names ([RFC5891]), the domain MUST consist of the Punycode-
	A-label ([RFC3492]) and not the U-label.		encoded A-labels ([RFC3492]) and not the U-labels.
	o "mx-host-pattern": The pattern of MX hostnames from the applied		o "mx-host-pattern": The pattern of MX hostnames from the applied
	policy. It is provided as a string, and is interpreted in the		policy. It is provided as a string, and is interpreted in the
	same manner as the "Checking of Wildcard Certificates" rules in		same manner as the "Checking of Wildcard Certificates" rules in
	Section 6.4.3 of [RFC6125]. In the case of Internationalized		Section 6.4.3 of [RFC6125]. In the case of Internationalized
	Domain Names ([RFC5891]), the domain is the Punycode-encoded		Domain Names ([RFC5891]), the domain MUST consist of the Punycode-
	A-label ([RFC3492]) and not the U-label.		encoded A-labels ([RFC3492]) and not the U-labels.
	o "result-type": A value from Section 4.3, "Result Types", above.		o "result-type": A value from Section 4.3, "Result Types", above.
	o "ip-address": The IP address of the sending MTA that attempted the		o "ip-address": The IP address of the sending MTA that attempted the
	STARTTLS connection. It is provided as a string representation of		STARTTLS connection. It is provided as a string representation of
	an IPv4 (see below) or IPv6 ([RFC5952]) address in dot-decimal or		an IPv4 (see below) or IPv6 ([RFC5952]) address in dot-decimal or
	colon-hexadecimal notation.		colon-hexadecimal notation.
	o "receiving-mx-hostname": The hostname of the receiving MTA MX		o "receiving-mx-hostname": The hostname of the receiving MTA MX
	record with which the sending MTA attempted to negotiate a		record with which the sending MTA attempted to negotiate a
	STARTTLS connection.		STARTTLS connection.
	o "receiving-mx-helo": (optional) The HELO or EHLO string from the		o "receiving-mx-helo": (optional) The HELO or EHLO string from the
	banner announced during the reported session.		banner announced during the reported session.
			o "receiving-ip": The destination IP address that was using when
			creating the outbound session. It is provided as a string
			representation of an IPv4 (see below) or IPv6 ([RFC5952]) address
			in dot-decimal or colon-hexadecimal notation.
	o "total-successful-session-count": The aggregate number (integer)		o "total-successful-session-count": The aggregate number (integer)
	of successfully negotiated TLS-enabled connections to the		of successfully negotiated TLS-enabled connections to the
	receiving site.		receiving site.
	o "total-failure-session-count": The aggregate number (integer) of		o "total-failure-session-count": The aggregate number (integer) of
	failures to negotiate a TLS-enabled connection to the receiving		failures to negotiate a TLS-enabled connection to the receiving
	site.		site.
	o "failed-session-count": The number of (attempted) sessions that		o "failed-session-count": The number of (attempted) sessions that
	match the relevant "result-type" for this section.		match the relevant "result-type" for this section.
	skipping to change at page 13, line 26 ¶		skipping to change at page 13, line 26 ¶
	begin-timestamp = 1*DIGIT		begin-timestamp = 1*DIGIT
	; seconds since 00:00:00 UTC January 1, 1970		; seconds since 00:00:00 UTC January 1, 1970
	; indicating start of the time range contained		; indicating start of the time range contained
	; in the report		; in the report
	end-timestamp = 1*DIGIT		end-timestamp = 1*DIGIT
	; seconds since 00:00:00 UTC January 1, 1970		; seconds since 00:00:00 UTC January 1, 1970
	; indicating end of the time range contained		; indicating end of the time range contained
	; in the report		; in the report
	extension = "json" / "json.gz"		extension = "json"
	The extension MUST be "json" for a plain JSON file, or "json.gz" for
	a JSON file compressed using GZIP.
	"unique-id" allows an optional unique ID generated by the Sending MTA		"unique-id" allows an optional unique ID generated by the Sending MTA
	to distinguish among multiple reports generated simultaneously by		to distinguish among multiple reports generated simultaneously by
	different sources within the same Policy Domain. For example, this		different sources within the same Policy Domain. For example, this
	is a possible filename for the gzip file of a report to the Policy		is a possible filename for the gzip file of a report to the Policy
	Domain "example.net" from the Sending MTA "mail.sender.example.com":		Domain "example.net" from the Sending MTA "mail.sender.example.com":
	"mail.sender.example.com!example.net!1470013207!1470186007!001.json.g		"mail.sender.example.com!example.net!1470013207!1470186007!001.json"
	z"
	5.2. Compression		5.2. Compression
	The report SHOULD be subjected to GZIP compression for both email and		The report SHOULD be subjected to GZIP compression for both email and
	HTTPS transport. Declining to apply compression can cause the report		HTTPS transport. Declining to apply compression can cause the report
	to be too large for a receiver to process (a commonly observed		to be too large for a receiver to process (a commonly observed
	receiver limit is ten megabytes); compressing the file increases the		receiver limit is ten megabytes); compressing the file increases the
	chances of acceptance of the report at some compute cost.		chances of acceptance of the report at some compute cost.
	5.3. Email Transport		5.3. Email Transport
	skipping to change at page 16, line 9 ¶		skipping to change at page 16, line 4 ¶
	------=_NextPart_000_024E_01CC9B0A.AFE54C00--		------=_NextPart_000_024E_01CC9B0A.AFE54C00--
	...		...
	Note that, when sending failure reports via SMTP, sending MTAs MUST		Note that, when sending failure reports via SMTP, sending MTAs MUST
	NOT honor MTA-STS or DANE TLSA failures.		NOT honor MTA-STS or DANE TLSA failures.
	5.4. HTTPS Transport		5.4. HTTPS Transport
	The report MAY be delivered by POST to HTTPS. If compressed, the		The report MAY be delivered by POST to HTTPS. If compressed, the
	report SHOULD use the media type "application/tlsrpt+gzip", and		report SHOULD use the media type "application/tlsrpt+gzip", and
	"application/tlsrpt+json" otherwise (see section Section 6, "IANA		The report MAY be delivered by POST to HTTPS. When doing so, the
	Considerations").		report should use the media-type "application/tlsrpt" (see section
			Section 6, "IANA Considerations"). If the reporting entity
			compresses the report, that should be noted in the Content-Type
			"conversions" field:
			Content-Type: application/tlsrpt; conversions=gzip Content-Type:
			application/tlsrpt; conversions=none Content-Type: application/tlsrpt
			The second and third items in the list are equivalent.
	A reporting entity SHOULD expect a "successful" response from the		A reporting entity SHOULD expect a "successful" response from the
	accepting HTTPS server, typically a 200 or 201 HTTP code [RFC7231].		accepting HTTPS server, typically a 200 or 201 HTTP code [RFC7231].
	Other codes could indicate a delivery failure, and may be retried as		Other codes could indicate a delivery failure, and may be retried as
	per local policy. The receiving system is not expected to process		per local policy. The receiving system is not expected to process
	reports at receipt time, and MAY store them for processing at a later		reports at receipt time, and MAY store them for processing at a later
	time.		time.
	5.5. Delivery Retry		5.5. Delivery Retry
	In the event of a delivery failure, regardless of the delivery		In the event of a delivery failure, regardless of the delivery
	method, a sender SHOULD attempt redelivery for up to 24hrs after the		method, a sender SHOULD attempt redelivery for up to 24hrs after the
	initial attempt. As previously stated the reports are optional, so		initial attempt. As previously stated the reports are optional, so
	while it is ideal to attempt redelivery, it is not required. If		while it is ideal to attempt redelivery, it is not required. If
	multiple retries are attempted, ideally they would be on a		multiple retries are attempted, ideally they SHOULD be done with
	logarithmic scale.		exponential backoff.
	5.6. Metadata Variances		5.6. Metadata Variances
	As stated above, there are a variable number of ways to declare		As stated above, there are a variable number of ways to declare
	information about the data therein. If it should be the case that		information about the data therein. If any of items declared via
	these objects were to disagree, then the report data contained within		subject or filename disagree with the report, the report MUST be
	the JSON body MUST be considered the authoritative source for those		considered the authoritative source.
	data elements.
	6. IANA Considerations		6. IANA Considerations
	The following are the IANA considerations discussed in this document.		The following are the IANA considerations discussed in this document.
	6.1. Message headers		6.1. Message headers
	Below is the Internet Assigned Numbers Authority (IANA) Permanent		Below is the Internet Assigned Numbers Authority (IANA) Permanent
	Message Header Field registration information per [RFC3864].		Message Header Field registration information per [RFC3864].
	skipping to change at page 21, line 21 ¶		skipping to change at page 21, line 21 ¶
	a large TTL (reducing the window for successful attacks against DNS		a large TTL (reducing the window for successful attacks against DNS
	resolution of the record) or to deploy DNSSEC on the deploying zone.		resolution of the record) or to deploy DNSSEC on the deploying zone.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[I-D.ietf-uta-mta-sts]		[I-D.ietf-uta-mta-sts]
	Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A.,		Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A.,
	and J. Jones, "SMTP MTA Strict Transport Security (MTA-		and J. Jones, "SMTP MTA Strict Transport Security (MTA-
	STS)", draft-ietf-uta-mta-sts-11 (work in progress),		STS)", draft-ietf-uta-mta-sts-14 (work in progress),
	November 2017.		January 2018.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc2119>.		editor.org/info/rfc2119>.
	[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:		[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
	Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,		Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
	<https://www.rfc-editor.org/info/rfc3339>.		<https://www.rfc-editor.org/info/rfc3339>.
	[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode		[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
	for Internationalized Domain Names in Applications		for Internationalized Domain Names in Applications
	(IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003,		(IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003,
	<https://www.rfc-editor.org/info/rfc3492>.		<https://www.rfc-editor.org/info/rfc3492>.
	[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifier (URI): Generic Syntax", STD 66,		Resource Identifier (URI): Generic Syntax", STD 66,
	RFC 3986, DOI 10.17487/RFC3986, January 2005,		RFC 3986, DOI 10.17487/RFC3986, January 2005,
	<https://www.rfc-editor.org/info/rfc3986>.		<https://www.rfc-editor.org/info/rfc3986>.
	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234,		Specifications: ABNF", STD 68, RFC 5234,
	DOI 10.17487/RFC5234, January 2008,		DOI 10.17487/RFC5234, January 2008, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc5234>.		editor.org/info/rfc5234>.
	[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,		[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
	Housley, R., and W. Polk, "Internet X.509 Public Key		Housley, R., and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,		(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
	<https://www.rfc-editor.org/info/rfc5280>.		<https://www.rfc-editor.org/info/rfc5280>.
	[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,		[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
	DOI 10.17487/RFC5321, October 2008,		DOI 10.17487/RFC5321, October 2008, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc5321>.		editor.org/info/rfc5321>.
	[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,		[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
	DOI 10.17487/RFC5322, October 2008,		DOI 10.17487/RFC5322, October 2008, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc5322>.		editor.org/info/rfc5322>.
	[RFC5891] Klensin, J., "Internationalized Domain Names in		[RFC5891] Klensin, J., "Internationalized Domain Names in
	Applications (IDNA): Protocol", RFC 5891,		Applications (IDNA): Protocol", RFC 5891,
	DOI 10.17487/RFC5891, August 2010,		DOI 10.17487/RFC5891, August 2010, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc5891>.		editor.org/info/rfc5891>.
	[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6		[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
	Address Text Representation", RFC 5952,		Address Text Representation", RFC 5952,
	DOI 10.17487/RFC5952, August 2010,		DOI 10.17487/RFC5952, August 2010, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc5952>.		editor.org/info/rfc5952>.
	[RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'		[RFC6068] Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
	URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010,		URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010,
	<https://www.rfc-editor.org/info/rfc6068>.		<https://www.rfc-editor.org/info/rfc6068>.
	[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and		[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
	Verification of Domain-Based Application Service Identity		Verification of Domain-Based Application Service Identity
	within Internet Public Key Infrastructure Using X.509		within Internet Public Key Infrastructure Using X.509
	(PKIX) Certificates in the Context of Transport Layer		(PKIX) Certificates in the Context of Transport Layer
	Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March		Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
	skipping to change at page 23, line 12 ¶		skipping to change at page 23, line 12 ¶
	STD 73, RFC 6522, DOI 10.17487/RFC6522, January 2012,		STD 73, RFC 6522, DOI 10.17487/RFC6522, January 2012,
	<https://www.rfc-editor.org/info/rfc6522>.		<https://www.rfc-editor.org/info/rfc6522>.
	[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication		[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
	of Named Entities (DANE) Transport Layer Security (TLS)		of Named Entities (DANE) Transport Layer Security (TLS)
	Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August		Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
	2012, <https://www.rfc-editor.org/info/rfc6698>.		2012, <https://www.rfc-editor.org/info/rfc6698>.
	[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Semantics and Content", RFC 7231,		Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
	DOI 10.17487/RFC7231, June 2014,		DOI 10.17487/RFC7231, June 2014, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc7231>.		editor.org/info/rfc7231>.
	[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",		[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
	RFC 7405, DOI 10.17487/RFC7405, December 2014,		RFC 7405, DOI 10.17487/RFC7405, December 2014,
	<https://www.rfc-editor.org/info/rfc7405>.		<https://www.rfc-editor.org/info/rfc7405>.
	[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493,		[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493,
	DOI 10.17487/RFC7493, March 2015,		DOI 10.17487/RFC7493, March 2015, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc7493>.		editor.org/info/rfc7493>.
	8.2. Informative References		8.2. Informative References
	[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over		[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
	Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207,		Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207,
	February 2002, <https://www.rfc-editor.org/info/rfc3207>.		February 2002, <https://www.rfc-editor.org/info/rfc3207>.
	[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION		[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
	4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,		4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
	<https://www.rfc-editor.org/info/rfc3501>.		<https://www.rfc-editor.org/info/rfc3501>.
	[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration		[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
	Procedures for Message Header Fields", BCP 90, RFC 3864,		Procedures for Message Header Fields", BCP 90, RFC 3864,
	DOI 10.17487/RFC3864, September 2004,		DOI 10.17487/RFC3864, September 2004, <https://www.rfc-
	<https://www.rfc-editor.org/info/rfc3864>.		editor.org/info/rfc3864>.
	[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection		[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
	Most of the Time", RFC 7435, DOI 10.17487/RFC7435,		Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
	December 2014, <https://www.rfc-editor.org/info/rfc7435>.		December 2014, <https://www.rfc-editor.org/info/rfc7435>.
	[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning		[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
	Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April		Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April
	2015, <https://www.rfc-editor.org/info/rfc7469>.		2015, <https://www.rfc-editor.org/info/rfc7469>.
	[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based		[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
	Message Authentication, Reporting, and Conformance		Message Authentication, Reporting, and Conformance
	(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,		(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
	<https://www.rfc-editor.org/info/rfc7489>.		<https://www.rfc-editor.org/info/rfc7489>.
			[RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via
			Opportunistic DNS-Based Authentication of Named Entities
			(DANE) Transport Layer Security (TLS)", RFC 7672,
			DOI 10.17487/RFC7672, October 2015, <https://www.rfc-
			editor.org/info/rfc7672>.
	Appendix A. Example Reporting Policy		Appendix A. Example Reporting Policy
	A.1. Report using MAILTO		A.1. Report using MAILTO
	_smtp-tlsrpt.mail.example.com. IN TXT \		_smtp-tlsrpt.mail.example.com. IN TXT \
	"v=TLSRPTv1;rua=mailto:reports@example.com"		"v=TLSRPTv1;rua=mailto:reports@example.com"
	A.2. Report using HTTPS		A.2. Report using HTTPS
	_smtp-tlsrpt.mail.example.com. IN TXT \		_smtp-tlsrpt.mail.example.com. IN TXT \
	skipping to change at page 25, line 33 ¶		skipping to change at page 25, line 33 ¶
	},		},
	"failure-details": [{		"failure-details": [{
	"result-type": "certificate-expired",		"result-type": "certificate-expired",
	"sending-mta-ip": "98.136.216.25",		"sending-mta-ip": "98.136.216.25",
	"receiving-mx-hostname": "mx1.mail.company-y.example",		"receiving-mx-hostname": "mx1.mail.company-y.example",
	"failed-session-count": 100		"failed-session-count": 100
	}, {		}, {
	"result-type": "starttls-not-supported",		"result-type": "starttls-not-supported",
	"sending-mta-ip": "98.22.33.99",		"sending-mta-ip": "98.22.33.99",
	"receiving-mx-hostname": "mx2.mail.company-y.example",		"receiving-mx-hostname": "mx2.mail.company-y.example",
			"receiving-ip": "192.168.14.72",
	"failed-session-count": 200,		"failed-session-count": 200,
	"additional-information": "https://reports.company-x.example/		"additional-information": "https://reports.company-x.example/
	report_info ? id = 5065427 c - 23 d3# StarttlsNotSupported "		report_info ? id = 5065427 c - 23 d3# StarttlsNotSupported "
	}, {		}, {
	"result-type": "validation-failure",		"result-type": "validation-failure",
	"sending-mta-ip": "47.97.15.2",		"sending-mta-ip": "47.97.15.2",
			"receiving-ip": "10.72.84.12",
	"receiving-mx-hostname": "mx-backup.mail.company-y.example",		"receiving-mx-hostname": "mx-backup.mail.company-y.example",
	"failed-session-count": 3,		"failed-session-count": 3,
	"failure-error-code": "X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED"		"failure-error-code": "X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED"
	}]		}]
	}]		}]
	}		}
	Figure: Example JSON report for a messages from Company-X to Company-		Figure: Example JSON report for a messages from Company-X to Company-
	Y, where 100 sessions were attempted to Company Y servers with an		Y, where 100 sessions were attempted to Company Y servers with an
	expired certificate and 200 sessions were attempted to Company Y		expired certificate and 200 sessions were attempted to Company Y
	skipping to change at page 26, line 4 ¶		skipping to change at page 26, line 5 ¶
	"failed-session-count": 3,		"failed-session-count": 3,
	"failure-error-code": "X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED"		"failure-error-code": "X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED"
	}]		}]
	}]		}]
	}		}
	Figure: Example JSON report for a messages from Company-X to Company-		Figure: Example JSON report for a messages from Company-X to Company-
	Y, where 100 sessions were attempted to Company Y servers with an		Y, where 100 sessions were attempted to Company Y servers with an
	expired certificate and 200 sessions were attempted to Company Y		expired certificate and 200 sessions were attempted to Company Y
	servers that did not successfully respond to the "STARTTLS" command.		servers that did not successfully respond to the "STARTTLS" command.
	Additionally 3 sessions failed due to		Additionally 3 sessions failed due to
	"X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED".		"X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED".
	Authors' Addresses		Authors' Addresses
	Daniel Margolis		Daniel Margolis
	Google, Inc		Google, Inc
	Email: dmargolis (at) google (dot com)		Email: dmargolis@google.com
	Alexander Brotman		Alexander Brotman
	Comcast, Inc		Comcast, Inc
	Email: alex_brotman (at) comcast (dot com)		Email: alex_brotman@comcast.com
	Binu Ramakrishnan		Binu Ramakrishnan
	Yahoo!, Inc		Yahoo!, Inc
	Email: rbinu (at) yahoo-inc (dot com)		Email: rbinu@oath.com
	Janet Jones		Janet Jones
	Microsoft, Inc		Microsoft, Inc
	Email: janet.jones (at) microsoft (dot com)		Email: janet.jones@microsoft.com
	Mark Risher		Mark Risher
	Google, Inc		Google, Inc
	Email: risher (at) google (dot com)		Email: risher@google.com
End of changes. 37 change blocks.
	61 lines changed or deleted		81 lines changed or added
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/