On Thu, Oct 24, 2002 at 10:33:26PM +0200, Robert Ian Smit wrote:
> Because of the increasing amount of spam I receive, I want to do
> something about it.
>
> I know spamassassin by name. I believe the version in stable is
> quite old. Is it useful to install that version? What other tools
> should I consider?
>
> My setup: fetchmail -> exim -> procmail (-> mutt)
>
> Ideally I'd like something that I setup once and then runs without
> intervention required.
Most good solutions take a little maintenance. Setting up a macro in
mutt to send spam back for review when you get junk helps you in turn.
Personally, I'm a fan of using both bogofilter -and-
spamassassin. Skip to the bottom "What it does..." or read the
implementation part here:
I use exim->procmail->mutt, so starting with my procmail's
.procmailrc:
#
# BogoFilter Start ...
#
# Check with bogofilter. If it's positive:
# - tell bogofilter to adjust the spam positive weights
# - file it in my "inbox-spam-bogo" mailbox
:0HB
* ? bogofilter
{
:0c
| bogofilter -s
:0
inbox-spam-bogo
}
# bogo said it wasn't spam. adjust non-spam positive weights...
:0EHBc
| bogofilter -n
#
# Spam Assassin part ...
#
# Check with spamassassin...
:0fw
| spamassassin
:0e
{
EXITCODE=$?
}
# Is it spam? Move it to "inbox-spam-assassin" if so.
:0:
* ^X-Spam-Status: Yes
inbox-spam-assassin
#
# Spam Filtering End
#
That's the first half of the puzzle. The second is in my .muttrc:
macro index X "<enter-command>unset wait_key\n|spamassassin -d|bogofilter
-S\n|spamassassin -r\n<enter-command>set wait_key\n<delete-message>"
macro index \cx "<enter-command>unset wait_key\n|spamassassin -d|bogofilter
-S\n<enter-command>set wait_key\n<delete-message>"
macro pager X "<enter-command>unset wait_key\n|spamassassin -d|bogofilter
-N\n<enter-command>set wait_key\n"
The above is unclear because of my key choices, but in a nutshell:
shift-X in list view: This message was spam and didn't get
caught. Tell bogo and spamassassin they screwed up, then delete.
ctrl-x in list view: Bogo didn't catch this, but spamassassin
did. Just tell bogo it screwed up.
shift-X in the email viewer: This message -wasn't- spam. Tell bogo it
screwed up. No way to tell spamassassin it had a false positive.
What it does...
The above runs a message through bogofilter, training it based on its
own results. If bogo believes a message isn't spam, it's passed on to
spamassassin to check. If neither believe they have found spam, the
message is run through the rest of my procmail rules.
My email reading goes like this:
Read mail in my main box and lists. If I spot any spam, I make sure
I'm in the list view (not the message view) and hit shift-X. This
strips all the bogo and spamassassin headers out, and submits the
message to spamassassin's top-secret review cabal. The message is also
passed back to bogofilter, telling it to undo the "good" weights and
apply bad.
Every few days, I review my spam boxes...
In the bogofilter box, I just delete anything that's obviously spam
from the headers. After a week's training, there are a few occasional
false positives, but the rate is perhaps a couple messages per
thousand. If I find a false positive, I hit shift-X from within the
message viewer and bogo is reprimanded.
The spamassassin box gets almost no use after a week or so of
training, as bogo catches most everything first. In the list view, I
use ctrl-X to report each found item back to bogofilter, and for false
positives, I know of no way to tell the spamassassin folks. In theory
if I started having a problem, I'd just adjust the weights of some of
the rules.
If I find a third good package, I'm thinking of routing unanimous
positives straight to /dev/null which would save a little more time
still.
In the meantime, the above isn't awkward once you get used to it. My
>100 pieces of spam take about 30 seconds out of my day now, where it
used to be five or six, and my ALL CAPS USING AOL FRIENDS don't get
twitch-deleted so often anymore. :-)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
