[dovecot] shared folders?
Any plans to implement shared folders anytime soon?
greetinx
MW
Timo Sirainen wrote:
On Wed, 2003-04-23 at 20:04, Moe Wibble wrote:
Any plans to implement shared folders anytime soon?
Very likely after 1.0. And 1.0 doesn't seem to be very near yet.
With maildir oes dovecot support multiple logins from the same user? If so, can't you just symlink any maildir dir to .SharedFolder in a users dir?
On Fri, 2003-04-25 at 05:26, Jesse Peterson wrote:
With maildir oes dovecot support multiple logins from the same user?
Yes. With mbox too.
If so, can't you just symlink any maildir dir to .SharedFolder in a users dir?
Well, you could.. If you did it manually, set up permissions correctly and preferrably didn't use shared index files (not so secure). That would also mean that message flags were shared between users.
On Fri, Apr 25, 2003 at 01:19:51PM +0300, Timo Sirainen wrote:
On Fri, 2003-04-25 at 05:26, Jesse Peterson wrote:
With maildir oes dovecot support multiple logins from the same user?
Yes. With mbox too.
If so, can't you just symlink any maildir dir to .SharedFolder in a users dir?
Well, you could.. If you did it manually, set up permissions correctly and preferrably didn't use shared index files (not so secure). That would also mean that message flags were shared between users.
Oh, really now? Last time I tried (some versions ago) this didn't work out.
I can't exactly remember what the problem was, though. Maybe I'll give it one more shot today.
What negative side effects could sharing the index have? Is there a way to safely disable the index only for the shared folders?
thanks
MW
On Fri, 2003-04-25 at 14:37, Moe Wibble wrote:
If so, can't you just symlink any maildir dir to .SharedFolder in a users dir?
Well, you could.. If you did it manually, set up permissions correctly and preferrably didn't use shared index files (not so secure). That would also mean that message flags were shared between users.
Oh, really now? Last time I tried (some versions ago) this didn't work out.
I can't exactly remember what the problem was, though. Maybe I'll give it one more shot today.
Well, I can't now think of why it wouldn't work :) At least as read-write, read-only wouldn't work now.
What negative side effects could sharing the index have?
If user can directly modify it, he could at least make Dovecot display wrong data about the mails, hide mails or possibly cause a buffer overflow.
Is there a way to safely disable the index only for the shared folders?
Easiest would be to specify different index location so it won't follow symlink to the shared directory, eg.:
default_mail_env = maildir:~/Maildir:INDEX=~/Maildir/indexes/
On Fri, Apr 25, 2003 at 04:39:51PM +0300, Timo Sirainen wrote:
On Fri, 2003-04-25 at 14:37, Moe Wibble wrote:
If so, can't you just symlink any maildir dir to .SharedFolder in a users dir?
Well, you could.. If you did it manually, set up permissions correctly and preferrably didn't use shared index files (not so secure). That would also mean that message flags were shared between users.
Oh, really now? Last time I tried (some versions ago) this didn't work out.
I can't exactly remember what the problem was, though. Maybe I'll give it one more shot today.
Well, I can't now think of why it wouldn't work :) At least as read-write, read-only wouldn't work now.
Ah yes, I think that was the point where it failed when I tried. Very unfornationate because ro-access for some users to shared folders where others can write is a must for us.
What negative side effects could sharing the index have?
If user can directly modify it, he could at least make Dovecot display wrong data about the mails, hide mails or possibly cause a buffer overflow.
Okay, doesn't sound so healthy. ;)
Is there a way to safely disable the index only for the shared folders?
Easiest would be to specify different index location so it won't follow symlink to the shared directory, eg.:
default_mail_env = maildir:~/Maildir:INDEX=~/Maildir/indexes/
That is my setup anyways. I remember now; shared folders kind of worked up to the point where I tried to restrict write access for single users through unix (group-)permissions. I think users without write-privileges couldn't even SELECT the folder.
Well, anyways. I'm really looking forward to "completed" sf-support in dovecot. As said, it's the one missing feature that still forces us to stick with cyrus.
I say "completed sf-support" because I figure that what can be done with symlinks now is already half of what we need. The method of having a separate Maildir (that doesn't need to belong to any dovecot user) and symlinking the folders that a user may see into his/her Maildir actually feels much better to me than most other approaches that I have come across. So if we can agree on that being an acceptable way of dealing w/ shared folders then all that's left to add would be: access control.
Since simplicity is my friend I'd vote against ACLs or similar overcomplex bloat for that matter. Instead I imagine an optional ".ro-users"-textfile in every Maildir. That file would simply contain a list of (dovecot) login-names that are to be restricted to r/o-access for that folder. Everybody else who can see the folder (= has it or a symlink to it in his/her Md) and is not listed in ".ro-users" would get r/w-permission.
That would allow to assign three levels of permission (n/a, r/o, r/w) to any user for any shared (or not shared..) folder in an, umm, I'm tempted to say "almost natural" way.
Ofcourse some may say that they need finer granularity of access control. Don't listen to them. ;)
Any opinions? :)
regards
MW
On Fri, 2003-04-25 at 20:06, Moe Wibble wrote:
Well, I can't now think of why it wouldn't work :) At least as read-write, read-only wouldn't work now.
Ah yes, I think that was the point where it failed when I tried. Very unfornationate because ro-access for some users to shared folders where others can write is a must for us.
There's mostly just one problem with this. Mails in new/ couldn't be accessed since they couldn't be moved to cur/ and their UID couldn't be saved into uidlist file.
This is actually somewhat related to quota full situation when there's no space to rewrite uidlist file.. Solution should be the same for both, but I'm not sure yet what it is :)
I'm really looking forward to "completed" sf-support in dovecot.
Courier-like shared maildir folders would probably be best way to do it. It'd use symlinks to message files, so flags can still be changed separately because it's only the user's symlink that gets renamed.
I wrote some kind of plan for shared folder + ACL support a few months ago when there was a possibility of getting paid to do it: (anyone still want to? :)
Change maildir hierarchy separator from '.' to '/', so that usernames could be used in mailboxes names without ugly mangling.
Namespace configuration:
- namespace_[private|user|shared]_prefix
- MAIL environment (or default_mail_env) additions:
- USER_SHARED=.__my_shared_store__
- SHARED=/somewhere for globally shared
- NAMESPACE command
Support for multiple namespaces
- struct mail_storage == one namespace
- fix all IMAP commands handling mailbox names to support other mail_storages based on the mailbox name prefix
mail_storage implementation for shared maildir folders
- SUBSCRIBE shared/timo.sirainen/folder would create .shared/timo.sirainen/folder/ and build indexes there
- UNSUBSCRIBE would delete it
- ..or should SELECT shared/user/folder work before being subscribed? (Later at least yes, but that would need special handling)
- LSUB could simply return all the folders in .shared/ dir
- LIST could use user-defined plugins
- getgroups() plugin
- (Courier compatibility? It used some extra files)
Separate per-mail symlinks to allow per-user mail flags
- mostly just about syncing symlink directory with real directory
ACL API design
- Needs to support stackable implementations, so that eg. filesystem ACL is at the bottom, on top of that an .aclrights file for more fine grained non-OS forced ACLs.
- compatible with ACL2 (currently draft), just a few issues
Filesystem ACL implementation for the ACL API
ACL IMAP commands
Make existing commands play nicely with ACLs and shared folders
- Say "permission denied" rather than "internal error" if some syscall returns EACCES (mostly when opening folders)
- When trying to expunge a message that wasn't ours, ignore or give human readable error message (which one?), but don't give "internal error"
- In general Dovecot doesn't currently like having read-only access to mailboxes
- Ask ACL if operation is permitted before doing that, so it can force the soft checks (.aclaccess file etc)
On Fri, Apr 25, 2003 at 08:21:35PM +0300, Timo Sirainen wrote:
On Fri, 2003-04-25 at 20:06, Moe Wibble wrote:
Well, I can't now think of why it wouldn't work :) At least as read-write, read-only wouldn't work now.
Ah yes, I think that was the point where it failed when I tried. Very unfornationate because ro-access for some users to shared folders where others can write is a must for us.
There's mostly just one problem with this. Mails in new/ couldn't be accessed since they couldn't be moved to cur/ and their UID couldn't be saved into uidlist file.
This is actually somewhat related to quota full situation when there's no space to rewrite uidlist file.. Solution should be the same for both, but I'm not sure yet what it is :)
I'd have some ideas for this but I'm not familar with the dovecot code so they might not be applicable.
I'm really looking forward to "completed" sf-support in dovecot.
Courier-like shared maildir folders would probably be best way to do it. It'd use symlinks to message files, so flags can still be changed separately because it's only the user's symlink that gets renamed.
I wrote some kind of plan for shared folder + ACL support a few months ago when there was a possibility of getting paid to do it: (anyone still want to? :)
Uh oh.
- Change maildir hierarchy separator from '.' to '/', so that usernames could be used in mailboxes names without ugly mangling.
Huh?
- Namespace configuration:
- namespace_[private|user|shared]_prefix
- MAIL environment (or default_mail_env) additions:
- USER_SHARED=.__my_shared_store__
- SHARED=/somewhere for globally shared
- NAMESPACE command
What for?
- Support for multiple namespaces
- struct mail_storage == one namespace
- fix all IMAP commands handling mailbox names to support other mail_storages based on the mailbox name prefix
Ugh.
- mail_storage implementation for shared maildir folders
- SUBSCRIBE shared/timo.sirainen/folder would create .shared/timo.sirainen/folder/ and build indexes there
- UNSUBSCRIBE would delete it
Why!?
- ..or should SELECT shared/user/folder work before being subscribed? (Later at least yes, but that would need special handling)
- LSUB could simply return all the folders in .shared/ dir
- LIST could use user-defined plugins
Why why why!?
- getgroups() plugin- (Courier compatibility? It used some extra files)
Why not treat shared folders like any other folders? Why the heck do you want to be "compatible" to inconveniences of other software? Wouldn't a one-shot-convert-courier-mailstore-to-dovecot-mailstore- utility be more reasonable than bloating the code with compatiblity- workarounds? Who in the world would want to run dovecot and courier in parallel?
- Separate per-mail symlinks to allow per-user mail flags
- mostly just about syncing symlink directory with real directory
Ummm. per-mail symlinks? Okay, there are a number of reasons why people want to get rid of courier imap. I'm convinced that would be one of them! Why not store per-user mailflags for a shared folder (shared folder = a folder that is a symlink not directory) in a separate (single?) meta-file? So dovecot sees: "oh a symlink. well, we'd better read the flags from our meta file then, rather than parse the name".
- ACL API design
- Needs to support stackable implementations, so that eg. filesystem ACL is at the bottom, on top of that an .aclrights file for more fine grained non-OS forced ACLs.
- compatible with ACL2 (currently draft), just a few issues
Okay, you're kidding. You are. Aren't you? You are. (*hides under desk*)
- Filesystem ACL implementation for the ACL API
Argh.
- ACL IMAP commands
Mercy!!
- Make existing commands play nicely with ACLs and shared folders
- Say "permission denied" rather than "internal error" if some syscall returns EACCES (mostly when opening folders)
Hm. Ah, that's what we get out of all the effort?
- When trying to expunge a message that wasn't ours, ignore or give human readable error message (which one?), but don't give "internal error"
Umm. Does anyone really care about that?
- In general Dovecot doesn't currently like having read-only access to mailboxes
I noticed that.
- Ask ACL if operation is permitted before doing that, so it can force the soft checks (.aclaccess file etc)
Okay, you got me really scared by now.
I mean... I don't even know where to start... Maybe: What kind of expired fish did you have for breakfast? (j/k;))
The positive point was that you said you're not going to actually do it. Can you promise that, please? ;)
Would you probably take a simpler approach like the one I briefly outlined in my previous mail into consideration or do you really think of ACLs as a must-have? If so, why?
PS: no personal offense intended!
greetinx
MW
On Fri, 2003-04-25 at 21:48, Moe Wibble wrote:
- Change maildir hierarchy separator from '.' to '/', so that usernames could be used in mailboxes names without ugly mangling. Huh?
So that if you have a login name of "first.last@domain.com", LIST could show that directly under "Other users/" namespace.
- Namespace configuration:
- namespace_[private|user|shared]_prefix
- MAIL environment (or default_mail_env) additions:
- USER_SHARED=.__my_shared_store__
- SHARED=/somewhere for globally shared
- NAMESPACE command
What for?
I'll do this in any case. Namespaces are good for clients and people want multiple locations for their mailboxes (mixed mboxes and maildir most commonly).
- Support for multiple namespaces
- struct mail_storage == one namespace
- fix all IMAP commands handling mailbox names to support other mail_storages based on the mailbox name prefix
Ugh.
Same as above.
- mail_storage implementation for shared maildir folders
- SUBSCRIBE shared/timo.sirainen/folder would create .shared/timo.sirainen/folder/ and build indexes there
- UNSUBSCRIBE would delete it
Why!?
Point was to be able to share your folders with other users. How else would you do that with IMAP protocol?
- ..or should SELECT shared/user/folder work before being subscribed? (Later at least yes, but that would need special handling)
- LSUB could simply return all the folders in .shared/ dir
- LIST could use user-defined plugins
Why why why!?
How would you list the possible folders that other people have shared?
- (Courier compatibility? It used some extra files)
Why not treat shared folders like any other folders?
Because they're not like other folders. Unless you want to manually create the symlink and delete it when you don't want that folder anymore.
Why the heck do you want to be "compatible" to inconveniences of other software?
That was in paranthesis :) And it's not a big deal, maybe creating a 0-byte file.
Wouldn't a one-shot-convert-courier-mailstore-to-dovecot-mailstore- utility be more reasonable than bloating the code with compatiblity- workarounds? Who in the world would want to run dovecot and courier in parallel?
There may be other programs that access Maildir++ than Courier. Maybe not shared folders, but for quota there's several others.
- Separate per-mail symlinks to allow per-user mail flags
- mostly just about syncing symlink directory with real directory
Ummm. per-mail symlinks? Okay, there are a number of reasons why people want to get rid of courier imap. I'm convinced that would be one of them! Why not store per-user mailflags for a shared folder (shared folder = a folder that is a symlink not directory) in a separate (single?) meta-file? So dovecot sees: "oh a symlink. well, we'd better read the flags from our meta file then, rather than parse the name".
I think the symlinking is quite simple way to do this and plays very nicely with how maildir works internally. If I do some separate meta-file for flags (I've thought about that too) it wouldn't be maildir anymore. I might just as well implement another mail storage format then.
- ACL API design
- Needs to support stackable implementations, so that eg. filesystem ACL is at the bottom, on top of that an .aclrights file for more fine grained non-OS forced ACLs.
- compatible with ACL2 (currently draft), just a few issues
Okay, you're kidding. You are. Aren't you? You are. (*hides under desk*)
- Filesystem ACL implementation for the ACL API
Argh.
- ACL IMAP commands
Mercy!!
So, you don't want IMAP ACL support at all? I do, but I'll of course leave it optional.
- Make existing commands play nicely with ACLs and shared folders
- Say "permission denied" rather than "internal error" if some syscall returns EACCES (mostly when opening folders)
Hm. Ah, that's what we get out of all the effort?
It's not nice to let users fill your error log files.
- When trying to expunge a message that wasn't ours, ignore or give human readable error message (which one?), but don't give "internal error"
Umm. Does anyone really care about that?
Depends on how you want the shared folder to behave. Yes, the guy who I wrote this mail first wanted such behaviour.
Would you probably take a simpler approach like the one I briefly outlined in my previous mail into consideration or do you really think of ACLs as a must-have? If so, why?
If you can't give shell access to IMAP users, that's the only way to let them share their folders.
On Fri, Apr 25, 2003 at 10:52:45PM +0300, Timo Sirainen wrote:
On Fri, 2003-04-25 at 21:48, Moe Wibble wrote:
- Change maildir hierarchy separator from '.' to '/', so that usernames could be used in mailboxes names without ugly mangling. Huh?
So that if you have a login name of "first.last@domain.com", LIST could show that directly under "Other users/" namespace.
Okay, I get it. (i think)
- Namespace configuration:
- namespace_[private|user|shared]_prefix
- MAIL environment (or default_mail_env) additions:
- USER_SHARED=.__my_shared_store__
- SHARED=/somewhere for globally shared
- NAMESPACE command
What for?
I'll do this in any case. Namespaces are good for clients and people want multiple locations for their mailboxes (mixed mboxes and maildir most commonly).
I must admit that I have never really understood (and only very briefly browsed over) the idea of imap namespaces. With the little bit I know I'm basically considering them mainly as a convenience for a person willing to implement an imap server because they make it easier to have the imapd emulate "virtual" folders to the client.
But why not just let the user arrange his folder hierarchy the way he likes when what we are dealing with actually is a folder anyways? I don't see the connection to shared folders. And I don't see a reason why shared folders should be separated in a different namespace?
Your maildir/mbox example makes a bit sense to me even though I don't see the big advantage there either.
But then again, maybe I'm just missing the whole point about namespaces..?
- mail_storage implementation for shared maildir folders
- SUBSCRIBE shared/timo.sirainen/folder would create .shared/timo.sirainen/folder/ and build indexes there
- UNSUBSCRIBE would delete it
Why!?
Point was to be able to share your folders with other users. How else would you do that with IMAP protocol?
Well, I wouldn't do it with the IMAP protocol but with symlinks. ;)
- ..or should SELECT shared/user/folder work before being subscribed? (Later at least yes, but that would need special handling)
- LSUB could simply return all the folders in .shared/ dir
- LIST could use user-defined plugins
Why why why!?
How would you list the possible folders that other people have shared?
Not at all, I symlink shared folders to the Maildirs of the users that should see them.
- (Courier compatibility? It used some extra files)
Why not treat shared folders like any other folders?
Because they're not like other folders. Unless you want to manually create the symlink and delete it when you don't want that folder anymore.
Yes, that's what I had in mind. :)
Why the heck do you want to be "compatible" to inconveniences of other software?
That was in paranthesis :) And it's not a big deal, maybe creating a 0-byte file.
Hum.
Wouldn't a one-shot-convert-courier-mailstore-to-dovecot-mailstore- utility be more reasonable than bloating the code with compatiblity- workarounds? Who in the world would want to run dovecot and courier in parallel?
There may be other programs that access Maildir++ than Courier. Maybe not shared folders, but for quota there's several others.
Hum².
- Separate per-mail symlinks to allow per-user mail flags
- mostly just about syncing symlink directory with real directory
Ummm. per-mail symlinks? Okay, there are a number of reasons why people want to get rid of courier imap. I'm convinced that would be one of them! Why not store per-user mailflags for a shared folder (shared folder = a folder that is a symlink not directory) in a separate (single?) meta-file? So dovecot sees: "oh a symlink. well, we'd better read the flags from our meta file then, rather than parse the name".
I think the symlinking is quite simple way to do this and plays very nicely with how maildir works internally. If I do some separate meta-file for flags (I've thought about that too) it wouldn't be maildir anymore. I might just as well implement another mail storage format then.
The major problem I see is the extensive use of inodes. Also keeping the symlink-copies in sync with the main folder seems like an expensive task to me. And you already have meta files (the index), why not add one?
[ ACL stuff ] [ Moe doesn't like ACL ]
So, you don't want IMAP ACL support at all? I do, but I'll of course leave it optional.
I'd really prefer a simpler approach, at least for a start. The "simple" shared folders should be fairly easy to implement. At least compared to full blown ACL support. Also they wouldn't bloat the code nearly as much as the latter and could easily co-exist with upcoming ACL support while it's under developement.
How good is client support for ACLs nowadays anyways?
- Make existing commands play nicely with ACLs and shared folders
- Say "permission denied" rather than "internal error" if some syscall returns EACCES (mostly when opening folders)
Hm. Ah, that's what we get out of all the effort?
It's not nice to let users fill your error log files.
Yes, you're right ofcourse. But it shouldn't be too hard to issue proper error messages even without ACLs. ;)
- When trying to expunge a message that wasn't ours, ignore or give human readable error message (which one?), but don't give "internal error"
Umm. Does anyone really care about that?
Depends on how you want the shared folder to behave. Yes, the guy who I wrote this mail first wanted such behaviour.
Well, that's where we have a different view on shared folders. :) "My" shared folders can be read-only or read-write. Trying to delete a message from a read-only shared folder would cause a "Permission denied."-message. I didn't quite understand in first place why that is worth mentioning?
Would you probably take a simpler approach like the one I briefly outlined in my previous mail into consideration or do you really think of ACLs as a must-have? If so, why?
If you can't give shell access to IMAP users, that's the only way to let them share their folders.
Ah, there we go. :) I don't need users to be able to share/unshare their folders with their mail client and all the other extras ACL makes possible. Thus my call for "simple" shared folders. You on the other hand have the real deal in mind, with ACLs, bells and whistles. Well, whatever it will be, shared folders would definately be a nice thing to have. ;)
greetinx
MW
On Sat, 26 Apr 2003, Moe Wibble wrote:
I must admit that I have never really understood (and only very briefly browsed over) the idea of imap namespaces. With the little bit I know I'm basically considering them mainly as a convenience for a person willing to implement an imap server because they make it easier to have the imapd emulate "virtual" folders to the client. But why not just let the user arrange his folder hierarchy the way he likes when what we are dealing with actually is a folder anyways? I don't see the connection to shared folders. And I don't see a reason why shared folders should be separated in a different namespace?
The reason for this comes naturally from one of the main applications of shared folders, which is companies that share announcement and news folders across their employees. One shared folder may be called "finance", another may be "news".
Now, I personally have a mailbox called "news" which is a superior to "CNN.com", "Freshmeat.net" and so on. So I can't subscribe to the shared folder "news" unless it's in a different namespace. The namespace name usually starts with a character that is disallowed in regular mailboxes.
So perhaps the company's namespace is "#thecompany". Now you can subscribe to two mailboxes whose names are both "news", one is just "news" or within some personal namespace "#personal/news", and one is "#thecompany/news".
Andy
-- Andreas Aardal Hanssen http://www.andreas.hanssen.name/gpg
On Sat, Apr 26, 2003 at 12:09:33PM +0200, Andreas Aardal Hanssen wrote:
On Sat, 26 Apr 2003, Moe Wibble wrote:
I must admit that I have never really understood (and only very briefly browsed over) the idea of imap namespaces. With the little bit I know I'm basically considering them mainly as a convenience for a person willing to implement an imap server because they make it easier to have the imapd emulate "virtual" folders to the client. But why not just let the user arrange his folder hierarchy the way he likes when what we are dealing with actually is a folder anyways? I don't see the connection to shared folders. And I don't see a reason why shared folders should be separated in a different namespace?
The reason for this comes naturally from one of the main applications of shared folders, which is companies that share announcement and news folders across their employees. One shared folder may be called "finance", another may be "news".
Now, I personally have a mailbox called "news" which is a superior to "CNN.com", "Freshmeat.net" and so on. So I can't subscribe to the shared folder "news" unless it's in a different namespace. The namespace name usually starts with a character that is disallowed in regular mailboxes.
So perhaps the company's namespace is "#thecompany". Now you can subscribe to two mailboxes whose names are both "news", one is just "news" or within some personal namespace "#personal/news", and one is "#thecompany/news".
So namespaces help to enforce corporate policies on folder names? ;) No seriously, if you'd work with symlinks it'd be up to the user how to name his folder and where to put it. Aren't namespaces represented as folders in most clients anyways? So what's the point about enforcing a folders name (or even worse part of the structure of the folder tree) on the client side?
As said, it might be more convinient for the imapd because it only has to prepend "#news" to the folder name instead of internally maintaining a "virtual" folder that can be renamed and everything. I'm not sure but I think at least mozilla displays namespaces as toplevel folders. And I guess moving folders between namespaces is not so easy, unless the client remembers some kind of mapping. So what if a user prefers to have "CNN.com" under #personal/news_n_stuff/web rather than #news?
I still don't see why shared folders need to exist in a dedicated namespace...
regards
MW
On Sat, 26 Apr 2003, Moe Wibble wrote:
On Sat, Apr 26, 2003 at 12:09:33PM +0200, Andreas Aardal Hanssen wrote:
On Sat, 26 Apr 2003, Moe Wibble wrote: Now, I personally have a mailbox called "news" which is a superior to "CNN.com", "Freshmeat.net" and so on. So I can't subscribe to the shared folder "news" unless it's in a different namespace. The namespace name usually starts with a character that is disallowed in regular mailboxes.
So perhaps the company's namespace is "#thecompany". Now you can subscribe to two mailboxes whose names are both "news", one is just "news" or within some personal namespace "#personal/news", and one is "#thecompany/news". So namespaces help to enforce corporate policies on folder names? ;) No seriously, if you'd work with symlinks it'd be up to the user how to name his folder and where to put it.
Now you're talking about a specific implementation. The shared folders concept needs to fit into the IMAP protocol, and it therefore needs to be completely platform independent. Sure, one solution is to use symlinks and that one feature allows a user to have a "local" name that can be different from the remote name. But in most cases, it makes little sense to mount a shared folder under another name.
Aren't namespaces represented as folders in most clients anyways? So what's the point about enforcing a folders name (or even worse part of the structure of the folder tree) on the client side?
The client is not an issue here. The client can assign that folder any name that it wants. The question is what the server should do, and the server represents shared folders' names exactly the way the source presents them. The client needs to access the folder using the server's folder name. To avoid name clashes, you need namespaces. That's what the entire purpose of a namespace is for.
As said, it might be more convinient for the imapd because it only has to prepend "#news" to the folder name instead of internally maintaining a "virtual" folder that can be renamed and everything.
If there is a source that presents a structure of shared mailboxes, and several of the names clash with your own mailboxes names, you can not easily mount / subscribe / access those mailboxes without namespaces.
I can see no reason whatsoever to _not_ use a seperate namespace for shared folders.
Andy
-- Andreas Aardal Hanssen http://www.andreas.hanssen.name/gpg
On Sat, 2003-04-26 at 06:52, Moe Wibble wrote:
I must admit that I have never really understood (and only very briefly browsed over) the idea of imap namespaces. With the little bit I know I'm basically considering them mainly as a convenience for a person willing to implement an imap server because they make it easier to have the imapd emulate "virtual" folders to the client.
Namespaces also tell client if a folder is user's own, other user's or public (eg. news). Client might want to do things differently depending on the type.
Your maildir/mbox example makes a bit sense to me even though I don't see the big advantage there either.
But then again, maybe I'm just missing the whole point about namespaces..?
Like Andreas said, the whole point is that you don't get naming collisions between folders.
You can of course always just create symlinks manually, but I'd like to support some more user friendly ways.
I think the symlinking is quite simple way to do this and plays very nicely with how maildir works internally. If I do some separate meta-file for flags (I've thought about that too) it wouldn't be maildir anymore. I might just as well implement another mail storage format then.
The major problem I see is the extensive use of inodes.
Why use maildir at all then? :) XFS at least doesn't have inode limits, I'd guess other file systems nowadays would neither.
Also keeping the symlink-copies in sync with the main folder seems like an expensive task to me.
Hmm. Well, it would require that symlink is updated when flags are updated in original folder.
And you already have meta files (the index), why not add one?
Such flag file would preferrably have to be NFS safe. That makes it a bit more difficult.
So, you don't want IMAP ACL support at all? I do, but I'll of course leave it optional.
I'd really prefer a simpler approach, at least for a start.
Sure. I'm not going to add shared folder or ACL support anytime soon. It's still scheduled post-1.0
The "simple" shared folders should be fairly easy to implement.
You have read-write already :)
How good is client support for ACLs nowadays anyways?
Probably not very good. Bynari's InsightConnector is one which could be useful. Makes it possible to replace MS Excenge with IMAP server for Outlook.
- Make existing commands play nicely with ACLs and shared folders
- Say "permission denied" rather than "internal error" if some syscall returns EACCES (mostly when opening folders)
Hm. Ah, that's what we get out of all the effort?
It's not nice to let users fill your error log files.
Yes, you're right ofcourse. But it shouldn't be too hard to issue proper error messages even without ACLs. ;)
Sure. That was just a related TODO item.
- When trying to expunge a message that wasn't ours, ignore or give human readable error message (which one?), but don't give "internal error"
Umm. Does anyone really care about that?
Depends on how you want the shared folder to behave. Yes, the guy who I wrote this mail first wanted such behaviour.
Well, that's where we have a different view on shared folders. :) "My" shared folders can be read-only or read-write. Trying to delete a message from a read-only shared folder would cause a "Permission denied."-message. I didn't quite understand in first place why that is worth mentioning?
That meant a folder where each message was owned by a user, and only he could delete the message. ie. unlink() fails for a file in sticky maildir directory because we're not the owner.
On Sun, Apr 27, 2003 at 05:00:24AM +0300, Timo Sirainen wrote:
On Sat, 2003-04-26 at 06:52, Moe Wibble wrote:
I must admit that I have never really understood (and only very briefly browsed over) the idea of imap namespaces. With the little bit I know I'm basically considering them mainly as a convenience for a person willing to implement an imap server because they make it easier to have the imapd emulate "virtual" folders to the client.
Namespaces also tell client if a folder is user's own, other user's or public (eg. news). Client might want to do things differently depending on the type.
Ah okay, that's the part I missed when reading about them. So "inbox", "public" and "shared" are not randomly chosen but actually tell the client (by definition) something about the nature of the folder? Okay, if clients deal properly with that then I'm fine. :)
Your maildir/mbox example makes a bit sense to me even though I don't see the big advantage there either.
But then again, maybe I'm just missing the whole point about namespaces..?
Like Andreas said, the whole point is that you don't get naming collisions between folders.
Yes, and I thought about solving them by having one of them renamed. But it doesn't matter anyways. My only concern was about how current MUAs handle (visualize) namespaces. If they don't tend to introduce any inconveniences for the user then my previous arguments are void. :)
You can of course always just create symlinks manually, but I'd like to support some more user friendly ways.
I like symlinks but I'm not religious about them! ;)
I think the symlinking is quite simple way to do this and plays very nicely with how maildir works internally. If I do some separate meta-file for flags (I've thought about that too) it wouldn't be maildir anymore. I might just as well implement another mail storage format then.
The major problem I see is the extensive use of inodes.
Why use maildir at all then? :) XFS at least doesn't have inode limits, I'd guess other file systems nowadays would neither.
Well, AFAIK most other filesystems do have inode limits. Adding a variable multiplier to the amount of inodes used doesn't seem very elegant to me.
Also keeping the symlink-copies in sync with the main folder seems like an expensive task to me.
Hmm. Well, it would require that symlink is updated when flags are updated in original folder.
So dovecot better be the only one making changes to the the original folder?
And you already have meta files (the index), why not add one?
Such flag file would preferrably have to be NFS safe. That makes it a bit more difficult.
I keep reading "NFS safe". To me that's an oxymoron...
So, you don't want IMAP ACL support at all? I do, but I'll of course leave it optional.
I'd really prefer a simpler approach, at least for a start.
Sure. I'm not going to add shared folder or ACL support anytime soon. It's still scheduled post-1.0
Well, looking forward to it. I'm a bit worried that dovecot won't be "slim" at all anymore by then, though.
The "simple" shared folders should be fairly easy to implement.
You have read-write already :)
Yes and adding not more but a per-user r/o-option to that would be perfectly sufficient for most of _my_ applications. I ofcourse can't speak for other users...
How good is client support for ACLs nowadays anyways?
Probably not very good. Bynari's InsightConnector is one which could be useful. Makes it possible to replace MS Excenge with IMAP server for Outlook.
I'll pretend I've not have read that last sentence...
On Sun, 2003-04-27 at 17:55, Moe Wibble wrote:
Namespaces also tell client if a folder is user's own, other user's or public (eg. news). Client might want to do things differently depending on the type.
Ah okay, that's the part I missed when reading about them. So "inbox", "public" and "shared" are not randomly chosen but actually tell the client (by definition) something about the nature of the folder?
The actual names don't matter, but just how they're liststed in NAMESPACE reply. For example:
- NAMESPACE (("INBOX." ".")("#mbox/" "/")) (("Other users/", "/")) (("#news." ".")("Mailing lists/" "/"))
Also keeping the symlink-copies in sync with the main folder seems like an expensive task to me.
Hmm. Well, it would require that symlink is updated when flags are updated in original folder.
So dovecot better be the only one making changes to the the original folder?
No, it doesn't matter who does the change in the original folder. Dovecot will just have to notice that symlink destination doesn't exist and fix it.
Sure. I'm not going to add shared folder or ACL support anytime soon. It's still scheduled post-1.0
Well, looking forward to it. I'm a bit worried that dovecot won't be "slim" at all anymore by then, though.
I try to keep it unbloated :) Preferrably all IMAP extensions should be possible to leave out at compile time, but some just are a bit too invasive to be left out without tons of #ifdefs.
participants (5)
-
Andreas Aardal Hanssen
-
Andreas Aardal Hanssen
-
Jesse Peterson
-
Moe Wibble
-
Timo Sirainen