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
