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 220.127.116.11, 18.104.22.168 and 22.214.171.124. The confirmation and FBL messages will come from email@example.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.
How are the confirmation addresses chosen?
The method chosen depends on the requested feedback entity. For an IP or IP range, reverse DNS and WHOIS, are both queried. The Reverse DNS method looks at the hostnames of the IP or the starting and ending IPs of the range. The system will allow you to chose between the users abuse@ and postmaster@ for each domain identified. The WHOIS approach queries global, regional, and national IP registrars, such as ARIN and APNIC, using the range and any referenced record returned for that range.
For an ASN, a WHOIS query will be made in manner similar for that of IPs, but instead for the ASN itself. However, the CIDRs associated for ASN are the entities actually confirmed for the feedback loop request. Further additions or modification to the CIDRs associated with an ASN must be submitted as additional requests. The information on what subnets are advertised each ASN is provided by RouteViews.org and we would like to thank them for making that available.
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 firstname.lastname@example.org<mailto:email@example.com>.
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.