On 5 Jan 2000, Vladimir Litovka wrote:
> There is strange situation, as for me. I send mail to some domain, which
> is unreachable now. Exim passes final cutoff time and drops this message
> with notification: "retry timeout exceeded". But I don't see this domain
> in retry database (result of 'exim_dumpdb /var/spool/exim retry' doesn't
> contain this entry). After restart of Exim there still isn't this domain,
> however Exim finds information about retry times, because immediately
> drops messages for this domain. Where this information is stored really?
The only store of such information is the retry database. However, it
may not be the mail domain which is failing, but the hosts to which it
is MX'd. Have you tried running
exinext user@domain
? That will inspect the retry database both for the domain (for routing
failures) and for the hosts it routes to (for delivery failures).
> How long Exim keeps entries in retry db after final cutoff time passed for
> particular domain? In the result of 'exim_dumpdb ... retry' I see very old
> entries - so Exim doesn't clear retry db at all, do it?
No, it never clears them. You are supposed to run exim_tidydb every now
and again. However, from release 3.10 it won't use any data that is
older than retry_data_expire.
> And last - there are two methods of implementing ETRN: set big cutoff time
> and use 'exim -R domain.com' or store messages in external spool and use
> external transport to deliver mail to recipients when ETRN received. I
> prefer first method, because it is more lightweight, but there is one
> trouble - when final cutoff time passed, Exim bounces messages for these
> clients after first unsuccessfull delivery. This depends on
> delay_after_cutoff variable, but doesn't solve the problem. Is it possible
> to clear retry db not only on first successfull deliver (i.e. at message
> arriving time client must be on-line), but on receiving ETRN directive
> too? It is useful feature - client signals to Exim "I'm still living!" and
> Exim will reset retry db for domain, used as argument to ETRN command.
> What do you think about this proposition?
You could cause ETRN to run a script that calls exim_fixdb to remove the
entry, I suppose.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
