Bayes Training

[Joe Borg <jo...@datastream.com.mt>]

Hi,
I'm trying to figure out a proper way how to teach spamassassin new spam.
I'm using v. 3.04. My Setup consists of Sendmail and Spamassassin (via
procmail). Subsequently mail is retrieved by users using POP3. 

When spam messages and not detected, my users typically forward this spam as
an rfc822 attachment to a special account (report_spam@mydomain.com). I was
then thinking of bouncing the actual attachment (spam) to another specific
account (spamtrap@mydomain.com), which I've setup so that mails received on
this account are learned as spam. I've also taken care of ignoring the
'ReSent' headers added in bouncing a message. My only issue now is that when
a message is bounced (I use PC Pine to bounce messages), there are two
'From' headers. Eg. 


>From report_spam@mydomain.com  Wed Aug 10 10:55:28 2005
Return-Path: < report_spam@mydomain.com >
Received: from localhost ([125.125.125.25])
        by mailhost.mydomain.com (8.12.11/8.12.11) with ESMTP id
j7A8tRQt018687
        for <sp...@mydomain.com>; Wed, 10 Aug 2005 10:55:28 +0200
From: "Spammer Me" <sp...@rubbishdomain.com>

As you can see the second 'From' is the true spammer, whilst the first
'From' is my own reporting account. My worry here is that bayes will use my
reporting account as a 'shortcut'. Is there any way of avoiding this (i.e.
can I tell bayes to ignore the first from header but not the second)?  

Alternatively do you have any suggestions as to how I should train bayes?
Thanks,
Joe

RE: Bayes Training

[Joe Borg <jo...@datastream.com.mt>]

-----Original Message-----
From: Loren Wilton [mailto:lwilton@earthlink.net] 
Sent: 10 August 2005 11:43
To: users@spamassassin.apache.org
Subject: Re: Bayes Training

> As you can see the second 'From' is the true spammer, whilst the first
> 'From' is my own reporting account. My worry here is that bayes will use
my
> reporting account as a 'shortcut'. Is there any way of avoiding this (i.e.
> can I tell bayes to ignore the first from header but not the second)?

While this isn't desirable for obvious reasons, I think in this case you
will be ok, as long as that account is used ONLY for spam.  Bayes learns
tokens, not token combinations or sequences.  As a result, it will doubtless
learn that name as a really spammy token.  But if that doesn't show up in
any ham, you should be fine.  It will just be wasting some effort learning a
token that doesn't really show up in spam or (hopefully) ham.

        Loren

Hi Loren,

Thanks for the info. Will stick to my current method then :)
Joe

Re: Bayes Training

[Loren Wilton <lw...@earthlink.net>]

> As you can see the second 'From' is the true spammer, whilst the first
> 'From' is my own reporting account. My worry here is that bayes will use
my
> reporting account as a 'shortcut'. Is there any way of avoiding this (i.e.
> can I tell bayes to ignore the first from header but not the second)?

While this isn't desirable for obvious reasons, I think in this case you
will be ok, as long as that account is used ONLY for spam.  Bayes learns
tokens, not token combinations or sequences.  As a result, it will doubtless
learn that name as a really spammy token.  But if that doesn't show up in
any ham, you should be fine.  It will just be wasting some effort learning a
token that doesn't really show up in spam or (hopefully) ham.

        Loren

Re: Bayes Training

[Kris Deugau <kd...@vianet.ca>]

Joe Borg wrote:
> When spam messages and not detected, my users typically forward this
> spam as an rfc822 attachment to a special account
> (report_spam@mydomain.com). I was then thinking of bouncing the actual
> attachment (spam) to another specific account (spamtrap@mydomain.com),

Any reason you don't just extract the attachment and learn it?

(Or extract the attachment and stuff it into a mail folder for manual
sorting and later manual learning or periodic automated learning.)

That would avoid the (potential) mistakes, hassles, and screwups that go
along with resending a spam (and therefore replacing "correct" headers,
or adding misleading or useless headers).

-kgd
-- 
Get your mouse off of there!  You don't know where that email has been!