On Aug 10, 2010, at 6:25 AM, ste...@bajic.ch wrote:
>>
>> 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)?
Since dspam does not keep track of signature retrain are you
suggesting always untrain (look for signature?) when retraining?
This would always decrement spam_learned or inocent_learned or always
decrement spam_misclassified or inocent_misclassified if the signature
was found?
I guess to be more helpful I should start using the Web-UI. I don't
have apache2-suexec installed. Guess I'll get that going so I can be a
better dspam citizen.
// Brad
------------------------------------------------------------------------------
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
