On 1/14/2013 3:19 AM, Jeremy Morton wrote:
On 14/01/2013 00:39, John Hardin wrote:
On Sun, 13 Jan 2013, Jeremy Morton wrote:
On 13/01/2013 18:06, John Hardin wrote:
Agreed. Generally the caller looks for the "X-Spam-Status: Yes,
score=16.6 ..." header in the processed message to make the
deliver/discard decision. I think it's dangerously confusing to
redefine
"threshold" in this manner.
...
I haven't looked at how the various glues process the spamc output, if
they look for ==1 rather than >0 what I suggest might break lots of
stuff.
Whereas my patch wouldn't break any existing code. Why would it be
"dangerously confusing" to make this change when the default behaviour
is identical, and we could give a relatively simple and easy
explanation as to what it does?
Because you're redefining what "threshold" means from what it is in the
configuration files. Perhaps "dangerous" was overstating it a bit, but
it will make it less obvious to figure out when someone asks "this
message says it was spam but it's still being delivered!"
To get to this stage, someone would need to:
- Get the latest version of spamc
- Look in its documentation
- Add -T x.x to their commandline arguments
OK, I guess if someone is dumb enough to add a commandline argument
they haven't bothered to understand, it may cause a problem. But how
often is that going to happen? And we could just add "are you calling
spamc with the -T argument?" to the standard list of questions such
people need to be asked already. :-)
If the patch is thorough, well documented and fairly minor, I can't see
how it will slow down spamc very much. Is that the key concern really?
