Stevan, as always, thank you for your quick response. You are a boon for us
dspam newbies.
While I understand your example, I was hoping for a pointer to some package
that others have used that I could slap in to place. I'm a developer, so
with your example as guidance, I could probably hack something together to
support this, but it's not really my focus right now. I'd rather not
re-invent the wheel if someone all ready has a script to do this.
Sounds like the right answer is for me to read up a bit on postfix email
processing rules, and just yank the email out of the stream at that point.
Training dspam after the fact is optional. I just want to remove obvious,
easy-to-identify-by-rule messages from the batch clients have to deal with.
Thanks,
Jesse
> On Tue, 10 Aug 2010 13:54:02 -0700
> Jesse Mundis <jesse.mun...@gmail.com> wrote:
>
> > Greetings dspam-ers.
> >
> > This has probably been asked before, but I couldn't find the discussion
> if
> > so.
> >
> > I know that dspam is all about the baysian filtering of tokens, but is
> there
> > any way to implement the equivalent of blanket "droplist" rules in
> addition,
> > at the dspam level of processing? That is, I trust the baysian analysis
> to
> > learn tokens over time, but I want to *always* treat as spam (as an
> example)
> > _any_ email with the string "viagra" in the from and/or subject line.
> >
> > I can do this easily client-side, but I'd love to have a way to filter
> these
> > out at the dspam level. I'm currently getting a few flavors of spam that
> > consistently get through dspam's filtering, even after training, and yet
> > strangely a subset of them always have this string in the "name" portion
> of
> > the from address. This makes them easy to spot in the client.
> >
> > Does dspam provide any mechanism besides post-hoc training where I can
> > define a simple list of tokens that, upon recognition in parsing,
> > automatically classifies the email as spam, trains and quarantines
> > appropriately, and be done with it?
> >
> Out of the box? No. DSPAM is all about statistics and not about rules.
> If you want something like that then you could implement it in your MTA.
> For example with Postfix doing header checks and if the header matches then
> reroute the mail to a custom made script that does nothing more than:
> 1) loop learning until DSPAM is saying that the message is SPAM
> 2) process the message
>
> Just out of my mind something like this:
> while true; do
> dsrc=$(dspam --user ${username} --classify --deliver=summary < ${message})
> if (echo ${dsrc}|grep -q "result=\"\(Whitelisted\|Innocent\)"); then
> dspam --user ${username} --class=spam --source=inoculation
> --deliver=summary < ${message}
> else
> break
> fi
> done
> dspam --user ${username} --process < ${message}
>
>
> Off course that is over simplified. I personally would add a maximum number
> of training loops and other things to prevent the script to tear down the
> system. Anyway... I think you get the picture.
>
>
>
> > Thanks,
> >
> > Jesse
> --
> 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
