Exim Weirdness

[Jason Cormie]

Just mailing to say that since I setup and ran the tidydb their have been no
more errors :)

-----Original Message-----
From: Nick Phillips [mailto:nwp at LEMON-COMPUTING.COM]
Sent: 07, January, 2003 10:53
To: MAILSCANNER at JISCMAIL.AC.UK
Subject: Re: Exim Weirdness


On Tue, Jan 07, 2003 at 08:46:51AM -0000, Jason Cormie wrote:
> Thanks Nick,
>         Somehow I lost that section of my own docs between pilot 1, pilot
2
> and
> production :-(
>
> Will implement and see what happens.
> Just out of curiosity, what exactly does it do and what would have
happened
> without it?

The problem is that Exim really isn't designed to not deliver anything.
It's difficult to make the "incoming" Exim make no delivery attempts on
any messages ever (pretty much impossible, in fact), and when it does make
an attempt, it's difficult to get it to do nothing in a harmless way.

The solution I've been recommending chooses to try to prevent delivery
attempts
by setting queue_only and not running cron jobs/queue runners with that
configuration anyway. This should prevent delivery attempts being made for
messages received by SMTP (as the queue_only setting should cause them to
be just dumped into the queue), but some locally generated messages will
still cause delivery attempts to be made (e.g. cron using the "-odi" option
when it invokes what it thinks is sendmail).

When delivery attempts are made for these (locally generated) messages, the
director described in the docs should cause the messages to be deferred.
The problem with this is that Exim counts a deferral as a failure as far
as the retry database for the destination host is concerned. If one delivery
attempt is made, then that causes an entry to be made in the retry database.
This would be cleared if a successful delivery was ever made (but since we
don't want any deliveries to be made, that won't happen). So, at that point
the clock starts ticking. After your maximum configured retry time has
passed,
Exim may bounce new messages for that host without even making a delivery
attempt (this depends a little on configuration).

So, to sort it out, we just clear the retry database well within the maximum
retry timeout. The maximum timeout is then never reached and Exim never gets
to do its extra clever special efficient tricks.

I'm a little worried to see so many addresses listed in your original mail
(I wouldn't usually expect that many deliveries to be attempted), so would
like to know what turns out to be the reason.


Cheers,


Nick

--
Nick Phillips -- nwp at lemon-computing.com
If you sow your wild oats, hope for a crop failure.