[TriLUG] Re: spam solutions - spamassassin

Myrhillion lug at blackwizard.net
Tue Jun 8 18:49:19 EDT 2004


Gregory,  Jon and Lance.

Finally got around to spooning myself the spamassassin docs (wading pool 
deep) and reading up a bit on procmail as a side dish.
Thanks for the input, it motivated me to install spamassassin and remove 
assp.

I'm using postfix for the MTA, procmail for local delivery (apparently, 
just one change in postfix configs), and now spamd/spamc to
take care of the filtering (well labeling / monitoring for a few 
days).   I have to take it a step further yet for the anti-virus but I 
want to get
to the point where I'm actually filtering instead of just labeling after 
I develop some trust (scary?) for spamassassin in a few days .

I'm already noticing that the default hits of 5 seems to miss a lot of 
spam (from the default config), so
I'll probably need to figure out this spam / ham feeding business next 
and then lower the hits value in config.

Anyway, just wanted to put it out there that I appreciated the responses 
(even a few weeks later).  It helped.

I have two friends urging me (read, covering their mouths, pointing and 
giggling for not using exim as the MTA:   ahh the endless wars continue).

Doug Taggart

Gregory Woodbury wrote:

>On Sat, May 22, 2004 at 04:42:37PM -0400, Myrhillion wrote:
>  
>
>>Hi Rick,
>>
>>I've been struggling a bit trying to setup a spam solution.
>>I have tried assp, but find it wanting..  too much training.
>>
>>Can you give me your opinions on spamassassin?  I hear a lot of people 
>>using this,
>>but was curious what kind of commitment is required to get it setup to 
>>actually
>>filter spam as opposed to spam + legit email.
>>
>>I thought an opinion from someone running it might be helpful.
>>Thanks for your time.
>>
>>Doug Taggart
>>    
>>
>
>I've been using spamassassin for several years now.  I have it trained
>fairly well to detect spam with 0 false positives and a low rate of
>false negatives.  In other words, it never classes legit email as spam
>and only rarely lets spam thru to my mail box.
>
>The amount of training is steep on the front end.  At first you have to
>feed a large selection of spam into the trainer and then you jut have to
>tweak the thing occasionally as new trends in spam arise.
>
>I have a collection of selected spam messages that I use to seed newly
>installed user filters (or if I re-install the whole system). This is
>not as big a deal as it might sound.  I use "selected" messages that
>don't have many of the "cache poisoning" random word collections that
>has become one of the recent attempts by spammers to bypass SA and other
>baysian detectors.
>
>If so inclined you can install the optional extended interface to
>Vipul's Razor collective database of spam but I find that a bit much for
>my lazy tastes.
>
>If you are on a Linux platform (easy guess huh?) an anti-virus filter
>like ClamAV is worth installing.  I slipped ClamAV into my system in
>about 15 minutes just a week or so ago [Fedora Core 1/sendmail] and it
>does wonders for the virus laden emails before they can slip past the SA
>filters.
>
>Installing SA can take two forms: a system-wide filtering with all mail
>being passed into SA by sendmail before local delivery; or a per-user
>installation where you have each users' procmail scripts process thru SA
>as part of local delivery.  I opted for the local procmail solution as
>there are a few usernames that get no spam and thus don't require the
>overhead. (Besides, I was too lazy to figure out the SA "milter" at the
>time of initial install and don't particularly relish being the "censor"
>for all the users - I wasn't sure how tuning/training worked when the
>system-wide method is used. I installed at home before I installed at
>any of my work locations.)
>
>For per-user installations, the following is used at the top of user
>procmailrc files to pass stuff thru the spamassassin daemon:
>
>
>---------------------------(cut here)
>:0f:
>|	/usr/bin/spamc -f
>
>:0:
>*	^X-Spam-Flag: YES
>	mbox.caughtspam
>
>:0
>*	^TO .*@trilug.org
>	mbox.trilug
>---------------------------(cut here)
>
>As you can see, the spam filtering is done before filtering mailing
>lists into separate folders, though you could select to filter stuff
>into folders before filtering thru spamc. 
>
>I'm supporting about 10 users and ~20 accounts on 6 machines here at
>home.  At one job we were supporting >5000 accounts and matching network
>scale with 1 SA daemon on the incoming mail server. Perhaps others will
>chime in with how it scales for them.
>
>
>  
>



More information about the TriLUG mailing list