On Thu, 2 Sep 2004, Dean Brooks wrote:
> on queue longer than maximum retry for address - allowing delivery
> 64.253.97.107 [64.253.97.107] status = usable
>
> So it appears the maximum retry issue is in play. However, from the docs,
> it would seem that it would bounce the message on the timeout.
>
> But, I get this in the debug log after it times out:
>
> == admin@??? R=mwdirect T=remote_smtp defer (145):
> Connection timed out: SMTP timeout while connected to 64.253.97.107
> [64.253.97.107] after end of data (3341 bytes written)
> locking /var/spool/exim/mailworks/db/retry.lockfile
> locked /var/spool/exim/mailworks/db/retry.lockfile
> opened hints database /var/spool/exim/mailworks/db/retry: flags=2
> address match: subject=*@64.253.97.107 pattern=*
> 64.253.97.107 in "*"? yes (matched "*")
> *@64.253.97.107 in "*"? yes (matched "*")
> retry for T:64.253.97.107:64.253.97.107:1Bxu0L-000737-K6 (eosystems.net) = *
> dbfn_read: key=T:64.253.97.107:64.253.97.107:1Bxu0L-000737-K6
> Writing retry data for T:64.253.97.107:64.253.97.107:1Bxu0L-000737-K6
> first failed=1092949765 last try=1094139700 next try=1094154100 expired=0
> error 145 65: Connection timed out
> dbfn_write: key=T:64.253.97.107:64.253.97.107:1Bxu0L-000737-K6
> end of retry processing
The retry data indicates that 64.253.97.107 itself has not timed out
(expired = 0). Looks like there might be some obscure interaction of the
various heuristics going on here. I will have to find time to wrap a wet
towel round my head and study this data more carefully. I'm afraid it
won't be for a few days at the earliest.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
Get the Exim 4 book: http://www.uit.co.uk/exim-book
