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, stripsamedomain or something, which means that jane still sees "Other Users/max", but could also see "Other Users/j...@company.com" if allowed. Bron. -- Bron Gondwana br...@fastmail.fm
