< draft-ietf-marf-not-spam-feedback-02.txt		draft-ietf-marf-not-spam-feedback-03.txt >
	marf K. Li		marf K. Li
	Internet-Draft B. Leiba		Internet-Draft B. Leiba
	Intended status: Standards Track Huawei Technologies		Intended status: Standards Track Huawei Technologies
	Expires: March 22, 2012 September 19, 2011		Expires: March 25, 2012 September 22, 2011
	Email Feedback Report Type Value : not-spam		Email Feedback Report Type Value : not-spam
	draft-ietf-marf-not-spam-feedback-02		draft-ietf-marf-not-spam-feedback-03
	Abstract		Abstract
	This document defines a new Abuse Reporting Format (ARF) feedback		This document defines a new Abuse Reporting Format (ARF) feedback
	report type value: "not-spam". It can be used to report a message		report type value: "not-spam". It can be used to report an email
	that was mistakenly marked as spam.		message that was mistakenly marked as spam.
	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 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 March 22, 2012.		This Internet-Draft will expire on March 25, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 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 14 ¶		skipping to change at page 2, line 14 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Feedback Report Type: Not-Spam . . . . . . . . . . . . . . . 4		2. Feedback Report Type: Not-Spam . . . . . . . . . . . . . . . 4
	3. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 5		4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
	7.1. Normative References . . . . . . . . . . . . . . . . . . . . 6		7.1. Normative References . . . . . . . . . . . . . . . . . . . . 6
	7.2. Informative References . . . . . . . . . . . . . . . . . . . 6		7.2. Informative References . . . . . . . . . . . . . . . . . . . 7
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 7		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 7
	1. Introduction		1. Introduction
	In RFC 5965 [RFC5965], an Abuse Reporting Format (ARF) is defined for		In RFC 5965 [RFC5965], an Abuse Reporting Format (ARF) is defined for
	reporting email abuse. Currently two feedback report types are		reporting email abuse. Currently two feedback report types are
	defined that are related to the spam problem, and that can be used to		defined that are related to the spam problem, and that can be used to
	report abusive or fraudulent email messages:		report abusive or fraudulent email messages:
	o abuse: indicates unsolicited email or some other kind of email		o abuse: indicates unsolicited email or some other kind of email
	skipping to change at page 3, line 51 ¶		skipping to change at page 3, line 51 ¶
	own, but will be considered along with other information, analysis of		own, but will be considered along with other information, analysis of
	the message, etc. Because different users have different needs and		the message, etc. Because different users have different needs and
	different views of what constitutes spam, reports from one user might		different views of what constitutes spam, reports from one user might
	or might not be applicable to others. And because users might		or might not be applicable to others. And because users might
	sometimes press a "report not spam" button accidentally, immediate		sometimes press a "report not spam" button accidentally, immediate
	strong action, such as marking all similar messages as "good" based		strong action, such as marking all similar messages as "good" based
	on a single report, is probably not the right approach. Recipients		on a single report, is probably not the right approach. Recipients
	of "not-spam" reports need to consider what's right in their		of "not-spam" reports need to consider what's right in their
	environments.		environments.
	There are anti-spam systems that use "not spam" feedback today. All		There are anti-spam systems that use (non-standard) "not spam"
	of them take the reports and mix them with other spam reports and		feedback today. All of them take the reports and mix them with other
	other data, using their own algorithms, to determine appropriate		spam reports and other data, using their own algorithms, to determine
	action. In no case do the existing systems use a "not spam" report		appropriate action. In no case do the existing systems use a "not
	as an immediate, automatic override.		spam" report as an immediate, automatic override.
			The feedback types "abuse" and "not-spam" can be taken as opposites.
			A mistaken "not-spam" report could be countermanded by a subsequent
			"abuse" report from the same user, and an operator could consider
			collected reports of "abuse" and "not-spam" in making future
			assessments.
	2. Feedback Report Type: Not-Spam		2. Feedback Report Type: Not-Spam
	This document only defines a new feedback report type, "not-spam",		This document only defines a new feedback report type, "not-spam",
	extending the Email Feedback Reports specification [RFC5965].		extending the Email Feedback Reports specification [RFC5965].
	In the first MIME part of the feedback report message, the end user		In the first MIME part of the feedback report message, the end user
	or the email client can add information to indicate why the message		or the email client can add information to indicate why the message
	is not spam -- for example, because the originator or its domain is		is not considered as spam -- for example, because the originator or
	well known.		its domain is well known.
	3. Example		3. Example
	In the example, Joe, a pharmaceuticals sales representative, has		In the example, Joe, a pharmaceuticals sales representative, has
	received a message about discount pharmaceuticals. Because that is a		received a message about discount pharmaceuticals. Because that is a
	frequent subject of spam email, the message has been marked as spam		frequent subject of spam email, the message has been marked as spam
	-- incorrectly, in this case. Joe has reported it as "not-spam", and		-- incorrectly, in this case. Joe has reported it as "not-spam", and
	this is an example of the report, shortened (the "[...etc...]" part)		this is an example of the report, shortened (the "[...etc...]" part)
	for presentation here.		for presentation here.
	Note that the message is DKIM-signed [I-D.ietf-dkim-rfc4871bis], a		Note that the message is DKIM-signed [RFC6376], a good security
	good security practice as suggested in RFC 5965 section 8.2		practice as suggested in RFC 5965 section 8.2 [RFC5965].
	[RFC5965]. [[anchor3: RFC Editor: please replace the DKIM citation
	with a reference to RFC 6376, once it's published.]]
	DKIM-Signature: v=1; a=rsa-sha256; s=abuse; d=example.com;		DKIM-Signature: v=1; a=rsa-sha256; s=abuse; d=example.com;
	c=simple/simple; q=dns/txt; i=abusedesk@example.com;		c=simple/simple; q=dns/txt; i=abusedesk@example.com;
	h=From:Date:Subject:To:Message-ID:MIME-Version:Content-Type;		h=From:Date:Subject:To:Message-ID:MIME-Version:Content-Type;
	bh=iF4dMNYs/KepE0HuwfukJCDyjkduUzZFiaHqO9DMIPU=;		bh=iF4dMNYs/KepE0HuwfukJCDyjkduUzZFiaHqO9DMIPU=;
	b=e+BF8DCHFGqCp7/pExleNz7pVaLEoT+uWj/8H9DoZpxFI1vNnCTDu14w5v		b=e+BF8DCHFGqCp7/pExleNz7pVaLEoT+uWj/8H9DoZpxFI1vNnCTDu14w5v
	ze4mqJkldudVI0JspsYHTYeomhPklCV4F95GfwpM5W+ziUOv7AySTfygPW		ze4mqJkldudVI0JspsYHTYeomhPklCV4F95GfwpM5W+ziUOv7AySTfygPW
	EerczqZwAK88//oaYCFXq3XV9T/z+zlLp3rrirKGmCMCPPcbdSGv/Eg=		EerczqZwAK88//oaYCFXq3XV9T/z+zlLp3rrirKGmCMCPPcbdSGv/Eg=
	From: <abusedesk@example.com>		From: <abusedesk@example.com>
	Date: Thu, 8 Mar 2005 17:40:36 EDT		Date: Thu, 8 Mar 2005 17:40:36 EDT
	skipping to change at page 6, line 21 ¶		skipping to change at page 6, line 29 ¶
	5. IANA Considerations		5. IANA Considerations
	Registration is requested for the newly defined feedback type name:		Registration is requested for the newly defined feedback type name:
	"not-spam", according to the instructions in section 7.3 of the base		"not-spam", according to the instructions in section 7.3 of the base
	specification [RFC5965].		specification [RFC5965].
	Please add the following to the "Feedback Report Type Values"		Please add the following to the "Feedback Report Type Values"
	registry:		registry:
	Feedback Type Name: not-spam		Feedback Type Name: not-spam
	Description: Indicates that a message is not spam. This may be used		Description: Indicates that the entity providing the report does not
	to correct a message that was incorrectly tagged or categorized		consider the message to be spam. This may be used to correct a
	as spam.		message that was incorrectly tagged or categorized as spam.
	Published in: this document		Published in: this document
	Status: current		Status: current
	6. Acknowledgements		6. Acknowledgements
	The authors would like thank Murray S. Kucherawy and Bert		The authors would like thank Murray S. Kucherawy and Bert
	Greevenbosch for their discussion and review, and J.D. Falk for		Greevenbosch for their discussion and review, and J.D. Falk for
	suggesting some explanatory text.		suggesting some explanatory text.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[RFC5965] Shafranovich, Y., Levine, J., and M. Kucherawy, "An		[RFC5965] Shafranovich, Y., Levine, J., and M. Kucherawy, "An
	Extensible Format for Email Feedback Reports", RFC 5965,		Extensible Format for Email Feedback Reports", RFC 5965,
	August 2010.		August 2010.
	7.2. Informative References		7.2. Informative References
	[I-D.ietf-dkim-rfc4871bis]
	Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys
	Identified Mail (DKIM) Signatures",
	draft-ietf-dkim-rfc4871bis-15 (work in progress),
	July 2011.
	[I-D.ietf-marf-as]		[I-D.ietf-marf-as]
	Falk, J., "Creation and Use of Email Feedback Reports: An		Falk, J., "Creation and Use of Email Feedback Reports: An
	Applicability Statement for the Abuse Reporting Format		Applicability Statement for the Abuse Reporting Format
	(ARF)", draft-ietf-marf-as-00 (work in progress),		(ARF)", draft-ietf-marf-as-00 (work in progress),
	September 2011.		September 2011.
	[OMA-SpamRep-RD]		[OMA-SpamRep-RD]
	Open Mobile Alliance, "Mobile Spam Reporting		Open Mobile Alliance, "Mobile Spam Reporting
	Requirements", OMA-RD-SpamRep-V1_0 20101123-C,		Requirements", OMA-RD-SpamRep-V1_0 20101123-C,
	November 2010.		November 2010.
			[RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys
			Identified Mail (DKIM) Signatures", RFC 6376,
			September 2011.
	Authors' Addresses		Authors' Addresses
	Kepeng Li		Kepeng Li
	Huawei Technologies		Huawei Technologies
	Huawei Base, Bantian, Longgang District		Huawei Base, Bantian, Longgang District
	Shenzhen, Guangdong 518129		Shenzhen, Guangdong 518129
	P. R. China		P. R. China
	Phone: +86-755-28974289		Phone: +86-755-28974289
	Email: likepeng@huawei.com		Email: likepeng@huawei.com
End of changes. 12 change blocks.
	27 lines changed or deleted		29 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/