You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Gerald Turner <gt...@unzane.com> on 2017/06/15 23:42:18 UTC
Errors since upgrading to 3.4.1: "meta test ... with a zero score"
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
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.)?
- Is there a bug with the project's sa-update channel / auto-
mass-check setup?
- 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?
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?
¹ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808572
--
Gerald Turner <gt...@unzane.com> Encrypted mail preferred!
OpenPGP: 4096R / CA89 B27A 30FA 66C5 1B80 3858 EC94 2276 FDB8 716D
Re: Fwd: Re: Errors since upgrading to 3.4.1: "meta test ... with a zero score"
Posted by "Kevin A. McGrail" <ke...@mcgrail.com>.
Thought. Get the update nums from previous turn back on and copy those files to a higher number and update dns. That will revert back to last known good.
Regards,
KAM
On June 15, 2017 9:24:37 PM EDT, Dave Jones <da...@apache.org> wrote:
>Ugg! I asked for some help QA'ing the rules for over a week but got
>zero response then. I wonder if what was in SVN wasn't what was really
>
>running on the old masscheck box. I used what was in SVN. I guess I
>will dig through the old VM backup to see if I can find the difference
>related to this issue.
>
>Dave
>
>-------- Forwarded Message --------
>Subject: Re: Errors since upgrading to 3.4.1: "meta test ... with a
>zero
>score"
>Date: Thu, 15 Jun 2017 18:00:28 -0700
>From: John Hardin <jh...@impsec.org>
>To: users@spamassassin.apache.org
>
>On Thu, 15 Jun 2017, Gerald Turner wrote:
>
>> spamd[32137]: rules: meta test FREEMAIL_FORGED_FROMDOMAIN has
>dependency 'HEADER_FROM_DIFFERENT_DOMAINS' with a zero score
>> 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
>
>> - Is there a bug with the project's sa-update channel / auto-
>> mass-check setup?
>
>That's what it sounds like to me - it should not be omitting or zeroing
>
>the scores of rules that participate in metas.
>
>Something is odd. This didn't come up on the old masscheck host, but
>the
>score generation code should not have changed since then...
>
>It looks like it's not setting both the net and non-net scores for a
>few
>rules:
>
> score FROM_IN_TO_AND_SUBJ 1.099 0.000 1.099 0.000
> score HEADER_FROM_DIFFERENT_DOMAINS 0.001 0.000 0.001 0.000
> score HK_SCAM_N8 2.506 0.000 2.506 0.000
> score LOTTO_AGENT 2.609 0.000 2.609 0.000
>
>The non-network-enabled scores should only be zero for rules marked as
>being network-dependent rules, and *all* rules should have a nonzero
>network-enabled score (which appears to be the problem here).
>
>Something else odd is going on in the score generation: some
>well-performing rules (notably URI_WP_HACKED) are now getting scored at
>
>1 point. There are only 56 rules listed in 72_scores.cf (the output
>from
>the masscheck score generator), the rest would be defaulting to 1
>point.
>
>
>--
> John Hardin KA7OHZ http://www.impsec.org/~jhardin/
> jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
> key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
>-----------------------------------------------------------------------
> If you ask amateurs to act as front-line security personnel,
> you shouldn't be surprised when you get amateur security.
> -- Bruce Schneier
>-----------------------------------------------------------------------
> 3 days until SWMBO's Birthday
Fwd: Re: Errors since upgrading to 3.4.1: "meta test ... with a zero
score"
Posted by Dave Jones <da...@apache.org>.
Ugg! I asked for some help QA'ing the rules for over a week but got
zero response then. I wonder if what was in SVN wasn't what was really
running on the old masscheck box. I used what was in SVN. I guess I
will dig through the old VM backup to see if I can find the difference
related to this issue.
Dave
-------- Forwarded Message --------
Subject: Re: Errors since upgrading to 3.4.1: "meta test ... with a zero
score"
Date: Thu, 15 Jun 2017 18:00:28 -0700
From: John Hardin <jh...@impsec.org>
To: users@spamassassin.apache.org
On Thu, 15 Jun 2017, Gerald Turner wrote:
> spamd[32137]: rules: meta test FREEMAIL_FORGED_FROMDOMAIN has dependency 'HEADER_FROM_DIFFERENT_DOMAINS' with a zero score
> 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
> - Is there a bug with the project's sa-update channel / auto-
> mass-check setup?
That's what it sounds like to me - it should not be omitting or zeroing
the scores of rules that participate in metas.
Something is odd. This didn't come up on the old masscheck host, but the
score generation code should not have changed since then...
It looks like it's not setting both the net and non-net scores for a few
rules:
score FROM_IN_TO_AND_SUBJ 1.099 0.000 1.099 0.000
score HEADER_FROM_DIFFERENT_DOMAINS 0.001 0.000 0.001 0.000
score HK_SCAM_N8 2.506 0.000 2.506 0.000
score LOTTO_AGENT 2.609 0.000 2.609 0.000
The non-network-enabled scores should only be zero for rules marked as
being network-dependent rules, and *all* rules should have a nonzero
network-enabled score (which appears to be the problem here).
Something else odd is going on in the score generation: some
well-performing rules (notably URI_WP_HACKED) are now getting scored at
1 point. There are only 56 rules listed in 72_scores.cf (the output from
the masscheck score generator), the rest would be defaulting to 1 point.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
If you ask amateurs to act as front-line security personnel,
you shouldn't be surprised when you get amateur security.
-- Bruce Schneier
-----------------------------------------------------------------------
3 days until SWMBO's Birthday
Re: Errors since upgrading to 3.4.1: "meta test ... with a zero
score"
Posted by Dave Jones <da...@apache.org>.
On 06/20/2017 03:24 AM, Merijn van den Kroonenberg wrote:
>> On 6/19/2017 8:56 AM, David Jones wrote:
>>> Does 72_scores.cf look OK lately? I just downloaded the latest rules
>>> set and an old one from March 15th and they look very similar with
>>> similar number of lines. Just making sure I don't need to dig into
>>> the automasscheck scripts on the new server to find a problem.
>> Yes, I am concerned that 72_scores.cf is too small.
>>
>> Checking 1799061 with a 3.4 branch, I show 47 lines and 2867 bytes.
>>
>> Comparing
>> http://svn.apache.org/repos/asf/spamassassin/tags/sa-update_3.4.2_20170315085034/rulesrc/scores/72_scores.cf
>> shows that it was 144 lines and 9810 bytes.
>>
>> What versions are you checking? Maybe I'm not checking apples to apples.
>>
> I think you compare the right thing, theres a big difference between those
> tags. So I am also curious which 72_scores.cf David is looking at (march
> 15th).
>
> And its really strange why HEADER_FROM_DIFFERENT_DOMAINS has been scored 0
> in the full net + bayes mode. Does the scoring process output debug
> information when it disables a rule? Or is it some kind of rounding issue,
> maybe trying to assign a score lower than 0.001?
>
>> I checked dependencies on the ASF SA-vm1 and only Digest::SHA1 was
>> missing so I don't think that is it. I also checked my work on SHA256
>> and it's not colliding nor have I committed it to a central repo.
>>
>> Overall I do not have lint problems with the current version but my
>> biggest concern is again apples to apples. Perhaps I'm not checking
>> something correctly.
>>
>> Regards,
>>
>> KAM
>>
>>
My day job has had me very busy lately traveling so I will look at this
on Saturday morning when I have some free time to concentrate on this.
It seems like an issue that is very deep down in the scripts that will
be hard to find.
One thing that looks interesting is that the new "broken" 72_scores.cf
file is stopping at "score MILLION_USD" most of the time and is just
under 4K in size:
https://svn.apache.org/viewvc/spamassassin/tags/sa-update_3.4.2_20170610083046/rulesrc/scores/72_scores.cf?r1=1798299&r2=1786484&sortby=date&diff_format=h
Dave
Re: Errors since upgrading to 3.4.1: "meta test ... with a zero
score"
Posted by Dave Jones <da...@apache.org>.
On 06/20/2017 03:24 AM, Merijn van den Kroonenberg wrote:
>> On 6/19/2017 8:56 AM, David Jones wrote:
>>> Does 72_scores.cf look OK lately? I just downloaded the latest rules
>>> set and an old one from March 15th and they look very similar with
>>> similar number of lines. Just making sure I don't need to dig into
>>> the automasscheck scripts on the new server to find a problem.
>> Yes, I am concerned that 72_scores.cf is too small.
>>
>> Checking 1799061 with a 3.4 branch, I show 47 lines and 2867 bytes.
>>
>> Comparing
>> http://svn.apache.org/repos/asf/spamassassin/tags/sa-update_3.4.2_20170315085034/rulesrc/scores/72_scores.cf
>> shows that it was 144 lines and 9810 bytes.
>>
>> What versions are you checking? Maybe I'm not checking apples to apples.
>>
> I think you compare the right thing, theres a big difference between those
> tags. So I am also curious which 72_scores.cf David is looking at (march
> 15th).
>
> And its really strange why HEADER_FROM_DIFFERENT_DOMAINS has been scored 0
> in the full net + bayes mode. Does the scoring process output debug
> information when it disables a rule? Or is it some kind of rounding issue,
> maybe trying to assign a score lower than 0.001?
>
>> I checked dependencies on the ASF SA-vm1 and only Digest::SHA1 was
>> missing so I don't think that is it. I also checked my work on SHA256
>> and it's not colliding nor have I committed it to a central repo.
>>
>> Overall I do not have lint problems with the current version but my
>> biggest concern is again apples to apples. Perhaps I'm not checking
>> something correctly.
>>
>> Regards,
>>
>> KAM
>>
>>
>
I have manually reverted the 72_scores.cf back to mid March with the
current ruleset. This should fix the low scoring on many rules reported
on the users list and other mailing lists related to SA (i.e.
MailScanner). We will hold here for a little while until I can figure
out what is going on with the build scripts on the new server.
I manually tested this new ruleset on my production servers. They
installed and linted fine.
Dave
Re: Errors since upgrading to 3.4.1: "meta test ... with a zero
score"
Posted by Merijn van den Kroonenberg <me...@web2all.nl>.
> On 6/19/2017 8:56 AM, David Jones wrote:
>> Does 72_scores.cf look OK lately? I just downloaded the latest rules
>> set and an old one from March 15th and they look very similar with
>> similar number of lines. Just making sure I don't need to dig into
>> the automasscheck scripts on the new server to find a problem.
>
> Yes, I am concerned that 72_scores.cf is too small.
>
> Checking 1799061 with a 3.4 branch, I show 47 lines and 2867 bytes.
>
> Comparing
> http://svn.apache.org/repos/asf/spamassassin/tags/sa-update_3.4.2_20170315085034/rulesrc/scores/72_scores.cf
> shows that it was 144 lines and 9810 bytes.
>
> What versions are you checking? Maybe I'm not checking apples to apples.
>
I think you compare the right thing, theres a big difference between those
tags. So I am also curious which 72_scores.cf David is looking at (march
15th).
And its really strange why HEADER_FROM_DIFFERENT_DOMAINS has been scored 0
in the full net + bayes mode. Does the scoring process output debug
information when it disables a rule? Or is it some kind of rounding issue,
maybe trying to assign a score lower than 0.001?
> I checked dependencies on the ASF SA-vm1 and only Digest::SHA1 was
> missing so I don't think that is it. I also checked my work on SHA256
> and it's not colliding nor have I committed it to a central repo.
>
> Overall I do not have lint problems with the current version but my
> biggest concern is again apples to apples. Perhaps I'm not checking
> something correctly.
>
> Regards,
>
> KAM
>
>
Re: Errors since upgrading to 3.4.1: "meta test ... with a zero
score"
Posted by "Kevin A. McGrail" <ke...@mcgrail.com>.
On 6/19/2017 8:56 AM, David Jones wrote:
> Does 72_scores.cf look OK lately? I just downloaded the latest rules
> set and an old one from March 15th and they look very similar with
> similar number of lines. Just making sure I don't need to dig into
> the automasscheck scripts on the new server to find a problem.
Yes, I am concerned that 72_scores.cf is too small.
Checking 1799061 with a 3.4 branch, I show 47 lines and 2867 bytes.
Comparing
http://svn.apache.org/repos/asf/spamassassin/tags/sa-update_3.4.2_20170315085034/rulesrc/scores/72_scores.cf
shows that it was 144 lines and 9810 bytes.
What versions are you checking? Maybe I'm not checking apples to apples.
I checked dependencies on the ASF SA-vm1 and only Digest::SHA1 was
missing so I don't think that is it. I also checked my work on SHA256
and it's not colliding nor have I committed it to a central repo.
Overall I do not have lint problems with the current version but my
biggest concern is again apples to apples. Perhaps I'm not checking
something correctly.
Regards,
KAM
Re: Errors since upgrading to 3.4.1: "meta test ... with a zero
score"
Posted by David Jones <dj...@ena.com.INVALID>.
On 06/16/2017 02:08 PM, John Hardin wrote:
> On Fri, 16 Jun 2017, RW wrote:
>
>> On Fri, 16 Jun 2017 10:56:30 -0700 (PDT)
>> John Hardin wrote:
>>
>>> That's odd, because is *does* appear in 72_scores.cf. The
>>> default-to-1-point behavior is if there is no score defined in the
>>> config files...
>>
>> It's not in mine.
>
> Ahhh, it disappeared overnight. It was there *yesterday* when I posted
> that snippet...
>
Does 72_scores.cf look OK lately? I just downloaded the latest rules
set and an old one from March 15th and they look very similar with
similar number of lines. Just making sure I don't need to dig into the
automasscheck scripts on the new server to find a problem.
--
David Jones
Re: Errors since upgrading to 3.4.1: "meta test ... with a zero
score"
Posted by John Hardin <jh...@impsec.org>.
On Fri, 16 Jun 2017, RW wrote:
> On Fri, 16 Jun 2017 10:56:30 -0700 (PDT)
> John Hardin wrote:
>
>> That's odd, because is *does* appear in 72_scores.cf. The
>> default-to-1-point behavior is if there is no score defined in the
>> config files...
>
> It's not in mine.
Ahhh, it disappeared overnight. It was there *yesterday* when I posted
that snippet...
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Vista is at best mildly annoying and at worst makes you want to
rush to Redmond, Wash. and rip somebody's liver out. -- Forbes
-----------------------------------------------------------------------
2 days until SWMBO's Birthday
Re: Errors since upgrading to 3.4.1: "meta test ... with a zero
score"
Posted by RW <rw...@googlemail.com>.
On Fri, 16 Jun 2017 10:56:30 -0700 (PDT)
John Hardin wrote:
> That's odd, because is *does* appear in 72_scores.cf. The
> default-to-1-point behavior is if there is no score defined in the
> config files...
It's not in mine.
Re: Errors since upgrading to 3.4.1: "meta test ... with a zero
score"
Posted by "Kevin A. McGrail" <ke...@mcgrail.com>.
On 6/16/2017 1:56 PM, John Hardin wrote:
> On Fri, 16 Jun 2017, Merijn van den Kroonenberg wrote:
>
>>> On Thu, 15 Jun 2017, Gerald Turner wrote:
>>>
>>> score HEADER_FROM_DIFFERENT_DOMAINS 0.001 0.000 0.001 0.000
>>
>> Yes I think something is wrong, here the 'HEADER_FROM_DIFFERENT_DOMAINS'
>> rule gets scored at 1 since the 8th. That doesn't sound right as it hits
>> on a lot of ham.
>
> That's odd, because is *does* appear in 72_scores.cf. The
> default-to-1-point behavior is if there is no score defined in the
> config files...
>
My thoughts are that perhaps the new ruleqa box doesn't have some
dependency modules which is messing things up.
Re: Errors since upgrading to 3.4.1: "meta test ... with a zero
score"
Posted by John Hardin <jh...@impsec.org>.
On Fri, 16 Jun 2017, Merijn van den Kroonenberg wrote:
>> On Thu, 15 Jun 2017, Gerald Turner wrote:
>>
>> score HEADER_FROM_DIFFERENT_DOMAINS 0.001 0.000 0.001 0.000
>
> Yes I think something is wrong, here the 'HEADER_FROM_DIFFERENT_DOMAINS'
> rule gets scored at 1 since the 8th. That doesn't sound right as it hits
> on a lot of ham.
That's odd, because is *does* appear in 72_scores.cf. The
default-to-1-point behavior is if there is no score defined in the config
files...
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Our government should bear in mind the fact that the American
Revolution was touched off by the then-current government
attempting to confiscate firearms from the people.
-----------------------------------------------------------------------
2 days until SWMBO's Birthday
Re: Errors since upgrading to 3.4.1: "meta test ... with a zero
score"
Posted by Merijn van den Kroonenberg <me...@web2all.nl>.
> On Thu, 15 Jun 2017, Gerald Turner wrote:
>
>> spamd[32137]: rules: meta test FREEMAIL_FORGED_FROMDOMAIN has
>> dependency 'HEADER_FROM_DIFFERENT_DOMAINS' with a zero score
>> [snip]
>> - Is there a bug with the project's sa-update channel / auto-
>> mass-check setup?
>
> That's what it sounds like to me - it should not be omitting or zeroing
> the scores of rules that participate in metas.
>
> Something is odd. This didn't come up on the old masscheck host, but the
> score generation code should not have changed since then...
>
> It looks like it's not setting both the net and non-net scores for a few
> rules:
>
> score FROM_IN_TO_AND_SUBJ 1.099 0.000 1.099 0.000
> score HEADER_FROM_DIFFERENT_DOMAINS 0.001 0.000 0.001 0.000
> score HK_SCAM_N8 2.506 0.000 2.506 0.000
> score LOTTO_AGENT 2.609 0.000 2.609 0.000
>
> The non-network-enabled scores should only be zero for rules marked as
> being network-dependent rules, and *all* rules should have a nonzero
> network-enabled score (which appears to be the problem here).
>
> Something else odd is going on in the score generation: some
> well-performing rules (notably URI_WP_HACKED) are now getting scored at 1
> point. There are only 56 rules listed in 72_scores.cf (the output from the
> masscheck score generator), the rest would be defaulting to 1 point.
>
Yes I think something is wrong, here the 'HEADER_FROM_DIFFERENT_DOMAINS'
rule gets scored at 1 since the 8th. That doesn't sound right as it hits
on a lot of ham.
>
> --
> John Hardin KA7OHZ http://www.impsec.org/~jhardin/
> jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
> key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
> -----------------------------------------------------------------------
> If you ask amateurs to act as front-line security personnel,
> you shouldn't be surprised when you get amateur security.
> -- Bruce Schneier
> -----------------------------------------------------------------------
> 3 days until SWMBO's Birthday
>
Re: Errors since upgrading to 3.4.1: "meta test ... with a zero score"
Posted by Gerald Turner <gt...@unzane.com>.
On Thu, Jun 15 2017, John Hardin wrote:
> On Thu, 15 Jun 2017, Gerald Turner wrote:
>> spamd[32137]: rules: meta test FREEMAIL_FORGED_FROMDOMAIN has dependency 'HEADER_FROM_DIFFERENT_DOMAINS' with a zero score
>> 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
>
>> - Is there a bug with the project's sa-update channel / auto-
>> mass-check setup?
>
> That's what it sounds like to me - it should not be omitting or
> zeroing the scores of rules that participate in metas.
>
> Something is odd. This didn't come up on the old masscheck host, but
> the score generation code should not have changed since then...
>
> It looks like it's not setting both the net and non-net scores for a
> few rules:
>
> score FROM_IN_TO_AND_SUBJ 1.099 0.000 1.099 0.000
> score HEADER_FROM_DIFFERENT_DOMAINS 0.001 0.000 0.001 0.000
> score HK_SCAM_N8 2.506 0.000 2.506 0.000
> score LOTTO_AGENT 2.609 0.000 2.609 0.000
>
> The non-network-enabled scores should only be zero for rules marked as
> being network-dependent rules, and *all* rules should have a nonzero
> network-enabled score (which appears to be the problem here).
>
> Something else odd is going on in the score generation: some
> well-performing rules (notably URI_WP_HACKED) are now getting scored
> at 1 point. There are only 56 rules listed in 72_scores.cf (the output
> from the masscheck score generator), the rest would be defaulting to 1
> point.
Uh oh!
FWIW my 3.004001/updates_spamassassin_org/72_scores.cf contains the same
lines:
# grep 0.000 72_scores.cf
score FROM_IN_TO_AND_SUBJ 1.099 0.000 1.099 0.000
score HEADER_FROM_DIFFERENT_DOMAINS 0.001 0.000 0.001 0.000
score HK_SCAM_N8 2.506 0.000 2.506 0.000
score LOTTO_AGENT 2.609 0.000 2.609 0.000
--
Gerald Turner <gt...@unzane.com> Encrypted mail preferred!
OpenPGP: 4096R / CA89 B27A 30FA 66C5 1B80 3858 EC94 2276 FDB8 716D
Re: Errors since upgrading to 3.4.1: "meta test ... with a zero
score"
Posted by John Hardin <jh...@impsec.org>.
On Thu, 15 Jun 2017, Gerald Turner wrote:
> spamd[32137]: rules: meta test FREEMAIL_FORGED_FROMDOMAIN has dependency 'HEADER_FROM_DIFFERENT_DOMAINS' with a zero score
> 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
> - Is there a bug with the project's sa-update channel / auto-
> mass-check setup?
That's what it sounds like to me - it should not be omitting or zeroing
the scores of rules that participate in metas.
Something is odd. This didn't come up on the old masscheck host, but the
score generation code should not have changed since then...
It looks like it's not setting both the net and non-net scores for a few
rules:
score FROM_IN_TO_AND_SUBJ 1.099 0.000 1.099 0.000
score HEADER_FROM_DIFFERENT_DOMAINS 0.001 0.000 0.001 0.000
score HK_SCAM_N8 2.506 0.000 2.506 0.000
score LOTTO_AGENT 2.609 0.000 2.609 0.000
The non-network-enabled scores should only be zero for rules marked as
being network-dependent rules, and *all* rules should have a nonzero
network-enabled score (which appears to be the problem here).
Something else odd is going on in the score generation: some
well-performing rules (notably URI_WP_HACKED) are now getting scored at 1
point. There are only 56 rules listed in 72_scores.cf (the output from the
masscheck score generator), the rest would be defaulting to 1 point.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
If you ask amateurs to act as front-line security personnel,
you shouldn't be surprised when you get amateur security.
-- Bruce Schneier
-----------------------------------------------------------------------
3 days until SWMBO's Birthday
Re: Errors since upgrading to 3.4.1: "meta test ... with a zero score"
Posted by Gerald Turner <gt...@unzane.com>.
On Thu, Jun 15 2017, David Jones wrote:
> On 06/15/2017 06:42 PM, Gerald Turner wrote:
>> 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.
Interesting. I had these files in /var/lib/spamassassin:
# ls -l
drwxr-xr-x 3 debian-spamd debian-spamd 4096 May 5 2013 3.003001
drwxr-xr-x 3 debian-spamd debian-spamd 4096 Apr 23 2015 3.003002
drwxr-xr-x 3 debian-spamd debian-spamd 4096 Jun 11 07:09 3.004000
drwxr-xr-x 3 debian-spamd debian-spamd 4096 Jun 15 06:47 3.004001
drwxr-xr-x 6 debian-spamd debian-spamd 4096 Jun 11 13:25 compiled
drwx------ 3 debian-spamd debian-spamd 4096 Jun 11 13:55 sa-update-keys
# ls -l compiled
drwxr-xr-x 3 debian-spamd debian-spamd 4096 Sep 3 2010 5.010
drwxr-xr-x 3 debian-spamd debian-spamd 4096 May 5 2013 5.014
drwxr-xr-x 3 debian-spamd debian-spamd 4096 Apr 26 2015 5.020
drwxr-xr-x 3 debian-spamd debian-spamd 4096 Jun 11 13:25 5.024
I removed *all* of these directories except for sa-update-keys, then
re-ran sa-update and sa-compile, resulting in much cleaner
/var/lib/spamassassin directory:
# ls -l
drwxr-xr-x 3 debian-spamd debian-spamd 4096 Jun 15 17:54 3.004001
drwxr-xr-x 3 debian-spamd debian-spamd 4096 Jun 15 17:55 compiled
drwx------ 3 debian-spamd debian-spamd 4096 Jun 11 13:55 sa-update-keys
# ls -l compiled
drwxrwxr-x 3 debian-spamd debian-spamd 4096 Jun 15 17:55 5.024
>> - 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.
I hope not either. Apologies for insinuating updates are bugged. Your
work on SA is much appreciated, thanks! :)
>> 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)'
This resulted in:
Jun 15 17:56:03.036 [12601] dbg: diag: [...] module not installed: Digest::SHA1 ('require' failed)
Jun 15 17:56:03.036 [12601] dbg: diag: [...] module not installed: Geo::IP ('require' failed)
Jun 15 17:56:03.036 [12601] dbg: diag: [...] module not installed: Net::CIDR::Lite ('require' failed)
Jun 15 17:56:03.037 [12601] dbg: diag: [...] module not installed: Encode::Detect::Detector ('require' failed)
Jun 15 17:56:03.037 [12601] dbg: diag: [...] module not installed: Net::Patricia ('require' failed)
Jun 15 17:56:03.945 [12601] dbg: config: warning: score set for non-existent rule FILL_THIS_FORM_FRAUD_PHISH
Jun 15 17:56:03.945 [12601] dbg: config: warning: score set for non-existent rule RCVD_IN_SORBS_SPAM
Jun 15 17:56:03.946 [12601] dbg: config: warning: score set for non-existent rule URI_OBFU_WWW
Much of these Perl modules are packaged as Recommends/Suggests metadata
to the Debian spamassassin package. Installed all of them except for
for Digest::SHA1 - I believe there must have been a historical change
from Digest::SHA1 to Digest::SHA, and SA has compatibility to load
either - at least that's my understanding after poking around SA's
source a bit.
[INSTALL, DEPENDENCIES] libdigest-sha-perl:amd64 5.96-1+b1
[INSTALL, DEPENDENCIES] libencode-detect-perl:amd64 1.01-4+b3
[INSTALL, DEPENDENCIES] libgeo-ip-perl:amd64 1.50-1+b1
[INSTALL, DEPENDENCIES] libnet-patricia-perl:amd64 1.22-1+b3
[INSTALL, DEPENDENCIES] libnet-cidr-lite-perl:amd64 0.21-1
Sadly, after this long overdue pass at SA cleanup, I still have the zero
score warnings:
spamd[12588]: rules: meta test __MONEY_FRAUD_8 has dependency 'LOTTO_AGENT' with a zero score
spamd[12588]: rules: meta test __ADVANCE_FEE_2_NEW has dependency 'LOTTO_AGENT' with a zero score
spamd[12588]: rules: meta test FREEMAIL_FORGED_FROMDOMAIN has dependency 'HEADER_FROM_DIFFERENT_DOMAINS' with a zero score
spamd[12588]: rules: meta test __ADVANCE_FEE_5_NEW has dependency 'LOTTO_AGENT' with a zero score
spamd[12588]: rules: meta test __FORM_FRAUD has dependency 'LOTTO_AGENT' with a zero score
spamd[12588]: rules: meta test __ADVANCE_FEE_3_NEW has dependency 'LOTTO_AGENT' with a zero score
spamd[12588]: rules: meta test __MONEY_FRAUD_5 has dependency 'LOTTO_AGENT' with a zero score
spamd[12588]: rules: meta test __FORM_FRAUD_3 has dependency 'LOTTO_AGENT' with a zero score
spamd[12588]: rules: meta test __FORM_FRAUD_5 has dependency 'LOTTO_AGENT' with a zero score
spamd[12588]: rules: meta test __ADVANCE_FEE_4_NEW has dependency 'LOTTO_AGENT' with a zero score
spamd[12588]: rules: meta test __MONEY_FRAUD_3 has dependency 'LOTTO_AGENT' with a zero score
--
Gerald Turner <gt...@unzane.com> Encrypted mail preferred!
OpenPGP: 4096R / CA89 B27A 30FA 66C5 1B80 3858 EC94 2276 FDB8 716D
Re: Errors since upgrading to 3.4.1: "meta test ... with a zero
score"
Posted by David Jones <dj...@ena.com>.
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