Skip to content

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.

Sign up for GitHub

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

Open
seanm wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Improved managesieve docs with regards to TLS #1190

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
46 changes: 35 additions & 11 deletions docs/core/config/sieve/managesieve.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -52,6 +52,18 @@ ManageSieve protocol support in Dovecot is to add `sieve` to the

The managesieve daemon will listen on port 4190 by default.

### TLS Configuration

The ManageSieve network protocol can be used either:

1. unencrypted
2. encrypted with opportunistic TLS (STARTTLS)
3. encrypted with implicit TLS

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.
Copy link
Contributor

@sirainen sirainen Dec 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


### Settings

As the implementation of the managesieve daemon is largely based on the
Expand Down Expand Up @@ -98,6 +110,7 @@ are shown.
service managesieve-login {
#inet_listener sieve {
# port = 4190
# ssl = yes
Copy link
Contributor

@sirainen sirainen Feb 25, 2025

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?..

Copy link
Contributor Author

@seanm seanm Feb 25, 2025

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.

Copy link
Contributor

@sirainen sirainen May 19, 2025 •
edited
Loading

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."

Copy link
Contributor

@slusarz slusarz May 19, 2025

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.

Copy link
Contributor

@slusarz slusarz Jun 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@stephanbosch : Thoughts on this?

Copy link
Contributor Author

@seanm seanm Jun 30, 2025

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).

Copy link
Contributor

@stephanbosch stephanbosch Dec 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@slusarz yes, I agree

Copy link
Contributor

@sirainen sirainen Dec 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. Here it could have:
  #inet_listener sieves {
  #  port = 4191
  #  ssl = yes
  #}

#}

#inet_listener sieve_deprecated {
Expand Down Expand Up @@ -213,9 +226,9 @@ the direct error messages from the server without intermission of your
client.

If you do not use TLS, you can connect using a simple `telnet`
or `netcat` connection to the configured port (typically 4190 or 2000
for older setups). Otherwise you must use a TLS-capable text protocol
client like `gnutls-cli` as described below.
or `netcat` connection to the configured port (typically 4190).
Otherwise you must use a TLS-capable text protocol client like `openssl`
or `gnutls-cli` as described below.

Upon connection, the server presents the initial greeting with its
capabilities:
Expand All @@ -229,12 +242,13 @@ OK "Dovecot ready."
```

Note that the reported `STARTTLS` capability means that the server
accepts TLS, but, since you are using telnet/netcat, you cannot use this
(refer to Manual TLS Login below). The `SASL` capability lists the
accepts opportunistic TLS, but, since you are using telnet/netcat, you cannot use this
(refer to Manual Opportunistic TLS Login below). The `SASL` capability lists the
available SASL authentication mechanisms. If this list is empty and
`STARTTLS` is available, it probably means that the server forces you
to initiate TLS first (as dictated by [[setting,auth_allow_cleartext,yes]]
in `dovecot.conf`).
to initiate STARTTLS first (as dictated by [[setting,auth_allow_cleartext,yes]]
in `dovecot.conf`). Note: if you're connecting from the same computer, the
connection is considered secure and plaintext authentication is allowed!

Now you need to log in. Although potentially multiple SASL mechanisms
are available, only `PLAIN` is described here. Authentication is
Expand All @@ -249,7 +263,7 @@ The credentials are the base64-encoded version of the string
`"\0<username>\0<password"` (in which `\0` represents the ASCII NUL
character). Generating this is cumbersome and a bit daunting for the
novice user, so for convenience a
[simple Perl script](http://pigeonhole.dovecot.org/utilities/sieve-auth-command.pl)
[simple Perl script](https://pigeonhole.dovecot.org/utilities/sieve-auth-command.pl)
is provided to generate the `AUTHENTICATE` command for you. It is used
as follows:

Expand Down Expand Up @@ -318,11 +332,21 @@ The symbolic link configured with the `sieve` setting should now point
to the activated script in the sieve directory. If no script is
active, this symbolic link is absent.

#### Manual TLS Login
#### Manual Implicit TLS Login
----------------

If you have enabled implicit TLS, you can use, for example, `openssl`
to connect:

```
openssl s_client -quiet -connect <host>:4190
Copy link
Contributor

@sirainen sirainen Dec 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. 4191 port here

```

#### Manual Opportunistic TLS Login
----------------

When TLS needs to be used during manual testing, `gnutls-cli` provides
the means to do so. This command-line utility is part of the GNUTLS
When opportunistic TLS needs to be used during manual testing, `gnutls-cli`
provides the means to do so. This command-line utility is part of the GNUTLS
distribution and on most systems this should be easy to install. It is
used to connect to ManageSieve as follows:

Expand Down