Improved managesieve docs with regards to TLS#1190
Improved managesieve docs with regards to TLS#1190seanm wants to merge 1 commit intodovecot:mainfrom
Conversation
| service managesieve-login { | ||
| #inet_listener sieve { | ||
| # port = 4190 | ||
| # ssl = yes |
There was a problem hiding this comment.
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.
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.
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.
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.
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).
There was a problem hiding this comment.
- Here it could have:
#inet_listener sieves {
# port = 4191
# ssl = yes
#}
|
|
||
| Implicit TLS is the best practice because STARTTLS can be susceptible | ||
| to downgrade attacks. To enable this, set `ssl = yes` in the | ||
| `inet_listener sieve` section. |
There was a problem hiding this comment.
So, to summarize: 1) This shouldn't have "sieve" section, perhaps just say "inet_listener section" without naming it. Or alternatively "inet_listener sieves" section.
| service managesieve-login { | ||
| #inet_listener sieve { | ||
| # port = 4190 | ||
| # ssl = yes |
There was a problem hiding this comment.
- Here it could have:
#inet_listener sieves {
# port = 4191
# ssl = yes
#}
| to connect: | ||
|
|
||
| ``` | ||
| openssl s_client -quiet -connect <host>:4190 |
4 participants
No description provided.