Johannes Berg wrote:
tallison@tacocat.net schrieb:
How is dspam any different from using something like bogofilter + procmail
Oh. Probably not at all really (different approach, yadda yadda). However, I want the SQL backend.
OTOH, I only posted the stuff about dspam here as an explanation of why I was looking for such a plugin :-)
I was about to chime in and say "I think people missed your point."
It never came across to me that you were wanting something specific with dpsam... more that you wanted an explicit trigger for when a user decided something was/wasn't SPAM. And I, personally, love the idea.
Auto-training when (and only when) the user evaluates a message? Sounds great. Count me in.
So, let me see if I fully understand how you want it to go: 1) mail hits your MTA, which hands it off to dspam 2) dspam munges it, decides if it's SPAM or HAM, and delivers it to the user, either in INBOX or SPAM 3) if the USER moves a messages into SPAM, dspam is notified it missed a message, and retrains on it. 4) if the USER moves a message out of SPAM, dspam is notified it got a false-positive, and retrains on it.
Seems to me it will possibly lower the overall load, since you will only rescan/retrain messages _explicitly_ changed from/to SPAM/HAM. Now, if only you could get some resident form of dspam, so you didn't have to keep spawning it.... or did I miss something in the docs? Then again, there's libdspam...
-- Curtis Maloney