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 (
https://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
https://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
www.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]
