AOL MX Change update

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

[S]tarting this week, the majority of AOL’s MX records will point to [OATH’s] new combined servers. This should be transparent to any sender as those servers will operate in simple pass-through mode. This means senders with established FBLs will continue to receive them from our AOL mail infrastructure.

Change is coming, but it should be mostly invisible to folks. Those of you using hardcoded MXs in your sending engines, will want to adjust them later this week.
One thing that is interesting, and is new to me is these are new combined servers. I have been saying that the AOL / Yahoo integration would involve changes in their mail handling processes, but this is the first time I’ve seen anything from AOL confirming that suspicion. In fact, when I first heard about this, I understood this was the AOL MXs switching to Yahoo, not new combined servers.
Hopefully this transition will go smoothly for everyone involved. Recent history with Microsoft suggests that MX changes are challenging at the best of times.

Collecting email addresses
Microsoft using the List-Unsubscribe header

Related Posts

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

Why do ISPs do that?

One of the most common things I hear is “but why does the ISP do it that way?” The generic answer for that question is: because it works for them and meets their needs. Anyone designing a mail system has to implement some sort of spam filtering and will have to accept the potential for lost mail. Even the those recipients who runs no software filtering may lose mail. Their spamfilter is the delete key and sometimes they’ll delete a real mail.
Every mailserver admin, whether managing a MTA for a corporation, an ISP or themselves inevitably looks at the question of false positives and false negatives. Some are more sensitive to false negatives and would rather block real mail than have to wade through a mailbox full of spam. Others are more sensitive to false positives and would rather deal with unfiltered spam than risk losing mail.
At the ISPs, many of these decisions aren’t made by one person, but the decisions are driven by the business philosophy, requirements and technology. The different consumer ISPs have different philosophies and these show in their spamfiltering.
Gmail, for instance, has a lot of faith in their ability to sort, classify and rank text. This is, after all, what Google does. Therefore, they accept most of the email delivered to Gmail users and then sort after the fact. This fits their technology, their available resources and their business philosophy. They leave as much filtering at the enduser level as they can.
Yahoo, on the other hand, chooses to filter mail at the MTA. While their spamfoldering algorithms are good, they don’t want to waste CPU and filtering effort on mail that they think may be spam. So, they choose to block heavily at the edge, going so far as to rate limit senders that they don’t know about the mail. Endusers are protected from malicious mail and senders have the ability to retry mail until it is accepted.
The same types of entries could be written about Hotmail or AOL. They could even be written about the various spam filter vendors and blocklists. Every company has their own way of doing things and their way reflects their underlying business philosophy.

Read More

Goodmail shutting down

Yesterday Goodmail sent out mail to all their customers announcing they are ceasing operations and taking all their token generators offline as of 5pm pacific on February 8th.
While this is a bit of a surprise on one level, I’m not that shocked. Ken Magill mentioned in August that Goodmail was on the sales block and rumors have been circulating for weeks about significant changes coming to Goodmail.
Goodmail has struggled to find a market since they first started. At one point they were even giving services away to customers at partner ESPs. Despite the free service, people at some of those ESPs told me they were having difficulty getting customers to adopt Goodmail.
Likewise, on the ISP side, Goodmail didn’t seem to have much penetration into the market. They had AOL, Yahoo and some cable companies, but not much else. And as of early last year, Yahoo removed the Goodmail machines.
I think the real underlying problem was that most companies who are doing things well don’t need certification services. Sure, there are a couple exceptions but in general anyone who is sending good mail is getting to the inbox. Even for companies where delivery was not quite as good as they might want, the marginal improvement at those ISPs that do use Goodmail was not sufficient to justify the cost of Goodmail services.
While I have the utmost respect for the Goodmail management team I think this result was almost inevitable. I never got the impression they valued the end recipient quite as much as the ISPs do. That was just one thing that lead me to believe they just didn’t seem to understand the email ecosystem quite the way that a certification service should.
I echo Dennis’ thoughts and well wishes towards the Goodmail folks. The experiment in sender financed delivery was well worth doing and I think they did it as well as anyone could have.

Read More