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 mallory@xxxxxxxxxxx just adding a sieve rule to forward a copy of > everything to john@xxxxxxxxxxx, 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 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. > I don't understand what RFC compliant tools you are referring to, that have a reason to be used by an administrator (i.e. not webmail and not a desktop client). I also don't understand what part of RFC compliance you are referring to, when you say that the current naming is not RFC compliant. I suppose you mean the current naming of user/jane/Trash@xxxxxxxxxxx isn't RFC compliant, but user/jane@xxxxxxxxxxx/Trash would be? If so, I suppose this makes the RFC compliance concern a side-effect specific to enabling any sort of cross-realm sharing in the first place, right? ;-) > So I am considering an option, stripsamedomain or something, which > means that jane still sees "Other Users/max", but could also see > "Other Users/john@xxxxxxxxxxx" if allowed. > I do not suppose that, should cross-realm sharing be allowed, and be subject to policy (mandatory access control), I would necessarily desire an option "stripsamedomain" at all -- if it's all the same to you as well, I would drop such option. 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
