Re: [exim] address_data extension

Magnus Holmgren wrote:
> On Tuesday 31 October 2006 15:02, Stephen Gran took the opportunity to say:
>> On Tue, Oct 31, 2006 at 09:05:21PM +0800, W B Hacker said:
>>> Marc Haber wrote:
>>>> While we're at it - has somebody thought about address_data_foo and
>>>> address_data_bar as a similiar concept to named acl variables?
>>>>
>>> Last time I looked we were calling them 'acl_r' variables...
>>>
>>> As in acl_c = 'Connect', acl_m = 'Message', acl_r = 'Routing'
>> steve@gashuffer:~$ zgrep -i acl_r /usr/share/doc/exim4-base/spec.txt.gz
>> steve@gashuffer:~$
>>
>> It appears we're not calling them anyting, at the moment.
>
> Jeremy Harris suggested $acl_r* variables (r for recipient) on February 28, in
> the thread entitled "acl variables per recipient rather than per message".
> They would still be set in ACLs, not in routers, and so are out of scope of
> the original question.


Yes - everything not ephemeral must be stored *somewhere* non-volatile whenever
an interactive session ends, if only because there can potentially be several
hundred such processes running. And the queue - with the message - is the
logical choice. All variables also need to be 'managed' as well, not left lying
about.

But the *term* 'acl' - whether applied to the 'interactive' case structure
(smtp-time) or not, is largely a *labeling convention*, not a law of nature.

With respect to the 'not predefined' variables, acl_m in particular, this
labeling is *already* made available in the router/transport sets.

> The difference between address_data and ACL variables
> is that ACL variables are stored on the spool, whereas address_data is set on
> each routing occasion.
>

Yes, at present. And this is limited specifically to acl_m variables, and those
to 'read only', even though first invocation loads the value from disk into memory.

Indeed, that specific set might be dangerously unpredictable if allowed to be
manipulated.

Far better to copy the stored value, then manipulate the copy, much as we may
now do in transferring an acl_c value to an acl_m value when entering
acl_smtp_rcpt from acl_smtp_helo.

None of this presents a barrier to the *future* provision of a set of
not-predefined variables that *could* be used for r/w within the
router/transport structure.

IOW - in addition to the singular $address_data now provided.

So, no - we are not 'out of scope' with what could be. Only with what 'is now'.

If such router/transport-time variables were to be provided, 'acl_r' would be a
reasonable choice in that it has a 'familiar' labeling that:

- reminds us of the zone or sub-function to which its use is restricted, as
acl_c and acl_m now do. '$address_data' by contrast is already a somewhat
misleading label. '$sole_scratchpad' might be more accurate.

- 'acl_r(n)' hints at a familiar permitted range of data type, storage capacity,
and supported manipulation and test operations.

- 'acl_r(n) could reasonably be expected to re-use a good deal of existing code
with minimal revision.

And no, none of that would make 'real time' variable-passing any more practical
than it is now.

Router/transports are 'store and forward' - divorced in time from the
interactive smtp session(s). By *years* if you down a box with messages still in
the queue and restart it 5 years later... ;-)

Anything they are handed *initially* _has to be_ from non-volatile storage.

But that doesn't mean they could not benefit from a few extra local variables.

Use of 'acl_r(n) as a label might just make the syntax more othogonal than some
other choices. As we already have acl_m(n) available to routers, where's the harm?

Bill