Spam Action rules: first match vs. all match?

[Jay Berkenbilt]

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/