Re: [exim] Re: Problem with prvs functions

Brian Candler wrote:

> I think I can answer my own question. ${prvscheck} does not work in the same
> way as other Exim expansions.
>
> Firstly, it expands its parameter 3 *before* deciding whether the test
> passed or not. Secondly, even though it doesn't allow parameter 3 to be
> omitted, it treats empty-string as a special case; an empty string here
> returns the contents of $prvscheck_address (the unencoded address), whether
> or not the cryptographic validation passed or failed.

I hit the limits of Philip's expansion system with what I wanted to do
so I got kind of creative. The first problem was that I wanted to set up
an expansion variable after expansion of parameter 1 that would be
present during the expansions of parameters 2+3 (so you can do lookups
using the decoded address as a key).

The second problem was that I wanted ${prvscheck to be easily usable in
a redirect router, using "data" (such a router would gracefully decline
if "data" is an empty string). It should also be easily usable in a
"condition =" line of an ACL (hence the creative use of parameter 3,
where you can just put a "1". That avoids the clutter of using ${if
cond{}{yes}{no}}.

Due to my creativity to solve problem #1 I could not make parameter 3
optional.

Your suggestion to use 4 parameters is valid. Like described above, I
more or less designed the item to fit the typical use-case (I'm an
engineer, sorry :). I don't think making it a condition would make its
usage easier. Also, I would still want ${prvscheck to return the decoded
address even if it expired or is invalid. That keeps the redirect router
really simple. If such an address has made it past the ACLs we should
deliver the attached message.

/tom