On 10-01-13 17:26, Martin Gregorie wrote: > On Thu, 2013-01-10 at 15:59 +0100, Tom Hendrikx wrote: > >> Since EX_TOOBIG is not really a temporary condition, I'm not sure if >> that condition and the semantics of -X from the patch actually helps. >> >> I'm thinking that it might be better to have a switch with the semantics >> 'Change all temporary errors to EX_TEMPFAIL' which would change most of >> the named exit codes in the man page into EX_TEMPFAIL, except when the >> message should be simply passed through (effectively only EX_TOOBIG). >> >> This would do for integration as documented in the bug: >> - spamc without special switch: exitcode indicates succes (0) or failure (1) >> - spamc -<new>: exitcode indicates succes (0), failure (1) or retry (75) >> - spamc -x: always raw exitcode >> >> But I guess it depends largely on the setup and the sysadmins opinion >> whether 'addressee unknown' is a temporary condition, so there is >> another exception to be handled... >> > It seems to me that the set of replies as currently linked to spamc > options would do a near-prefect job with two minor tweaks: > > (1) remove the EX_TOOBIG kludge from --no-safe-fallback so it does > what it says on ythe tin > > (2) use the --exitcode behavior as the default in place of > --no-safe-fallback > > The manpage needs to say that --no-safe-fallback should be used during > testing and explain that, although it catches more errors, it should > not be used for production because it treats EX_TOOBIG as an error > rather than a warning. > > Personal opinion: the best approach would be to stick with > --no-safe-fallback after removing the EX_TOOBIG kludge and for the > calling script/code to make more detailed exit code checks. However, I > also realise this change would break a lot of installations, which is > why I'm suggesting making --exitcode the default in place of > --no-safe-fallback. >
Reviewing my previous suggestion, I mostly agree with the above, and meant this too (but with wrong words). I meant to provide the user with consistent behaviour for: 1) always exit with EX_OK, disregarding actual processing outcome or errors (current default behaviour) 2) indicate ham/spam difference with EX_OK/EX_FAILURE (current --exitcode behaviour) 3) all power (and responsibility) to the user (current --no-safe-fallback behaviour, but with kludges removed) In my original proposal: 4) indicate ham/spam/failure with EX_OK/EX_FAILURE/EX_TEMPFAIL, use case based on introduction of the -X switch, but generalised for all other tempfail-alike exit codes too (i.e. nearly all error conditions except EX_TOOBIG). The first 3 seem very common, the last one is a more exotic scenario. The question is: where is the line you draw between common and exotic, and do you introduce extra complexity for that? In fact all exotic scenarios could be implemented easily by wrapping 'spamc --no-safe-fallback' with a 4-line shell script that evaluates and manipulates the exitcode, but only if spamc would consistently expose all exit codes. Exit code manipulation for -c should ultimately be removed for simplicity: the user can easily combine it with -E (as documented in the man page), and exit code manipulation is then separated from presented output (i.e. you can easily make all of the above switches non-combinable, avoiding the crap from https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5412). The recently added -X switch would also be too exotic for me, and be removed again. I would also not implement a variant as described in 4) above, also discarding as too exotic. Final result: simple, no unexpected kludges, common scenarios facilitated out of the box, all exotic scenarios available to the brave. Kind regards, Tom
