Christine Borgia
-
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
While you're visiting, be sure to check out the new IP Reputation lookup tool.
Christine
Manager, 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
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
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
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
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
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
Implementing Captcha on Postmaster Tools, Limit Requests
To protect our system, we will soon implement captcha on our postmaster tools, including the FBL and whitelist request forms. There are some senders who submit one request for each IP address used. Please do not do this any longer. When submitting whitelist or FBL requests on a range, please minimize the number of requests. Excessive requests may be denied.
Christine
Manager, Postmaster Team
Christine
Manager, Postmaster Team
Re: AOL Postmaster Blog System Maintenance, Loss of Feedback Loops
Everything is back to normal now. All spam complaints are now generating feedback loops as configured.
System Maintenance, Loss of Feedback Loops
We are doing some system maintenance which is resulting in the loss of 15% of outgoing feedback loops. We expect this to continue for the next few hours.
Christine
Christine
AOL Postmaster Support Restored
Postmaster support has been restored. Any requests that were submitted on our website have been processed, and you should have received an email confirmation.
We normally strive for a turnaround time of 24-48 hours, but requests are taking longer as we work through our backlog. It is not necessary to contact the call center to check the status of your ticket, or to submit duplicate tickets. We appreciate your patience.
We normally strive for a turnaround time of 24-48 hours, but requests are taking longer as we work through our backlog. It is not necessary to contact the call center to check the status of your ticket, or to submit duplicate tickets. We appreciate your patience.
Postmaster Support Offline Temporarily
Postmaster support is currently unavailable as we work through a technical issue. Thank you for your patience, and we will post when support is again available.
Change to the Report Card Process - Part Deux
As we promised, we will be sending a different report card to domains generating an excess of 1.0% inbox complaints on a given day. Below is the text of the 1% report card.
Christine
Manager, Postmaster Team
Dear [domain name],Expect this change to occur in the next few days.
You are receiving this message via our automated "Report Card" process because our available data indicate that in the last 24 hours your domain's [insert domain here] mail stream has exceeded an inbox complaint rate of 1%.
If you are an ISP, please investigate any active bot infestations, zombied computers, compromised webforms, etc.
If you are a bulkmailer, please ensure that you have a feedback loop, and that that you are following AOL's best practices guidelines for bulk-mailers.
If you are a hosting company, please ensure that you have a feedback loop on your shared servers and general IP space, and are monitoring it and addressing any problems.
If you are experiencing delivery issues as a result of rising complaints, please first address the situation and then if delivery problems persist, seek AOL's assistance via our Support Request Tools.
For additional information please visit our Postmaster website, where one can find a more detailed explanation of how the Report Card system works, AOL's technical requirements for sending email to us, AOL's best practices guidelines for bulk-mailers, and more.
This is an automated notification. Replies to this email will not be seen.
ChristineManager, Postmaster Team
Change to the Report Card Process
This is a heads up that we are going to be making a change next week to our Report Card process.
Previously, Report Cards were sent to any domain generating in excess of 0.1% inbox complaints. The Report Card itself listed the specific inbox complaint number.
The new Report Cards will be sent to domains generating in excess of 0.3% inbox complaints. While 0.1% is still the target for a bulk mailer, we do not feel it is necessary to alert mailers of a potential problem until they have reached 0.3%. In addition to this change, we will no longer be providing the specific inbox complaint percentage for each domain. The report card will simply be an indication that you have exceeded 0.3% and that you should check your processes to ensure you are managing your spam complaints.
We have also updated our Report Card information page on the Postmaster site and the text of the Report Card itself. The new text of the Report Card is as follows:
The next step we plan to take is to send a different report card to domains generating over 1.0% inbox complaints. So, if you have 0.3% - 1.0% you will get Report Card #1. If you have over 1% complaints, you will get Report Card #2. This change will likely be made in the coming weeks, and we will post the text for Report Card #2 at that time.
Christine
Manager, Postmaster Team
Previously, Report Cards were sent to any domain generating in excess of 0.1% inbox complaints. The Report Card itself listed the specific inbox complaint number.
The new Report Cards will be sent to domains generating in excess of 0.3% inbox complaints. While 0.1% is still the target for a bulk mailer, we do not feel it is necessary to alert mailers of a potential problem until they have reached 0.3%. In addition to this change, we will no longer be providing the specific inbox complaint percentage for each domain. The report card will simply be an indication that you have exceeded 0.3% and that you should check your processes to ensure you are managing your spam complaints.
We have also updated our Report Card information page on the Postmaster site and the text of the Report Card itself. The new text of the Report Card is as follows:
From: postmaster@aol.com [mailto:postmaster@aol.com]
Sent: 9/6/2005 9:45:07 AM Eastern Daylight Time
Subject: AOL email concerns for "domain name"
Dear "domain name",
You are receiving this message via our automated "Report Card" process because our available data indicate that in the last 24 hours your domain's [insert domain here] mail stream has exceeded an inbox complaint rate of 0.30%.
This email is only an indication that your domain's mail stream has exceeded a pre-defined complaint threshold; it is not necessarily indicative of a spam problem. We send a report card to every domain that exceeds this threshold, regardless of what type of mail is sent. We hope that it may be useful to help identify potential issues.
For additional information please visit our Postmaster website, where one can find a more detailed explanation of how the Report Card system works, AOL's technical requirements for sending email to us, AOL's best practices guidelines for bulk-mailers, and more.
This is an automated notification. Replies to this email will not be seen.
Sent: 9/6/2005 9:45:07 AM Eastern Daylight Time
Subject: AOL email concerns for "domain name"
Dear "domain name",
You are receiving this message via our automated "Report Card" process because our available data indicate that in the last 24 hours your domain's [insert domain here] mail stream has exceeded an inbox complaint rate of 0.30%.
This email is only an indication that your domain's mail stream has exceeded a pre-defined complaint threshold; it is not necessarily indicative of a spam problem. We send a report card to every domain that exceeds this threshold, regardless of what type of mail is sent. We hope that it may be useful to help identify potential issues.
For additional information please visit our Postmaster website, where one can find a more detailed explanation of how the Report Card system works, AOL's technical requirements for sending email to us, AOL's best practices guidelines for bulk-mailers, and more.
This is an automated notification. Replies to this email will not be seen.
The next step we plan to take is to send a different report card to domains generating over 1.0% inbox complaints. So, if you have 0.3% - 1.0% you will get Report Card #1. If you have over 1% complaints, you will get Report Card #2. This change will likely be made in the coming weeks, and we will post the text for Report Card #2 at that time.
Christine
Manager, Postmaster Team
Online Sender Support Tools
On July 8, 2008, David Zakar announced that AOL was launching beta online sender support tools. A big thanks to our pilot testers who helped us identify bugs and ensure that our tools are usable by everyone around the world*. I'm pleased to announce that we are removing the "beta" and launching our online support tools as the primary method of contacting the AOL Postmaster team. Moving forward, priority will be given to requests that come through our online tools.
There are currently four primary support pages. To receive the quickest and most accurate support, please fill in the entire form accurately.
FBL Modification/Deletion Request Tool: Any requests regarding FBLs should be made here.
RTR/RLY/DNS Block Removal Request Tool: This form is for mail administrators only. Telnet and nslookup results from the IPs in question are required to submit this form.
HVU Inquiry/Removal Tool: Anyone receiving an HVU error can submit a support request here. HVU blocks occur when you try to send email with a blocked URL to AOL users. This form will help you identify which URL is blocked and to request removal of the block.
Other information requests: We recognize that not all support requests will fit nicely into one of the buckets above, and this page is where you can tell us about any other issues you experience while sending mail to AOL users. We do not guarantee that you will receive a response to an inquiry placed using this form. If you are being blocked, please use the appropriate tool. Submitting an unblock request on the "Other" tool is the slowest way to resolve your issue.
If you have not already begun using our online support tools, please do so from here forward. Priority will be given to requests made through these tools, so bookmark these pages and take the call center number off your speed dial!
Christine
Manager, Postmaster Team
*The only known limitation of the tool right now is that it does not accept nslookup results in non-English languages. Please use an English-language version of nslookup, or translate the strings in your nslookup to English - use the troubleshooting guide's results to see what they should be. We hope to support more languages in the near future.
There are currently four primary support pages. To receive the quickest and most accurate support, please fill in the entire form accurately.
FBL Modification/Deletion Request Tool: Any requests regarding FBLs should be made here.
RTR/RLY/DNS Block Removal Request Tool: This form is for mail administrators only. Telnet and nslookup results from the IPs in question are required to submit this form.
HVU Inquiry/Removal Tool: Anyone receiving an HVU error can submit a support request here. HVU blocks occur when you try to send email with a blocked URL to AOL users. This form will help you identify which URL is blocked and to request removal of the block.
Other information requests: We recognize that not all support requests will fit nicely into one of the buckets above, and this page is where you can tell us about any other issues you experience while sending mail to AOL users. We do not guarantee that you will receive a response to an inquiry placed using this form. If you are being blocked, please use the appropriate tool. Submitting an unblock request on the "Other" tool is the slowest way to resolve your issue.
If you have not already begun using our online support tools, please do so from here forward. Priority will be given to requests made through these tools, so bookmark these pages and take the call center number off your speed dial!
Christine
Manager, Postmaster Team
*The only known limitation of the tool right now is that it does not accept nslookup results in non-English languages. Please use an English-language version of nslookup, or translate the strings in your nslookup to English - use the troubleshooting guide's results to see what they should be. We hope to support more languages in the near future.
