Whitelisting is dead

A decade or so ago I was offering whitelisting services to clients. It was pretty simple. I’d collect a bunch of information and do an audit on the customer’s sending. They’d get a report back identifying any issues that would limit their chances at acceptance. Then I’d go and fill in the forms on behalf of the client. Simple enough work, and it made clients feel better knowing their mail was whitelisted at the various ISPs.
When email filters were less complex and more binary, whitelists were a great way for receivers to identify which senders were willing to stand up and be held accountable for their mail. Over time, whitelists became much less useful. Filtering technology progressed. Manual whitelisting wasn’t necessary for ISPs to sort out good mail from bad.
The era of whitelisting is over.
In fact, three of the major whitelist providing ISPs were AOL, Yahoo, and Verizon; all three are now a part of OATH. The Verizon whitelist page now redirects to postmaster.aol.com. New requests to signup for the AOL whitelist are rejected with the message that AOL whitelisting is no longer available or necessary. Yahoo has a “new IP review” form rather than a whitelisting form.
Whitelisting is dead.
Even the various certification and whitelisting services have mostly gone away. Both Habeas and Goodmail failed to achieve a profitable exit event. Of course, Return Path is still around, but they have built a platform of tools and services unrelated to whitelisting or certification.
Now senders are going to have to focus on sending mail that people ask for and want in order to make it to the inbox.
 

Another day another dead blacklist
List the world!

Related Posts

AOL Changes

We’ve known for a while that AOL email infrastructure is going to be merging with Yahoo’s, but apparently it’s happening sooner than anyone expected.
The MXes for aol.com will be migrated to Yahoo infrastructure around February 1st. Reading between the lines I expect that this isn’t a flag day, and much of the rest of the AOL email infrastructure will be in use for a while yet, but primary delivery decisions will be made on Yahoo infrastructure.
The AOL and Yahoo postmaster teams are pretty smart so I assume they’ll have made sure that their reputation data is consistent, and be doing everything else they can do to make the migration as painless as possible. But it’s a major change affecting a lot of email, and I wouldn’t be surprised to see some bumpiness.
If you’ve done anything … unwise … with delivery to AOL addresses, such as hard-wiring MXes for delivery to aol.com, you should probably look at undoing that in the next week or so. I’m guessing the changeover will happen at the DNS level, so if you’ve nailed down delivery IPs for aol.com you might end up trying – and probably failing – to deliver to the old AOL infrastructure.
 

Read More

AOL MX Change update

The AOL postmaster team posted some information about the upcoming MX transition on their blog.

Read More

DMARC and organizations

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.

Read More