On Thu, 23 Jul 2020, Kevin A. McGrail wrote:
On 7/23/2020 5:39 PM, Loren Wilton wrote:
The "alias" directive should not affect RE rules at all, other than
perhaps removing one if the alias is defined after a RE rule having the
same name was defined.
I would hope another use of ALIAS would be to redirect a subsequent
SCORE or DESCRIPTION directive to the renamed rule rather than
producing a warning for "score for nonexistant rule" or the like.
I'm not sure if the need for alias was overcome by how we solved it (see
below) which allows for rule template processing, local scoring and
local rules to work without any changes. John, was there other reasons
to add it?
if can(Mail::SpamAssassin::Conf::feature_blocklist_welcomelist)
#bz7826 renames whitelist to welcomelist
header USER_IN_WELCOMELIST_TO eval:check_to_in_welcomelist()
describe USER_IN_WELCOMELIST_TO User is listed in 'welcomelist_to'
tflags USER_IN_WELCOMELIST_TO userconf nice noautolearn
score USER_IN_WELCOMELIST_TO -6.0
else
header USER_IN_WELCOMELIST_TO eval:check_to_in_whitelist()
describe USER_IN_WELCOMELIST_TO User is listed in 'welcomelist_to'
tflags USER_IN_WELCOMELIST_TO userconf nice noautolearn
score USER_IN_WELCOMELIST_TO -0.01
meta USER_IN_WHITELIST_TO (USER_IN_WELCOMELIST_TO)
describe USER_IN_WHITELIST_TO DEPRECATED: See
USER_IN_WELCOMELIST_TO
tflags USER_IN_WHITELIST_TO userconf nice noautolearn
score USER_IN_WHITELIST_TO -6.0
endif
No, that's incomplete.
The intent was to avoid breaking existing production configurations and
third-party tools when feature_block_welcome becomes available, in order
to complete the coverage of backwards compatibility.
Note in the above rule definition that when that feature becomes
available, the definition for the USER_IN_WHITELIST_TO rule *disappears*,
leading to lint failures and unexpected behavior if local rules reference
it.
Having an "alias" directive lets us avoid that by having local references
to USER_IN_WHITELIST_TO (e.g., notably, scoring) be associated with
USER_IN_WELCOMELIST_TO.
In other words, we'd ship this:
if can(Mail::SpamAssassin::Conf::feature_blocklist_welcomelist)
#bz7826 renames whitelist to welcomelist
header USER_IN_WELCOMELIST_TO eval:check_to_in_welcomelist()
describe USER_IN_WELCOMELIST_TO User is listed in 'welcomelist_to'
tflags USER_IN_WELCOMELIST_TO userconf nice noautolearn
score USER_IN_WELCOMELIST_TO -6.0
if can(Mail::SpamAssassin::Conf::feature_alias)
alias USER_IN_WHITELIST_TO USER_IN_WELCOMELIST_TO
endif
else
...
...which avoids "score for nonexistent rule USER_IN_WHITELIST_TO" lint
problems and associated unexpected behavior changes.
And if a particular site is performing post-SA scanning of rule hits, and
that is looking for USER_IN_WHITELIST_TO in particular, then the local
site config would add this:
alias USER_IN_WHITELIST_TO USER_IN_WELCOMELIST_TO publish
...to add the "publish" option to the alias in order to report the
USER_IN_WELCOMELIST_TO hit under USER_IN_WHITELIST_TO as well to support
that post-SA processing until it could be updated to look for
USER_IN_WELCOMELIST_TO instead.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
[email protected] FALaholic #11174 pgpk -a [email protected]
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
USMC Rules of Gunfighting #4: If your shooting stance is good,
you're probably not moving fast enough nor using cover correctly.
-----------------------------------------------------------------------
102 days until the Presidential Election
