Re: [exim] Dovecot authentication

Top Page
Delete this message
Reply to this message
Author: W B Hacker
Date:  
To: exim users
Subject: Re: [exim] Dovecot authentication
Renaud Allard wrote:
> Tony Finch wrote:
>
>>On Sun, 9 Jul 2006, Renaud Allard wrote:
>>
>>
>>>All passwords are already stored in a kerberos server _AND_ a plaintext
>>>file (could be SQL, but this wouldn't change anything as this would be a
>>>plaintext store anyway). However, I still need 2 password's DB to
>>>provide all authentication possibilities. My goal is to have only one
>>>encrypted DB to hold all of the authentication data. And this DB has to
>>>be a kerberos server in order to provide GSSAPI auth.
>>
>>If you want Kerberos you need cyrus_sasl.
>>
>
>
> I already compiled exim with cyrus_sasl and it works well with GSSAPI
> authentication. Exim also works well with cyrus_sasl for PLAIN, CRAM,
> LOGIN as they are available in cyrus. Dovecot also works well with
> PLAIN, LOGIN, GSSAPI, etc but doesn't use cyrus and isn't able to do
> PLAIN, LOGIN, CRAM with the kerberos authentication. So in my case, I
> have 2 databases to handle the passwords, one in plaintext for dovecot
> and exim for PLAIN, LOGIN, CRAM, and one on the kerberos server for
> GSSAPI. What that means is both databases should be treated differently
> based on the authentication scheme, which is very unpractical.


Not much of a 'database' if you need a separate DB for each field of each record.

> Also, if
> passwords for GSSAPI are the same than plaintext ones, that means there
> is a plaintext file which contains all the principals passwords, which
> is IMHO a very bad idea.
> So, for the moment, I think I have 2 solutions:
> 1: switch to cyrus-imapd (which doesn't seem a good idea to me)
> 2: write a patch for dovecot which uses cyrus-sasl to mimic exim's behaviour
>

3: Learn what a real database can do for you.

4: Use the much smaller set of methods real-world MUA's actually support.

> Conclusion: I don't think this is an exim related problem anymore :)
>
>


Not to put too fine a point on it, but it never was.

Bill Hacker