On 06/15/2017 06:42 PM, Gerald Turner wrote:
Hello list, I'm a happy long-time user of SA, and just upgraded a mail
server from Debian 8 "jessie" to Debian 9 "stretch", and in turn
upgraded SA from 3.4.0 to 3.4.1. The upgrade was smoothe, other than
some irrelevant breakage with FuzzyOCR¹, however there's been an
enormous increase in syslog messages that I've been combating, and I
cannot find the root cause.
Upon upgrading to SA 3.4.1, each email scanned is emitting the following
message to syslog:
spamd[32137]: rules: meta test FREEMAIL_FORGED_FROMDOMAIN has dependency
'HEADER_FROM_DIFFERENT_DOMAINS' with a zero score
After a bit of searching, I gave up and simply added the following line
to /etc/spamassassin/local.cf:
score HEADER_FROM_DIFFERENT_DOMAINS 0.001
The default score should be fine after you work out your issue. See below.
Now a week later, a simlar set of 'meta test ... with a zero score'
syslog messages have appeared:
spamd[31552]: rules: meta test __FORM_FRAUD_3 has dependency 'LOTTO_AGENT'
with a zero score
spamd[31552]: rules: meta test __MONEY_FRAUD_3 has dependency 'LOTTO_AGENT'
with a zero score
spamd[31552]: rules: meta test __FORM_FRAUD_5 has dependency 'LOTTO_AGENT'
with a zero score
spamd[31552]: rules: meta test __ADVANCE_FEE_4_NEW has dependency
'LOTTO_AGENT' with a zero score
spamd[31552]: rules: meta test __MONEY_FRAUD_8 has dependency 'LOTTO_AGENT'
with a zero score
spamd[31552]: rules: meta test __ADVANCE_FEE_2_NEW has dependency
'LOTTO_AGENT' with a zero score
spamd[31552]: rules: meta test __MONEY_FRAUD_5 has dependency 'LOTTO_AGENT'
with a zero score
spamd[31552]: rules: meta test __ADVANCE_FEE_3_NEW has dependency
'LOTTO_AGENT' with a zero score
spamd[31552]: rules: meta test __ADVANCE_FEE_5_NEW has dependency
'LOTTO_AGENT' with a zero score
spamd[31552]: rules: meta test __FORM_FRAUD has dependency 'LOTTO_AGENT'
with a zero score
> Looking at the timestamps of /var/lib/spamassassin/3.004001 files
reveals that there was an sa-update this morning, minutes before the
warning messages began.
Now I suppose I'll add another line to local.cf ("score LOTTO_AGENT
0.001"), but this doesn't feel right - this server has been setup for
ten+ years, has been through four or five Debian stable upgrades, and
the corresponding SA upgrades, and in all these years SA has been low
maintenance.
What could be the cause?
- Cruft left behind by old SA versions
(e.g. /etc/spamassassin/v310.pre, /var/lib/spamassassin/3.003001,
etc.)?
Make sure you remove all old rule dirs like that one.
/var/lib/spamassassin should only have your new 3.004001 directory.
- Is there a bug with the project's sa-update channel / auto-
mass-check setup?
I hope not. I have spent dozens and dozens of hours getting the
masscheck processing running again on a new server. It seems to be
working fine to me. We tested for a couple of weeks before going live
with sa-update updates recently.
- Configuration for sa-update's channels seems rather sparse, and I
see no evidence that I'm using anything other than the
defaults. Could I be pulling from the wrong channel?
There's really only the main updates_spamassassin_org channel these days.
FWIW my local.cf is pretty boring, a bit of bayes configuration,
trusted_networks and shortcircuit options. On a per-user basis there
are a few odd custom rules, but nothing hitting this "money" and/or
freemail stuff.
I ran “spamassassin -D --lint” and it only reported dbg messages, none
of which contained "LOTTO_AGENT".
I also manually ran “su debian-spamd -c "sa-update --refreshmirrors -D
channel,gpg,http --gpghomedir /var/lib/spamassassin/sa-update-keys"”,
which is normally handled by Debian's cron.daily script, and it's output
was clean:
Jun 15 16:25:55.464 [3027] dbg: gpg: Searching for 'gpg'
Jun 15 16:25:55.464 [3027] dbg: gpg: found /usr/bin/gpg
Jun 15 16:25:55.464 [3027] dbg: gpg: release trusted key id list:
0C2B1D7175B852C64B3CDC716C55397824F434CE
5E541DC959CB8BAC7C78DFDC4056A61A5244EC45
Jun 15 16:25:55.465 [3027] dbg: channel: attempting channel
updates.spamassassin.org
Jun 15 16:25:55.465 [3027] dbg: channel: using existing directory
/var/lib/spamassassin/3.004001/updates_spamassassin_org
Jun 15 16:25:55.465 [3027] dbg: channel: channel cf file
/var/lib/spamassassin/3.004001/updates_spamassassin_org.cf
Jun 15 16:25:55.465 [3027] dbg: channel: channel pre file
/var/lib/spamassassin/3.004001/updates_spamassassin_org.pre
Jun 15 16:25:55.466 [3027] dbg: channel: metadata version = 1798658, from
file /var/lib/spamassassin/3.004001/updates_spamassassin_org.cf
Jun 15 16:25:55.561 [3027] dbg: channel: current version is 1798658, new
version is 1798658, skipping channel
Any ideas?
1. Clean up any old versions of rules in /var/lib/spamassassin.
2. Make sure that spamd is restarted to pickup the rule changes
3. Run this to find any issues:
spamassassin -D --lint 2>&1 | grep -Ei '(failed|undefined
dependency|score set for non-existent rule)'
NOTE: There could be some legit issues even with dependencies with the
official SA rules. I have had to disable some SURBL rules due to high
volume of mail flow so there are some expected dependency problems with
other rules.
--
Dave
