On 9.8.2004, at 09:31, Tom Metro wrote:
The first problem I ran into was upon startup it complained that there was no certificate, which makes sense, except that I hadn't enabled imaps in the config file. It would make more sense not to require SSL support files if SSL isn't being used. But this is minor.
imaps in protocol line only means that it's listening in imaps-port. SSL can still be used by giving STARTTLS command. So SSL is really disabled only when you set ssl_disable = yes, and then it doesn't ask about certificates.
I encountered more serious problems when I tried migrating from real user accounts to virtual accounts via MySQL. Has anyone written a howto on setting up Dovecot with MySQL? (Just pointing to dovecot-mysql.conf leaves out a lot.) If not, I'll volunteer to write something up.
I've written howto for Postgresql in wiki. Maybe it could be used as a base for Mysql-specific howto.
Some questions the documentation left unanswered: Is home= required if default_mail_env will suffice for virtual users? Can mail= be used instead, as implied by the database documentation? Practically speaking, is there any difference between the two in the case of virtual user accounts?
Dovecot chdir()s into user's home directory. Currently there's no other difference. Maybe later I add some other things such as possibility to read user-specific settings from ~/.dovecotrc. Also if you enable rawlogs they're written under home directory.
Aug 8 03:53:50 lex dovecot: Dovecot starting up Aug 8 03:53:52 lex dovecot-auth: MySQL: connected to localhost Aug 8 03:55:13 lex imap-login: Disconnected: Inactivity [192.168.0.200] .. but still no additional verbosity. How should things look different when auth_verbose is enabled?
auth_verbose logs each authentication attempt and reason if it failed.
1 LOGIN tmetro@example.com password 1 NO Login failed: Unsupported authentication mechanism
Isn't this the kind of thing that should appear in the log when auth_verbose is enabled?
Hmm. auth_verbose is handled by dovecot-auth process completely. In this case imap-login process never sent anything to dovecot-auth because it knew itself that it won't work.
Perhaps it should be logged, but it'd be kind of annoying to fix without ugly kludging.
That seemed odd, as 'digest-md5' is mentioned right in dovecot.conf as a valid choice.
It enables digest-md5 authentication mechanism then which works only if client supports and uses it.
In retrospect, I gather what the message above is trying to tell me is that Dovecot wasn't configured to accept a 'plain' authentication, which is apparently what I was using in my manual session. It would be nice if the error message could express that a bit better.
Yes, could be. The error message is fine for AUTHENTICATE command I think, but for LOGIN it could be something like: "Plaintext authentication mechanism is disabled"
I did have some suspicion that it might be the that plain text authentication was being prevented, as at that point I didn't know what auth_mechanisms applied to, but I looked at dovecot.conf and found disable_plaintext_auth = no, which seemed to imply that plain text at the IMAP protocol level should have been permitted. Might it be clearer if that attribute was incorporated into the auth_mechanisms settings or at least moved into the auth section?
Not really. Plaintext auth mechanisms can still be used if SSL is enabled. As for moving into auth section.. Hm.. Maybe. But it's also somewhat SSL-specific setting and it's currently grouped with SSL settings. How about:
# 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
That got me wondering whether there were two different areas where authentication terms apply - one being the password exchange in the IMAP protocol, and the other being how the password is stored on the server - yet the discussion of the two seems to be mixed together in the documentation.
Where? I don't see any obvious mixes, except that DIGEST-MD5 is both an authentication mechanism name and password scheme name (because they're supposed to be used together).
I tried putting the password into the database unencrypted, but that didn't work (probably because of my default_pass_scheme setting?).
Yep.
This leads to some questions: auth_mechanisms doesn't seem to be describing the way in which the password is stored, so what does it describe?
The way client and server perform the authentication. With plain client sends the password directly, others are more advanced.
In dovecot-mysql.conf I had: default_pass_scheme = DIGEST-MD5
and didn't change it.
Default is PLAIN-MD5. DIGEST-MD5 scheme isn't very useful unless you're using DIGEST-MD5 authentication.
What purpose does it serve? Is it only to identify the encryption used when there isn't a {SCHEME} tag present?
Right.
For DIGEST-MD5, which encrypts "user:realm:pass", does realm include the @? Does user include @realm? I assumed no in both cases, yet it didn't work.
Clients that support DIGEST-MD5 usually ask you for username, realm and password separately. So there's no @ anywhere. Although I think currently if realm isn't given but username contains @ character, the realm is taken from after the @ char. Realms are a bit confusing and I'm not sure how well they even work.
Aug 8 21:23:47 lex dovecot: chdir(maildir:/var/mail/example.com/tmetro/) failed with uid 5000: Permission denied Aug 8 21:23:47 lex dovecot: child 10315 (imap) returned error 89
which is the problem I discussed above, but is it reasonable for Dovecot to disconnect the IMAP socket and not send an error message to the client?
In case of a initial server misconfiguration, I think it's good enough. And I'm not sure if there's any easy and non-horribly-kludgy way to do it with current design.
Is auth_methods an alias for auth_mechanisms?
It's an old name for it that I had forgotten to change. Fixed.