You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Eduardo Júnior <ih...@gmail.com> on 2008/07/25 13:58:25 UTC
Sa-update
Hi,
I have just done an update in the rules of my spamassassin with sa-update
He dropped everything to /var/lib/spamassassin/version
He created the directory with several updates_spamassassin_org. Cf
And a updates_spamassassin_org.cf and updates_spamassassin_org.pre.
Peguei of the includes updates_spamassassin_org.cf and put in
/etc/spamassassin/local.cf and I made a copy of my *. cf / etc /
spamassassin to maintain consistently referenced in the path includes.
Executei a /init.d/spamassassin restart to restart.
The question is:
I am making an accurate?
How to test if these new rules are working properly?
I´m using:
# spamassassin --version
SpamAssassin version 3.1.7
running on Perl version 5.8.8
[]´s
--
Eduardo Júnior
GNU/Linux user #423272
:wq
Re: Sa-update
Posted by Matt Kettler <mk...@verizon.net>.
Eduardo Júnior wrote:
>
> Continuing with the sa-update
>
> When run sa-update -D, my output has the following excerpt:
>
> [14661] dbg: diag: module not installed: IP:: Country:: Fast (
> 'require' failed)
> [14661] dbg: diag: module not installed: Razor2:: Client:: Agent (
> 'require' failed)
> [14661] dbg: diag: module not installed: Net:: Ident ( 'require' failed)
> [14661] dbg: diag: module not installed: IO:: Socket:: INET6 (
> 'require' failed)
> [14661] dbg: diag: module not installed: IO:: Socket:: SSL ( 'require'
> failed)
>
>
> They have some influence in learning?
All of those are modules that support optional features.
The IP::Country::Fast can influence learning, by providing additional
token data on what countries the message has been routed through, but
it's hardly critical.
> And how to verify that the recognition of spam in fact improved?
Look for higher BAYES_* rules hitting on spam, and lower ones on nonspam.
Re: Sa-update
Posted by Eduardo Júnior <ih...@gmail.com>.
Continuing with the sa-update
When run sa-update -D, my output has the following excerpt:
[14661] dbg: diag: module not installed: IP:: Country:: Fast ( 'require'
failed)
[14661] dbg: diag: module not installed: Razor2:: Client:: Agent ( 'require'
failed)
[14661] dbg: diag: module not installed: Net:: Ident ( 'require' failed)
[14661] dbg: diag: module not installed: IO:: Socket:: INET6 ( 'require'
failed)
[14661] dbg: diag: module not installed: IO:: Socket:: SSL ( 'require'
failed)
They have some influence in learning?
And how to verify that the recognition of spam in fact improved?
On Sat, Jul 26, 2008 at 10:42 AM, Eduardo Júnior <ih...@gmail.com>wrote:
>
>
> On Fri, Jul 25, 2008 at 8:39 PM, Matt Kettler <mk...@verizon.net>wrote:
>
>> Eduardo Júnior wrote:
>>
>>>
>>> Hi,
>>>
>>>
>>> I have just done an update in the rules of my spamassassin with sa-update
>>>
>>> He dropped everything to /var/lib/spamassassin/version
>>>
>>> He created the directory with several updates_spamassassin_org. Cf
>>> And a updates_spamassassin_org.cf <http://updates_spamassassin_org.cf>
>>> and updates_spamassassin_org.pre.
>>>
>>> Peguei of the includes updates_spamassassin_org.cf <
>>> http://updates_spamassassin_org.cf> and put in /etc/spamassassin/
>>> local.cf <http://local.cf> and I made a copy of my *. cf / etc /
>>> spamassassin to maintain consistently referenced in the path includes.
>>>
>> No. DO NOT copy the files from where sa-update put them. Just run it, and
>> leave them where they are. SA will find them where sa-update put them.
>>
>> The *ONLY* files that should be in /etc/spamassassin are the ones you put
>> there (ie: local.cf, or any add-on rules that aren't a part of the
>> standard set).
>
>
>
>
> Ok, but I already did this, correct this, as this before.
>
>
>
>>
>>
>>
>>> Executei a /init.d/spamassassin restart to restart.
>>>
>>> The question is:
>>>
>>> I am making an accurate?
>>> How to test if these new rules are working properly?
>>>
>> If you want to make sure your SA is detecting the new rule directory
>> sa-update created:
>>
>> Look near the top of the output of "spamassassin --lint -D", it should
>> mention the new directory about a half page down or so.
>
>
>
> Yes, debugging shows me that information.
>
>
>
>
>>
>>>
>>>
>>> I´m using:
>>>
>>> # spamassassin --version
>>> SpamAssassin version 3.1.7
>>> running on Perl version 5.8.8
>>>
>> You really should consider upgrading versions. sa-update only updates
>> rules, and there have been no new rules for the 3.1.x family since late
>> 2007. We're on 3.2.5 now.
>
>
>
> Unfortunately, it's not possible now, because the server is in production
> and can't stop.
> But i already proposed an updated.
>
>
>
> []'s
>
>
>
> --
> Eduardo Júnior
> GNU/Linux user #423272
>
> :wq
>
--
Eduardo Júnior
GNU/Linux user #423272
:wq
Re: Sa-update
Posted by Eduardo Júnior <ih...@gmail.com>.
On Fri, Jul 25, 2008 at 8:39 PM, Matt Kettler <mk...@verizon.net>wrote:
> Eduardo Júnior wrote:
>
>>
>> Hi,
>>
>>
>> I have just done an update in the rules of my spamassassin with sa-update
>>
>> He dropped everything to /var/lib/spamassassin/version
>>
>> He created the directory with several updates_spamassassin_org. Cf
>> And a updates_spamassassin_org.cf <http://updates_spamassassin_org.cf>
>> and updates_spamassassin_org.pre.
>>
>> Peguei of the includes updates_spamassassin_org.cf <
>> http://updates_spamassassin_org.cf> and put in /etc/spamassassin/local.cf<
>> http://local.cf> and I made a copy of my *. cf / etc / spamassassin to
>> maintain consistently referenced in the path includes.
>>
> No. DO NOT copy the files from where sa-update put them. Just run it, and
> leave them where they are. SA will find them where sa-update put them.
>
> The *ONLY* files that should be in /etc/spamassassin are the ones you put
> there (ie: local.cf, or any add-on rules that aren't a part of the
> standard set).
Ok, but I already did this, correct this, as this before.
>
>
>
>> Executei a /init.d/spamassassin restart to restart.
>>
>> The question is:
>>
>> I am making an accurate?
>> How to test if these new rules are working properly?
>>
> If you want to make sure your SA is detecting the new rule directory
> sa-update created:
>
> Look near the top of the output of "spamassassin --lint -D", it should
> mention the new directory about a half page down or so.
Yes, debugging shows me that information.
>
>>
>>
>> I´m using:
>>
>> # spamassassin --version
>> SpamAssassin version 3.1.7
>> running on Perl version 5.8.8
>>
> You really should consider upgrading versions. sa-update only updates
> rules, and there have been no new rules for the 3.1.x family since late
> 2007. We're on 3.2.5 now.
Unfortunately, it's not possible now, because the server is in production
and can't stop.
But i already proposed an updated.
[]'s
--
Eduardo Júnior
GNU/Linux user #423272
:wq
Re: Sa-update
Posted by Matt Kettler <mk...@verizon.net>.
Eduardo Júnior wrote:
>
> Hi,
>
>
> I have just done an update in the rules of my spamassassin with sa-update
>
> He dropped everything to /var/lib/spamassassin/version
>
> He created the directory with several updates_spamassassin_org. Cf
> And a updates_spamassassin_org.cf <http://updates_spamassassin_org.cf>
> and updates_spamassassin_org.pre.
>
> Peguei of the includes updates_spamassassin_org.cf
> <http://updates_spamassassin_org.cf> and put in
> /etc/spamassassin/local.cf <http://local.cf> and I made a copy of my
> *. cf / etc / spamassassin to maintain consistently referenced in the
> path includes.
No. DO NOT copy the files from where sa-update put them. Just run it,
and leave them where they are. SA will find them where sa-update put them.
The *ONLY* files that should be in /etc/spamassassin are the ones you
put there (ie: local.cf, or any add-on rules that aren't a part of the
standard set).
>
> Executei a /init.d/spamassassin restart to restart.
>
> The question is:
>
> I am making an accurate?
> How to test if these new rules are working properly?
If you want to make sure your SA is detecting the new rule directory
sa-update created:
Look near the top of the output of "spamassassin --lint -D", it should
mention the new directory about a half page down or so.
>
>
>
> I´m using:
>
> # spamassassin --version
> SpamAssassin version 3.1.7
> running on Perl version 5.8.8
You really should consider upgrading versions. sa-update only updates
rules, and there have been no new rules for the 3.1.x family since late
2007. We're on 3.2.5 now.
Re: Sa-update
Posted by Eduardo Júnior <ih...@gmail.com>.
I could see the problem:
read on:
http://www.ijs.si/software/amavisd/#faq-spam
amavisd realized that's who manages the upgrade of headers, overwriting any
changes made by spamassassin.
So what I incialmente is that the check is made by spammers by spamassassin
alone, without the amavis as an intermediary.
Desabilitei in / etc / amavis / amavisd.conf the line that makes the check
for spam:
# @ bypass_spam_checks_acl = qw (.);
I do not know if this is the appropriate list, but:
uncomment the above is sufficient for most amavis not call the spamassassin?
I ask this because below that the configuration file, you have several rules
that relate to spamassassin.
[]´s
On Fri, Jul 25, 2008 at 8:58 AM, Eduardo Júnior <ih...@gmail.com> wrote:
>
> Hi,
>
>
> I have just done an update in the rules of my spamassassin with sa-update
>
> He dropped everything to /var/lib/spamassassin/version
>
> He created the directory with several updates_spamassassin_org. Cf
> And a updates_spamassassin_org.cf and updates_spamassassin_org.pre.
>
> Peguei of the includes updates_spamassassin_org.cf and put in
> /etc/spamassassin/local.cf and I made a copy of my *. cf / etc /
> spamassassin to maintain consistently referenced in the path includes.
>
> Executei a /init.d/spamassassin restart to restart.
>
> The question is:
>
> I am making an accurate?
> How to test if these new rules are working properly?
>
>
>
> I´m using:
>
> # spamassassin --version
> SpamAssassin version 3.1.7
> running on Perl version 5.8.8
>
>
>
>
> []´s
>
> --
> Eduardo Júnior
> GNU/Linux user #423272
>
> :wq
>
--
Eduardo Júnior
GNU/Linux user #423272
:wq
Re: Sa-update
Posted by mouss <mo...@netoyen.net>.
Eduardo Júnior wrote:
> At least in my pathhad no sa-compile.
>
> But that's not important now.
> I did as recommended by colleagues above, correcting my mistakes and
> understanding the operation.
> Until had found odd repetition of files.
>
>
> But when I run sa-update, my list of rules is not updated and can now be
> used after restarted?
> I must compile the rules updated with sa-compile so they can be used?
>
there are (mainly) two set of rules:
- your own rules
- public rules
your own rules are those rules that you write yourself. these are not
updated by any SA tool. these are the rule that _you_ decide to
implement. these rules are generally found in $base/etc/spamassassin or
$base/etc/mail/spamassassin/.
the public rules are the ones that all of us have (whether we use
directly, we override, or not). at installation time, they are in an
installation directory ($base/share/spamassassin/). when you use
sa-update, the "original" ones are no more used and your SA will use the
updated ones.
if you use sa-update, the public rules are updated. and optionally, you
can get more rules. all these go to a new directory (generally
$datadir/spamassassin/).
once you update your rules, you can run sa-compile. some people do. some
don't.
Re: Sa-update
Posted by Eduardo Júnior <ih...@gmail.com>.
At least in my pathhad no sa-compile.
But that's not important now.
I did as recommended by colleagues above, correcting my mistakes and
understanding the operation.
Until had found odd repetition of files.
But when I run sa-update, my list of rules is not updated and can now be
used after restarted?
I must compile the rules updated with sa-compile so they can be used?
any reference
[]´s
On Fri, Jul 25, 2008 at 11:17 AM, Richard Frovarp <
richard.frovarp@sendit.nodak.edu> wrote:
> Kai Schaetzl wrote:
>
>> Eduardo Júnior wrote on Fri, 25 Jul 2008 08:58:25 -0300:
>>
>>
>>
>>> Peguei of the includes updates_spamassassin_org.cf and put in
>>> /etc/spamassassin/local.cf and I made a copy of my *. cf / etc /
>>> spamassassin to maintain consistently referenced in the path includes.
>>>
>>>
>>
>> Not sure what this means. You have to do *nothing* after an sa-update with
>> the exception of restarting spamd or whatever daemon application you are
>> using. In case you symlinked some stuff from /etc/mail/spamassassin to
>> /var/lib/spamassassin or reverse or copied some stuff over: this was wrong,
>> revert it.
>>
>> Kai
>>
>>
>>
> You may want to run sa-compile if the rules have changed. That is if you
> use sa-compile. Then restart whatever is using SA.
>
--
Eduardo Júnior
GNU/Linux user #423272
:wq
Re: Sa-update
Posted by Richard Frovarp <ri...@sendit.nodak.edu>.
Kai Schaetzl wrote:
> Eduardo Júnior wrote on Fri, 25 Jul 2008 08:58:25 -0300:
>
>
>> Peguei of the includes updates_spamassassin_org.cf and put in
>> /etc/spamassassin/local.cf and I made a copy of my *. cf / etc /
>> spamassassin to maintain consistently referenced in the path includes.
>>
>
> Not sure what this means. You have to do *nothing* after an sa-update with
> the exception of restarting spamd or whatever daemon application you are
> using. In case you symlinked some stuff from /etc/mail/spamassassin to
> /var/lib/spamassassin or reverse or copied some stuff over: this was
> wrong, revert it.
>
> Kai
>
>
You may want to run sa-compile if the rules have changed. That is if you
use sa-compile. Then restart whatever is using SA.
Re: Sa-update
Posted by Kai Schaetzl <ma...@conactive.com>.
Eduardo Júnior wrote on Fri, 25 Jul 2008 08:58:25 -0300:
> Peguei of the includes updates_spamassassin_org.cf and put in
> /etc/spamassassin/local.cf and I made a copy of my *. cf / etc /
> spamassassin to maintain consistently referenced in the path includes.
Not sure what this means. You have to do *nothing* after an sa-update with
the exception of restarting spamd or whatever daemon application you are
using. In case you symlinked some stuff from /etc/mail/spamassassin to
/var/lib/spamassassin or reverse or copied some stuff over: this was
wrong, revert it.
Kai
--
Kai Schätzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com