On Sun, 27 Feb 2005, Stephen Gran wrote:
> It is still problematic with 4.50 - it seems that it is not set in all
> cases. With the following acl:
>
> warn condition = ${if !def:acl_m1 {true}{false}}
> !dnslists = dsn.rfc-ignorant.org/$sender_address_domain
> !acl = acl_whitelist_local_deny
> !verify = sender/callout=30s,defer_ok
> log_message = $acl_verify_message
> set acl_m1 = Sender verify failed: $acl_verify_message
I have now looked at this. If you look in TFM, you will find this:
$acl_verify_message: During the expansion of the "message" and "log_message"
modifiers in an ACL statement after an address verification has failed, this
variable contains the original failure message that will be overridden by
the expanded string.
Notice the condition that is imposed:
During the expansion of the "message" and "log_message"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
For historical/internal reasons, the code implements this precisely. So
this isn't a bug. But I have noted it as an infelicity that perhaps
should be fixed.
Regards,
Philip
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
