On Tue, 10 Aug 2010 08:50:25 -0700, Bradley Giesbrecht
<bradley.giesbre...@gmail.com> wrote:
> 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?
>
No. I suggest that (just out of my head. I need to rethink that all and
maybe come up with an better solution):
1) reclassifying FP
1.1) would call: --source=error --class=innocent
1.2) would compute: innocent learned + 1 , innocent misclassified + 1
1.3) undoing the reclassification would compute: innocent learned - 1 ,
innocent misclassified - 1
2) reclassifying FN:
2.1) would call: --source=error --class=spam
2.2) would compute: spam learned + 1 , spam misclassified + 1
2.3) undoing the reclassification would compute: spam learned - 1 ,
spam misclassified - 1
A undo would then be: --source=error --class=[spam|innocent]
--mode=unlearn
> This would always decrement spam_learned or inocent_learned or always
> decrement spam_misclassified or inocent_misclassified if the signature
> was found?
>
See above.
> 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.
>
I don't have apache2-suexec installed too nor do I need it for running my
DSPAM Web-UI. :)
> // Brad
--
Kind Regards from Switzerland,
Stevan Bajić
------------------------------------------------------------------------------
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
