Hello,

Let's say dovecot.conf contains:

        mail_uid        = dovemailer
        mail_gid        = dovemailer
        mail_home       = /some/path/%n
        mail_location   = mbox:~/mboxes:INBOX=~/mboxes/inbox

and that the password database query is of the form:

        password_query = \
        SELECT \
                passwd AS password, \
                nickname AS user, \
                mail_home AS userdb_home, \
                mail_location AS userdb_mail, \
        WHERE \
                ...

The database initially comes with NULL for both mail_home and mail_location, 
the goal being to be able to progressively replace legacy settings.

With the above, one gets such entries in the logs upon a pop or imap connection:

        auth-worker(11262): Debug: auth(u12345678,127.0.0.1): username changed 
u12345678 -> john.doe
        auth: Debug: auth(u12345678,127.0.0.1,<dsNsasbgRQB/AAAB>): username 
changed u12345678 -> john.doe
        [...]
        auth: Debug: prefetch(john.doe,127.0.0.1,<dsNsasbgRQB/AAAB>): passdb 
didn't return userdb entries, trying the next userdb

and, of course, the userdb_query fails since it isn't supposed to be invoked 
under such circumstances.

Of course, the userdb_query could be adapted so as to handle pop/imap 
connections in addition to say, lmtp or doveadm connections, but this would 
anyway raise the question: why bother with a prefetch database setup?

In fact, it seems that the problem comes from the fact that the password_query 
returns NULL values (i.e. "do not override dovecot.conf settings") for all 
userdb_xxx settings even if, technically speaking, it returns such columns.

A slight yet somewhat silly modification of the password_query, such as this 
one:

        password_query = \
        SELECT \
                passwd AS password, \
                nickname AS user, \
                'dovemailer' AS userdb_uid, \
                mail_home AS userdb_home, \
                mail_location AS userdb_mail, \
        WHERE \
                ...

indeed seems to bring back all the expected behavior: now, the "passdb returns 
userdb entries" and, for example, the config's mail_home expands to the 
expected value /some/path/john.doe.

Could it be that the case "userdb_xxx columns returned, even if all with NULL 
values" has been somehow overlooked in the code?
Or am I erring with my interpetation of all those matters?

TIA,
Axel

Reply via email to