Le 5 juil. 2013 à 19:14, Axel Luttgens a écrit :
[...]
Hello Steffen,
You helped me to look twice at those matters. So, it seems that variable %u (or, for what matters, even %n) indeed expands to the value as changed thru a database lookup.
In fact, I now understand that I was struggling with a somewhat unexpected behavior of the prefetch database, and that I failed to correctly interpret the behaviors I was encountering. Will be a question for a next post. ;-)
Thanks to Timo (see http://www.dovecot.org/list/dovecot/2013-July/091315.html), that prefetch question has been solved.
But... But this allowed me to track more narrowly a differing behavior of the prefetch and the user databases. If you allow, I'll try to explain what I mean.
Let's consider these settings from dovecot.conf:
mail_uid = dovemailer
mail_gid = dovemailer
mail_home = /some/path/%u
plugin {
quota = dict:Quota utilisateur:%u:proxy::sql_quota
}and a password query looking like this one:
password_query = \
SELECT \
passwd AS password, \
nickname AS user, \
mail_home AS userdb_home, \
[...]
WHERE \
[...]John Doe, with nickname "john.doe" and a NULL mail_home, authenticates for a pop session as "u123456":
auth: Debug: auth client connected (pid=15516)
[...]
auth-worker(15518): Debug: auth(u123456,127.0.0.1): username changed u123456 -> john.doe
auth: Debug: auth(u123456,127.0.0.1,<XwGi7rPhNwB/AAAB>): username changed u123456 -> john.doe
[...]
auth: Debug: prefetch(john.doe,127.0.0.1,<XwGi7rPhNwB/AAAB>): success
[...]
pop3(john.doe): Debug: Effective uid=999, gid=999, home=/some/path/john.doe
pop3(john.doe): Debug: Quota root: name=Quota utilisateur backend=dict args=john.doe:proxy::sql_quota
[...]
pop3(john.doe): Disconnected: Logged out top=0/0, retr=0/0, del=0/92, size=144038Note the "username changed" lines. And it clearly appears that variable %u appearing in dovecot.conf has been expanded to the converted name ("john.doe"), not the original one ("u123456").
Let's now consider a userdb query similar to this one:
userdb_query = \
SELECT \
nickname AS user, \
mail_home AS userdb_home, \
[...]
WHERE \
[...]and send a message to john.doe@example.com:
lmtp(15823): Connect from local
[...]
auth: Debug: master in: USER 1 john.doe@example.com service=lmtp
auth: Debug: prefetch(john.doe@example.com): passdb didn't return userdb entries, trying the next userdb
[...]
auth-worker(15825): Debug: auth(john.doe@example.com): username changed john.doe@example.com -> john.doe
auth: Debug: userdb out: USER 1 john.doe@example.com
lmtp(15823): Debug: auth input: john.doe@example.com
lmtp(15823): Debug: Added userdb setting: plugin/=yes
lmtp(15823, john.doe@example.com): Debug: Effective uid=999, gid=999, home=/some/path/john.doe@example.com
lmtp(15823, john.doe@example.com): Debug: Quota root: name=Quota utilisateur backend=dict args=john.doe@example.com:proxy::sql_quota
[...]
lmtp(15823): Disconnect from local: Successful quitThere's a "username changed" line too, leading to great hopes... Yet, variable %u from dovecot.conf has been expanded to "john.doe@example.com", not "john.doe". And John Doe now has two mailboxes: one for receiving emails, the other for reading emails.
I understand I am on the fringe here, since the wiki doesn't say anything about the possible effects of a "AS username" (or "AS user") clause in the userdb_query. On the other hand, this could also just reflect an omission in the documentation, since the "username changed" line written to the log tend to indicate there could/should be an effect.
Hence my question: what's the intended behavior?
TIA, Axel