POLL: per-domain shared folder/sieve/etc
Jeroen van Meeuwen (Kolab Systems)
vanmeeuwen at kolabsys.com
Mon Nov 3 06:52:02 EST 2014
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
>> > This is all, obviously, Cyrus 3.0 stuff.
>> In the multi-domain environments we typically run, while sharing
>> 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
>> like to ensure some sort mandatory access policy is in place, where
>> 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 /
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
partner.com: company.com competitor.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
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 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.
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
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
>> without a realm (as part of its login username) is currently able to
>> view lists of mailboxes across realms -- bear with me while I
>> 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
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 at example.org isn't RFC
compliant, but user/jane at example.org/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,
> 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.
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.
Jeroen van Meeuwen
Systems Architect, Kolab Systems AG
e: vanmeeuwen at kolabsys.com
m: +41 79 951 9003
pgp: 9342 BF08
More information about the Cyrus-devel