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:
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
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 info dovecot[3804]: auth(default): prefetch([EMAIL PROTECTED],192.168.11.254): success Oct 08 12:42:02 burlywood3 info 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 error 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 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:
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
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 copypasted 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:
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 copypasted 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 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 copypasted 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 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: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
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
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 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
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
[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
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
