New Year's Resolution and new beta release

[David Lee]

On Fri, 5 Jan 2007, Julian Field wrote:

> David Lee wrote:
> > [...]
> > Could you check, please, the report from November:
> >    http://lists.mailscanner.info/pipermail/mailscanner/2006-November/067706.html
> >
> > which is part of thread:
> >    http://lists.mailscanner.info/pipermail/mailscanner/2006-November/067415.html
> >
> > This is (presumably) rare for others, but it has been, and still is, real
> > for us. That is, it falls into the "occurs in real experience" category.
> > (I'm surviving by using a suboptimal fudge around the problem.)
> >
> >
> > Brief summary: "MailScanner/SA.pm" does a fork()/exec() to SpamAssassin.
> > If, for some reason, that SA crashes then the parent (MS) process seems
> > not to detect this, and treats it as a good, 'ham' result.  (I give
> > possible suggestions in that November email.)
> >
> And therefore it is failing 'safe'. Why wouldn't you want it to fail
> safe? Failure resulting in message delivery sounds a whole lot better
> than failure resulting in message disposal.

That's envisioning it just as a two-state success/fail.  The summary from
the end of the 17/11/06 email was:

-----------------------------------------------
MS BUG: If MS's call to SA fails (e.g. crash/segfault), MS is unable to
distinguish this from a successful return.

RESOLUTION: The code immediately following the "eval {}" ought to check
the return (e.g "$PipeReturn") to detect SA/child failures.  Such failures
may reasonably be expected to be rare, but should nevertheless be handled,
perhaps by leaving the email where it is, and doing a high-priority (e.g.
"error") syslog message.

NOTE: Might the SA/child itself need an enclosing "eval {}"?
-----------------------------------------------

That is, at the least giving a syslog message, and if possible allowing
processing to be deferred (which, OK, would leave to a buildup in the
inbound queue).  Or, in that "state" model, a (hopefully!) rare third
state of "deferred" with an associated "ring syslog alarm bells".

Does that seem OK?

-- 

:  David Lee                                I.T. Service          :
:  Senior Systems Programmer                Computer Centre       :
:                                           Durham University     :
:  http://www.dur.ac.uk/t.d.lee/            South Road            :
:                                           Durham DH1 3LE        :
:  Phone: +44 191 334 2752                  U.K.                  :