Hello Felix,
Answers inlined,
Best regards
On 20/11/2024 10:58, Felix Auringer wrote:
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.
+1
Let's open a dedicated JIRA ticket for discussing configuration changes
and overall code architecture?
-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?
> Do you plan to mainline those changes
There's currently no such plans.
And this for three reasons:
- Team mailboxes were originally very limited. It was a quick-win
simplification that could have been controversial in James.
- Team mailboxes are "features" which I tipically disucss with my
management. I tend to contribute such features to "my company product"
in order to protect the community from the company requirements.
- James is already a complex project with too many components. Adding
a new "core" component for shared mailboxes adds ti the project
complexity and makes it harder to get contributions.
James is a platform to do email. The goal is to allow doing. Not to push
a specific vision of how to do things to users. (at least to me!)
#2445 is in line with this vision:
- Limited capabilities in James servers
- But unrestricted ways to override extend and enrich the behaviour
for the willings.
> why did you decide to implement it in Linagora after you implemented
all the prerequisites (#2445) in James?
(feeling slightly offended here)
The timeline is wrong.
Team mailboxes got in first. And were very limited.
Work on #2445 got here and lifted most restrictions.
Now note that I am not against to add shared mailboxes alike TwakeMail
team mailboxes into James. But it would mean all the extra work in
SMTP/processing layers and administrative APIs. Also likely work on JMAP
side might be needed,
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.
(maybe I need a refresher on how team mailboxes are implemented 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
XList is outdated.
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
thathttps://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.
Assignation of special use flags needs to be done via mailbox annotations.
Possible: MailboxTyper is here for a grab if your requirements are IMAP
only. Wire your own implementation and that's it!
A refactoring to abstract away the horrible `Role::from` method that
hard codes the link between name and role... A new interfac could allow
plugging other behaviours...
I still am reluctant for performance reasons: worry of this creating
unnecessary amounts of metedata DB reads... If a metadata based
implementation is coded, I would like to be able to downgrade to the
name version if running into prod troubbles.
But why not getting a contribution on this!
- 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.
I can discuss the topic on my next visit to headquaters on 3-5th December.
- 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
