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

Announcement: No More Report Cards

Just a quick announcement to let you know that we are no longer sending report cards. If you have a complaint feedback loop, make sure you are monitoring your spam complaints and not relying on the report card to alert you to complaint issues. If you don't have a feedback loop, you can apply for one here: http://postmaster.aol.com/Postmaster.FeedbackLoop.html

Reminder: Do not use the comment section of this blog to request postmaster support. Support requests must be submitted here: http://postmaster.aol.com/Postmaster.SupportRequest.html.

Christine
Manager, Postmaster Team

AOL Changing Mailer Daemon Error Senders

AOL is making a change which will affect the behavior of ALL bounce messages for both inbound and outbound mail.

Currently all bounce messages have the sender name of MAILER-DAEMON@aol.com.

With the changes for outbound mail, ALL bounce messages will have the sender name of MAILER-DAEMON@sender-domain. For example, an AIM account sending invalid recipients to the internet, will receive a bounce from MAILER-DAEMON@aim.com, and a switched.com member from MAILER-DAEMON@switched.com, UK member from MAILER-DAEMON@aol.co.uk.

With the changes for inbound mail, ALL bounce messages (mostly due to user-defined spam settings) will have the sender name of MAILER-DAEMON@recipient –domain. For example, a member of yahoo sending to an AIM account with a user-defined block, would receive a bounce message from MAILER-DAEMON@aim.com.

This may result in multiple bounce messages generated for a single piece of email being returned to the same sender. One bounce message is generated for each unique recipient domain.

For example, a member of yahoo sending a message with four recipients, two AIM accounts and two switched.com accounts (all with user-defined blocks), would receive ONE bounce message from MAILER-DAEMON@aim.com and ONE from MAILER-DAEMON@switched.com.

These changes will be installed into production over the next couple of weeks.

Christine
Manager, Postmaster Team

AOL Postmaster Support Restored

AOL Postmaster support is back online. Thanks again for your patience. We did not lose any requests as far as we know, so please wait patiently for responses.

-David

Postmaster Support Temporarily Offline

Postmaster support is currently offline as we work through a technical issue. Your requests will be processed (eg, you should receive an email that your request was received), but will not be actioned until the system comes back online. Please do not submit multiple requests on the same issue. We will post an entry on the blog when the system is back online.

Thank you for your patience.

-David

Next Page >

AOL Postmaster Blog bloggers (30 days)

#BloggerPostsCmts
1Annalivia Ford40

Recent Comments

AOL Postmaster Blog Tags

news