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.
--
Alexey Promokhov <alexpro@???>, 2:5020/1513@FidoNet
