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=144038 Note 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....@example.com: lmtp(15823): Connect from local [...] auth: Debug: master in: USER 1 john....@example.com service=lmtp auth: Debug: prefetch(john....@example.com): passdb didn't return userdb entries, trying the next userdb [...] auth-worker(15825): Debug: auth(john....@example.com): username changed john....@example.com -> john.doe auth: Debug: userdb out: USER 1 john....@example.com lmtp(15823): Debug: auth input: john....@example.com lmtp(15823): Debug: Added userdb setting: plugin/=yes lmtp(15823, john....@example.com): Debug: Effective uid=999, gid=999, home=/some/path/john....@example.com lmtp(15823, john....@example.com): Debug: Quota root: name=Quota utilisateur backend=dict args=john....@example.com:proxy::sql_quota [...] lmtp(15823): Disconnect from local: Successful quit There's a "username changed" line too, leading to great hopes... Yet, variable %u from dovecot.conf has been expanded to "john....@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
