On Mon, 2018-10-01 at 22:45 +0100, RW wrote:
> It seems to be related to the use decimal numeric literals
>
> meta __YYY 1/2
> meta __XXX 0.2 * __YYY + 0.1
>
> $ spamassassin --lint
> ...
> ... warn: config: Strange rule __XXX token: 0.2
> ... warn: config: Strange rule __XXX token: 1.1
>
Interesting. I have only one local rule with a literal '1.5' in a meta
rule body. Here's that rule:
describe MG_LOTTO Fake lotto winner
header __MG_LOT1 From =~ /lotto/i
body __MG_LOT2 /(lotto|loterie)/i
meta MG_LOTTO ( ( __MG_LOT1 + __MG_LOT2 ) > 1.5 )
score MG_LOTTO 2.0
This rule has been around and working as expected for several years.
That's read from and parsed from different file (local.cf) than the
rule that's getting blamed for the problem (in MimeMagic.cf) and some
600 lines earlier if these files are read in collation sequence.
MimeMagic.cf contains conditional code:
if (version >= 3.003)
loadplugin Mail::SpamAssassin::Plugin::MimeMagic MimeMagic.pm
followed by defining two rules called MG_IMG_TYPE_WRONG and
MG_IMISMATCH
else
ifplugin Mail::SpamAssassin::Plugin::ImageInfo
followed by defining several rules, all with double underscore prefixes
to their names, either
of the form: mimeheader .... Content-Type =~ /image\/xxx/i ...
or: body ... eval:image_count('xxx',1)
then a bunch of metas, also with double underscore name prefixes, that
are combined into a final meta rule, IMAGE_MISMATCH, which has a score
of 1.5
endif
The oddity here is that *both* IMAGE_MISMATCH and MG_IMISMATCH appear
in that order immediately before the
warn: config: Strange rule token: 1.5
warning but there "-D --lint" log does not mention the
MG_IMG_TYPE_WRONG rule at all.
This looks to me as if there might there be some problem with the
if...else...endif handling.
There was a second 'endif' in the file, which I've removed without,
apparently, any effect at all - and certainly no effect on this
problem.
Martin
