Feedback loop (email)
A feedback loop (FBL), sometimes called a complaint feedback loop, is an inter-organizational form of feedback by which a Mailbox Provider (MP) forwards the complaints originating from their users to the sender's organizations. MPs 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 MP from which they want to collect users' complaints.
Feedback loops are one of the ways for reporting spam. Whether and how to provide an FBL is a choice of the MP. End users should report abuse at their mailbox provider's reporting hub, so as to also help filtering. As an alternative, competent users may send abuse complaints directly, acting as mailbox providers themselves.
- Spencer sends a message to Alice.
- Alice complains to Isaac (her ISP) about the message, e.g. by hitting the report spam button.
- 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. Otherwise, RFC 6650 provides for auto-subscribe just-in-time FBLs, started by sending an unsolicited abuse report that contains further directives (at a minimum, a way to unsubscribe).
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. 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 hence 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 an alternative to 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.
- 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 an 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.
- Setting up FBLs requires filling out web forms. This can be inconsistent from one FBL to another.
- Some FBLs provide no option for communicating feedback automatically to multiple parties: the sender, the ESP (if one is involved), or the upstream datacenter/network address provider—as currently construed by the Federal Trade Commission's (FTC) "Follow the Money" strategy.
- There is no convenient way for a sender to automatically and repeatedly verify that a FBL is operating correctly without tarnishing the sender's deliverability. Furthermore, manual FBL testing for low-volume senders significantly degrades the sender's Sender Score as calculated by Return Path.
- There is no convenient mechanism for discovering new FBLs. RFC 6650 provides for auto-subscription on the Feedback Provider's own initiative, which may be a convenient mechanism as long as senders can easily update their Whois data or set up
abuse@mailboxes effectually. However, that diminishes the opt-in mitigation for the first point above.
- Work has begun at www.maawg.org on an "FBL 2.0" initiative to resolve these issues.
Abuse feedback reporting format
The Abuse Reporting Format (ARF) is the standard format for FBL reports. Much like bounce messages, whose design is inherited by ARF, an abuse report consists of a human readable part, followed by a machine readable part, and the original message. The report is characterized by a Feedback-Type field whose values may indicate one of abuse, fraud, virus, or other (more types are registered at IANA).
Microsoft, who use the name Junk Mail Reporting (JMR), also use their own format.
- AOL http://www.postmaster.aol.com/Postmaster.FeedbackLoop.html
- Bluetie/Excite http://feedback.bluetie.com/
- Comcast http://feedback.comcast.net/
- Cox http://fbl.cox.net/
- Earthlink (email only): fblrequest at abuse.earthlink.net
- Fastmail http://fbl.fastmail.fm/
- Hotmail https://support.msn.com/eform.aspx?productKey=edfsjmrpp&page=support_home_options_form_byemail&ct=eformts&scrx=1
- Mail.ru http://postmaster.mail.ru/
- OpenSRS/Tucows http://fbl.hostedemail.com/
- Outblaze (mail.com): email ONLY: postmaster at outblaze.com
- QQ.com http://open.mail.qq.com/
- Rackspace (formerly Mailtrust) http://fbl.apps.rackspace.com/
- RoadRunner/Time Warner Cable http://feedback.postmaster.rr.com/
- Synacor http://fbl.synacor.com/
- Terra http://fbl.mail.terra.com.br/
- USA.NET http://fbl.usa.net/
- United Online/Juno/Netzero http://www.unitedonline.net/postmaster/whitelisted.html
- Yahoo! http://feedbackloop.yahoo.net/ (requires DomainKeys or DKIM)
- Zoho.com http://fbl.zoho.com/
- J.D. Falk, ed. (November 2011). Complaint Feedback Loop Operational Recommendations. IETF. RFC 6449. https://tools.ietf.org/html/rfc6449. Retrieved 30 November 2011.
- John R. Levine (9 December 2009). "Adding a spam button to MUAs". mail. ASRG. Retrieved 22 April 2011.
- J.D. Falk (2008-11-11). "FeedBack loops". ASRG mailing list. IRTF. Retrieved 18 November 2008.
- Murray Kucherawy, ed. (June 2012). Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF). IETF. RFC 6650. https://tools.ietf.org/html/rfc6650. Retrieved 28 June 2012. "Feedback Providers MUST provide a way for report recipients to request that no further reports be sent."
- 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.
- Derek Harding (2006-09-07). "Getting in the Feedback Loop". ClikZ. Retrieved 16 November 2008.
- "What are feedback loops (fbl’s) and how can they help my deliverability?". Email Manual. 2009-07-15. Retrieved 15 July 2009.
- "Your Reputation Holds the Key to Deliverability". ReturnPath. 2008-08-18. Retrieved 16 November 2008.
- "Hotmail Running Its Own SMTP Variation". CircleID. 2008-05-17. Retrieved 16 November 2008. It reports a case of stealth blocking
- 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.
- John Levine (2008-11-13). "FeedBack loops". ASRG mailing list. IRTF. Retrieved 18 November 2008.
- "Spam Unsubscribe Services". The Spamhaus Project. 2007-01-19. Retrieved 16 November 2008.
- Chris Lewis (2008-11-12). "FeedBack loops". ASRG mailing list. IRTF. Retrieved 18 November 2008.
- Barry Shein (2008-11-13). "FeedBack loops". ASRG mailing list. IRTF. Retrieved 18 November 2008.
- Barry Shein (2008-11-13). "FeedBack loops". ASRG mailing list. IRTF. Retrieved 18 November 2008.
- Deborah Platt Majoras et al (2004-09). "A CAN-SPAM Informant Reward System". US Federal Trade Commission. Retrieved 8 November 2011.
- "Services for Senders and ISPs". Microsoft. Retrieved 11 November 2011.
- Mutual Internet Practices Association has an /arf section
- Messaging Anti-Abuse Working Group mentions feedback loops in various published documents
- abusix GmbH offers automated abuse handling software and consulting for ISPs
- Word to the Wise's ARF page has some software tools
- Free eMail Deliverability Guide - A guide to the industry best practices and the basics on how to improve your deliverability.