Feedback Loop (email)

From Seo Wiki - Search Engine Optimization and Programming Languages

Jump to: navigation, search

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[1].

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 (, or determined by querying either the Regional Internet registry's whois databases --which may have query result limits[2]-- or other databases created specifically for this purpose[3].


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.)[4]

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.


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.[5] 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. [6]

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. [7].

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[8].

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[9]. 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[10] 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[6]. Consequently, report spam may act as unsubscribe in some cases[11]. One of the reasons not to hit unsubscribe links is to avoid confirming that the message had been received and opened[12]. 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.


  • 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.[13] 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[14]. For example, it does not ease reporting to a list owner that a specific post in the (non moderated) list is actually spam[15].

Abuse Feedback Reporting Format (ARF)

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

In January of 2010, the IETF chartered [19] 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: <>
  Date: Thu, 8 Mar 2005 17:40:36 EDT
  Subject: FW: Earn money
  To: <>
  MIME-Version: 1.0
  Content-Type: multipart/report; report-type=feedback-report;
  Content-Type: text/plain; charset="US-ASCII"
  Content-Transfer-Encoding: 7bit
  This is an email abuse report for an email message received from IP on Thu, 8 Mar 2005 14:00:00 EDT. For more information
  about this format please see
  Content-Type: message/feedback-report
  Feedback-Type: abuse
  User-Agent: SomeGenerator/1.0
  Version: 0.1
  Original-Mail-From: <>
  Original-Rcpt-To: <>
  Received-Date: Thu, 8 Mar 2005 14:00:00 EDT
  Content-Type: message/rfc822
  Content-Disposition: inline
  From: <>
  Received: from (
       []) by 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
  Date: Thu, 02 Sep 2004 12:31:03 -0500
  Spam Spam Spam
  Spam Spam Spam
  Spam Spam Spam
  Spam Spam Spam

Feedback Loop Links for some Email Providers

YAHOO (Uses ReturnPath) (requires DomainKeys or DKIM)

USA.NET (Uses ReturnPath)




COMCAST (Uses ReturnPath)

ROADRUNNER (Uses ReturnPath)

BLUETIE (Uses ReturnPath)


  1. "Feedback Loop Setup". datran media. 2007-05-08. Retrieved 16 November 2008.  It contains examples of how to subscribe to AOL,, Excite FBL, Hotmail, SpamCop, and more.
  2. "Community Consultation Underway - Removal of WHOIS Query Result Limit". ARIN. 2007-03-12. Retrieved 2009-09-28. "[T]he ARIN WHOIS query limit of 256 results [...] has been in place since ARIN's inception as a means of curtailing data mining." 
  3. "Global Reporting". 2009-07-05. Retrieved 2009-09-28. "With this approach, we provide solid, accurate and reliable information about spam mails and other abusive behavior to ISP in order to help them clean their network." 
  4. J.D. Falk (2008-11-11). "FeedBack loops". ASRG mailing list. IRTF. Retrieved 18 November 2008. 
  5. Rich Kulawiec (2008-11-13). "FeedBack loops". ASRG mailing list. IRTF. Retrieved 16 November 2008.  But cf. Matthew G. Nelson (2007-03-28). "Report: Consumers Are Savvier Spam Defenders Than Previously Thought". ClikZ. Retrieved 16 November 2008. 
  6. 6.0 6.1 Derek Harding (2006-09-07). "Getting in the Feedback Loop". ClikZ. Retrieved 16 November 2008. 
  7. "What are feedback loops (fbl’s) and how can they help my deliverability?". Email Manual. 2009-07-15. Retrieved 15 July 2009. 
  8. "Your Reputation Holds the Key to Deliverability". ReturnPath. 2008-08-18. Retrieved 16 November 2008. 
  9. "Hotmail Running Its Own SMTP Variation". CircleID. 2008-05-17. Retrieved 16 November 2008.  It reports a case of stealth blocking
  10. RFC 2369 The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields defines the URL to unsubscribe to serial messages, which should presumably correspond to some button on the Mail User Agent, but are usually just not visible.
  11. John Levine (2008-11-13). "FeedBack loops". ASRG mailing list. IRTF. Retrieved 18 November 2008. 
  12. "Spam Unsubscribe Services". The Spamhaus Project. 2007-01-19. Retrieved 16 November 2008. 
  13. Chris Lewis (2008-11-12). "FeedBack loops". ASRG mailing list. IRTF. Retrieved 18 November 2008. 
  14. Barry Shein (2008-11-13). "FeedBack loops". ASRG mailing list. IRTF. Retrieved 18 November 2008. 
  15. Barry Shein (2008-11-13). "FeedBack loops". ASRG mailing list. IRTF. Retrieved 18 November 2008. 
  16. Yakov Shafranovich (2005-04-14). "New Abuse Draft". Retrieved 17 November 2008. 
  17. Y. Shafranovich; J. Levine; P. Hoffman; M. Kucherawy (2008-06-16). "An Extensible Format for Email Feedback Reports". IETF. Retrieved 17 November 2008. 
  18. Christine Borgia (2008-06-27). "AOL Converting All FBLs to ARF on 9/2/08". AOL. Retrieved 17 November 2008. 
  19. IETF. "MARF charter". Retrieved January 26 2010. 

External links


Personal tools

Served in 1.732 secs.