Re: [exim] retry question

--On 13 August 2007 10:13:39 -0500 cjackson <cjackson@???>
wrote:

> Ian Eiloart wrote:
>>
>>
>> --On 10 August 2007 11:07:17 -0500 cjackson <cjackson@???>
>> wrote:
>>
>>> Hi,
>>>
>>> I am having a very difficult time sending email to att.net with the
>>> default Exim 4.62 configuration. Att.net gives me 450 Busy Retry error
>>> on almost all email I send to them right after the connection attempt. I
>>> notice that if I manually resend using exim -M <emailid> many times,
>>> like once every second for 30 seconds, the email usually goes. What
>>> configuration should I try in the configure file to make this happen? I
>>> tried this but it doesn't work.
>>>
>>> att.net rcpt_450 F,1m,1s
>>
>> If they're busy, then it's not a good time to be hammering away at their
>> server like this - you'll just make the situation worse. Have patience,
>> and apply your usual retry rules.
>>
>>
> Ordinarily, I'd agree with you. But their servers are _always_ too busy.
> So that won't work. Exim gives up and won't retry ever -- so 450 becomes
> essentially an immediate permanent error.
>
> I have been speaking with a qualified person at Bellsouth who has
> informed me that certain IP blocks that ATT has identified as sources of
> spam are "throttled". The blocks of course are DSL/DHCP addresses, plus
> others lumped in there because it makes their lives easier at ATT.
> Unfortunately, I'm in one of the other blocks that is static, so I get
> the 450 treatment. I have no choice but to resend. It's sort like a
> greylist, I guess.

I see. I imagine that it's the number of retries that counts, not the rate
of retries.

However, throttling could mean lots of things. It could mean that they're
limiting the rate of sending for all such hosts, in which case hammering
away won't do you any good. Or, it could mean that they limit the number of
concurrent connections, in which case hammering away may be your only
choice.

You need to find out what they mean by "throttling".

>
>>>
>>> Is the hints database preventing the retry? Please let me know how you
>>> send to att.net or how I can make this work.
>>>
>>> Thanks.
>>> Craig
>>
>>



--
Ian Eiloart
IT Services, University of Sussex
x3148