Spam Action rules: first match vs. all match? (2)

[Julian Field]

The other thing I have just implemented helps solve the problem of not
being able to predict the result of a ruleset when there are lots of
recipients which have conflicting results. This is to save you always
having to split the message so that there is only 1 recipient per message.
It doesn't solve the problem of multiple conflicting rules completely, but
it does mean you can predict exactly what will happen for any given
message, which has got to be a good thing :-)

# When trying to work out the value of configuration parameters which are
# using a ruleset, this controls the behaviour when a rule is checking the
# "To:" addresses.
# If this option is set to "yes", then the following happens when checking
# the ruleset:
#   a) 1 recipient. Same behaviour as normal.
#   b) Several recipients, but all in the same domain (domain.com for example).
#      The rules are checked for one that matches the string "*@domain.com".
#   c) Several recipients, not all in the same domain.
#      The rules are checked for one that matches the string "*@*".
#
# If this option is set to "no", then some rules will use the result they
# get from the first matching rule for any of the recipients of a message,
# so the exact value cannot be predicted for messages with more than 1
# recipient.
#
# This value *cannot* be the filename of a ruleset.
Use Default Rules With Multiple Recipients = no

At 08:27 05/08/2003, you wrote:
>What was the general consensus on this subject?
>
>Is it worth my implementing this "stop" keyword? It will cause a couple of
>extra "if" statements inside a function that is called a few dozen times
>for each message, so I don't want to add it unless quite a few people will
>find it useful.
>
>At 18:37 28/07/2003, you wrote:
>>On Mon, 28 Jul 2003 18:02:33 +0100, Julian Field
>><mailscanner at ECS.SOTON.AC.UK> wrote:
>>
>> >What I thought about doing was adding a "STOP" entry in any of the "all
>> >matches" rules, so that evaluation of the rules for that recipient/sender
>> >would stop at that point and not carry on trying to match other rules in
>> >the ruleset.
>> >
>> >The rules would still be evaluated for all of the recipient(s) and the
>> >sender, but this would enable you to stop the rule checking when you had
>> >matched a previous rule.
>> >
>> >Would that solve the problem, or indeed help at all?
>>
>>How would that work?  If you mean something like this:
>>
>>FromAndTo: *@primary.domain forward zzz at yyy
>>STOP
>>To:  *@primary.domain bounce forward zzz at yyy
>>FromOrTo: default   deliver forward zzz at yyy
>>
>>meaning that when the STOP line is encountered, rule matching should
>>stop if any above rules had matched, that would work for me and would
>>actually add quite a bit of flexibility.  It would make it possible to
>>do things like have a specific list of users or subdomains in a domain
>>that get special treatment.  For example:
>>
>>From:  user1 at domain.com deliver
>>From:  user2 at domain.com deliver
>>From:  user3 at one.domain.com deliver
>>From:  user4 at two.domain.com deliver
>>From:  *@two.domain.com forward zzz at yyy
>>STOP
>>From:  *@one.domain.com forward zzz at yyy
>>STOP
>>From:  *@*.domain.com  bounce forward zzz at yyy
>>From:  *@domain.com  bounce forward zzz at yyy
>>
>>Semantics such as what would result from the above could be tricky to
>>achieve with either all or first rules.  If it weren't for user4, then
>>the above without STOP would be the same as if it were interpreted as
>>first match, but with the above as all with STOP implemented,
>>user4 at two.domain.com's actions would be "deliver forward zzz at yyy".
>>(Okay, this example would be easy to make work with first, but
>>still...)
>>
>>Another option I had been thinking about would be to able to mark a
>>single rule as exclusive, but I think the above is better.
>>
>>--
>>Jay Berkenbilt <ejb at ql.org>
>>http://www.ql.org/q/
>
>--
>Julian Field
>www.MailScanner.info
>MailScanner thanks transtec Computers for their support

--
Julian Field
www.MailScanner.info
MailScanner thanks transtec Computers for their support