You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by "Shaun T. Erickson" <st...@gmail.com> on 2007/01/01 21:13:57 UTC
No hits on SARE rules.
I have two identically (or so I thought) configured mail servers, each
pulling down SARE rules (successfully, I might add). One of them shows
hits on SARE rules all the time - the other one, never. Aside from
simply configuring sa-update to pull the rules down, I'm wondering if
there is something I've forgotten to do, on the one server, to
actually put them into effect - aside from restarting SA, which has
been done numerous times. SA is called by amavisd-new, in both cases,
which is restarted any time the rules are updated.
What am I doing wrong?
--
-ste
Re: No hits on SARE rules.
Posted by Brian Z <li...@tekmonster.net>.
Do you have any log entries in /var/logs/maillog
----- Original Message -----
From: "Shaun T. Erickson" <st...@gmail.com>
To: "SpamAssassin" <us...@spamassassin.apache.org>
Sent: Monday, January 01, 2007 3:27 PM
Subject: Re: No hits on SARE rules.
> On 1/1/07, Shaun T. Erickson <st...@gmail.com> wrote:
>>
>> What am I doing wrong?
>
> I just ran amavisd with the debug-sa option, and as near as I can
> tell, it appears to only be using the original ruleset - and doesn't
> even seem to know that I am pulling new rules down with sa-update.
>
> I must have missed some important configuration step somewhere ...
> --
> -ste
>
Re: No hits on SARE rules.
Posted by "Shaun T. Erickson" <st...@gmail.com>.
Ok. I'm starting to understand this now. I've built perl 5.8.8 and
pointed my existing amavisd-new at it, by editing its first line. I
then added, via CPAN, any module it complained was missing, each time
I tried to run it, until it no longer complained of anything missing
(that was required, anyway - I seem to have a fair number of optional
modules that start like auto::something that I'm missing and not sure
how to get).
amavisd is definitely looking at perl 5.8.8 as is evident from it's
out put. In fact it's using
/usr/local/perl-5.8.8/etc/mail/spamassassin/local.cf as it's config
file and the *.pre files it's using are in the same directory and the
rules it's loading are in /usr/local/perl-5.8.8/share/spamassassin. It
doesn't appear to be reading any other local.cf.
I'll work on removing any other versions of SA on the system, except
the one under perl 5.8.8. What else can I do to get this to work? I
think I'm making progress at least. :)
--
-ste
Re: No hits on SARE rules.
Posted by "Shaun T. Erickson" <st...@gmail.com>.
On 1/1/07, Shaun T. Erickson <st...@gmail.com> wrote:
> Ok, this is interesting. :)
The follow-up to this is that I just got spam that was hit by the SARE
rules, so it's working now. Additionally, Razor2 & DCC are now
working, as well. So the only mystery is why everything installed
where it did. I'm guessing that since it's a standalone build of perl,
that it compiled it's prefix (/usr/local/perl-5.8.8) into every module
as I built and installed them via CPAN, using that version of perl ...
just a guess.
Btw, thanks for the help everyone. It was your combined knowledge that
helped me get it running.
--
-ste
Re: No hits on SARE rules.
Posted by Gary V <mr...@hotmail.com>.
>Ok, this is interesting. :)
>
>I removed all SA installations, except for the one under
>/usr/local/perl-5.8.8.
>I moved my sa-update-keys directory to
>/usr/local/perl-5.8.8/etc/mail/spamassassin.
>I modified my nightly script to use /usr/local/perl-5.8.8/bin/sa-update.
>I ran my nightly script.
>
>Now it has re-downloaded all of my sare rules and so forth to
>/usr/local/perl-5.8.8/var/spamassassin/3.001007/
>
>When I run amavisd debug-sa, it now finds all the rules that were just
>downloaded to the above location. I presume I can get rid of the now
>useless and never used copies that are under /var/lib/spamassassin/...
>
>I'm not used to seeing everything under the perl install though ...
>--
> -ste
I have to admit I've never seen that before. Not sure what to think. In
general I think it is a challenge to run more than one version of Perl.
Gary V
_________________________________________________________________
The MSN Entertainment Guide to Golden Globes is here. Get all the scoop.
http://tv.msn.com/tv/globes2007/
Re: No hits on SARE rules.
Posted by "Shaun T. Erickson" <st...@gmail.com>.
Ok, this is interesting. :)
I removed all SA installations, except for the one under /usr/local/perl-5.8.8.
I moved my sa-update-keys directory to
/usr/local/perl-5.8.8/etc/mail/spamassassin.
I modified my nightly script to use /usr/local/perl-5.8.8/bin/sa-update.
I ran my nightly script.
Now it has re-downloaded all of my sare rules and so forth to
/usr/local/perl-5.8.8/var/spamassassin/3.001007/
When I run amavisd debug-sa, it now finds all the rules that were just
downloaded to the above location. I presume I can get rid of the now
useless and never used copies that are under /var/lib/spamassassin/...
I'm not used to seeing everything under the perl install though ...
--
-ste
Re: No hits on SARE rules.
Posted by "Shaun T. Erickson" <st...@gmail.com>.
On 1/1/07, Gary V <mr...@hotmail.com> wrote:
>
> When you run amavisd debug-sa does it say you are using?:
> Module Mail::SpamAssassin 3.001007
Yes.
> Have you run 'sa-update'? I'm wondering if you have files in
> /var/lib/spamassassin/3.001007/
Yes, I see stuff in there, and in the directories I see the normal SA
rules and the SARE rules.
> If so, you should see something similar to:
> <...>
> dbg: config: read file /etc/spamassassin/init.pre
That's where it goes astray (?) and uses everything from
/usr/local/perl-5.8.8/etc/mail/spamassassin
--
-ste
Re: No hits on SARE rules.
Posted by Gary V <mr...@hotmail.com>.
>>You must be running SA 3.1.4 or older and amavisd-new 2.4.2 or older.
>
>Nope. SA 3.1.7 & amavisd-new 2.4.4.
>
>I see in amavisd, the line you suggested I add is actually there, but
>commented out, as a comment there indicates that SA should be able to
>handle this on it's own.
>
>This is a RH9 system (my client won't let me upgrade). I had
>previously built perl 5.8.7 and installed it in /usr/local/perl-5.8.7
>and changed the first line of amavisd to point to it instead of the
>system perl. Is changing that one line sufficient to insure that that
>version of perl is the only one that amavis will use for everything
>perl (including SA)?
>
Not sure.
>Since I have some indication that there might be a problem with that
>version of perl, I'm now building 5.8.8 and will point amavis at that.
>Anything else I should do? Of course, I'll install all needed module
>into this new version, via CPAN.
>--
> -ste
Not sure there either.
When you run amavisd debug-sa does it say you are using?:
Module Mail::SpamAssassin 3.001007
Have you run 'sa-update'? I'm wondering if you have files in
/var/lib/spamassassin/3.001007/
If so, you should see something similar to:
<...>
dbg: config: read file /etc/spamassassin/init.pre
dbg: config: read file /etc/spamassassin/v310.pre
dbg: config: read file /etc/spamassassin/v312.pre
dbg: config: using "/var/lib/spamassassin/3.001007" for sys rules pre files
dbg: config: read file
/var/lib/spamassassin/3.001007/updates_spamassassin_org.pre
dbg: config: using "/var/lib/spamassassin/3.001007" for default rules dir
dbg: config: read file
/var/lib/spamassassin/3.001007/updates_spamassassin_org.cf
dbg: config: using "/etc/spamassassin" for site rules dir
<...>
At this point SA will no longer look in a place like /usr/share/spamassassin
for any rules.
With amavisd-new 2.4.4 you should be able to narrow down debug output so you
only see config lines:
amavisd -d config debug-sa
Note where amavisd-new looks for your rules files (all SA files for that
matter). It's possible you have more than one directory where rules are
placed (spamassassin is installed in more than one place). If so, you need
to place the SARE rules where amavisd-new says it is looking for them, or
better yet, clean it up by removing the stuff that belongs to a different
(older) version of spamassassin (if that's what the problem is).
Gary V
_________________________________________________________________
Get FREE Web site and company branded e-mail from Microsoft Office Live
http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/
Re: No hits on SARE rules.
Posted by "Shaun T. Erickson" <st...@gmail.com>.
On 1/1/07, Gary V <mr...@hotmail.com> wrote:
>
> You must be running SA 3.1.4 or older and amavisd-new 2.4.2 or older.
Nope. SA 3.1.7 & amavisd-new 2.4.4.
I see in amavisd, the line you suggested I add is actually there, but
commented out, as a comment there indicates that SA should be able to
handle this on it's own.
This is a RH9 system (my client won't let me upgrade). I had
previously built perl 5.8.7 and installed it in /usr/local/perl-5.8.7
and changed the first line of amavisd to point to it instead of the
system perl. Is changing that one line sufficient to insure that that
version of perl is the only one that amavis will use for everything
perl (including SA)?
Since I have some indication that there might be a problem with that
version of perl, I'm now building 5.8.8 and will point amavis at that.
Anything else I should do? Of course, I'll install all needed module
into this new version, via CPAN.
--
-ste
Re: No hits on SARE rules.
Posted by Gary V <mr...@hotmail.com>.
>On 1/1/07, Shaun T. Erickson <st...@gmail.com> wrote:
>>
>>What am I doing wrong?
>
>I just ran amavisd with the debug-sa option, and as near as I can
>tell, it appears to only be using the original ruleset - and doesn't
>even seem to know that I am pulling new rules down with sa-update.
>
>I must have missed some important configuration step somewhere ...
>--
> -ste
You must be running SA 3.1.4 or older and amavisd-new 2.4.2 or older. This
issue was resolved in both 3.1.5 and 2.4.3 so upgrading to a newer version
of either would solve the problem. You can also patch older versions of
amavisd-new by adding LOCAL_STATE_DIR => '/var/lib', in the location shown
here:
--- amavisd~ Mon Apr 3 16:32:34 2006
+++ amavisd Thu Aug 3 15:13:19 2006
@@ -14562,2 +14562,3 @@
stop_at_threshold => 0,
+ LOCAL_STATE_DIR => '/var/lib',
# DEF_RULES_DIR => '/usr/local/share/spamassassin',
>From amavisd-new release notes:
- add "LOCAL_STATE_DIR => '/var/lib'" to the SA object initialization
for versions of SA 3.1.4 or older, so that SpamAssassin would see
additional rules provided by sa-update and placed to its default location;
the SA 3.1.5 provides its own default so this becomes unnecessary;
Gary V
_________________________________________________________________
Find sales, coupons, and free shipping, all in one place! MSN Shopping
Sales & Deals
http://shopping.msn.com/content/shp/?ctid=198,ptnrid=176,ptnrdata=200639
Re: No hits on SARE rules.
Posted by "Shaun T. Erickson" <st...@gmail.com>.
On 1/1/07, Shaun T. Erickson <st...@gmail.com> wrote:
>
> What am I doing wrong?
I just ran amavisd with the debug-sa option, and as near as I can
tell, it appears to only be using the original ruleset - and doesn't
even seem to know that I am pulling new rules down with sa-update.
I must have missed some important configuration step somewhere ...
--
-ste
Re: No hits on SARE rules.
Posted by Richard Ozer <ro...@ois-online.com>.
Make sure you do not have multiple directories containing your local.cf.
What you are describing can occur if (for instance) you have both an
/etc/spamassassin and /etc/mail/spamassassin directory containing
configuration files. Also, make sure your root home directory does not
contain a local.cf.
----- Original Message -----
From: "Shaun T. Erickson" <st...@gmail.com>
To: "SpamAssassin" <us...@spamassassin.apache.org>
Sent: Monday, January 01, 2007 12:13 PM
Subject: No hits on SARE rules.
>I have two identically (or so I thought) configured mail servers, each
> pulling down SARE rules (successfully, I might add). One of them shows
> hits on SARE rules all the time - the other one, never. Aside from
> simply configuring sa-update to pull the rules down, I'm wondering if
> there is something I've forgotten to do, on the one server, to
> actually put them into effect - aside from restarting SA, which has
> been done numerous times. SA is called by amavisd-new, in both cases,
> which is restarted any time the rules are updated.
>
> What am I doing wrong?
> --
> -ste
>