Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

#

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Improved managesieve docs with regards to TLS #1190

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

### 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

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
Author

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.

#}

#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
```

#### 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