Re: [exim] temp_errors and processes terminated by signal

On Mon, Mar 24, 2008 at 01:04:22PM -0700, Phil Pennock wrote:
> > It would be nice to have a way to have those deliveries deferred instead.
>
> Wrap it in a script or a small C program which masks the signals, uses
> setrlimit() to prevent core-files, logs the event to let you track it
> and try to find a root cause, etc.

That would be one way to do it I suppose.

> > It seems like it would be easy to make the 'temp_errors = *' flag apply in
> > this case. Is there any particular reason why this would not be a good idea?
>
> Speaking to the broad case: Yes.
>
> Exim gets blamed for enough problems with external programs invoked by
> Exim. Deliberately adding features to encourage people to ignore flaws
> is a bad idea. Programs dying on a signal should be investigated and
> fixed;

Certainly.

> the nightmare scenario is that you're actually looking at a
> buffer overflow or other exploitable issue and tying it into the MTA has
> just allowed your system to be remotely exploited.

Sure. Making Exim defer instead of bounce the message does little to change
that scenario though - if anything, it provides you with the offending
message still in the queue which simplifies the analysis of the problem,
which I would argue is a plus.

> If people want to (or have to) ignore severe flaws in software and still
> tie it into a system which accepts fairly arbitrary input from just
> about anywhere on the Internet, then on their heads be it and they
> should wrap it up themselves. That step alone will help limit it to
> people with enough technical ability that they can assess whether or not
> there is actually an exploitable issue.
>
> What's your use-case that makes a signal exit something you can't fix in
> the external software and which you want to work around by making it a
> deferring error?

I had a somewhat braindead init script for dspam that was invoked by
logrotate, and which essentially did a 'killall -9 dspam', killing any
running dspam processes started from an exim pipe transport.

That script was silly of course - and I fixed it.

Sadly, this caused legitimate mail to be bounced.

It seems to me that the safer approach would be to configure exim in such a
way that it would not bounce, but just defer, if a child process of a pipe
gets killed with a signal. It should be logged too so that this stuff does
not go unnoticed.

Thanks,
Ward.

--
Ward Vandewege <ward@???>
Free Software Foundation - Senior System Administrator