bug in rule handling of filename rules

[Knutzen, Heinz (DZ-SH)]

There is a bug / problem in rule handling of filename rules.
When multiple rules apply to a single message,
then ALL filename rule files of all matching rules
are concatenated in a RANDOM order.
I expected that only the FIRST filename rule would be used
or that at least the original order would be preserved 
if all filename rules are used.

This problem occures in 4.05-3 as well as 4.22-5.
You will find a simple patch below.

Example:

MailScanner.conf:
Filename Rules = %rules-dir%/filename.rules

filename.rules:
to      master at test.de  /etc/MailScanner/filename-any.rules.conf
to      *@test.de               /etc/MailScanner/filename-secure.rules.conf

filename-any.rules.conf:
allow   .       -       -

filename-secure.rules.conf:
allow   \.txt$  -       -
allow   \.rtf$  -       -
allow   \.doc$  -       -
allow   \.pdf$  -       -
allow   \.xls$  -       -
allow   \.vcf$  -       -
allow   \.msg$  -       -
allow   \.html?$        -       -
deny    .               forbidden by rule       forbidden by rule

For this example I always thougt, only filename rules from
filename-any.rules.conf would be applied to messages to 
master at test.de.
But MailScanner did reject e.g. *.zip files to master at test.de.
This problem occured in real life with a real customer.

When looking at the source code I found in
1.
ConfigDefs.pl:
[All,File]
#FilenameRules          /etc/MailScanner/filename.rules.conf
FilenameRules

i.e. MailScanner reads ALL values it finds for a given message.

2.
Config.pm:
sub Value {
...
    # It's an all-matches rule
...
              map { $matches{$_} = 1; } (split(" ",$value))
...
    $results = join(" ", keys %matches);
...
}

i.e.
result values are returned in a random order, since they are read 
from a hash whereby the original order is lost.


I solved this problem by simply changing the "category" of
FilenameRules in ConfigDefs.pl from "all-matches" to "first-match".
In fact, I changed this for all "File" rules which are
FilenameRules and FiletypeRules.

To preserve similar problems I would propose to change "sub Value"
in Config.pm such that the original order of values remains unchanged.

Patch
-----
*** ConfigDefs.pl.orig  Thu Jul  3 17:37:02 2003
--- ConfigDefs.pl       Mon Jul  7 15:14:58 2003
***************
*** 316,322 ****
  SpamStars             0       no      0       yes     1
  UseSpamAssassin               0       no      0       yes     1

! [All,File]
  #FilenameRules                /etc/MailScanner/filename.rules.conf
  FilenameRules
  FiletypeRules
--- 316,322 ----
  SpamStars             0       no      0       yes     1
  UseSpamAssassin               0       no      0       yes     1

! [First,File]
  #FilenameRules                /etc/MailScanner/filename.rules.conf
  FilenameRules
  FiletypeRules

Viele Grüße

-- Heinz Knutzen

Datenzentrale Schleswig-Holstein
Altenholzer Str. 10-14, 24161 Altenholz, Germany
http://www.dzsh.de/
mailto:heinz.knutzen at dzsh.de
Tel: +49.431.3295.6581 Fax: +49.431.3295.410