Re: Shared mailboxes via IMAP

[btell...@linagora.com]

Hello Jan,

I recently worked on https://github.com/apache/james-project/pull/2445 
which brings access to other user mailbox in IMAP

It:
 - Defines clear interface for converting MailboxPath into IMAP mailbox 
name
 - Provides a default implementation exposing private mailbox, and 
other users mailbox shared with current user under the name #user
 - Tests extensively that default implementation
 - Tests and exercises in depth the IMAP rights and actions they allow 
or not and provide related fixes.

While this is a freshly merged topic, a review / critical eye on this 
work is indeed welcome.

Answers / reactions inlined.

On 31/10/2024 10:33, Jan-Eric Hellenberg wrote:
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.

This is extactly what LINAGORA intends to do for implementation of Team 
mailboxes into Twake Mail software.

- 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.

- 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.
I cherry picked the commits from your work. Thanks!
- 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 ?

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).
I'm not opposed to this.
- The IMAP LIST, CREATE, DELETE and RENAME commands should support 
shared mailboxes, while making sure to honour mailbox ACLs according 
to RFC4314.
Should be provided by #2445
- 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.
Idem, that's #2445
- 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.

As said, I am less enthusiast about this.

While I'd agree that people willing to should be able to drop this "no 
cross domain access" logic, I do not think this shall the default.

-- 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. 

That's actually mentioned in RFC 4314:

      When a
      new mailbox is created, it SHOULD inherit the ACL from the parent
      mailbox (if one exists) in the defined hierarchy.

Not a must but definitely a should. #2445 implements it.

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.
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.


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.
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

- 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!
- 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...

We would be happy to engage in further discussion on this topic.

Great to hear that!

Best regards, and welcome onboard the community!

Benoit


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