We are still seeing this issue (01-29-2014) with Time Warner. More specifically with roadrunner.com and maine.rr.com recipient addresses.
|2014-01-29 13:17:52 EST||Recipient Disposition: [250 Queue (RCPT Domain roadrunner.com, Message Domain *****.org); Mode: ; Queued: yes; Frontend TLS: yes]|
|2014-01-29 13:18:02 EST||Detail: first attempt failure: 451 all mx servers are unavailable for domain roadrunner.com|
I obfuscated our domain but can provide if neccesary.
I have already tried working with Time Warner AND our provider Excal Micro.
Many of our Members are on TW email and this is having a real impact on our business.
We have been seeing these temporary failures for a while with RoadRunner. The issue is that RoadRunner/Time Warner intermittently throttles connections from large email providers including McAfee. All that McAfee can do is temp-fail the message and retry for up to 5 days or until RoadRunner accepts the message. Customers of Time Warner may need to contact the provider regarding their throttling practices, however McAfee is unable to force RoadRunner to change their policies as an unaffiliated third party, nor can we force their servers to accept the messages. At this point, the only choice we have is to queue and re-attempt messages that fail due to throttling.
Please let me know if you have any questions.
Interesting and aggrevating.
Their intial response to me was a DNS issue:
When we checked the domain name (*****.org) on http://www.site24x7.com/dns-lookup.html
it shows that the zone file is not setup properly in theprimary Name Server host. It may also be due to any of the following reasons:-1.The Name Server domain is actually not running at all. Start your Name Serverdomain before running this test again.
2.The Name Server domain is not reachable from theInternet because there is a firewall or filtering router that is blockingconnections to port 53 on this host for both UDP and TCP connections. Thefirewall configuration must permit connections on this port from any host onthe Internet for the DNS to function properly.
It could also be due to an anti spam technic calledgrey-listing, or have black listed you and are not accepting your connection.
First of all we would advise you to check with Mcafeeregarding the DNS.
We use GoDaddy for DNS so up even upgraded to their Premium DNS offering vs the free to see if that made any difference. It has not.
It would not, DNS changes or upgrading to a more robust DNS Package through GoDaddy would not resolve these types of issues. We have feedback loops in place with Time Warner to alert us if spam messages reach their system, and at this time those alerts have been quiet, indicating that the throttling/greylisting is due to volume and not any actual threat identified.
Yes, in the same sense that every drop of rain impacts the volume of the river. But unless you send an enormous, six-plus-figure volume of mail daily to RoadRunner addresses, it would be quite unlikely that your volume plays a significant role.
Thank you for confirming that.
Is there any way to check the disposition of the email after the initial 'all mx servers are unavailable' message? It seems like whe doing the message audit it shows when the initial connection was attempted but nothing more once the emai lis delivered. Is that corect? If so, is there a way to see when it was delivered?
You will see an additional disposition once the message is delivered, something to the effect of delivered from queue, but it won't show until we can successfully hand the message off (plus about 5-10 minutes processing time as the logs are updated). In some cases a message isn't delivered for an hour or more.
So it does:
2014-01-30 13:46:46 EST
|Recipient Disposition: [250 Queue (All MX servers are unavailable for domain maine.rr.com); Mode: normal; Queued: yes; Frontend TLS: yes]|
|2014-01-30 13:46:53 EST||Detail: first attempt failure: 451 all mx servers are unavailable for domain maine.rr.com|
|2014-01-30 13:55:29 EST||Detail: local delivery from dir[process], [maine.rr.com:/mxl/var/sockets/mta_outbound]: 250 backend replied [120aae25.2af7dd401940.106834.00-537.270806.p02c12o144.mxlogic.net]: 2.0.0 ok ea/76-10399-120aae25|
Is there nothing we can do to impact their policy?
Unfortunately, no. Server administrators are free to enforce any policies they choose to including rate limiting. Much like some administrators use old-school anti-spam tactics of requiring their server to wait 10-20 seconds before issuing a 220 banner, even though that tactic does not work well any longer and tends to cause havoc with legitimate senders, no one on the outside can force the administrator to change this practice. Customers of RoadRunner have the most leverage though, and can usually get further with RoadRunner support in voicing their opposition to arbitrary rate limits.