parsing rules files & finding offensive lines

[Mariano Absatz]

It's not that... further investigation shows that the problem is during 
message processing, when the regexp itself is invalid, so it's not a 
"ruleset syntax problem" but a "regexp syntax problem".

But, man... lookin' at the code, this has changed wildly since 4.23-11 I 
have up and runnin...

I'll solve my problem on my small CGI... I tried to follow all of the new 
Config.pm, but this is being done in several places so as to make a quick 
fix.

The idea to solve this problem is, once you have the actual regular 
expression that will be stored as part of the rule, you should verify it 
by trying to compile it...

Maybe inside RuleToRegexp (in several places) is the right place to put 
something this:

# supose $regexp has the "final" regexp to be used by this rule
my $evalok, $compiledre;
$evalok = eval {$compiledre = qr/$regexp/i;} ;
unless ($evalok) {
  MailScanner::Log::WarnLog("Invalid regular expression: %s. ".
           "RE compiler said: %s",$regexp,$@);
  $regexp = '/^$/';
}

The idea is to ignore wrong regexps (loggin'g them, obviously... maybe 
include the file/line where this was found), but keep working.

Maybe this can (should?) be done inside Config::Value when the regexp is 
actually compiled (that is , eval'ing the actual regexp compilation)... 
Sorry, I didn't follow all of the logic.

El 27 Nov 2003 a las 8:49, Julian Field escribió:

> Fixed.
> Apply this to /usr/lib/MailScanner/MailScanner/Config.pm
> 
> --- Config.pm.old  2003-11-19 15:31:19.000000000 +0000
> +++ Config.pm   2003-11-27 08:49:28.000000000 +0000
> @@ -1777,8 +1777,8 @@
>     flock($rulesfh, $LOCK_UN);
>     $rulesfh->close();
> 
> -  MailScanner::Log::DieLog("Aborting due to syntax errors in %s.",
> -                           $rulesfilename) if $errors;
> +  MailScanner::Log::WarnLog("Error: Syntax errors in %s.", $rulesfilename)
> +    if $errors;
>   }
> 
> 
> 
> At 20:23 26/11/2003, you wrote:
> >Hi,
> >
> >we have an installation with a sysadmin who is able (kind of) to create
> >whitelist & blacklist rules.
> >
> >We did a rough web page for him to add address patterns to block or
> >whitelist and then create the spam.whitelist.rules and
> >spam.blacklist.rules from there.
> >
> >Now, if a rule has a problem in the pattern, MailScanner happily (and
> >silently) dies...
> >
> >Typical problems are patterns like that must include a "+" or "="...
> >these have to be prepended by a "\".
> >
> >The question is, is there a way to verify a rule is correct (at least to
> >the point of _not_ making MailScanner silently die)?
> >
> >I'd like to verify rulesets (or better yet individual rules) off-line so
> >I can warn the user (or at least forbid him to apply the new ruleset).
> >
> >For what I saw, ruleset processing is deep inside MailScanner::Config
> >
> >--
> >Mariano Absatz
> >El Baby
> >----------------------------------------------------------
> >The primary purpose of the DATA statement is to give names to
> >constants; instead of referring to pi as 3.141592653589793 at
> >every appearance, the variable pi can be given that value with
> >a DATA statementand used instead of the longer form of the constant.
> >This alsosimplifies modifying the program, should the value of pi
> >change.
> >                          -- FORTRAN manual for Xerox computers
> 
> --
> Julian Field
> www.MailScanner.info
> MailScanner thanks transtec Computers for their support
> 
> PGP footprint: EE81 D763 3DB0 0BFD E1DC  7222 11F6 5947 1415 B654


--
Mariano Absatz
El Baby
----------------------------------------------------------
Friends help you move. Real friends help you move bodies.