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.
> >
> >* timeout F,1h,12m;
No. The main campus, where the dns-servers are, was not affected.
> If the campus had a power failure it probably affected the DNS servers too.
> After the first hour any new mail to the campus would be dropped.
> >
> ># Local machines are retried more regularly (i.e. 1 min).
> >
> >*.sun.ac.za * F,12h,1m; G,24h,10m,1.5; F,3d,3h
> >
> ># Everybody else starts with a 12 min retry interval.
> >* * F,2h,12m; G,16h,2h,1.5; F,2d,4h
> >~
> >
> >But this happens to email sent to be delivered there:
> >
> >2004-08-04 15:15:42 1BsLcM-0002Sx-7l <= jhspies@???
> >H=cpt-mail.adept.co.za [196.44.39.5] P=esmtp S=1177
> >id=20040804131538.5B0D0884066@???
> >2004-08-04 15:15:42 1BsLcM-0002Sx-7l ** ralf@???
> ><ralf@???>
> >R=relayrouter T=remote_smtp: retry time not reached for any host after
> >a long failure period
> >2004-08-04 15:15:42 1BsLcM-0002Sx-7l Completed
>
> Was this during the outage? If so, this looks normal.
Yes it was. Why is it normal? To quote the Exim book:
"When a permanent SMTP error code (5<xx>) is given at the start of a
connection or in response to an EHLO or HELO command, all the
addresses that are routed to the host are failed, and returned to the
sender in a bounce message
The other kinds of host error are treated as temporary, and they cause
all addresses to the host to be deferred. Retry data is created fot
eh host, and it is not tried again, for any message, until its retry
time arrives..." (page 270).
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
and
exim_tidydb -t 10m /var/spool/exim4 wait-remote_smtp
but that did not make any difference.
Should I try and set delay_after_cutoff to false? I do not clearly
understand the use of this function.
Regards
Johann
--
Johann Spies Telefoon: 021-808 4036
Informasietegnologie, Universiteit van Stellenbosch
"And not only so, but we glory in tribulations also;
knowing that tribulation worketh patience; And
patience, experience; and experience, hope."
Romans 5:3,4
