Sven Eschenberg <sven@???> (Mi 01 Jun 2016 14:42:00 CEST):
> Maybe I got something fundamentally wrong regarding expansions, but I am
> seeing a behavior I consider a little inconsistent.
…
>
> exim -be '${extract{$received_ip_address}{10.0.0.1=hosta 127.0.0.1=local4
> ::1=local6}{$value}fail}'
> Failed: first argument of "extract" must not be empty
>
> That was somewhat expected, the docs say the key must not consist of all
> digits. There's no hint on what happens if the key is empty.
We can update the docs. (I did already, but not yet pushed.)
> Anyhow using such an expansion on smtp_active_hostname yields a panic, while
> a forced fail (second example) will result in smtp_active_hostname being set
> to $primary_hostname (as documented)
The first failure is not a forced failure, because the ${extract…}
"operator" isn't used properly. (see this as a "syntax error")
The 2nd failure is forced, maybe comparable to "undef" (Perl), "NUL"
(SQL), "NIL" (??) as an indication that everything went right, but
there isn't a return value anyway. In several places of the Exim
configuration we differntiate between an empty result and a "forced
failure".
> Question is: Why do different failures yield different behavior? Does exim
What's wrong with different failures yielding different behaviour.
A "forced failure" is in intentional failure, used to signal something.
> But let's go on, actually something else struck me in the first place. Let's
> safeguard the extract:
> exim -oMi 10.0.0.1 -be '${if def:received_ip_address{yes}fail}'
> yes
> (expected)
…
That what you tried, I tried to reproduce:
$ exim -be '${if def:received_ip_address{${extract{$received_ip_address}{10.0.0.1=hosta 127.0.0.1=local4 ::1=local6}{$value}fail}}fail}'
Failed: "if" failed and "fail" requested
(expected)
$ exim -oMi 127.0.0.1 -be '${if def:received_ip_address{${extract{$received_ip_address}{10.0.0.1=hosta 127.0.0.1=local4 ::1=local6}{$value}fail}}fail}'
local4
(expected)
It's exim -bV: Exim version 4.87_51-e37f8a8 #12 built 24-May-2016 23:01:22
The 4.87 (git 74d8288d7a8fa83989968647149ae47ba10194f8) exposes the
behaviour you describe.
Git 1cf59ee7f68960237ad5cd3d599512fdbe5b3954 fixes it (Bug 1815).
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de ---------------------------- internet & unix support -
Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
gnupg encrypted messages are welcome --------------- key ID: F69376CE -
! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ -
