[Dovecot] Variable similar to %u but providing the username changed by a database lookup?

[Axel Luttgens]

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 at example.com:

	lmtp(15823): Connect from local
	[...]
	auth: Debug: master in: USER	1	john.doe at example.com	service=lmtp
	auth: Debug: prefetch(john.doe at example.com): passdb didn't return userdb entries, trying the next userdb
	[...]
	auth-worker(15825): Debug: auth(john.doe at example.com): username changed john.doe at example.com -> john.doe
	auth: Debug: userdb out: USER	1	john.doe at example.com	
	lmtp(15823): Debug: auth input: john.doe at example.com 
	lmtp(15823): Debug: Added userdb setting: plugin/=yes
	lmtp(15823, john.doe at example.com): Debug: Effective uid=999, gid=999, home=/some/path/john.doe at example.com
	lmtp(15823, john.doe at example.com): Debug: Quota root: name=Quota utilisateur backend=dict args=john.doe at 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 at 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