[Dovecot] MySQL passdb, auth_verbose, and documentation

[Timo Sirainen]

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

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://dovecot.org/pipermail/dovecot/attachments/20040809/048144ad/attachment-0001.bin>