Nico Erfurth wrote:
> Tom Kistner wrote:
>
>> What do you mean with "generic"? Having it in the ACL system is doing
>> just that. You can roll your own headers/replies and log messages, use
>> the standard "control" statement, have extra "condition" entries that
>> can work with some expansion variables that I set up ...
> But you introduce many new verbs, like demime/malware/spam, i think a
> single verb would be better, like
Small correction: "deny" and "warn" are the verbs. The things I add are
conditions (or modifiers, if they return a fixed value).
> deny
> localscan = malware, spam
> condition =
>
> All what this does is calling the localscan/exiscan and passing the
> arguments to it, just as a string.
Sorry, but that is too unflexible. Where is the advantage? Where would
you put "run" conditions for every single facility?
It sure looks "clean" from the code side of view, but does it really
matter if I add one or five conditions to acl.c? I think not. And the
end user does not care about the code.
In my concept, every condition has a return value (true, false, defer),
and is run conditionally, if the right hand value expands to something
non-nullish.
When run successfully, every condition has a side effect of filling in
expansion variables (for example, $malware_name), that can be used in
messages or additional conditions.
For example, "malware" has a right-hand side option for a virus name regex:
deny log_message = Klez-Type virus, blackholing (bouncing is useless)
malware = Klez
control = blackhole
deny message = Virus detected ($malware_name)
malware = *
The actual scanning process is only invoked once, of course, with the
results being cached.
> Well, this is just my opinion, but I really dislike your current scheme.
The "spam" condition may still be changed, it currently gets the
username as the right-hand side value, this is not really intuitive, I know.
regards,
/tom
