On Wed, 15 Jul 2009, Karsten Bräckelmann wrote:
Actually, in this very rule, the negative look-ahead is useless and
won't match the remaining part of the RE anyway.
Correct. Because this is my 'live' .cf file, I have modified the 'working'
rule (05) to minimize false positives (in the old fashioned way) so I
could raise its score, then, to avoid accusations that rule 01 and rule
05 are not 'identical' I inserted that extra code into rule 01 (and
again, to be clear, and certain there were no invisible characters, I
actually fixed up rule 01, then cut-n-pasted it to make a new rule 05,
and removed the look-ahead from 05).
Yes, it makes the look-ahead "useless", but the rule SHOULD still trigger.
I should be able to remove that complicated either-or code in the rule
(which actually does not cover *all* possible obfuscations) and have the
negative look-ahead handle the one true false negative.
Given that the negative look-ahead actually does nothing, but yet
prevents the RE from matching when added -- this either is a bug with
your Perl (assuming the ONLY difference is the added negative look-
ahead), or the assumption doesn't hold and the REs actually are not
identical.
I am going to play with it a bit more right now. I've reduced the negative
look-ahead to (?!www\.[a-z0-9]+\.net) and we'll see if.www .pe31. net
still triggers only one rule....
- Charles
