Hello Benoit, thanks for your reply!
We are happy that #2445 with support for other users' namespaces has been merged! Please see the inlined comments below. >> https://issues.apache.org/jira/browse/MAILBOX-318 disallowed sharing >> of a mailbox with users of a different domain. We believe this change >> to be too restrictive and we would want to ultimately have shared >> mailboxes containing users of multiple domains >> Yet this end up being a major safeguard that limits the risk of cross >> tenant data leaks, in the event of defects on the ACL enforcements. > > Having several layers of security seems important to me. > > - ACL enforcement might be the sit-bealt > - Preventing cross domain access regardless of ACL can be compared to > the airbag. > > What can be done here is to add a system property allowing disabling the > check, allowing use cases that requires it to disable this without > impacting other users. We can see that this is an important security measure, especially if you have one deployment for multiple tenants that have different domains. We still see an organisation that uses a single deployment but manages multiple email-domains as a valid use case for shared mailboxes. Therefore, we have started implementing the possibility to enable cross domain mailbox sharing (disabled by default). This will mark our first contribution. >> - https://issues.apache.org/jira/browse/JAMES-1838 disabled support >> for shared mailboxes altogether. Eventually, the aim should be to >> revert this. > > The subject is actually tackled by #2445 ? #2445 implements support for "Other users' namespaces", which means that a regular user can share its mailboxes with another user. This is a big step in the desired direction, but this does still not provide for "shared namespaces" (see IMAP 4rev2 RFC, https://www.ietf.org/rfc/rfc9051.html#name-namespaces), which (as you probably know) are supposed to contain public mailboxes (probably not common anymore nowadays) and mailboxes that are not associated with a regular user (e.g. a team / group mailbox). We looked at other implementations: - Dovecot uses the shared namespace to share mailboxes created by the administrator. - Stalwart does not implement shared namespaces at all. Instead, they use Other users' mailboxes for their group-feature (group mailbox shared with all users that have this group). We have seen a PR in the Linagora repository (https://github.com/linagora/tmail-backend/pull/1311) which implements shared mailboxes via shared namespaces. Those changes are basically what we intended to implement for James, although they also (implicitly) forbid to create team mailboxes with users for different domains (because team mailboxes are searched for based on the domain of the current user). Do you plan to mainline those changes and if not, why did you decide to implement it in Linagora after you implemented all the prerequisites (#2445) in James? > I would be careful of over-engineering here. > > - Maybe this trouble could be avoid altogether by creating subfolder > of (say) the INBOX? > - Maybe we could cheat and use MailboxPath("#Shared", > "markett...@domain.tld", "") in order to allow creating > "MailboxPath("#Shared", "markett...@domain.tld", "")" > > Pretty sure those are not valid today, but we could easily use those > for TLD ACL management while enforcing that those: > > -> Are not user exposed > -> Rejected for storing mails > > A bit hacky but could do? > > A quick thought: we could review what other mail servers do. We are not very happy about creating mailboxes with empty names. This makes the logic harder to understand and while it may be RFC compliant (?), we could very well imagine that it leads to confusing errors later on. We reviewed how other servers handle this: - Dovecot: - creating a mailbox copies the ACL - if there is a parent: copies ACL from parent - if root-level-mailbox: copies default from namespace - namespace defaults: - personal: owner has all rights - other users' / shared: nobody has any rights, those have to be bootstrapped by an admin manually - Stalwart: - as described above, shared namespaces are not supported - other users' namespace: - path has always the same structure: #shared/<user/group>/<folder> - creating mailboxes directly under #shared is not allowed - root-level-mailbox for user already exists and has ACLs that can be used We are aware that Linagora refers to shared mailbox folders in the format MailboxPath("#TeamMailbox", "<static_user>.domain", "team.Drafts"), which is essentially the same as the static approach we proposed (enabling us to assign the ACLs to the root folder of the team, MailboxPath("#TeamMailbox", "<static_user>.domain", "team")). We would be fine with that approach, but we are slightly confused on why you regard that as overengineering then. >> - Assignment of special-use-flags should be done in a more robust >> manner. Currently, only mailboxes named exactly INBOX >> (case-insensitive) will be assigned the INBOX special flag. This is >> problematic, for example in cases when we are looking at a folder >> team1/INBOX instead of INBOX. >> Please point to SPECs or behaviours of others servers > > RFC-6154 do not mention INBOX in special use attribute, and inbox role > in deep nested hierarchy. Only XLIST mentions the \\INBOX role cf > mpt/impl/imap-mailbox/core/src/main/resources/org/apache/james/imap/scripts/XList.test > > In JMAP inbox is where new mail arrives by default, this notions is > account scoped. > > Thus the example for INBOX seems irrelevant to me. > > Setting those special use to user private user mailboxes seems like a > legitimate choice. Are there rationals in RFC-6154 or in other server > implentations? > > To quote chatGPT: In IMAP, the |\\Sent| role is a special folder > designation typically associated with a user’s own sent messages. > > Also if special needs subsists it should be rather easy to start a > derivative of James with a custom MailboxTyper Okay, so using INBOX as an example was not great here, thanks for pointing that out. What we were referring to, really, is that https://www.rfc-editor.org/rfc/rfc6154.html#section-5.4 specifies that we can assign special-use flags like \Drafts to folders with any name. We believe that this is currently not supported with the implementation of the org.apache.james.mailbox.Role. However, this is just something we noticed, not something we really require to be changed. >> - We believe that the Webadmin API/CLI should be extended to allow >> editing shared mailbox ACLs, with suggested endpoints "GET >> /users/{owner}/mailboxes/{mailboxName}/acl", "GET >> /users/{owner}/mailboxes/{mailboxName}/acl/{user}", "PUT >> /user/{owner}/mailboxes/{mailboxName}/acl". > > Contribution welcome on the topic! If Linagora does not want to mainline the shared namespaces and we would decide that we still want to implement it for James, we would probably develop this for our own testing on the way. If so, we will be happy to contribute this after the feature is complete. >> - The Webadmin API routes for managing mailboxes should be modified to >> accept (and return) a namespace parameter (or #user for user mailboxes). >> Or we shall set up a separate webadmin route for managin non private >> user mailboxes, thus avoiding confusion? >> >> - We believe the current default path delimiter of "." to be not >> ideal, as almost every mail address will contain a dot (and thus be >> split into two components by default, during parsing, as well as in >> mail clients). We would propose to use "/" as delimiter instead. >> Alternatively, if changing the delimiter would be too much of a >> breaking change, path escaping as introduced by PR#2445 for the >> PathConverter would be always needed. > > +1 for making this configurable, a-la cyrus 😉 Contribution welcome. > > Let's refrain from changing the default behaviour though: that's what > Dovecot, Cyrus IMAP and Courrier do... As PR#2445 made this working, we will not immediately pursue this change :) Best regards, Jan-Eric & Felix --- Gesellschaft für interkulturelles Zusammenleben gGmbH (GIZ) Felix Auringer IT Reformationsplatz 2 13597 Berlin Tel: 030/513 0100 00; Fax: 030/513 0100 09 www.giz.berlin; felix.auringer@giz.berlin Amtsgericht Charlottenburg HRB 200872 B Geschäftsführerin: Dr. Britta Marschke --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
