Re: POLL: per-domain shared folder/sieve/etc
On 2014-11-01 21:29, Bron Gondwana wrote: > We already have one at FastMail to stop users setting an 'anyone' ACL. > I think this may already be in upstream, unless you're talking about a different implementation/solution? http://git.cyrusimap.org/cyrus-imapd/tree/lib/imapoptions#n179 >> > This is all, obviously, Cyrus 3.0 stuff. >> > >> >> In the multi-domain environments we typically run, while sharing >> between >> domains is indeed an often requested feature, we love the inability to >> share cross-realm -- preventing accidentally sharing your @company.com >> content with @competitor.com people. > > Yes, that's pretty dangerous, isn't it. > >> If the new way of doing things is to allow cross-realm sharing, I >> would >> like to ensure some sort mandatory access policy is in place, where >> one >> has to specify @something can in fact share with @else. > > This is tricky, particularly for FastMail where multiple companies can > have addresses in the shared domains (e.g. fastmail.com) as well. > > It sounds like the right general approach is to allow an external > daemon to be queried for policy responses. > I suppose the level of complexity depends on the level of flexibility / features required. Suppose that the default is to not have any realm be allowed to use any other realm (no other realm's mailboxes are visible, no ACL subject identifiers validate). This, I would say, represents the current situation most accurately. Suppose a list of source realms (the authenticated user is in this realm) is used as a lookup key, and for any other realm that realm must have presence in the lookup value) -- admittedly a very simplistic view: company.com: subsidiary.com partner.com subsidiary.com: company.com partner.com: company.com competitor.com competitor.com: partner.com Suppose this means that @company.com people (source, lookup key) can share @company.com mailboxes (source, lookup key, must match logged in account?) with @subsidiary.com and with @partner.com ACL subject identifiers. Suppose this means @partner.com (target lookup value) can therefore see @company.com mailboxes -- but cannot share with @company.com because of the first rule, but because of the third rule. I do not suppose there is any use-case to nesting such rules to the tune to, in the above list, allow subsidiary to partner descending to company authorizations (or any other way). I suppose in the case of FastMail, you would list fastmail.com as a lookup key and perhaps use a regular expression .* to ensure @fastmail.com mailboxes are visible to all other realms? > Of course, to a certain degree this is trying to make a technical > solution to a human problem. If it's that vital that they can't see > each other, they should be on separate Cyrus instances at the very > least, if not entirely separate infrastructure. There's nothing to > stop mall...@example.org just adding a sieve rule to forward a copy of > everything to j...@company.com, or handing over credentials, or any > number of things. > I agree with the general sentiment, but disagree with such separation on the infrastructure level being that kind of a must (for that level of vital). There are other considerations that could require an organization to have infrastructure isolated from a multi-customer "hosted" environment, but such are in the gut-feeling-more-so-than-technical-literacy, compliance and telco regulatory domains. While "to share or not" is certainly a social problem, and "to enable sharing or not" probably is so too, "to allow sharing or not" is definitely a more technical one if the implementation thereof leaves behind a Free-for-All. For Sieve rules forwarding content, cross-realm ACLs are rather irrelevant. One could (define to) forward content using Sieve regardless, unless Cyrus IMAP's Sieve implementation is extended to allow a similar level of access control. The current methodology to prevent this from happening lays in limiting the user interfaces, not including Sieve extensions, MTA configuration and Data-Loss Prevention systems -- neither of which are helped or negated by introducing cross-realm ACLs, and neither of which requires a given customer to run off of completely separate infrastructure. Should sharing across domains be allowed, but without mandatory access control, however, then you move Cyrus IMAP from the "perfect for hosted environments with multiple customers" universe to the "it's such a Free-for-All you require separate infrastructure for each customer". >> On 2014-10-24 02:59, Bron Gondwana wrote: >> > No, the per-user namespace is still fine - users can still share with >> > other users in their own domain - just currently it is technically >> > impossible to share with users in other domains right now - because the >> > mailbox naming is not RFC compliant, so it's not compatible with real >> > IMAP client, only with Cyrus management tools. >> > >> >> You mentioned in a
Re: POLL: per-domain shared folder/sieve/etc
On Thu, Oct 30, 2014, at 01:45 AM, Jeroen van Meeuwen (Kolab Systems) wrote: > On 2014-10-22 23:02, Bron Gondwana wrote: > > Yes, that means a massive change, instead of internally: > > > > example.com!user.foo.bar <=> user/foo/b...@example.com (which is a > > million ways of bogus) we would have: > > > > user.foo@example^com.bar <=> user/f...@example.com/bar > > > > Or in alt namspace: > > > > Other Users/f...@example.com/bar > > > > This means we will finally be able to share things across domains. It > > creates a single consistent way to access everything. > > > > The "domain" used to be used as an "authorization realm", where a user > j...@example.com would only see "Other Users/foo/bar" -- without the > domain. > > How would this translate to the new way? So I think we can do it fine. We can have a "don't display domain if they are the same" option. > If the external name (the new default) uses unix hierarchy separators, > would it be reasonable to update the internal format to that as well, > and translate "user/foo/b...@example.org" or "user/f...@example.org/bar" > back to using the netnews hierarchy separator if so configured? So that would be ugly: user.foo@example^org.bar - but we can still suppress users in other domains from being visible pretty easily, and likewise disallow cross domain ACLs. That would be an easy config option. We already have one at FastMail to stop users setting an 'anyone' ACL. > > > > > > The problem is, it means you can't set quotas per domain, you can't > > have sieve scripts per domain, and most of all - you can't have shared > > folders in a domain. > > > > example.com!shared.stuff worked fine, but > > > > shared.example^com.stuff would be weird. It's just a folder, and > > wouldn't be treated specially in any way. The domain would have no > > special meaning. > > > > This is now shared/st...@example.org, I suppose a hierarchy of such > folders would lead to shared/st...@example.org/something? Yes, that's right. > > This is all, obviously, Cyrus 3.0 stuff. > > > > In the multi-domain environments we typically run, while sharing between > domains is indeed an often requested feature, we love the inability to > share cross-realm -- preventing accidentally sharing your @company.com > content with @competitor.com people. Yes, that's pretty dangerous, isn't it. > If the new way of doing things is to allow cross-realm sharing, I would > like to ensure some sort mandatory access policy is in place, where one > has to specify @something can in fact share with @else. This is tricky, particularly for FastMail where multiple companies can have addresses in the shared domains (e.g. fastmail.com) as well. It sounds like the right general approach is to allow an external daemon to be queried for policy responses. Of course, to a certain degree this is trying to make a technical solution to a human problem. If it's that vital that they can't see each other, they should be on separate Cyrus instances at the very least, if not entirely separate infrastructure. There's nothing to stop mall...@example.org just adding a sieve rule to forward a copy of everything to j...@company.com, or handing over credentials, or any number of things. We block the 'anyone' ACL just because some clients make it too easy to turn on, and it's too confusing to the people who suddenly see a random unexpected folder. We don't block people deliberately sharing, because that's a people problem. > On 2014-10-24 02:59, Bron Gondwana wrote: > > No, the per-user namespace is still fine - users can still share with > > other users in their own domain - just currently it is technically > > impossible to share with users in other domains right now - because the > > mailbox naming is not RFC compliant, so it's not compatible with real > > IMAP client, only with Cyrus management tools. > > > > You mentioned in another post (quote above) that the current naming of > mailboxes is not necessarily RFC-compliant, and that only the Cyrus > tooling is compatible. > > I may be misunderstanding what this means, because only an administrator > without a realm (as part of its login username) is currently able to > view lists of mailboxes across realms -- bear with me while I transcribe > from the top of my head: Yes, but the administrator can't use RFC compliant tooling to do it, because the LIST response is bogus. > Settings: > > virtdomains: userid > > admins: cyrus-admin ad...@example.org > > cyrus-admin: > > C: . LIST "" "*" > > S: * user/j...@company.com > > S: * user/j...@example.org > > S: * user/m...@example.org it's this: S: * user/jane/b...@example.org > ad...@example.org: > > C: . LIST "" "*" > > S: * user/jane > > S: * user/max > > j...@example.org: > > C: . LIST "" "*" > > S: * INBOX > > S: * Other Users/max And all this is fine so long as you only have one domain that you care about. So I am considering an option, stripsamedomai
Re: POLL: per-domain shared folder/sieve/etc
On 2014-10-22 23:02, Bron Gondwana wrote: > Yes, that means a massive change, instead of internally: > > example.com!user.foo.bar <=> user/foo/b...@example.com (which is a > million ways of bogus) we would have: > > user.foo@example^com.bar <=> user/f...@example.com/bar > > Or in alt namspace: > > Other Users/f...@example.com/bar > > This means we will finally be able to share things across domains. It > creates a single consistent way to access everything. > The "domain" used to be used as an "authorization realm", where a user j...@example.com would only see "Other Users/foo/bar" -- without the domain. How would this translate to the new way? If the external name (the new default) uses unix hierarchy separators, would it be reasonable to update the internal format to that as well, and translate "user/foo/b...@example.org" or "user/f...@example.org/bar" back to using the netnews hierarchy separator if so configured? > > > The problem is, it means you can't set quotas per domain, you can't > have sieve scripts per domain, and most of all - you can't have shared > folders in a domain. > > example.com!shared.stuff worked fine, but > > shared.example^com.stuff would be weird. It's just a folder, and > wouldn't be treated specially in any way. The domain would have no > special meaning. > This is now shared/st...@example.org, I suppose a hierarchy of such folders would lead to shared/st...@example.org/something? > This is all, obviously, Cyrus 3.0 stuff. > In the multi-domain environments we typically run, while sharing between domains is indeed an often requested feature, we love the inability to share cross-realm -- preventing accidentally sharing your @company.com content with @competitor.com people. If the new way of doing things is to allow cross-realm sharing, I would like to ensure some sort mandatory access policy is in place, where one has to specify @something can in fact share with @else. On 2014-10-24 02:59, Bron Gondwana wrote: > No, the per-user namespace is still fine - users can still share with > other users in their own domain - just currently it is technically > impossible to share with users in other domains right now - because the > mailbox naming is not RFC compliant, so it's not compatible with real > IMAP client, only with Cyrus management tools. > You mentioned in another post (quote above) that the current naming of mailboxes is not necessarily RFC-compliant, and that only the Cyrus tooling is compatible. I may be misunderstanding what this means, because only an administrator without a realm (as part of its login username) is currently able to view lists of mailboxes across realms -- bear with me while I transcribe from the top of my head: Settings: > virtdomains: userid > admins: cyrus-admin ad...@example.org cyrus-admin: > C: . LIST "" "*" > S: * user/j...@company.com > S: * user/j...@example.org > S: * user/m...@example.org ad...@example.org: > C: . LIST "" "*" > S: * user/jane > S: * user/max j...@example.org: > C: . LIST "" "*" > S: * INBOX > S: * Other Users/max Kind regards, Jeroen van Meeuwen -- Systems Architect, Kolab Systems AG e: vanmeeuwen at kolabsys.com m: +41 79 951 9003 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: POLL: per-domain shared folder/sieve/etc
On Fri, Oct 24, 2014, at 12:23 PM, Stephen Ingram wrote: > On Thu, Oct 23, 2014 at 6:18 PM, Bron Gondwana > wrote: >> Yeah, I'm afraid so. >> >> It's going to kind of suck for FastMail customers as much as anyone >> actually - since that's what we use! But here's the thing: >> >> a) it will be possible to switch to the netnews way if you want >> b) but if you have virtdomains AND netnews separator, then that will >>mean that you need to switch. Hopefully most clients will cope - I >>haven't tested it. >> >> If you DON'T have virtdomains, or the users are all in the default >> domain, then it will keep working just the same. I guess we could >> have a config option "strip domain if same" or something, and get the >> same display as what we have now despite the different representation >> internally. The only thing is, you _could_ share with users in other >> domains if you wanted. > > Since everything is in one domain on our system, it sounds like you > are saying we can stay with what we have. I'm wondering though how > difficult it would be to change to unixheirarchysep method. Does this > simply change the way that the server presents the mailbox information > to the client, and, thus, require changes to the cyrus database files > or does it actually require changes to how the files/directories are > stored on the disk? If it's just the cyrus database, is this difficult > to convert? I'm guessing there is as you would want to deploy this at > Fastmail, right? In theory you can run different imapds with different configurations. It might be a little tricky due to the sieve scripts being in whatever namespace is the server default, but it's probably manageable. It's going to be a pain to deploy at FastMail for historical reasons - but I would like to switch everyone over to unixhs and altns along with setting up a new servername to connect to, because then we can support dots in usernames and sharing across domains, which are both often-requested features. The changes in the database format are easy - the hard part is getting everybody to reconfigure their clients! So I suspect we will keep the existing endpoint (mail.messagingengine.com) with compatible behaviour (suppress other domains, strip domains, regular namespace) and tell new users to use the new server name so they can see everything else. Bron. -- Bron Gondwana br...@fastmail.fm Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: POLL: per-domain shared folder/sieve/etc
On Thu, Oct 23, 2014 at 6:18 PM, Bron Gondwana wrote: > Yeah, I'm afraid so. > > It's going to kind of suck for FastMail customers as much as anyone > actually - since that's what we use! But here's the thing: > > a) it will be possible to switch to the netnews way if you want > b) but if you have virtdomains AND netnews separator, then that will mean > that you need to switch. Hopefully most clients will cope - I haven't > tested it. > > If you DON'T have virtdomains, or the users are all in the default domain, > then it will keep working just the same. I guess we could have a config > option "strip domain if same" or something, and get the same display as > what we have now despite the different representation internally. The only > thing is, you _could_ share with users in other domains if you wanted. > Since everything is in one domain on our system, it sounds like you are saying we can stay with what we have. I'm wondering though how difficult it would be to change to unixheirarchysep method. Does this simply change the way that the server presents the mailbox information to the client, and, thus, require changes to the cyrus database files or does it actually require changes to how the files/directories are stored on the disk? If it's just the cyrus database, is this difficult to convert? I'm guessing there is as you would want to deploy this at Fastmail, right? Steve Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: POLL: per-domain shared folder/sieve/etc
On Thu, Oct 23, 2014, at 09:18 PM, Bron Gondwana wrote: > If you DON'T have virtdomains, or the users are all in the default > domain, then it will keep working just the same. I guess we could have > a config option "strip domain if same" or something, and get the same > display as what we have now despite the different representation > internally. The only thing is, you _could_ share with users in other > domains if you wanted. (the reason why I don't mind suggesting this sort of option is that I'm very close to having code where there is just one place where all this logic would need to be, so the complexity load isn't so bad any more) Bron. -- Bron Gondwana br...@fastmail.fm Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: POLL: per-domain shared folder/sieve/etc
On Thu, Oct 23, 2014, at 09:03 PM, Stephen Ingram wrote: > On Thu, Oct 23, 2014 at 5:59 PM, Bron Gondwana > wrote: >> __ >> On Thu, Oct 23, 2014, at 08:55 PM, Stephen Ingram wrote: >> >>> On Wed, Oct 22, 2014 at 2:02 PM, Bron Gondwana >>> wrote: >>> >>> We only set quotas on individual mailboxes so that wouldn't be a >>> problem. We also don't have sieve scripts except per-mailbox, so >>> ditto there. >>> >> >> Sounds like you'll be fine. >> >>> I'm not quite clear though about the global sharing thing. Does this >>> mean, for example, that if one user wants to share a mailbox with >>> another user, its name has to be unique on the entire system? We >>> would have users who would want to only share with other users in >>> their domain. >> >> >> No, the per-user namespace is still fine - users can still share with >> other users in their own domain - just currently it is technically >> impossible to share with users in other domains right now - because >> the mailbox naming is not RFC compliant, so it's not compatible with >> real IMAP client, only with Cyrus management tools. >> >>> Since we support a single-realm Kerberos setup we only use usernames >>> not email address login. Does that make any difference here since >>> there appears to be an issue with the domain part? >> >> >> There's nothing wrong with running without domains still - there >> would still be support for virtdomains: off, or else for a single >> defaultdomain: "example.com" which would be appended/stripped as >> appropriate. >> >> > > Great. I forgot to ask about unixheirarchysep. Does that mean that the > default netnews "." way of doing things is going away? If so, will > there be an easy way to convert? Yeah, I'm afraid so. It's going to kind of suck for FastMail customers as much as anyone actually - since that's what we use! But here's the thing: a) it will be possible to switch to the netnews way if you want b) but if you have virtdomains AND netnews separator, then that will mean that you need to switch. Hopefully most clients will cope - I haven't tested it. If you DON'T have virtdomains, or the users are all in the default domain, then it will keep working just the same. I guess we could have a config option "strip domain if same" or something, and get the same display as what we have now despite the different representation internally. The only thing is, you _could_ share with users in other domains if you wanted. Bron. -- Bron Gondwana br...@fastmail.fm Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: POLL: per-domain shared folder/sieve/etc
On Thu, Oct 23, 2014 at 5:59 PM, Bron Gondwana wrote: > On Thu, Oct 23, 2014, at 08:55 PM, Stephen Ingram wrote: > > On Wed, Oct 22, 2014 at 2:02 PM, Bron Gondwana wrote: > > We only set quotas on individual mailboxes so that wouldn't be a problem. > We also don't have sieve scripts except per-mailbox, so ditto there. > > > Sounds like you'll be fine. > > > I'm not quite clear though about the global sharing thing. Does this mean, > for example, that if one user wants to share a mailbox with another user, > its name has to be unique on the entire system? We would have users who > would want to only share with other users in their domain. > > > No, the per-user namespace is still fine - users can still share with > other users in their own domain - just currently it is technically > impossible to share with users in other domains right now - because the > mailbox naming is not RFC compliant, so it's not compatible with real IMAP > client, only with Cyrus management tools. > > > Since we support a single-realm Kerberos setup we only use usernames not > email address login. Does that make any difference here since there appears > to be an issue with the domain part? > > > There's nothing wrong with running without domains still - there would > still be support for virtdomains: off, or else for a single defaultdomain: " > example.com" which would be appended/stripped as appropriate. > > Great. I forgot to ask about unixheirarchysep. Does that mean that the default netnews "." way of doing things is going away? If so, will there be an easy way to convert? Steve Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: POLL: per-domain shared folder/sieve/etc
On Thu, Oct 23, 2014, at 08:55 PM, Stephen Ingram wrote: > On Wed, Oct 22, 2014 at 2:02 PM, Bron Gondwana > wrote: > > We only set quotas on individual mailboxes so that wouldn't be a > problem. We also don't have sieve scripts except per-mailbox, so > ditto there. Sounds like you'll be fine. > I'm not quite clear though about the global sharing thing. Does this > mean, for example, that if one user wants to share a mailbox with > another user, its name has to be unique on the entire system? We > would have users who would want to only share with other users in > their domain. No, the per-user namespace is still fine - users can still share with other users in their own domain - just currently it is technically impossible to share with users in other domains right now - because the mailbox naming is not RFC compliant, so it's not compatible with real IMAP client, only with Cyrus management tools. > Since we support a single-realm Kerberos setup we only use usernames > not email address login. Does that make any difference here since > there appears to be an issue with the domain part? There's nothing wrong with running without domains still - there would still be support for virtdomains: off, or else for a single defaultdomain: "example.com" which would be appended/stripped as appropriate. Bron. -- Bron Gondwana br...@fastmail.fm Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: POLL: per-domain shared folder/sieve/etc
On Wed, Oct 22, 2014 at 2:02 PM, Bron Gondwana wrote: > So Cyrus has three different types of domain split: > > * none at all > * "on/yes" => weird reverse DNS hackery > * userid => login with domain. > > As part of finally switching to unixheirarchysep: on (yay) and better key > format (double yay) I want to change the overarching "split users into > separate domains" logic we have right now. > > Yes, that means a massive change, instead of internally: > > example.com!user.foo.bar <=> user/foo/b...@example.com (which is a > million ways of bogus) we would have: > > user.foo@example^com.bar <=> user/f...@example.com/bar > > Or in alt namspace: > > Other Users/f...@example.com/bar > > This means we will finally be able to share things across domains. It > creates a single consistent way to access everything. > > > > The problem is, it means you can't set quotas per domain, you can't have > sieve scripts per domain, and most of all - you can't have shared folders > in a domain. > > example.com!shared.stuff worked fine, but > > shared.example^com.stuff would be weird. It's just a folder, and wouldn't > be treated specially in any way. The domain would have no special meaning. > > This is all, obviously, Cyrus 3.0 stuff. It's a significant change in how > folder naming works. It's really good for removing some inconsistencies > though. I just want to have an idea of whether it will mess up anyone's > existing workflows - and if so how we can make sure you can still achieve a > similar result, even if it doesn't look quite the same in the new world. We only set quotas on individual mailboxes so that wouldn't be a problem. We also don't have sieve scripts except per-mailbox, so ditto there. I'm not quite clear though about the global sharing thing. Does this mean, for example, that if one user wants to share a mailbox with another user, its name has to be unique on the entire system? We would have users who would want to only share with other users in their domain. Since we support a single-realm Kerberos setup we only use usernames not email address login. Does that make any difference here since there appears to be an issue with the domain part? Steve Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: POLL: per-domain shared folder/sieve/etc
On Thu, Oct 23, 2014, at 05:39 AM, Clement Hermann (nodens) wrote: > On 22/10/2014 23:02, Bron Gondwana wrote: > So if I understand this correctly, it means we could still have "global" > shared folders but not shared folders limited in a domain namespace like > we have now ? Correct. > if so, it seems both good and bad to me. > > The good : if you have several domains in a single organisation, you can > have shared folder for all. And likewise users can share across those domains, which is my real goal here (apart from neatness and RFC correctness of the view that the admin sees) > The bad : in a multi-tenant environment, we can't provide shared folder > to our customers without adding something to the name to ensure it is > unique accross all customers, or use the standard mailbox sharing (so > the end user sees "Other users/mypublicmailbox@mydomain" in its client). > No more "Shared Folders/contact" or "Shared Folders/public". So you could do Shared Folders/mydomain.com/contact as well, but I do see your point. > Shared folders in a multi-tenant environment is not so widespread I > think, it's more a global organisation thing, but still, it could be an > issue for some. > > I'm not sure how well it would be handled in groupware suites like Horde > for instance. Presumably with the right groups, it would work OK - unless the shared folder names are hard coded. Another alternative is just to run a fully separate instance of Cyrus for every domain. Bron. -- Bron Gondwana br...@fastmail.fm Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: POLL: per-domain shared folder/sieve/etc
On 22/10/2014 23:02, Bron Gondwana wrote: > The problem is, it means you can't set quotas per domain, you can't have > sieve scripts per domain, and most of all - you can't have shared folders in > a domain. > > example.com!shared.stuff worked fine, but > > shared.example^com.stuff would be weird. It's just a folder, and wouldn't be > treated specially in any way. The domain would have no special meaning. So if I understand this correctly, it means we could still have "global" shared folders but not shared folders limited in a domain namespace like we have now ? if so, it seems both good and bad to me. The good : if you have several domains in a single organisation, you can have shared folder for all. The bad : in a multi-tenant environment, we can't provide shared folder to our customers without adding something to the name to ensure it is unique accross all customers, or use the standard mailbox sharing (so the end user sees "Other users/mypublicmailbox@mydomain" in its client). No more "Shared Folders/contact" or "Shared Folders/public". Shared folders in a multi-tenant environment is not so widespread I think, it's more a global organisation thing, but still, it could be an issue for some. I'm not sure how well it would be handled in groupware suites like Horde for instance. Cheers, -- Clément Hermann (nodens) Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
POLL: per-domain shared folder/sieve/etc
So Cyrus has three different types of domain split: * none at all * "on/yes" => weird reverse DNS hackery * userid => login with domain. As part of finally switching to unixheirarchysep: on (yay) and better key format (double yay) I want to change the overarching "split users into separate domains" logic we have right now. Yes, that means a massive change, instead of internally: example.com!user.foo.bar <=> user/foo/b...@example.com (which is a million ways of bogus) we would have: user.foo@example^com.bar <=> user/f...@example.com/bar Or in alt namspace: Other Users/f...@example.com/bar This means we will finally be able to share things across domains. It creates a single consistent way to access everything. The problem is, it means you can't set quotas per domain, you can't have sieve scripts per domain, and most of all - you can't have shared folders in a domain. example.com!shared.stuff worked fine, but shared.example^com.stuff would be weird. It's just a folder, and wouldn't be treated specially in any way. The domain would have no special meaning. This is all, obviously, Cyrus 3.0 stuff. It's a significant change in how folder naming works. It's really good for removing some inconsistencies though. I just want to have an idea of whether it will mess up anyone's existing workflows - and if so how we can make sure you can still achieve a similar result, even if it doesn't look quite the same in the new world. Bron. -- Bron Gondwana br...@fastmail.fm Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
