draft-ietf-marf-as-15.txt		draft-ietf-marf-as.txt
	MARF Working Group J. Falk		MARF Working Group J. Falk
	Internet-Draft Return Path		Internet-Draft Return Path
	Updates: 5965 (if approved) M. Kucherawy, Ed.		Updates: 5965 (if approved) M. Kucherawy, Ed.
	Intended status: Standards Track Cloudmark		Intended status: Standards Track Cloudmark
	Expires: October 27, 2012 April 25, 2012		Expires: October 27, 2012 April 25, 2012
	Creation and Use of Email Feedback Reports: An Applicability Statement		Creation and Use of Email Feedback Reports: An Applicability Statement
	for the Abuse Reporting Format (ARF)		for the Abuse Reporting Format (ARF)
	draft-ietf-marf-as-15		draft-ietf-marf-as-16
	Abstract		Abstract
	RFC 5965 defines an extensible, machine-readable format intended for		RFC 5965 defines an extensible, machine-readable format intended for
	mail operators to report feedback about received email to other		mail operators to report feedback about received email to other
	parties. This Applicability Statement describes common methods for		parties. This Applicability Statement describes common methods for
	utilizing this format for reporting both abuse and authentication		utilizing this format for reporting both abuse and authentication
	failure events. Mailbox Providers of any size, mail sending		failure events. Mailbox Providers of any size, mail sending
	entities, and end users can use these methods as a basis to create		entities, and end users can use these methods as a basis to create
	procedures that best suit them. Some related optional mechanisms are		procedures that best suit them. Some related optional mechanisms are
	skipping to change at page 3, line 45		skipping to change at page 3, line 45
	memo.		memo.
	Further introduction to this topic may be found in [RFC6449], which		Further introduction to this topic may be found in [RFC6449], which
	is effectively an Applicability Statement written outside of the IETF		is effectively an Applicability Statement written outside of the IETF
	and thus never achieved IETF consensus. Much of the content for that		and thus never achieved IETF consensus. Much of the content for that
	document was input to this one.		document was input to this one.
	At the time of publication of this document, five feedback types are		At the time of publication of this document, five feedback types are
	registered. This document only discusses two of them ("abuse" and		registered. This document only discusses two of them ("abuse" and
	"auth-failure") as they are seeing sufficient use in practice that		"auth-failure") as they are seeing sufficient use in practice that
	applicability statements can be made about them. The others are		applicability statements can be made about them. The others, i.e.,
	either too new or too seldomly used to be included here.		"fraud" [RFC5965] and "not-spam" [RFC6430], are either too new or too
			seldomly used to be included here.
	1.1. Discussion		1.1. Discussion
	[RFC Editor: please remove this section prior to publication.]		[RFC Editor: please remove this section prior to publication.]
	This document is being discussed within the IETF MARF Working Group,		This document is being discussed within the IETF MARF Working Group,
	on the marf@ietf.org mailing list.		on the marf@ietf.org mailing list.
	2. Definitions		2. Definitions
	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], and are		document are to be interpreted as described in [RFC2119], and are
	intended to replace the Requirement Levels described in Section 3.3		intended to replace the Requirement Levels described in Section 3.3
	of [RFC2026].		of [RFC2026].
	skipping to change at page 6, line 12		skipping to change at page 6, line 12
	email messages that can be received are discussed in Section 4.2		email messages that can be received are discussed in Section 4.2
	of [RFC6449].		of [RFC6449].
	3. Recipients of feedback reports that are part of formal feedback		3. Recipients of feedback reports that are part of formal feedback
	arrangements have to be capable of handling large volumes of		arrangements have to be capable of handling large volumes of
	reports. This could require automation of report processing.		reports. This could require automation of report processing.
	Discussion of this can be found in Section 4.4 of [RFC6449].		Discussion of this can be found in Section 4.4 of [RFC6449].
	4.5. What To Expect		4.5. What To Expect
	1. An automated report processing system MUST accept all Feedback-		1. The list of vaild Feedback-Types is defined in [RFC5965], which
	Types defined in [RFC5965] or extensions to it. This means the		created an IANA registry for valid values to allow for
	implementers need to provide mechanisms to add support for new		extensions. However, an automated report processing system MUST
	types as they are defined and registered, possibly including new		NOT reject (in the SMTP sense) a report based on an unknown
	processing steps (such as when new reporting fields are added to		Feedback-Type, to allow for handling of new types that are not
	a type). However, Mailbox Providers might only make use of the		yet supported. The automated system can simply set reports of
	"abuse" Feedback-Type. Therefore, report receivers might be		unknown types aside for manual handling. However, Mailbox
	required to do additional analysis to separate different types of		Providers might only make use of the "abuse" Feedback-Type.
	abuse reports after receipt if they do not have prior specific		Therefore, report receivers might be required to do additional
	knowledge of the sender of the report.		analysis to separate different types of abuse reports after
			receipt if they do not have prior specific knowledge of the
			sender of the report.
	2. Reports receivers MUST accept reports that have obscured their		2. Reports receivers MUST accept reports that have obscured their
	user-identifiable data as described in [RFC6590]. That document		user-identifiable data as described in [RFC6590]. That document
	also discusses the handling of such reports. This technique is		also discusses the handling of such reports. This technique is
	also discussed in Section 4.4 of [RFC6449].		also discussed in Section 4.4 of [RFC6449].
	4.6. What To Do With Reports		4.6. What To Do With Reports
	1. Section 4.3 of [RFC6449] discusses actions that mail operators		1. Section 4.3 of [RFC6449] discusses actions that mail operators
	might take upon receiving a report (or multiple reports).		might take upon receiving a report (or multiple reports).
	skipping to change at page 11, line 36		skipping to change at page 11, line 37
	Also, these reports may be forged as easily as ordinary Internet		Also, these reports may be forged as easily as ordinary Internet
	electronic mail. User agents and automatic mail handling facilities		electronic mail. User agents and automatic mail handling facilities
	(such as mail distribution list exploders) that wish to make		(such as mail distribution list exploders) that wish to make
	automatic use of reports of any kind should take appropriate		automatic use of reports of any kind should take appropriate
	precautions to minimize the potential damage from denial-of-service		precautions to minimize the potential damage from denial-of-service
	attacks.		attacks.
	Perhaps the simplest means of mitigating this threat is to assert		Perhaps the simplest means of mitigating this threat is to assert
	that these reports should themselves be signed with something like		that these reports should themselves be signed with something like
	DKIM or authorized by SPF. On the other hand, if there is a problem		DKIM and/or authorized by something like SPF. Note, however, that if
	with the DKIM infrastructure at the Verifier, signing DKIM failure		there is a problem with the email infrastructure at either end, DKIM
	reports may produce reports that aren't trusted or even accepted by		and/or SPF may result in reports that aren't trusted or even accepted
	their intended recipients. Similar issues could exist with SPF		by their intended recipients, so it is important to make sure those
	evaluation. Use of both technologies can mitigate this risk to a		components are properly configured. Use of both technologies in
	degree.		tandem can resolve this concern to a degree since they generally have
			disjoint failure modes.
	8.3. Amplification Attacks		8.3. Amplification Attacks
	Failure to comply with the recommendations regarding selection of the		Failure to comply with the recommendations regarding selection of the
	envelope sender can lead to amplification denial-of-service attacks.		envelope sender can lead to amplification denial-of-service attacks.
	This is discussed in Section 6 as well as in [RFC3464].		This is discussed in Section 6 as well as in [RFC3464].
	8.4. Automatic Generation		8.4. Automatic Generation
	ARF ([RFC5965]) reports have historically been generated individually		ARF ([RFC5965]) reports have historically been generated individually
	skipping to change at page 15, line 16		skipping to change at page 15, line 16
	for Authorizing Use of Domains in E-Mail, Version 1",		for Authorizing Use of Domains in E-Mail, Version 1",
	RFC 4408, April 2006.		RFC 4408, April 2006.
	[RFC5617] Allman, E., Fenton, J., Delany, M., and J. Levine,		[RFC5617] Allman, E., Fenton, J., Delany, M., and J. Levine,
	"DomainKeys Identified Mail (DKIM) Author Domain Signing		"DomainKeys Identified Mail (DKIM) Author Domain Signing
	Practices (ADSP)", RFC 5617, August 2009.		Practices (ADSP)", RFC 5617, August 2009.
	[RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys		[RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys
	Identified Mail (DKIM) Signatures", RFC 6376,		Identified Mail (DKIM) Signatures", RFC 6376,
	September 2011.		September 2011.
			[RFC6430] Li, K. and B. Leiba, "Email Feedback Report Type Value:
			not-spam", RFC 6430, November 2011.
	[RFC6449] Falk, J., "Complaint Feedback Loop Operational		[RFC6449] Falk, J., "Complaint Feedback Loop Operational
	Recommendations", RFC 6449, November 2011.		Recommendations", RFC 6449, November 2011.
	[RFC6590] Falk, J. and M. Kucherawy, "Redaction of Potentially		[RFC6590] Falk, J. and M. Kucherawy, "Redaction of Potentially
	Sensitive Data from Mail Abuse Reports", RFC 6590,		Sensitive Data from Mail Abuse Reports", RFC 6590,
	April 2012.		April 2012.
	Authors' Addresses		Authors' Addresses
End of changes. 6 change blocks.
	20 lines changed or deleted		26 lines changed or added
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/