[Exim] Re: exim 3.35 problem with string expansion

Page principale
Supprimer ce message
Répondre à ce message
Auteur: Spiro Trikaliotis
Date:  
À: exim-users
Sujet: [Exim] Re: exim 3.35 problem with string expansion
Hello,

I had a problem with exim which I posted on alt.comp.mail.exim. As I
have been told that this mailing list is more frequently read, I
answered there, but I'm also forwarding here, as a question regarding
the documentation remains. It has to do with doubling colons in
client_send = ... like lines.

I myself wrote in alt.comp.mail.exim:

> I'm using exim 3.35 (debian/woody). I want to use the idea from
> http://www.linuxer.onlinehome.de/apps/exim.htm (sorry, german only)
> to setup exim with different smarthosts.

[...]

> In fact, I even tried the simple case
> client_send = "${extract{3}{:}{1:2:3:4}}"
> and I get the error message:
>
> 2004-04-21 08:51:42 1BGBXz-0002bf-00 == trik-news@??? T=remote_smtp
>    defer (0): expansion of "${extract{3}{" failed in login authenticator:
>    missing } at end of string

[...]

> Here, these seem to work as expected, as well as in the cram-md5
> authenticator:
>
> cram_md5:

[...]
>   client_name = "${extract{3}{:}{${lookup{$sender_address}<---
>     lsearch{/etc/exim/passwd.client}{$value}fail}}}"


> I'm a little bit stuck. Does anyone have the same problem, or, even better,
> a solution to this? Is this a bug in exim, or am I using it totally wrong?


If someone is intested in the solution: The problem lies in the colons
in the second parameters to client_send. As these are interpretet by
client_send itself, I cannot give it as arguments to ${extract...}.
Doubling the colons ("::") solved the problem.

I have checked the manual (online and on
http://exim.work.de/exim-html-3.30/doc/html/spec.html), I have not
found that anywhere but in section 9.4
(http://exim.work.de/exim-html-3.30/doc/html/spec_9.html#SEC179, for pam
{<string1>:<string2>:...}). Same applies to the current doc for 4.3.

Is this left out in the documentation, or am I not searching at the
right places?

Regards,
Spiro.

--
Spiro R. Trikaliotis
http://www.trikaliotis.net/