bogofilter setup in multi-user

[.rp]

On 29 Jun 2004 at 17:21, Tom Anderson wrote:

> From: ".rp" <printer at moveupdate.com>
> > Next we check the subject for certain words that we know we want no part
> of
> >
> > :0H
> > *  ^Subject:.*(p0rn| pr0n| HGH |ha1f| curn |GB2312)|\
> >   ^Subject:.*(paris hilton|p4ris|par1s|p4r1s )|\
> >   ^Subject:.*(iagra |@gra|1agra|lagra|Cialis)|\
> > /dev/null
> 
> This is dangerous... what if you have legitimate emails that talk about
> these topics... like emails in this list?
> 
so? the subject in the header is checked, not the body.

> > #no legit mail should have "|" in its subject
> > :0H
> > * ^Subject:.*(\|)
> > /var/spool/mail/junkbox
> 
> Why not?  I don't see anything in the RFC banning it.  Do you often receive
> spams with a pipe in the subject?  This seems odd to me.
>
who said anything about the RFC? this is real world. And yes, we did get tons of it, 
otherwise it wouldn't have made an issue.
 
> > :0H:
> > * ^Subject:.*(â|í|Ò|Æ|¶|¯|º|Í|Á|ª|Í|¨|È|«|¿|ª|Í|¨|Ë|ë|ä|ö|ü|ï|é|¡|ã|ò)
> > /dev/null
> 
> Again, dangerous.
>
Not for us, but yes if you did run a foreign language shop you should probably adjust 
it to your purposes.
 
> > Then we go through and see if it is for someone with special needs in
> their filtering
> > #if for Rick -  do a special run for them
> 
> Why not specify these rules in each users own procmailrc file and specify
> their bogofilter settings in their bogofilter.cf file?  Managing this in a
> single large file could be burdensome with a much larger set of users.
>
Depends - if the user already needs and has a shell account, then a .procmail is 
setup in their directories. But if they don't , we handle it in one central location. This 
actually turned out to be much easier than handling lots of individual files. In addition, 
we already had a procmailrc setup to handle other email flows unrelated to BF.
 
> It seems like you could just eliminate most of these procmail rules and rely
> solely on bogofilter instead.  Bogofilter should handle most of the obvious
> spam terms like "pr0n" and whatnot, and then you wouldn't have to maintain
> your own ad hoc list which will likely go out of date very quickly.
> 
We see no need to have bogofilter handle the obvious spam anymore and would 
prefer to spend computer resources on those that are not obvious.
As for using /dev/null - those rules that got it 100% after a 3 month testing period 
were assigned /dev/null, the ones that didn't get placed into folders that are rotated 
every day and kept for a month.