Mail problems at AOL

We cannot help endusers troubleshoot AOL connection problems. Please do not call. Please do not write. You need to talk to AOL. We are not AOL. We cannot help you. 

 
Over the last few months there have been ongoing mail problems at AOL. These problems are all over the map and are resulting in a lot of delayed and unsent email. People are reporting a number of different error messages from AOL mail servers. These messages don’t seem to always be accurate or correct.
A couple examples:
SMTP error from remote mail server after end of data: host mailin-02.mx.aol.com [64.12.90.65]: 521 5.2.1 :(CON:B1) http://postmaster.info.aol.com/errors/554conb1.html reported by the owner of a low volume discussion list with paying subscribers that should have zero complaints.
delivery temporarily suspended: host mailin-01.mx.aol.com[205.188.146.193] refused to talk to me: 421 mtain-dg03.r1000.mx.aol.com Service unavailable – try again later reported by all sorts of senders.
205.188.190.2 failed after I sent the message. Remote host said: 521 5.2.1 “TempFail” reported by a small mail host.
554 mtain-dc03.r1000.mx.aol.com ESMTP not accepting connections reported by an ESP.
421 4.7.0 mtain-dg05.r1000.mx.aol.com Error: too many errors reported by a university, a mailserver vendor and a bunch of ISP and telcos.
This is not a constant or consistent set of errors. It is coming and going, with AOL reporting things are fixed and senders reporting queues emptying. However, every time it seems to be fixed, something else breaks.
There isn’t much anyone outside of AOL can do, though. This has to be fixed internally by their engineers. I’m afraid this is just the result of a highly complex system that is failing due to bit rot, though. Which means only significant investment in time and programming power can fix this for all of us. I do hope I’m wrong.
It’s weird to be writing this blog post the same day I found out that Jay Levitt, one of the original AOL mail system architects has died. I didn’t know Jay well, although he did post a comment here once or twice. I haven’t heard any details, yet, but it’s strange to be writing about AOL mail today.
Update Feb 8, 2016: AOL users are having problems logging in. Word to the Wise cannot help you. Please do not contact us for help. Contact AOL directly.

Related Posts

AOL delivery problems

There have been ongoing reports this week from ESPs and ISPs that AOL is having problems accepting email. People are reporting difficulties connecting to AOL MTAs and random dropping of connections. Other people are reporting random rejection messages that make no sense. A number of folks are seeing rejections claiming that the reason is a new IP when that IP has successfully sent mail from that IP in the recent past.
AOL seems to be working on things, and some people are seeing improvements. If you’re seeing AOL problems recently, it’s not you. It’s them.
EDIT: AOL has asked senders to please reduce mail volume while they are resolving issues.

Read More

20% of email doesn't make it to the inbox

Return Path released their global delivery report for the second half of 2009. To put together the report, they look at mail delivery to the Mailbox Monitor accounts at 131 different ISPs for 600,000+ sends. In the US, 20% of the email sent by Mailbox Monitor customers to Return Path seed accounts doesn’t make it to the inbox. In fact, 16% of the email just disappears.
I’ve blogged in the past about previous Return Path deliverability studies. The recommendations and comments in those previous posts still apply. Senders must pay attention to engagement, permission, complaints and other policy issues. But none of those things really explain why email is missing.
Why is so much mail disappearing? It doesn’t match with the philosophy of the ISPs. Most ISPs do their best to deliver email that they accept and I don’t really expect that ISPs are starting to hard block so many Return Path customers in the middle of a send. The real clue came looking at the Yahoo numbers. Yahoo is one of those ISPs that does not delete mail they have accepted, but does slow down senders. Other ISPs are following Yahoo’s lead and using temporary failures as a way to regulate and limit email sent by senders with poor to inadequate reputations. They aren’t blocking the senders outright, but they are issuing lots of 4xx “come back later” messages.
What is supposed to happen when an ISP issues a 4xx message during the SMTP transaction is that email should be queued and retried. Modern bulk MTAs (MessageSystems, Port25, Strongmail) allow senders to fine tune bounce handling, and designate how many times an email is retried, even allowing no retries on a temporary failure.
What if the missing mail is a result of senders aggressively handling 4xx messages? Some of the companies I’ve consulted for delete email addresses from mailing lists after 2 or 3 4xx responses. Other companies only retry for 12 – 24 hours and then the email is treated as hard bounced.
Return Path is reporting this as a delivery failure, and the tone of discussion I’m seeing seems to be blaming ISPs for overly aggressive spamfiltering. I don’t really think it’s entirely an ISP problem, though. I think it is indicative of poor practices on the part of senders. Not just the obvious permission and engagement issues that many senders deal with, but also poor policy on handling bounces. Perhaps the policy is fine, but the implementation doesn’t reflect the stated policy. Maybe they’re relying on defaults from their MTA vendor.
In any case, this is yet another example of how senders are in control of their delivery problems. Better bounce handling for temporary failures would lower the amount of email that never makes it to the ISP. This isn’t sufficient for 100% inbox placement, but if the email is never handed off to the ISP it is impossible for that email to make it to the inbox.

Read More

Broken record…

The Return Path In the Know blog listed 4 reasons mailing those old addresses is a bad idea.
Ashley, the author, is completely right and I endorse everything she said. (Although I’d really like to hear what happened to the customer that added back all those addresses. What was the effect on that campaign and future email marketing?) As I was reading the article though, I realized how many times this has been said and how depressing it is that we have to say it again. And again. And again.
A number of folks have told me that the reason they don’t pay any attention to delivery professionals is because we don’t provide enough real data. They can show that sending mail to old addresses costs them nothing, and makes them real money.
That’s not really true, though. We do provide data, they just don’t like it so they don’t listen to it. Return Path publishes lots of numbers showing that mailing unengaged recipients lowers overall delivery. I can provide case studies and data but companies that are committed to sending as much mail as possible throw up many reasons why our data isn’t good or valid.
The biggest argument is that they want hard numbers. I do understand this. Numbers are great. Direct and clear answers are wonderful. But delivery is a squishy science. There are a lot of inputs and a lot of modifiers and sometimes we can’t get exactly one answer. The data is noisy, and difficult to replicate. One of the reasons is that filtering is a moving target. Filters are not, and cannot be, fixed. They are adaptive and are changing even between one hour and the next.
Delivery experts are about risk management. They are the parents requiring everyone in the car wear seat belts, even though the driver has never had an accident. They are the fire department enforcing fire codes, even though it’s the rainy season.
Risk management isn’t about the idea that bad things will absolutely happen but rather that it is more likely that a bad thing will happen in some cases.
In this case, it’s more likely that delivery problems will happen when mailing old addresses. And if those addresses aren’t actively contributing to revenue, it’s hard to argue that their presence on a list is more beneficial than their absence.
But I repeat myself. Again.

Read More