draft-ietf-uta-smtp-tlsrpt-07.txt		draft-ietf-uta-smtp-tlsrpt-08.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: February 1, 2018 Comcast, Inc		Expires: February 16, 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
	July 31, 2017		August 15, 2017
	SMTP TLS Reporting		SMTP TLS Reporting
	draft-ietf-uta-smtp-tlsrpt-07		draft-ietf-uta-smtp-tlsrpt-08
	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 [RFC3207], DANE
	[RFC6698], and MTA-STS (TODO: Add ref). These protocols can fail due		[RFC6698], and MTA-STS (TODO: Add ref). These protocols can fail due
	to misconfiguration or active attack, leading to undelivered messages		to misconfiguration or active attack, leading to undelivered messages
	or delivery over unencrypted or unauthenticated channels. This		or delivery over unencrypted or unauthenticated channels. This
	document describes a reporting mechanism and format by which sending		document describes a reporting mechanism and format by which sending
	systems can share statistics and specific information about potential		systems can share statistics and specific information about potential
	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 February 1, 2018.		This Internet-Draft will expire on February 16, 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 47 ¶		skipping to change at page 2, line 47 ¶
	4.3.3. General Failures . . . . . . . . . . . . . . . . . . 8		4.3.3. General Failures . . . . . . . . . . . . . . . . . . 8
	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 . . . . . . . . . . . . . . . . . . . . . . . 11		5. Report Delivery . . . . . . . . . . . . . . . . . . . . . . . 11
	5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 11		5.1. Report Filename . . . . . . . . . . . . . . . . . . . . . 11
	5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 12		5.2. Compression . . . . . . . . . . . . . . . . . . . . . . . 12
	5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 12		5.3. Email Transport . . . . . . . . . . . . . . . . . . . . . 12
	5.3.1. Example Report . . . . . . . . . . . . . . . . . . . 14		5.3.1. Example Report . . . . . . . . . . . . . . . . . . . 14
	5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 14		5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 14
	5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 15		5.5. Delivery Retry . . . . . . . . . . . . . . . . . . . . . 15
			5.6. Metadata Variances . . . . . . . . . . . . . . . . . . . 15
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	6.1. Message headers . . . . . . . . . . . . . . . . . . . . . 15		6.1. Message headers . . . . . . . . . . . . . . . . . . . . . 15
	6.2. Report Type . . . . . . . . . . . . . . . . . . . . . . . 15		6.2. Report Type . . . . . . . . . . . . . . . . . . . . . . . 15
	6.3. application/tlsrpt+json Media Type . . . . . . . . . . . 15		6.3. application/tlsrpt+json Media Type . . . . . . . . . . . 16
	6.4. application/tlsrpt+gz Media Type . . . . . . . . . . . . 17		6.4. application/tlsrpt+gzip Media Type . . . . . . . . . . . 17
	6.5. STARTTLS Validation Result Types . . . . . . . . . . . . 18		6.5. STARTTLS Validation Result Types . . . . . . . . . . . . 18
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 18		7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	8. Appendix 1: Example Reporting Policy . . . . . . . . . . . . 19		8. Appendix 1: Example Reporting Policy . . . . . . . . . . . . 19
	8.1. Report using MAILTO . . . . . . . . . . . . . . . . . . . 19		8.1. Report using MAILTO . . . . . . . . . . . . . . . . . . . 19
	8.2. Report using HTTPS . . . . . . . . . . . . . . . . . . . 19		8.2. Report using HTTPS . . . . . . . . . . . . . . . . . . . 19
	9. Appendix 2: Example JSON Report . . . . . . . . . . . . . . . 19		9. Appendix 2: Example JSON Report . . . . . . . . . . . . . . . 19
	10. Normative References . . . . . . . . . . . . . . . . . . . . 21		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
			10.1. Normative References . . . . . . . . . . . . . . . . . . 21
			10.2. Informative References . . . . . . . . . . . . . . . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
	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
	skipping to change at page 4, line 46 ¶		skipping to change at page 4, line 48 ¶
	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-tlsrpt". 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-tlsrpt.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 failures should be sent (see Section 4,		information about policy validation results should be sent (see
	"Reporting Schema", for more information). Two URI schemes are		Section 4, "Reporting Schema", for more information). Two URI
	supported: "mailto" and "https".		schemes are supported: "mailto" and "https". As with DMARC
			[RFC7489], the policy domain can specify a comma-separated list of
			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.		([RFC2818]) to the specified URI. Report submitters MAY ignore
			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 failures. This may mean that the reports are delivered in
	the clear.		the clear. Additionally, reports sent via SMTP MUST contain a
			valid DKIM [RFC6376] signature by the reporting domain. Reports
			lacking such a signature MUST be ignored by the recipient.
	The formal definition of the "_smtp-tlsrpt" TXT record, defined using		The formal definition of the "_smtp-tlsrpt" TXT record, defined using
	[RFC5234], is as follows:		[RFC5234], is as follows:
	tlsrpt-record = tlsrpt-version *WSP field-delim *WSP tlsrpt-rua		tlsrpt-record = tlsrpt-version *WSP field-delim *WSP tlsrpt-rua
	[field-delim [tlsrpt-extensions]]		[field-delim [tlsrpt-extensions]]
	field-delim = %x3B ; ";"		field-delim = %x3B ; ";"
	tlsrpt-version = %x76 *WSP "=" *WSP %x54 %x4C %x53 %x52		tlsrpt-version = %x76 *WSP "=" *WSP %x54 %x4C %x53 %x52
	%x50 %x54 %x76 %x31 ; "v=TLSRPTv1"		%x50 %x54 %x76 %x31 ; "v=TLSRPTv1"
	tlsrpt-rua = %x72 %x75 %x61 *WSP "=" *WSP tlsrpt-uri ; "rua=..."		tlsrpt-rua = %x72 %x75 %x61 *WSP "=" *WSP
			tlsrpt-uri *(*WSP "," *WSP tlsrpt-uri) ; "rua=..."
	tlsrpt-uri = URI		tlsrpt-uri = URI
	; "URI" is imported from [@!RFC3986]; commas (ASCII		; "URI" is imported from [@!RFC3986]; commas (ASCII
	; 0x2C) and exclamation points (ASCII 0x21)		; 0x2C) and exclamation points (ASCII 0x21)
	; MUST be encoded; the numeric portion MUST fit		; MUST be encoded; the numeric portion MUST fit
	; within an unsigned 64-bit integer		; within an unsigned 64-bit integer
	tlsrpt-extensions = tlsrpt-extension *(field-delim tlsrpt-extension)		tlsrpt-extensions = tlsrpt-extension *(field-delim tlsrpt-extension)
	[field-delim]		[field-delim]
	; extension fields		; extension fields
	skipping to change at page 6, line 42 ¶		skipping to change at page 6, line 45 ¶
	* A unique identifier for the report		* A unique identifier for the report
	* The reporting date range for the report		* The reporting date range for the report
	o Policy, consisting of:		o Policy, consisting of:
	* One of the following policy types: (1) The MTA-STS policy		* One of the following policy types: (1) The MTA-STS policy
	applied (as a string) (2) The DANE TLSA record applied (as a		applied (as a string) (2) The DANE TLSA record applied (as a
	string, with each RR entry of the RRset listed and separated by		string, with each RR entry of the RRset listed and separated by
	a semicolon) (3) The literal string "no-policy-found", if		a semicolon) (3) The literal string "no-policy-found", if
	neither a TLSA nor MTA-STS policy could be found.		neither a DANE nor MTA-STS policy could be found.
	* The domain for which the policy is applied		* The domain for which the policy is applied
	* The MX host		* The MX host
	* 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.
	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.		allow for easier correlation of failure events. To avoid a Denial of
			Service against the system processing the reports, the reports should
			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 "success-count": This indicates that the sending MTA was able to
	successfully negotiate a policy-compliant TLS connection, and		successfully negotiate a policy-compliant TLS connection, and
	serves to provide a "heartbeat" to receiving domains that		serves to provide a "heartbeat" to receiving domains that
	reporting is functional and tabulating correctly. This field		reporting is functional and tabulating correctly. This field
	contains an aggregate count of successful connections for the		contains an aggregate count of successful connections for the
	skipping to change at page 8, line 30 ¶		skipping to change at page 8, line 32 ¶
	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.		SERVFAIL for the requested TLSA record. It should be noted that
			if the reporter's systems are having problems resolving
			destination DNS records due to DNSSEC failures, it's possible they
			will also be unable to resolve the TLSRPT record, therefore these
			types of reports may be rare.
	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 10, line 32 ¶		skipping to change at page 10, line 38 ¶
	MTA-STS policy.		MTA-STS policy.
	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 is the Punycode-encoded
	A-label ([RFC3492]) and not the U-label.		A-label ([RFC3492]) and not the U-label.
	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].		Section 6.4.3 of [RFC6125]. In the case of Internationalized
			Domain Names ([RFC5891]), the domain is the Punycode-encoded
			A-label ([RFC3492]) and not the U-label.
	o "result-type": A value from Section 4.3, "Result Types", above.		o "result-type": A value from Section 4.3, "Result Types", above.
	In the case of Internationalized Domain Names ([RFC5891]), the
	domain is the Punycode-encoded A-label ([RFC3492]) and not the
	U-label.
	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.
	skipping to change at page 11, line 25 ¶		skipping to change at page 11, line 28 ¶
	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 an TLS-related
	error code or error message.		error 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 = DIGIT		dec-octet "." dec-octet "." dec-octet "." dec-octet
	; 0-9 / %x31-39 DIGIT ; 10-99 / "1" 2DIGIT ; 100-199 / "2" %x30-34		dec-octet = DIGIT ; 0-9 / %x31-39 DIGIT ; 10-99 / "1" 2DIGIT ;
	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.
	5.1. Report Filename		5.1. Report Filename
	The filename is typically constructed using the following ABNF:		The filename is RECOMMENDED to be constructed using the following
			ABNF:
	filename = sender "!" policy-domain "!" begin-timestamp		filename = sender "!" policy-domain "!" begin-timestamp
	"!" end-timestamp [ "!" unique-id ] "." extension		"!" end-timestamp [ "!" unique-id ] "." extension
	unique-id = 1*(ALPHA / DIGIT)		unique-id = 1*(ALPHA / DIGIT)
	sender = domain ; imported from [@!RFC5321]		sender = domain ; imported from [@!RFC5321]
	policy-domain = domain		policy-domain = domain
	skipping to change at page 13, line 21 ¶		skipping to change at page 13, line 21 ¶
	TLS-Report-Submitter: Sender-Domain		TLS-Report-Submitter: Sender-Domain
	These message headers MUST be included and should allow for easy		These message headers MUST be included and should allow for easy
	searching for all reports submitted by a report domain or a		searching for all reports submitted by a report domain or a
	particular submitter, for example in IMAP [RFC3501]:		particular submitter, for example in IMAP [RFC3501]:
	"s SEARCH HEADER "TLS-Report-Domain" "example.com""		"s SEARCH HEADER "TLS-Report-Domain" "example.com""
	It is presumed that the aggregate reporting address will be equipped		It is presumed that the aggregate reporting address will be equipped
	to process new message header fields and extract MIME parts with the		to process new message header fields and extract MIME parts with the
	prescribed media type and filename, and ignore the rest.		prescribed media type and filename, and ignore the rest. These
			additional headers SHOULD be included in the DKIM [RFC6376] signature
			for the message.
	The [RFC5322].Subject field for individual report submissions SHOULD		The [RFC5322].Subject field for report submissions SHOULD conform to
	conform to the following ABNF:		the following ABNF:
	tlsrpt-subject = %s"Report" FWS ; "Report"		tlsrpt-subject = %s"Report" FWS ; "Report"
	%s"Domain:" FWS ; "Domain:"		%s"Domain:" FWS ; "Domain:"
	domain-name FWS ; per RFC6376		domain-name FWS ; per RFC6376
	%s"Submitter:" FWS ; "Submitter:"		%s"Submitter:" FWS ; "Submitter:"
	domain-name FWS ; per RFC6376		domain-name FWS ; per RFC6376
	%s"Report-ID:" FWS ; "Report-ID:		%s"Report-ID:" FWS ; "Report-ID:
	"<" id-left "@" id-right ">" ; per RFC5322		"<" id-left "@" id-right ">" ; per RFC5322
	[CFWS] ; per RFC5322 (as with FWS)		[CFWS] ; per RFC5322 (as with FWS)
	skipping to change at page 14, line 46 ¶		skipping to change at page 14, line 46 ¶
	------=_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		"application/tlsrpt+json" otherwise (see section Section 6, "IANA
	Considerations").		Considerations").
	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, they should be on a logarithmic		multiple retries are attempted, ideally they would be on a
	scale.		logarithmic scale.
			5.6. Metadata Variances
			As stated above, there are a variable number of ways to declare
			information about the data therein. If it should be the case that
			these objects were to disagree, then the report data contained within
			the JSON body MUST be considered the authoritative source for those
			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 16, line 47 ¶		skipping to change at page 17, line 4 ¶
	Magic number(s): n/a		Magic number(s): n/a
	File extension(s): ".json"		File extension(s): ".json"
	Macintosh file type code(s): n/a		Macintosh file type code(s): n/a
	Person & email address to contact for further information: See		Person & email address to contact for further information: See
	Authors' Addresses section.		Authors' Addresses section.
	Intended usage: COMMON		Intended usage: COMMON
	Restrictions on usage: n/a		Restrictions on usage: n/a
	Author: See Authors' Addresses section.		Author: See Authors' Addresses section.
	Change controller: Internet Engineering Task Force		Change controller: Internet Engineering Task Force
	(mailto:iesg@ietf.org).		(mailto:iesg@ietf.org).
	6.4. application/tlsrpt+gz Media Type		6.4. application/tlsrpt+gzip Media Type
	+-------------+----------------+-------------+-------------------+		+-------------+----------------+-------------+-------------------+
	| Type | Subtype | File extn | Specification |		| Type | Subtype | File extn | Specification |
	+-------------+----------------+-------------+-------------------+		+-------------+----------------+-------------+-------------------+
	| application | tlsrpt+gzip | .gz | Section 5.3 |		| application | tlsrpt+gzip | .gz | Section 5.3 |
	+-------------+----------------+-------------+-------------------+		+-------------+----------------+-------------+-------------------+
	Table 2: SMTP TLS Reporting Media Type		Table 2: SMTP TLS Reporting Media Type
	Type name: application		Type name: application
	Subtype name: tlsrpt+gzip		Subtype name: tlsrpt+gzip
	Required parameters: n/a		Required parameters: n/a
	Optional parameters: n/a		Optional parameters: n/a
	Encoding considerations: Encoding considerations are identical to		Encoding considerations: Binary
	those specified for the "application/json" media type. See
	[RFC7493].
	Security considerations: Security considerations relating to SMTP TLS		Security considerations: Security considerations relating to SMTP TLS
	Reporting are discussed in Section 7.		Reporting are discussed in Section 7.
	Interoperability considerations: This document specifies format of		Interoperability considerations: This document specifies format of
	conforming messages and the interpretation thereof.		conforming messages and the interpretation thereof.
	Published specification: Section 5.3 of this document.		Published specification: Section 5.3 of this document.
	Applications that use this media type: Mail User Agents (MUA) and		Applications that use this media type: Mail User Agents (MUA) and
	skipping to change at page 20, line 21 ¶		skipping to change at page 20, line 21 ¶
	"report-id": "5065427c-23d3-47ca-b6e0-946ea0e8c4be",		"report-id": "5065427c-23d3-47ca-b6e0-946ea0e8c4be",
	"policy": {		"policy": {
	"policy-type": "sts",		"policy-type": "sts",
	"policy-string": "{ \"version\": \"STSv1\",\"mode\": \"report\", \"mx\": [\".mail.company-y.com\"], \"max_age\": 86400 }",		"policy-string": "{ \"version\": \"STSv1\",\"mode\": \"report\", \"mx\": [\".mail.company-y.com\"], \"max_age\": 86400 }",
	"policy-domain": "company-y.com",		"policy-domain": "company-y.com",
	"mx-host": ".mail.company-y.com"		"mx-host": ".mail.company-y.com"
	},		},
	"summary": {		"summary": {
	"total-successful-session-count": 5326,		"total-successful-session-count": 5326,
	"total-failure-session-count": 303		"total-failure-session-count": 303
	}		},
	"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.com",		"receiving-mx-hostname": "mx1.mail.company-y.com",
	"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.com",		"receiving-mx-hostname": "mx2.mail.company-y.com",
	"failed-session-count": 200,		"failed-session-count": 200,
	"additional-information": "hxxps://reports.company-x.com/		"additional-information": "hxxps://reports.company-x.com/
	report_info?id=5065427c-23d3#StarttlsNotSupported"		report_info?id=5065427c-23d3#StarttlsNotSupported"
	}, {		}, {
	"result-type: "validation-failure",		"result-type": "validation-failure",
	"sending-mta-ip": "47.97.15.2",		"sending-mta-ip": "47.97.15.2",
	"receiving-mx-hostname: "mx-backup.mail.company-y.com",		"receiving-mx-hostname": "mx-backup.mail.company-y.com",
	"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		Figure: Example JSON report for a 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
	"X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED".		"X509_V_ERR_PROXY_PATH_LENGTH_EXCEEDED".
	10. Normative References		10. 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, DOI 10.17487/		Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
	RFC2119, March 1997,		RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/		[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/
	RFC2818, May 2000,		RFC2818, May 2000,
	<http://www.rfc-editor.org/info/rfc2818>.		<http://www.rfc-editor.org/info/rfc2818>.
	[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
	Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207,
	February 2002, <http://www.rfc-editor.org/info/rfc3207>.
	[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,
	<http://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,
	<http://www.rfc-editor.org/info/rfc3492>.		<http://www.rfc-editor.org/info/rfc3492>.
	[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
	4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
	<http://www.rfc-editor.org/info/rfc3501>.
	[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
	Procedures for Message Header Fields", BCP 90, RFC 3864,
	DOI 10.17487/RFC3864, September 2004,
	<http://www.rfc-editor.org/info/rfc3864>.
	[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, RFC		Resource Identifier (URI): Generic Syntax", STD 66, RFC
	3986, DOI 10.17487/RFC3986, January 2005,		3986, DOI 10.17487/RFC3986, January 2005,
	<http://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, DOI 10.17487/		Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/
	RFC5234, January 2008,		RFC5234, January 2008,
	<http://www.rfc-editor.org/info/rfc5234>.		<http://www.rfc-editor.org/info/rfc5234>.
	skipping to change at page 22, line 30 ¶		skipping to change at page 22, line 21 ¶
	URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010,		URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010,
	<http://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, <http://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.,
			"DomainKeys Identified Mail (DKIM) Signatures", STD 76,
			RFC 6376, DOI 10.17487/RFC6376, September 2011,
			<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", STD		the Reporting of Mail System Administrative Messages", STD
	73, RFC 6522, DOI 10.17487/RFC6522, January 2012,		73, RFC 6522, DOI 10.17487/RFC6522, January 2012,
	<http://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, <http://www.rfc-editor.org/info/rfc6698>.		2012, <http://www.rfc-editor.org/info/rfc6698>.
	[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data		[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
	Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March		Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
	2014, <http://www.rfc-editor.org/info/rfc7159>.		2014, <http://www.rfc-editor.org/info/rfc7159>.
			[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
			[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
			Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207,
			February 2002, <http://www.rfc-editor.org/info/rfc3207>.
			[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
			4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
			<http://www.rfc-editor.org/info/rfc3501>.
			[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
			Procedures for Message Header Fields", BCP 90, RFC 3864,
			DOI 10.17487/RFC3864, September 2004,
			<http://www.rfc-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, <http://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, <http://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,
	<http://www.rfc-editor.org/info/rfc7489>.		<http://www.rfc-editor.org/info/rfc7489>.
	[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI
	10.17487/RFC7493, March 2015,
	<http://www.rfc-editor.org/info/rfc7493>.
	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. 35 change blocks.
	57 lines changed or deleted		87 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/