TL;DR: This email talks about the potential of adding shared mailboxes
to James and summarizes our team's initial reflections on design and
potential implementation intended to serve as input for discussion.
Hello everyone!
In our company, most of our teams need to have a shared mailbox for
their team emails. We are currently in progress of changing our mail
stack and have identified James as our preferred option, but the missing
support for shared mailboxes is currently a blocker for us. Therefore,
we would like to contribute by implementing this feature for James, or
at least providing input for a discussion on how an implementation for
that could look like.
RELATED EXISTING ISSUES:
- https://issues.apache.org/jira/browse/JAMES-2182 wants to have the
IMAP LIST command return not only mailboxes from the personal namespace,
but also from shared namespaces. We are aware of
https://github.com/apache/james-project/pull/2445, which was recently
merged and implemented that. Although that PR appears to only consider
sharing of user mailboxes (from other users' namespaces) at the moment,
this should be a great starting point for extension to shared mailboxes
in general.
- 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.
- https://issues.apache.org/jira/browse/JAMES-2621 disabled creation of
sub-mailboxes in mailboxes not owned by the user. While this makes sense
for user mailboxes, we would need to partially lift this restriction for
shared mailboxes, where creation of sub-mailboxes should depend on ACLs,
not ownership. PR#2445 appears to tackle that as well.
- https://issues.apache.org/jira/browse/JAMES-1838 disabled support for
shared mailboxes altogether. Eventually, the aim should be to revert this.
RELATED IMPLEMENTATIONS:
We are aware of a shared mailbox implementation in the Linagora
extension of James (https://github.com/linagora/tmail-backend), but that
implementation only works for JMAP at the moment.
DESIGN DISCUSSION:
- Shared mailboxes should reside under a common namespace (probably
#shared).
- The IMAP LIST, CREATE, DELETE and RENAME commands should support
shared mailboxes, while making sure to honour mailbox ACLs according to
RFC4314.
- In particular, creating sub-mailboxes in shared mailboxes should not
be tied to ownership, but the `k` ACL right. Also, for security reasons,
it should not be possible to login as the mailbox itself (i.e., as a
user with the shared mailbox address as its private address). Creating a
user corresponding to a shared mailbox must not be allowed in the first
place.
- The domain of the shared mailbox to be accessed should not be derived
from the domain of the logged-in user, to allow for users from different
domains in the same shared mailbox.
-- ACCESS MANAGEMENT
From our point of view, this is the aspect that has the biggest impact
on the design, and we have not come to a definite conclusion on how we
think it should be handled best.
We believe that newly created sub-mailboxes (henceforth referred to as
folders for clarity) should initially inherit the ACL each user had on
the parent folder. A naive implementation would then require the shared
mailbox ITSELF to also be a folder, as the level-1-subfolders of the
shared mailbox would need to derive their ACLs from somewhere.
As an example, consider a shared mailbox #shared/team1@james.domain. To
store our root ACLs, we would then need a mailbox
#shared/team1@james.domain/team. The actual folders would reside under
#shared/team1#james.domain/team/{INBOX;Drafts;...} instead of simply
#shared/team1@james.domain/{INBOX;Drafts;...}. However, that would imply
that the shared mailbox root (i.e., #shared/team1@james.domain/team)
could also store mails itself, which may not be of much semantic sense.
Also, mail clients would show INBOX not as a folder of
team1@james.domain, but team1@james.domain/team instead.
Alternatively, the shared mailbox could also be entirely encoded in the
folder part of the path (i.e.,
#shared/<staticSharedMailboxOwner>/team1@james.domain), at least
internally, which (as the owner is static), could be easily translated
and externally represented as only #shared/team1@james.domain.
Note that not having the shared mailbox as a folder itself would no
longer enable us to perform access management by looking up ACLs on
folders (mailboxes); instead, we would introduce an edge-case, where
ACLs of a shared mailbox root would need to be stored somewhere else.
Also, simply checking shared mailbox membership would require performing
a separate lookup there as well.
IMPLEMENTATION REMARKS:
- 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.
- 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".
- The Webadmin API routes for managing mailboxes should be modified to
accept (and return) a namespace parameter (or #user for user mailboxes).
- 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.
We would be happy to engage in further discussion on this topic.
Kind regards,
Jan-Eric Hellenberg
for the GIZ Berlin, a German non-profit organization
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
