Only problem with Dave's conclusions is that the connection is NOT being rejected/dropped. The 4XX errors indicate the server does not have enough resources to handle a new message right now and is asking the sender to try later when it should be available. If ATT is not giving the right error response when dropping the connect, then they are just plain wrong! But they say the sender is not being blocked, which is consistent with the error number Keith is seeing.
Why would one network get 95% failure and another does not? Good question! If the connection attempt is made very close to the same point in time and the responses are different, I have no explanation except there may be some preference given to the connection for one network over the other. Now this is not supposed to happen, but I seen a few proposals to do just this (paying more for premium network service). ATT is big enough to be experimenting with something like this... Maybe you can tell us here when you are seeing connection problems and we can try connecting from our networks. If we all try at some specific moment, we could cause a fair number of connections and push their server a bit. If we also get the error, well that confirms the problem is at their end, not yours! You might try the other hosts in att's MX records to see if they accept your email. You can force this by putting the IP & hostname (att.net) in the HOSTS file on the IMail server, and this will bypass the DNS lookups. If the other server accepts your messages at a higher rate, well, that seems to confirm the problem is the receiving mail server. Daniel Donnelly -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dave Doherty Sent: Wednesday, March 01, 2006 11:33 AM To: [email protected] Subject: Re: [IMail Forum] 450 busy, when delivering to att.net Hi, Keith- In my experience, most oddball problems with mail are DNS-related in some way. > But I've specifically tried sending tests from domains that are NOT using > the gateway and these still get the '450 busy' response. How are you sending the telnet from the domains? Does each domain have its own mail server? One idea: See if you can get the gateway provider to try the telnet test directly on the gateway server. You may want to try using your inbound gateway also as an outbound gateway if you find that telnetting from the gateway works. Second idea: Do you have SPF records for the domains? Are they correct? One way this MIGHT work: - You start the telnet session - ATT checks reverse lookup on your mail server's IP - ATT tries a forward lookup on the returned FQDN to see whether it matches the IP - ATT checks for an MX record covering the domain and looks to see whether that returns the IP - ATT checks for an SPF record to see whether the IP is authorized. ATT MIGHT reject the connection if one or more of the following are true: - There is no reverse lookup for the IP - There is a reverse lookup but the FQDN doesn't resolve to the IP - There is no MX record for the domain - There is an MX record, but it doesn't resolve to the IP - There is no SPF record - There is an SPF record, but the IP isn't authorized Just a few thoughts. There are certainly other explanations. -d ----- Original Message ----- From: "imail" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Wednesday, March 01, 2006 11:12 AM Subject: Re: [IMail Forum] 450 busy, when delivering to att.net > Dave and Matti, thanks for your ideas; they got me thinking/testing in > some new directions, but I'm still pretty stumped. > > Regarding the possibility of greylisting: "does the email deliver with the > next queue run?" No. Our mail server makes 5 attempts over the course of > several hours and usually all 5 attempts return the '450 busy' smtp > response. > > Regarding our MX records: we are using a third party spam filtering > gateway for inbound mail on some domains, but not all domains. I hadn't > thought of this being a potential problem before. But I've specifically > tried sending tests from domains that are NOT using the gateway and these > still get the '450 busy' response. > > To add to the mystery, I've discovered that the connections aren't failing > 100% of the time. The connections are failing roughly 95% of the time. > About one out of every twenty attempts are delivered fine. When I try to > telnet to att.net's smtp servers from our mail server > (mail.addisontech.com), I get the exact same result: 95% of the attempts > return '450 busy', while 5% connect fine. > > Telnet from my workstation (on a different IP address, but in the same > Class C IP range) results in 95% failure (450 busy). Telnet from my home > computer (through a completely different ISP) results in 100% success. > Coupled with the tests Dave ran, I'm not sure what to make of these > results. AT&T continues to assure us that our mail server IP is not being > blacklisted. > > -Keith > > > To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/ To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
