Sa-update - SpamAssassin

This is a discussion on Sa-update - SpamAssassin ; 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 ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: Sa-update

  1. 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


  2. Re: Sa-update

    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 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


  3. Re: Sa-update

    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


  4. Re: Sa-update

    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.


  5. Re: Sa-update

    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


  6. Re: Sa-update

    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.


  7. Re: Sa-update

    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
    > 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.

    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.


  8. Re: Sa-update

    On Fri, Jul 25, 2008 at 8:39 PM, Matt Kettler 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
    >> 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


  9. Re: Sa-update

    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 wrote:

    >
    >
    > On Fri, Jul 25, 2008 at 8:39 PM, Matt Kettler 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
    >>> 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 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


  10. Re: Sa-update

    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.


+ Reply to Thread