AOL has updated their Postmaster pages with a new design and new resources for senders who are sending to AOL. If you are sending to AOL, use the updated site to sign up for the feedback loop, request whitelisting, open a trouble ticket, or learn about the AOL error codes and bulk sending best practices.
Things are extremely busy here and blogging is going to be light for a few weeks. I’ll be reposting some older blog posts that are still relevant for today’s email senders.
Today’s post is a repost from November 2008. I look at the whys and hows of FBLs, address some of the objections people had to them and discuss how senders should deal with FBL mail.
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 like our Abacus software, or something custom written internally) 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.
Comcast recently published a statement on DMARC over on their postmaster page. The short version is that Comcast is publishing a DMARC record, but has no current intentions to publish a p=reject policy for Comcast user email. Comcast will be publishing a p=reject for some of their domains that they use exclusively to communicate with customers, like billing notices and security notices.
Comcast does point out that Yahoo! and AOL’s usage of p=reject is “not common usage.”
This is something a lot of people have been arguing loudly about on various mail operations lists and network lists. DMARC is about organizational identity. In fact, I was contacted about my DMARC primer and told that I didn’t mention that it’s not about domains, it’s about organizations.
The way I read the DMARC spec, it is all about organizational identity. The underlying theme being that the domain name is linked to a particular organization and everyone using email at that domain has some official relationship with that organization. I’ve always read the spec mentally replacing organization with corporate brand. This was for brands and organizations that strictly control how their domains are used, who can use those domains and how the mail is sent with those domains.
I never expected any mailbox provider or commercial ISP to publish a p=reject message as it would just break way too much of the way customers use email. And it did break a lot of legitimate and end user uses of email. Many organizations have had to scramble to update mailing list software to avoid bouncing users off the lists. Some of these upgrades have broken mailbox filters, forcing endusers to change how they manage their mailboxes.
Even organizations see challenges with a p=reject message and can have legitimate mail blocked. At M3AAWG 30 in San Francisco I was talking with some folks who have been actively deploying DMARC for organizations. From my point of view anyone who wants to publish a DMARC p=reject should spend at least 6 months monitoring DMARC failures to identify legitimate sources of email. The person I was talking to said he recommends a minimum of 12 months.
This is just an example of how difficult it is to capture all the legitimate sources of emails from a domain and effectively authenticate that mail. For a mailbox provider, I think it’s nearly impossible to capture all the legitimate uses of email and authenticate them.
It remains to be seen if the other mailbox providers imitate Yahoo! and AOL or if they push back against the use of DMARC reject policies at mailbox providers. Whatever the outcome, this is a significant shift in how email is used. And we’re all going to have to deal with the fallout of that.
I was doing some research about the evolution of the this-is-spam button for a blog article. In the middle of it, I found an old NY Times report about spam from 2003.
Read More