load-sa-rules.pl skips rules that lack description lines

[rjl]

The load-sa-rules script currently ignores rules that don't contain the "describe" line that the SpamAssassin docs stipulate. A well-formed header rule, for instance, should look something like:

header FOO_BAR    X-Foo =~ /bar/
score FOO_BAR     1.0
describe FOO_BAR  X-Foo header contains the string 'bar'

Without the "describe" line, SpamAssassin will leniently process the rule anyway, but no descriptive text will appear in its spam report header next to the rule name. Since load-sa-rules doesn't load such rules at all, however, these rules will not appear in the report section of Maia's mail viewer when they're triggered, and no stats will be tracked for them on the SpamAssassin statistics page.

While it is possible to parse rules without "describe" lines, it is not always clear when the rule author has omitted the description intentionally (e.g. in the case of a sub-test that is only significant if it triggers in combination with certain other rules, which collectively get one "describe" line in the form of a meta-rule), or out of carelessness. load-sa-rules should make a better effort at distinguishing these two cases, or resort to loading all rules, sub-tests and all.

[mortonda@…]

Couldn't maia_record_tests() in amavisd-maia add the tests to the database? It wouldn't have the description maybe, but then again, that's the problem here anyway...

[rjl@…]

Ticket #504 (implemented in [1300] and [1301]) tries to address this issue by simply adding new rules as amavisd-maia encounters them, even if it means adding them with null descriptions that need to be edited later.

That same solution can be applied to this ticket as well, by having load-sa-rules.pl add any rules that aren't obvious tests (i.e. all rules that do not begin with '_'), without regard for 'describe' lines. If no matching 'describe' line can be found, those rules can have their descriptions left null, just as #504 handles it, leaving it to a later GUI-based editing feature to supply missing descriptions at the superadmin's leisure.

With this change, #504 becomes redundant so long as load-sa-rules.pl is used properly by the administrator, run whenever changes are made to the SpamAssassin rules. Where #504 remains marginally useful is to cover admins who aren't good at reading instructions--if they forget to run load-sa-rules.pl after adding new rules, amavisd-maia can still catch the new rules and add them to the database with null descriptions.

One consequence of #504, though, is that load-sa-rules.pl should also start looking for rules in the database that have null descriptions, and should supply those descriptions if they can be found in the *.cf files it parses.

[mortonda@…]

And/Or with a web interface for an admin to write their own description, perhaps an option to just refresh all original descriptions would be useful.

[mortonda@…]

might be able to make a small perl script to extract the spamassassin info of where the directory is, and then call it via php, update the db and offer to edit.

The only perl specific bit is:

    my $sa = Mail::SpamAssassin->new();
    my $sa_version = $sa->VERSION;
    my $sa_prefix = $sa->{PREFIX};

which is then used to find the paths

[mortonda@…]

[1457] adds an option to reload or update existing rule descriptions; This allows you to add a description to the local.cf file and update the database from that. Also helps if you ran amavisd-maia without first running load-sa-rules.pl

[mortonda@…]

Superseding the rest of these issues with #544 for future versions.