Hi,
This is the one thing holding me back from switching to Dovecot...
Can anyone give a realistic timeframe for when Shred maildirs will be officially supported?
Thanks... other than that missing piece, Dovecot rocks!
Charles
On Sat, 2006-01-28 at 13:51 -0500, Charles Marcus wrote:
Hi,
This is the one thing holding me back from switching to Dovecot...
Can anyone give a realistic timeframe for when Shred maildirs will be officially supported?
What do you need from shared folders? Is it enough if administrator sets them up, or would users also need to set them up via ACLs?
Some kind of support for ACLs and shared maildirs will come within a month, but I don't remember right now what exactly I'm supposed to implement :)
On Sun, Jan 29, 2006 at 12:04:02PM +0200, Timo Sirainen wrote:
Can anyone give a realistic timeframe for when Shred maildirs will be officially supported?
What do you need from shared folders? Is it enough if administrator sets them up, or would users also need to set them up via ACLs?
the most important thing regarding shared folders for me would be users having their own seen flags on the mailbox.
grant.
On Sun, 2006-01-29 at 21:31 +1100, grant beattie wrote:
On Sun, Jan 29, 2006 at 12:04:02PM +0200, Timo Sirainen wrote:
Can anyone give a realistic timeframe for when Shred maildirs will be officially supported?
What do you need from shared folders? Is it enough if administrator sets them up, or would users also need to set them up via ACLs?
the most important thing regarding shared folders for me would be users having their own seen flags on the mailbox.
I thought that already worked, but looks like it got lost long time ago when I rewrote maildir syncing code.
There is a pretty simple way to do this, but I'm not sure how good idea it is. If each user has their own separate index files, the flags can simply be stored there. If seen-flag is wanted to be private, then it's stored only in the index file, and the seen-flag in maildir filenames is ignored. All other flags are read/updated as usual.
The one problem with that is that index files aren't 100% reliable. Although it is in my TODO that I should make the code to do less "oh well, we're corrupted, let's rebuild everything" and more trying to fix the problem and preserve all information that it can.
Courier handles shared maildirs by making symlinks to each mail so that the private flags are stored in symlink names and shared flags in the filename where the symlink points to. I don't know if I want to bother adding support for that.
Can anyone give a realistic timeframe for when Shred maildirs will be officially supported?
What do you need from shared folders? Is it enough if administrator sets them up, or would users also need to set them up via ACLs?
the most important thing regarding shared folders for me would be users having their own seen flags on the mailbox.
But... I would also like for these to be configurable, because there is actually one set of Shared folders we have right now that I *don't* want this to happen on - our incoming Fax folder. We have 5 people who have access to this folder, and incoming faxes get routed on a first-seen basis - and once one has gotten routed (shows as 'read' by the person doing the routing), I want it to be seen as read by the others.
I also need support for ACLs, because some people/groups will need full control, and others will need read-only access. Unix perms (one group and one owner) is not enough.
Yes, it will be nice if/when you get around to supporting the ability for Users to Share their own folders, but all I care about is official support (not a 'kludge') via administrator assigning the ACLs.
Thanks!
Charles
Well, aout 2 month ago, I made the same question and this is what I got:Now, correct me if I'm wrong. Although the symlink option would work, wouldn't he have to run Dovecot rootless then? And I believe that is a security risk then, no?
Public folders should be a bit easier than symlinks which seems to be quite a kludge. I have experience with the public folders in MS Exchange, but not in IMAP or anything. It has to be possible without a kludge. But, then again, I'm probably wrong.
TedSki
Peter Fern wrote:
Are you familiar with symlinking/hardlinking under unix? If not, it's fairly straight forward, and yes - they are like file aliases. I suggest you google for it to see how it works, or 'man ln'. You'll need to understand this to make the solution below work.
For your scenario, linking individual files into user's mailboxes probably isn't the best method - better to use the inbuilt shared folder support in dovecot. There are two methods of provisioning shared mailboxes in dovecot - using the namespace configuration directives, or symlinking the folders in. The namespace method will make shared folders available to *all* mail users, so if you want opt-in/-out you'll need to use the symlink method, so for your setup, this would be the easiest method.
A quick outline on how to make this happen:
- Create a central store somewhere containing your folders to be shared. eg: /var/mail/public/.MySQL /var/mail/public/.PostgreSQL etc...
- In each of these folders create a file called 'dovecot-shared' and set file permissions to 0644 and set the group to one that your mail users will be members of - this will determine the permissions of mails within the folder.
- When a user signs up to the folder, create a symlink to the relevant folder under the user's maildir.
Then just drop mails into these maildirs. This is all a little off-the-cuff, so if anyone disagrees yell out.
Cheers, Pete
[SNIP]
Charles Marcus wrote:
Can anyone give a realistic timeframe for when Shred maildirs will be officially supported?
What do you need from shared folders? Is it enough if administrator sets them up, or would users also need to set them up via ACLs?
the most important thing regarding shared folders for me would be users having their own seen flags on the mailbox.
But... I would also like for these to be configurable, because there is actually one set of Shared folders we have right now that I *don't* want this to happen on - our incoming Fax folder. We have 5 people who have access to this folder, and incoming faxes get routed on a first-seen basis - and once one has gotten routed (shows as 'read' by the person doing the routing), I want it to be seen as read by the others.
I also need support for ACLs, because some people/groups will need full control, and others will need read-only access. Unix perms (one group and one owner) is not enough.
Yes, it will be nice if/when you get around to supporting the ability for Users to Share their own folders, but all I care about is official support (not a 'kludge') via administrator assigning the ACLs.
Thanks!
Charles
Well, aout 2 month ago, I made the same question and this is what I got:Now, correct me if I'm wrong. Although the symlink option would work, wouldn't he have to run Dovecot rootless then? And I believe that is a security risk then, no?
Public folders should be a bit easier than symlinks which seems to be quite a kludge. I have experience with the public folders in MS Exchange, but not in IMAP or anything. It has to be possible without a kludge. But, then again, I'm probably wrong.
TedSki
Peter Fern wrote:
Are you familiar with symlinking/hardlinking under unix? If not, it's fairly straight forward, and yes - they are like file aliases. I suggest you google for it to see how it works, or 'man ln'. You'll need to understand this to make the solution below work.
For your scenario, linking individual files into user's mailboxes probably isn't the best method - better to use the inbuilt shared folder support in dovecot. There are two methods of provisioning shared mailboxes in dovecot - using the namespace configuration directives, or symlinking the folders in. The namespace method will make shared folders available to *all* mail users, so if you want opt-in/-out you'll need to use the symlink method, so for your setup, this would be the easiest method.
A quick outline on how to make this happen:
- Create a central store somewhere containing your folders to be shared. eg: /var/mail/public/.MySQL /var/mail/public/.PostgreSQL etc...
- In each of these folders create a file called 'dovecot-shared' and set file permissions to 0644 and set the group to one that your mail users will be members of - this will determine the permissions of mails within the folder.
- When a user signs up to the folder, create a symlink to the relevant folder under the user's maildir.
Then just drop mails into these maildirs. This is all a little off-the-cuff, so if anyone disagrees yell out.
Cheers, Pete
[SNIP]
Now, Im wondering if Dovecot would deal with itCharles Marcus wrote:
Can anyone give a realistic timeframe for when Shred maildirs will be officially supported?
What do you need from shared folders? Is it enough if administrator sets them up, or would users also need to set them up via ACLs?
the most important thing regarding shared folders for me would be users having their own seen flags on the mailbox.
But... I would also like for these to be configurable, because there is actually one set of Shared folders we have right now that I *don't* want this to happen on - our incoming Fax folder. We have 5 people who have access to this folder, and incoming faxes get routed on a first-seen basis - and once one has gotten routed (shows as 'read' by the person doing the routing), I want it to be seen as read by the others.
I also need support for ACLs, because some people/groups will need full control, and others will need read-only access. Unix perms (one group and one owner) is not enough.
Yes, it will be nice if/when you get around to supporting the ability for Users to Share their own folders, but all I care about is official support (not a 'kludge') via administrator assigning the ACLs.
Thanks!
Charles
Few month ago I made this very same question and I heard that would be possible. Now I see people saying that it isn't possible.
Here's my problem:
I have ~10,000 users talking in a private mailing list. I don't want have 10,001 copies of each mail, so, I wanted to make 1 common folder where all of them have the same access.
Solution that I got:"If all you need is to deliver a single mail to many users at once, you might consider hardlinking the message into the mailbox - you may lose a little space (never more than one block) as the filename entry in the filesystem will require nominal space, but it's likely to be quite efficient. Symlinking won't use any additional filespace for each link, but will use inodes... I'm not sure whether dovecot will handle a symlink for an actual mail message though - I would assume not. In any case, this will only work properly if you are using maildirs, but then if you're not, why not? ;)
Alternatively, the 1.0 series of dovecot does support shared folders, and I believe per-user flags are supported, though I'd like someone to confirm? Again, this will only work easily on maildirs due to filesystem permissions and such... " Quoted from Peter Fern
So, what's the deal about it?Few month ago I made this very same question and I heard that would be possible. Now I see people saying that it isn't possible.
Here's my problem:
I have ~10,000 users talking in a private mailing list. I don't want have 10,001 copies of each mail, so, I wanted to make 1 common folder where all of them have the same access.
Solution that I got:"If all you need is to deliver a single mail to many users at once, you might consider hardlinking the message into the mailbox - you may lose a little space (never more than one block) as the filename entry in the filesystem will require nominal space, but it's likely to be quite efficient. Symlinking won't use any additional filespace for each link, but will use inodes... I'm not sure whether dovecot will handle a symlink for an actual mail message though - I would assume not. In any case, this will only work properly if you are using maildirs, but then if you're not, why not? ;)
Alternatively, the 1.0 series of dovecot does support shared folders, and I believe per-user flags are supported, though I'd like someone to confirm? Again, this will only work easily on maildirs due to filesystem permissions and such... " Quoted from Peter Fern
So, what's the deal about it?Reikan - Sidney Ferreira wrote:
I have ~10,000 users talking in a private mailing list. I don't wanthave 10,001 copies of each mail, so, I wanted to make 1 common folder where all of them have the same access.
You're trying to use the wrong tool, IMNSHO. Massively shared discussion like that would be much better served by a Forum (BBS) than a mailing list.
John
-- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4501 Forbes Boulevard Suite H Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5748
On Sun, 2006-01-29 at 08:42 -0500, Charles Marcus wrote:
the most important thing regarding shared folders for me would be users having their own seen flags on the mailbox.
But... I would also like for these to be configurable, because there is actually one set of Shared folders we have right now that I *don't* want this to happen on
Sure.
Yes, it will be nice if/when you get around to supporting the ability for Users to Share their own folders, but all I care about is official support (not a 'kludge') via administrator assigning the ACLs.
OK, that at least comes within a month. I'm not exactly sure yet what would be the best way to configure them though. One possibility would be some global /etc/dovecot-acls.conf and another would be per-mailbox dovecot-acls file. Or perhaps both could be supported.. Suggestions welcome :)
Yes, it will be nice if/when you get around to supporting the ability for Users to Share their own folders, but all I care about is official support (not a 'kludge') via administrator assigning the ACLs.
OK, that at least comes within a month. I'm not exactly sure yet what would be the best way to configure them though. One possibility would be some global /etc/dovecot-acls.conf and another would be per-mailbox dovecot-acls file. Or perhaps both could be supported.. Suggestions welcome :)
Well, although IANAP, I like the idea of both - especially if the global file can 'include' other individual files (group and/or individual mailbox files?) - this would make it easier to manage acls, especially in larger settings.
Whatever is secure, reliable and easiest will work for me, though. I do not have a large user base to worry about, although I do have 5 or 6 virtual domains that I am managing.
I'm glad to hear this is coming soon. I'll definitely be ready and waiting to switch.
Thanks!
Charles
On Sun, 29 Jan 2006, Timo Sirainen wrote:
OK, that at least comes within a month. I'm not exactly sure yet what would be the best way to configure them though. One possibility would be some global /etc/dovecot-acls.conf and another would be per-mailbox dovecot-acls file. Or perhaps both could be supported.. Suggestions welcome :)
Actually, I would prefer having one ACL configuration per folder. There you could also store any other folder-specific settings, say "have flags per user" vs. "share flags among users" or "inherit settings to (newly created?) sub-folders" or "may create sub-folders".
A system-wide configuration is hard to maintain, if it applies to every folder.
Bye,
-- Steffen Kaiser
Yes, it will be nice if/when you get around to supporting the ability for Users to Share their own folders, but all I care about is official support (not a 'kludge') via administrator assigning the ACLs.
OK, that at least comes within a month. I'm not exactly sure yet what would be the best way to configure them though. One possibility would be some global /etc/dovecot-acls.conf and another would be per-mailbox dovecot-acls file. Or perhaps both could be supported.. Suggestions welcome :)
Well, although IANAP, I like the idea of both - especially if the global file can 'include' other individual files (group and/or individual mailbox files?) - this would make it easier to manage acls, especially in larger settings.
Actually, I would prefer having one ACL configuration per folder. There you could also store any other folder-specific settings, say "have flags per user" vs. "share flags among users" or "inherit settings to (newly created?) sub-folders" or "may create sub-folders".
A system-wide configuration is hard to maintain, if it applies to every folder.
Hmmm... well, I don't see anywhere where I suggested that. In fact, I sort of took for granted that ACLs would be configurable on a per folder basis. All I suggested was a way to implement it using a Global .conf file, but with the ability to 'include' other .conf files, to make it easier to maintain in a large environment.
Ok, to get some more detail... what I am interested in is two-fold - seen flags, and ACLs. The following is just a wish-list. I don't know if IMAP ACLs are actually capable of all of the described behavior.
- 'Seen' flags (I know there are more - but these are the only ones I need to be able to configure) - I need to be able to set these as 'Per User', on a per Folder basis. If this option is *not* set on a folder, then the server should maintain the seen state - any user can change it, and all will see the new state.
It wouldn't matter to me which was the default behavior - ie, if I had to set seen='per user', or seen='server'.
'Hide Unreadable' Global flag - if I set it, then users should not even see shared folders that they don't have at least read-only perms. Samba does this really well with shares - any folders inside a share are invisible to users who don't have perms to open them.
ACLs - ability to set user and group ACLs on a per folder (or per group of folders) basis.
Do IMAP ACLs support the ability to set whether a user can add new folders or not (assuming they have read/write perms), and if they are allowed to, whether the ACLs should propogate to (be inherited by) any new sub-folders or not?
Hope this made sense...
--
Best regards,
Charles
On Tue, 2006-01-31 at 12:41 -0500, Charles Marcus wrote:
- 'Seen' flags (I know there are more - but these are the only ones I need to be able to configure) - I need to be able to set these as 'Per User', on a per Folder basis. If this option is *not* set on a folder, then the server should maintain the seen state - any user can change it, and all will see the new state.
It wouldn't matter to me which was the default behavior - ie, if I had to set seen='per user', or seen='server'.
This isn't on my paid-to-do list, but I'll probably add support for this after ACLs work in general. I'll do it by making Dovecot store the per-user-flags into index files only, hope that's good enough..
- 'Hide Unreadable' Global flag - if I set it, then users should not even see shared folders that they don't have at least read-only perms. Samba does this really well with shares - any folders inside a share are invisible to users who don't have perms to open them.
IMAP ACLs have separate "can see" and "can open" flags.
- ACLs - ability to set user and group ACLs on a per folder (or per group of folders) basis.
Yep. Although I'm not exactly sure how groups should be configured for users. If users are in /etc/passwd, using /etc/group is probably a good idea. But for virtual users then should there be also virtual groups, and how are they configured?
Do IMAP ACLs support the ability to set whether a user can add new folders or not (assuming they have read/write perms),
It has a flag to specify if user can create subfolders for a mailbox. Perhaps I could also make it possible to set those flags for a "" mailbox, which would control if user can create anything under root.
and if they are allowed to, whether the ACLs should propogate to (be inherited by) any new sub-folders or not?
There's no inheritation specified by the spec. I'm not sure if I should bother doing that for Dovecot either.. Might get difficult to understand how the configuration works. Or maybe I could support wildcards, so "box/*" would be possible. But those ACLs couldn't then be modified via IMAP ACL extension (or maybe they could be, but they just couldn't be listed).
- 'Seen' flags (I know there are more - but these are the only ones I need to be able to configure) - I need to be able to set these as 'Per User', on a per Folder basis. If this option is *not* set on a folder, then the server should maintain the seen state - any user can change it, and all will see the new state.
It wouldn't matter to me which was the default behavior - ie, if I had to set seen='per user', or seen='server'.
This isn't on my paid-to-do list, but I'll probably add support for this after ACLs work in general. I'll do it by making Dovecot store the per-user-flags into index files only, hope that's good enough..
Sure... as long as it works... :)
So, the initial support will be only for server-side 'blanket' seen/read state - when one person marks it as seen, it will show as seen/read by everyone else?
- 'Hide Unreadable' Global flag - if I set it, then users should not even see shared folders that they don't have at least read-only perms. Samba does this really well with shares - any folders inside a share are invisible to users who don't have perms to open them.
IMAP ACLs have separate "can see" and "can open" flags.
Good - so maybe another questions is, which ACL flags will be supported with the initial implementation, and roughly how long before full support for all IMAP ACLs?
- ACLs - ability to set user and group ACLs on a per folder (or per group of folders) basis.
Yep. Although I'm not exactly sure how groups should be configured for users. If users are in /etc/passwd, using /etc/group is probably a good idea. But for virtual users then should there be also virtual groups, and how are they configured?
Well, ianap, but... shouldn't this simply be left to whatever auth mechanism is implemented? I use virtual groups in my setup, so shouldn't Dovecot just validate them as it does users now?
Do IMAP ACLs support the ability to set whether a user can add new folders or not (assuming they have read/write perms),
It has a flag to specify if user can create subfolders for a mailbox. Perhaps I could also make it possible to set those flags for a "" mailbox, which would control if user can create anything under root.
Sub-folders is enough for me - in fact, I don't want my users to be able to create anything willy-nilly - just in the limited p=layground I give them. So as long as that support will be coming, that will make me happy. :)
and if they are allowed to, whether the ACLs should propogate to (be inherited by) any new sub-folders or not?
There's no inheritation specified by the spec. I'm not sure if I should bother doing that for Dovecot either. Might get difficult to understand how the configuration works. Or maybe I could support wildcards, so "box/*" would be possible. But those ACLs couldn't then be modified via IMAP ACL extension (or maybe they could be, but they just couldn't be listed).
Hmmm... well, according to a draft I found, sub-folders should inherit the ACLs of the parent folder:
www3.ietf.org/proceedings/04aug/I-D/draft-ietf-imapext-acl-10.txt
If this is indeed the cyrrent spec, it is fine with me. I really have no interest in this being 'optional'.
Many thanks, Timo - I am very gratified that you are willing to entertain such questions from an obvious non-programmer type.
--
Best regards,
Charles
participants (6)
-
Charles Marcus
-
grant beattie
-
John Peacock
-
Reikan - Sidney Ferreira
-
Steffen Kaiser
-
Timo Sirainen