On Wed, 2004-08-11 at 03:27 -0400, Tom Metro wrote:
http://dovecot.org/doc/auth.txt says:
Authentication is split into three parts: authentication mechanism, password database and user database.
Which is good, except it never defines what "authentication mechanism" really means, and how it is distinct from how the password is stored.
How about:
http://wiki.dovecot.org/moin.cgi/Authentication
# Space separated list of wanted authentication mechanisms: # plain digest-md5 anonymous # # All IMAP/POP3 clients support plain-authentication. Digest-MD5 is more # secure, but it's not widely supported by clients. Note that by default # plaintext authentication is disabled unless SSL is used - see # disable_plaintext_auth setting. auth_mechanisms = plain
Here too, I think it would be useful to define "authentication mechanisms", but you should probably first provide a better definition for "Authentication processes." Though the term "process" makes me think that we're talking about an executable. But I guess it is defining the behavior of a child process - right?
Yes. Although it's also in a separate executable, but there can be multiple processes.
Perhaps:
## ## Authentication processes ##
# An Authentication process is a child process used by Dovecot that # handles the authentication steps. The steps cover an authentication # mechanism (auth_mechanisms, how the client authenticates in the IMAP # protocol), which password database should be queried (auth_passdb), # and which user database should be queried (auth_userdb, to obtain # UID, GID, and location of the user's mailbox/home directory). # # You can have multiple processes, though a typical configuration will # have only one. Each time "auth = xx" is seen, a new process # definition is started. The point of multiple processes is to be able # to set stricter permissions. (See auth_user below.) # # Just remember that only one Authentication process is asked for the # password, so you can't have different passwords accessible through # different process definitions (unless they have different # auth_mechanisms, and you're ok with having different password for # each mechanisms).
Looks good. I'll use that, except use IMAP/POP3 there.
(What is the order in which Authentication processes are chosen, if say, you have multiple defined for the 'plain' auth_mechanisms? Or is that considered a configuration error?
The order is unspecified. Dovecot will just chose one of them. With 0.99 multiple auth processes is quite pointless really. 1.0-tests support fallbacking to next process if first one fails.
That's also why I haven't really bothered to update 0.99's documentation. It makes less sense and once 1.0 is finished it has to be changed anyway. In Wiki I started to write about 1.0 already though..
# Specifies how the client authenticates in the IMAP protocol. ..
Also looks good.
# cram-md5 as the communication is already encrypted. Note that by # default plain text authentication is disabled unless SSL is used - # see disable_plaintext_auth setting. auth_mechanisms = plain
(I thought by default disable_plaintext_auth=no. Has that changed?
Right, it's no in 0.99. I've changed it to yes in 1.0-tests.
My assertion, "the password can be encrypted by Dovecot to match any of the encryption schemes used in password databases," may not be accurate. Your comments seem to imply that Dovecot won't translate a plain password to a digest-md5 storage scheme (perhaps also cram-md5), though it seems this should be possible.)
It's possible. I added "(or be in plaintext)" there.