Hallo,
> > where local_part="${quote_mysql:${extract {1}{@%!}{$1}}}"
> What exactly is the setting you use?
with authentication driver cram_md5:
server_secret = ${lookup mysql{ \
select password_hash from popbox \
where local_part = '${quote_mysql:${extract {1}{@%!}{$1}}}' \
and domain_name = '${quote_mysql:${extract {2}{@%!}{$1}}}' \
}{${extract {2}{\}}{$value}}}{fail}}
but the same applies to using it with plain's server_condition.
(The passwords are stored as "{plaintext}this_is_the_pass" in a mysql-db
which is also used by vmail.)
I think the problem is the usage of quotes, because then the escaping
backslash itself has to be escaped with a second backslash (as said in
the spec 9: "if the string appears in quotes in the configuration file,
two backslashes are required because the quotes themselves cause
interpretation of backslashes when the string is read in") but
quote_mysql uses only one backslash. I have to use quotes for strings in
SQL-queries.
Maybe query_mysql does not know of the nesting level of expansions, so
one had to use something like (just had this idea)
"${quote_mysql:${quote_mysql:${extract {1}{@%!}{$1}}}}"
but that's really ugly and just works with backslashes but fails with
quotes.
Currently I'm simply stripping \ and ' from the string with
"${sg{${extract {1}{@%!}{$1}}}{[\\\\\\']}{}}", maybe you have a better
workaround.
I first wanted to strip none alphanumeric chars completely but it seems
that I cannot negate in regexps with a !, "${sg{test-bla}{![a-z]}{}}"
gives back the complete string.
But wait, I just tested again with a freshly compiled 3.35 and it seems
to do fine. I looked into 3.35's ChangeLog before but didn't think
change 7 included this... so, sorry for bothering.
> > And even worse, I really don't think that such a verbose error
message
> > should be sent back in the SMTP dialogue:
> It should be different in Exim 4.
Hm, ok, I wanted to upgrade to exim4 in the near future anyway...
--
Bye, Jakob
