On 2011-10-08 at 09:59 +0300, Nikita Koshikov wrote:
> Hello list,
>
> I have a question regarding next exim 4.77 update and "match" clutching.
> Reading Phil's announce letter it's a bit unclear to me what will work and how correctly remake current configs if it won't work.
>
> Few examples:
>
> 1)
> {match_ip{$sender_host_address}{iplsearch;EXIM_ROOT/local/bad_auth_hosts}}
This will still work.
> Lookups are now not allowed, so should I define new hostlist and make iplsearch there or maybe exist some better way?
> >{match_ip{$sender_host_address}{+new_hostlist}} ?
Lookups are still allowed. The change is that the second part will not
be expanded. There is no "$" sign anywhere in
"iplsearch;EXIM_ROOT/local/bad_auth_hosts". There is no change in
behaviour that affects you here.
> 2)
> {match_ip{$sender_helo_name}{@[]}}
> @[] - if I'm correct - this is internal variable to exim - will it be allowed ?
Lookups still work, list matches still work, you're using match_ip{}{}
correctly, as it was designed to be used, and this example will still
work.
> 3)
> ${if !match{$sender_helo_name}{\\.}}
> This should work - pure regex, Am I right ?
Correct. match{}{} is unchanged. For clarity, you might want:
${if !match{$sender_helo_name}{\N\.\N}}
so that you're not into leaning toothpick syndrome.
> 4)
> Final one
> ${if forany\
> {<,\
> ${lookup{$sender_host_address}iplsearch{EXIM_ROOT/local/allow_ip_senders}}\
> }\
> {match{${lc:$sender_address}}{$item}}\
> }
match{}{} is unchanged. ${lookup...} is unchanged. forany{}{} is
unchanged.
> allow_ip_senders have format like this:
> IP Sender
> 1.1.1.1 trusted@???, services-.*@???
>
> What is the right way to make such functionality in upcoming exim release?
This is correct and will still work.
Every part of your configuration is correct and safe, to the best of my
knowledge. None of the parts which you have cited here will be broken
by 4.77. Your configuration is exactly the sort of working
configuration which we're trying to preserve.
The only backwards-incompatible change is that for expansion conditions
match_address, match_domain, match_ip and match_local_part, the second
parameter is not subject to string expansion as part of reading it.
This means, that for those four conditions, and only those four, a "$"
somewhere in the second parameter will be treated as an ordinary
character. When the time comes to perform the lookup, if it's
referencing a named list and the named list definition uses $expansions
then those will still work as before.
Does this make things any clearer?
-Phil
