Re: Local rules prefix

[John Hardin]

On Thu, 16 Jan 2020, RW wrote:


On Thu, 16 Jan 2020 17:47:32 -0500
Kevin A. McGrail wrote:


I'm fine with any PMC member who wants to create a wiki for this and
add code to the masscheck/qa to enforce that the stock rules won't
use some prefix.  I suggest LOCAL and __LOCAL so it's 100% clear.


The reason why I suggested L is that it's terse. The idea was to avoid
collisions without having to resort to long prefixes.


And there are length limits, at least by convention.

A useful compromise might be LCL_ and __LCL_

--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
 Tomorrow: Benjamin Franklin's 314th Birthday

Re: Local rules prefix

[RW]

On Thu, 16 Jan 2020 17:47:32 -0500
Kevin A. McGrail wrote:

> I'm fine with any PMC member who wants to create a wiki for this and
> add code to the masscheck/qa to enforce that the stock rules won't
> use some prefix.  I suggest LOCAL and __LOCAL so it's 100% clear.

The reason why I suggested L is that it's terse. The idea was to avoid
collisions without having to resort to long prefixes.

 

Re: Local rules prefix

[John Hardin]

On Thu, 16 Jan 2020, Michael Peddemors wrote:

Eg, we use __LM and __MM depending on what platform the rules are meant to be 
for..


However, maybe we 'should' consider ways for standardizing naming 
conventions, eg for any one building private rule sets for distribution.. eg, 
if one of our customer decided to also add someone else's private rule sets, 
and the person happened to be named 'Mighty Mouse'..


If an idea does surface, it should be good for all cases.

Long term, suggest that we build in something to the actual naming 
conventions somehow, that if it comes from anything other than the base 
upstream, somehow it gets auto_prefixed.. Just throwing the idea out.


The problem with auto-prefixing is it prevents *intentional* override of 
the base rules.


Is there a reliable way to distinguish between base rules and local rules? 
Using the path to the config file seems fragile...




On 2020-01-16 12:43 p.m., Kevin A. McGrail wrote:
I would recommend local rules are named based on your initials.  That's 
been the collision avoidance for nearly 2 decades.  Does that not solve the 
issue at hand?


On Thu, Jan 16, 2020, 14:53 John Hardin > wrote:


On Thu, 16 Jan 2020, RW wrote:

 > On Thu, 16 Jan 2020 17:37:48 +0200
 > Henrik K wrote:
 >
 >> On Thu, Jan 16, 2020 at 03:03:40PM +, RW wrote:
 >>>
  It would seem more productive to actually make spamassassin 
--lint

  output info messages (not errors) when rules are redefined.  And
  perhaps add a new tflag "redefine" (suggestions?) to suppress
  those warnings for intentional redefines.
 >>>
 >>> That requires actual coding, and it only partially works.
 >>>
 >>> Let's say I have local rules:
 >>>
 >>> body  __FOO ...
 >>> meta  FOO   __FOO ...
 >>> score FOO  0.001
 >>>
 >>> and then in the middle of the night sa-learn downloads new rules:
 >>>
 >>> header  __FOO ...
 >>> meta    BAR   __FOO ...
 >>> score   BAR  3.0
 >>>
 >>> My high-FP informational version of __FOO then gets used in
place of
 >>> the core version in a high scoring meta rule.
 >>
 >> And --lint would say
 >>
 >> Notice: rule __FOO redefined, check what's going on or use tflags
 >> redefine
 >
 > And that would only be noticed after the FPs.

+1



--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  Judicial Activism (n): interpreting the Constitution to grant the
  government powers that are popularly felt to be "needed" but that
  are not explicitly provided for therein (common definition);
  interpreting the Constitution as it is written (Brady definition)
---
 Tomorrow: Benjamin Franklin's 314th Birthday

Re: Local rules prefix

[Kevin A. McGrail]

I'm fine with any PMC member who wants to create a wiki for this and add
code to the masscheck/qa to enforce that the stock rules won't use some
prefix.  I suggest LOCAL and __LOCAL so it's 100% clear.
--
Kevin A. McGrail
Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171


On Thu, Jan 16, 2020 at 4:55 PM Michael Peddemors 
wrote:

> Eg, we use __LM and __MM depending on what platform the rules are meant
> to be for..
>
> However, maybe we 'should' consider ways for standardizing naming
> conventions, eg for any one building private rule sets for
> distribution.. eg, if one of our customer decided to also add someone
> else's private rule sets, and the person happened to be named 'Mighty
> Mouse'..
>
> If an idea does surface, it should be good for all cases.
>
> Long term, suggest that we build in something to the actual naming
> conventions somehow, that if it comes from anything other than the base
> upstream, somehow it gets auto_prefixed.. Just throwing the idea out.
>
> On 2020-01-16 12:43 p.m., Kevin A. McGrail wrote:
> > I would recommend local rules are named based on your initials.  That's
> > been the collision avoidance for nearly 2 decades.  Does that not solve
> > the issue at hand?
> >
> > On Thu, Jan 16, 2020, 14:53 John Hardin  > > wrote:
> >
> > On Thu, 16 Jan 2020, RW wrote:
> >
> >  > On Thu, 16 Jan 2020 17:37:48 +0200
> >  > Henrik K wrote:
> >  >
> >  >> On Thu, Jan 16, 2020 at 03:03:40PM +, RW wrote:
> >  >>>
> >   It would seem more productive to actually make spamassassin
> --lint
> >   output info messages (not errors) when rules are redefined.
> And
> >   perhaps add a new tflag "redefine" (suggestions?) to suppress
> >   those warnings for intentional redefines.
> >  >>>
> >  >>> That requires actual coding, and it only partially works.
> >  >>>
> >  >>> Let's say I have local rules:
> >  >>>
> >  >>> body  __FOO ...
> >  >>> meta  FOO   __FOO ...
> >  >>> score FOO  0.001
> >  >>>
> >  >>> and then in the middle of the night sa-learn downloads new
> rules:
> >  >>>
> >  >>> header  __FOO ...
> >  >>> metaBAR   __FOO ...
> >  >>> score   BAR  3.0
> >  >>>
> >  >>> My high-FP informational version of __FOO then gets used in
> > place of
> >  >>> the core version in a high scoring meta rule.
> >  >>
> >  >> And --lint would say
> >  >>
> >  >> Notice: rule __FOO redefined, check what's going on or use tflags
> >  >> redefine
> >  >
> >  > And that would only be noticed after the FPs.
> >
> > +1
> >
> > --
> >John Hardin KA7OHZ http://www.impsec.org/~jhardin/
> > jhar...@impsec.org FALaholic #11174
> > pgpk -a jhar...@impsec.org 
> >key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873
> 2E79
> >
>  ---
> > People that keep dreaming about the wasteland, labyrinths and
> > quick cash, die in amusing ways. -- Root the
> Dragon
> >
>  ---
> >Tomorrow: Benjamin Franklin's 314th Birthday
> >
>
>
>
> --
> "Catch the Magic of Linux..."
> 
> Michael Peddemors, President/CEO LinuxMagic Inc.
> Visit us at http://www.linuxmagic.com @linuxmagic
> A Wizard IT Company - For More Info http://www.wizard.ca
> "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
> 
> 604-682-0300 Beautiful British Columbia, Canada
>
> This email and any electronic data contained are confidential and intended
> solely for the use of the individual or entity to which they are addressed.
> Please note that any views or opinions presented in this email are solely
> those of the author and are not intended to represent those of the company.
>

Re: Local rules prefix

[Michael Peddemors]

Eg, we use __LM and __MM depending on what platform the rules are meant 
to be for..


However, maybe we 'should' consider ways for standardizing naming 
conventions, eg for any one building private rule sets for 
distribution.. eg, if one of our customer decided to also add someone 
else's private rule sets, and the person happened to be named 'Mighty 
Mouse'..


If an idea does surface, it should be good for all cases.

Long term, suggest that we build in something to the actual naming 
conventions somehow, that if it comes from anything other than the base 
upstream, somehow it gets auto_prefixed.. Just throwing the idea out.


On 2020-01-16 12:43 p.m., Kevin A. McGrail wrote:
I would recommend local rules are named based on your initials.  That's 
been the collision avoidance for nearly 2 decades.  Does that not solve 
the issue at hand?


On Thu, Jan 16, 2020, 14:53 John Hardin > wrote:


On Thu, 16 Jan 2020, RW wrote:

 > On Thu, 16 Jan 2020 17:37:48 +0200
 > Henrik K wrote:
 >
 >> On Thu, Jan 16, 2020 at 03:03:40PM +, RW wrote:
 >>>
  It would seem more productive to actually make spamassassin --lint
  output info messages (not errors) when rules are redefined.  And
  perhaps add a new tflag "redefine" (suggestions?) to suppress
  those warnings for intentional redefines.
 >>>
 >>> That requires actual coding, and it only partially works.
 >>>
 >>> Let's say I have local rules:
 >>>
 >>> body  __FOO ...
 >>> meta  FOO   __FOO ...
 >>> score FOO  0.001
 >>>
 >>> and then in the middle of the night sa-learn downloads new rules:
 >>>
 >>> header  __FOO ...
 >>> meta    BAR   __FOO ...
 >>> score   BAR  3.0
 >>>
 >>> My high-FP informational version of __FOO then gets used in
place of
 >>> the core version in a high scoring meta rule.
 >>
 >> And --lint would say
 >>
 >> Notice: rule __FOO redefined, check what's going on or use tflags
 >> redefine
 >
 > And that would only be noticed after the FPs.

+1

-- 
   John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhar...@impsec.org     FALaholic #11174 
    pgpk -a jhar...@impsec.org 

   key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
    People that keep dreaming about the wasteland, labyrinths and
    quick cash, die in amusing ways.                 -- Root the Dragon
---
   Tomorrow: Benjamin Franklin's 314th Birthday





--
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

Re: Local rules prefix

[John Hardin]

On Thu, 16 Jan 2020, Kevin A. McGrail wrote:


I would recommend local rules are named based on your initials.  That's
been the collision avoidance for nearly 2 decades.  Does that not solve the
issue at hand?


Well, not really, because the local rules we're concerned about are at the 
various individual sites.


We don't publish any *documented* guidance for local rule naming, we've 
just been relying on common sense and seeing how others do it. This is 
more "we should document this to try to avoid problems", and reserving the 
"L_" and "__L_" prefixes for that purpose with a guarantee that the base 
rules will never use them (potentially with build process enforcement).


--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  Public Education: the bureaucratic process of replacing
  an empty mind with a closed one.  -- Thorax
---
 Tomorrow: Benjamin Franklin's 314th Birthday

Re: Local rules prefix

[Henrik K]

There is no issue.  I have never read about an issue on the lists.  But
apparently there might be an issue if we don't come up with a standard
naming...  so..  yeah..

On Thu, Jan 16, 2020 at 03:43:10PM -0500, Kevin A. McGrail wrote:
> I would recommend local rules are named based on your initials.  That's been
> the collision avoidance for nearly 2 decades.  Does that not solve the issue 
> at
> hand?
> 
> On Thu, Jan 16, 2020, 14:53 John Hardin <[1]jhar...@impsec.org> wrote:
> 
> On Thu, 16 Jan 2020, RW wrote:
> 
> > On Thu, 16 Jan 2020 17:37:48 +0200
> > Henrik K wrote:
> >
> >> On Thu, Jan 16, 2020 at 03:03:40PM +, RW wrote:
> >>>
>  It would seem more productive to actually make spamassassin --lint
>  output info messages (not errors) when rules are redefined.  And
>  perhaps add a new tflag "redefine" (suggestions?) to suppress
>  those warnings for intentional redefines.
> >>>
> >>> That requires actual coding, and it only partially works.
> >>>
> >>> Let's say I have local rules:
> >>>
> >>> body  __FOO ...
> >>> meta  FOO   __FOO ...
> >>> score FOO  0.001
> >>>
> >>> and then in the middle of the night sa-learn downloads new rules:
> >>>
> >>> header  __FOO ...
> >>> meta    BAR   __FOO ...
> >>> score   BAR  3.0
> >>>
> >>> My high-FP informational version of __FOO then gets used in place of
> >>> the core version in a high scoring meta rule.
> >>
> >> And --lint would say
> >>
> >> Notice: rule __FOO redefined, check what's going on or use tflags
> >> redefine
> >
> > And that would only be noticed after the FPs.
> 
> +1
> 
> --
>   John Hardin KA7OHZ                    [2]http://www.impsec.org/~jhardin/
>   [3]jhar...@impsec.org    FALaholic #11174     pgpk -a [4]
> jhar...@impsec.org
>   key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
> ---
>    People that keep dreaming about the wasteland, labyrinths and
>    quick cash, die in amusing ways.                 -- Root the Dragon
> ---
>   Tomorrow: Benjamin Franklin's 314th Birthday
> 
> 
> References:
> 
> [1] mailto:jhar...@impsec.org
> [2] http://www.impsec.org/~jhardin/
> [3] mailto:jhar...@impsec.org
> [4] mailto:jhar...@impsec.org

Re: Local rules prefix

[Kevin A. McGrail]

I would recommend local rules are named based on your initials.  That's
been the collision avoidance for nearly 2 decades.  Does that not solve the
issue at hand?

On Thu, Jan 16, 2020, 14:53 John Hardin  wrote:

> On Thu, 16 Jan 2020, RW wrote:
>
> > On Thu, 16 Jan 2020 17:37:48 +0200
> > Henrik K wrote:
> >
> >> On Thu, Jan 16, 2020 at 03:03:40PM +, RW wrote:
> >>>
>  It would seem more productive to actually make spamassassin --lint
>  output info messages (not errors) when rules are redefined.  And
>  perhaps add a new tflag "redefine" (suggestions?) to suppress
>  those warnings for intentional redefines.
> >>>
> >>> That requires actual coding, and it only partially works.
> >>>
> >>> Let's say I have local rules:
> >>>
> >>> body  __FOO ...
> >>> meta  FOO   __FOO ...
> >>> score FOO  0.001
> >>>
> >>> and then in the middle of the night sa-learn downloads new rules:
> >>>
> >>> header  __FOO ...
> >>> metaBAR   __FOO ...
> >>> score   BAR  3.0
> >>>
> >>> My high-FP informational version of __FOO then gets used in place of
> >>> the core version in a high scoring meta rule.
> >>
> >> And --lint would say
> >>
> >> Notice: rule __FOO redefined, check what's going on or use tflags
> >> redefine
> >
> > And that would only be noticed after the FPs.
>
> +1
>
> --
>   John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
>   jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
>   key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
> ---
>People that keep dreaming about the wasteland, labyrinths and
>quick cash, die in amusing ways. -- Root the Dragon
> ---
>   Tomorrow: Benjamin Franklin's 314th Birthday
>

Re: Local rules prefix

[John Hardin]

On Thu, 16 Jan 2020, RW wrote:


On Thu, 16 Jan 2020 17:37:48 +0200
Henrik K wrote:


On Thu, Jan 16, 2020 at 03:03:40PM +, RW wrote:



It would seem more productive to actually make spamassassin --lint
output info messages (not errors) when rules are redefined.  And
perhaps add a new tflag "redefine" (suggestions?) to suppress
those warnings for intentional redefines.


That requires actual coding, and it only partially works.

Let's say I have local rules:

body  __FOO ...
meta  FOO   __FOO ...
score FOO  0.001

and then in the middle of the night sa-learn downloads new rules:

header  __FOO ...
metaBAR   __FOO ...
score   BAR  3.0

My high-FP informational version of __FOO then gets used in place of
the core version in a high scoring meta rule.


And --lint would say

Notice: rule __FOO redefined, check what's going on or use tflags
redefine


And that would only be noticed after the FPs.


+1

--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  People that keep dreaming about the wasteland, labyrinths and
  quick cash, die in amusing ways. -- Root the Dragon
---
 Tomorrow: Benjamin Franklin's 314th Birthday

Re: Local rules prefix

[Henrik K]

On Thu, Jan 16, 2020 at 04:42:35PM +, RW wrote:
> > And --lint would say
> > 
> > Notice: rule __FOO redefined, check what's going on or use tflags
> > redefine
> 
> And that would only be noticed after the FPs. 

Depends how sa-update is run.  I get STDERR mailed to me from cron.

Re: Local rules prefix

[RW]

On Thu, 16 Jan 2020 17:37:48 +0200
Henrik K wrote:

> On Thu, Jan 16, 2020 at 03:03:40PM +, RW wrote:
> >
> > > It would seem more productive to actually make spamassassin --lint
> > > output info messages (not errors) when rules are redefined.  And
> > > perhaps add a new tflag "redefine" (suggestions?) to suppress
> > > those warnings for intentional redefines.  
> > 
> > That requires actual coding, and it only partially works. 
> > 
> > Let's say I have local rules:
> > 
> > body  __FOO ...
> > meta  FOO   __FOO ...
> > score FOO  0.001
> > 
> > and then in the middle of the night sa-learn downloads new rules:
> > 
> > header  __FOO ...
> > metaBAR   __FOO ...
> > score   BAR  3.0
> > 
> > My high-FP informational version of __FOO then gets used in place of
> > the core version in a high scoring meta rule.  
> 
> And --lint would say
> 
> Notice: rule __FOO redefined, check what's going on or use tflags
> redefine

And that would only be noticed after the FPs. 

 
> I'm not sure what you mean by "partially" working?  

Because half the time it's only noticed after the FPs.

Re: 3.4 "EOL" status

[Giovanni Bechis]

On 1/15/20 3:18 PM, Henrik K wrote:
> On Wed, Jan 15, 2020 at 08:57:21AM -0500, Kevin A. McGrail wrote:
>> Yeah, I retract the EOL statement.  We have 3.4 in serious bugfixes only mode
>> and hopefully this week.we can get the svn 4.0 branching done.
>>
>> Can you fix the fromnamespoof plugin regex for 5.8.8 compatibility and revert
>> the INSTALL to the previous text?
> 
> I'll let Giovanni look at why the possessive quantifier is there..  my head
> hurts trying to understand what's going on here :-D
> 
>   if ($fnd{'addr'} =~ 
> /\b([\w\.\!\#\$\%\&\'\*\+\/\=\?\^\_\`\{\|\}\~\-]+@[\w\-\.]+\.[\w\-\.]++)\b/i) 
> {
> my $nochar = ($fnd{'addr'} =~ y/A-Za-z0-9//c);
> $nochar -= ($1 =~ y/A-Za-z0-9//c);
> 
> return 0 unless ((length($fnd{'addr'})+$nochar) - length($1) <= 
> $conf->{'fns_extrachars'});
> 
> $fnd{'addr'} = lc $1;
> 
>> I will work on rolling a 3.4.4 this week and maybe even a 4.0.0pre1 next week
>> so people can start testing that.
>>
This works on 5.8.8, not sure about all the regexp bits though.

>> Then we can agree to start saying EOL a year after the first 4.0 release?
> 
> Sure.
> 
> There is bunch of stuff in bugzilla that's supposed to go to 4.0 though. 
> But I don't think there is anything lacking or needing immediate attention
> in trunk, so we could just retarget all future improvements to 4.1 and say
> that IDN support etc is much better, but still subject to be improved etc..
> 

Index: lib/Mail/SpamAssassin/Plugin/FromNameSpoof.pm
===
--- lib/Mail/SpamAssassin/Plugin/FromNameSpoof.pm	(revision 1872882)
+++ lib/Mail/SpamAssassin/Plugin/FromNameSpoof.pm	(working copy)
@@ -262,7 +262,9 @@
   my ($self, $pms, $check_lvl) = @_;
   $self->_check_fromnamespoof($pms);
 
-  $check_lvl //= $pms->{conf}->{fns_check};
+  if ( not defined $check_lvl ) {
+$check_lvl = $pms->{conf}->{fns_check};
+  }
 
   my @array = (
 ($pms->{fromname_address_different}) ,
@@ -348,7 +350,7 @@
 
   $fnd{'addr'} = $pms->get("From:name");
 
-  if ($fnd{'addr'} =~ /\b([\w\.\!\#\$\%\&\'\*\+\/\=\?\^\_\`\{\|\}\~\-]+@[\w\-\.]+\.[\w\-\.]++)\b/i) {
+  if ($fnd{'addr'} =~ /\b((?>[\w\.\!\#\$\%\&\'\*\+\/\=\?\^\_\`\{\|\}\~\-]+@[\w\-\.]+\.[\w\-\.]+))\b/i) {
 my $nochar = ($fnd{'addr'} =~ y/A-Za-z0-9//c);
 $nochar -= ($1 =~ y/A-Za-z0-9//c);
 

Re: Local rules prefix

[Henrik K]

On Thu, Jan 16, 2020 at 03:03:40PM +, RW wrote:
>  
> > It would seem more productive to actually make spamassassin --lint
> > output info messages (not errors) when rules are redefined.  And
> > perhaps add a new tflag "redefine" (suggestions?) to suppress those
> > warnings for intentional redefines.
> 
> That requires actual coding, and it only partially works. 
> 
> Let's say I have local rules:
> 
> body  __FOO ...
> meta  FOO   __FOO ...
> score FOO  0.001
> 
> and then in the middle of the night sa-learn downloads new rules:
> 
> header  __FOO ...
> metaBAR   __FOO ...
> score   BAR  3.0
> 
> My high-FP informational version of __FOO then gets used in place of
> the core version in a high scoring meta rule.

And --lint would say

Notice: rule __FOO redefined, check what's going on or use tflags redefine

I'm not sure what you mean by "partially" working?  It's something that user
needs to look into.  We can't fail lint because of that.  And there are
always 95% of users that don't read documentation or any announces, no
matter how much we suggest that use __L or whatever in your rules.

Re: Local rules prefix

[RW]

On Wed, 15 Jan 2020 07:55:59 +0200
Henrik K wrote:

> On Tue, Jan 14, 2020 at 10:42:48PM +,
> bugzilla-dae...@spamassassin.apache.org wrote:
> > https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7366
> > (In reply to RW from comment #8)  
> > > It's not about anyone seeing them, it's about avoiding name
> > > collisions between the core rules and local rules. At the moment
> > > there's no standard way of doing this. Someone people use long
> > > prefixes, but these reduce readability and bloat meta-rules. And
> > > there's no guarantee that someone wont pick the same prefix and
> > > contribute their rules to core.
> > > 
> > > L_  seems like the ideal candidate for a reserved prefix.  
> > 
> > Along with __L_ for subrules.
> > 
> > +1 from me. We can even add build tooling to ensure none such ever
> > get added to the base rules.  
> 
> Guys please continue on list.
> 
> If you want some L_ policy that's fine.  Not something I personally
> would use.

I doubt I would as as I've already gone too far down the route of
not caring, but there is a lot of advocacy for local prefixes.

 
> It would seem more productive to actually make spamassassin --lint
> output info messages (not errors) when rules are redefined.  And
> perhaps add a new tflag "redefine" (suggestions?) to suppress those
> warnings for intentional redefines.

That requires actual coding, and it only partially works. 

Let's say I have local rules:

body  __FOO ...
meta  FOO   __FOO ...
score FOO  0.001

and then in the middle of the night sa-learn downloads new rules:

header  __FOO ...
metaBAR   __FOO ...
score   BAR  3.0

My high-FP informational version of __FOO then gets used in place of
the core version in a high scoring meta rule.

Rule updates are too old - 2020-01-16 3.3.0:2020-01-15 3.3.1:2020-01-15 3.3.2:2020-01-15

[darxus]

SpamAssassin version 3.3.0 has not had a rule update since 2020-01-15.
SpamAssassin version 3.3.1 has not had a rule update since 2020-01-15.
SpamAssassin version 3.3.2 has not had a rule update since 2020-01-15.

20200115:  Spam and ham are above threshold of 150,000:  
http://ruleqa.spamassassin.org/?daterev=20200115
20200115:  Spam: 793325, Ham: 864630


The spam and ham counts on which this script alerts are from
http://ruleqa.spamassassin.org/?daterev=20200115
Click "(source details)" (it's tiny and low contrast).
It's from the second and third columns of the line that ends with
"(all messages)"

The source to this script is
http://www.chaosreigns.com/sa/update-version-mon.pl

It looks like both the weekly and nightly masschecks need to have sufficient
corpora in order for an update to be generated.