[Dovecot] Re: %d empty even though username has @domain
Daniel Watts
d at nielwatts.com
Mon Mar 27 02:39:03 EEST 2006
dovecot-ri wrote:
> Daniel Watts wrote:
>
>> William Ross wrote:
>>
>>> hello,
>>>
>>> Sorry to jump straight in with a question, but I've searched the
>>> archive[0] and I'm pretty sure the answer's not there.
>>>
>>> I'm using dovecot to replace courier imap, so authentication is by
>>> vpopmail and the Maildirs are stored in the usual domains/domain/user/
>>> Maildir. Everything seems to work very well, and setting it up has been
>>> easy, so thank you very much for that.
>>>
>>> I have only one problem left: %d is empty when interpolated into
>>> default_mail_env. I expect there's something obvious I'm doing wrong,
>>> but it's hard to tell because the wiki isn't always up to date (i'd be
>>> happy to update the vpopmail sections once this is working):
>>>
>>> Config has this [1]:
>>>
>>> default_mail_env = maildir:/home/vpopmail/domains/%d/%n/Maildir
>>>
>>> and i log in over imaps with the account i'm using for testing:
>>>
>>> username: sysadmin at spanner.org
>>> password: ...
>>>
>>> Authentication seems to work perfectly, but then the logs show:
>>>
>>> dovecot: Dec 05 12:24:59 Info: imap(sysadmin): maildir: root=/home/
>>> vpopmail/domains//sysadmin/Maildir, index=/home/vpopmail/domains//
>>> sysadmin/Maildir, control=, inbox=
>>>
>>> any suggestions, please?
>>>
>>> thank you,
>>>
>>> will
>>>
>>>
>> Will, Timo,
>>
>> [CCed to Timo as he implemented a solution to a related problem].
>>
>> Digging this up from the archives - I have the same problem and can't
>> find the solution. However: I've traced the problem through my mail logs:
>>
>> Mar 22 18:16:43 tg1 dovecot: auth(default): client in: AUTH 1 PLAIN
>> service=IMAP lip=xxx.xxx.35.122 rip=xxx.xxx.32.85
>> resp=AGRhbkBhbHVtaW5hdGkubmV0AHBhc3Mx
>> Mar 22 18:16:43 tg1 dovecot: auth-worker(default):
>> sql(dan at domain.net,xxx.xxx.32.85): query: SELECT username as user,
>> password, mailenv as userdb_mail, uid as userdb_uid, gid as userdb_gid
>> FROM users WHERE username = 'dan' AND domain = 'domain.net'
>> Mar 22 18:16:43 tg1 dovecot: auth-worker(default):
>> auth(dan at domain.net,xxx.xxx.32.85): username changed dan at domain.net -> dan
>> Mar 22 18:16:43 tg1 dovecot: auth(default):
>> auth(dan at domain.net,xxx.xxx.32.85): username changed dan at domain.net -> dan
>> Mar 22 18:16:43 tg1 dovecot: auth(default): client out: OK 1 user=dan
>> Mar 22 18:16:43 tg1 dovecot: auth(default): master in: REQUEST 1 24736
>> 1
>>
>>
>> The line to look for says:
>>
>> username changed dan at domain.net -> dan
>>
>> After this point %d is empty which is a problem if you use it in any
>> configuration settings (which I'm trying to do).
>>
>> The login now works because I use the prefetch to fetch the mail and
>> home directory informatin out of the database (rather than dynamically
>> work it out) but there are some other settings (ie namespaces) where I
>> wan to use %d.
>>
>> Can anyone suggest how to maintain the information in %d?
>> Particularly why does it shorten the username to "dan"?
>>
>> Daniel
>>
>
>
> Your SQL query is not returning the domain part in the "user" field. The name returned in the "user" field replaces the IMAP username for all future stuff. Change your SQL query like this (assuming MySQL):
>
> SELECT
> CONCAT(username, '@', domain) as user,
> password,
> mailenv as userdb_mail,
> uid as userdb_uid,
> gid as userdb_gid
> FROM
> users
> WHERE
> username = 'dan' AND domain = 'domain.net';
>
> This same issue tripped me up for quite a while until I finally figured it out. Virtual users with a user part that matched a local username were accessing the local user's e-mail, not their own. This was because the SQL passdb was authenticating them but the passwd userdb was returning the home directory.
>
> Hope this helps!
>
>
Many thanks! Timo came back with the same answer and it worked perfectly
then.
A little clarification/warning in the dovecot-sql.conf file would
probably be a good idea to avoid other people being caught out. If it
can happen twice it *will* happen again!
Daniel
More information about the dovecot
mailing list