Loren Wilton writes:
> > If it's a plugin, it has to be a code-tied rule! Otherwise it
> > wouldn't need the plugin.
>
> Hey, what a neat way to completely disable the initial concept of the
> Rules project and put things back into the Land Of Arcana where they
> belong!
>
> Just move 'body', 'rawbody', 'header', and 'full' to plugins! Then you
> can move all those ruletypes into the code-tied directory and never have
> to worry about whether they are applicable to any particular version!
>
> Hey! Great idea! While you are at it, why don't you make all those
> plugins disabled by default, and admins can enable them only if they
> think they need them?
Bit of hyperbole, but I agree with your point -- that is indeed an end
situation I think we need to avoid.
- (a) If anything like a currently-working rule type is pluginized, it
needs to remain on by default, not requiring admin activity to reenable
(which in 99% of sites will never happen), and fully rules-language
compatible. Otherwise we're breaking the platform for third-party rules.
- (c) If something is implemented in a plugin, it is *not* a code-tied
rule, that just makes no sense.
Take this thought experiment: "body" rule type is moved to a plugin;
therefore all "body" rules in the ruleset have to be considered
code-tied rules. Seriously, that *cannot* be how it works, it's
nonsensical!
I would define the following criteria to determine if a rule is code-tied
or not:
- 1. implementation is an "eval:" function
- 2. the eval function in question is not a documented public API, for use
in more than one rule.
so for example, these are "code-tied":
- body HTML_EVENT_UNSAFE eval:html_test('html_event_unsafe')
Code-tied, because its behaviour depends on what the html_test()
function does, and that function is tied into HTML.pm, which is part of
the core code, is undocumented, and not offered as a public API.
- header NO_DNS_FOR_FROM eval:check_dns_sender()
Code-tied, check_dns_sender() is part of EvalTests.pm in core,
and not offered as a public API.
But these aren't:
- header ACCESSDB eval:check_access_database('/etc/mail/access.db')
Not code-tied; check_access_database() is a public API offered by the
Mail::SpamAssassin::Plugin::AccessDB plugin, and its function API is
well-defined for public use by other rules, by its POD docs.
- body URIBL_SBLXBL eval:check_uridnsbl('URIBL_SBLXBL')
check_uridnsbl() is the documented public API for URIBL rules, defined
in URIDNSBL.pm's POD docs.
If the term "code-tied" causes confusion, let's make it clearer.
"non-public eval rules"?
--j.
