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 <[EMAIL PROTECTED]> Free Software Foundation - Senior System Administrator -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
