Re: [exim-dev] Exim 4.68 and Spam Assassin 3.2.3 mistagging …

Top Page
Delete this message
Reply to this message
Author: Ted Cooper
Date:  
To: exim-dev
Subject: Re: [exim-dev] Exim 4.68 and Spam Assassin 3.2.3 mistagging email
Norton, Ian wrote:
> Hi All,
>
> I've tried posting this question to the exim-users list but received no replies at all. Sorry for the duplicate posting but I'm hoping that perhaps someone here might be able to help. Currently this issue is stopping us deploying as we don't have any ideas as to why this might have happened or how to make sure that it doesn't re-occur.


I remember reading it or something like it and I thought I replied but
that doesn't seem to be the case since I can't find it in any of my sent
mail. Darn.

> We're using spam assassin 3.2.3 and exim 4.68


Almost same here.

> Here's the relevant snippet of ACL from the configuration:
>
>   # Put headers in all messages (no matter if spam or not)
>   warn  spam       = nobody:true
>         add_header = X-Spam-Score: $spam_score ($spam_bar)

>
>   warn  spam       = nobody:true
>         add_header = X-Spam-Report: $spam_report


>   X-Spam-Score:  ()
>   X-Spam-Report: Spam detection software, running on the system
>         "whobblebury.lancs.ac.uk", has processed this message.
>         The results are shown below.
>         Content analysis details:   (27.6 points, 4.5 required)


You'll have to excuse the random order of this reply. I wrote it over an
hour period while experimenting and looking at source code.

I had to go back and read your post a few times as I am getting confused
by the "clean message" response in the SA logs when what you gave is
clearly not a clean message.
SA looks like it has whole heartedly decided it's spam and so has exim,
it's just missing the variable contents on the first run which is
interesting since the message is only sent to SA once and all further
results are cached.
"matching rules three and four above even when spam assassin logs them
as clean" - Does SA really say they are clean in the SA log even though
it has a score of 27.6?

$spam_score working on a later line means it can't be a parsing error
from SA to exim or a memory overwrite issue.

So long as the user is not changed for a spam check, the cached results
are used so it's only being run once so it's not a persistent error.

If rules 1 and 2 were skipped but 3 and 4 were not it could be put down
to some sort of issue with the warn verb and a single condition that is
always going to return true.

I have a few theories as to what is happening but every time I try to
type them out I just seem to confuse myself. Basically - add_header is
getting executed before spam = nobody:true, and/or spam = nobody:true is
being evaluated to true as the only important condition and execution of
SA is being skipped for that ACL.
I didn't have much of a look at the code to see if either of these cases
were possible but it's working fine here and the only difference is the
wording of the ACL.

A possible work around would be to split the execution of SA off into
it's own one line warn statement and use the result in all subsequent
ones. ie:

warn    spam       = nobody


warn    spam       = nobody:true
        add_header = X-Spam-Score: $spam_score
($spam_bar)\nX-Spam-Report: $spam_report


If all else fails, head back to the original evil warn message style.
It's so old it even has the {1}{0} on the IF statements!

# Add headers to all messages regardless of the spam threshold.
  warn    message       = X-Spam-Score: $spam_score ($spam_bar)
          condition     = ${if <{$message_size}{DATA_SA_MAX}{1}{0}}
          spam          = spamc:true


# Add spam report to headers
  warn    message       = X-Spam-Report: $spam_report
          condition     = ${if <{$message_size}{DATA_SA_MAX}{1}{0}}
          spam          = spamc:true
          condition     = ${if >{$spam_score_int}{50}{1}{0}}


# Change the subject if it's spam according to SpamAssassin
  warn    message       = X-New-Subject: **SPAM** $spam_score $h_subject:
          condition     = ${if <{$message_size}{DATA_SA_MAX}{1}{0}}
          spam          = spamc


  deny    message       = Spam score too high
          log_message   = Spam score too high ($spam_score)
          condition     = ${if <{$message_size}{DATA_SA_MAX}{1}{0}}
          spam          = spamc:true/defer_ok
          condition     = ${if >{$spam_score_int}{SPAMLEVEL}{1}{0}}


If you can narrow down what exact change makes the problem appear I
might have a chance of finding it in the code. I have not looked into
the configuration file parsing and ACL modifier execution code so I need
to hunt down a specific problem rather than blindly looking at the code
and hoping to spot an error in something I don't understand.
The above chunk of ACL is almost straight out of my configuration file
and it is almost identical to what you run. "message" over "add_header"
and the use "condition" are the only real differences.

Good luck and let us know if you find the root issue.

--
The Exim Manual
http://www.exim.org/docs.html
http://www.exim.org/exim-html-current/doc/html/spec_html/index.html