AOL Postmaster Support down Jan 16th through Jan 20th

AOL just posted that the backend of their postmaster support ticketing system will be down over the from January 16th through January 20th. This means that while new tickets can be opened, work will not proceed on them until the system is back up on Jan 20th. I expect this also means that any tickets in the system might be delayed as well.

Related Posts

Reputation: part 2

Yesterday, I posted about reputation as a combination of measurable statistics, like bounce rates and complaint rates and spamtrap hits. But some mailers who meet those reputation numbers are still seeing some delivery problems. When they ask places, like AOL, why their mail is being put into the bulk folder or blocked they are told that the issue is their reputation. This leads to confusion on the part of those senders because, to them, their reputation is fine. Their numbers are exactly where they were a few weeks ago when their delivery was fine.
What appears to have changed is how reputation is being calculated. AOL has actually been hinting for a while that they are looking at reputation, and even published a best practices document back in April. Based on what people are saying some of that change has started to become sender visible.
We know that AOL and other ISPs look at engagement, and that they can actually measure engagement a lot more accurately than sender can. Senders rely on clicks and image loading to determine if a user opened an email. ISPs, particularly those who manage the email interface, can measure the user actively opening the email.
We also know that ISPs measure clicks. Not just “this is spam” or “this is not spam” clicks in the interface, but they know when a link in an email has been clicked as well.
I expect that both these measures are now a more formal and important part of the AOL reputation magic.
In addition to the clicks, I would speculate that AOL is now also looking at the number of dead addresses on a list. It is even possible they are doing something tricky like looking at the number of people who have a particular from address in their address book.
All ISPs know what percentage of a list is delivered to inactive accounts. After a long enough period of time of inactivity, mail to those accounts will be rejected. However for some period of time the accounts will be accepting mail. Sending a lot of mail to a lot of dead accounts is a sign of a mailer who is not paying attention to recipient engagement.
All ISPs with bulk folders have to know how many people have the from address in their address book. Otherwise, the mail would get delivered incorrectly. In this way, ISPs can monitor the “generic” recipient’s view of the email. Think of it as a similar to hitting the “this is not spam” button preemptively.
This change in reputation at the ISPs is going to force senders to change how they think of reputation, too. No longer is reputation all about complaints, it is about sending engaging and relevant email. The ISPs are now measuring engagement. They are measuring relevancy. They are measuring better than many senders are.
Senders cannot continue to accrete addresses on lists and continue sending email into the empty hole of an abandoned account while not taking a hit on their reputation. That empty hole is starting to hurt reputation much more than it helps reputation.

Read More

Google Apps – where's my abuse@

Most ISP feedback loops require you to demonstrate that you’re really responsible for your domain before they’ll start forwarding reports to you. The usual way that works is pretty similar to a closed-loop opt-in signup for a mailing list – the ISP sends an email with a link in it to the abuse@ and postmaster@ aliases for your domain, and you need to click the link in one or both of the emails to continue with the feedback loop signup process.
That’s mostly there to protect you, by making sure that someone else can’t get feedback loop messages for your domain. And it’s not too difficult to do, as you should already have an abuse@ and postmaster@ alias set up, and have someone reading the abuse@ alias.
But maybe you’re using Google Apps to host your corporate email, and that’s the domain you need to use for your feedback loops. So you go to create abuse and postmaster users, but it won’t let you – you just get the error Username is reserved for email list only. Uhm, what?
Google want to police use of domains hosted on their service, so they automatically set up abuse and postmaster aliases for your domain, and any mail sent to them is handled by Google support staff. You may well be happy with Google snooping on your abuse role account, but you really need to be able to read the mail sent to it yourself too.
So what to do? Well, the way Google set things up they actually create invisible mailing lists for the two role accounts, and subscribe Google Support to the lists. In older versions of Google Apps you could make those mailing lists visible through the user interface by trying to create a new mailing list with the same name, then simply add yourself to the mailing list and be able to read your abuse@ email.
But Google broke that functionality in the latest version of the Google Apps control panel, when they renamed email lists to “groups”. If you try and create a new group with the email address abuse@ your domain you’ll get the error Email already exists in this domain, and no way to make that list visible.
So, what to do?
Well, there’s a workaround for now. If you go to Domain Settings you can select the “Current Version” of the control panel, rather than the “Next Generation” version. That gives you the old version of the control panel, where all this worked. Then you can go to User Accounts, create a new email list delivering to abuse@ and add one of your users to the mailing list. You can then set the control panel back to “Next Generation” and have access to the mailing lists via Service Settings → Email → Email Addresses.
Hopefully Google will fix this bug, but until they do here’s the step-by-step workaround:

Read More