Re: Feature idea: Expiring rules

On Thu, 15 Jun 2017 10:44:03 -0400 Dianne Skoll wrote: > Hi, Kevin, I did not realize I was replying to the list. :P Newbie mistake... Anyway, this is for the list. Feature idea is up at https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7436 Regards, Dianne.

Re: Feature idea: Expiring rules

Hi, Kevin, > Diane, I'd appreciate if you would synopsize things to the best of > what you see from the conversation and add it as a feature request in > bugzilla bug. https://bz.apache.org/SpamAssassin/ Sure. I've forgotten my Bugzilla password, so just waiting for the reset token to arrive

Re: Feature idea: Expiring rules

Diane, I'd appreciate if you would synopsize things to the best of what you see from the conversation and add it as a feature request in bugzilla bug. https://bz.apache.org/SpamAssassin/ If you have even a rough framework patch to start, that will help too. And yes, I'm aware there are a lot

Re: Feature idea: Expiring rules

On Wed, 14 Jun 2017 08:43:40 -0400 Dianne Skoll wrote: > On Wed, 14 Jun 2017 13:38:49 +0100 > RW wrote: > > > The way I suggested has advantages: > > > - there's no need to clean-out expired rules manually > > A minor advantage at best. And nothing stops you

Re: Feature idea: Expiring rules

On Wed, 14 Jun 2017 13:52:12 +0100 RW wrote: > On Wed, 14 Jun 2017 13:38:49 +0100 > RW wrote: > > > On Tue, 13 Jun 2017 22:06:12 -0400 > > Dianne Skoll wrote: > > > > > > > Why not do it properly, > > > > The way I suggested has advantages: > > > > - there's no need to clean-out

Re: Feature idea: Expiring rules

On Wed, 14 Jun 2017 13:38:49 +0100 RW wrote: > On Tue, 13 Jun 2017 22:06:12 -0400 > Dianne Skoll wrote: > > > > Why not do it properly, > > The way I suggested has advantages: > > - there's no need to clean-out expired rules manually > - it's clear which rules are permanent,

Re: Feature idea: Expiring rules

On Wed, 14 Jun 2017 13:38:49 +0100 RW wrote: > The way I suggested has advantages: > - there's no need to clean-out expired rules manually A minor advantage at best. And nothing stops you from keeping your expiring rules in a separate .cf file so they can be

Re: Feature idea: Expiring rules

On Tue, 13 Jun 2017 22:06:12 -0400 Dianne Skoll wrote: > Why not do it properly, once, so everyone can benefit? The way I suggested has advantages: - there's no need to clean-out expired rules manually - it's clear which rules are permanent, temporary and expired - grep can easily

Re: Feature idea: Expiring rules

On Wed, 14 Jun 2017 00:52:15 +0100 RW wrote: > If you want it to work that way it can be done in an external script > in about 10 lines. *SIGH* Yes. I'm perfectly aware of that. My point is that we can have hundreds of sysadmins writing hacky little scripts that

Re: Feature idea: Expiring rules

On Tue, 13 Jun 2017 18:15:50 -0400 Dianne Skoll wrote: If you make a rule that you *know* will be effective for a > pretty limited timespan, setting the expiry at the time of creation > seems more efficient to me than having to remember to go back and > expire it. If you want it to work that

Re: Feature idea: Expiring rules

On Tue, 13 Jun 2017 23:10:25 +0100 RW wrote: > Then why not write a script to parse your logs and determine when that > happens. Because that's more work, and I'm lazy, just like all true sysadmins. > > What if we did something like: > > expire MYRULE_FOO 2017-09-01

Re: Feature idea: Expiring rules

On Tue, 13 Jun 2017 11:39:10 -0400 Dianne Skoll wrote: > Hi, > > Something I and possibly others might find useful would be rules that > expire. Quite often, we might make some very specific rules to handle > a particular spam run and they lose their effectiveness pretty > quickly. Then why

Re: Feature idea: Expiring rules

On Tue, 13 Jun 2017, Bowie Bailey wrote: On 6/13/2017 3:53 PM, Dianne Skoll wrote: 2) If a rule has an expiry set and then is used to build a meta rule, then the expiry is ignored and the parser issues a warning or even a fatal error. I'm partial to the fatal error because warnings are

Re: Feature idea: Expiring rules

On 6/13/2017 3:53 PM, Dianne Skoll wrote: 2) If a rule has an expiry set and then is used to build a meta rule, then the expiry is ignored and the parser issues a warning or even a fatal error. I'm partial to the fatal error because warnings are usually ignored. :) Or require that the meta

Re: Feature idea: Expiring rules

Kevin A. McGrail skrev den 2017-06-13 21:45: On 6/13/2017 3:38 PM, Noel wrote: Maybe expired rules could automatically score as 0.01 rather than invalid. Then log a warning to remind the admin. I think that would defeat the purpose since the goal is likely to make the core engine run more

Re: Feature idea: Expiring rules

On 6/13/2017 2:45 PM, John Hardin wrote: > On Tue, 13 Jun 2017, Noel wrote: > >> On 6/13/2017 12:10 PM, Dianne Skoll wrote: >>> On Tue, 13 Jun 2017 08:59:27 -0700 (PDT) >>> John Hardin wrote: >>> Dependencies. >>> Yes, that would mess things up. Probably shouldn't be

Re: Feature idea: Expiring rules

On Tue, 13 Jun 2017 14:38:21 -0500 Noel wrote: > Maybe expired rules could automatically score as 0.01 rather than > invalid. Then log a warning to remind the admin. No, I don't like that. As others mentioned, that does nothing for dependent rules. I think a sensible use

Re: Feature idea: Expiring rules

On Tue, 2017-06-13 at 14:38 -0500, Noel wrote: > On 6/13/2017 12:10 PM, Dianne Skoll wrote: > > On Tue, 13 Jun 2017 08:59:27 -0700 (PDT) > > John Hardin wrote: > > > > > Dependencies. > > > > Yes, that would mess things up.  Probably shouldn't be able to > > expire > > rules

Re: Feature idea: Expiring rules

On 6/13/2017 3:38 PM, Noel wrote: Maybe expired rules could automatically score as 0.01 rather than invalid. Then log a warning to remind the admin. I think that would defeat the purpose since the goal is likely to make the core engine run more efficiently for RDJ items that are no longer

Re: Feature idea: Expiring rules

On Tue, 13 Jun 2017, Noel wrote: On 6/13/2017 12:10 PM, Dianne Skoll wrote: On Tue, 13 Jun 2017 08:59:27 -0700 (PDT) John Hardin wrote: Dependencies. Yes, that would mess things up. Probably shouldn't be able to expire rules that others depend on. The parser could

Re: Feature idea: Expiring rules

On 6/13/2017 12:10 PM, Dianne Skoll wrote: > On Tue, 13 Jun 2017 08:59:27 -0700 (PDT) > John Hardin wrote: > >> Dependencies. > Yes, that would mess things up. Probably shouldn't be able to expire > rules that others depend on. The parser could check for that and make > them

Re: Feature idea: Expiring rules

On Tue, 13 Jun 2017, Dianne Skoll wrote: Hi, Something I and possibly others might find useful would be rules that expire. Quite often, we might make some very specific rules to handle a particular spam run and they lose their effectiveness pretty quickly. I would love this for private

Re: Feature idea: Expiring rules

On Tue, 13 Jun 2017, Kevin A. McGrail wrote: On 6/13/2017 1:13 PM, Dianne Skoll wrote: > Brilliant idea but how to keep that information from spammers? Would it matter? Especially for private site rules. I wouldn't advocate this for centrally-distributed rules I don't think it would

Re: Feature idea: Expiring rules

On 6/13/2017 1:13 PM, Dianne Skoll wrote: Brilliant idea but how to keep that information from spammers? Would it matter? Especially for private site rules. I wouldn't advocate this for centrally-distributed rules, which are in any event expired out by removing the rules. I don't think it

Re: Feature idea: Expiring rules

Our company does something similar with external scripts that we wrote. Our small but powerful internal RBL works somewhat the same way. Very useful. --Bryan On Tue, Jun 13, 2017 at 1:13 PM, Dianne Skoll wrote: > On Tue, 13 Jun 2017 11:56:57 -0400 > "Kevin A. McGrail"

Re: Feature idea: Expiring rules

On Tue, 13 Jun 2017 11:56:57 -0400 "Kevin A. McGrail" wrote: > Brilliant idea but how to keep that information from spammers? Would it matter? Especially for private site rules. I wouldn't advocate this for centrally-distributed rules, which are in any event expired

Re: Feature idea: Expiring rules

On Tue, 13 Jun 2017 08:59:27 -0700 (PDT) John Hardin wrote: > Dependencies. Yes, that would mess things up. Probably shouldn't be able to expire rules that others depend on. The parser could check for that and make them non-expiring (with a warning.) Regards, Dianne.

Re: Feature idea: Expiring rules

Kevin A. McGrail skrev den 2017-06-13 17:56: I've been thinking a lot about hive protection on rules and centralizing this type of data. i will like to go the other way around, make spamassassin rules more decentraly, with feks ip repution, and uri repution based on maybe to see dmarc pass,

Re: Feature idea: Expiring rules

On Tue, 13 Jun 2017, Dianne Skoll wrote: Hi, Something I and possibly others might find useful would be rules that expire. Quite often, we might make some very specific rules to handle a particular spam run and they lose their effectiveness pretty quickly. What if we did something like:

Re: Feature idea: Expiring rules

On 6/13/2017 11:39 AM, Dianne Skoll wrote: Something I and possibly others might find useful would be rules that expire. Quite often, we might make some very specific rules to handle a particular spam run and they lose their effectiveness pretty quickly. What if we did something like: expire

Feature idea: Expiring rules

Hi, Something I and possibly others might find useful would be rules that expire. Quite often, we might make some very specific rules to handle a particular spam run and they lose their effectiveness pretty quickly. What if we did something like: expire MYRULE_FOO 2017-09-01 or maybe tflags