On 1/11/2013 7:52 AM, Martin Gregorie wrote:
On Thu, 2013-01-10 at 19:49 -0500, Kevin A. McGrail wrote:
Do the scenarios you have identified cover all current usage of spamd?
The only use scenario I mentioned is entirely my own: I make no claims
that anybody else uses spamc in the same way.
I understand that but realize that this makes taking any overarching
input from you fairly difficult to accept.
Specifically things like MTAs that integrate spam checking especially
midstream and use these various exit levels?
Now for my suggested option changes: these were written on the
assumption that, with the exception of the EX-TOOBIG kludge when -x is
in force and which is now known to be undocumented,
I've addded to the docs that * The EX_TOOBIG error level is never used.
If spamc receives a message that is
too big, the exit code will be 0.
the spamc manpage is
a true description of the effect of the various options. I haven't
attempted to compare the current code with the current manpage. If there
are discrepancies, then the code and manpage should be synchronised
before 3.4.0 is released.
I'm not aware of any problems but happy to fix them if you note any
other issues.
Another deficiency is that the manpage doesn't say whether -E or -x is
the default though it is implied by the -x option description.
It uses neither: By default, spamc will use the 'safe fallback' error
recovery method.
See the first section under EXIT CODES.
If we add flexibility that covers more scenarios, great but to me this
looks like you are talking about removing options that i can only
assume are used. Am i wrong?
With all due respect, yes. I'm suggesting that the default set of exit
codes for all processing options should be what -E --exitcode currently
defines and that -x (possibly renamed) overrides that just as it does at
present. Taking this view makes the -E --exitcode option redundant and,
indeed, confusing so its would be better to document this as the default
set of exit codes and remove the -E --exitcode option. This does not
constrain spamc flexibility or remove any current functionality.
These options were added through real-world usage scenarios. Removing
them is not something I can support without more study that we aren't
breaking things for people.
Regards,
KAM
