On Tue, 6 Dec 2005, Dean Brooks wrote:
> I almost got to the point where it seemed like Exim (v4.60) was
> clobbering the contents of $2 in some manner, which affected the second
> lookup, but I can't prove that and I wasn't able to get much out
> of "debug +expand".
>
> driver = plaintext
> public_name = PLAIN
> server_prompts = :
> server_condition = \
> "${if or { {eq {${lookup{${lc:$2}} dbm{DBDIR/authentication} {$value}
> {*NP*}}} {${md5:$3}}} \
> {and{{match_domain {${domain:$2}}{+localdomains}} \
> {eq {${lookup{${local_part:${lc:$2}}}
> dbm{DBDIR/authentication} {$value} {*NP*}}} {${md5:$3}}}}} \
> } {yes}{no}}"
> server_set_id = $2
This has finally arrived the front of my work queue, and I now
understand what is going on. You were right. The problem is that $1, $2,
etc. are reset by some kinds of expansion item. In particular, this
happens for match_domain (and other matches) because the matching may
involve a regular expression that itself puts values into these
numerical variables. The new values are used when expanding the "yes"
and "no" strings after the match. For example
${if match_domain {something} {^...(...)...} {...$1...} ...
I think the solution to this problem is to invent a new set of
variables, specifically for use in authenticators. I propose to call
them $auth1, $auth2, $auth3 (currently no more than 3 are needed, but we
can extend if ever that becomes necessary). These will not be messed
with during expansion and so should solve this problem. The use of the
numerical variables - in cases where they work - will of course still be
possible for backwards compatibility, but it will no longer be the
preferred thing to do.
Philip
--
Philip Hazel University of Cambridge Computing Service,
[EMAIL PROTECTED] Cambridge, England. Phone: +44 1223 334714.
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/
