For an even blunter approach, you might want to modify your ip-up script
to do:
rm -f EXIM_SPOOL_DIRECTORY/retry/*
exim -qff
On Wed, 14 Mar 2001, Dave C. wrote:
>
>
> At first look this seemed very unusual. But then I remembered that the
> retry rules are per *host*, not per message.
>
> I would check the following:
>
> 1. The time/date of the last message that was *succesfully* delivered to
> any of the hosts listed as MX records for mail.ru
>
> 2. The next delivery *attempt* (after the last successful delivery) to
> those hosts, and the amount of time elapsed between then and the
> date/time of the 'retry time exceeded' log entry you included below.
> You'll probably find it quite close to your 4 day maximum retry time.
>
> Then go and set 'delay_after_cutoff = false' in your smtp transport(s)
> (and HUP your exim daemon of course)
>
> You also might want to change the first retry interval to something
> shorter (eg 5m)
>
> On Thu, 15 Mar 2001, Alexey Promokhov wrote:
>
> > On Wed, 14 Mar 2001, Dave C. wrote:
> >
> > > > Maybe I'm described my problem not so clean... I'm connecting to ISP very
> > > > often, and retry time is long enough. Moreover, exim -qff is executed after
> > > > connection from /etc/ppp/ip-up.
> > > >
> > > > Problem is that my telephone station was built more then 30 years ago, it
> > > > have very old equipment, and it is basically not designed for modem
> > > > connections. So, connection quality is very low, and modem going to retrain
> > > > very often.
> > > >
> > > > Message was in queue about 1 hour when I called my ISP, and it cannot be
> > > > bounced because it was in queue during long time. I'm connected to ISP, and
> > > > exim -qqf was executed. Here is a log:
> > > >
> > > > 2001-03-11 11:04:33 2 args: exim -qqf
> > > > 2001-03-11 11:04:33 Start queue run: pid=232 -qqf
> > > > 2001-03-11 11:04:54 14c2TI-0000Jw-00 ** iv_comp@???: retry timeout exceeded
> > >
> > > 'retry timeout exceeded' means that message was on your queue longer
> > > than your maximum retry time, NOT an SMTP timeout.. Now its possible
> > > that your exim has been trying for that long to deliver the message, and
> > > has been getting an SMTP timeout or other such error each time it tried,
> > > and now that the retry time has been exceeded, it is giving up and
> > > returning the message as undeliverable.
> > >
> > > Take a close look at your retry rules to determine the maximum allowed
> > > retry time. Depending on how complex these are, then what domain or user
> > > the message was addressed to, the specific types of errors, and or the
> > > DNS setup (wether it was an MX or A record) may affect while rule
> > > applies. Hopefully you have a fairly simple retry ruleset.
> >
> > There is only one line:
> >
> > * * F,2h,15m; G,16h,1h,1.5; F,4d,8h
> >
> >
> > >
> > > Then do:
> > >
> > > cat (exim mainlog filename) | grep 14c2TI-0000Jw-00
> > >
> > > Be sure to use that spool ID, and not 14c3eg-00003p-00 (which is the
> > > spool ID of the nondelivery notice)
> > >
> > > and you should see the initial reception of this message (and date/time
> > > thereof), and each delivery attemptalong with its result. This is
> > > assuming that you havent purged or rotated your mainlog since the
> > > reception of the message.
> >
> > Here it is:
> >
> > 2001-03-11 09:49:04 14c2TI-0000Jw-00 "alexpro@???" rewritten as "alexpro@???" by rule 2
> > 2001-03-11 09:49:04 14c2TI-0000Jw-00 "alexpro@???" rewritten as "alexpro@???" by rule 2
> > 2001-03-11 09:49:04 14c2TI-0000Jw-00 <= alexpro@??? H=localhost [127.0.0.1] U=alexpro P=esmtp S=1589 id=Pine.LNX.4.32.0103111248080.967-100000@??? T="=?KOI8-R?Q?Re=3A_Fw=3A_=F4=C1=CE=D4=D2=C1?=" from <alexpro@???> for iv_comp@???
> > 2001-03-11 09:49:14 14c2TI-0000Jw-00 == iv_comp@??? R=lookuphost defer (-1): host lookup did not complete
> > 2001-03-11 09:59:26 14c2TI-0000Jw-00 == iv_comp@??? routing defer (-42): retry time not reached
> > 2001-03-11 09:59:26 14c2TI-0000Jw-00 == iv_comp@??? routing defer (-42): retry time not reached
> > 2001-03-11 10:16:34 14c2TI-0000Jw-00 == iv_comp@??? R=lookuphost defer (-1): host lookup did not complete
> > 2001-03-11 10:16:34 14c2TI-0000Jw-00 == iv_comp@??? routing defer (-42): retry time not reached
> > 2001-03-11 10:30:38 14c2TI-0000Jw-00 == iv_comp@??? routing defer (-42): retry time not reached
> > 2001-03-11 10:30:38 14c2TI-0000Jw-00 == iv_comp@??? routing defer (-42): retry time not reached
> > 2001-03-11 10:45:57 14c2TI-0000Jw-00 == iv_comp@??? R=lookuphost defer (-1): host lookup did not complete
> > 2001-03-11 10:45:57 14c2TI-0000Jw-00 == iv_comp@??? routing defer (-42): retry time not reached
> > 2001-03-11 11:00:37 14c2TI-0000Jw-00 == iv_comp@??? routing defer (-42): retry time not reached
> > 2001-03-11 11:00:37 14c2TI-0000Jw-00 == iv_comp@??? routing defer (-42): retry time not reached
> > 2001-03-11 11:04:54 14c2TI-0000Jw-00 ** iv_comp@???: retry timeout exceeded
> > 2001-03-11 11:04:54 7 args: /usr/local/bin/exim -t -oem -oi -f <> -E14c2TI-0000Jw-00
> > 2001-03-11 11:04:54 14c3eg-00003p-00 <= <> R=14c2TI-0000Jw-00 U=root P=local S=2408 T="Mail delivery failed: returning message to sender" from <> for alexpro@???
> > 2001-03-11 11:04:54 14c2TI-0000Jw-00 Error message sent to alexpro@???
> > 2001-03-11 11:04:54 14c2TI-0000Jw-00 Completed
> >
> > All defers are occured because my system was not online. As you can see, the
> > time intervel between putting message in queue and final failure is great
> > less than retry timeout... Note: I was connected to ISP about 11:03.
> >
> >
>
>
--
