Re: [exim] temp_errors and processes terminated by signal

On 2008-03-24 at 10:39 -0400, Ward Vandewege wrote:
> Reading through src/transports/pipe.c I see that child processes terminated
> by a signal always fail delivery in pipe transports.

Correct.

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

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

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?

-Phil