Feedback Loops cover


Feedback Loops

Several weeks ago Validity announced that they are to start monetizing their Universal Feedback Loop service which has been in use by a number of ISPs and relied upon by many in the industry for some time now.

Since then, there has been much discussion and confusion about “What’s next?” in the industry. Especially since Validity seems to care more about its balance sheet than the email ecosystem, this has been long coming, as Laura Atkins of WttW sums this up in her latest blog post.

What are Feedback Loops, and why are they important?

Once upon a time, consumers were told never to click on an unsubscribe in an email because if the email was not from a legitimate source, they would give the “bad guys” the feedback that their email actively used and therefore a great target for more spam.

This is still somewhat true today, but only for a tiny percentage of messages that someone might receive; even some of the “bad guys” don’t want to continue sending to recipients that might report them or are unlikely to respond to their messages.

However, unsubscribes are essential for the legitimate email-sending industry. If a recipient who signed up for a mailing list no longer wishes to receive further messages, then this is the proper way to do it and ensure that the email sender maintains clean lists and only sends to engaged recipients who want their mail.

But users might not want to click the unsubscribe and possibly have to answer a few questions. Just clicking the “This is Spam” is so much easier, and it is supposed to achieve the same goal, right? From a user perspective, their goal would be achieved – one less unwanted message in the inbox.

Return-Path (now Validity), a company at the time helping to promote good sending practices in the industry, understood that this information would be very valuable for senders and for their certification programs.

So they built their Universal Feedback Loop service, so that participating ISPs could send them the messages where their users clicked “This is Spam” and they would report these actions back to approved originators of these messages, allowing them to remove the recipients from the mailing lists and at the same time provide an indication of the “Complaint Rate” which in turn helps ESPs deliverability teams monitor and educate their customers and maintain their reputation. Win-win, as this helps both the sender and recipient and Return-Path could also leverage this data for their certification programs.

Feedback Loops

So what’s next?

In Laura’s blog post, she references the Independent RFC draft proposing the use of a “CFBL-Address” header which the sender would put into their messages, telling the receiver where to send Feedback Loop data (provided the necessary criteria is met).

Having read this, we think this is a very promising idea, however, looking at our own spam trap data, the only entity currently sending CFBL-Address headers is CleverReach, who are the authors of this draft.

Getting something else in place quickly will be nearly impossible as it will require new development work for the mailbox providers, and they will still have to individually approve any CFBL-Addresses that are discovered.

Over the past few months, we have been working on our “Global Reporting” project, which is basically Abuse-Reporting-as-a-free-service. Essentially, we will take in abuse reports and provided they meet the requirements by supplying enough useful data to report a given abuse type – we’ll do it on behalf of the reporter and send a valid XARF report to the network owner for action, using our ContactDB to determine where to send the report. Our goal is to help improve the standard of reporting by using XARF and to increase the amount of entities reporting abuse by making it easier to do so and ultimately reporting as much abuse as possible, so that action can be taken against the source.

We have already started reporting spam trap data on behalf of several partners and will increase this steadily over the next few months.

If there was interest from the email community, then we could add Feedback Loops into the capabilities of our Global Reporting project relatively easily and quickly.

We would propose that in a very short time frame, we could:

  • Allow mailbox providers to send their Feedback Loop data to us using a unique mailbox address per provider.
  • Look for and validate the CFBL-Address header(s) present in any messages sent to the FBLs and report these in XARF format to the reporting address.
  • We would manage the approval of individual CFBL-Addresses based on the data we use for Abusix Mail Intelligence in a mostly automated way.

Longer-term we could:

  • Allow reporting in ARF/MARF if there was a desire for this.
  • Provide some high level statistics.

So what does Abusix get out of this?

Firstly, it’s good for the email community of which we are a part and helps drive adoption of the Independent Draft RFC.

Secondly, this will help drive adoption of XARF as “The” Abuse Reporting standard, instead of the myriad of non-standard and unparsable formats that are currently used.

And lastly, the data owner can optionally allow us to use the FBL data to help improve Abusix Mail Intelligence.

We’re happy to discuss this with the community either at ETIS or M3AAWG. Feel free to reach out to either of us directly or via LinkedIn.

Read More


At Abusix, our philosophy is that in order to truly implement effective abuse-handling, you need to see issues faster with...


The modern-day botnet attack is comprised of many machines, often home PCs, managed from an Internet Relay Chat (IRC) channel....