Re: [Dovecot] Initial support for shared mailboxes
On Oct 11, 2008, at 10:52 AM, Sascha Wilde wrote: I have made a first rough sketch of the userdb-checkpassword back end, basically by copying the code of the passdb version. Now I stumbled upon the note "FIXME: if we ever do some other kind of forking, this needs fixing" in sigchld_handler(). The only problem I experienced is, that the handler dosen't return, when the signaling child wasn't listed in the modules clients -- but simply replacing the continue with return like this: Please ignore this statement -- wrong test, wrong result ... The proposed change is not sufficient, the only reason why my test didn't fail was, that I used an other passdb backend, so that my userdb backend was the only one registering a SIGCHILD handler... This might be helpful: http://hg.dovecot.org/icecap/file/401c2bc71594/src/lib/child-wait.h http://hg.dovecot.org/icecap/file/401c2bc71594/src/lib/child-wait.c Idea would be that you'd have two child_waits, one for passdb and one for userdb. Then you'd add all the PIDs to that wait structure. I guess it should also have a plain child_wait_new() without a PID. PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] Initial support for shared mailboxes
Sascha Wilde <[EMAIL PROTECTED]> writes: > Sascha Wilde <[EMAIL PROTECTED]> writes: >> Timo Sirainen <[EMAIL PROTECTED]> writes: >>> On Sep 30, 2008, at 6:08 PM, Sascha Wilde wrote: >> [...] So I guess what is needed is a new userdb backend which is explicitly runs an arbitrary external program to get the user data (instead of caching the passdb results). >>> >>> Right. Perhaps the passdb checkpassword code could be used as userdb >>> too, just with an added extra variable specifying if it's a passdb or >>> a userdb lookup. >> >> I just started to work on this feature > > I have made a first rough sketch of the userdb-checkpassword back end, > basically by copying the code of the passdb version. Now I stumbled > upon the note "FIXME: if we ever do some other kind of forking, this > needs fixing" in sigchld_handler(). > > The only problem I experienced is, that the handler dosen't return, when > the signaling child wasn't listed in the modules clients -- but simply > replacing the continue with return like this: Please ignore this statement -- wrong test, wrong result ... The proposed change is not sufficient, the only reason why my test didn't fail was, that I used an other passdb backend, so that my userdb backend was the only one registering a SIGCHILD handler... cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpdDygB0XVTs.pgp Description: PGP signature
Re: [Dovecot] Initial support for shared mailboxes
Sascha Wilde <[EMAIL PROTECTED]> writes: > Timo Sirainen <[EMAIL PROTECTED]> writes: >> On Sep 30, 2008, at 6:08 PM, Sascha Wilde wrote: > [...] >>> So I guess what is needed is a new userdb backend which is explicitly >>> runs an arbitrary external program to get the user data (instead of >>> caching the passdb results). >> >> Right. Perhaps the passdb checkpassword code could be used as userdb >> too, just with an added extra variable specifying if it's a passdb or >> a userdb lookup. > > I just started to work on this feature I have made a first rough sketch of the userdb-checkpassword back end, basically by copying the code of the passdb version. Now I stumbled upon the note "FIXME: if we ever do some other kind of forking, this needs fixing" in sigchld_handler(). The only problem I experienced is, that the handler dosen't return, when the signaling child wasn't listed in the modules clients -- but simply replacing the continue with return like this: --- a/src/auth/passdb-checkpassword.c Fri Oct 10 12:06:06 2008 +0200 +++ b/src/auth/passdb-checkpassword.c Fri Oct 10 21:34:36 2008 +0200 @@ -165,7 +165,7 @@ "with signal %d", dec2str(pid), WTERMSIG(status)); } - continue; + return; } if (WIFSIGNALED(status)) { seems to fix this. The next handler is called and every thing seems to work well (at least at a first very short test). Is there any reason not to do so? And are there any other issues you had in mind writing the FIXME? cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpjBtt4OXRgC.pgp Description: PGP signature
Re: [Dovecot] Initial support for shared mailboxes
Timo Sirainen <[EMAIL PROTECTED]> writes: > On Wed, 2008-10-08 at 12:54 +0200, Sascha Wilde wrote: >> I just started to work on this feature and for testing purpose I wrote a >> very simple dummy checkpassword program. But I have a problem setting >> the UID and GID: >> >> I'm using: >> >> userdb_uid=12345 >> userdb_gid=12345 >> EXTRA="userdb_uid userdb_gid" >> export userdb_uid userdb_gid EXTRA >> >> according to http://wiki.dovecot.org/PasswordDatabase/CheckPassword but > > I guess it worked more or less accidentally at some point. Changed now > so it should really work: > http://hg.dovecot.org/dovecot-1.2/rev/a38778911fa9 Thanks, works now for me as expected. cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgploq3KrSOdc.pgp Description: PGP signature
Re: [Dovecot] Initial support for shared mailboxes
On Wed, 2008-10-08 at 12:54 +0200, Sascha Wilde wrote: > I just started to work on this feature and for testing purpose I wrote a > very simple dummy checkpassword program. But I have a problem setting > the UID and GID: > > I'm using: > > userdb_uid=12345 > userdb_gid=12345 > EXTRA="userdb_uid userdb_gid" > export userdb_uid userdb_gid EXTRA > > according to http://wiki.dovecot.org/PasswordDatabase/CheckPassword but I guess it worked more or less accidentally at some point. Changed now so it should really work: http://hg.dovecot.org/dovecot-1.2/rev/a38778911fa9 signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Initial support for shared mailboxes
Timo Sirainen <[EMAIL PROTECTED]> writes: > On Sep 30, 2008, at 6:08 PM, Sascha Wilde wrote: [...] >> So I guess what is needed is a new userdb backend which is explicitly >> runs an arbitrary external program to get the user data (instead of >> caching the passdb results). > > Right. Perhaps the passdb checkpassword code could be used as userdb > too, just with an added extra variable specifying if it's a passdb or > a userdb lookup. I just started to work on this feature and for testing purpose I wrote a very simple dummy checkpassword program. But I have a problem setting the UID and GID: I'm using: userdb_uid=12345 userdb_gid=12345 EXTRA="userdb_uid userdb_gid" export userdb_uid userdb_gid EXTRA according to http://wiki.dovecot.org/PasswordDatabase/CheckPassword but then I get an internal login failure. From the dovecot log: Oct 08 12:42:02 burlywood3 dovecot[3804]: auth(default): prefetch([EMAIL PROTECTED],192.168.11.254): success Oct 08 12:42:02 burlywood3 dovecot[3804]: auth(default): master out: USER[EMAIL PROTECTED] home=/kolab/var/dovecot/spool/[EMAIL PROTECTED]/home uid=0 gid=0 uid=19415 gid=19415 Oct 08 12:42:02 burlywood3 dovecot[3804]: uid specified multiple times for [EMAIL PROTECTED] So am I missing something or is this dovecot extension currently broken? cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpVpA0AkZ0jp.pgp Description: PGP signature
Re: [Dovecot] Initial support for shared mailboxes
On Sep 30, 2008, at 6:48 PM, Sascha Wilde wrote: On Sep 30, 2008, at 6:08 PM, Sascha Wilde wrote: Is there a %%h, too? So that, if we have mail_location = maildir:~ .. Another (more specific) problem in this context: Is is it possible to determine a users home calling an external program like checkpassword? This would be needed in an setup, where the users $HOME is set by an checkpassword program to an compute value, to access another users mailbox. This would require doing a userdb lookup from dovecot-auth the same way as deliver or expire-tool does it. I'm not quite sure what you mean by "this" here, are you referring to the proposed `%%h' variable, too or only to my more specific problem with computer HOME paths? I think it's the same thing. Is it? I might be wrong, but i thought for configurations where userdb doesn't depend on the passdb implementing %%h as the home directory of user %%u should be straight forward. Or am I missing something? I guess I just misunderstood what you meant. All I meant was that %%h expansion would always have to be done using a userdb lookup. PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] Initial support for shared mailboxes
Timo Sirainen <[EMAIL PROTECTED]> writes: > On Sep 30, 2008, at 6:08 PM, Sascha Wilde wrote: > Is there a %%h, too? So that, if we have mail_location = maildir:~ >>> .. Another (more specific) problem in this context: Is is it possible to determine a users home calling an external program like checkpassword? This would be needed in an setup, where the users $HOME is set by an checkpassword program to an compute value, to access another users mailbox. >>> >>> This would require doing a userdb lookup from dovecot-auth the same >>> way >>> as deliver or expire-tool does it. >> >> I'm not quite sure what you mean by "this" here, are you referring to >> the proposed `%%h' variable, too or only to my more specific problem >> with computer HOME paths? > > I think it's the same thing. Is it? I might be wrong, but i thought for configurations where userdb doesn't depend on the passdb implementing %%h as the home directory of user %%u should be straight forward. Or am I missing something? [...] >> So I guess what is needed is a new userdb backend which is explicitly >> runs an arbitrary external program to get the user data (instead of >> caching the passdb results). > > Right. Perhaps the passdb checkpassword code could be used as userdb > too, God, so we will try to go this way. > just with an added extra variable specifying if it's a passdb or > a userdb lookup. Or maybe instead of sending "user \0 pass \0" it'd > just send "user". I'm not really sure. In any case I think the reply > should be handled somewhat differently so that the checkpassword can't > accidentally think it's doing a userdb lookup while it's really doing > a passdb lookup and return success. Ack. I or someone else from the Kolab/Dovecot team will write a short proposal on the list as soon as we have one... ;-) cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 Intevation GmbH, Osnabrück http://www.intevation.de/~wilde/ Amtsgericht Osnabrück, HR B 18998 http://www.intevation.de/ Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpsPFjZuUJPr.pgp Description: PGP signature
Re: [Dovecot] Initial support for shared mailboxes
On Sep 30, 2008, at 6:08 PM, Sascha Wilde wrote: Is there a %%h, too? So that, if we have mail_location = maildir:~ .. Another (more specific) problem in this context: Is is it possible to determine a users home calling an external program like checkpassword? This would be needed in an setup, where the users $HOME is set by an checkpassword program to an compute value, to access another users mailbox. This would require doing a userdb lookup from dovecot-auth the same way as deliver or expire-tool does it. I'm not quite sure what you mean by "this" here, are you referring to the proposed `%%h' variable, too or only to my more specific problem with computer HOME paths? I think it's the same thing. So sure it'd be possible, but I'm not really interested in implementing it yet. I think expire-tool is currently using copy&pasted code from deliver, those could be merged into some library function and then the namespace code could easily use the same function. But is deliver currently able to utilize an external program to get user data? deliver will do the userdb lookup from dovecot-auth, which in turn can use the external program. So I guess what is needed is a new userdb backend which is explicitly runs an arbitrary external program to get the user data (instead of caching the passdb results). Right. Perhaps the passdb checkpassword code could be used as userdb too, just with an added extra variable specifying if it's a passdb or a userdb lookup. Or maybe instead of sending "user \0 pass \0" it'd just send "user". I'm not really sure. In any case I think the reply should be handled somewhat differently so that the checkpassword can't accidentally think it's doing a userdb lookup while it's really doing a passdb lookup and return success. PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] Initial support for shared mailboxes
Timo Sirainen <[EMAIL PROTECTED]> writes: > On Tue, 2008-09-30 at 10:46 +0200, Sascha Wilde wrote: >> > namespace shared { >> > separator = / >> > # %%u gets expanded to the remote user. Instead of %%u you can >> > # also use %%n and %%d. >> > prefix = shared/%%u/ >> > location = Maildir:/home/%%u/Maildir:INDEX=~/Maildir/shared/%%u >> > } >> >> Sounds great, and it's an essential feature we need to make Dovecot work >> with Kolab Server. >> >> Is there a %%h, too? So that, if we have >> >> mail_location = maildir:~ > .. >> Another (more specific) problem in this context: Is is it possible to >> determine a users home calling an external program like checkpassword? >> This would be needed in an setup, where the users $HOME is set by an >> checkpassword program to an compute value, to access another users >> mailbox. > > This would require doing a userdb lookup from dovecot-auth the same way > as deliver or expire-tool does it. I'm not quite sure what you mean by "this" here, are you referring to the proposed `%%h' variable, too or only to my more specific problem with computer HOME paths? > So sure it'd be possible, but I'm not > really interested in implementing it yet. I think expire-tool is > currently using copy&pasted code from deliver, those could be merged > into some library function and then the namespace code could easily use > the same function. But is deliver currently able to utilize an external program to get user data? From reading the docs I got the impression that userdb only allows to use data supplied by an arbitrary program by the "Prefetch" backend in combination with an checkpassword passdb, and that deliver can't use this mechanism as the user doesn't login when deliver is run. So I guess what is needed is a new userdb backend which is explicitly runs an arbitrary external program to get the user data (instead of caching the passdb results). What do you think? cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 Intevation GmbH, Osnabrück http://www.intevation.de/~wilde/ Amtsgericht Osnabrück, HR B 18998 http://www.intevation.de/ Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgpGQiBRx4f3e.pgp Description: PGP signature
Re: [Dovecot] Initial support for shared mailboxes
On Tue, 2008-09-30 at 10:46 +0200, Sascha Wilde wrote: > > namespace shared { > > separator = / > > # %%u gets expanded to the remote user. Instead of %%u you can > > # also use %%n and %%d. > > prefix = shared/%%u/ > > location = Maildir:/home/%%u/Maildir:INDEX=~/Maildir/shared/%%u > > } > > Sounds great, and it's an essential feature we need to make Dovecot work > with Kolab Server. > > Is there a %%h, too? So that, if we have > > mail_location = maildir:~ .. > Another (more specific) problem in this context: Is is it possible to > determine a users home calling an external program like checkpassword? > This would be needed in an setup, where the users $HOME is set by an > checkpassword program to an compute value, to access another users > mailbox. This would require doing a userdb lookup from dovecot-auth the same way as deliver or expire-tool does it. So sure it'd be possible, but I'm not really interested in implementing it yet. I think expire-tool is currently using copy&pasted code from deliver, those could be merged into some library function and then the namespace code could easily use the same function. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Initial support for shared mailboxes
Timo Sirainen <[EMAIL PROTECTED]> writes: > Well, I actually started it today since it's needed for replication: > http://hg.dovecot.org/dovecot-1.2/rev/6dd0c6755afe > > Mailboxes can't be listed yet (and I'm not planning on implementing that > anytime soon), but if you add the wanted mailboxes to subscriptions they > should be usable by clients. Configuration goes like: > > namespace shared { > separator = / > # %%u gets expanded to the remote user. Instead of %%u you can > # also use %%n and %%d. > prefix = shared/%%u/ > location = Maildir:/home/%%u/Maildir:INDEX=~/Maildir/shared/%%u > } Sounds great, and it's an essential feature we need to make Dovecot work with Kolab Server. Is there a %%h, too? So that, if we have mail_location = maildir:~ we can say: namespace shared { separator = / prefix = users/%%u/ location = Maildir:%%h:INDEX=~/Maildir/shared/%%u } To make user-mailboxess accessible for other users? If not, how hard would it be to implement? Another (more specific) problem in this context: Is is it possible to determine a users home calling an external program like checkpassword? This would be needed in an setup, where the users $HOME is set by an checkpassword program to an compute value, to access another users mailbox. cheers sascha -- Sascha Wilde OpenPGP key: 4BB86568 Intevation GmbH, Osnabrück http://www.intevation.de/~wilde/ Amtsgericht Osnabrück, HR B 18998 http://www.intevation.de/ Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner pgp0uBfCeeg1U.pgp Description: PGP signature
Re: [Dovecot] Initial support for shared mailboxes
Robert Schetterer schrieb: Timo Sirainen schrieb: On Wed, 2008-09-17 at 01:31 +0200, Robert Schetterer wrote: dovecot: Sep 17 01:26:05 Panic: IMAP([EMAIL PROTECTED]): shared mailbox list: Can't return path for 'users/' Fixed: http://hg.dovecot.org/dovecot-1.2/rev/fd4091d53627 http://hg.dovecot.org/dovecot-1.2/rev/909ed7cd98a5 Hi Timo, i will test this seems to be fixed -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
Re: [Dovecot] Initial support for shared mailboxes
Timo Sirainen schrieb: On Wed, 2008-09-17 at 01:31 +0200, Robert Schetterer wrote: dovecot: Sep 17 01:26:05 Panic: IMAP([EMAIL PROTECTED]): shared mailbox list: Can't return path for 'users/' Fixed: http://hg.dovecot.org/dovecot-1.2/rev/fd4091d53627 http://hg.dovecot.org/dovecot-1.2/rev/909ed7cd98a5 Hi Timo, i will test this -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
Re: [Dovecot] Initial support for shared mailboxes
On Wed, 2008-09-17 at 01:31 +0200, Robert Schetterer wrote: > dovecot: Sep 17 01:26:05 Panic: IMAP([EMAIL PROTECTED]): shared > mailbox list: Can't return path for 'users/' Fixed: http://hg.dovecot.org/dovecot-1.2/rev/fd4091d53627 http://hg.dovecot.org/dovecot-1.2/rev/909ed7cd98a5 signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Initial support for shared mailboxes
Timo Sirainen schrieb: On Sat, 2008-09-06 at 11:11 +0300, Timo Sirainen wrote: On Sat, 2008-09-06 at 10:05 +0200, Robert Schetterer wrote: Timo Sirainen schrieb: On Sat, 2008-09-06 at 09:42 +0200, Robert Schetterer wrote: Hi Timo, what about imap acl full implemented ( not plugin ) is there a chance to have it in v1.2 ? It's not in my plans, but Kolab people are probably going to need it, so maybe they'll implement it. :) And what do you mean by "not plugin"? It's most likely going to be a plugin in any case. Sorry Timo i missposted you *g, the problem is the file based acl ( whatever plugin or not ), i dont know any webmail etc which gives the users themselfs a chance to make their own acls, editing files i.e via ftp is very outdated, what dovecot needs is edit acls direct via the client over imap like its in cyrus, so we can use horde or squirrel webmail The problem isn't really about making IMAP commands available for the ACL file creation, that's pretty easy to implement. The problem is that once the ACLs have been given the mailboxes should be visible to other users. That's more difficult to implement. Well, I actually started it today since it's needed for replication: http://hg.dovecot.org/dovecot-1.2/rev/6dd0c6755afe Mailboxes can't be listed yet (and I'm not planning on implementing that anytime soon), but if you add the wanted mailboxes to subscriptions they should be usable by clients. Configuration goes like: namespace shared { separator = / # %%u gets expanded to the remote user. Instead of %%u you can # also use %%n and %%d. prefix = shared/%%u/ location = Maildir:/home/%%u/Maildir:INDEX=~/Maildir/shared/%%u } I didn't bother testing it with ACL plugin yet, but I guess it should work. And as for the IMAP ACL commands then.. Well, they shouldn't be too difficult to implement I think. Someone else could try to do it though. :) Hi Timo if i use %%u %u works i get failure dovecot: Sep 17 01:26:03 Error: child 15148 (imap) killed with signal 6 dovecot: Sep 17 01:26:05 Panic: IMAP([EMAIL PROTECTED]): shared mailbox list: Can't return path for 'users/' dovecot: Sep 17 01:26:05 Error: IMAP([EMAIL PROTECTED]): Raw backtrace: /usr/lib/dovecot/imap [0x80e9531] -> /usr/lib/dovecot/imap [0x80e95b2] -> /usr/lib/dovecot/imap [0x80e8f49] -> /usr/lib/dovecot/imap [0x809b8e1] -> /usr/lib/dovecot/modules/imap/lib01_acl_plugin.so [0xb7d9a8ae] -> /usr/lib/dovecot/modules/imap/lib01_acl_plugin.so(acl_object_init_from_name+0x1d) [0xb7d98e2d] -> /usr/lib/dovecot/modules/imap/lib01_acl_plugin.so(acl_backend_init+0x176) [0xb7d99556] -> /usr/lib/dovecot/modules/imap/lib01_acl_plugin.so(acl_mailbox_list_created+0xde) [0xb7d9cece] -> /usr/lib/dovecot/modules/imap/lib20_mail_log_plugin.so [0xb7ef50a4] -> /usr/lib/dovecot/imap(mailbox_list_init+0x13c) [0x80b211c] -> /usr/lib/dovecot/imap [0x809bc17] -> /usr/lib/dovecot/imap(mail_storage_create+0x114) [0x80b0c74] -> /usr/lib/dovecot/imap(mail_namespaces_init+0x29e) [0x80ace0e] -> /usr/lib/dovecot/imap(main+0x3e3) [0x806f173] -> /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe0) [0xb7db7450] -> /usr/lib/dovecot/imap [0x805ef21] dovecot: Sep 17 01:26:05 Error: child 15152 (imap) killed with signal 6 -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
Re: [Dovecot] Initial support for shared mailboxes
Timo Sirainen schrieb: On Sat, 2008-09-06 at 11:11 +0300, Timo Sirainen wrote: On Sat, 2008-09-06 at 10:05 +0200, Robert Schetterer wrote: Timo Sirainen schrieb: On Sat, 2008-09-06 at 09:42 +0200, Robert Schetterer wrote: Hi Timo, what about imap acl full implemented ( not plugin ) is there a chance to have it in v1.2 ? It's not in my plans, but Kolab people are probably going to need it, so maybe they'll implement it. :) And what do you mean by "not plugin"? It's most likely going to be a plugin in any case. Sorry Timo i missposted you *g, the problem is the file based acl ( whatever plugin or not ), i dont know any webmail etc which gives the users themselfs a chance to make their own acls, editing files i.e via ftp is very outdated, what dovecot needs is edit acls direct via the client over imap like its in cyrus, so we can use horde or squirrel webmail The problem isn't really about making IMAP commands available for the ACL file creation, that's pretty easy to implement. The problem is that once the ACLs have been given the mailboxes should be visible to other users. That's more difficult to implement. Well, I actually started it today since it's needed for replication: http://hg.dovecot.org/dovecot-1.2/rev/6dd0c6755afe Mailboxes can't be listed yet (and I'm not planning on implementing that anytime soon), but if you add the wanted mailboxes to subscriptions they should be usable by clients. Configuration goes like: namespace shared { separator = / # %%u gets expanded to the remote user. Instead of %%u you can # also use %%n and %%d. prefix = shared/%%u/ location = Maildir:/home/%%u/Maildir:INDEX=~/Maildir/shared/%%u } I didn't bother testing it with ACL plugin yet, but I guess it should work. And as for the IMAP ACL commands then.. Well, they shouldn't be too difficult to implement I think. Someone else could try to do it though. :) Hi Timo, youre great, i will test this soon -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
[Dovecot] Initial support for shared mailboxes
On Sat, 2008-09-06 at 11:11 +0300, Timo Sirainen wrote: > On Sat, 2008-09-06 at 10:05 +0200, Robert Schetterer wrote: > > Timo Sirainen schrieb: > > > On Sat, 2008-09-06 at 09:42 +0200, Robert Schetterer wrote: > > >> Hi Timo, what about imap acl full implemented ( not plugin ) > > >> is there a chance to have it in v1.2 ? > > > > > > It's not in my plans, but Kolab people are probably going to need it, so > > > maybe they'll implement it. :) > > > > > > And what do you mean by "not plugin"? It's most likely going to be a > > > plugin in any case. > > > > > > > Sorry Timo i missposted you *g, > > the problem is the file based acl ( whatever plugin or not ), i dont > > know any > > webmail etc which gives the users themselfs a chance > > to make their own acls, editing files i.e via ftp is > > very outdated, what dovecot needs is edit acls direct via the client > > over imap like its in cyrus, so we can use horde or squirrel webmail > > The problem isn't really about making IMAP commands available for the > ACL file creation, that's pretty easy to implement. The problem is that > once the ACLs have been given the mailboxes should be visible to other > users. That's more difficult to implement. Well, I actually started it today since it's needed for replication: http://hg.dovecot.org/dovecot-1.2/rev/6dd0c6755afe Mailboxes can't be listed yet (and I'm not planning on implementing that anytime soon), but if you add the wanted mailboxes to subscriptions they should be usable by clients. Configuration goes like: namespace shared { separator = / # %%u gets expanded to the remote user. Instead of %%u you can # also use %%n and %%d. prefix = shared/%%u/ location = Maildir:/home/%%u/Maildir:INDEX=~/Maildir/shared/%%u } I didn't bother testing it with ACL plugin yet, but I guess it should work. And as for the IMAP ACL commands then.. Well, they shouldn't be too difficult to implement I think. Someone else could try to do it though. :) signature.asc Description: This is a digitally signed message part