Do the scenarios you have identified cover all current usage of spamd? Specifically things like MTAs that integrate spam checking especially midstream and use these various exit levels?
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? Regards, KAM Martin Gregorie <mar...@gregorie.org> wrote: >On Fri, 2013-01-11 at 00:20 +0100, Tom Hendrikx wrote: > >> 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) >> >Yes, that sounds like something I'd do. > >> The recently added -X switch would also be too exotic for me, and be >> removed again. >> >I'd go with 1=SPAM, 0=HAM plus checks skipped all reasons (i.e. >--exitcode) for the default because it seems to work well in practice >for production running and --no-fail-fallback (renamed to something >like >--extended-exit-codes / -x for testing as opposed to production >operation). > >> Final result: simple, no >> unexpected kludges, common scenarios facilitated out of the box, all >> exotic scenarios available to the brave. >> >I think we're in agreement - see my last on the subject. As KAM says >there's a window for changing options and option names in preparation >for 3.4.0 I say have at it and good luck. > > >Cheers, >Martin
