You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Giampaolo Tomassoni <g....@libero.it> on 2010/04/27 14:21:07 UTC

Score overriding and behaviour

Hi everybody.

Recently I updated my Gentoo installations to spamassassin-3.3.1-r1 (the
'r1' thing means a 'stock' SA-3.3.1 with some -often few - patches applied).

Everything worked fine after upgrading, but now I see that some rules I have
in my local.cf doesn't seem to work anymore.

Since they are very simple, I'm wondering why.

These rules were used to reverse the score points added by the FRT_SOMA and
FRT_SOMA2 rules when the text was in Italian and the word "somma" (which
means "amount" in English) was present. You may understand that this word is
quite common in business messages, so I had to place these:

...
body      __SOMMA       m'\Wsomma\W'i

meta      SOMMA         ( FRT_SOMA && __IN_ITALIAN && __SOMMA )
describe  SOMMA         E' somma...
score     SOMMA         -2.300
score     FRT_SOMA      2.300

meta      SOMMA2        ( FRT_SOMA2 && __IN_ITALIAN && __SOMMA )
describe  SOMMA2        E' sempre somma...
score     SOMMA2        -2.200
score     FRT_SOMA2     2.200
...


Now the problem I see. First, __SOMMA doesn't trigger anymore, thereby SOMMA
and SOMMA2 don't too.

The second problem is that the FRT_SOMA and FRT_SOMA2 score override don't
work too: I see they respectively score 2.871 and 0.001, which are the ones
assigned to them by the current
3.003001/updates_spamassassin_org/50_scores.cf file by sa-update.

Both the effects are quite weird to me. Maybe I didn't pay attention to some
post in this list announcing a different behaviour of the body rules and a
new score override mechanism?

Thank you,

Giampaolo


RE: [sa] RE: Score overriding and behaviour

Posted by Giampaolo Tomassoni <g....@libero.it>.
> On Tue, 27 Apr 2010, Giampaolo Tomassoni wrote:
> >> Do ANY of the rules in your local.cf fire?
> > Yes, they do. The __IN_ITALIAN rule referred by SOMMA and SOMMA2, in
> > example.
> 
> Just a side thought, but are we checking for SOMMA or SOMA? One 'm' or
> two? FRT_SOMA2
> 
> Try 'retyping' the __SOMMA rule without the m' ....
> 
> body __SOMMA /\Wsomma\W/i
> 
> Also, look for a 'runaway' unclosed quote on a prior rule (though I
> would
> expect such a condition to barf error messages like crazy....)

I was checking for m/\Wsomma\W/i in body, but maybe the leading 'm' got
somehow removed in my typing. Or I should say "reoved", then?

However, you've probably already seen that I'm a dumb fish, since I forgot I
had disabled these (and others) rules by enclosing them in a if(0)...endif
block. This happened many months ago.

You know, now spamassassin is much more robust than at its starts. Now it is
a lot like a "setup-and-forget" product. I accomplished to this by
forgetting having disabled rules... :)

Sorry for bothering you and others,

Giampaolo


Re: [sa] RE: Score overriding and behaviour

Posted by Charles Gregory <cg...@hwcn.org>.
On Tue, 27 Apr 2010, Giampaolo Tomassoni wrote:
>> Do ANY of the rules in your local.cf fire?
> Yes, they do. The __IN_ITALIAN rule referred by SOMMA and SOMMA2, in
> example.

Just a side thought, but are we checking for SOMMA or SOMA? One 'm' or 
two? FRT_SOMA2

Try 'retyping' the __SOMMA rule without the m' ....

body __SOMMA /\Wsomma\W/i

Also, look for a 'runaway' unclosed quote on a prior rule (though I would 
expect such a condition to barf error messages like crazy....)

- C

RE: Score overriding and behaviour

Posted by Giampaolo Tomassoni <g....@libero.it>.
> Do ANY of the rules in your local.cf fire?

Yes, they do. The __IN_ITALIAN rule referred by SOMMA and SOMMA2, in
example.


However,

> Try putting a test rule that
> will 'always' fire (like 'header From =~ /\@/') at the end of local.cf,
> then if it doesn't fire, start moving it up, to see if you can home in
> on a line that is perhaps aborting further reading of local.cf....

bottom of local.cf:


header  ECERTO  From =~ /\@/


Score results:


 pts rule name              description
---- ----------------------
--------------------------------------------------
 ...
 1.0 ECERTO                 ECERTO
 2.9 FRT_SOMA               BODY: ReplaceTags: Soma
 0.0 FRT_SOMA2              BODY: ReplaceTags: Soma (2)
 ...



Never mind... (Was: RE: Score overriding and behaviour)

Posted by Giampaolo Tomassoni <g....@libero.it>.
It turn out I put this and other stuff in a if(0) endif block, such that it
of course didn't fire...

Thanks everybody!

Giampaolo



RE: Score overriding and behaviour

Posted by John Hardin <jh...@impsec.org>.
On Tue, 27 Apr 2010, Giampaolo Tomassoni wrote:

>> On Tue, 27 Apr 2010, Giampaolo Tomassoni wrote:
>>>  Also, why
>>>  body      __SOMMA       m'\Wsomma\W'i
>>>
>>>  doesn't fire?
>>
>> This is more a sylistic comment, but: you don't need to alter the
>> delimiters on that RE. Does this behave any better?
>>
>>     body      __SOMMA       /\Wsomma\W/i
>
> John, problem solved: these rows were all disabled being in a if(0)...endif
> block. I already posted a "I'm a dumb fish" statement about it.

Yeah, and I saw that just after hitting {send} on the above. :)

> I'm used to use m'...' because occasionally I have regexp with some '/' in
> it, so my special regexp rules are almost all that way.

That's reasonable, until you want to write a RE with a single quote in 
it... :)

>> That also won't hit if "somma" appears at the beginning or end of a
>> line. Perhaps this would work better?
>>
>>     body      __SOMMA       /\bsomma\b/i
>
> It would be almost always counter-productive. "Somma" is (like in english) a
> noun, so if it is early in a line, it is at least prefixed by an article:
> "LA somma è ..." ("The amount is ...")
>
> It very seldom may appear last in a row, since it would instead be followed
> by some '.,;': "Questa è la somma:".

OK.

-- 
  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
-----------------------------------------------------------------------
   The fetters imposed on liberty at home have ever been forged out
   of the weapons provided for defense against real, pretended, or
   imaginary dangers from abroad.               -- James Madison, 1799
-----------------------------------------------------------------------
  13 days since a sunspot last seen - EPA blames CO2 emissions

RE: Score overriding and behaviour

Posted by Giampaolo Tomassoni <g....@libero.it>.
> On Tue, 27 Apr 2010, Giampaolo Tomassoni wrote:
> >  Also, why
> >  body      __SOMMA       m'\Wsomma\W'i
> >
> >  doesn't fire?
> 
> This is more a sylistic comment, but: you don't need to alter the
> delimiters on that RE. Does this behave any better?
> 
>     body      __SOMMA       /\Wsomma\W/i

John, problem solved: these rows were all disabled being in a if(0)...endif
block. I already posted a "I'm a dumb fish" statement about it.

I'm used to use m'...' because occasionally I have regexp with some '/' in
it, so my special regexp rules are almost all that way. 


> That also won't hit if "somma" appears at the beginning or end of a
> line.
> Perhaps this would work better?
> 
>     body      __SOMMA       /\bsomma\b/i

It would be almost always counter-productive. "Somma" is (like in english) a
noun, so if it is early in a line, it is at least prefixed by an article:
"LA somma è ..." ("The amount is ...")

It very seldom may appear last in a row, since it would instead be followed
by some '.,;': "Questa è la somma:".

I may accept the writer to be an accountant/salesman. I can't accept he/she
writes in bad italian. If he/she does... well, it's FRT_SOMA time, which is
no big deal after all (a couple of spam points)... ;)

Thank you, anyway,

Giampaolo


Re: Score overriding and behaviour

Posted by John Hardin <jh...@impsec.org>.
On Tue, 27 Apr 2010, Giampaolo Tomassoni wrote:
>  Also, why
>  body      __SOMMA       m'\Wsomma\W'i
>
>  doesn't fire?

This is more a sylistic comment, but: you don't need to alter the 
delimiters on that RE. Does this behave any better?

    body      __SOMMA       /\Wsomma\W/i

That also won't hit if "somma" appears at the beginning or end of a line. 
Perhaps this would work better?

    body      __SOMMA       /\bsomma\b/i

-- 
  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 guards and searches and metal detectors can't keep a gun out of
   a maximum-security solitary confinement prisoner's cell, how will
   a disciplinary policy and some signs keep guns out of a university?
-----------------------------------------------------------------------
  13 days since a sunspot last seen - EPA blames CO2 emissions

Re: Score overriding and behaviour

Posted by Charles Gregory <cg...@hwcn.org>.
On Tue, 27 Apr 2010, Giampaolo Tomassoni wrote:
> Also, why
> body      __SOMMA       m'\Wsomma\W'i
>
> doesn't fire? I have the Rule2XSBody plugin active. Maybe somehow it wasn't
> compiled? But why, then?

Do ANY of the rules in your local.cf fire? Try putting a test rule that 
will 'always' fire (like 'header From =~ /\@/') at the end of local.cf, 
then if it doesn't fire, start moving it up, to see if you can home in on 
a line that is perhaps aborting further reading of local.cf....

- C



RE: Score overriding and behaviour

Posted by Giampaolo Tomassoni <g....@libero.it>.
> > Both the effects are quite weird to me. Maybe I didn't pay attention
> to some
> > post in this list announcing a different behaviour of the body rules
> and a
> > new score override mechanism?
> 
> No change in this logic and behavior.
> 
> Did you --lint check? Does it complain perhaps? To see which cf files
> are used, feed a mail to spamassassin -D.

Right, I do it when I change something. It doesn't complain at all.

I see this in the --lint -D output:


Apr 27 14:50:12.384 [31432] dbg: config: read file
/var/lib/spamassassin/3.003001/updates_spamassassin_org.cf


then, few lines below, I see:


Apr 27 14:50:12.385 [31432] dbg: config: read file
/etc/mail/spamassassin/local.cf


but I see the output talks about scores much later:


Apr 27 14:50:13.759 [31432] dbg: config: fixed relative path:
/var/lib/spamassassin/3.003001/updates_spamassassin_org/50_scores.cf
Apr 27 14:50:13.759 [31432] dbg: config: using
"/var/lib/spamassassin/3.003001/updates_spamassassin_org/50_scores.cf" for
included file
Apr 27 14:50:13.760 [31432] dbg: config: read file
/var/lib/spamassassin/3.003001/updates_spamassassin_org/50_scores.cf


Which may probably be why scores in local.cf are disregarded? Are they
basically overridden by 50_scores.cf, instead of being the contrary?

But then I can't remember any post about this matter...

Also, why


body      __SOMMA       m'\Wsomma\W'i


doesn't fire? I have the Rule2XSBody plugin active. Maybe somehow it wasn't
compiled? But why, then?

Giampaolo


Re: Score overriding and behaviour

Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Tue, 2010-04-27 at 14:21 +0200, Giampaolo Tomassoni wrote:
> Everything worked fine after upgrading, but now I see that some rules I have
> in my local.cf doesn't seem to work anymore.

> The second problem is that the FRT_SOMA and FRT_SOMA2 score override don't
> work too: I see they respectively score 2.871 and 0.001, which are the ones
> assigned to them by the current
> 3.003001/updates_spamassassin_org/50_scores.cf file by sa-update.
> 
> Both the effects are quite weird to me. Maybe I didn't pay attention to some
> post in this list announcing a different behaviour of the body rules and a
> new score override mechanism?

No change in this logic and behavior.

Did you --lint check? Does it complain perhaps? To see which cf files
are used, feed a mail to spamassassin -D.


-- 
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}