We have been having the same issue with ATT.net.  Our DNS is fine,
including reverse lookup PTR and MX record.  We've checked it with DNS
Stuff and Men & Mice's DNS Expert utility.

Like previously reported, the 450 busy message is all that is received
and not every e-mail receives it.  Further, many times on a subsequent
Queue run, ATT.net finally accepts the mail.

Each of our customers have their own IP address.  We receive e-mail to
their domain and then forward it to their final destination POP at
ATT.net.

I'm wondering if ATT.net is doing some kind of rate limiting, i.e.
only allowing a certain number of connections during a given period of
time.



Wednesday, March 1, 2006, 11:02:57 AM, Daniel Donnelly <[EMAIL PROTECTED]> 
wrote:
DD> Only problem with Dave's conclusions is that the connection is
DD> NOT being rejected/dropped. The 4XX errors indicate the server
DD> does not have enough resources to handle a new message right now
DD> and is asking the sender to try later when it should be
DD> available. If ATT is not giving the right error response when
DD> dropping the connect, then they are just plain wrong! But they
DD> say the sender is not being blocked, which is consistent with the
DD> error number Keith is seeing.

DD> Why would one network get 95% failure and another does not? Good
DD> question! If the connection attempt is made very close to the
DD> same point in time and the responses are different, I have no
DD> explanation except there may be some preference given to the
DD> connection for one network over the other. Now this is not
DD> supposed to happen, but I seen a few proposals to do just this
DD> (paying more for premium network service). ATT is big enough to
DD> be experimenting with something like this...

DD> Maybe you can tell us here when you are seeing connection
DD> problems and we can try connecting from our networks. If we all
DD> try at some specific moment, we could cause a fair number of
DD> connections and push their server a bit. If we also get the
DD> error, well that confirms the problem is at their end, not yours!

DD> You might try the other hosts in att's MX records to see if they
DD> accept your email. You can force this by putting the IP &
DD> hostname (att.net) in the HOSTS file on the IMail server, and
DD> this will bypass the DNS lookups. If the other server accepts
DD> your messages at a higher rate, well, that seems to confirm the
DD> problem is the receiving mail server.

DD> Daniel Donnelly

DD> -----Original Message-----
DD> From: [EMAIL PROTECTED]
DD> [mailto:[EMAIL PROTECTED] Behalf Of Dave
DD> Doherty
DD> Sent: Wednesday, March 01, 2006 11:33 AM
DD> To: [email protected]
DD> Subject: Re: [IMail Forum] 450 busy, when delivering to att.net


DD> Hi, Keith-

DD> In my experience, most oddball problems with mail are DNS-related
DD> in some
DD> way.

>>  But I've specifically tried sending tests from domains that
DD> are NOT using
>> the gateway and these still get the '450 busy' response.

DD> How are you sending the telnet from the domains? Does each domain
DD> have its
DD> own mail server?

DD> One idea: See if you can get the gateway provider to try the
DD> telnet test
DD> directly on the gateway server. You may want to try using your
DD> inbound
DD> gateway also as an outbound gateway if you find that telnetting
DD> from the
DD> gateway works.

DD> Second idea: Do you have SPF records for the domains? Are they
DD> correct?

DD> One way this MIGHT work:
DD>  - You start the telnet session
DD>  - ATT checks reverse lookup on your mail server's IP
DD>  - ATT tries a forward lookup on the returned FQDN to see whether
DD> it matches
DD> the IP
DD>  - ATT checks for an MX record covering the domain and looks to
DD> see whether
DD> that returns the IP
DD>  - ATT checks for an SPF record to see whether the IP is
DD> authorized.

DD> ATT MIGHT reject the connection if one or more of the following
DD> are true:
DD>  - There is no reverse lookup for the IP
DD>  - There is a reverse lookup but the FQDN doesn't resolve to the
DD> IP
DD>  - There is no MX record for the domain
DD>  - There is an MX record, but it doesn't resolve to the IP
DD>  - There is no SPF record
DD>  - There is an SPF record, but the IP isn't authorized

DD> Just a few thoughts. There are certainly other explanations.

DD> -d



DD> ----- Original Message -----
DD> From: "imail" <[EMAIL PROTECTED]>
DD> To: <[email protected]>
DD> Sent: Wednesday, March 01, 2006 11:12 AM
DD> Subject: Re: [IMail Forum] 450 busy, when delivering to att.net


>> Dave and Matti, thanks for your ideas; they got me
DD> thinking/testing in
>> some new directions, but I'm still pretty stumped.
>>
>> Regarding the possibility of greylisting: "does the email
DD> deliver with the
>> next queue run?"  No.  Our mail server makes 5 attempts over
DD> the course of
>> several hours and usually all 5 attempts return the '450 busy'
DD> smtp
>> response.
>>
>> Regarding our MX records: we are using a third party spam
DD> filtering
>> gateway for inbound mail on some domains, but not all domains.
DD> I hadn't
>> thought of this being a potential problem before.  But I've
DD> specifically
>> tried sending tests from domains that are NOT using the gateway
DD> and these
>> still get the '450 busy' response.
>>
>> To add to the mystery, I've discovered that the connections
DD> aren't failing
>> 100% of the time.  The connections are failing roughly 95% of
DD> the time.
>> About one out of every twenty attempts are delivered fine.
DD> 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
DD> attempts
>> return '450 busy', while 5% connect fine.
>>
>> Telnet from my workstation (on a different IP address, but in
DD> the same
>> Class C IP range) results in 95% failure (450 busy).  Telnet
DD> from my home
>> computer (through a completely different ISP) results in 100%
DD> success.
>> Coupled with the tests Dave ran, I'm not sure what to make of
DD> these
>> results.  AT&T continues to assure us that our mail server IP
DD> is not being
>> blacklisted.
>>
>> -Keith
>>
>>
>>


DD> To Unsubscribe:
DD> http://www.ipswitch.com/support/mailing-lists.html
DD> List Archive:
DD> http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
DD> Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/

DD> To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html
DD> List Archive:
DD> http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
DD> Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/



----
Don Brown - Dallas, Texas USA     Internet Concepts, Inc.
[EMAIL PROTECTED]       http://www.inetconcepts.net
(972) 788-2364                    Fax: (972) 788-5049
----

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/

Reply via email to