On Wed, 15 Jan 2020 07:55:59 +0200 Henrik K wrote: > On Tue, Jan 14, 2020 at 10:42:48PM +0000, > [email protected] 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 ... 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.
