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

On Thu, 15 Mar 2001, Alexey Promokhov wrote:

> On Sun, 11 Mar 2001, Dave C. wrote:
>
> > > > A message was written about one hour ago. I'm just connected to ISP and
> > > > tried to send it. But modem connection was unstable due to poor line
> > > > quality. And the message has been bounced. But why? This error is really
> > > > temporary, not permanent.
> > >
> > > You composed the message when offline and exim keeps trying to resend it,
> > > fails. It's just telling you that the mail is stuck in your queue four hours
> > > after you sent it.
> > >
> > > > I'm using the default retry configuration.
> > >
> > > You might want to increase the queue interval of exim
> > >
> >
> > And extend the retry time to be longer than you reasonable expect to
> > remain not connected for. (If you connect at least once a day, I would
> > set it to 2 day.)..
> >
> > Also, you might want to consider some sort of mechanism to force an exim
> > queue run (with -qff) when you do connect.
> 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.

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.

> 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
>
> It is seems like a SMTP timeout or other SMTP error. (Modem connection was
> very poor). But AFAIU that message should be deferred, not bounced...
>
>
>

--