On Oct 27, 2008, at 5:42 AM, Jakob Hirsch wrote:
>>
>> I don't see the harm in making the change Brian asks for -- it will
>
> It's a change of behaviour. strict_acl_vars was introduced to protect
> against typos, like Perl's "use strict". If there is a use case for
> such
> a check, it should be done with a new expansion condition, e.g.
> "isset:var".
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} }
this comes into play where a local user will send an email to another
local user which generates an auto-reply using the autoreply transport
driver.
That message that is created will not have the necessary acl_m
variable set because it did not go through the normal acl chain and so
I cannot simply use:
message_size_limit = $acl_m_pref_msg_maxsize
With the former construct, I cannot operate (at the very least on our
test server) with strict_acl_vars=on
isset: would be very helpful.
------
One may ask why I have these message_size limits in place at the
transport level....
The main reason is dumb MUAs.....
We've seen time and again that having max message size enforced at the
acl level for a locally authenticated user can result in a continuous
stream for days on end of that message trying to be sent from that
users OutBox. The MUA isn't smart enough to deal with the fact the
message is being rejected due to size and will continue to try and
send this large attachment over and over chewing up bandwidth.
The fix is: We accept messages of ANY size from trusted hosts (relay,
whitelisted and authd cnxns) and then enforce the max size in the
routing/transport which will simply create a bounce instead.
Brian
