dovecot - Sep 2010 - password_query, user_query and unrelated userid and emails

Let's say one has a SQL table with following fields for John Doe:

	login:		u0007
	password:	{SHA1}...
	mailhome:	/path/to/joeshome
	email:		john.doe at example.com

To log in, for internal policy reasons, John MUST make use of his userid
"u0007".
So, in the password_query, one would need something like:

	... WHERE login = '%u' ...

On the other hand, for receiving mail thru say, LMTP, one would need something
like this in the user_query:

	... WHERE email = '%Lu' ...

With such a simplistic setup, this works fine:

	$ doveadm auth u0007
	Password:
	passdb: u0007 auth succeeded

but this one obviously fails:

	$ doveadm user u0007
	userdb lookup: user u0007 doesn't exist

and one has to do:

	$ doveadm user john.doe at example.com
	userdb: john.doe at example.com
	  home       : /path/to/joeshome

I can't manage to devise a way to systematically refer to users thru their
login, nor to avoid such messages:

	prefetch(u0007): passdb didn't return userd entries, trying the next userdb

There sure must be a way thru adequate "SELECT ... AS ..." clauses.
Could someone show me the light?

Many, many TIA,
Axel

On Sat, 2010-09-25 at 15:23 +0200, Axel Luttgens wrote:
> Let's say one has a SQL table with following fields for John Doe:
> 
> 	login:		u0007
> 	password:	{SHA1}...
> 	mailhome:	/path/to/joeshome
> 	email:		john.doe at example.com
> 
> To log in, for internal policy reasons, John MUST make use of his userid
"u0007".
> So, in the password_query, one would need something like:
> 
> 	... WHERE login = '%u' ...
> 
> On the other hand, for receiving mail thru say, LMTP, one would need
something like this in the user_query:
> 
> 	... WHERE email = '%Lu' ...
You could make it so that password_query changes the username to email
by selecting "email AS user" and then user_query has only the
email='%
Lu'. Or you could make your user_query have "where (email='%Lu'
or
user='%u').
> I can't manage to devise a way to systematically refer to users thru
their login, nor to avoid such messages:
> 
> 	prefetch(u0007): passdb didn't return userd entries, trying the next
userdb
This seems like a different problem to me..