On 6 Dec 2005, at 17:21, Timo Sirainen wrote:> On Tue, 2005-12-06 at 17:11 +0000, William Ross wrote: >> On 6 Dec 2005, at 16:51, Timo Sirainen wrote: >> >>> On Fri, 2005-10-28 at 17:52 +0200, Riccardo Bini wrote: >>>>> I just wrote this: http://wiki.dovecot.org/Quota >>>> Well... but you have to correct %n with vpopmail backend. %u in the >>>> default_mail_env (like in the log) is always the user name without >>>> the >>>> domain.... >>> >>> That's a bug in Dovecot's vpopmail code. I don't know why it doesn't >>> work. Would be nice if someone using vpopmail fixed that.. >> >> point me in the right direction and I'll have a go. > > src/auth/passdb-vpopmail.c > > If user logs in as user@domain, then they both should be in > request->user string. %d is taken from there. I don't see request- > >user > being modified in that file either, so I think it should have worked..I finally got round to working on this. I'm a perl programmer, and it has all been very educational, so please bear with me :) I was stuck because the domain name was not interpolated into the Maildir path[0], when using the configuration recommended here: http://wiki.dovecot.org/ QuestionsAndAnswers#head-153aa253aff40951a05cf238da4245b1cc1a4665 It turns out that the answer is really simple. You don't need to supply a default_mail_env parameter with vpopmail and dovecot v1.x. Indeed, you shouldn't: the path to the maildir is retrieved from vpopmail and if you specify default_mail_env then it will be used in place of that correct value. Also, it will be used wrongly, as there is also an interpolation bug, and %d isn't replaced correctly. The code in passdb-vpopmail and userdb-vpopmail works perfectly, by the way: the login email address[1] is parsed correctly, the vpopmail hookup is correct, and the vqpasswd struct that is returned by vpopmail_lookup_vqp contains all the right values. eg (these are debugging-for-dummies lines that I've scattered everywhere):> dovecot: Jan 17 22:51:42 Info: auth(default): * > vpopmail_verify_plain: now vpop_user = sysadmin, vpop_domain = > spanner.org, request->user = sysadmin@spanner.org, vpw->pw_dir = / > home/vpopmail/domains/spanner.org/sysadminin the callback method I got this tab-separated auth_reply_stream:> dovecot: Jan 18 00:30:01 Info: auth(default): userdb_callback str: > USER 2 sysadmin uid=7797 gid=2109 home=/home/ > vpopmail/domains/spanner.org/sysadminbut I still saw these lines later:> dovecot: Jan 18 01:31:46 Info: imap(sysadmin): maildir: root=/home/ > vpopmail/domains//sysadmin/Maildir, index=/home/vpopmail/domains// > sysadmin/Maildir, control=, inboxI became suspicious, and tested with nonsense values in default_mail_env: sure enough i got the same thing. During the userdb stage we have the correct path to the maildir, but later on we see a different value derived from the nonsense configuration I've just entered. I guess that we're getting the initial value from vpopmail and try the same thing but with no default_mail_env entry at all. It works perfectly. I say some new words I have learned from my wife. I don't know where the failure lies, but I can tell you that the 'user' value passed to get_var_expand_table (which comes from getenv ("USER")) contains only the first part of the email address. That's probably not the intention, because get_var_expand_table then tries to split it on @. As it happens the home-directory value is passed to get_var_expand_table as the expansion for %h, so this works too, in a completely redundant way: default_mail_env = maildir:%h I've tested this with an new tarball of 1.0.beta1 and it works fine - with the configuration change - so if this all sounds sane to you then I'll update the wiki. best, will [0] under vpopmail the maildir for the address brian@domain.com usually lives somewhere like: /home/vpopmail/domains/domain.com/brian/, [1] in order to disambiguate usernames, vpopmail has you log in with your full email address as the user id. dovecot would therefore need to split the email address and interpolate the fragments into the maildir path to get to the right place. however, the vpopmail password file also specifies the maildir for each user, which i guess is what dovecot is using now.
The QuestionsAndAnswers page on the wiki is immutable, but the configuration it gives for vpopmail users is wrong. how would I go about correcting it, please? will On 18 Jan 2006, at 02:33, William Ross wrote:> On 6 Dec 2005, at 17:21, Timo Sirainen wrote: >> On Tue, 2005-12-06 at 17:11 +0000, William Ross wrote: >>> On 6 Dec 2005, at 16:51, Timo Sirainen wrote: >>> >>>> On Fri, 2005-10-28 at 17:52 +0200, Riccardo Bini wrote: >>>>>> I just wrote this: http://wiki.dovecot.org/Quota >>>>> Well... but you have to correct %n with vpopmail backend. %u in >>>>> the >>>>> default_mail_env (like in the log) is always the user name without >>>>> the >>>>> domain.... >>>> >>>> That's a bug in Dovecot's vpopmail code. I don't know why it >>>> doesn't >>>> work. Would be nice if someone using vpopmail fixed that.. >>> >>> point me in the right direction and I'll have a go. >> >> src/auth/passdb-vpopmail.c >> >> If user logs in as user@domain, then they both should be in >> request->user string. %d is taken from there. I don't see request- >> >user >> being modified in that file either, so I think it should have >> worked.. > > I finally got round to working on this. I'm a perl programmer, and > it has all been very educational, so please bear with me :) > > I was stuck because the domain name was not interpolated into the > Maildir path[0], when using the configuration recommended here: > > http://wiki.dovecot.org/ > QuestionsAndAnswers#head-153aa253aff40951a05cf238da4245b1cc1a4665 > > It turns out that the answer is really simple. You don't need to > supply a default_mail_env parameter with vpopmail and dovecot v1.x. > Indeed, you shouldn't: the path to the maildir is retrieved from > vpopmail and if you specify default_mail_env then it will be used > in place of that correct value. Also, it will be used wrongly, as > there is also an interpolation bug, and %d isn't replaced correctly. > > The code in passdb-vpopmail and userdb-vpopmail works perfectly, by > the way: the login email address[1] is parsed correctly, the > vpopmail hookup is correct, and the vqpasswd struct that is > returned by vpopmail_lookup_vqp contains all the right values. eg > (these are debugging-for-dummies lines that I've scattered > everywhere): > >> dovecot: Jan 17 22:51:42 Info: auth(default): * >> vpopmail_verify_plain: now vpop_user = sysadmin, vpop_domain = >> spanner.org, request->user = sysadmin@spanner.org, vpw->pw_dir = / >> home/vpopmail/domains/spanner.org/sysadmin > > in the callback method I got this tab-separated auth_reply_stream: > >> dovecot: Jan 18 00:30:01 Info: auth(default): userdb_callback str: >> USER 2 sysadmin uid=7797 gid=2109 home=/home/ >> vpopmail/domains/spanner.org/sysadmin > > but I still saw these lines later: > >> dovecot: Jan 18 01:31:46 Info: imap(sysadmin): maildir: root=/home/ >> vpopmail/domains//sysadmin/Maildir, index=/home/vpopmail/domains// >> sysadmin/Maildir, control=, inbox> > I became suspicious, and tested with nonsense values in > default_mail_env: sure enough i got the same thing. During the > userdb stage we have the correct path to the maildir, but later on > we see a different value derived from the nonsense configuration > I've just entered. I guess that we're getting the initial value > from vpopmail and try the same thing but with no default_mail_env > entry at all. It works perfectly. I say some new words I have > learned from my wife. > > I don't know where the failure lies, but I can tell you that the > 'user' value passed to get_var_expand_table (which comes from getenv > ("USER")) contains only the first part of the email address. That's > probably not the intention, because get_var_expand_table then tries > to split it on @. > > As it happens the home-directory value is passed to > get_var_expand_table as the expansion for %h, so this works too, in > a completely redundant way: > > default_mail_env = maildir:%h > > I've tested this with an new tarball of 1.0.beta1 and it works fine > - with the configuration change - so if this all sounds sane to you > then I'll update the wiki. > > best, > > will > > > > [0] under vpopmail the maildir for the address brian@domain.com > usually lives somewhere like: /home/vpopmail/domains/domain.com/ > brian/, > > [1] in order to disambiguate usernames, vpopmail has you log in > with your full email address as the user id. dovecot would > therefore need to split the email address and interpolate the > fragments into the maildir path to get to the right place. however, > the vpopmail password file also specifies the maildir for each > user, which i guess is what dovecot is using now. > >
On Wed, 2006-01-18 at 02:33 +0000, William Ross wrote:> > dovecot: Jan 17 22:51:42 Info: auth(default): * > > vpopmail_verify_plain: now vpop_user = sysadmin, vpop_domain = > > spanner.org, request->user = sysadmin@spanner.org, vpw->pw_dir = / > > home/vpopmail/domains/spanner.org/sysadmin > > in the callback method I got this tab-separated auth_reply_stream: > > > dovecot: Jan 18 00:30:01 Info: auth(default): userdb_callback str: > > USER 2 sysadmin uid=7797 gid=2109 home=/home/ > > vpopmail/domains/spanner.org/sysadminI guess this fixes it then: diff -u -r1.19 userdb-vpopmail.c --- src/auth/userdb-vpopmail.c 16 Oct 2005 14:34:39 -0000 1.19 +++ src/auth/userdb-vpopmail.c 22 Jan 2006 09:58:37 -0000 @@ -85,7 +85,7 @@ } reply = auth_stream_reply_init(auth_request); - auth_stream_reply_add(reply, NULL, vpw->pw_name); + auth_stream_reply_add(reply, NULL, request->user); auth_stream_reply_add(reply, "uid", dec2str(uid)); auth_stream_reply_add(reply, "gid", dec2str(gid)); auth_stream_reply_add(reply, "home", vpw->pw_dir); -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://dovecot.org/pipermail/dovecot/attachments/20060122/478bd28f/attachment.pgp