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.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 quit

There'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