On 1/10/2013 11:26 AM, 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.
Ignore breaking things because with a major version like 3.4.0, if this
is the "right" thing to do, it's completely feasible and best to do
right now with no delay.
Overall, what we almost need is "Usage scenarios" and appropriate
parameters. Then we can identify scenarios with missing parameters to
support.
Or perhaps spamc needs a configuration file to set any and all of the
possible exit levels which would alleviate the need for all these
switches perhaps?
Unfortunately, the current way spamc exits meets all of my needs so I'm
not sure of the scenarios otherwise needed.
regards,
KAM
