On 11 Sep 2015, at 17:25, Peter Kelly wrote:
Bill,
I checked there first, I always assume it is something I am doing
wrong
first. Yes mailchecker (not that obsolete version) is the http service
we
use and it in turn uses this Golang lib for spamc -
https://github.com/saintienn/go-spamc
I can actually see the 0.0 scores directly in the logs at
/var/log/mail.log
on the spamassassin servers.
E.g.
Sep 11 21:07:19 ip-10-181-62-231 spamd[13929]: spamd: clean message
(0.0/5.0) for (unknown):65534 in 0.4 seconds, 8128 bytes.
Sep 11 21:07:19 ip-10-181-62-231 spamd[13929]: spamd: result: . 0 -
BAYES_00,FREEMAIL_FROM,HTML_IMAGE_ONLY_32,HTML_MESSAGE,HTML_TAG_BALANCE_BODY,NO_RELAYS,SPF_NEUTRAL,T_DKIM_INVALID,URIBL_BLOCKED
Hmmm.... That reminds me: spamd only returns a score with a single
decimal place, so the fact that this one would add up to 0.039 doesn't
make the log line wrong in the way I thought your screenshot was wrong.
However, it DOES make any tool reporting greater precision (i.e. the
"0.00" values in your screenshot) misleading by design, so the problem
isn't (probably) misparsing but incorrect conversion of 0.0 to 0.00.
It must be the bayes is completely messed up. I actually did a
sa-learn
--clear and ran a fresh 1000 spam and ham (verified) through again,
still
seeing BAYES_00 an unusually high number of times. I will look into my
own
DNS nameserver for the RELAY and TRUSTED problem.
That's not a DNS issue, it's a configuration issue and/or a data
preparation issue. Messages that match NO_RELAYS are either not properly
formatted, have had their headers mangled, or originated on the same
machine where they were delivered. ALL_TRUSTED can result from lesser
header damage and/or a mis-specified trusted_networks setting in
SpamAssassin.
