On 11/12/06, Daniel Tiefnig <exim@???> wrote:
> Now, I encountered something different meanwhile. Tried to replace the
> "hosts = ..." part like follows:
>
> warn condition = ${lookup{$sender_host_address} \
> dbm{/etc/exim/spamblock.dbm}{yes}fail}
> message = X-Inode-RBL: $sender_host_address is blacklisted
> set acl_m2 = $sender_host_address is blacklisted
>
> So, if the IP Address is not found in the list, the string expansion is
> forced to fail, and should IMHO abort processing of the current "warn"
> acl verb. But that's not the case. Debug oputput tells me:
>
> [...]
> failed to expand: ${lookup{ ... }{yes}fail}
> error message: "lookup" failed and "fail" requested
> failure was forced
> expanding: $sender_host_address is blacklisted
> [...]
>
> So it processes the next ACL condition. Is this intended? The section
> about "ACL verbs" (i.e. the paragraph about "warn") in the specification
> suggests it's not.
Feature.
Quoting PH in an answer abour 3 hours ago to an identical question:-
condition = <string>
This feature allows you to make up custom conditions. If the result
of expanding the string is an empty string, the number zero, or one
of the strings no or false, the condition is false. If the result is
any non-zero number, or one of the strings yes or true, the
condition is true. For any other value, some error is assumed to
have occurred, and the ACL returns defer. However, if the expansion
is forced to fail, the condition is ignored. The effect is to treat
it as true, whether it is positive or negative.
--
Peter Bowyer
Email: peter@???
