https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7987
--- Comment #20 from Michael Storz <sa-mst@lrz.de> ---
(In reply to Henrik Krohns from comment #18)
> (In reply to Michael Storz from comment #17)
> > If that
> > could happen the logic of the eval rule is too complex and should be changed.
>
> A DNSBL can do this:
> - It parses for example 4 IP addresses from Received
> - For each of the IP it starts a separate bgsend_and_start_lookup, expecting
> 4 separate callbacks
>
> Obviously if got_hit() is called, we know rule is ready regardless of any
> pending lookups.
>
> What things should the callback do if there is no hit?
>
> Current logic:
>
> sub callback {
> rule_ready(thisrule)
> foreach (answer) {
> if (match) got_hit(thisrule)
> }
> }
>
> Using got_miss() would probably be:
>
> sub callback {
> foreach (answer) {
> if (match) got_hit(thisrule)
> }
> if (!tests_already_hit(thisrule) && !get_async_pending_rules(thisrule))
> got_miss(thisrule)
> }
>
> I guess we could brind back the deprecated Dns/is_rule_complete function,
> which can do the checks. So would this be the most elegant flow?
>
> sub callback {
> foreach (answer) {
> if (match) got_hit(thisrule)
> }
> if (is_rule_complete(thisrule)) got_miss(thisrule)
> }
short executive answer for Henrik:
Since the decision logic of how to process the different asynchronous calls is
completely contained in the plugin and therefore cannot be detected from the
outside, I don't know how a support system could look like. For this we
probably need first several examples from which we could take an idea for the
realization.
long version:
If we take the standard case of one rule one result, then we can represent the
decision logic for your example of a DNSBL with 4 lookups l1 to l4 like this:
hit = l1 || l2 || l3 || l4
miss = !hit = !(l1 || l2 || l3 || l4) = !l1 && !l2 && !l3 && !l4
With short-circuit evaluation we can evaluate a hit already with the result of
one lookup hit. But for a miss we need the evaluation of all lookups.
The logic could be the other way around in another case:
hit = l1 && l2 && l3 && l4
Now we would need all lookup results for the evaluation of a hit and only one
for a miss.
In principle, the logic can take any form of a boolean expression:
hit = (l1 && l2) || (l3 && l4)
Here, too, there are combinations where we can only decide whether it is a hit
or a miss after evaluating all lookups.
I.e. logically we always need three levels
- eval function
- asynchronous lookups
- decision function
i.e. the callbacks of the lookups must always call a decision function, which
keeps track of the status of all lookups and makes a decision about hit or miss
based on this data.
Besides the standard case, there are also the cases with one rule many results.
In the extreme case, there could also be four hit/miss results associated with
the four lookups, i.e. the lookups are completely independent of each other.
Which logic is implemented in the plugin cannot be determined from the outside.
At the moment I don't know how to support the implementation of the logic. For
this we need first of all examples from which we can then perhaps derive
something.
I would therefore implement nothing for the support of the decision logic for
the time being.
--
You are receiving this mail because:
You are the assignee for the bug.
--- Comment #20 from Michael Storz <sa-mst@lrz.de> ---
(In reply to Henrik Krohns from comment #18)
> (In reply to Michael Storz from comment #17)
> > If that
> > could happen the logic of the eval rule is too complex and should be changed.
>
> A DNSBL can do this:
> - It parses for example 4 IP addresses from Received
> - For each of the IP it starts a separate bgsend_and_start_lookup, expecting
> 4 separate callbacks
>
> Obviously if got_hit() is called, we know rule is ready regardless of any
> pending lookups.
>
> What things should the callback do if there is no hit?
>
> Current logic:
>
> sub callback {
> rule_ready(thisrule)
> foreach (answer) {
> if (match) got_hit(thisrule)
> }
> }
>
> Using got_miss() would probably be:
>
> sub callback {
> foreach (answer) {
> if (match) got_hit(thisrule)
> }
> if (!tests_already_hit(thisrule) && !get_async_pending_rules(thisrule))
> got_miss(thisrule)
> }
>
> I guess we could brind back the deprecated Dns/is_rule_complete function,
> which can do the checks. So would this be the most elegant flow?
>
> sub callback {
> foreach (answer) {
> if (match) got_hit(thisrule)
> }
> if (is_rule_complete(thisrule)) got_miss(thisrule)
> }
short executive answer for Henrik:
Since the decision logic of how to process the different asynchronous calls is
completely contained in the plugin and therefore cannot be detected from the
outside, I don't know how a support system could look like. For this we
probably need first several examples from which we could take an idea for the
realization.
long version:
If we take the standard case of one rule one result, then we can represent the
decision logic for your example of a DNSBL with 4 lookups l1 to l4 like this:
hit = l1 || l2 || l3 || l4
miss = !hit = !(l1 || l2 || l3 || l4) = !l1 && !l2 && !l3 && !l4
With short-circuit evaluation we can evaluate a hit already with the result of
one lookup hit. But for a miss we need the evaluation of all lookups.
The logic could be the other way around in another case:
hit = l1 && l2 && l3 && l4
Now we would need all lookup results for the evaluation of a hit and only one
for a miss.
In principle, the logic can take any form of a boolean expression:
hit = (l1 && l2) || (l3 && l4)
Here, too, there are combinations where we can only decide whether it is a hit
or a miss after evaluating all lookups.
I.e. logically we always need three levels
- eval function
- asynchronous lookups
- decision function
i.e. the callbacks of the lookups must always call a decision function, which
keeps track of the status of all lookups and makes a decision about hit or miss
based on this data.
Besides the standard case, there are also the cases with one rule many results.
In the extreme case, there could also be four hit/miss results associated with
the four lookups, i.e. the lookups are completely independent of each other.
Which logic is implemented in the plugin cannot be determined from the outside.
At the moment I don't know how to support the implementation of the logic. For
this we need first of all examples from which we can then perhaps derive
something.
I would therefore implement nothing for the support of the decision logic for
the time being.
--
You are receiving this mail because:
You are the assignee for the bug.