Feedback loops: net benefit or net harm?

There has been a very long, ongoing discussion on one of my mailing lists about whether or not feedback loops are a net good or a net harm. I believe, overall, they are a net good, but there are people who believe they are not. The biggest objection is that the lawyer mandated redaction of the To: address combined with the fact that some users use the “this is spam” button to delete unwanted email, makes it difficult for some FBL recipients to sort out the real issues from the cruft.
Redaction can be a problem for some senders, particularly for the small mailing list hosted as a hobby or contribution to the community. In order to effectively deal with FBL emails, a sender needs to have tools on the email sending side and on the FBL receiving side. This is often more overhead than the volunteer list maintainer wants to handle. Unfortunately, these senders are a minority and therefore their issues are often not addressed by the ISPs.
Some of the objections and complaints about “broken” or “useless” FBLs come from people who do not really have any history for the FBLs, where they are, what they were designed for and who their target audience is. A bit of history may help explain why things are how they are.
The First FBL
The “this is spam” button evolved from the “notify AOL” button. This button was a way email recipients could notify AOL staff about any number of problems, including threats, viruses and other unwanted emails. As time went on, this was changed to “this is spam” to encourage users to report more spam so the AOL would have the data to make delivery decisions. Eventually, AOL made the decision to share that data with some senders and ISPs. The lawyers made the decision to redact the “To:” address, but not make any other changes to the message because they believe they should not be sharing subscriber email addresses with third parties. As some people correctly point out, the lawyers are not interested in hearing from non lawyers about changing this. It is possible that another lawyer may be able to put together a position paper and convince them this stance is overly cautious. I am pretty sure, though, that no one without a legal degree will be given any audience from them.
Given the success of the AOL FBL and the demand from both ESPs and ISPs for FBLs, other ISPs started offering FBLs as well. Many of them also redacted the To: address, either just following AOL’s lead or under advice of their own counsel.
That means, as senders, we are in a situation where we really cannot make the ISPs change what they’re doing. We can either adapt our own mailing practices to cope with them or we can forego the data provided by the FBL. One of the challenges in choosing to shun the whitelist at AOL that in order to qualify for whitelisting, you have to accept a FBL. For ISPs, who want to whitelist their outgoing MTAs, but have customers sending mail, maybe running small mailing lists, or who are forwarding mail to their ISP account, this can be a problem. However, any ISP needs some sort of abuse desk automation, and this automation should be able to handle FBLs. This can also be a problem for small ESPs or companies doing in-house email marketing. They buy something off the shelf to handle mail (or install mailman) that does not do VERP or otherwise enter the specific address in the email. When faced with a redacted email they cannot do anything with the complaint.
What does the FBL email tell the FBL recipient?
This really depends on what role the FBL recipient plays in the mail transport system. Bandwidth and network service providers use the FBL as an aggregate tool. They really only deal with FBL complaints if there is a change in complaint volume about an IP, they don’t treat each complaint as a valuable source of information. Typically what happens is that an ISP abuse desk notices a spike in complaints. After investigation, they may discover that a customer machine is compromised. They then notify the customer, the customer patches or disconnects the machine and the problem is fixed.
ESPs tend treat the FBL as an unsubscribe mechanism as well as a way to monitor customers. A few FBL complaints are not necessarily a sign that the sender is spamming, but once a threshold is reached the ESP delivery / abuse team addresses the issue. Spammers can get FBLs and often use them as a way to clean lists of complainants. Some really dirty spammers even suppress those complainants from all their lists.
Is a FBL useful?
This is really something that someone else cannot tell you. Some companies find FBLs to be extremely useful, even after they have had to make investments in software (either off the shelf or custom) to send mail that will survive the FBL redaction process and to handle the actual FBL email. Some companies find the FBLs to be more trouble than they are worth. The question, however, is really one only the sender can answer.
Overall, I think FBLs are more helpful than they are harmful. They do require investment on both sides of the transaction, but does encourage senders and receivers to cooperate with one another.

Related Posts

FBL updates

Roadrunner shifted the release date for their new FBL to December 14th.
Despite rumors, the Yahoo FBL is not actually accepting new participants.

Read More

AOL and DKIM

Yesterday, on an ESPC call, Mike Adkins of AOL announced upcoming changes to the AOL reputation system. As part of these changes, AOL will be checking DKIM on the inbound. Best estimates are that this will be deployed in the first half of 2009, possibly in Q1. This is something AOL has been hinting at for most of 2008.
As part of this, AOL has deployed an address where any sender can check the validity of a DKIM signature against the AOL DKIM implementation. To check a signature, send an email to any address at dkimtest.aol.com.
I have done a couple of tests, from a domain not signing with either DK or DKIM, from a domain signing with DK and from a domain signing with both DK and DKIM. In all cases, the mail is rejected by AOL. The specific rejection messages are different, however.
Unsighng domain: host dkimtest-d01.mx.aol.com[205.188.103.106] said: 554-ERROR: No DKIM header found 554 TRANSACTION FAILED (in reply to
end of DATA command)
DK signing domain: “205.188.103.106 failed after I sent the message.
Remote host said: 554-ERROR: No DKIM header found
554 TRANSACTION FAILED”
DK/DKIM signing domain: “We tried to delivery your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 554 554-PASS: DKIM authentication verified
554 TRANSACTION FAILED (state 18).”
As you can see, in all cases mail is rejected from that address. However, when there is a valid DKIM signature, the failure message is “554-PASS.”
As I have been recommending for months now, all senders should be planning to sign with DKIM early in 2009. AOL’s announcement that they will be using DKIM signatures as part of their reputation scoring system is just one more reason to do so.

Read More

Declan weighs in on the VA law

Declan McCullagh writes today about the VA anti-spam law being overturned by the state supreme court.

Read More