I've been playing around with Dovecot for the past few months for testing (on a Debian 3.0 system), and initially it was easy to setup and worked well.
Recently I upgraded to 0.99.10.9, and when I rebuilt it I enabled MySQL and SSL.
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.
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 set up dovecot-mysql.conf as I thought it should be, created a database, added a record with a digest-md5 password, and changed some dovecot.conf directives as follows:
default_mail_env = maildir:/var/mail/%d/%n/ auth_mechanisms = digest-md5 auth_default_realm = example.com auth_userdb = static uid=5000 gid=5000 home=/var/mail/%d/%n/ auth_passdb = mysql /etc/dovecot-mysql.conf
For the static auth_userdb I wasn't quite sure what to put after home= as I wasn't really defining a home directory location. I initially tried making it identical to default_mail_env, but later learned that it clearly didn't like the "maildir:" prefix.
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?
I tried to access Dovecot from a mail client and repeatedly received a login failure. Unfortunately, this is typical of what I saw in the log file:
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]
I enabled auth_verbose: auth_verbose = yes
and checked my syslog.conf to make sure all priorities were being logged: mail.* /var/log/syslog/mail.log
but still no additional verbosity. How should things look different when auth_verbose is enabled?
Checking MySQL's log I could see that Dovecot was successfully connecting to the database server, but never executing any queries. I was going to next turn on logging of all IMAP traffic, but noticed the Wiki suggested trying a manual session, which I did:
% telnet localhost imap
- OK dovecot ready. 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?
That seemed odd, as 'digest-md5' is mentioned right in dovecot.conf as a valid choice.
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.
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?
I switched it to 'plain-md5', as mentioned in auth.txt, and tried again. That resulted in:
Aug 8 21:11:53 lex dovecot-auth: Unknown authentication mechanism 'plain-md5' Aug 8 21:11:53 lex dovecot: Auth process died too early - shutting down Aug 8 21:11:53 lex dovecot: child 10293 (auth) returned error 89 Aug 8 21:11:53 lex imap-login: fd_send(-1) failed: Broken pipe
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.
I tried switching to: auth_mechanisms = plain
and finally got something more expected:
Aug 8 21:20:44 lex dovecot-auth: mysql(tmetro@example.com): Password mismatch
I tried putting the password into the database unencrypted, but that didn't work (probably because of my default_pass_scheme setting?). Generating a PLAIN-MD5 per auth.txt finally worked.
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? In dovecot-mysql.conf I had: default_pass_scheme = DIGEST-MD5
and didn't change it. What purpose does it serve? Is it only to identify the encryption used when there isn't a {SCHEME} tag present?
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.
In other matters...during one of my login attempts I got:
- OK dovecot ready. 1 LOGIN tmetro@example.com password 1 OK Logged in. Connection closed by foreign host.
The abrupt disconnect after an apparently successful login seemed odd. The log file showed:
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?
At the end of the dovecot-example.conf is:
#auth = digest_md5 #auth_methods = digest-md5 #auth_realms = #auth_userdb = passwd-file /etc/passwd.imap #auth_passdb = passwd-file /etc/passwd.imap #auth_user = imapauth #auth_chroot =
Is auth_methods an alias for auth_mechanisms?
Aside from the insufficient detail in the log, most of the difficulty I encountered could be avoided with better documentation and comments in the config files. I'd be happy to submit clarified comments once I get some answers to the above questions and confirm my understanding of how things work.
-Tom