Re: [Exim] Mail delivery failed: returning message to sender…

Top Page
Delete this message
Reply to this message
Author: Dave C.
Date:  
To: alexpro
CC: exim-users
Subject: Re: [Exim] Mail delivery failed: returning message to sender (fwd)

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.
>
>


--