Frequently Asked Questions

What is a Feedback Loop?
A Feedback Loop (FBL) is a system by which an Internet Service Provider (ISP) provides the sender a copy of a message that one of their subscribers has reported as spam – usually by hitting a “report spam” button in that ISP’s mail interface. A feedback loop service may be offered by ISPs to people or companies sending mail via an IP address they manage. ISPs offer feedback loops to qualified senders, so the senders can identify either (a) customers who no longer want to receive similar mail (b) any problems originating from their networks, such as virus-infected spam-producing machines.

Feedback Loop recipients are generally expected to remove any subscriber from their mailing lists to prevent similar “spam complaints” – but the core requirement is simply that they fix whichever problems within their network caused the complaints.

What will be the format for the FBL messages?
The messages will be sent in the standard Abuse Feedback Reporting Format (ARF). You can find a definition of this format and sample reports in the following document: http://mipassoc.org/arf/specs/draft-shafranovich-feedback-report-02.html. All reports generated by this FBL will be of type Feedback-Type: abuse.

More information about this format and related efforts can be found at http://mipassoc.org/arf/.

What IP address/ email address/ domain will these FBL emails be sent from?
The FBL’s will come from IPs in the range now 66.45.29.128/26 (= 66.45.29.128 - 66.45.29.191). The confirmation and FBL messages will come from feedback@feedback.bluetie.com.

I never got my confirmation message. Now what?
Please check whether email to your confirmation address is being filtered. If so, look in your junk mail folder and make sure to whitelist the IP addresses and email address listed above. If you still cannot find the confirmation message, use the “Resend confirmation” link from the FBL sign-up page and have the confirmation message sent again. You will need to click on the link in the confirmation message before the request can be approved or declined.

What domain should I use when requesting a Feedback loop?
Please use a domain used in mail sent from the IP addresses for which you requested to receive feedback. The domain you enter is also the destination the confirmation message. So, use a domain used in outbound mail from these IP addresses at which you can receive mail to the abuse or postmaster address.

Are there tools available for me to process these messages?
Sample messages and some basic tools to help in the processing can be found at http://mipassoc.org/arf. Return Path also provides a commercial solution to process these messages for you in a simplified manner.

How do I tell if my feedback loop is working?
Are you receiving reports? If not, the easiest method is to send a message to an account which you control, and then report that message as spam. (Don’t worry, one complaint won’t doom your mail to the junk folder forever.)

I’m not receiving any feedback loop reports. What now?
There are two basic reasons why you might not be receiving reports:

Nobody’s complaining. Time to celebrate!
Your mail is already being filtered to the “spam” folder, or equivalent. If your messages aren’t in a user’s inbox, the user won’t complain about them.
There’s something wrong with the email address that the reports are being sent to. Try sending a message to it from an account you control, and check your mail logs or other internal diagnostics to find out what’s happening.

How do I process complaints from the feedback loop?
We recommend that you remove unhappy subscribers from your mailing lists to prevent future complaints. However, the core requirement is for senders to address any issues within their mail program or network that are causing complaints.

The ISP may redact parts of the original message to protect the privacy of their users. In the event an ISP redacts subscriber email addresses from their feedback loop messages, you should incorporate a tracking ID unique to the recipient's record in your database and your messages so that you can process the removals. You can add this ID in the body of the message or add an "X" header in the header of the message. An example of this could be X-SenderName-ClientID: 543432."

Problem: Some MTA configurations, particularly Sendmail, will automatically resolve the CNAME upon receipt. This will make mail appear to be from feedbackloop@fbl.senderscore.net<mailto:feedbackloop@fbl.senderscore.net>.
This is a client-side issue. However, we have investigated the root cause and recommend the following solution:

This appears to be a problem with the default configuration of all versions of Sendmail. (It is unknown which, if any, other MTAs also use this as a default setting).

The Sendmail configuration documentation can be found at: http://www.sendmail.org/documentation/configurationReadme

The macro option confDONT_EXPAND_CNAMES is set to false by default, meaning the default behavior of all versions of Sendmail is to expand CNAMES.

Specifically, the documentation says:

confDONT_EXPAND_CNAMES DontExpandCnames [False]
If set, $[ ... $] lookups that do DNS based lookups do not expand CNAME records. This currently violates the published standards, but the IETF seems to be moving toward legalizing this. For example, if "FTP.Foo.ORG" is a CNAME for "Cruft.Foo.ORG", then with this option set a lookup of "FTP" will return "FTP.Foo.ORG"; if clear it returns "Cruft.FOO.ORG". (N.B. you may not see any effect until your downstream neighbors stop doing CNAME lookups as well.)

That documentation is years out of date. Specifically, IETF RFC2821 says that CNAME records are fine and don’t need to be expanded.