On 2012-06-12 02:34, Phil Pennock wrote:
> On 2012-06-11 at 22:32 +0100, Jeremy Harris wrote:
>> In a fit of coding insanity I ran up the following:
>>
>> + 9. New expansion item ${acl {name}{argument}} to call an ACL. The argument can
>> + be accessed by the ACL in $address_data. The expansion result is set by
>> + a "message =" modifier and an "accept" return from the ACL.
>>
>> Is there any value in this going forward?
>
> Is there a reason to reuse $address_data? It seems unwise.
>
> Folks passing data down using $address_data, letting content be
> ${extract}ed from it, may well want to log/process data from that, but
> also have something else be passed in as the ACL argument. Eg,
> ${extract{usercode}{$address_data}} for log-purposes, showing that
> delivery was done by authenticating as that usercode.
>
> If there's no specific reason to override $address_data, just add a new
> variable.
OK, that doesn't seem too hard.
>
> If the ACL returns non-accept, does that cause an immediate expansion
> failure? Does it count as a forced failure?
I've made it cause a failure, but I'm not sure of what type....
It's in expand_string_internal() like the notdef
case of EITEM_DLFUNC.
--
Jeremy
