Re: [Exim] Second stab at supporting Cyrus SASL's saslauthd

Philip Hazel wrote:

>>With sub-curly-braces I got rid of possibility of encountering ':' in password
>>or elsewhere (by which i was once bitten), but now none of the fields can
>>contain '{' or '}'. Not that curly braces are that common in passwords, but
>>nevertheless is there any way to somehow escape curly braces?
>
>
> With something like
>
>
>>server_condition = ${if saslauthd{{$2}{$3}}{1}{0}}
>
>
> This should not matter, because Exim does not re-expand the data that it
> inserts. (Only if you wrap it inside ${expand: does it do this.) Have
> you tried a password that contains braces? I would expect it to work.

Hmm. I'm more concerned about the case when, say, realm has to be hardcoded
into configuration and to have a curly brace(s) in itself. One can make an
lsearch-file to get around this, like:

realm: }curly{}realm{
service: {curly}{service}

${if saslauthd{
{$2}\
{$3}\
{${lookup{service}lsearch{/etc/curly-stuff}}\
{${lookup{realm}lsearch{/etc/curly-stuff}}\
}{yea}{nay}}

but that's not very elegant.

> I think, however, that we should keep the syntax of pwcheck and
> saslauthd the same. The former is
>
> ${if pwcheck{user:password}
>
> which forbids a colon in the username, but not in the password.

Problem is, while for two fields with more-or-less clear semantics this is
acceptable, four fields of saslauthd, with two latter still remaining a
mystery, I'm afraid colon-separation is not the right thing.

> In retrospect, that was probably a bad idea, even though colons in user
> names are unlikely. Maybe I should modify pwcheck to allow the
> alternative syntax and deprecate the old syntax.

I think it's better to deprecate pwcheck condition itself. In Cyrus SASL
pwcheck has been deprecated long long ago in favor of saslauthd.

--

./lxnt