You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by "Lawrence @ Rogers" <la...@nl.rogers.com> on 2011/10/13 04:02:38 UTC
SA 3.3.1 bug or mistake in my custom rules?
Hi,
I am using SpamAssassin 3.3.1 (cPanel) with latest rule updates.
Starting today, I've noticed that 3 of my rules fire in situations where
they should not. They are simple meta rules that count how many rule,
against certain URIBL rules, fire. They then raise the spam score.
They are as follows
---------------------------------------------------------------------------------------------
meta LW_URIBL_LO ((URIBL_BLACK + URIBL_RED + URIBL_SBL + URIBL_AB_SURBL
+ URIBL_JP_SURBL + URIBL_OB_SURBL + URIBL_PH_SURBL + URIBL_SC_SURBL +
URIBL_WS_SURBL) == 1)
meta LW_URIBL_MD ((URIBL_BLACK + URIBL_RED + URIBL_SBL + URIBL_AB_SURBL
+ URIBL_JP_SURBL + URIBL_OB_SURBL + URIBL_PH_SURBL + URIBL_SC_SURBL +
URIBL_WS_SURBL + URIBL_RHS_DOB) == 2)
meta LW_URIBL_HI ((URIBL_BLACK + URIBL_RED + URIBL_SBL + URIBL_AB_SURBL
+ URIBL_JP_SURBL + URIBL_OB_SURBL + URIBL_PH_SURBL + URIBL_SC_SURBL +
URIBL_WS_SURBL + URIBL_RHS_DOB) > 2)
score LW_URIBL_LO 1.5
tflags LW_URIBL_LO net
score LW_URIBL_MD 3.0
tflags LW_URIBL_MD net
score LW_URIBL_HI 4.5
tflags LW_URIBL_HI net
---------------------------------------------------------------------------------------------
I'm receiving e-mails where both LW_URIBL_LO and LW_URIBL_MD are fired.
The only rule in the message that could trigger them are URIBL_DBL_SPAM
and URIBL_RHS_DOB
Any thoughts?
Regards,
Lawrence
Re: Results of eval and meta rules
Posted by "Lawrence @ Rogers" <la...@nl.rogers.com>.
On 13/10/2011 9:01 PM, Karsten Bräckelmann wrote:
> On Thu, 2011-10-13 at 03:57 -0230, Lawrence @ Rogers wrote:
>> On 13/10/2011 1:45 AM, Karsten Bräckelmann wrote:
>>> In a related note, as per the M::SA::Conf docs for meta rules -- "The
>>> value of a hit meta test is that of its arithmetic expression. The value
>>> of a hit eval test is that returned by its method."
>>>
>>> The latter means, this style of adding "rules" is not necessarily safe,
>>> since these are eval tests. However, in this case, I believe they all
>>> should be set to 1 in case of a match.
>>>
>>> The former means, you could eliminate such issues due to inconsistencies
>>> and code duplication, by using an additional meta level:
>>>
>>> meta __VALUE FOO + BAR
>>>
>>> meta ONE __VALUE == 1
>>> meta TWO __VALUE == 2
>> I don't know how I overlooked that omission in the first rule :)
> In particular, since these rules are not exactly complex, and seeing
> them side by side... ;)
>
> Anyway, that's why I also included a way, to prevent this from ever
> happening. Define once, don't duplicate code, simply by adding another
> meta rule level.
>
>
>> Thanks, it's working as expected now.
>>
>> I designed the rules using the information available on
>> http://wiki.apache.org/spamassassin/WritingRules
>>
>> Under "Meta rules"
>>
>> It has this rule
>>
>> meta LOCAL_MULTIPLE_TESTS (( __LOCAL_TEST1 + __LOCAL_TEST2 +
>> __LOCAL_TEST3)> 1)
>>
>> "The value of the sub rule in an arithmetic meta rule is the true/false
>> (1/0) value for whether or not the rule hit. "
>>
>> If this is incorrect, perhaps this documentation should be updated.
> Well, incorrect... Put into easy terms, I'd say. It's intended as a
> quick-start tutorial. After that, I seriously recommend having a look
> into the full documentation.
>
> There are two points here:
>
> "The value of a hit eval test is that returned by its method."
>
> Which, I believe (without looking at the code) is generally the boolean
> value as mentioned in the wiki. Including the URI DNSBL eval rules you
> are using.
>
> However, and that was mostly meant as a heads-up, it MAY NOT hold true
> always, since eval rules MAY return something else.
>
> "The value of a hit meta test is that of its arithmetic expression."
>
> This also most likely is generally the boolean value. Definitely in the
> example given, since the (non-boolean!) sub-result of the arithmetic
> expression then is compared against a number -- either true, of false.
>
> The trick is, to keep the duplicated arithmetic sub-expression in a
> single meta, and use that result for your comparison. Using the
> supported, though generally not used feature for your benefit.
>
>
Thanks for the info :)
Regards,
Lawrence
Results of eval and meta rules (was: Re: SA 3.3.1 bug or mistake
in my custom rules?)
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Thu, 2011-10-13 at 03:57 -0230, Lawrence @ Rogers wrote:
> On 13/10/2011 1:45 AM, Karsten Bräckelmann wrote:
> > In a related note, as per the M::SA::Conf docs for meta rules -- "The
> > value of a hit meta test is that of its arithmetic expression. The value
> > of a hit eval test is that returned by its method."
> >
> > The latter means, this style of adding "rules" is not necessarily safe,
> > since these are eval tests. However, in this case, I believe they all
> > should be set to 1 in case of a match.
> >
> > The former means, you could eliminate such issues due to inconsistencies
> > and code duplication, by using an additional meta level:
> >
> > meta __VALUE FOO + BAR
> >
> > meta ONE __VALUE == 1
> > meta TWO __VALUE == 2
> I don't know how I overlooked that omission in the first rule :)
In particular, since these rules are not exactly complex, and seeing
them side by side... ;)
Anyway, that's why I also included a way, to prevent this from ever
happening. Define once, don't duplicate code, simply by adding another
meta rule level.
> Thanks, it's working as expected now.
>
> I designed the rules using the information available on
> http://wiki.apache.org/spamassassin/WritingRules
>
> Under "Meta rules"
>
> It has this rule
>
> meta LOCAL_MULTIPLE_TESTS (( __LOCAL_TEST1 + __LOCAL_TEST2 +
> __LOCAL_TEST3) > 1)
>
> "The value of the sub rule in an arithmetic meta rule is the true/false
> (1/0) value for whether or not the rule hit. "
>
> If this is incorrect, perhaps this documentation should be updated.
Well, incorrect... Put into easy terms, I'd say. It's intended as a
quick-start tutorial. After that, I seriously recommend having a look
into the full documentation.
There are two points here:
"The value of a hit eval test is that returned by its method."
Which, I believe (without looking at the code) is generally the boolean
value as mentioned in the wiki. Including the URI DNSBL eval rules you
are using.
However, and that was mostly meant as a heads-up, it MAY NOT hold true
always, since eval rules MAY return something else.
"The value of a hit meta test is that of its arithmetic expression."
This also most likely is generally the boolean value. Definitely in the
example given, since the (non-boolean!) sub-result of the arithmetic
expression then is compared against a number -- either true, of false.
The trick is, to keep the duplicated arithmetic sub-expression in a
single meta, and use that result for your comparison. Using the
supported, though generally not used feature for your benefit.
--
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; }}}
Re: SA 3.3.1 bug or mistake in my custom rules?
Posted by "Lawrence @ Rogers" <la...@nl.rogers.com>.
On 13/10/2011 1:45 AM, Karsten Bräckelmann wrote:
> On Wed, 2011-10-12 at 23:32 -0230, Lawrence @ Rogers wrote:
>> Starting today, I've noticed that 3 of my rules fire in situations where
>> they should not. They are simple meta rules that count how many rule,
>> against certain URIBL rules, fire. They then raise the spam score.
>> meta LW_URIBL_LO ((URIBL_BLACK + URIBL_RED + URIBL_SBL + URIBL_AB_SURBL
>> + URIBL_JP_SURBL + URIBL_OB_SURBL + URIBL_PH_SURBL + URIBL_SC_SURBL +
>> URIBL_WS_SURBL) == 1)
> URIBL_RHS_DOB is missing here.
>
>> meta LW_URIBL_MD ((URIBL_BLACK + URIBL_RED + URIBL_SBL + URIBL_AB_SURBL
>> + URIBL_JP_SURBL + URIBL_OB_SURBL + URIBL_PH_SURBL + URIBL_SC_SURBL +
>> URIBL_WS_SURBL + URIBL_RHS_DOB) == 2)
>>
>> meta LW_URIBL_HI [...]
>> I'm receiving e-mails where both LW_URIBL_LO and LW_URIBL_MD are fired.
> That would happen, if URIBL_RHS_DOB and another rule of the LO meta
> variant are hit.
>
>> The only rule in the message that could trigger them are URIBL_DBL_SPAM
>> and URIBL_RHS_DOB
> DBL is not part of the meta, so I don't get this. Or did you actually
> mean to communicate, these are the only URI DNSBL rules triggered? That
> would be even more confusing -- a real Status header copied would have
> helped...
>
> The above rules are *verbatim*, copy and paste from your rc files, with
> no human messing around, right?
>
>
> In a related note, as per the M::SA::Conf docs for meta rules -- "The
> value of a hit meta test is that of its arithmetic expression. The value
> of a hit eval test is that returned by its method."
>
> The latter means, this style of adding "rules" is not necessarily safe,
> since these are eval tests. However, in this case, I believe they all
> should be set to 1 in case of a match.
>
> The former means, you could eliminate such issues due to inconsistencies
> and code duplication, by using an additional meta level:
>
> meta __VALUE FOO + BAR
>
> meta ONE __VALUE == 1
> meta TWO __VALUE == 2
>
>
Hi Karsten,
I don't know how I overlooked that omission in the first rule :)
Thanks, it's working as expected now.
I designed the rules using the information available on
http://wiki.apache.org/spamassassin/WritingRules
Under "Meta rules"
It has this rule
meta LOCAL_MULTIPLE_TESTS (( __LOCAL_TEST1 + __LOCAL_TEST2 +
__LOCAL_TEST3) > 1)
"The value of the sub rule in an arithmetic meta rule is the true/false
(1/0) value for whether or not the rule hit. "
If this is incorrect, perhaps this documentation should be updated.
Regards,
Lawrence
Re: SA 3.3.1 bug or mistake in my custom rules?
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Wed, 2011-10-12 at 23:32 -0230, Lawrence @ Rogers wrote:
> Starting today, I've noticed that 3 of my rules fire in situations where
> they should not. They are simple meta rules that count how many rule,
> against certain URIBL rules, fire. They then raise the spam score.
> meta LW_URIBL_LO ((URIBL_BLACK + URIBL_RED + URIBL_SBL + URIBL_AB_SURBL
> + URIBL_JP_SURBL + URIBL_OB_SURBL + URIBL_PH_SURBL + URIBL_SC_SURBL +
> URIBL_WS_SURBL) == 1)
URIBL_RHS_DOB is missing here.
> meta LW_URIBL_MD ((URIBL_BLACK + URIBL_RED + URIBL_SBL + URIBL_AB_SURBL
> + URIBL_JP_SURBL + URIBL_OB_SURBL + URIBL_PH_SURBL + URIBL_SC_SURBL +
> URIBL_WS_SURBL + URIBL_RHS_DOB) == 2)
>
> meta LW_URIBL_HI [...]
> I'm receiving e-mails where both LW_URIBL_LO and LW_URIBL_MD are fired.
That would happen, if URIBL_RHS_DOB and another rule of the LO meta
variant are hit.
> The only rule in the message that could trigger them are URIBL_DBL_SPAM
> and URIBL_RHS_DOB
DBL is not part of the meta, so I don't get this. Or did you actually
mean to communicate, these are the only URI DNSBL rules triggered? That
would be even more confusing -- a real Status header copied would have
helped...
The above rules are *verbatim*, copy and paste from your rc files, with
no human messing around, right?
In a related note, as per the M::SA::Conf docs for meta rules -- "The
value of a hit meta test is that of its arithmetic expression. The value
of a hit eval test is that returned by its method."
The latter means, this style of adding "rules" is not necessarily safe,
since these are eval tests. However, in this case, I believe they all
should be set to 1 in case of a match.
The former means, you could eliminate such issues due to inconsistencies
and code duplication, by using an additional meta level:
meta __VALUE FOO + BAR
meta ONE __VALUE == 1
meta TWO __VALUE == 2
--
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; }}}