Johann Spies wrote:
> On Wed, Aug 04, 2004 at 10:14:17AM -0400, John Dalbec wrote:
>
>>Johann Spies wrote:
>>
>>
>>>One of our campuses experience a power failure for about 2½ hours. I
>>>would expect exim to keep the emails in the queue in accordance with
>>>these retry rules:
>>>
>>># If DNS lookups timeout, drop the mail after trying for a hour.
The "timeout" keyword seems to apply to connection timeouts also:
# timeout_connect_MX: connection timeout from a host obtained from an MX record
# timeout_connect_A: connection timeout from a host not obtained from an MX record
# timeout_connect: any connection timeout
# timeout_MX: any timeout from a host obtained from an MX record
# timeout_A: any timeout from a host not obtained from an MX record
# timeout: any timeout
There doesn't appear to be a keyword for DNS timeouts only. Since you're
getting connection timeouts (as shown below), this rule is being applied.
Maybe Phil can add that to the wishlist?
>>>
>>>* timeout F,1h,12m;
>
>
> No. The main campus, where the dns-servers are, was not affected.
>
>
>
> This clearly was a temporary error as shown in:
>
> $ sudo exinext ralf@???
> Transport:
> mail.belpark.sun.ac.za [146.232.96.209] error 110: Connection timed out
> first failed: 04-Aug-2004 12:38:40
> last tried: 04-Aug-2004 15:37:51
> next try at: 04-Aug-2004 15:49:51
> past final cutoff time
>
>
>> If it's still happening, try deleting the retry database.
>
>
> I did a
>
> exim_tidydb -t 10m /var/spool/exim4 retry
What about "rm /usr/local/exim/spool/db/retry*"?
John
> and
> exim_tidydb -t 10m /var/spool/exim4 wait-remote_smtp
>
> but that did not make any difference.
