>
> On Aug 9, 2010, at 11:08 PM, Stevan BajiÄ wrote:
>
>> On Mon, 9 Aug 2010 22:49:35 -0700
>> Bradley Giesbrecht <bradley.giesbre...@gmail.com> wrote:
>>
>>>
>>> On Aug 9, 2010, at 10:37 PM, Stevan BajiÄ wrote:
>>>
>>>> On Mon, 9 Aug 2010 18:46:50 -0700
>>>> Bradley Giesbrecht <bradley.giesbre...@gmail.com> wrote:
>>>>
>>>> [...]
>>>>>> How do you undo a training when not using the Web-UI?
>>>>>
>>>>> I don't know. Send the same message to s...@domain.com and then
>>>>> h...@domain.com
>>>>> ?
>>>>>
>>>> But that must somehow trigger a command.
>>>> s...@domain.com/h...@domain.com
>>>> are not standard DSPAM aliases. You must have added something to
>>>> your MTA in order to trigger a training. What have you added?
>>>
>>>
>>> Your script.
>>>
>>> master.cf
>>> dspam-retrain unix - n n - - pipe
>>> flags=Rhq user=_vmail:_vmail argv=/opt/local/sbin/dspam-retrain-
>>> forward.pl
>>> --mode=toe
>>> --class=${nexthop}
>>> --source=error
>>> --user ${sender}
>>> --client
>>>
>> Okay. That is calling DSPAM binary. And that script above has no
>> knowledge if you undo a training or not. All it knows is that you
>> want to classify a message either as SPAM or as INNOCENT and that
>> the source is error.
>>
>> To get the other requested function to be able to undo a training
>> and then have the stats modified the correct way, one would need to
>> extend DSPAM to keep track of the state of a signature. This would
>> require some additional code that is currently not available in
>> DSPAM. I really ask myself how many times such a code would be
>> really needed? Probably not much. And the small issue that the stats
>> is off by one when doing such an undo is in the long run a small
>> problem that IMHO can be ignored. It is for sure not common that
>> people get a message classified as X and then tell DSPAM that it was
>> an error and it should be classified as Y and then after have done
>> that reclassifcation go again and say: ooohhh. No! It should have
>> been class X! Reclassify again but don't reclassify but do a undo,
>> etc...
>
> I agree and I do not care about the stats being off on double retrain.
>
> My only point was that IF someone wanted to change dspam retrain
> behavior the Web-UI was probably not the place to do it.
>
I too think that the Web-UI is not the ideal place to keep track of that
kind of things.
>> There is already the mode UNTRAIN that could be extended to do that
>> correct stats handling but without keeping the state of the
>> signature (aka: without checking if the signature was really learned
>> as the correct class).
>
> Sounds like that could work.
>
I need to find a good logic where to put that into when doing a untrain. I
guess that untrain in combination with source=error could be considered as
a undo (class being either spam or innocent)?
>
> Regards,
> Bradley Giesbrecht
------------------------------------------------------------------------------
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
Dspam-user mailing list
Dspam-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspam-user
