https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
Henrik Krohns changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #93 from Kevin A. McGrail ---
+1 from me too because Wolfgang's initial discovery, the subsequent testing,
and the patch work from Henrik look good.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #92 from Bill Cole ---
+1 to commit.
I'm slightly uneasy about my (shallow) depth of understanding of this issue,
but I trust those with a deeper understanding and really want to get 4.0
released.
--
You are receiving this
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #91 from Henrik Krohns ---
I guess let's vote on the patch then. +1
Note that I did one small if tweak, $mp to $mt
if (!exists $mp->{$deprule}) {
-->
if (!exists $mt->{$deprule}) {
Basically it's the exact same result and
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #90 from Wolfgang Breyha ---
Looking at the plain results that looks good. Same score and same
(Total Subtest Hits: 208 / Deduplicated Total Hits: 133)
I also added a dbg output to the loop so it looks like
foreach my
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #89 from Henrik Krohns ---
Created attachment 5855
--> https://bz.apache.org/SpamAssassin/attachment.cgi?id=5855=edit
Meta patch for r1905203, fix finishing metas
^ You are very right.. I already finished a quick patch that
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #88 from Wolfgang Breyha ---
Just brainstorming...
At the point the do_meta_rules()/finish_meta_rules() block is reached:
If all unavailable non-meta rules/tags are set to a "0" result before that
point shouldn't that clear
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
Henrik Krohns changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #86 from Wolfgang Breyha ---
regarding the revert... sorry, my fault. The part in Check.pm was moved up (out
of my sight).
regarding the new troubles:
With my new sample I again see a lot of meta rules delayed to the point
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #85 from Henrik Krohns ---
(In reply to Wolfgang Breyha from comment #84)
> I noticed that the "revert" patch in comment 71
> also reverted parts (but not all) of the fix for #8060. Was this intentional?
Not sure what you are
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #84 from Wolfgang Breyha ---
I noticed that the "revert" patch in comment 71
also reverted parts (but not all) of the fix for #8060. Was this intentional?
And I'm sorry to say that I'm currently struggling with another sample
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
Henrik Krohns changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #82 from Bill Cole ---
+1 to commit latest fix.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #81 from Giovanni Bechis ---
(In reply to Henrik Krohns from comment #80)
> (In reply to Henrik Krohns from comment #76)
> >
> > --- lib/Mail/SpamAssassin/Plugin/Check.pm (revision 1905124)
> > +++
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #80 from Henrik Krohns ---
(In reply to Henrik Krohns from comment #76)
>
> --- lib/Mail/SpamAssassin/Plugin/Check.pm (revision 1905124)
> +++ lib/Mail/SpamAssassin/Plugin/Check.pm (working copy)
> @@ -316,7 +316,7
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #79 from Wolfgang Breyha ---
Calling rule_ready() looks good and achieves the same results as my changes.
I see you added the call to do_meta_tests() in front of finish_meta_tests() as
well in October with the patch for #8061.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #78 from Henrik Krohns ---
(In reply to Wolfgang Breyha from comment #77)
>
> IMO finish_meta_tests() fails to rerun rules if dependencies are resolved
> later in the loop... but reading the comments in the code it tries at
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #77 from Wolfgang Breyha ---
I will try it ASAP.
But even if it achieves the same as my patch I think this is not enough to
guarantee that meta rules are always run with as much dependencies resolved as
possible. This fix
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
Henrik Krohns changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #75 from Wolfgang Breyha ---
I checked out rev 1905124 today, built a local package and tried to test it
with some of my test E-Mails I used before.
I compared the results with my currently running 4.0-rc3 with the patches
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
Henrik Krohns changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #73 from Kevin A. McGrail ---
I have not tested it but I've reviewed it and +1 to commit Meta patch for
r1904929, revert to old logic so we can get it into trunk. We'll then look to
test.
--
You are receiving this mail
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
Giovanni Bechis changed:
What|Removed |Added
CC||giova...@paclan.it
--- Comment
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #71 from Henrik Krohns ---
Created attachment 5854
--> https://bz.apache.org/SpamAssassin/attachment.cgi?id=5854=edit
Meta patch for r1904929, revert to old logic
Here's patch to revert to old meta logic. Basically just
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #70 from Henrik Krohns ---
I think Bill summed it up quite nicely. There's some agreement happening, so
I'll start tuning things to the way of old logic. Nothing is going to waste, as
the new code will still help make metas run
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
Bill Cole changed:
What|Removed |Added
CC||billc...@apache.org
--- Comment #69
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
Loren Wilton changed:
What|Removed |Added
CC|lwil...@earthlink.net |
--
You are receiving this mail
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #68 from Loren Wilton ---
(In reply to Kevin A. McGrail from comment #66)
> So I believe the new logic is trying to be efficient and not run rules that
> are unnecessary.
I believe the change was done more for proper rule
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #67 from Loren Wilton ---
(In reply to Henrik Krohns from comment #65)
> Not sure I follow, would it matter why a rule is unrun?
People have been talking about meta rules that evaluate to something useful,
and then "season" the
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
Kevin A. McGrail changed:
What|Removed |Added
CC||kmcgr...@apache.org
--- Comment
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #65 from Henrik Krohns ---
(In reply to Loren Wilton from comment #64)
> Can you tell the difference in the unrun rules list between a rule FOO that
> didn't run because it was a net test that timed out (or is undefined, or
>
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
Loren Wilton changed:
What|Removed |Added
CC||lwil...@earthlink.net
--- Comment
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #63 from Wolfgang Breyha ---
I vote for the old logic. The new one is unpredictable and makes maintenance of
"homebrew rules" a burden. And in most cases they are used with "||" or "+"
where a zeroed unrun rule makes no
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #62 from Henrik Krohns ---
Ok so all pending commits are now done.
This bug is still open for:
- Discussion about what to do with "unrun" rules
- Documentation
Please vote or discuss:
- Keep logic as is, unrun rules may
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #61 from Henrik Krohns ---
(In reply to Loren Wilton from comment #60)
> My mind keeps coming back to the idea of marking unrun rules that are
> dependencies as zero score, and running the dependent metas.
>
> Or simplify that
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
Loren Wilton changed:
What|Removed |Added
CC|lwil...@earthlink.net |
--
You are receiving this mail
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
Loren Wilton changed:
What|Removed |Added
CC||lwil...@earthlink.net
--- Comment
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #59 from Henrik Krohns ---
Maybe new "tflags FOOBAR allow_unrun" or such for a meta rule?
A global toggle to allow unrun rules?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #58 from Henrik Krohns ---
(In reply to Henrik Krohns from comment #57)
> (In reply to Wolfgang Breyha from comment #55)
> > I see other rules which fail that way:
> >
> > eg. FSL_BULK_SIG
> > If the rule without DCC_CHECK
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #57 from Henrik Krohns ---
(In reply to Wolfgang Breyha from comment #55)
> I see other rules which fail that way:
>
> eg. FSL_BULK_SIG
> If the rule without DCC_CHECK will result in 0, but DCC_CHECK is toggled 0/1
> the "||"
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #56 from Henrik Krohns ---
I see that the "unrun" rules logging was still buggy.
dbg: rules: RESULT1 DIGEST_MULTIPLE $VAR1 = '';
dbg: rules: RESULT2 DIGEST_MULTIPLE $VAR1 = '';
dbg: rules-all: ran meta rule DIGEST_MULTIPLE, no
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #55 from Wolfgang Breyha ---
I see other rules which fail that way:
eg. FSL_BULK_SIG
If the rule without DCC_CHECK will result in 0, but DCC_CHECK is toggled 0/1
the "||" will produce different results and the rule stays
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #54 from Wolfgang Breyha ---
(In reply to Henrik Krohns from comment #52)
> What does the __METATEST rule contain?
It is the __ZID_PHISH_BASE rule for example from my ruleset I sent you. It is a
arithmetic rule dependent on
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #53 from Kevin A. McGrail ---
Interesting. I think meta was designed to run if rules with dependencies
wouldn't be able to run.
I know I used this in rules where I would add a condition that might helpful
but not required for a
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #52 from Henrik Krohns ---
(In reply to Wolfgang Breyha from comment #51)
> I took the time and read the whole thread and bug 4549 now and understand
> how "running a rule twice" should work in theory. No problem with that
>
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #51 from Wolfgang Breyha ---
I took the time and read the whole thread and bug 4549 now and understand how
"running a rule twice" should work in theory. No problem with that anymore.
But still, it doesn't work that way
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #50 from Wolfgang Breyha ---
All that I can say is that meta rules did/do not work as expected with SA4.
This might be the case because of the one issue which is not in bugzilla yet
which I sent you personally and I've patched
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
Henrik Krohns changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
Wolfgang Breyha changed:
What|Removed |Added
CC||wbre...@gmx.net
--- Comment #48
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
Henrik Krohns changed:
What|Removed |Added
Blocks||8062, 8065
Referenced Bugs:
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #47 from Henrik Krohns ---
The more I've seen complex real world meta rulesets, network rules behaving
badly, being blocked etc... I'm wondering if the current "unrun" handling makes
more trouble than it's worth.
No one has
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
Henrik Krohns changed:
What|Removed |Added
Blocks||8061
Referenced Bugs:
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
Henrik Krohns changed:
What|Removed |Added
Blocks||8059, 8060
Referenced Bugs:
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
Loren Wilton changed:
What|Removed |Added
CC|lwil...@earthlink.net |
--
You are receiving this mail
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
Henrik Krohns changed:
What|Removed |Added
Blocks||7987
Referenced Bugs:
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
Henrik Krohns changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #45 from Sidney Markowitz ---
(In reply to Henrik Krohns from comment #43)
> Not seeing any unrun variations after that commit. Can you make any tests
> fail?
Everything I tried passed. If you are happy with this, you can close
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #44 from Sidney Markowitz ---
(In reply to Henrik Krohns from comment #43)
> Not seeing any unrun variations after that commit. Can you make any tests
> fail?
That fix makes a lot more sense to me. My tests looking for unrun
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #43 from Henrik Krohns ---
Not seeing any unrun variations after that commit. Can you make any tests fail?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #42 from Henrik Krohns ---
- Disabled (score 0) metas no longer added to meta_pending
- Unrun debug reporting should now be foolproof
Committed revision 1901397.
--
You are receiving this mail because:
You are the assignee
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #41 from Henrik Krohns ---
(In reply to Sidney Markowitz from comment #39)
> (In reply to Sidney Markowitz from comment #38)
> > In finish_meta_tests, when it does
> > delete $mp->{$rulename};
> > should it also do
> >
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #40 from Henrik Krohns ---
(In reply to Sidney Markowitz from comment #37)
>
> I got confused. I really have two separate questions. One is how the checks
> for meta and dependencies work when a meta is defined with a header
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #39 from Sidney Markowitz ---
(In reply to Sidney Markowitz from comment #38)
> In finish_meta_tests, when it does
> delete $mp->{$rulename};
> should it also do
> delete $unrun_metas{$rulename};
> in case one that was
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #38 from Sidney Markowitz ---
In finish_meta_tests, when it does
delete $mp->{$rulename};
should it also do
delete $unrun_metas{$rulename};
in case one that was found as unrun in a previous loop now can be run?
--
You
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #37 from Sidney Markowitz ---
(In reply to Sidney Markowitz from comment #36)
> How does this work?
I got confused. I really have two separate questions. One is how the checks for
meta and dependencies work when a meta is
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #36 from Sidney Markowitz ---
How does this work?
rules/72_active.cf:header __THREAD_INDEX_GOOD
is used in a number of meta rule definitions with a || operator.
What does that do with the dependency checks and the do_meta
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #35 from Henrik Krohns ---
Sort is just hiding the bug. It should be enough to run a single
do_meta_tests/finish_meta_tests in the end, which should iterate all metas over
and over until all are ready. I just can't figure out
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #34 from Sidney Markowitz ---
(In reply to Henrik Krohns from comment #30)
> There's still some strange bug somewhere that makes meta rules behave
> differently on different runs.
The following change in Check.pm makes that go
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #33 from Sidney Markowitz ---
(In reply to Henrik Krohns from comment #30)
> There should be no
> reason for the list to change between runs.
>
> spamassassin -t -L -D rules-all < message 2>&1 | grep unrun
As an easy way to
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #32 from Sidney Markowitz ---
I can't reproduce the sporadic failures in t/basic_meta2.t since the latest
fixes to tests, but since it was always sporadic that is not a definitive
result.
--
You are receiving this mail
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
Sidney Markowitz changed:
What|Removed |Added
CC||sid...@sidney.com
--- Comment
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
Henrik Krohns changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
Henrik Krohns changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
Henrik Krohns changed:
What|Removed |Added
Attachment #5746|0 |1
is obsolete|
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #27 from Henrik Krohns ---
(In reply to Loren Wilton from comment #26)
> I don't understand the concern expressed in Comment 19.
It's been exaplained a few times. Rules that are simply intended for reducing
FPs are not run in
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #26 from Loren Wilton ---
> Loren, I might be a bit tired from long work day, but I'm not sure what you
> are implying/suggesting.. tried reading it thrice. :-)
Sorry, I'm too verbose because I don't know the actual code at
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #25 from Henrik Krohns ---
(In reply to Henrik Krohns from comment #24)
> I will look if there is a some 3.4 compatible way to implement "if
> (local_tests_only)".
Ugh it gets a bit wonky. Current conf parser considers any
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #24 from Henrik Krohns ---
Loren, I might be a bit tired from long work day, but I'm not sure what you are
implying/suggesting.. tried reading it thrice. :-)
Unrun rule currently has simple definition: either it was not run at
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #23 from Loren Wilton ---
It seems to me that if net rules are turned off, they are unrun and the result
is indeterminate: that is, we don't know how they would have evaluated if they
had been run.
In that sense, they are then
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #22 from Henrik Krohns ---
(In reply to Henrik Krohns from comment #21)
> But net-flag makes no difference on when rules run or are considered unrun.
Ok correction, eval-rules marked as net are not run if local rules only. But
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #21 from Henrik Krohns ---
(In reply to John Hardin from comment #20)
> Is that in there to include what we're currently doing? Or is it not
> inheriting tflags net and thus it is running with the assumption I stated
> above?
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #20 from John Hardin ---
(In reply to Henrik Krohns from comment #19)
> Example: BITCOIN_SPAM_05 will not run in daily masschecks, because
> __SPOOFED_FREEMAIL -> __NOT_SPOOFED depends on DKIM/SPF checks, which
> obviously don't
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #19 from Henrik Krohns ---
Example: BITCOIN_SPAM_05 will not run in daily masschecks, because
__SPOOFED_FREEMAIL -> __NOT_SPOOFED depends on DKIM/SPF checks, which obviously
don't run with local checks only.
Solutions?
-
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
Henrik Krohns changed:
What|Removed |Added
Attachment #5744|0 |1
is obsolete|
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #17 from Henrik Krohns ---
Doing some more testing, mass check 4000 messages with -j4
trunk 138s
trunk.meta 190s
Seems the performance gap is a bit too unacceptable here. Still looking for
ways to optimize.
--
You are
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
Henrik Krohns changed:
What|Removed |Added
Attachment #5743|0 |1
is obsolete|
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #15 from Henrik Krohns ---
Argh never mind the previous comment, brain freeze.. that specific example
works, as both evals are true, let's say DCC_CHECK is disabled
1 + 0 + 1 > 1
1 + 1 + 1 > 1
Any other scenario to consider?
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #14 from Henrik Krohns ---
Ok I've finished the dual evaluation code, but I'm still wondering whether
timed out lookups should count as unrun rules.
Let's take this stock rule as example.
meta DIGEST_MULTIPLE RAZOR2_CHECK +
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
Henrik Krohns changed:
What|Removed |Added
Attachment #5742|0 |1
is obsolete|
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #12 from Henrik Krohns ---
(In reply to Henrik Krohns from comment #11)
> - Duplicate rule merging code has been removed, since it would require new
> bloaty extra logic to work with all the above. It saved very little
>
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #11 from Henrik Krohns ---
Created attachment 5742
--> https://bz.apache.org/SpamAssassin/attachment.cgi?id=5742=edit
Meta patch for trunk v1
Took too many days, but here's patch for a brute force approach.
Things done:
-
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
Henrik Krohns changed:
What|Removed |Added
CC||quin...@pathname.com
--- Comment
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #9 from Loren Wilton ---
Minor correction to the previous post. I said there that there was a sync rule
list and a sync meta list, and the sync rules were processed in priority order,
then the sync meta rules. This isn't quite
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
Loren Wilton changed:
What|Removed |Added
CC||lwil...@earthlink.net
--- Comment
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #7 from Henrik Krohns ---
Perhaps meta rules should not use the "rule priority" system at all. Any metas
that depend on async rules simply hang waiting at that priority, which is
pointless.
There should be some system that
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
Stingertough changed:
What|Removed |Added
CC||wolfsp...@gmail.com
--
You are
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #6 from Henrik Krohns ---
But if some of these rules do indeed disappear from our daily masschecks, I
might revert this change to my previous code which was simply Reuse.pm doing
the same thing: forcing reuse of the
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #5 from John Hardin ---
(In reply to Henrik Krohns from comment #4)
> Yes it's a bit tricky, but honestly, who uses "non-net rulesets" these days
> anyway?
True.
--
You are receiving this mail because:
You are the assignee
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
--- Comment #4 from Henrik Krohns ---
Yes it's a bit tricky, but honestly, who uses "non-net rulesets" these days
anyway? You can't even use SpamAssassin without sa-update. And those with some
strange private network usage, probably don't
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7735
John Hardin changed:
What|Removed |Added
CC||jhar...@impsec.org
--- Comment #3
1 - 100 of 103 matches
Mail list logo
