[Bug 7735] Meta rules need to handle missing/unrun dependencies
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 daily masschecks. meta __NOT_SPOOFED SPF_PASS || DKIM_VALID || !__LAST_EXTERNAL_RELAY_NO_AUTH || ALL_TRUSTED SPF_PASS or DKIM_VALID are unrun. Double eval will not make the meta hit. (0||0||0||0) && (1||1||0||0) It makes it harder to tune rules as you need to wait a week for results. There should be a way to bypass it, if the dependencies are not considered critical. > Does this mean that an undefined rule appearing in a meta evaluates to true > rather than to "unrun"? If so I see that as a possible problem; I'd prefer > an undefined rule to be treated as unrun, but I can see the logic of > treating it as a constant value (but I'd think false makes more sense). Sorry, to clarify, this only applies to "if" clauses. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 7735] Meta rules need to handle missing/unrun dependencies
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 all well. > Unrun rule currently has simple definition: either it was not run at all, or > result was not received (timeout). Unrun rules in metas are evaluated twice > as That is what I think should happen. I don't understand the concern expressed in Comment 19. > Ugh it gets a bit wonky. Current conf parser considers any unknown string as > true. Does this mean that an undefined rule appearing in a meta evaluates to true rather than to "unrun"? If so I see that as a possible problem; I'd prefer an undefined rule to be treated as unrun, but I can see the logic of treating it as a constant value (but I'd think false makes more sense). -- You are receiving this mail because: You are the assignee for the bug.
[Bug 7735] Meta rules need to handle missing/unrun dependencies
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 unknown string as true. # Will always apply on old versions if (local_rules_only) meta __SPOOFED 0 endif # Something like this would be required, mandatory feature check if can(Mail::SpamAssassin::Conf::feature_local_rules_only) && local_rules_only meta __SPOOFED 0 else meta __SPOOFED DKIM_INVALID || STUFF endif -- You are receiving this mail because: You are the assignee for the bug.
[Bug 7735] Meta rules need to handle missing/unrun dependencies
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 all, or result was not received (timeout). Unrun rules in metas are evaluated twice as before mentioned. I don't think tflags should matter here, unrun is unrun. Let me know in clear terms, if you think something should be changed there. I will look if there is a some 3.4 compatible way to implement "if (local_tests_only)". -- You are receiving this mail because: You are the assignee for the bug.
[Bug 7735] Meta rules need to handle missing/unrun dependencies
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 no different than a net rule that was fired but the result didn't arrive in time. With the recent changes, meta rules are (I believe) run twice with the result both true and false for an unreceived net result. I would say that with net rules disabled, we would treat all meta rules that depend on net rule results the same way: the net results weren't received in time, so they need to be evaluated twice. This should extend to any missing result a meta rule depends on, but I don't know if it makes more sense to do the double evaluation based on not having the net rule result, or based on checking tflags net for the dependency and some flag that says net rules are disabled. Given that the case: #body SOME_DISABLED_RULE /./ meta COMPOUND_TEST SOME_DISABLED_RULE && OTHER_RULE should evaluate the meta based solely on OTHER_RULE, it seems to me that disabled net rules are the same case as the undefined disabled rule, so possibly the same logic works to ignore the results if disabled net rules. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 7735] Meta rules need to handle missing/unrun dependencies
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 metas or any other types don't have such a check (should they?). -- You are receiving this mail because: You are the assignee for the bug.
[Bug 7735] Meta rules need to handle missing/unrun dependencies
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? Not sure I understand the questions. But net-flag makes no difference on when rules run or are considered unrun. -- You are receiving this mail because: You are the assignee for the bug.
