[Mimedefang] Fw: [Sare-users] Spam with numbers in subj and body

Wed Jun 7 12:02:36 EDT 2006

> There are no case-sensitive numbers, not even in UTF8. So out of the
> 270 possible characters that you are matching with that \d, the /i
> adds nothing. But that's not really important. At least you
> fixed the old /\d*/ match, which matched on _every_ string
> (because it matches the null string).

Thanks.  The /i change is a good catch.

>> body            __KAM_NUMBER2   /\d{1,6}/
>
> Same here: a wildcard at the end isn't useful, your match isn't
> anchored, and this matches everywhere /\d/ does. Maybe /^\d{1,6}$/m
> could be useful. I suppose even better would be something like:
>
> rawbody __RULENAME /^<html><body>\s+^\d+$/m

I still haven't received enough of the emails to further check but I believe 
the rule as it stands *in combination* with the other rules is adequate 
as-is.  I also don't try and make rules as pinpoint as this because I expect 
the spammers to evolve and I try and make the rule as generic as possible 
where it doesn't create an FP.

> Why don't you use __KAM_NUMBER1 && __KAM_NUMBER2 && MIME_HTML_ONLY
>    && HTML_SHORT_LENGTH

Because I often take rules in the next stage where they are not weighted 
equally.  See URUNIT rule or TIME PIECE for example.

> (If you add or
> remove a rule you have to update the count. Also the brackets
> aren't necessary).

I switch between too many program languages on a daily basis to remember 
mathematical precedence rules for all of them.  The use of extra parens is 
simply to be exact on the precedence I want applied. Going further, my 
mantra is that programming is a state of mind not a language.  Give me a 
syntax book, existing code and a some time to equilibrate and I can 
generally program in any language.

I'd also argue that programming guides I've read in the past and classes I 
took decades ago recommended more parens is always better than less so you 
don't have to worry what the precedence interpretation might be.

Regards,
KAM