[SA-exim] Re: Bug#246715: sa-exim: network checks are failing because headers are incomplete

[Sander Smeenk]

Quoting Wayne Schlitt (wayne at midwestcs.com):

> I happen to run SpamAssassin twice on each email, once using SA-Exim and
> once using procmail.  I noticed that the scores from procmail were
> higher, often *MUCH* higher so I investigated a little bit and found
> that the DNSBL checks weren't being done in SA-Exim.

Uhm, i'm forwarding this upstream, but you are aware that when you run
spamc it uses your spamassassin settings, bayes databases,
autowhitelists, and when sa-exim runs spamc it uses 'nobody''s settings,
which most probably do not exist.

> I wrote a little shell script to track the spamc options and data that
> SA-Exim was using.  I discovered that the top Recieved: header (the one
> that is added by Exim on my machine) is not being sent to spamc.  I'm
> not sure if this header has even been created yet or not.

Well, I remember something similar being reported recently about Exiscan
on the exim4 mailinglist. Hmm. It could be...

> The result, however, is that SpamAssassin will either find no
> Received: headers and therefore can't check DNSBL stuff, or it can be
> mislead into believing that forged headers can be trusted since the top
> Received: header is "always trustworthy".

Seems like you did a good job investigating the problem. I'd really like
to see the Spam Tests that sa-exim's spamc-run found, and the Spam Tests
that you found.

> ii  debconf [debconf-2.0]       1.4.22       Debian configuration management sy
> ii  exim4-daemon-heavy          4.32-1       Exim (v4) with extended features, 
> ii  libc6                       2.3.2.ds1-11 GNU C Library: Shared libraries an
> ii  spamassassin                2.63-1       Perl-based spam filter using text 
> ii  spamc                       2.63-1       Client for perl-based spam filteri

Regards,
Sander.
-- 
| If swimming makes you thin, then what do whales do wrong?
| 1024D/08CEC94D - 34B3 3314 B146 E13C 70C8  9BDB D463 7E41 08CE C94D