https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7992
--- Comment #19 from Henrik Krohns <apa...@hege.li> ---
(In reply to John Hardin from comment #18)
> I like the syntax, too.
>
> (In reply to Henrik Krohns from comment #16)
> > If a regex rule depends on a tag %{FOO} and no match is found for it, should
> > we consider it as unrun? I guess so. Doesn't make much sense to try matching
> > the literal value anyway.
>
> There are no %{MUMBLE} rules in the base ruleset but if anyone defined some
> locally for some reason they'd stop working as expected.
Just need to document it clearly in changelog. Quite unlikely that anyone would
use that. I found a _single_ message from 2018 in my spam corpus that a similar
template..
<B>To:</B><SPAN> %{RECEIVER_ADDRESS}</SPAN>
> Perhaps a check for that match name being defined, and if no rule was
> defined to capture that name then treat it as a literal? Do we need/want to
> lint for that? "Rule X contains '%{MUMBLE}' but no rule captures tag
> MUMBLE"? Seems a good idea.
As we are heading in the direction that "tags" are used for everything, it's
not possible to know in advance what tags are defined. Plugins can create tags
etc.
> What is the recommended CAN() test for this so we can guard rules using the
> new syntax from bothering old code?
Mail::SpamAssassin::Conf::feature_capture_rules
It was defined week ago before %{} format. I guess we could even rename/add a
new one like feature_capture_tags or something.
--
You are receiving this mail because:
You are the assignee for the bug.
