Hello Benoit, answers inlined.
>> Do you plan to mainline those changes > >There's currently no such plans. Thank you very much for your explanation :) We can understand that this would add a lot of complexity to James and are thankful for #2445. >> 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? We opened a ticket for this, see [JAMES-4097](https://issues.apache.org/jira/browse/JAMES-4097). >> 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, Sorry if we offended you. We greatly appreciate your contributions to James and did not want to diminish them. We were apparently a little confused because we indeed got the timeline wrong. We thought (or maybe hoped) that the step from #2445 (shared user mailboxes) to actual shared mailboxes would not be that much anymore, so maybe we misjudged that. Currently, we tend to use Linagora's Tmail where all this work is already done. >> 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.> > 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! Thanks for all your thoughts on this! We will keep that in mind in case changes to that become necessary for us. 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
