One document matched: draft-ietf-marf-as-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC1939 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1939.xml">
<!ENTITY RFC2026 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2026.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2505 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2505.xml">
<!ENTITY RFC2616 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml">
<!ENTITY RFC3501 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3501.xml">
<!ENTITY RFC5321 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5321.xml">
<!ENTITY RFC5322 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5322.xml">
<!ENTITY RFC5965 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5965.xml">
<!ENTITY RFC5598 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5598.xml">
<!ENTITY I-D.jdfalk-maawg-cfblbcp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.jdfalk-maawg-cfblbcp.xml">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?rfc strict="no" ?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes" ?>
<?rfc comments="yes" ?>

<rfc category="std" docName="draft-ietf-marf-as-00" ipr="trust200902" updates="5965">
	<front>
		<title abbrev="ARF AS">
			Creation and Use of Email Feedback Reports:
			An Applicability Statement for the Abuse Reporting Format (ARF)</title>
		<author fullname="J.D. Falk" initials="J.D." surname="Falk">
			<organization>Return Path</organization>
			<address>
				<postal>
					<street>100 Mathilda Street, Suite 100</street>
					<city>Sunnyvale</city>
					<region>CA</region>
					<code>94089</code>
					<country>USA</country>
				</postal>
				<!-- <phone/> -->
				<!-- <facsimile/> -->
				<email>ietf@cybernothing.org</email>
				<uri>http://www.returnpath.net/</uri>
			</address>
		</author>
		<date year="2011"/>
		<area>Applications</area>
		<workgroup>MARF Working Group</workgroup>
		<keyword>arf</keyword>
		<keyword>marf</keyword>
		<keyword>abuse reporting</keyword>
		<keyword>spam reporting</keyword>
		<abstract>
			<t> RFC 5965 defines an extensible, machine-readable format intended for mail operators to report feedback about
				received email to other parties.  This document describes one common method for utilizing this format for 
				reporting at scale between large mailbox providers, and from large mailbox providers to other mail sending 
				entities. </t>
		</abstract>
	</front>
	
	<middle>
		<section title="Introduction">
			<t> The Abuse Reporting Format (ARF) was initially developed for two very specific use cases.  Initially, it was 
				intended to be used for reporting feedback between large email operators, or from large email operators to end user
				network access operators, any of whom could be presumed to have automated abuse-handling systems.  Secondarily, it  
				is used by those same large mail operators to send those same reports to other entities, including those involved 
				in sending bulk email for commercial purposes.  In either case, the reports would be triggered by direct end user 
				action such as clicking on a "report spam" button in their email client. </t>
				
			<t> Though other uses for the format defined in <xref target="RFC5965"/> have been discussed (and may be documented
				similarly in the future), those were (and remain) the primary applications. </t>
				
			<t> Further introduction to this topic may be found in <xref target="I-D.jdfalk-maawg-cfblbcp"/>. </t>
			
			<section title="Definitions">
				<t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
					"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
        			this document are to be interpreted as described in
        			<xref target="RFC2119"/>, and are intended to replace the Requirement Levels described in
					section 3.3 of <xref target="RFC2026"/>. </t>
				
				<t> Some of the terminology used in this document is taken from <xref target="RFC5598"/>. </t>
								
				<t> "Mailbox Provider" refers to an organization that accepts, stores, and offers access to 
					<xref target="RFC5322"/> messages ("email messages") for end users.  Such an organization MUST have implemented
					SMTP (<xref target="RFC5321"/>), and MAY provide access to messages through IMAP (<xref target="RFC3501"/>), 
					POP (<xref target="RFC1939"/>), a proprietary interface designed for HTTP (<xref target="RFC2616"/>), or a
					proprietary protocol. </t>
			</section>
			
			<note title="Applicability Statement?">
				<t> [RFC Editor: please remove this section prior to publication.] </t>

				<t> This document is part of the experiment to reintroduce Applicability Statements, as defined in 
				section 3.2 of <xref target="RFC2026"/>, to the Applications Area. </t>
			</note>
			
			<section title="Discussion">
				<t> [RFC Editor: please remove this section prior to publication.] </t>
				
				<t> This document is being discussed within the IETF MARF Working Group, on the marf@ietf.org mailing list. </t>
			</section>
		</section>
		
		<section title="Creating and Sending Complaint-Based Reports">
			<t>
				<list style="numbers">
					<t> A Mailbox Provider receives reports of abusive or unwanted mail from their users, most often by providing 
						a "report spam" button (or similar nomenclature) in the MUA.  The method of transferring this message and
						any associated metadata from the MUA to the Mailbox Provider's ARF processing system is not defined by any
						standards document, but is discussed further in section 3.2 of <xref target="I-D.jdfalk-maawg-cfblbcp"/>.  
						Policy concerns related to the collection of this data are discussed in section 3.4 of 
						<xref target="I-D.jdfalk-maawg-cfblbcp"/>. </t>
						
					<t> The Mailbox Provider SHOULD process the reports to improve their spam filtering systems.  The design of
						these systems is discussed in <xref target="RFC2505"/> and elsewhere. </t>
							
					<t> The Mailbox Provider SHOULD (but is not required to) send reports to relevant parties who have requested
						to receive such reports.  The reports MUST be formatted per <xref target="RFC5965"/>, and transmitted as an
						<xref target="RFC5322"/> message using <xref target="RFC5321"/>. The process whereby such parties may 
						request the reports is discussed in section 3.5 of <xref target="I-D.jdfalk-maawg-cfblbcp"/>.</t>
					
					<t> The reports SHOULD use "Feedback-Type: abuse", but MAY use other types if appropriate.  However, the
						Mailbox Provider generating the reports SHOULD NOT assume that the operator receiving the reports will
						treat different Feedback-Types differently. </t>
					
					<t> The reports SHOULD include the following optional fields: Original-Mail-From, Arrival-Date, Source-IP,
						Original-Rcpt-To.  Other optional fields MAY be included, as the implementor feels is appropriate. </t>

					<t> Ongoing maintenance of an ARF processing system is discussed in section 3.6 of
						<xref target="I-D.jdfalk-maawg-cfblbcp"/>. </t>
				</list>
			</t>
		</section>
			
		<section title="Receiving and Processing Complaint-Based Reports">
			<t>
				<list style="numbers">
					<t> At the time this document is being written, for the use cases described here, mail operators need to 
						proactively request a stream of ARF reports from Mailbox Providers.	Recommendations for preparing to make 
						that request are discussed in section 4.1 of <xref target="I-D.jdfalk-maawg-cfblbcp"/>. </t>
						
					<t> Mail operators MUST be prepared to receive reports formatted per <xref target="RFC5965"/> as
						<xref target="RFC5322"/> messages via <xref target="RFC5321"/>.  These and other types of
						<xref target="RFC5322"/> messages which may be received at discussed in section 4.2 of
						<xref target="I-D.jdfalk-maawg-cfblbcp"/>. </t>
						
					<t> Mail operators SHOULD utilize an automated system to receive and process these reports, as discussed in 
						section 4.4 of <xref target="I-D.jdfalk-maawg-cfblbcp"/>. </t>
						
					<t> This system MUST accept all Feedback-Types defined in <xref target="RFC5965"/>, but implementors
						SHOULD NOT assume that Mailbox Providers will use any Feedback-Type other than "abuse".  Additional
						logic may be required to separate different types of abuse reports after receipt. </t>
						
					<t> Implementors SHOULD NOT expect all Mailbox Providers to include the same optional fields. </t>
						
					<t> Actions that mail operators MAY take upon receiving a report (or multiple reports) are discussed in
						section 4.3 of <xref target="I-D.jdfalk-maawg-cfblbcp"/>. </t>
				</list>
			</t>			
		</section>
		
		<section title="Other Applications">
			<t> What is described here is the most common application of <xref target="RFC5965"/>, and provides a starting point
				for additional applications, but it is certainly not the only possible application.  Other uses for ARF could 
				include direct complaint submissions from MUAs, reports triggered by mail sent to "spam trap" addresses without 
				human involvement, reports of authentication failures, virus reports, and so forth.  These applications may be 
				described in other IETF documents. </t>
		</section>
	
		<section anchor="IANA" title="IANA Considerations">
			<t> [RFC Editor: please remove this section prior to publication.] </t>
			
			<t> This document has no IANA actions. </t>
    	</section>

		<section anchor="Security" title="Security Considerations">
			<t> Implementers are strongly urged to review, at a minimum, the Security Considerations sections of 
				<xref target="RFC5965"/> and <xref target="I-D.jdfalk-maawg-cfblbcp"/>. </t>
    	</section>

		<section anchor="Acknowledgements" title="Acknowledgements">
			<t> This document is a product of the IETF MARF Working Group, chaired by Barry Leiba and Murray Kucherawy.  The idea 
				to present it in the form of an Applicability Statement originated (I believe) with Pete Resnick. </t>
				
			<t> All of the Best Practices referenced by this document are found in <xref target="I-D.jdfalk-maawg-cfblbcp"/>, 
			    written within the Collaboration Committee of the Messaging Anti-Abuse Working Group (MAAWG) -- which is described 
			    further in <xref target="I-D.jdfalk-maawg-cfblbcp"/>. </t>
				
			<t> Finally, I must thank the doctors and staff at the University of Texas MD Anderson Cancer Center for doing what
				they do. </t>
    	</section>
	</middle>
	
	<back>
		<references title="Normative References">
      		&RFC2119;
			&RFC5321;
			&RFC5322;
      		&RFC5965;
      		&RFC5598;
    	</references>
		<references title="Informative References">
			&RFC1939;
			&RFC2026;
			&RFC2505;
			&RFC2616;
			&RFC3501;
      		&I-D.jdfalk-maawg-cfblbcp;
    	</references>
	</back>
</rfc>