Feedback Loop (email)

A feedback loop (FBL), sometimes called a complaint feedback loop, is an inter-organizational form of feedback by which an internet service provider (ISP) forwards the complaints originating from their users to the sender's organizations. ISPs can receive users' complaints by placing report spam buttons on their webmail pages, or in their email client, or via help desks. The message sender's organization, often an email service provider, has to come to an agreement with each ISP from which they want to collect users' complaints.

As an alternative, abuse complaints may be directly sent to addresses where such feedback might be received. Target abuse mailboxes can be assumed to be in the form defined by RFC 2142 (abuse@example.com), or determined by querying either the Regional Internet registry's whois databases --which may have query result limits-- or other databases created specifically for this purpose.

Reporting process

1. Spencer sends a message to Alice.
2. Alice complains to Isaac (her ISP) about the message, e.g. by hitting the report spam button.
3. Isaac encapsulates the message as either an Abuse Reporting Format MIME part, or (less commonly) a standalone message/rfc822 MIME part, and sends it to Spencer (if Spencer has signed up to receive that feedback.)

In rare cases, these feedback loops may not be based on user reports. For example, they may be based on automated virus detection, or similar mechanisms.

Advantages

The gain for the email system as a whole may appear questionable, since the report spam button is said by some to often be used improperly. However, benefits to each involved party are possible.

Advantages for senders

Marketers striving for their mail to be delivered have a twofold advantage: they can remove subscribers that don't want to receive that kind of advertising (listwashing), and they can analyze the complaint rate and thence how their advertising meets market expectations.

Although it may seem like a bit of a waste unsubscribing users who complain once, in the long term it will pay dividends. By unsubscribing users who complain once you are reducing the likelihood of them complaining again, this means your overall complaint rate per IP or domain is kept low which is the key metric that ISP’s use to choose whether or not to deliver your messages. By keeping your complaint rate low from your messages to ISP’s which have feedback loops they are much more likely to allow your messages straight through to the inbox ensuring you continue to get your emails to the subscribers who actually want to receive them. .

ESPs, when playing the sender's role, are very sensitive to how sending mail on behalf of their customers may affect their reputation. Monitoring the complaint rate is one of the ways they can control what their users are sending.

Advantages for ISPs

ISPs delivering unwanted messages dissatisfy their users. Thus they deploy spam filters. However, spam filtering is not an exact science and rough operations may result in incorrect behavior. Getting to terms with legitimate senders can mitigate some of the resulting inconveniences.

Advantages for users

The spam button brings some fuzzy functionality. Automatic unsubscribe is an example. For years, end users have been told not to trust email unsubscribe links, so many users hit the spam button as a way of unsubscribing. Consequently, report spam may act as unsubscribe in some cases. One of the reasons not to hit unsubscribe links is to avoid confirming that the message had been received and opened. As it is difficult to know exactly what personally identifiable information is being transferred in a feedback loop, it may seem that the spam button defeats that reason. Users have to trust their ISP for not getting into agreements with spammers, in the strict sense of the latter term.

Criticism

• The feedback loops fail to meet the generic anti-spam criterion of not generating more email messages. Even if the amount of feedback is just a fraction of the amount of messages that en ESP sends out, most ESPs are not yet organized for handling it. This is mitigated by the fact that feedback loops are voluntary (opt in e-mail) for both the sender and receiver of the feedback.
• Using the same button for both abuse reports and list unsubscribe implies guesswork by the (automated) help desk. For example, it does not ease reporting to a list owner that a specific post in the (non moderated) list is actually spam.

Abuse Feedback Reporting Format (ARF)

A draft describing a standard format for FBL reports was posted by Yakov Shafranovich in April 2005 and evolved to the current draft format at the IETF. AOL, who pioneered the field in 2003, initially used a different format, and converted to this de facto standard in 2008. Feedback loops don't have to use ARF, but most do.

In January of 2010, the IETF chartered a new working group working towards the goal of standardizing the ARF format. The new WG is called Messaging Abuse Reporting Format WG or MARF.

The ARF format is designed to be extensible, providing for generic spam reporting, e.g. from users to some anti-spam center or help desk, or for opt-out operations. The format defines a new MIME type to be included in a multipart/report attachment, and includes at least the headers of the offending message. Although the draft description acknowledges that some operators may choose to modify or redact that portion for privacy or legal reasons, it recommends that the entire original email message be attached, including the unmodified recipient address.

An ARF-encapsulated FBL report comes with the same subject as the offending message. Much like bounce messages, an FBL report consists of a human readable part, followed by a machine readable part, and the original message. The machine readable part's type is message/feedback-report, whose definition is the core of the draft. Extensibility is achieved by including a Feedback-Type field that characterizes the report. Possible values of this field are

abuse	spam or some other kind of email abuse;
dkim	a DKIM signature verification error;
fraud	indicates some kind of fraud or phishing activity;
miscategorized	indicates that the content categorization applied in connection with a certification or reputation system was incorrect;
not-spam	indicates that a message that was tagged or categorized as spam (such as by an ISP) is not spam;
opt-out	a request to opt out from mailings from this provider;
virus	report of a virus found in the originating message;
other	any other feedback that doesn't fit into other types.

A IANA registry is provided for the Feedback-Type, as well as for the other field names. Each field name may either be relevant for any type of feedback, or for a specified type only. Some fields may appear multiple times. For example, the Source-IP field, containing the IP address from which the original message was received, may appear in any type of FBL report, but only once; the Removal-Recipient field, indicating email addresses to be removed, may only appear in opt-out reports, but one or more times. In addition, there is a DKIM-Failure subtype, with its own IANA registry.

An example report for email abuse is as follows. (Note that only the first three lines of the machine readable part are required.)

  From: <abusedesk@example.com>
  Date: Thu, 8 Mar 2005 17:40:36 EDT
  Subject: FW: Earn money
  To: <abuse@example.net>
  MIME-Version: 1.0
  Content-Type: multipart/report; report-type=feedback-report;
       boundary="part1_13d.2e68ed54_boundary"
   
  --part1_13d.2e68ed54_boundary
  Content-Type: text/plain; charset="US-ASCII"
  Content-Transfer-Encoding: 7bit
   
  This is an email abuse report for an email message received from IP
  10.67.41.167 on Thu, 8 Mar 2005 14:00:00 EDT. For more information
  about this format please see http://www.mipassoc.org/arf/.
   
  --part1_13d.2e68ed54_boundary
  Content-Type: message/feedback-report
   
  Feedback-Type: abuse
  User-Agent: SomeGenerator/1.0
  Version: 0.1
  Original-Mail-From: <somespammer@example.net>
  Original-Rcpt-To: <user@example.com>
  Received-Date: Thu, 8 Mar 2005 14:00:00 EDT
  Source-IP: 10.67.41.167
  Authentication-Results: mail.example.com
                 smtp.mail=somespammer@example.com;
                 spf=fail
  Reported-Domain: example.net
  Reported-Uri: http://example.net/earn_money.html
  Reported-Uri: mailto:user@example.com
  Removal-Recipient: user@example.com
   
  --part1_13d.2e68ed54_boundary
  Content-Type: message/rfc822
  Content-Disposition: inline
   
  From: <somespammer@example.net>
  Received: from mailserver.example.net (mailserver.example.net
       [10.67.41.167]) by example.com with ESMTP id M63d4137594e46;
       Thu, 08 Mar 2005 14:00:00 -0400
  To: <Undisclosed Recipients>
  Subject: Earn money
  MIME-Version: 1.0
  Content-type: text/plain
  Message-ID: 8787KJKJ3K4J3K4J3K4J3.mail@example.net
  Date: Thu, 02 Sep 2004 12:31:03 -0500
   
  Spam Spam Spam
  Spam Spam Spam
  Spam Spam Spam
  Spam Spam Spam
  --part1_13d.2e68ed54_boundary--

Feedback Loop Links for some Email Providers

YAHOO (Uses ReturnPath) http://feedbackloop.yahoo.net/index.php (requires DomainKeys or DKIM)

USA.NET (Uses ReturnPath) http://fbl.usa.net/

AOL http://www.postmaster.aol.com/fbl/index.html

HOTMAIL https://support.msn.com/eform.aspx?productKey=edfsjmrpp&page=support_home_options_form_byemail&ct=eformts&scrx=1

UNITED ONLINE http://www.unitedonline.net/postmaster/whitelisted.html

COMCAST (Uses ReturnPath) http://feedback.comcast.net/

ROADRUNNER (Uses ReturnPath) http://feedback.postmaster.rr.com/

BLUETIE (Uses ReturnPath) http://feedback.bluetie.com/

External links

• What are feedback loops (fbl’s) and how can they help my deliverability?
• Mutual Internet Practices Association has an /arf section
• Messaging Anti-Abuse Working Group mentions feedback loops in various published documents
• abusix UG (haftungsbeschraenkt) offers automatic abuse handling software and consulting for ISPs
• Word to the Wise's ARF page has some software tools