RE: Seeing where SpamAssassin rules hit

[Sven Riedel]

Title: RE: Seeing where SpamAssassin rules hit

> tried the frist obvious test with:
>
> cat <spamfile> | sa_hits
>
> which results in a Usage message.
Yes, currently no piping of mail to stdin, as stated on the webpage :)

> Next try with:
>
> [EMAIL PROTECTED]:~/spam> sa_hits 00005742
> Use of uninitialized value in pattern match (m//) at /home/thomas/bin/sa_hits
...and giving rule files is mandatory. Thats a bug in the usage message,
I'll haave to fix that.

> Another try gives:
>
> [EMAIL PROTECTED]:~/spam> sa_hits 00000058 /etc/mail/spamassassin/99_TA_Price.cf
> Skipping the following rules, since I don't know how to handle them:
>
> -- BODY --
> Mail got hit by the following rules:
> TA_Price_01 (Score: 5.0):  (?i-xsm:\bRetail Price: \$[0-9]+\.[0-9][0-9].*Our
> Price: \$[0-9]+\.[0-9][0-9])
> TA_Price_02 (Score: 5.0):  (?i-xsm:You Save.*\$[0-9]+\.[0-9][0-9])
> [snip]
>
> But the mail was not hit by the Rules.

What the script does in default mode is check for the X-Spam-Status: header (the
last one in the mail, if multiple are present) and extracts the rules from
"tests=X". It will then go through the rules files provided and search for
the rule definition and apply the regular _expression_ from that rule on the
mail. This will of course require you to have the rule definitions on
your local machine somewhere that match those on the machine that filtered the
mail.

If your tests feather rule names with different local definitions, nothing (at
best) or wrong sections (at worst) will be found by the script.

> There is a lot of work to be done :-)
Of course. Especially with the documentation. :) And adding more useful options
like ignoring said X-Spam-Status header and just applying the list of rules given
on the command line or applying all rules found in the rule files one by one.

Regs,
Sven