https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6890
--- Comment #8 from Jez <[email protected]> --- (In reply to comment #7) > First of all, spamc is meant to be a light-weight client, merely feeding > messages to the daemon, and dealing with the result in an absolute minimal > way. spamc deliberately does not decide about the score, nor rewrite the > message or even add headers. That is entirely left to spamd. I fail to see the problem. spamc can optionally care about the score - it's a very convenient place to do it because it already has the score stored in a struct in memory. Serializing it to text and then deserializing again is horribly inefficient. > Thus, if a feature like this would be implemented, I am strongly in favor of > dealing with it in spamd. By definition this can't be dealt with in spamd, because it is supposed to offer a lightweight way of defining a "grey area" for the spam score. > Moreover, this basically duplicates existing functionality No it doesn't, or I wouldn't have had to add it. Existing functionality is slow, slow, slow. This is so much quicker that I'd say it counts as new functionality. > , and introduces > the notion of "discard" -- something SA does not do. SA scores, but it does > not deliver, nor discard. It doesn't really introduce the notion of discard, I just suggested that one interpretation a shell script might have for a return value of 1 is to discard the message - which is what often happens already - but of course the script can do what it wants. > The environment described in comment 0 is almost identical to adding the > X-Spam-Level header, which is not by coincidence meant to easily allow for > this shades of gray differentiation. The only difference between this > existing behavior and the request is, what the spamc calling tool acts upon > -- the $is_spam return value, instead of grepping for a single line. Quite, and when that tool is a shell script, it has very little to work with. grepping for a score that has been serialized, deserializing it again, and re-converting it to an integer is horrible to do in bash and, apart from anything else, inefficient as hell. There's a good reason I didn't want to go down that route. > Changing, overriding the decision (exitcode) whether a message is deemed > spam or not in this way seems pretty confusing, too. A message's score > exceeding the required_score threshold is classified spam. The return value > of spamc should not claim anything else. If if changed the existing behaviour, I'd agree it could be confusing, but it doesn't. By default, nothing changes with this patch. You have to add the extra commandline argument. Who is going to do that without reading the documentation? If they randomly add this commandline arg and get confused by it, then I'd say it's their fault. -- You are receiving this mail because: You are the assignee for the bug.
