GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6449

Internet Engineering Task Force (IETF) J. Falk, Ed. Request for Comments: 6449 Messaging Anti-Abuse WG Category: Informational November 2011 ISSN: 2070-1721

        Complaint Feedback Loop Operational Recommendations

Abstract

 Complaint Feedback Loops similar to those described herein have
 existed for more than a decade, resulting in many de facto standards
 and best practices.  This document is an attempt to codify, and thus
 clarify, the ways that both providers and consumers of these feedback
 mechanisms intend to use the feedback, describing some already common
 industry practices.
 This document is the result of cooperative efforts within the
 Messaging Anti-Abuse Working Group, a trade organization separate
 from the IETF.  The original MAAWG document upon which this document
 is based was published in April, 2010.  This document does not
 represent the consensus of the IETF; rather it is being published as
 an Informational RFC to make it widely available to the Internet
 community and simplify reference to this material from IETF work.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It has been approved for publication by the Internet
 Engineering Steering Group (IESG).  Not all documents approved by the
 IESG are a candidate for any level of Internet Standard; see Section
 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc6449.

Falk Informational [Page 1] RFC 6449 CFBL Recommendations November 2011

Copyright Notice

 Copyright (c) 2011 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.
 This document may not be modified, and derivative works of it may not
 be created, except to format it for publication as an RFC or to
 translate it into languages other than English.

Falk Informational [Page 2] RFC 6449 CFBL Recommendations November 2011

Table of Contents

 1. Overview ........................................................4
 2. Glossary of Standard Terms ......................................5
 3. Mailbox Providers and Feedback Providers ........................9
    3.1. Benefits of Providing Feedback .............................9
    3.2. Collecting Complaints .....................................10
    3.3. Creating Reports ..........................................11
    3.4. Policy Concerns ...........................................11
         3.4.1. Privacy and Regulatory Compliance ..................11
         3.4.2. Terms of Use .......................................12
    3.5. Handling Requests to Receive Feedback .....................12
         3.5.1. Application Web Site ...............................13
         3.5.2. Saying No ..........................................14
         3.5.3. Automation .........................................14
    3.6. Ongoing Maintenance .......................................15
         3.6.1. IP Validation ......................................15
         3.6.2. Email Address Validation ...........................16
         3.6.3. Feedback Production Changes ........................16
 4. Feedback Consumers .............................................16
    4.1. Preparation ...............................................17
    4.2. What You'll Receive .......................................18
         4.2.1. Feedback Reports ...................................18
         4.2.2. Administrative Messages ............................18
         4.2.3. Report Cards .......................................18
    4.3. Handling Feedback Messages ................................19
         4.3.1. Unsubscription or Suppression ......................20
         4.3.2. Trending and Reporting .............................21
    4.4. Automatically Handling an Incoming Feedback Stream ........22
 5. Conclusion .....................................................25
 6. Acknowledgments ................................................26
    6.1. About MAAWG ...............................................26
 7. Security Considerations ........................................26
 8. Informative References .........................................26
 Appendix A. Abuse Reporting Format (ARF) ..........................28
   A.1. A Brief History ............................................28
   A.2. Structure of an ARF Message ................................28
 Appendix B. Using DKIM to Route Feedback ..........................29
 Appendix C. Unsolicited Feedback ..................................30
   C.1. Guidelines .................................................30
   C.2. Pros .......................................................30
   C.3. Cons .......................................................31

Falk Informational [Page 3] RFC 6449 CFBL Recommendations November 2011

1. Overview

 The intent of a Complaint Feedback Loop is to provide Feedback
 Consumers with information necessary to mitigate Spam or the
 perception of Spam.  Thus, feedback was originally only offered to
 mailbox, access, and network providers -- in other words, to ISPs --
 who would use the feedback to identify network compromises and
 fraudulent accounts or to notify their downstream customer that there
 may be a problem.
 Senders of bulk, transactional, social, or other types of email can
 also use this feedback to adjust their mailing practices, using Spam
 Complaints as an indicator of whether the Recipient wishes to
 continue receiving email.  Common reactions often include refining
 opt-in practices, mailing frequency, list management, message
 content, and other measures.  Over time, this has become the Feedback
 Consumer use case most often discussed at MAAWG meetings and other
 industry events -- but readers are cautioned that it is not the sole
 use for feedback.
                            [ Feedback Consumer Database ]
                                          |
                                          V
 [  User   ]    [ Mailbox  ]         [ Feedback ]
 [ Reports ]--->[ Provider ]--SMTP-->[ Provider ]
 [  Spam   ]         |                    |
                     V                    V               [ Feedback ]
           [Spam Filter Rules]    [ ARF Message ]--SMTP-->[ Consumer ]
                               Figure 1
 When an End User of a Mailbox Provider issues a Spam Complaint, the
 Feedback Provider sends a report to the Feedback Consumer.  This
 report may include the Full Body of the original email or (less
 commonly) only the full header of the original email.  Some Feedback
 Providers will redact information deemed private, such as the Message
 Recipient's Email Address.
 Ensuring that Feedback Messages are only sent to authorized Feedback
 Consumers is the responsibility of the Feedback Provider, with the
 identity of each message Sender generally determined from the SMTP
 session's connecting IP address or a message's DomainKeys Identified
 Mail (DKIM) signature domain, both of which are hard to forge.  This
 is important because Spammers and other miscreants may also attempt
 to apply for Feedback Loops on networks not belonging to them, in an
 attempt to steal Email Addresses and other private personal or
 corporate information.

Falk Informational [Page 4] RFC 6449 CFBL Recommendations November 2011

 It is the responsibility of the Feedback Consumer to identify the
 source and nature of the original message in the reports they receive
 and take any appropriate action.  The Feedback Provider does not make
 any claims or judgments about the validity of the complaint, beyond
 whatever technical data the Feedback Provider has themselves
 included.  Every complaint is forwarded to the Feedback Consumer
 without human review, without any additional application of filters;
 thus, some individual reports may prove not to be actionable.
 The Feedback Consumer and the Feedback Provider will each evaluate a
 Spam Complaint for validity and take whatever action deemed necessary
 from their own perspective and, in most cases, will not communicate
 with each other which actions were (or were not) taken.  Similarly,
 it is rare for any party to communicate further with the End User who
 initiated the complaint.

2. Glossary of Standard Terms

 Wherever possible, these terms are derived from [RFC5598].
 o  Abuse Reporting Format - The standard format for Feedback
    Messages, defined in Appendix A and [MARF].
 o  Access Provider - Any company or organization that provides End
    Users with access to the Internet.  It may or may not be the same
    entity that the End User uses as a Mailbox Provider.
 o  Application for Feedback Loop - the process, manual or online, by
    which a prospective Feedback Consumer requests to receive a
    Feedback Loop from a particular Feedback Provider.
 o  ARF -- See "Abuse Reporting Format".
 o  ARF Report -- See "Feedback Message".
 o  Body - See "Full Body".
 o  Complaint or Complaint Message - See "Feedback Message".
 o  Complaint Feedback Loop - See Overview and Taxonomy section.
 o  Complaint Stream - See "Feedback Stream".
 o  Delivery - See "Message Delivery".
 o  DKIM - DomainKeys Identified Mail, further described in the MAAWG
    email authentication white paper "Trust in Email Begins with
    Authentication" [Trust] and [DKIM].

Falk Informational [Page 5] RFC 6449 CFBL Recommendations November 2011

 o  End User - A customer of a Mailbox Provider or Access Provider.
 o  Envelope Sender - The Email Address included as the argument to
    the [SMTP] "MAIL" command during transfer of a message.
 o  Email Address - A string of the form user@domain, where the domain
    (after the @ symbol) is used to determine where to transfer an
    email message so that it may be delivered to the mailbox specified
    by the username (before the @ symbol).  The precise technical
    format of an Email Address is defined in [SMTP].  Email delivery
    can be a complex process and is not described further in this
    document.
 o  Email Service Provider (ESP) - A provider of email sending
    services; the ESP is often a Message Originator working on behalf
    of a Message Author.  MAAWG uses the term "ESP" solely for this
    definition and does not refer to a Mailbox Provider for End Users
    as ESPs.
 o  FBL - The acronym "FBL" (Feedback Loop) is intentionally not used
    in this document.
 o  Feedback or Feedback Stream - A set (often a continuous stream) of
    Feedback Messages sent from a single Feedback Provider to a single
    Feedback Consumer.
 o  Feedback Consumer - A Recipient of the Feedback Messages, almost
    always on behalf of or otherwise associated with the Message
    Originator.  Often the Message Originator and Feedback Consumer
    are the same entity, but we describe them separately in this
    document because they are each responsible for different parts of
    the Complaint Feedback Loop process, as demonstrated in the
    flowchart in the Overview section.
 o  Feedback Loop - See Complaint Feedback Loop.
 o  Feedback Message - A single message, often using the Abuse
    Reporting Format defined above and outlined in Appendix 1, which
    is part of a Feedback Stream.
 o  Feedback Provider - The Sender of the Feedback Messages, almost
    always on behalf of or associated with the Mailbox Provider.
    Often the Mailbox Provider and Feedback Provider are the same
    entity, but we describe them separately in this document because
    they are each responsible for different parts of the Complaint
    Feedback Loop process.  In some instances, the Feedback Provider
    may be operating solely on behalf of the Message Recipient,
    without any direct participation from their Mailbox Provider.

Falk Informational [Page 6] RFC 6449 CFBL Recommendations November 2011

 o  Full Body - An email message (the "DATA" portion of the [SMTP]
    conversation) consists of two parts: the header and the body.  The
    "Full Body" is simply the entirety of the body of the message,
    without modification or truncation.  Note that images or other so-
    called "attachments" are actually part of the body, designated in
    accordance with the [MIME] standard.
 o  Full Header Section - An email message (the "DATA" portion of the
    [SMTP] conversation) consists of two parts: the header and the
    body.  The header contains multiple header fields, each formatted
    as "Header-Name: header contents".  Although most Mail User Agents
    (MUAs) only show the basic four header fields (From, To, Date, and
    Subject), every message includes additional header fields that
    primarily contain diagnostic information or data intended to
    assist automatic processing.  Often informally called "Full
    Headers".  These fields are fully defined in [RFC5322]
 o  Header - See "Full Header Section" above.
 o  ISP - Internet Service Provider, usually referred to as either an
    Access Provider or a Mailbox Provider in this paper.
 o  Mail Abuse Reporting Format (MARF) - See "Abuse Reporting Format"
    above.
 o  Mailbox Provider - A company or organization that provides email
    mailbox hosting services for End Users and/or organizations.  Many
    Mailbox Providers are also Access Providers.
 o  Mailing List - A set of Email Addresses that will receive specific
    messages in accordance with the policies of that particular list.
 o  Message-ID Header Field - One of the diagnostic header fields
    included in every email message (see "Full Header Section" above)
    is the Message-ID.  Theoretically, it is a unique identifier for
    that individual message.
 o  Message Delivery - The process of transferring a message from one
    mail transfer agent (MTA) to another.  Once the message has been
    accepted by the MTA operating on behalf of the Recipient, it is
    considered to be "delivered" regardless of further processing or
    filtering that may take place after that point.
 o  Message Originator - The Sender, but not necessarily the author or
    creator, of a message.
 o  Message Recipient - The person or mailbox that receives a message
    as final point of delivery.

Falk Informational [Page 7] RFC 6449 CFBL Recommendations November 2011

 o  MIME - Multipurpose Internet Mail Extensions refers to a set of
    standards permitting non-plaintext data to be embedded in the body
    of a message.  Concepts such as file attachments and formatted or
    "rich" text are all accomplished solely through [MIME].
 o  MUA - Mail User Agent; loosely referring to the software used by
    an End User to access, interact with, or send email messages.
 o  Provider - See "Feedback Provider" above.
 o  Received Header Field - Diagnostic header fields included in an
    email message (see "Full Header Section" above) that start with
    "Received:" and document (from bottom to top) the path a message
    traversed from the originator to its current position.
 o  Recipient - See "Message Recipient" above.
 o  Return-Path - An optional message header field (see "Full Header
    Section" above) that indicates the Envelope Sender of the message.
 o  Reverse DNS - The [DNS] name of an IP address, called "reverse"
    because it is the inverse of the more user-visible query that
    returns the IP address of a DNS name.  Further, a Reverse DNS
    query returns a PTR record rather than an A record.
 o  Sender - see "Message Originator" above.
 o  SMTP - Simple Mail Transfer Protocol, the mechanism and language
    for transferring an email message from one place to another as
    defined in RFC 5321 [SMTP].
 o  Spam - For the purposes of this document (and for most Complaint
    Feedback Loops), "spam" is defined as any message that the
    Recipient chooses to complain about, regardless of the intent of
    the message's author or Sender.
 o  Spam Complaint - See "Complaint" above.
 o  Spammer - An entity that knowingly, intentionally sends Spam
    messages (see "Spam" above).
 o  Terms of Use - A legal document describing how a particular system
    or service is to be used.
 o  VERP - Variable Envelope Return Path [VERP], an informally
    standardized method for encoding information about the Message
    Recipient into the return path while delivering a message in order
    to ensure that any non-delivery notices are processed correctly.

Falk Informational [Page 8] RFC 6449 CFBL Recommendations November 2011

3. Mailbox Providers and Feedback Providers

 In practice, a Mailbox Provider receives complaints from their End
 Users, and is often also the Feedback Provider for those complaints
 and is a consumer of feedback from other providers.  In this
 document, we separate the Mailbox Provider and Feedback Provider
 functions to reduce possible confusion over those cases where they
 are separate, and we also urge Mailbox Providers to read the
 "Feedback Consumer" section later in this document.

3.1. Benefits of Providing Feedback

 The decision to provide a Complaint Feedback Loop service should not
 be taken lightly.  The benefits of a Feedback Loop are great, but
 success depends on a sound plan, organized implementation, and
 dedication to upkeep.
 What are some benefits of providing feedback to fellow Mailbox
 Providers and Access Providers?  Primarily, other industry actors are
 quickly alerted to Spam outbreaks on their networks.
 End Users are becoming more aware of and comfortable with mechanisms
 to report Spam, and a Feedback Loop does just what it implies; it
 closes the loop.  The End User's complaint makes its way back to the
 Message Originator (not necessarily the message Sender, who may be a
 Spammer), allowing the originator to take appropriate action.  In
 this process, the mail system operator is just a messenger, relieved
 of the responsibility of reviewing and forwarding complaints
 manually.
 Further, because every complaint is sent immediately -- without any
 review or analysis by the Feedback Provider -- the complaint is
 received by the Feedback Consumer in near real time.  If the Feedback
 Consumer is paying attention to their Feedback Stream and taking
 appropriate action on it, the receiving Mailbox Provider receives
 less Spam, blocks less legitimate mail, and does not have to assign
 staff to follow up with the originating network.  If the Mailbox
 Provider does not pay attention to its Feedback Stream, and does not
 take appropriate action, the Feedback Provider may block or otherwise
 filter the email from that Message Originator, considering the
 Feedback Messages to be sufficient notice.
 What are some benefits of providing Feedback Loops to bulk Feedback
 Consumers?  As Message Recipients become more aware of and
 comfortable with Spam reporting mechanisms, they often prefer this
 method over the often-confusing and inconsistent "unsubscribe" or
 "opt-out" mechanisms provided by most legitimate Message Originators
 or Senders.

Falk Informational [Page 9] RFC 6449 CFBL Recommendations November 2011

 End Users often do not remember what lists they signed up for or are
 otherwise not confident in the established relationship they may have
 with a message Sender.  As such, they often choose to report messages
 as Spam to their Mailbox Providers, considering that to be sufficient
 notification of their desire not to receive such email in the future.
 If the Message Originator is paying attention to and taking
 appropriate action on their Feedback Stream, it will have a happier
 set of Message Recipients and should receive fewer Spam Complaints
 (assuming their opt-in processes are sound).  If the Message
 Originator is not paying attention to Feedback and not taking
 appropriate action, the Mailbox Provider may consider the Feedback
 Stream sufficient notice that messages from that originator may no
 longer be accepted in the future.

3.2. Collecting Complaints

 To produce Feedback Messages and to ensure they are useful, the
 Feedback Provider needs to obtain near real-time complaints from the
 Mailbox Provider's users.  This is typically done by integrating the
 feedback mechanism with the collection of Spam reports from its
 users.
 These reports are typically made using the "Report Spam" buttons
 integrated into Webmail interfaces, or a proprietary desktop client
 provided to users.  Mailbox Providers may also look at deploying a
 toolbar or MUA plug-in that provides a "Report Spam" button in the
 MUA interface.
 Usability studies with average users should be performed on all
 interface changes before implementation.  A "help" interface should
 also be available to educate users about how the Spam button should
 be used and what it does.
 If the Mailbox Provider does not offer its customers a mail client
 with this button, then the Feedback Provider's chances for providing
 an effective Feedback Loop are slim.  While it is possible for the
 Mailbox Provider to instruct its customers to forward unwanted mail
 to a central location and for the Mailbox Provider to explain how to
 ensure the report includes headers and bodies, the success rate of
 customers doing so tends to be low.  Even those complaints that do
 contain all required information might prove difficult to parse, as
 variations in formatting and content types will lead to automated
 tools being consistently updated with new logic blocks for each
 variation that occurs.

Falk Informational [Page 10] RFC 6449 CFBL Recommendations November 2011

3.3. Creating Reports

 It is recommended that Feedback Messages be sent using the standard
 Abuse Reporting Format, to facilitate uniformity and ease of
 processing for all consumers of feedback.  This will also enable the
 Feedback Provider to extensively automate the processes of generating
 and sending Feedback Messages and of analyzing complaint statistics.
 This format is described further in Appendix 1.
 Feedback Loops are usually (but not always) keyed to the "last hop"
 IP address (i.e., the IP address that passed the unwanted message to
 the Mailbox Provider's servers).  Consequently, the Feedback Provider
 must be able to process the header from each complaint to determine
 the IP address for the complaint.
 A Feedback Provider may wish to provide, as part of its Feedback
 Loop, other information beyond Spam Complaints that Feedback
 Consumers may find valuable.  It might include summary delivery
 statistics (volume, inbox delivery rate, Spam trap hits, etc.) or
 other data that the Feedback Provider may deem pertinent to Feedback
 Consumers.
 Any mature Feedback Loop system will produce situations in which the
 Feedback Consumer may have follow-up questions or have other
 information to provide in regard to the feedback.  Feedback Messages
 should include contact information (typically an Email Address) for
 the Feedback Consumer to use for such questions, and ideally the
 contact Email Address will feed into a ticket system or other
 automated tool used by the Mailbox Provider's postmaster and/or anti-
 abuse staff for handling general email delivery issues.

3.4. Policy Concerns

3.4.1. Privacy and Regulatory Compliance

 Feedback Messages provide information relayed by Feedback Providers
 from a Mailbox Provider's End Users to the Feedback Consumer.  There
 might not be any concerns with relaying non-private data to a third
 party.  However, the information provided in the complaints generated
 by the user must be evaluated and any data deemed private may need to
 be removed before distributing to a third party, per local policy.
 For example, the Recipient's or reporter's Email Address and IP
 address may be categorized as private data and removed from the
 feedback report that is provided to the Feedback Consumer.  Privacy
 laws and corporate data classification standards should be consulted
 when determining what information should be considered private.

Falk Informational [Page 11] RFC 6449 CFBL Recommendations November 2011

 Information provided by the Feedback Consumer to the Feedback
 Provider for the purpose of enrolling in the Feedback Loop should
 also be kept private.  It should only be shared or used for the
 purposes explicitly agreed to during the enrollment process (see the
 "Terms of Use" section below).
 Feedback Loops inevitably span country borders.  Local laws and
 regulations regarding distribution of information domestically and
 internationally need to be considered when implementing a Feedback
 Loop program.  For example, in some European countries, data exchange
 requires permission from governing bodies.  The terms and
 circumstances surrounding the exchange of data need to be clearly
 defined and approved.

3.4.2. Terms of Use

 A written Terms of Use agreement should be provided by the Feedback
 Provider and agreed to by the Feedback Consumer before any feedback
 is provided.  The following concepts should be considered when
 drafting the terms of use agreement:
 o  Data provided in Feedback Messages are provided to a specific,
    approved entity.  Information should not be transmitted outside of
    the intended, approved Recipient.  Any inappropriate use of the
    information can lead to immediate termination from the feedback
    program.
 o  Consumers of Feedback have a responsibility to keep the
    information they provide for Feedback Loop purposes -- such as
    abuse contact information, IP addresses, and other records --
    accurate and up to date.
 o  The providing of Feedback information is a privilege and needs to
    be treated appropriately.  It does not entitle the consumer of the
    feedback to any special sending privileges.
 o  Approval and continued enrollment in the program is a privilege
    that can be denied or revoked for any reason and at any time.

3.5. Handling Requests to Receive Feedback

 There should be a streamlined application process for receiving
 feedback and the vetting of such applications.  This vetting may be
 stringent in cases where the Mailbox Provider chooses to tie its
 Complaint Feedback Loop program to a whitelist.  Criteria may involve
 the following:

Falk Informational [Page 12] RFC 6449 CFBL Recommendations November 2011

 o  Cross-checking that the requestor is indeed authorized to receive
    feedback for the IP addresses concerned.
 o  Gathering other information such as whether the IPs are an ISP
    smarthost network, a webhosting farm, an email marketing or
    Mailing List service, or other entity.
 o  Requesting information such as a link to the policies of the
    requestor, contacts to send Feedback Messages, and escalation
    points of contact.
 Ideally, enrollment will be a two-step process, with the applicant
 filling out a form and being required to receive and acknowledge a
 confirmation email (best sent to abuse@ or postmaster@ the domain in
 question) before the applicant's request is even put into the queue
 for the Feedback Provider to process.
 Ownership of IP addresses can and should be cross-checked by means of
 origin Autonomous System Number (ASN), WHOIS/RWHOIS records, Reverse
 DNS of the sending hosts, and other sources.  This can be automated
 to some extent, but it often requires some manual processing.

3.5.1. Application Web Site

 Applications for Feedback Loops can be accepted on a stand-alone web
 site or can be part of the Mailbox Provider's postmaster site.
 Regardless, the web site for the Complaint Feedback Loop program
 should contain other content specific to the Feedback Loop, including
 FAQs for the Feedback Loop program, the Terms of Service for the
 Feedback Loop, and perhaps a method for enrolled parties to modify
 their existing enrollments.
 The web site should also provide the Feedback Consumer with general
 information on how the feedback will be sent, including:
 o  Report Format (ARF or otherwise)
 o  Sending IP addresses and/or DKIM "d=" string
 o  "From" Email Address

Falk Informational [Page 13] RFC 6449 CFBL Recommendations November 2011

3.5.2. Saying No

 Denial of a Feedback Loop application may be appropriate in certain
 cases such as:
 o  Where the Feedback Provider suspects "gaming" of delivery policies
    via the Feedback received, with attempts to pollute Feedback Loop
    metrics by, for example, creating bogus accounts and reporting
    false negatives with these, to offset the negative reputation
    caused by high complaint rates.
 o  Where the Feedback Provider has decided to block the Message
    Originator's IP space for which feedback has been requested on the
    grounds that email from that originator has a sufficiently
    negative reputation that it will not be delivered at all.  This is
    somewhat on the lines of a global unsubscribe of the Message
    Provider's users from the originator's lists, which would make
    rendering additional feedback unnecessary.
 It is recommended that the Feedback Provider send notification if an
 application is denied.  Additionally, they should maintain a
 documented, clear, and transparent appeals process for denial of
 requests.  This process can be as simple as the prospective Feedback
 Consumer replying to the denial email requesting review or escalation
 to a team lead, which also cites reasons the application should be
 reviewed.

3.5.3. Automation

 For a Feedback Loop to be cost-effective and usable for large
 Feedback Consumers and Feedback Providers, it must be possible for
 reports to be generated and processed automatically without any human
 interaction.  On the other hand, it should be possible for small
 Feedback Consumers to handle a low volume of reports manually,
 without requiring any automation.
 In automating the feedback process, the consumer of the Feedback
 Stream must receive enough information about the report that it can
 take appropriate action, typically to remove the Recipient from the
 Mailing List about which it is sending a report.  The Recipient's
 Email Address is not enough, as the Recipient may be on several
 Mailing Lists managed by the Feedback Loop consumer and only need to
 be removed from the particular list reported.
 Also, some producers of Feedback Loops might redact the Recipient's
 Email Address for privacy reasons.  Effective implementation of a
 Complaint Feedback Loop requires that the Feedback Provider put in

Falk Informational [Page 14] RFC 6449 CFBL Recommendations November 2011

 place as many automated processes and tools as feasible to handle all
 aspects of the process.  Feedback Providers should seek to automate
 or script the following:
 o  Accepting and validating Feedback Loop Applications from
    prospective Feedback Consumers.
 o  Processing requests to determine whether or not they meet the
    Feedback Provider's criteria for enrollment in the program.
 o  Accepting Spam Complaints from End Users; this will form the bulk
    (and perhaps sole) component of the feedback sent by the Feedback
    Provider.
 o  Production of Feedback Messages from Spam Complaints.
 o  Production of other Feedback Loop artifacts as chosen by the
    Feedback Provider.
 o  Optionally, provision of a mechanism for Feedback Consumers to
    further engage a Feedback Provider about a given Feedback Message.
 o  Ongoing validation of Feedback Loop enrollments to determine if a
    currently enrolled IP address or network merits continued
    inclusion in the Feedback Loop.
 o  Optional periodic emails to Feedback Consumers to determine if
    their enrolled Email Addresses are still valid.

3.6. Ongoing Maintenance

 It is recommended that self-service maintenance be offered to
 Feedback Consumers, to the extent practicable.  The more they can do
 themselves, the less you have to do.

3.6.1. IP Validation

 The criteria that a Feedback Provider uses to validate a Feedback
 Loop application may change over time.  It is a near certainty at
 least some subset of Feedback Consumers enrolled to receive feedback
 will at some point after enrollment fail to meet those criteria,
 regardless of whether or not the criteria change.
 The Feedback Provider should put in place tools to periodically
 re-validate all Feedback Consumers enrolled in its Feedback Loop
 system against its current criteria.  Additionally, the Feedback

Falk Informational [Page 15] RFC 6449 CFBL Recommendations November 2011

 Provider will likely have objective criteria for remaining in the
 Feedback Loop for enrolled Feedback Consumers; the enrolled consumers
 should be validated against those criteria as well.

3.6.2. Email Address Validation

 Just as some Mailing List software has the built-in ability to send
 periodic "probe" emails to subscribed addresses to validate them, so
 too should the Feedback Provider develop tools to send similar emails
 to the addresses receiving Feedback Messages to ensure that they are
 valid.  This is especially true for the addresses that are not the
 abuse@ and postmaster@ addresses originally used as part of the
 enrollment acknowledgment step.  Over time, people may change
 employers, or at least roles, and validating the Email Addresses
 associated with an IP is one way for the Feedback Provider to ensure
 that Feedback Messages are still being accepted and acted upon by the
 Feedback Consumer.

3.6.3. Feedback Production Changes

 Updating Feedback Consumers when one's own IP addresses are changing
 is an important aspect of Feedback Loop maintenance.  The exact
 format, automation, and other considerations of these updates are
 outside the scope of this document, but are topics worthy of further
 discussion and eventual documentation.

4. Feedback Consumers

 A Feedback Consumer receives its Feedback Messages after its
 submitted Application for a Complaint Feedback Loop is approved.  A
 Feedback Consumer will usually have Complaint Feedback Loop
 subscriptions set up with multiple Feedback Providers.  Different
 Feedback Streams may be in different formats or include different
 information, and the Feedback Consumer should identify a process to
 organize the data received and take appropriate action.
 A Feedback Consumer, Mailbox Provider, or Access Provider (i.e., a
 hosting company or ISP) will use this Feedback to identify network
 compromises, fraudulent accounts, policy violations, and other
 concerns.  The Feedback Loop provides real-time visibility into Spam
 Complaints from Message Recipients, greatly enabling these Mailbox
 Providers to mitigate Spam propagating from their networks.
 Senders of bulk email should use the complaints to make decisions
 regarding future mailings.  Such decisions may include one or more of
 the following: modification of email frequency, branding, opt-in
 practices, or list management.

Falk Informational [Page 16] RFC 6449 CFBL Recommendations November 2011

 The authors of this document urge those who are solely Feedback
 Consumers to also read the previous sections for Mailbox Providers
 and Feedback Providers.  This will provide the proper context of the
 recommendations included below.
 Further recommendations for bulk senders may be found in the MAAWG
 Sender Best Communications Practices [MAAWG-BCP].

4.1. Preparation

 Feedback Consumers need to prepare to process and act on feedback
 before asking to receive it.  At a minimum, make sure to have:
 1.  The "Role" Email Addresses such as abuse@ and postmaster@.  The
     person who applies for the Feedback needs to make sure they have
     access to these Email Addresses.  Feedback Providers often send a
     confirmation link to those accounts to prevent End Users,
     Spammers, or competitors from signing up for Feedback for which
     they are not authorized.
 2.  A dedicated Email Address to receive the Feedback Messages, such
     as fbl@example.com or isp-feedback@example.com.  While not
     required, this will make it easier for to process the reports
     received.
 3.  A list of IP addresses for which you want to receive Feedback
     Messages, making sure you can prove the ownership of the IP
     addresses and associated domains.  Feedback Providers often
     require that:
  • Reverse DNS for each IP shares the domain of either the

applicant's Email Address or the Email Address that will be

        receiving the Feedback Messages.
  • WHOIS information for the IPs requested is obviously

associated with the domain name.

 4.  Contact information such as name, Email Address, phone number,
     and other relevant information.
 5.  The knowledge that if the application form asks for your credit
     card number or other financial information, it is assuredly a
     scam.

Falk Informational [Page 17] RFC 6449 CFBL Recommendations November 2011

4.2. What You'll Receive

 Once a Feedback Consumer has signed up to receive feedback from a
 Feedback Provider, it may also receive several other sorts of
 delivery-related reports.  This includes Feedback Messages,
 administrative messages, and other messages.

4.2.1. Feedback Reports

 Feedback Messages are the main emails generally associated with a
 Feedback Loop.  Each time a Recipient hits the "This Is Spam" button,
 the Feedback Loop system creates a boilerplate report with a copy of
 the original email attached and sends it to the consumer of the
 Feedback Loop.
 The handling of feedback reports is discussed in the next section.

4.2.2. Administrative Messages

 Administrative messages will typically be sent to the Email Address
 provided for contacting the person who originally applied for the
 Feedback Loop, rather than to the address provided for handling the
 Feedback Messages.  These messages are likely to be sent infrequently
 and irregularly, but it is important they are seen by the person
 managing the Feedback Stream processor in a timely manner.  It is
 usually a poor idea to have these sent to an individual's Email
 Address since they may be lost if that person is on vacation, changes
 position within the company, or leaves the company.
 Instead, they should be sent to a role account that goes to a
 ticketing system or "exploded" to multiple responsible parties within
 the organization.  If there is not already an appropriate role
 account such as support@ or noc@ that reaches the right team, it may
 be a good idea to set up a dedicated alias such as fblmaster@ to sign
 up for all Feedback Loops.

4.2.3. Report Cards

 The detail in a report card can vary greatly.  Feedback Providers
 might send a regular summary of traffic levels and complaint rates
 seen, perhaps just an overview or possibly broken down by source IP
 address or some other identifier.  Sometimes these may be sent just
 when some metric (typically a complaint rate) reaches a level that
 causes the Mailbox Provider to notify the Feedback Consumer there may
 be a problem developing that needs to be investigated and addressed.
 At the other extreme, some report cards will contain almost no useful

Falk Informational [Page 18] RFC 6449 CFBL Recommendations November 2011

 data at all, just a warning that the Message Originator is causing
 complaints -- with the implication that its email will be blocked
 unless it is improved.
 Report cards are human readable, since there are not currently any
 standard machine-readable formats and the information they include,
 both the provided metrics and their semantics, varies widely from one
 Mailbox Provider to another.  They are useful reference overviews for
 a Message Originator to monitor the overall perceived quality of the
 email it sends and, in the case of ESPs, perhaps which customers are
 causing higher than expected rates of complaints.  They can also be
 the only warning of serious problems prior to email being blocked
 altogether by the receiving Mailbox Provider.  It is critical they be
 are seen by someone handling delivery issues for the Message
 Originator, so again, they should be handled by an email alias that
 is always read.
 Report cards also contain useful data to track mechanically and
 perhaps report on trends, though as their content varies, it is hard
 to generalize what use might be made of them.  At the very least, the
 "warning" report cards are something that should be visible on an
 ESP's business intelligence or delivery dashboard.

4.3. Handling Feedback Messages

 Mailbox Providers sending feedback may have published policies as to
 how they expect a Feedback Consumer to use Feedback Messages or may
 expect the Feedback Consumer to simply "make the problem stop".  In
 practice, this mostly boils down to three things:
 o  First, where the consumer of the feedback has some specific
    control over sending the email, it is expected not to send email
    of the same type to the same Recipient again.
 o  Second, it should identify the underlying problem (if any) and fix
    it so that it receives fewer reports of that type in the future.
 o  Third, it is not necessary to inform the Mailbox Provider or
    Feedback Provider, or their End User(s), of which actions have
    been or will be taken in response to automated complaint feedback.
 If the Feedback Consumer is a separate entity from the Message
 Originator, the two entities are expected to work together to resolve
 any problem.

Falk Informational [Page 19] RFC 6449 CFBL Recommendations November 2011

4.3.1. Unsubscription or Suppression

 A Sender (whether author or originator) of commercial email should
 treat the Feedback Message similar to an unsubscribe request,
 ensuring that no further email from that list is sent to that
 Recipient, either by removing the email from that list or adding it
 to the associated suppression list.  It needs to use its best
 judgment, keeping in mind the goal of reducing future complaints, as
 to how broadly to apply that unsubscribe.  Suppressing the address
 across an entire ESP is likely too broad.  However, if a single
 Feedback Consumer (or customer of an ESP) has multiple segmented
 lists, then suppressing them across all those lists is probably a
 good idea.
 It is universally acknowledged that not all complaints are
 intentional; for example, Recipients might accidentally hit the wrong
 button or mark an entire mailbox as Spam.  However, it is best for
 Feedback Consumers to assume the Recipient does not want more email
 and to suppress mail to the Recipient in all but fairly extreme cases
 such as a Mailing List the Recipients pay to receive, email from a
 genuine company to its valid employees, or email from an Access
 Provider or Mailbox Provider to its users.
 This gets more complex in the case of transactional mail -- mail that
 is tied to some other service, such as ticket purchase confirmations
 or billing statements.  In that case, the Feedback Consumer has to,
 again, use its best judgment based on the specific situation.  In
 some cases, the right thing to do may be to communicate with the
 Recipient via another channel, such as a message on a web site used
 for the service; i.e., "You reported your notification mail as Spam
 so we are not going to send you any more messages unless you tell us
 otherwise".
 In some cases, the best thing to do may be to ignore the Feedback
 Message.  For example, if your customer has reported as Spam the
 airline tickets he purchased and you emailed him, he probably did not
 mean it and he is going to be very annoyed if you do not send him the
 other tickets he has ordered.  In rare cases, it might be appropriate
 to suppress email to the Recipient, but also to suspend access to a
 service he or she uses until the Recipient confirms a desire to
 receive the associated email.  In all these cases, the important goal
 is to keep the customer happy and reduce future complaints, even in
 the apparently paradoxical situations where the way to do that is to
 ignore their Feedback.  In the real world, however, these are a small
 minority of cases.

Falk Informational [Page 20] RFC 6449 CFBL Recommendations November 2011

4.3.2. Trending and Reporting

 Counting the Feedback Messages received over regular time periods can
 provide much useful information to ISPs, ESPs, and other Feedback
 Consumers, especially when broken down appropriately.
 An ISP (Mailbox Provider or Access Provider) might want to count the
 number of Feedback Messages a particular customer or IP address
 causes in a given day.  If there is a sudden increase from a
 particular customer or server, it may be a sign that a Spammer has
 signed up or a system has been compromised.  If there is a high level
 of complaints about a particular customer, it may be worth
 investigating to see if there is a reason for that.  For example, 10
 Feedback Messages a day would be a sign of serious problems in some
 cases, but might be perfectly reasonable "background" levels for a
 Message Originator that sends 300,000 emails a month.  If the count
 shows there may be a problem, the ISP can dig down and look at the
 emails that are being reported to determine the underlying cause.
 An ESP can do similar things but can also break the data down in more
 ways: by customer, by Mailing List, by campaign.  An ESP also has
 access to more information; it knows how many emails were delivered
 to the receiving Mailbox Provider over a given time period.  As a
 result, it can estimate the number of complaints divided by the
 number of emails sent, which is often a more useful metric than the
 absolute number of reports.  This is critical data for ESPs to track
 over time because it can help identify and quantify problem
 customers.
 An individual Feedback Consumer, whether sending their own email or
 using an ESP, can acquire at least some information from complaint
 rates.  A spike in complaints on an otherwise stable list might be a
 sign there is a problem with address acquisition, if the spike is due
 to reports from new subscribers.  If it came from older subscribers,
 it might be attributable to content of a particular mailing that was
 not well received.  Perhaps the branding was not recognized or the
 content was offensive or inappropriate for the list.
 The complaint rate is determined by the number of Feedback Messages
 received over a given time period divided by the number of emails
 delivered to the associated Mailbox Provider over the same period.
 It is an obvious and useful metric to track, but there are a few
 subtle issues to be aware of.
 One issue is that Feedback Messages tend to be counted on the day the
 complaint was sent, which is the day the original message was read by
 the Recipient.  That may not be the same day that the message was
 sent.  A simple example is the fact that a Message Originator that

Falk Informational [Page 21] RFC 6449 CFBL Recommendations November 2011

 sends email regularly Monday through Friday will often see a high
 complaint rate on Saturday.  The absolute number of Feedback Messages
 sent by people catching up with the week's email over the weekend may
 not be that high.  However, since hardly any email is sent on
 Saturday, a fairly reasonable number of complaints end up being
 divided by a very small number of total sent emails, possibly even
 zero, which would break the reporting engine.  This can lead to a
 complaint rate that seems to range anywhere from suspicious to
 ridiculous.  Consequently, large Mailing Lists that are virtually
 silent on the weekend could end up receiving more complaints on a
 Saturday than email they sent that day, leading to complaint rates of
 well over 100%.
 Another arithmetic issue to consider is the interaction between the
 inbox, the bulk folder, and the "This Is Spam" button.  If an
 organization sends a high volume of email that has a terrible
 reputation, it may end up with perhaps 500 of its 10,000 mails in the
 inbox and the remaining 9,500 in the bulk folder.  If it gets 10
 Feedback Messages and divides that by the 10,000 emails it sent, it
 will get a very respectable 0.1% complaint rate.  However, the
 Mailbox Provider is probably going to calculate the complaint rate by
 dividing the number of emails delivered to the inbox instead --
 giving a 2% complaint rate, which is probably grounds for immediate
 blocking.  So, if one sees a large difference between a complaint
 rate as reported by a Mailbox Provider or other reputation system and
 the rate calculated from raw delivery numbers, it is important to
 look closely at the data.

4.4. Automatically Handling an Incoming Feedback Stream

 Even when signing up for a Feedback Loop is partly automated,
 modifications to it tend to be handled manually.  Even something as
 trivial as changing the Email Address that the Feedback Messages are
 sent to can be time-consuming and can cause significant overhead to
 the Feedback Provider.  Multiply that by a dozen Feedback Loops, and
 getting it right the first time can save a lot of time and energy.
 Even the smallest of users should create a unique email alias for
 each Feedback Loop.  There are several advantages to this, even if
 they all deliver to the same person's inbox at first.  Sending each
 Feedback Loop to a unique address makes it immediately clear which
 Feedback Provider was the source of any given report, even if it is
 sent from an inconsistent From address.  It makes it easy to put
 lightweight pre-processing in place for a particular Feedback Stream,
 if needed.  It makes it easy to discard Feedback Messages if needed
 (though only temporarily, as it could be very bad for one's

Falk Informational [Page 22] RFC 6449 CFBL Recommendations November 2011

 reputation to miss a changing trend).  If a Feedback Consumer needs
 to scale up, it is easy to point the existing aliases at a Feedback
 Loop processing engine.
 If an organization might possibly scale up appreciably in the future
 or consider outsourcing its Feedback Loop processing to a third-party
 Feedback Consumer, it may be even better to create a subdomain for
 handling Feedback Streams.  For example, example.com might use
 fbl-aol@fbl.example.com to accept its AOL Feedback Loop, allowing it
 to delegate the whole of @fbl.example.com to a Feedback Loop handling
 appliance or service, should the need arise.
 Small Feedback Consumers, with lists of no more than a few thousand
 Recipients, or small ISPs with no particular history of problems,
 should be able to handle feedback reports with little or no
 automation, as an ARF message should be readable in most mail
 clients.  It may be worthwhile to add some very lightweight
 processing to the inbound Feedback Messages to make them easier to
 triage from other email client.  For example, arffilter.c [Wise] can
 annotate the Subject line of inbound Feedback Messages with the IP
 address being reported, making it easier to see patterns of problems
 by sorting the messages by Subject line in the mail client.  To
 identify which Recipient is causing the feedback to be sent, small
 Feedback Consumers should add some of the automation mentioned below
 that is intended for larger Feedback Consumers.
 Larger Feedback Consumers need to be able to automate the handling of
 Feedback, as it scales beyond the ability of someone to manage
 manually quite quickly.  The main capability a Feedback Loop
 processor needs is to extract some relevant data from the report,
 reliably.  The most important bits of data tend to be the following:
 o  The Recipient of the original email
 o  The Mailbox Provider originating sending the Feedback Message
    (some Feedback Providers operate on behalf of multiple Mailbox
    Providers)
 o  The customer who sent the original email (in the case of an ESP or
    Mailbox Provider)
 o  The campaign and Mailing List that the original email belonged to,
    if any
 o  (Possibly) the IP address from which the original email was sent
    and any [DKIM] signature domain

Falk Informational [Page 23] RFC 6449 CFBL Recommendations November 2011

 The last isn't vital, but may be a useful piece of data in diagnosing
 delivery problems.
 It can be very difficult to extract some of this data without some
 upfront work before email is sent.  Some Feedback Providers will
 redact the Email Address in the To: header or Recipient Email
 Addresses anywhere within the message.  Some will delete any
 identifying information they can.  It may be possible to identify the
 End User based on the Message-ID, Subject line, and Received header
 timestamps, if there is access to the mail server logs, but at best
 it is painful and time-consuming, and only worth doing in an
 exceptional case.
 The solution is similar to the one used for automated bounce handling
 using VERP -- embed the information in the email in a way that it is
 unlikely to be removed by Feedback Providers but is easy to recognize
 in the email.  That information may already be there in a form such
 as VERP if the Return-Path header is included in the embedded email,
 or included in one-click unsubscribe links included in the body of
 the email.  If it is not already there, a good place to add the
 information is in the local part of the Message-ID as that is often
 used to track the progress of email through delivery.  It is often
 available from log files as well as in the headers of the original
 message included in the Feedback Message.
 There are several good ways to store the mapping between Recipients
 and identifiers in mail.  For a database-backed ESP or bulk sender, a
 synthesized database primary key can be used.  It is very small, and
 very opaque, and it is not expensive to retrieve the associated data
 from the main database -- but it is impossible to read by hand.
 Therefore, it needs automation with access to the core database to
 map the key onto the actual data.
 Recording the required information directly within the email but
 encrypting it with strong or weak encryption removes the need for
 database access to extract the data.  However, it still does need
 some automation.
 A hybrid approach with the various bits of data stored separately but
 having some pieces either encrypted or obfuscated is possible by just
 including a database ID.  This can provide a good compromise where
 most of the data is not immediately obvious to third parties but
 patterns in it can be recognized by eye.  For example, a Message-ID
 of "esp-423-27-42460@example.com" is opaque to a third party, but
 someone familiar with the format can tell that it is a Message-ID
 added by the system.  In this case it starts with "esp" followed by
 three numbers separated by dashes, meaning it is from customer 423,
 campaign 27, and the Recipient has the database key 42460.  Even

Falk Informational [Page 24] RFC 6449 CFBL Recommendations November 2011

 decoding this manually, while it may not be possible to identify
 customer number 423, it is easy to recognize that 10 Feedback
 Messages in a row relate to the same customer.  From experience, it
 is not unusual for the vast majority of reports at an ESP to be about
 a very small number of customers, and one learns their customer IDs
 very quickly.
 Once a Message Originator embeds Recipient identifiers in an easily
 recognizable format in all its mail, it is quite easy for a Feedback
 Message processor to extract that with a conventional expression
 match and possibly a couple of database queries.  It can then
 suppress that Email Address and record the customer and campaign for
 future reporting.  In the case where the Feedback Messages are
 recorded in a ticketing system, it can also annotate the tickets with
 that data (again, for reporting and trending analysis).
 A Feedback Message processor is often bolted onto the side of an
 already complex bulk mail generator, making it difficult to reliably
 suppress mail to the Recipient.  If the delivery data is stored in a
 way that makes it easy to convert into the same format as the VERP
 string used for bounce processing then the Feedback processor can
 create a "fake" hard bounce and send it to the existing bounce
 processor, suppressing mail to that address.
 Mailbox Providers and Access Providers also need to automate Feedback
 processing.  They are usually less interested in the details about
 the message and more interested in the IP address and which customer
 sent it.  In most cases, the IP address can be extracted easily from
 ARF metadata; whereas, in other cases, it may need to be extracted
 from the Received headers embedded in the included original message.
 That data can then be used both for automated forwarding of Feedback
 Messages to the originating customer, if the ISP feels that is
 appropriate, and also for reporting on complaint levels across the
 ISP's customer base.

5. Conclusion

 Whether you are acting as a Mailbox Provider or a Feedback Consumer,
 Complaint Feedback processing can be complex and scary -- or, with
 some intelligence and automation, simple and easy.  In either case,
 it is an important and necessary tool for detecting messaging abuse
 and ensuring End User satisfaction.
 MAAWG encourages all Mailbox Providers to offer Feedback of whatever
 form is appropriate for their local user base and legal framework,
 and it encourages all Senders of email to consume and act upon any
 Feedback available.  An actively maintained list of known Feedback
 Loops can be found at [Wise].

Falk Informational [Page 25] RFC 6449 CFBL Recommendations November 2011

6. Acknowledgments

 This document was written within the MAAWG Collaboration Committee.
 The project was led by John Feaver and Kate Nowrouzi.  The primary
 authors were Steve Atkins, Christine Murphy Borgia, J.D. Falk, John
 Feaver, Todd Herr, John Levine, Heather Lord, Kate Nowrouzi, and
 Suresh Ramasubramanian.
 The document was edited by John Levine, J.D. Falk, and Linda Marcus.
 Further editing and formatting required for this version to be
 published by the IETF was performed by J.D. Falk, with advice from
 Barry Leiba and Murray Kucherawy.

6.1. About MAAWG

 [MAAWG] is the largest global industry association working against
 Spam, viruses, denial-of-service attacks, and other online
 exploitation.  Its members include ISPs, network and mobile
 operators, key technology providers, and volume sender organizations.
 It represents over one billion mailboxes worldwide, and its
 membership contributed their expertise in developing this description
 of current Feedback Loop practices.

7. Security Considerations

 Security and privacy considerations are discussed in many sections of
 this document, most notably Sections 1, 3.4, and 3.5.

8. Informative References

 [DKIM]        Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys
               Identified Mail (DKIM) Signatures", RFC 6376,
               September 2011.
 [DNS]         Mockapetris, P., "Domain names - concepts and
               facilities", STD 13, RFC 1034, November 1987.
 [DomainKeys]  Delany, M., "Domain-Based Email Authentication Using
               Public Keys Advertised in the DNS (DomainKeys)",
               RFC 4870, May 2007.
 [MAAWG]       Messaging Anit-Abuse Working Group,
               <http://www.maawg.org/>.

Falk Informational [Page 26] RFC 6449 CFBL Recommendations November 2011

 [MAAWG-BCP]   MAAWG, "MAAWG Sender Best Communications Practices
               Executive Summary and MAAWG Sender Best Communications
               Practices Version 2.0a-Updated", September 2011,
               <http://www.maawg.org/sites/maawg/files/news/
               MAAWG_Senders_BCP_Ver2.pdf>.
 [MARF]        Shafranovich, Y., Levine, J., and M. Kucherawy, "An
               Extensible Format for Email Feedback Reports",
               RFC 5965, August 2010.
 [MIME]        Freed, N. and N. Borenstein, "Multipurpose Internet
               Mail Extensions (MIME) Part One: Format of Internet
               Message Bodies", RFC 2045, November 1996.
 [RFC5322]     Resnick, P., Ed., "Internet Message Format", RFC 5322,
               October 2008.
 [RFC5598]     Crocker, D., "Internet Mail Architecture", RFC 5598,
               July 2009.
 [SMTP]        Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
               October 2008.
 [Trust]       Crocker, D., Ed., "Trust in Email Begins with
               Authentication", Issued by the Messaging Anti-Abuse
               Working Group (MAAWG), June 2008,
               <http://www.maawg.org/sites/maawg/files/news/
               MAAWG_Email_Authentication_Paper_2008-07.pdf>.
 [VERP]        Wikipedia, "Variable Envelope Return Path",
               <https://secure.wikimedia.org/wikipedia/en/wiki/
               Variable_envelope_return_path>.
 [Wise]        "arffilter - rewrite ARF reports",
               <http://wordtothewise.com/products/arffilter.html>.

Falk Informational [Page 27] RFC 6449 CFBL Recommendations November 2011

Appendix A. Abuse Reporting Format (ARF)

A.1. A Brief History

 The approach used by the first Feedback Loop to be deployed -- the
 "scomp" system at AOL -- was to send an entire copy of the message to
 the consumer of the Feedback Loop.  It expected that large Feedback
 Consumers would embed sufficient information in the email so they
 could identify which Message Recipient had complained.
 That worked well enough when there was only a single entity providing
 feedback, but as other Mailbox Providers started to offer Feedback,
 it became clear that it would be useful for the Feedback Provider to
 be able to add some additional information, both machine readable and
 human readable, to the report.  This led to ARF, the Abuse Reporting
 Format, which quickly became the de facto standard for Feedback
 Messages.
 Today, ARF is used by nearly all Feedback Providers, both within
 MAAWG and without, constituting the vast majority of all Feedback
 Messages generated worldwide.  ARF is recognized by all MAAWG members
 that have developed software or services that consume and process
 Feedback Messages.  There are no competing standards for reporting
 individual messages.
 ARF has now been published by the IETF as RFC 5965 [MARF].

A.2. Structure of an ARF Message

 An ARF report (Feedback Message) is sent by email, with one message
 sent for each Spam report made.  It consists of three sections, in a
 standard [MIME] message format called multipart/report.
 The first section contains human-readable plaintext, primarily for
 the benefit of small Feedback Consumers who are handling reports
 manually.  It typically contains boilerplate text explaining that
 this is a Feedback Message and providing URLs to other data such as
 contact information for the Feedback Provider or Mailbox Provider
 that originated the Feedback Message.
 The second section contains some machine-readable information,
 including the version of the ARF protocol used and the type of report
 it is ("abuse," "fraud," or other label).  It also might include some
 optional information about the email being reported, such as the
 original Envelope Sender or the time the mail was received.  In
 theory, the information in this section can be used to mechanically
 route and triage the report, though in current practice most Feedback

Falk Informational [Page 28] RFC 6449 CFBL Recommendations November 2011

 Messages are treated identically.  As a result, this section is often
 ignored entirely by Feedback Consumers who prefer to process the
 third section themselves.
 The third section of the report consists of a copy of the original
 email that the report is about, as a standard [MIME] message/rfc822
 attachment.  While ideally this would be an unmodified copy of the
 original email, it is likely that many producers of reports will
 modify or "redact" some elements of the report, especially the Email
 Address of the Recipient, due to privacy or other legal concerns.
 The strict technical specifications of ARF, as well as some example
 reports and tools to handle the format, can be found at
 <http://mipassoc.org/arf/>, [Wise], and in [MARF]

Appendix B. Using DKIM to Route Feedback

 Historically, the IP address of the "last hop" -- the MTA that
 transferred a message into the receiving Mailbox Provider's
 administrative domain -- was the sole reliable identifier used to
 denote the source of a message.  With the emergence of authentication
 technologies such as [DKIM], another identifier can now be used;
 specifically, the authenticated domain associated with a message.
 This domain is the "d=" value in a DKIM-Signature header field.
 In a social or policy context, applying a DKIM signature to a message
 is tantamount to stating, "I take responsibility for this message".
 The DKIM signature is most often applied by the author or originator
 of a message, which may be far upstream of the "last hop" MTA.  This
 is true particularly in cases where the originator's intended
 Recipient Email Address is configured to forward to another Recipient
 Email Address.  Stories of users who have strung together multiple
 forwarding accounts are not uncommon, and these users are unable to
 complain effectively about Spam because their Mailbox Providers
 cannot easily or reliably follow the path of a message back to the
 initial originator.
 A single DKIM "d=" value may be used across multiple servers with
 multiple IP addresses.  Servers may be added or removed at any time
 without changing the dynamics of the DKIM signature.  When a Feedback
 Loop is based on the IP address, the Feedback Consumer must contact
 the Feedback Provider to change its subscription options every time
 an IP address needs to be added or removed.  However, when a Feedback
 Loop uses DKIM, no reconfiguration is necessary because the signing
 domain does not change.

Falk Informational [Page 29] RFC 6449 CFBL Recommendations November 2011

 One recurring concern with DKIM, however, is that ESPs often send
 messages addressed with hundreds or thousands of customer domains,
 yet they want to receive Feedback Messages for all of these domains.
 This was particularly difficult with [DomainKeys] (the predecessor to
 DKIM), which tied the "d=" to the "From" header field.  DKIM removed
 this tie, so it is simple for an ESP to use a domain of its own to
 sign the message and sign up for Feedback regarding all messages
 signed with that domain.  Such a signature may be in addition to, or
 instead of, signatures from the various client domains.  While there
 are still many unknowns related to reputation (which will be
 addressed in a future MAAWG document), this is clearly an appropriate
 use of DKIM to take responsibility (and receive Feedback) for a
 message.

Appendix C. Unsolicited Feedback

 Is it always necessary for a Feedback Consumer to apply for a
 Feedback Loop or is it permissible for a Feedback Provider to
 configure a Feedback Loop for a Feedback Consumer without an explicit
 request?  There is continuing debate about whether this is an
 acceptable practice, and MAAWG is neither endorsing nor condemning
 such activity at this time.
 That said, if a Feedback Provider chooses to send Feedback without
 being asked first, certain guidelines should be followed.  In
 general, it should make prudent decisions to minimize the negative
 impact on Mailbox Providers and Access Providers.

C.1. Guidelines

 This should only be done for Mailbox and Access Providers.
 This should only be done after attempting to contact the provider to
 ask if it is possible to set up a Feedback Loop via the normal
 practice.
 These Feedback Loops should only be set up to send to the published
 abuse address from the provider's WHOIS record.

C.2. Pros

 Feedback Consumers may not realize they have abuse problems until
 they begin receiving the spam complaints.
 Feedback Consumers may not be aware of Feedback Loops and may
 appreciate the additional data feed.

Falk Informational [Page 30] RFC 6449 CFBL Recommendations November 2011

 Upstream providers have an additional information stream to help them
 identify problem customers.
 Spam coming from a network is abuse; therefore it is appropriate to
 send reports of the abuse back to the Mailbox Provider or Access
 Provider.  Setting up a Feedback Loop automates the process.

C.3. Cons

 It creates confusion for Feedback Consumers if they did not apply and
 do not understand why they are suddenly receiving complaints.
 It can conflict with existing Terms of Service because a new feed of
 information is available.  For example, if a provider has a policy to
 terminate service after a certain number of abuse complaints, and it
 starts receiving unexpected Feedback Loop complaints, it may either
 be forced to terminate customers that did not have a previous issue
 or be required to update its Terms of Service and Acceptable Use
 Policy agreements.
 Upstream providers do not have access to the mail being sent by their
 customers, so they cannot tell whether bulk mail complaints
 constitute a problem.
 The listed abuse address may not be the correct place for automated
 spam complaints to be sent.
 The listed abuse address may feed into a ticketing system that is not
 capable of correctly handling ARF messages.
 Feedback Consumers may not be equipped to handle the volume or format
 of complaints without some warning and preparation.

Author's Address

 J.D. Falk (editor)
 Messaging Anti-Abuse Working Group
 Presidio of San Francisco
 P.O. Box 29920
 572 B Ruger Street
 San Francisco, CA  94129-0920
 US
 EMail: ietf@cybernothing.org
 URI:   http://www.maawg.org/

Falk Informational [Page 31]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6449.txt · Last modified: 2011/11/17 04:57 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki