exit codes in docs

[Matthias Andree]

On Mon, 04 Aug 2003, Greg Louis wrote:

> I could live fine with that.  It's the convenience of having an
> "unsure" exit code that I request be made available.  Convenience (not
> individual convenience, but user convenience) should, I'd have thought,
> be the design basis of most interfaces.
> 
> It's the lack of an "unsure" exit code that caused poor David to have
> to build a really convoluted generic version of my randomtrain script
> so generic bogofilter could run it.  Now we can make it simple and
> clean.

Well, I understand the problem but why change existing codes to add a
new one? That's the point I have troubles with.

> > Or the next one wants 0=error 1=spam 2=unsure 3=nonspam?
> 
> I wouldn't normally have a unix program exit with 0 for error, and I
> don't think it unreasonable to refuse to do that.

Well, just as an example. The "spam" and "unsure" codes aren't "error"
exits either, yet they are non-zero.

> As for the simple procmail rule, what I want in production is exactly:
> if bogofilter exits with 0, sequester the message as spam; else deliver
> it.  If bogofilter exits with an error or unsure, the safe thing is to
> deliver.  So:
> 
> :0HB:
> * ? /usr/bin/bogofilter
> /home/glouis/mail/bogo
> 
> does the trick nicely.

No, it doesn't, not at large at least. It lacks the :0e line to catch
I/O and disk full errors. Your mail may just as well end up in
/var/spool/mail/glouis. Ouch. See what I mean? We encourage a use of
procmail that can do anything it wants to, depending on weather and
things. The safe thing with "bogofilter error" is to defer rather than
deliver, at least for sites with high spam ratios (which you'll commonly
find for role accounts such as info@ or sales@).