On Tue, 10 Aug 2010 14:52:41 -0700
Jesse Mundis <jesse.mun...@gmail.com> wrote:
> 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.
You could do that easy by setting header_checks to a regexp or a pcre file. For
example:
header_checks = pcre:${config_directory}/header_checks
And then add something like this to the header_checks file:
/^Subject: .*(v|V|\\\/)(i|I|1|\xef|\|)(a|A|\(a\)|4|@)(g|G)(r|R)(a|A|\(a\)|4|@)/
REJECT Confirmed SPAM. Go away.
/^Subject: .*(v|V|\\\/)(a|A|\(a\)|4|@)(l|L|\|)(i|I|1|\xef|\|)(u|U|\(u\))(m|M)/
REJECT Confirmed SPAM. Go away.
If you ask me then I would suggest you to use something like policyd-weight or
policyd or postfwd and drop those bastards as soon as possible.
On my personal MX I have an enhanced version of policyd-weight that does GeoIP
(country and continent), distance computation, S25R, p0f and other small
things. This helps me to lower the inbound easy down to a fraction of what
would normally be queued by Postfix.
> 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
