Some webmail users seeing "oops" page redirection.

A webmail authentication issue is causing some AOL/AIM user sessions to be redirected to defunct sites. Users affected by this issue will see "oops... this page no longer exists" errors.

We are aware of the issue and are working on a resolution.

**This issue was resolved 3/11/2010 at 11:30PM, Eastern**

Thanks,
mkr.

Inbound Mail Delays

Internet senders may experience delays in sending to mailboxes hosted on AOL. The problem which caused the delays has been fixed; our queues are currently draining. We expect mail delivery to resume at a normal rate by 11AM Eastern, today.

***Update*** This issue was resolved Thursday, March 11 at 10:20AM, Eastern.

mkr.

RTR:DU Block Update

We've had intermittent issues with RTR:DU (spamhaus PBL blocks) refuses beginning 2/23, which will be fixed by 10AM Eastern on Monday, March 8.

If you've been seeing RTR:DU errors and you have confirmed your sending IP is not listed in the Spamhaus PBL, your issue should be cleared on Monday.

Thanks for your patience,
mkr.

Error code fixed

We should not be returning "451 4.3.0 <invaliduser@aol.com>: Temporary lookup failure" for invalid users as of 2/18. If people are still seeing this error code issued after that date, please let us know.

--
Annalivia Ford
Senior Technical Account Manager
AOL Postmaster Team

Error code update

We are at present issuing a "451 4.3.0 <invaliduser@aol.com>: Temporary lookup failure" which should be read as "User not known". This is transient and we will post an update when it stops.

This is not replacing the existing two codes:

500, text= 5.1.1 <invaliduser@aol.com>: Recipient address rejected: aol.com

and

550 Mailbox not found

Senders using scripts to remove unknown users automatically should be looking for all three codes for the moment.

--
Annalivia Ford
Senior Technical Account Manager
AOL AntiSpam

ARF fix pushed successfully

The additional text included in some of the feedback loops was corrected as of Friday. Thank you for letting us know about it.

--
Annalivia Ford
Senior Technical Account Manager
AOL Postmaster Team

System Status Update

There have been reports of our ARF feedback loops having some extra text in them that is causing parsing problems for some people. We are aware of the issue and will be rolling a fix by the end of the business week.

The MTA migration continues. Please check back here for updates. We will post them as we get them.


--
Annalivia Ford
Sr. Technical Account Manager
AOL AntiSpam Operations

Postmaster Team Update

The Postmaster team has suffered significant staff reductions, and any tickets opened will see slower processing times. Thank you for your understanding and patience.



-Annalivia Ford
Senior Technical Account Manager
AOL Postmaster Team

Migration Updates

  • New error code for invalid mailboxes/user unknown:
ERROR [state=rcpt_to, code=550, text= 5.1.1 <invaliduser@aol.com>: Recipient address rejected: aol.com

[edited]
The actual error code is
500 5.1.1 <sdfklsdksdfdfd@aol.com>: Recipient address rejected: aol.com


Senders using scripts to remove unknown users automatically should be looking for both the new error code and the old one.

The Postmaster site will be updated with new SMTP error codes as quickly as possible.
  • Still migrating, and the MTA timeouts continue, but mail should go through on re-try. If this is not the case please contact us and let us know. Please include some log lines so that we can troubleshoot. A manual SMTP session would also be invaluable.
  • Some feedback loop recipients may find they have malformed ARF. We are aware of the problem and are working on a fix.



-Annalivia Ford
Senior Technical Account Manager
AOL Postmaster Team

Mail Delivery Delays

AOL Mail is installing a new MTA. This is resulting in delayed deliveries to our members. We appreciate your patience.

New AOL Postmaster Website

If you visit the AOL Postmaster website today, you will probably notice that it looks a little lot different. We've reorganized and streamlined the site to make it easier for the many different types of people that visit to quickly find the information they are looking for. Whether you are an ISP, an AOL Mail user, or an Email Service Provider - if you're having trouble sending or receiving mail from AOL, you can find the information you need here.

While you're visiting, be sure to check out the new IP Reputation lookup tool.



Christine
Manager, Postmaster Team

Feedback Loops De-Mystified

We get a lot of questions about AOL spam complaints, what they are, what they mean, what they do, etc.

AOL's mail system is set up in such a way that members who use the AOL software, webmail, and certain 3rd party mail clients such as Outlook with IMAP can report unwanted mail to AOL by selecting the undesirable mail, and either clicking on the "spam" button, or dragging it to the spam folder.

AOL spam complaints are generated by AOL members through explicit user action, and they can only report spam on mail in their inboxes. These reports are never automatically generated by the system without user action.

When a member performs this action, it creates a "spam complaint", which sends a copy of the header and body to AOL. If the sending network has IP ownership rights and has set up a feedback loop, a copy will also be sent to them, in a standardized format called "ARF".

The sending network can then do different things with the complaint, depending on the circumstances.

Bulk senders can:
  • remove complainants from their mailing lists in order to help manage their IP reputation.
  • use complaints to identify clients who generate the highest volume, and work with them on their acquisition and retention practices.
  • work on better branding, better subject lines, different content, and then test and see if people respond better.
  • monitor incoming complaints live, spot a problem mailing as it is happening, and stop it before it causes more damage.
Hosting companies and mailbox providers can:
  • use their FBL to identify spamming/compromised accounts.
  • monitor their incoming complaint feed to pinpoint virus outbreaks, botnets, etc.
  • locate customers that are using their IPs as mail servers against the network TOS.
  • ignore complaints about mail from Grandma as false positives.

Corporate mail server admins can use their FBL to spot compromised machines behind their NAT, or unintentional loops created by employee "out of the office" auto-acks.

Small mailing list/listserv/groups owners should ensure their recipients have an easy way to opt out of the list included on every email sent, to reduce the number of complaints generated, and can also use their complaints feed to curb abuse of the group.

AOL does not have any policy requirements that specify actions to be taken in response to a spam complaint. High amounts of spam complaints could result in action against your IP, so it is in your best interest to ensure you keep your spam complaints to a minimum.

That being said, as a sending network, receiving a single spam complaint does not mean that any value judgments have been made about your IP, domain, or brand. It does not mean that your IP(s) will be blocked. It does not mean your mail has been targeted by AOL. It simply means that the person who received the mail reported it to AOL using the "spam" button. It could have been because they truly believe it to be spam. They could be having a bad day and reported all of their inbox as spam out of frustration. They could have done it by accident. We are aware that there will be false positives, and have taken that fact into account, so there is no reason to assume your IP will be blocked for a handful of complaints. However, if you are seeing delivery issues on your whitelisted IP, you should start by taking some action to reduce your spam complaints, and by contacting us to let us know what kind of mail your IP sends.


--
Annalivia Ford, AOL Postmaster Team

Permission vs. Request

The first step to obtaining a high level of user engagement is permission. Before you send someone an email, you should obtain their permission, right? Not exactly. Engagement comes when users REQUEST mail, not just concede to receive it. How many times has a telemarketer called and asked for you, and you tell them that you are not home. They say they will call back at another time, hoping to find you home. Inside you say "Ughhhhh" but you hear your voice say "Okay, that sounds good." They know it's you, they know you are home, and they know you will pretend not to be home next time they call. But they will do it anyway, because you didn't tell them not to.

A deliverability vendor recently contacted me and said that a big client was having trouble sending to AOL and asked me to look into it. This sender is one that I have worked with repeatedly in the past and that causes me much consternation. They claim to send only opt-in notifications to their members, yet the statistics on the mail are abysmal -- high complaints and low engagement all around. They had fallen off my radar for a while but they were back. Evidently our IP reputation system was not happy with their mail and was delivering most of it to the spam folder.

I take a look. Stats are still abysmal. What we are sending to the inbox is generating complaints. What we are sending to the spam folder is going unnoticed. All engagement metrics are low. Everything about this mail stinks, which obviously does not add up to opt-in notification mail. Hmmm...

I decide to test it out myself. I visit the website and try to run a query. To see the results of my query, I am requested to log into the site or create a new login. I create a new login, and before I submit my request, I see the tiny print telling me that by creating this account, I permit this site to send me periodic notifications. I click submit, generate my account, and view the results of my query. That day, I begin receiving notifications from this website that there are new listings on their site that match my query. There is a link in the email telling me that I can modify my email settings, so I click on that and am taken to the website. Here, I uncheck all of the email notification boxes, so I should never be contacted by email again. In essence, I am not required to receive emails in order to do searches on their site, but I am forced to initially sign up for those emails then unsubscribe manually.

So, I speak to the sender and explain to them that their permissions process needs fixing, and until they fix it, our reputation system will continue to deliver their mail to the spam folder. He does not believe that it's a permissions issue, considering all of the mail is opt-in. Which brings us back to the word REQUEST.

When I signed up on the site, I was required to give permission (i.e., opt in to receive their email notifications) in order to proceed with my account creation. Is it permission-based? I guess I'd have to agree that it is. But is it wanted? The sender has no idea whether it's wanted. I didn't request these emails, and I wasn't given the option to request them. Now, the sender can argue until his face turns blue about permission, opt-in, CAN-SPAM, etc. But at the end of the day, this practice leads to bad user engagement and more mail being delivered to the spam folder. In this case, we were not blocking the mail outright, because there are, in fact, a large number of people who DO want this mail, and we want to be sure that they get it. Why not just let those people request the mail, which would increase the chance they get it in their inbox and actually look at it? What good does it do to send mail to people that don't want it, thereby having most of it get delivered to the spam folder?

So I made some recommendations. First, the account creation process needs to be modified. Users should be asked whether they would like to receive email notifications. Expectations should be set as to which emails they will be receiving and how often. The site should be as flexible as possible, allowing users to customize their mailings (I may want a notification when new items matching my search are available, but may not want a weekly summary, for instance). Second, he should remove from his list anyone who didn't specifically request the emails and who also hadn't visited his site in some period of time.

The sender complained that doing this would negatively impact his bottom line. He was afraid that people, if asked, would not subscribe to the emails. He said his site received a lot of activity from the emails, because a lot of people don't realize they want the emails until they actually receive them. Basically, he wanted to send email to everyone who ever visited his site, in the hopes that some of them would not mind. He would remove those who complained about it, and then have a squeaky clean list. Unfortunately for him, it doesn't work that way.

Bottom line... Permission isn't enough. Our best practices document says "Ensure that you are only sending mail to users who specifically requested it." Look at your opt-in process. Are people really requesting your mail? If not, I'd bet you aren't seeing the inbox delivery you'd like to see.

Christine
Manager, Postmaster Team

Changes to the Enhanced Whitelist

I wanted to let you know about changes we have made to our Enhanced Whitelist, or EWL. The EWL is generated on a daily basis, and IPs on the EWL are delivered to the inbox with images and links enabled. Historically, any IP on our regular whitelist that fell below a certain complaint threshold was added to the EWL. This meant that IPs with excellent mail statistics were not included in the EWL if they had not applied for the whitelist. Similarly, some IPs were on the EWL due to low complaints, even though the IP didn't have the best IP reputation. (Reminder: a positive reputation requires not only low complaints, but also high user engagement.)

Taking this into consideration, we have modified our EWL process to benefit IPs with our highest internal reputation score. This means that IPs being added to the EWL have consistently maintained a low complaint level as well as high user engagement.

The EWL serves to benefit senders with very targeted lists, whose mail is wanted and expected by the recipients. Making our EWL reputation-based ensures that these senders are rewarded for their adherence to best practices.

Christine
Manager, Postmaster Team

AOL hosting mail for MMC/mail.com domains

AOL has inked an agreement to host mail for MMC/mail.com domains. The roll-out will be in several phases. In September, AOL began MXing for mail.com domains. The list of domains can be found on www.mail.com. Right now, AOL is taking the messages on our inbound relays, then handing them off to Outblaze, where the mailboxes are currently hosted. This should not be misinterpreted as AOL spoofing or being an open relay.

New MMC mailboxes are being hosted at AOL. We are in the process of migrating existing MMC mailboxes to the AOL system. This process will continue for the next several weeks until complete.

What does this mean for you?

You will already be seeing SMTP errors from AOL if we do not accept delivery of a message on our relays. This will be the familiar RLY:B1, DYN:T1, HVU:B1, etc. errors. As mailboxes are created on AOL or migrated to AOL, they will be included in our complaint feedback loop process.

What do you need to do?

Nothing new. Delivery, whitelisting, feedback loops, etc. applies to all mail delivered to our complex, whether it is for aol.com mailboxes, my eAddress mailboxes, or any other domains for which we host mail. Any technical questions or delivery issues related to this change should follow our normal Postmaster support process. Mail.com remains an independently owned and operated business. Any business questions related to mail.com should be directed to mail.com.

Christine
Manager, Postmaster Team

Next Page >

AOL Postmaster Blog bloggers (30 days)

#BloggerPostsCmts
1Margot Romary31
2Annalivia Ford11

Most Commented On (7 days)