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.
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 a
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
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 from keeping your
> expiring
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 ex
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, temporar
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 auto-purged.
> - it's clear whic
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 separ
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 all do things slightly differe
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 way
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
> This seems sub-optimal to
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 no
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 usu
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 ru
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 ef
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 able to
>>> expire
>>> r
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 case for this would
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 that others depend o
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
r
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 check for that and make
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 non-expiring (with a
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 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 mat
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 wo
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" wrote:
>
> > Brilliant id
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 out by
removing the 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.
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,
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:
expir
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 MY
30 matches
Mail list logo
