Re: [exim] retry question

Góra strony
Delete this message
Reply to this message
Autor: cjackson
Data:  
Dla: Exim-users
Temat: Re: [exim] retry question
cjackson wrote:
> 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
>>
>> Is the hints database preventing the retry? Please let me know how you
>> send to att.net or how I can make this work.
>>
>
> I can't seem to get the retry to work. Here are the retry lines.
>
> att.net         rcpt_450         F,3m,3s; F,2h,5m; G,16h,1h,1.5; F,4d,6h
> bellsouth.net   rcpt_450         F,3m,3s; F,2h,5m; G,16h,1h,1.5; F,4d,6h
> *                      *           F,2h,5m; G,16h,1h,1.5; F,4d,6h

>
> Now if I run exim -brt, the last retry rule applies. The email is to
> bellsouth.net, so shouldn't the 2nd rule apply?
>
>


This list has gotten pretty quiet.

Anyway, I figured out a couple of things. Basically, I conclude that the
retry rules don't work the way I need them to. The messages are not
being resent. So I set up a script that greps the queue for Bellsout/ATT
mail then starts a special queue runner that resends the mail every 5s
then kills the queue runner process. It works. Mail is now being
accepted by those rogue systems. But is this really the best way to do
this with Exim? Surely there's a better way. Comments welcome.

Thanks.
Craig