{SPAM?} Re: [SLUG] local mail filtering

From: Paul M Foster (paulf@quillandmouse.com)
Date: Tue Mar 16 2004 - 19:15:55 EST


On Tue, Mar 16, 2004 at 04:08:58PM -0500, Mike Branda wrote:

> Hello!
>
> I attend the Dunedin meeting and was referred to the slug list for help so
> here goes.
> I'm running SuSE 9 as a firewalled gateway box. We don't have a large mail
> load or a large budget so I would like to double the gateway as a "in house"
> mail filter. Our mail is hosted externally and filtering is now needed due
> to a large increase in spam and viruses in the inbound mail. Our current
> web host does not handle filtering. I would like to pull down the mail with
> fetchmail, filter it through spamassassin and maybe amavis or other virus
> scanner, and then spool it for the LAN machines to pull down into Outlook
> for Windows. Ideally, the questionable stuff would be dropped into a holding
> folder to determine if it's legitimate or not. The Problem I am having is
> that I can already pull down the mail, but I don't know how to set up the
> config files for procmail ( if that's the proper software? ) or how to
> forward the processed mail to the local pop3/imap server for outlook to
> retrieve.

I can help with the part up to your local pop server, but I know nothing
about setting up a local pop server. The following advice is based on me
pulling down my personal mail. I don't process mail on a machine-wide
basis, so the .fetchmailrc and .procmailrc files I talk about here are
local to my user. You'll have to search around to find the analogs for
the whole machine.

In your fetchmailrc file, it should look something like this:

poll my.mail.server
protocol pop3
timeout 180
username bilbo
password baggins
mda "/usr/bin/procmail"

The really important line is the last one, where it hands off the mail
to procmail.

In procmail, you need to find the .procmailrc file and edit that.

First, I would strongly advise backing up your inbound mail, in case you
screw something up. I would add a line like this into my .procmailrc
before any other recipes:

:0 c:
backup

This will make a _copy_ of everything inbound and put it into a "backup"
folder. (Actually I do this in a more complicated way, by having a
backup folder for every day of the month, which then get rotated
monthly. If you need specifics on this, let me know.)

After this, you would normally put recipes that cull mail that you know
_isn't_ spam, so SpamAssassin doesn't have to look at it. The man pages
for procmailrc and procmailex will explain in detail how to set up
procmail recipes, and there are numerous websites full of such recipes.
There is also a treatment of this on the SLUG FAQ page.

For SpamAssassin, there are instructions in and amongst the spamassassin
files about how to do spamassassin procmail recipes. After all your
other recipes, you insert spamassassin recipes in your .procmailrc. It
goes like this:

:0fw: spamassassin.LCK
* < 256000
| spamassassin

:0
* ^X-Spam-Status: Yes
/dev/null

:0:
maybe

The recipe above hands any mail smaller than 256K off to spamassassin.
If you want _all_ mail regardless of size to be checked, remove the "* <
256000" line. However, note that doing so may cause your spamassassin to
have to scan for text strings in multi-meg mail files. This recipe marks
the mail internally as to its spam-worthiness.

The second recipe checks to see if the preceding mail was spammish. It
checks for a header line like "X-Spam-Status: Yes". If this is present
(SA decided it was spam), this mail will be shuttled off to /dev/null.
You can do something else with it here, if you like, by changing
"/dev/null" to the name of some other folder.

The last recipe routes any remaining mail to the "maybe" folder. Change
as needed. Also note that any mail skipped by the first recipe (< 256K)
will also end up in this folder.

There are a couple of other things to know. First, you can speed up the
process of SA scanning your mail by using the spamd and spamc programs.
The spamd is a daemon that runs in the background, and spamc is the
client version you actually hand mail off to (instead of
"spamassassin"). When you get further along, you can ask about how to do
this, or read the man pages for spamassassin.

The other thing to know is that SA is tunable. SA has a built-in
threshhold from 1 to 10 on the way it grades spam. The higher the score,
the more spammacious mail is. You can change this threshhold so that
more mail gets marked as spam by lowering the threshhold. Somewhere
where all your other spamassassin files are is one called "user_prefs"
(likely perhaps in /etc/spamassassin or in ~/.spamassassin/). In that
file, there is a statement like:

required_hits 5

You can change this to a lower number to let less spam through.

This is _way_ overlong, but hopefully it will point you in the right
direction. If you need, clarification, ask.

Paul

-----------------------------------------------------------------------
This list is provided as an unmoderated internet service by Networked
Knowledge Systems (NKS). Views and opinions expressed in messages
posted are those of the author and do not necessarily reflect the
official policy or position of NKS or any of its employees.



This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 19:21:50 EDT