One document matched: draft-ietf-marf-as-01.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 RFC6449 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6449.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-01" 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>
		<author initials="M." surname="Kucherawy"
			fullname="M. Kucherawy" role="editor">
			<organization>Cloudmark</organization>
			<address>
				<postal>
					<street>128 King St., 2nd Floor</street>
					<city>San Francisco</city>
					<region>CA</region>
					<code>94107</code>
					<country>US</country>
				</postal>
				<email>msk@cloudmark.com</email>
			</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>

			<t> [NOTE TO EDITOR: Murray Kucherawy is listed as an
			     author only to enable him to complete the
			     publication process on behalf of J.D. Falk.
			     Please remove Murray from the author list prior
			     to publication.] </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="RFC6449"/>. </t>
		</section>
			
		<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 has typically
			    implemented SMTP
			    (<xref target="RFC5321"/>), and might
			    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>
			
		<section 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>
		</section>
			
		<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 title="Creating and Sending Complaint-Based Reports">
			<t>
			    <list style="numbers">
				<t> A Mailbox Provider receives reports of
				    abusive or unwanted mail from its 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="RFC6449"/>.  Policy concerns
				    related to the collection of this data
				    are discussed in Section 3.4 of
				    that document. </t>

				<t> The Mailbox Provider SHOULD process the
				    reports to improve its spam filtering
				    systems.  The design of these systems is
				    discussed in <xref target="RFC2505"/> and
				    elsewhere. </t>
							
				<t> The Mailbox Provider SHOULD 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 email message
				    (<xref target="RFC5322"/>), typically
				    using SMTP (<xref target="RFC5321"/>).
				    The process whereby such parties may 
				    request the reports is discussed in
				    Section 3.5 of
				    <xref target="RFC6449"/>.</t>
					
				<t> The reports SHOULD use
				    "Feedback-Type: abuse", but MAY use other
				    types as 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 whenever practical:
				    Original-Mail-From, Arrival-Date,
				    Source-IP, Original-Rcpt-To.  Other
				    optional fields MAY be included, as the
				    implementer feels is appropriate. </t>

				<t> Ongoing maintenance of an ARF processing
				    system is discussed in Section 3.6 of
				    <xref target="RFC6449"/>. </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="RFC6449"/>. </t>
						
				<t> Mail operators MUST be prepared to receive
				    reports formatted per
				    <xref target="RFC5965"/> as email
				    messages (<xref target="RFC5322"/>) over
				    SMTP (<xref target="RFC5321"/>).  These
				    and other types of email messages that
				    may be received are discussed in
				    Section 4.2 of
				    <xref target="RFC6449"/>. </t>
						
				<t> Mail operators SHOULD utilize an automated
				    system to receive and process these
				    reports, as discussed in Section 4.4 of
				    <xref target="RFC6449"/>. </t>
						
				<t> That system MUST accept all Feedback-Types
				    defined in <xref target="RFC5965"/> or
				    extensions to it, but implementors
				    SHOULD NOT assume that Mailbox Providers
				    will make use of 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 might take upon
				    receiving a report (or multiple reports)
				    are discussed in Section 4.3 of
				    <xref target="RFC6449"/>. </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"
			    or "honeypot" addresses without human involvement,
			    reports of authentication failures, virus reports,
			    and so forth.  These applications might be
			    described in future 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="RFC6449"/>. </t>
    	</section>

	<section anchor="Acknowledgements" title="Acknowledgements">
		<t> All of the Best Practices referenced by this document are
		    found in <xref target="RFC6449"/>, written within the
		    Collaboration Committee of the Messaging Anti-Abuse
		    Working Group (MAAWG) -- which is described further in
		    <xref target="RFC6449"/>. </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;
      		&RFC6449;
	</references>
	</back>
</rfc>