I do in the next PR for Jmap, i think same as Rene in this way about pem. пн, 5 окт. 2026 г., 22:42 Benoit TELLIER via server-dev < [email protected]>:
> Java 26+ comes with native PEM support. > I agree with Java keystore deprecation once PEM support is main steam and > do not require third party library. > > I think the point "avoid people to manage keystores" is consensual. > > But the real point is: should James handle HTTPS termination ? Or shall we > mandate NGINX (for instance) as a reverse proxy. If handling HTTPS in james > itself is consensual then sure, lets head in that direction. It surely make > sense for self hosters. So PR welcomed, but let's put JMAP endpoint in the > scope. > -- > > > Best regards, > > Benoit TELLIER > > General manager of Linagora VIETNAM. > Product owner for Twake-Mail product. > Chairman of the Apache James project. > > Mail: [email protected] > Tel: (0033) 6 77 26 04 58 (WhatsApp, Signal) > > > > Le oct. 5, 2026 4:19 AM, de Rene Cordier <[email protected]>Hello, > > Ilya, as long as discussions stay respectful and on the initial subject > concerning the project itself, everybody can express his opinion, might > he be newcomer or long time committer :) > > Interesting point you are raising here Felix. > > I would agree like you regarding the java keystore, it's a thing from > the past, I ain't too fond of it either. I would be in favor of > deprecating it for James 3.10 and removing it for James 3.11. > > For the rest I disagree though. I think James should provide TLS > handling for its protocols. A user should be able to choose if it's just > simpler for him to use TLS handling from James server or add a reverse > http proxy to do the job. > > We can always work towards enhancing James code to provide better TLS > support, getting closer to the standards HTTP reverse proxies do as well. > > That's my personal opinion though :) > > Rene. > > On 10/3/26 05:39, Ilya Terskov wrote: > > Hi guys. I dont know i have right say something here (cuz i am PR > starter) > > but for me certificates part of mail server so having full .pem support > and > > one certificate for all smtp/pop/imap/jwt/webadmin/jmap makes things > easier > > and not that painful. Well yeah you can use revers proxy with l4 but > which > > not work for starttls correctly so you need exclusion for some ports it. > > > > I just think the more simple to manage server (common routine tasks) the > > more people will use it. > > > > I even think about integrated acme (ofc its not part of this PRs) in > future. > > > > сб, 3 окт. 2026 г., 05:11 Felix Auringer <[email protected]>: > > > >> Hey everybody, > >> > >> I started a small discussion in this PR ( > >> github.com/apache/james-project/pull/3224) on the extent TLS > >> connection handling should be part of James. > >> Benoit summarized the current state: > >> > >> - For "older" email protocols (IMAP, SMTP, ...): James supports > >> PEM-encoded X.509 certificates or Java keystores for implicit TLS or > >> STARTTLS > >> - JMAP: James relies on a reverse proxy to handle TLS > >> - Webadmin: James supports Java keystores and > >> github.com/apache/james-project/pull/3224 wants to add support > >> for PEM-encoded X.509 certificates > >> > >> Now my personal opinion: > >> Java keystores are a thing of the past. I think it could make the James > >> code less complex and reduce the number of configuration options if > support > >> for Java keystores was removed for all protocols. > >> Additionally, I do not think that webadmin needs any kind of TLS support > >> on the James side. > >> The reason is that there are enough HTTP reverse proxies available that > >> can handle TLS much better than James. They have for example support for > >> ACME to directly retrieve valid certificates, HTTP/3 for reduced > latency, > >> HTTP to HTTPS redirects, basic auth, HTTP security headers like HSTS, > and > >> much more. Implementing all those features does not make sense because > the > >> result will probably never be as good as other projects that focus only > on > >> that part. It would also greatly increase the complexity of the James > >> codebase. Without support for automatic certificate rotation, additional > >> software is always needed, so I also do not really see a need for the > basic > >> TLS functionality currently implemented in webadmin. > >> > >> For the non-web-based email protocols, I'm totally fine with the current > >> state. > >> There are less reverse proxies for layer 4 and because of STARTTLS, some > >> TLS support is required anyway. > >> I still think that also the configuration does not need to support Java > >> keystores anymore. > >> > >> Have a nice weekend, > >> 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 > >> giz.berlin; [email protected] > >> > >> Amtsgericht Charlottenburg HRB 200872 B > >> Geschäftsführerin: Dr. Britta Marschke > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
