POLL: per-domain shared folder/sieve/etc

[Bron Gondwana]

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/bar at example.com (which is a
> > million ways of bogus) we would have:
> > 
> > user.foo at example^com.bar <=> user/foo at example.com/bar
> > 
> > Or in alt namspace:
> > 
> > Other Users/foo at 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 
> john at 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/bar at example.org" or "user/foo at example.org/bar" 
> back to using the netnews hierarchy separator if so configured?

So that would be ugly:

user.foo at 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/stuff at example.org, I suppose a hierarchy of such 
> folders would lead to shared/stuff at 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 mallory at example.org just adding a sieve rule to forward a copy of everything to john at 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 admin at example.org
> 
> cyrus-admin:
> > C: . LIST "" "*"
> > S: * user/john at company.com
> > S: * user/jane at example.org
> > S: * user/max at example.org

it's this:

S: * user/jane/bar at example.org

> admin at example.org:
> > C: . LIST "" "*"
> > S: * user/jane
> > S: * user/max
>
> jane at 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/john at company.com" if allowed.

Bron.
-- 
  Bron Gondwana
  brong at fastmail.fm