On 08/03/06 07:31 AM, Justin Mason wrote:
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"?
This, to me, sounds like a reasonable criteria and definition. Daryl
