Re: [exim] def:acl var with strict_acl_vars=true

Top Page
Delete this message
Reply to this message
Author: W B Hacker
Date:  
To: exim users
Subject: Re: [exim] def:acl var with strict_acl_vars=true
Brian Blood wrote:
> On Oct 27, 2008, at 1:41 PM, Jakob Hirsch wrote:
>
>>> My particular use is the following:
>>>
>>> We have the ability in our solution to allow per message max message
>>> size and that value is set in a acl_m variable.
>>>
>>> This value is made use of in our local user transport like so:
>>>
>>>    message_size_limit = ${if def:acl_m_pref_msg_maxsize
>>> {$acl_m_pref_msg_maxsize}{DEFAULT_MESSAGE_SIZE_LIMIT} }


>> Ok, but AFAICS, it would be sufficient for you to pre-set
>> acl_m_pref_msg_maxsize to the emtpy string early in your ACLs, e.g. in
>> acl_smtp_connect and acl_not_smtp_start.
>
>
>
> acl_ variables aren't defined in the message generated by the
> autoreply transport driver
>
>
>


Nor can they be.

The router/transport chain has ONLY read-access to acl_m variables.

Upon entry to acl_smtp_rcpt phase, you might be better served to set the
acl_m to a default integer value rather than empty or null, expecting it
to be overwritten (or not) by per-user prefs.

Whichever - the result survives for later testing/use in router/transports.

The default value could be either:

- a real default, such as a useful size limit, ex: 100

OR

- a specific number that was anything BUT a useful limit - eg - intended
only to match a conditional. '1' or '0' comes to mind.

acl_c and acl_m variables are not only uninitialized w/r a value - they
are not initialized as to *type* either.

On any given child invocation, they don't know if they will dress up as
strings or numbers until onpassed a value of one type or the other and
shoved out of their closet.

;-)


Bill