And the answer is of course yes. Just the userdb out string has the wrong value. The right value is lost somewhere. But where?
Your messages to this list seem to miss a feature that is very welcome on this kind of mailing lists: an actual problem or an issue you want to fix.
I'm sorry that i wasn't able to formulate my problem correctly. :) I try to elaborate: If you read the config in my original message, and read the logs (line by line), then you will notice the following facts:
- The username change is intended.
- The log says, that the username change is happening as it should.
- The log says, that the "userdb out" contains the original (not changed) username.
- With passdb it works correctly: "passdb out" contains the right (changed) username.
Outcome 1.: Fact 3 means, that any service which calls for userdb lookup will get a wrong username. Wrong means here that it's not the username intended for userdb lookup callers.
Outcome 2.: For me, fact 4 says that it was the developers intention to be able to change the username. Eg.: to give *db lookup callers a changed username, not the original as entered by the user.
But outcome 1. and 2. contradicts each other. That gave me three possible conclusions: a. I made some mistake b. my assumption(s) was/were wrong c. Someone else made a mistake (it's a bug)
But i couldn't find out which is the correct, soooo i sent my original message to the list.
And while i tried to confute "conclusion b." i tried the whole process with LDAP. With success. LDAP userdb lookup returns the changed username. Here we are now. :)
Thank you, if you read it until here. My only excuse for not writing all that in my original message is that i wanted to keep my problem description clean and simple. In my 23 years of history on technical electronic messaging boards, i've been told many many times that i write irrelevant informations in my messages. (like this) :) And i assumed i couldn't change... :)
When users can login and the username change is intended (as can be concluded from your comments), then what is the problem you're reporting?
Are you trying to reporting the fact that the auth debug output has the wrong username value? If not, what is it you're to tell us? :)
I hope that the debug output is a trustful source of information. But who knows? It would be my third assumption proved wrong - today.
And all my struggle just to be able to use quota-status service with postfix. With unauthenticated senders, postfix only sends the recipient address (beside many irrelevant data) to the policy service (quota-status). So userdb has to use the email address to lookup up the quota rule, and to give a username to quota-dict for lookup. My usernames are sadly not email addresses, thats why i had to make query which resolves addresses to usernames. The whole problem started here.
Regards,
Peter