draft-ietf-uta-smtp-tlsrpt-12.txt		draft-ietf-uta-smtp-tlsrpt-13.txt
	skipping to change at page 1, line 16 ¶		skipping to change at page 1, line 16 ¶
	Expires: June 7, 2018 Comcast, Inc		Expires: June 7, 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		December 4, 2017
	SMTP TLS Reporting		SMTP TLS Reporting
	draft-ietf-uta-smtp-tlsrpt-12		draft-ietf-uta-smtp-tlsrpt-13
	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 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 . . . . . . . . . . . . . . . . . . . . . 15		5.4. HTTPS Transport . . . . . . . . . . . . . . . . . . . . . 16
	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 . . . . . . . . . . . . . . . . . . . 19		7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
	8.1. Normative References . . . . . . . . . . . . . . . . . . 21		8.1. Normative References . . . . . . . . . . . . . . . . . . 21
	8.2. Informative References . . . . . . . . . . . . . . . . . 23		8.2. Informative References . . . . . . . . . . . . . . . . . 23
	Appendix A. Example Reporting Policy . . . . . . . . . . . . . . 23		Appendix A. Example Reporting Policy . . . . . . . . . . . . . . 24
	A.1. Report using MAILTO . . . . . . . . . . . . . . . . . . . 23		A.1. Report using MAILTO . . . . . . . . . . . . . . . . . . . 24
	A.2. Report using HTTPS . . . . . . . . . . . . . . . . . . . 23		A.2. Report using HTTPS . . . . . . . . . . . . . . . . . . . 24
	Appendix B. Example JSON Report . . . . . . . . . . . . . . . . 23		Appendix B. Example JSON Report . . . . . . . . . . . . . . . . 24
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
	1. Introduction		1. Introduction
	The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and		The STARTTLS extension to SMTP [RFC3207] allows SMTP clients and
	hosts to establish secure SMTP sessions over TLS. The protocol		hosts to establish secure SMTP sessions over TLS. The protocol
	design is based on "Opportunistic Security" (OS) [RFC7435], which		design is based on "Opportunistic Security" (OS) [RFC7435], which
	maintains interoperability with clients that do not support STARTTLS		maintains interoperability with clients that do not support STARTTLS
	but means that any attacker who can delete parts of the SMTP session		but means that any attacker who can delete parts of the SMTP session
	(such as the "250 STARTTLS" response) or redirect the entire SMTP		(such as the "250 STARTTLS" response) or redirect the entire SMTP
	session (perhaps by overwriting the resolved MX record of the		session (perhaps by overwriting the resolved MX record of the
	skipping to change at page 5, line 38 ¶		skipping to change at page 5, line 38 ¶
	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) and exclamation
	; points (ASCII 0x21) MUST be encoded		; points (ASCII 0x21) 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
	skipping to change at page 13, line 10 ¶		skipping to change at page 13, line 10 ¶
	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:
	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 ; From the [@!RFC5321] that is used		sender = domain ; From the [RFC5321] that is used
	; as the domain for the `contact-info`		; as the domain for the `contact-info`
	; address in the report body		; address in the report body
	policy-domain = domain		policy-domain = domain
	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
	skipping to change at page 14, line 15 ¶		skipping to change at page 14, line 15 ¶
	Inside it, there are two parts: The first part is human readable,		Inside it, there are two parts: The first part is human readable,
	typically "text/plain", and the second part is machine readable with		typically "text/plain", and the second part is machine readable with
	a new media type defined called "application/tlsrpt+json". If		a new media type defined called "application/tlsrpt+json". If
	compressed, the report should use the media type "application/		compressed, the report should use the media type "application/
	tlsrpt+gzip".		tlsrpt+gzip".
	In addition, the following two new top level message header fields		In addition, the following two new top level message header fields
	are defined:		are defined:
	"TLS-Report-Domain: Receiver-Domain TLS-Report-Submitter: Sender-		"TLS-Report-Domain: Receiver-Domain TLS-Report-Submitter: Sender-
	Domain" The "TLS-Report-Submitter" value MUST match the value found		Domain"
	in the filename and the [RFC5321] domain from the "contact-info" from
	the report body. These message headers MUST be included and should		The "TLS-Report-Submitter" value MUST match the value found in the
	allow for easy searching for all reports submitted by a report domain		filename and the [RFC5321] domain from the "contact-info" from the
	or a particular submitter, for example in IMAP [RFC3501]:		report body. These message headers MUST be included and should allow
			for easy searching for all reports submitted by a report domain or a
			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. These		prescribed media type and filename, and ignore the rest. These
	additional headers SHOULD be included in the DKIM [RFC6376] signature		additional headers SHOULD be included in the DKIM [RFC6376] signature
	for the message.		for the message.
	The [RFC5322].Subject field for report submissions SHOULD conform to		The [RFC5322].Subject field for report submissions SHOULD 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		[CFWS] ; per [RFC5322]
	; (as with FWS)		; (as with FWS)
	The first domain-name indicates the DNS domain name about which the		The first domain-name indicates the DNS domain name about which the
	report was generated. The second domain-name indicates the DNS		report was generated. The second domain-name indicates the DNS
	domain name representing the Sending MTA generating the report. The		domain name representing the Sending MTA generating the report. The
	purpose of the Report-ID: portion of the field is to enable the		purpose of the Report-ID: portion of the field is to enable the
	Policy Domain to identify and ignore duplicate reports that might be		Policy Domain to identify and ignore duplicate reports that might be
	sent by a Sending MTA.		sent by a Sending MTA.
	For instance, this is a possible Subject field for a report to the		For instance, this is a possible Subject field for a report to the
	Policy Domain "example.net" from the Sending MTA		Policy Domain "example.net" from the Sending MTA
	"mail.sender.example.com". It is line-wrapped as allowed by		"mail.sender.example.com". It is line-wrapped as allowed by
			[RFC5322]:
	Subject: Report Domain: example.net		Subject: Report Domain: example.net
	Submitter: mail.sender.example.com		Submitter: mail.sender.example.com
	Report-ID: <735ff.e317+bf22029@mailexample.net>		Report-ID: <735ff.e317+bf22029@mailexample.net>
	5.3.1. Example Report		5.3.1. Example Report
	From: tlsrpt@mail.sender.example.com		From: tlsrpt@mail.sender.example.com
	Date: Fri, May 09 2017 16:54:30 -0800		Date: Fri, May 09 2017 16:54:30 -0800
	To: mts-sts-tlsrpt@example.net		To: mts-sts-tlsrpt@example.net
	Subject: Report Domain: example.net		Subject: Report Domain: example.net
End of changes. 11 change blocks.
	19 lines changed or deleted		23 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/