Removing IP from AOL email Black List postmaster

I’m finding the AOL process really really annoying. We have been trying to clear up blacklist and reputation problems with a new IP range that was previously abused.

AOL have some tools that pretend to help. What you need to know is this.

1. Ensure your mail server IP has a RDNS – so when you do an NS lookup on the IP address it will show a name, like smtp.interactivewebs.com

2. Setup an email account like abuse@ or postmaster@  that domain. Make sure you get that mail.

3. Ensure that you verify with AOL that you are the admin for that RDNS lookup name. That is by submitting a ticket called Feedback Loop here: http://postmaster.aol.com/SupportRequest.FBL.php

4. Wait till they verify your Feedback Loop. AKA. that you are getting mail on that domain.

6. Use this link: http://www.mxtoolbox.com/SuperTool.aspx?action=mx%3aaol.com
to work out the IP of an AOL mail server.

7. Work out what code error is given when you try to connect from your mail server using Telnet. Follow these instructions. http://support.microsoft.com/kb/153119 but use the IP address and port 25 of the AOL mail server from step 6 above.

8. Look at the error result and compare it to this page: http://postmaster.aol.com/Postmaster.Errors.php

9. Follow the support request process from that page, to submit a ticket to have them fix things up.

Easy as that.!


Imagine if we had to do that crap for every email domain in the world. This was a recent blog from AOL about their update:

http://postmaster-blog.aol.com/2011/05/05/general-update/

We are in the process of automating email problem report resolution. This is a mid-term project, and is being implemented in stages on a queue-by-queue basis. (Ex: Each unique error code type represents a different queue, as do feedback loop and whitelist requests. http://postmaster.aol.com/Postmaster.Errors.php )
The last couple of months were spent migrating our sundry ticketing systems onto one common platform — essentially readying a back-end for the front-end logic flow that you will interface with. We are excited to finally be addressing the part of this project that will offer, in most cases, immediate resolution to your issues.
We are starting with router-level queues, the first of which will be RTR:BB errors. I will post on our progress as we push the code into production, along with what ticket submitters should expect with the automated process specific to the queue addressed. If you are seeing problems with the queues in transition, please comment on that particular blog post, and we’ll take a look.
Meanwhile, our Postmaster staff will continue handling every ticket we receive.
Thanks for your patience and support during this transition!

 


This was my comment.

1. Good that you are improving things. Sucks that your process is so stupid in the first place. An example of how frigging annoying I am finding things.
We at: http://www.interactivewebs.com have been forced by a chapter 11 of an upstream provider to move all our servers to a new IP range.
First thing we did was to setup RDNS and check mail reputation (on all the major Black Lists, and senderbase.org). What we found was that the IP range has been abused. So we set about cleaning that up.
Naturally we checked AOL, and found that the IP was "undisclosed" reputation. Helpful Right… NOT!
But it does not show AOL was listing it.
So we move and fire up services. THEN and only then do we find out that AOL does have the address on a BL and mail cannot be delivered.
How about tools that work, and a process that works to allow proper checking/de-listing.
The ironic part of dealing with your 1990 process, is that it really does not work as well as other systems. AOL users get more spam than many other reputable spam systems. There is even free spam software services that do better.
So why stick with such a lame process, when the end result is HEAPS of false positives?

Leave a Reply