Small proposals to enhance Apache James extensibility

["btellier@apache.org" <bt...@apache.org>]

Hello all,

As part of my Linagora job, we are about to write some extensions built
on top of James to deliver "Functional Mailboxes" in one of our product,
TMail.

By functional mailboxes we mean a mailbox belonging to a team, which
receive emails on a dedicated email address, and whose members can
access the mails, and send emails from this very address. Eg:
marketting@linagora.com.

Building this feature would require us to (slightly) stretch what James
extension mechanisms allow. Thus we would need to contribute some
interfaces / guice tricks to make it possible. We see it as a chance for
other people, with their own business requirements, to implement more
easily similar features in the future.

We would contribute the following points in the coming mounth(s).

For each of these points we would introduce JIRAs, propose pull request,
including tests of these extension mechanisms, if meaningful.

Best regards,

Benoit

==========

*## Reject creation of users, aliases, groups with a name belonging to a
functional mailbox and vice versa*

Today entity validation is duplicated in aliases and groups routes,
absent of user routes.

This makes adding a new entity linked to a mail address hard as:
 - We need to implement validation for each pre-existing entities (user
group aliases) in our new functional mailbox entity. The overall process
of entity validation is O(n^2) - each entity validates each entity. It
is a lot of work and it is too easy to miss one.
 - The current approach is not extensible: as entity validation is hard
coded in James current webadmin routes, we can not add the logic for new
entities outside of James project without rewritting all those routes.

We would like to propose a modular approach: have a API telling if a
given entity references a given email address. By aggregating them we
can thus reuse the validation logic in all routes. We could inject
validation logic for extension entities like our functional mailboxes.

We believe in addition to allow such extensions, this would be
beneficial to todays JAMES code in term of refactoring.

*## Put an interface in front of LocalResources*

We need functional mailboxes email addresses to be considered as "local
addresses" by the mailet processing.

|LocalResources| is the class called by the mailets / matchers to have a
notin of "Is this local".

Thus to address the above points, we need to overload it in order to add
to it the notion of "functional mailboxes" in our code base.

Rename |LocalResources| into |LocalResourcesImpl| and put it behind an
interface. This would empower overloading.

*## QuotaRoot => Username*

I already opened JAMES-3655 on the topic. And fixed a bug for quota
extensions interactions with sharing.
*
**## Have an interface for MailboxAppender in james-server-mailets*

We would like to be able to decorate "LocalDelivery" mailet in order to
add to it the notion of functional mailboxes.

|MailboxAppender| is the class actually putting the message in ones mailbox.

However, today, the MailboxAppender is a concrete class. Hard to overload...

We would put MailboxAppender behind an interface and have a
|MailboxAppenderImpl.
*
**##*|*||**Modularize JMAP Identity providers*

Here is a user story of what we try to achieve:

|GIVEN a shared mailbox james@linagora.com AND a user
btellier@linagora.com part of that shared mailbox WHEN
btellier@linagpora.com lists his identities THEN there is an identity
for james@linagora.com |

To read the identities in JMAP, a user issues |Identity/get| calls. See
https://jmap.io/spec-mail.html#identityget
<https://jmap.io/spec-mail.html#identityget>

Thus we need to be able to /inject/ our identities in it.

However today implementation is fully static.

We proposes a modular approach where identities are supplied by an |IdentityProvider| and aggregated together in todays |IdentityFactory|. 

||

*## Being able to specify custom namespaces in JMAP Mailbox/get*

James already ships an extension allowing a user to share a mailbox with
another user. See
https://github.com/apache/james-project/blob/master/server/protocols/jmap-rfc-8621/doc/specs/spec/mail/rights.mdown


Mailbox object had been extendeed to have a `namespace` property giving
context about what this mailbox is.

We of course would like to have a "FunctionalMailbox" namespace for
compatible clients to correctly display functional mailboxes, which
means that we likely need a factory on top this namespace property
generation, tht we would be able to replace.
||