[Dovecot] MySQL passdb, auth_verbose, and documentation

[Tom Metro]

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 at 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 at 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 at 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