On 01/13/2013 05:15 PM, RW wrote:
On Sun, 13 Jan 2013 13:24:14 +0000
Jeremy Morton wrote:
Hi,
I attach a proposed patch for the spamc client which I have tested -
it seems to be working well. It's based off the latest SVN I got
from: http://svn.apache.org/repos/asf/spamassassin/trunk
It adds the option -T to allow the spam threshold value to be
overridden, which changes when spamc will return 0/1 to indicate
spam, but does *not* change any of SpamAssassin's message rewriting.
The reason I think this change is a good idea is that I (and perhaps
others) find myself wanting to be able to define a "grey area" of
e-mails, where they are rewritten as spam but not completely
discarded. This can be done by setting the threshold override higher
than the normal SpamAssassin threshold.
For example, if you want the grey area to be between 3.0 and 8.0,
you'd set the normal SpamAssassin threshold to 3.0, then call spamc
with the threshold override of 8.0. Scores under 3.0 would be OK;
spamc returns 0 and the message is not rewritten. Scores between 3.0
and 8.0 would be "grey area" - spamc still returns 0 (so a shell
script will not discard it), but the message *is* rewritten. It will
be delivered to the user's mailbox as a rewritten message. Remaining
scores would cause the message to be rewritten *and* spamc would
return 1, allowing a shell script to discard it.
What do you think?
I don't like it. If spamassassin is to have support for two-level
classification it should IMO be in the library and set through normal
configuration.
Normally this is achieved by the glue as with Amavis, MailScanner, using
the API or Fuglu using spamd results
IMO, spamc should remain simple and lightweight.
Axb
