RE: How to properly teach SA to recognise the spam that is still getting through, despite the rules updates

[Bowie Bailey <Bo...@BUC.com>]

Olaf Greve wrote:
> Hi,
> 
> Firstly: I'm new to this list and also pretty new to SA in general. I
> did try to find the answers to my questions in the FAQ, but haven't
> succeeded beyond all doubt at doing so. I do hope, however, that I'm
> not flogging a dead horse with my below questions (which appear at
> the end of the message)...:P    
> 
> Secondly, I'd like to say that SA is a *great* tool, and that
> "Internet-life" is much better with it, than it used to be without
> it! :P  
> 
> The situation:
> I run a FreeBSD 5.4-release AMD-64 based server, on which I have
> installed SA (identified by pkg_info as:
> "p5-Mail-SpamAssassin-3.2.4_2") through Amavisd-new (precise version,
> according to pkg_info: "amavisd-new-2.5.2,1"), which is being invoked
> after mail arrives on the RX side of Sendmail. The RX daemon is split
> in two, and tunnels the mail locally through amavisd-new (using clamd
> and SA), and all mail that passes the tests gets delivered, and the
> rest goes directly to the quarantine.       
> 
> The problem:
> The above set-up was working fine (using SA 3.2.3) for several
> months, and virtually no spam got through. However, all of a sudden
> since some two weeks I'm getting about 100 spam mails per day again,
> and these seem to include spam mails that I have previously seen
> being filtered out... Still, by far most of the spam does get
> filtered out, but for some reason (perhaps spammers finding ways
> around SA?) more and more spam is getting through again.      
> 
> My approach so far:
> Figuring SA or the rules to be outdated (despite the twice-weekly
> call to sa-update from cron), I first updated SA to 3.2.4. (and
> performed an sa-update too), but to no real avail: the same amount of
> spam seemed to be getting through. I then checked into additional
> channels, and soon came across the SARE (based) ones. I decided to
> add the saupdates.openprotect.com channel, but still the same amount
> of spam seems to get through.      
> 
> The way I perform my updates are as follows:
> 
> Cron call:
> 23 3 * * 2,5 /usr/local/bin/sa-update --allowplugins --gpgkeyfile
> /root/sa_pgp_keys --channelfile /root/sa_channels &&
> /usr/local/etc/rc.d/sa-spamd.sh restart > /dev/null  
> 
> (yes, I realise spamd is not actually used by amavisd-new, but I
> decided to have it running anyway) 
> 
> My /root/sa_channels file contains the following:
> saupdates.openprotect.com
> updates.spamassassin.org
> 
> Now, my questions are:
> 1-Am I doing anything wrong, or am I grossly overlooking something?
> 2-I've never tried to teach SA about which messages are spam and
> which are ham. From what I gather from the website, I need to set-up
> a mailbox with solely spam and feed that to sa-learn, and then do the
> same for a mailbox containing solely ham. However, how can I best go
> about this? Once spam is misidentified, it gets mixed in the live
> mailboxes with ham, so I wouldn't want to classify all of it as
> either ham or spam... Then, I did keep the spam messages from the
> last few days. Can I perhaps (manually) forward those to a local
> mailbox, and then run sa-learn on that mailbox, getting it
> successfully identified as spam, or will that not work due to the new
> mail headers added by the forward action from my mail client? 3-Are
> there perhaps other good (preferrably automatic ways) to tell SA
> about what is spam, and what isn't? 4-Are there perhaps other very
> efficient rules channels that you can recommend me to add (like using
> the full set of SARE rules, rather than the openprotect subset of
> it)? 5-Just a theory, but is it perhaps possible that SA somehow
> misidentified a spam message as being ham, and that all messages that
> are similar to that particular spam message are now being
> misidentified as ham, hence all getting through?               
> 
> Any and all feedback will be greatly appreciated, and I would like to
> thank you all for taking the time to read this e-mail and address the
> questions raised in it.  
> 
> With kind regards,
> Olaf Greve

Lots of questions here.  I don't see you doing anything wrong, so the
place to start would be with a sample spam so that we can see what you
are getting and what rules are (and are not) hitting on it.

-- 
Bowie

Re: How to properly teach SA to recognise the spam that is still getting through, despite the rules updates

[Jari Fredriksson <ja...@iki.fi>]

> Olaf Greve wrote:
>> The way I perform my updates are as follows:
>> 
>> Cron call:
>> 23 3 * * 2,5 /usr/local/bin/sa-update --allowplugins
>> --gpgkeyfile /root/sa_pgp_keys --channelfile
>> /root/sa_channels && /usr/local/etc/rc.d/sa-spamd.sh
>> restart > /dev/null 
>> 
>> (yes, I realise spamd is not actually used by
>> amavisd-new, but I decided to have it running anyway)
>> 
> 
> Lots of questions here.  I don't see you doing anything
> wrong, so the place to start would be with a sample spam
> so that we can see what you are getting and what rules
> are (and are not) hitting on it. 

What is an error, is that amavis-new does not get restarted after sa-update. While the unnecessary spamd gets restarted, the actual daemon running the SA is not..

Hardly not the cause for the spam passing thru, but who knows.