> > Was numerical variables not being available outside an individual
> > string expansion a design decision in Exim as in Perl I am used to
> > have numerical variables available for later use?
>
> I myself am never sure in Perl exactly when they are going to
> get reset, but I understand your point. However...
>
> Exim configurations are not programs. If you write, in a
> router, something like
>
> local_parts = ^some(regex)(with)(parens)...
> domains = whatever
>
> it does not mean that the local_parts regex is used before
> the domains condition is tested. (In fact, in this example,
> domains is checked first, as documented in 3.12.)
>
> It is true that ACLs are more like programs in that the
> various verbs are obeyed in order, but ACLs are latecomers,
> not arriving till Exim 4.
> So the philosophy (and code) was well-established by then.
>
> > Have you ever been asked to modify this in Exim so that these
> > variables continue to exist after a string expansion?
>
> There are documented instances when they do - for example,
> after a "matches" condition in an Exim filter.
>
> The answer to your question is "no", or more accurately "not
> that I can remember (but my memory is not what it was and I
> may be wrong)".
>
> Looking at the code, I see that in fact $1 is not explicitly
> unset after a string expansion. I was mistaken in suggesting
> this. So why doesn't your code work? You had this:
>
> discard condition = ${if match{${lc:$mime_filename}}
> {[.] *(gif|jpg|jpeg|png|bmp)\$}}
> !sender_domains = +ok_domains
> logwrite = External e-mail from
> '$sender_address' with invalid attached file type ($1)
> '$mime_filename' - discard!
>
> The answer is that when Exim is checking +ok_domains, there
> may be regex matches, and the numerical variables are also
> set for some other kinds of wildcard match. So the resetting
> of $1 is a consequence of checking
> +ok_domains. (This harks back to my comment above about never quite
> knowing in Perl when these variables are reset.)
>
> But in general, my original comment stands: You can only rely
> on $1 etc
> remaining available in circumstances where this is documented.
I had tried setting an ACL variable to $1 some time ago but it didn't
work and so resorted to using the $mime_filename variable in the
logwrite.
Modified my config MIME ACL again to confirm what I had found before:
# Discard e-mail with graphic file attachment.
discard condition = ${if match
{${lc:$mime_filename}} {[.] *(gif|jpg|jpeg|png|bmp)\$}}
set acl_m2 = $1
!sender_domains = +ok_domains
logwrite = External e-mail from
'$sender_address' with invalid attached file type ($acl_m2)
'$mime_filename' - discard!
No value is printed for $acl_m2 in the logwrite.
I presume that if $1 contains a value then the 'set acl_m2' would copy
it into the acl_m2 variable.
So if nothing is being printed in the logwrite then this would mean that
the $1 is being unset after a string expansion?
Paul McIlfatrick
