-
Notifications
You must be signed in to change notification settings - Fork 64
Improved managesieve docs with regards to TLS #1190
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
@@ -98,6 +110,7 @@ are shown. | |||
service managesieve-login { | |||
#inet_listener sieve { | |||
# port = 4190 | |||
# ssl = yes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm. Seems wrong to recommend changing the standard sieve port to use implicit TLS. Clients expect it to be plaintext / STARTTLS. Not sure if there is any standard implicit TLS port for it, probably not? @stephanbosch thoughts?..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems wrong to recommend changing the standard sieve port to use implicit TLS. Clients expect it to be plaintext / STARTTLS.
Most clients I know of support all 3. roundcube definitely does for example. Plaintext of course should discouraged, but even STARTTLS should be discouraged at this point due to potential downgrade attacks. RFC8314 for example recommends against STARTTLS.
Not sure if there is any standard implicit TLS port for it, probably not?
I could not find one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure they support all 3, but the default expectation should be that 4190 port starts as plaintext. If not, it needs explicit configuration on the client side. And if that's not done, it can cause hangs and unexplainable errors. So seems safer to me use a different port instead for implicit TLS in port 4190. How about the next port 4191? That's actually what ChatGPT kind of suggested:
"Some custom or private deployments might configure an additional port (e.g., 4191 or 4193) for implicit TLS, but this is not standardized or recognized by IANA or RFCs."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that 4190 cannot be SSL, and 4191 is as good of a choice as any. Adding a comment that says as such ("this is an arbitrary port that is chosen...") would be very helpful.
Given the tiny number of managesieve instances that are actually accessible to the general Internet, I doubt that there would be any interest in assigning a dedicated port either.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@stephanbosch : Thoughts on this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A dedicated port would be best I agree, but it seems their isn't one. I know nothing of the process to get a port number officially blessed, I imagine it's hard?
My main point is that in 2025, we should be encouraging implicit TLS. (And managesieve doesn't have to be exposed to the public internet to want this, even on a company LAN it's preferable).
No description provided.