[
https://issues.apache.org/jira/browse/JAMES-3215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17135616#comment-17135616
]
David Leangen commented on JAMES-3215:
--------------------------------------
Hahaha.
I was surprised, but not offended. On the one hand, I think it's great that
everybody is moving so quickly. On the other hand, I think it is customary in
most cases for the person who reported the issue to close it, so that would
have been my preference. :)
I do have some more questions before I am satisfied, though. :)
> I don't like the idea of having to setup another component to handle what
> should be mandatory for any service in 2020: having encryption over TCP
> session.
Agree that encryption is mandatory.
Is there a way of making the encryption an optional extension, easy to include
if needed, easy to remove if not needed? (And I don't mean just configuring to
"off" while keeping the unused code intact.)
> I may be wrong but I suspect all others mail servers handle TLS by
> themselves. (and having encryption termination is not enough because you need
> to support STARTTLS)
I was thinking that for my own server, I would only allow SSL. No 25 or 143.
Only 465 and 993. (Oh yeah, no POP, either.) My (very shallow) understanding of
the spec is that STARTTLS is only for backwards compatibility. It allows a
non-encrypted server to communicate, and escalates to encryption only when
supported.
If SSL is now mandatory, then I thought STARTTLS would be longer necessary, and
is therefore obsolete.
I will check the specs again to be sure. Any comments on my statement before I
do that?
> Also, I don't agree with this claim.
> > It causes the inclusion of various libraries, and Java suuuuuucks for SSL
> > support.
Hehe, ok, let's drop this part. Did not mean to offend.
> I would rather open a ticket about support certificates without keystores
> and/or implement letsencrypt protocol
I had three motivations for filing this issue:
# I would like to see purged from the distribution (and even the code base)
anything that is no longer necessary. (Since we just established that providing
SSL is necessary, then this does not apply, though it would be preferable to
have the option not to include.)
# It should be possible and easy (show examples etc.) to configure an external
SSL termination (I think this is now pretty common in a containerized
environment).
# It should be possible to use use letsencrypt because (a) it's free and (b)
it's easy to autorenew.
If there is internal support that allows easier use of SSL and autorenewal
(like letsencrypt) that would be awesome! Otherwise if we can get the nginx
proxy working with letsencrypt, that would also be satisfactory.
> Remove SSL support in James
> ---------------------------
>
> Key: JAMES-3215
> URL: https://issues.apache.org/jira/browse/JAMES-3215
> Project: James Server
> Issue Type: Improvement
> Reporter: David Leangen
> Assignee: Ioan Eugen Stan
> Priority: Major
>
> SSL support is not working [1], and it complicates the installation process.
> It causes the inclusion of various libraries, and Java suuuuuucks for SSL
> support.
> It would make James a lot simpler to remove SSL support and make SSL
> termination somebody else's problem. These days it should be easy to use a
> proxy (like nginx) or an ingress (for example in Kubernetes) to perform SSL
> termination.
> It would be one less thing to maintain in James, one less thing that can go
> wrong, one less step to take just to get a James server working, and a step
> closer to providing good user support.
> {quote}[1] I define "working" by meaning that as a user, I follow the
> instructions but it still does not work as intended.
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
