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

Re: version 3.4.1 with block TLD

> On Jun 12, 2017, at 9:44 PM, Joseph Brennan wrote: > > > > --On June 8, 2017 at 12:07:43 PM -0400 Robert Kudyba > wrote: > > I would like >> to block *@*.us but allow the cities and schools that use them so allow >> examples like