Editing Sieve via Thunderbird and stand alone is not possible

Prerequisites

[ ] Tried the most recent nightly build
[x] Checked if your issue is already reported.
[x] Answered all the questions in this template (Or provide a working crystal ball).

What happened?

The description of the problem concerns the Thunderbird but also the stand alone version. I would like to edit Sieve via the plugin/program. My mail account works without problems and can also send/receive. Creating a new account is possible without any problems. As soon as I click on "Connect", the loading bar is permanently there and nothing happens. I have activated debugging in the settings, but I don't know where it is saved. if someone tells me, I can submit the log later. I had already mentioned the problem in mailcow's github, but everything seems to be working on the server side.

I hope that someone can help me:(

What did you expect to happen?

that I can connect to the servers.

Settings

Settings from Sieve: Server imap.xxxxxx.eu: 4190 (Secured connection) Username my@fancydomain.eu

Logs and Traces

Error message in logs from my server:

dovecot-mailcow_1 | May 9 02:47:16 04888203e1b5 dovecot: managesieve-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=92.123.123.123, lip=123.123.123.123, TLS handshaking: SSL_accept() failed: error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate: SSL alert number 42

What i tried?

gnutls-cli --starttls -p 4190 imap.xxxxxx.eu Output: `Processed 129 CA certificate(s). Resolving 'imap.xxxxxxxxx.eu:4190'... Connecting to '2a03:4000:34:522:981b:xxxx:xxxx:xxxx:4190'...

Simple Client Mode: "IMPLEMENTATION" "Dovecot Pigeonhole" "SIEVE" "fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date index ihave duplicate mime foreverypart extracttext vacation-seconds editheader imapflags notify imapsieve vnd.dovecot.imapsieve" "NOTIFY" "mailto" "SASL" "" "STARTTLS" "VERSION" "1.0" OK "Dovecot ready."`

Which Version

Client Thunderbird:

OS: Windows 10
Sieve Version: 0.5.3
Thunderbird Version: 78.11.0

Client Standalone:

OS: Windows 10
Sieve Version: 0.5.2

Mailcow: OS: Ubuntu 20.04 Mailcow Versions: acme-mailcow (mailcow/acme:1.78) clamd-mailcow (mailcow/clamd:1.39) dockerapi-mailcow (mailcow/dockerapi:1.38) dovecot-mailcow (mailcow/dovecot:1.145) ejabberd-mailcow (mailcow/ejabberd:1.5) ipv6nat-mailcow (robbertkl/ipv6nat) memcached-mailcow (memcached:alpine) mysql-mailcow (mariadb:10.5) netfilter-mailcow (mailcow/netfilter:1.41) nginx-mailcow (nginx:mainline-alpine) olefy-mailcow (mailcow/olefy:1.7) php-fpm-mailcow (mailcow/phpfpm:1.74) postfix-mailcow (mailcow/postfix:1.61) redis-mailcow (redis:5-alpine) rspamd-mailcow (mailcow/rspamd:1.76) sogo-mailcow (mailcow/sogo:1.98) solr-mailcow (mailcow/solr:1.7) unbound-mailcow (mailcow/unbound:1.13) watchdog-mailcow (mailcow/watchdog:1.91)

This looks to me like a badly broken server configuration.

ManageSieve requires the client to do an explicit starttls call. This means you always start with an unsecured connection then the client upgrades it via the starttls command to a secure channel. This is earliest point to do such an upgrade is after the server published his capabilities.

But your server seems to configured to expect an implicit starttls upon connection. Which violates the manage sieve specification and thus breaks the communication.

You can easily verify this. Just connect to your managesieve via telnet. You should always get as initial message the server's capabilities. Only then it is configured correctly.

In contrast a gnutls-cli --starttls, which does an implicit upgrade, has to fail on a correctly configured server.

It is very easy to mess up the security settings with Dovecot servers to be sure to stick to the manual when configuring it.

There are a many mail thread on this topic on the dovecot mailing list. The following describes the problem and contains the instructions how you can fix you configuration.

http://dovecot.2317879.n4.nabble.com/managesieve-configuration-td66094.html#a66132

This looks to me like a badly broken server configuration.

ManageSieve requires the client to do an explicit starttls call. This means you always start with an unsecured connection then the client upgrades it via the starttls command to a secure channel. This is earliest point to do such an upgrade is after the server published his capabilities.

But your server seems to configured to expect an implicit starttls upon connection. Which violates the manage sieve specification and thus breaks the communication.

You can easily verify this. Just connect to your managesieve via telnet. You should always get as initial message the server's capabilities. Only then it is configured correctly.

In contrast a gnutls-cli --starttls, which does an implicit upgrade, has to fail on a correctly configured server.

It is very easy to mess up the security settings with Dovecot servers to be sure to stick to the manual when configuring it.

There are a many mail thread on this topic on the dovecot mailing list. The following describes the problem and contains the instructions how you can fix you configuration.

http://dovecot.2317879.n4.nabble.com/managesieve-configuration-td66094.html#a66132

Thank you for your answer:)

Sorry if I'm being silly, but I'm still learning this:)

In the first paragraph you say "ManageSieve requires the client to do an explicit starttls call".

In the second "But your server seems to be configured to expect an implicit starttls upon connection".

Isn't that the same thing?

I have looked at the thread and also tried to adjust the relevant place in the dovecot config, but without success. what could it be? have tried with "yes" and "no".

dovecot.conf

service managesieve-login { inet_listener sieve { port = 4190 ssl = no } inet_listener sieve_haproxy { port = 14190 haproxy = yes } service_count = 1 process_min_avail = 2 vsz_limit = 1G }

Sorry if I'm being silly, but I'm still learning this:)

In the first paragraph you say "ManageSieve requires the client to do an explicit starttls call".

In the second "But your server seems to be configured to expect an implicit starttls upon connection".

Isn't that the same thing?

well, no they are mutual exclusive. Explicit means you ask someone before doing something and only if you got the permission you do it. While implicit means you just do it without asking, because you already know or assume to know the answer.

Https is for example a protocol with an implicit starttls handshake. It is defined, that the socket is always secure and thus the first thing is upgrading the socket implicitly (which is without explicitly asking for an upgrade). Technically the socket is upgraded before a single byte of payload data is transferred.

Manage Sieve like most mail related protocols works vice versa. It is by default not secured unless you do an explicate upgrade. Which means you need to tell the server by sending a special command when you want to switch to secure. There is no way for the server to guess if and when a client want to do this upgrade. Which also means an implicit upgrade is impossible.

I have looked at the thread and also tried to adjust the relevant place in the dovecot config, but without success. what could it be? have tried with "yes" and "no".

dovecot.conf

service managesieve-login { inet_listener sieve { port = 4190 ssl = no } inet_listener sieve_haproxy { port = 14190 haproxy = yes } service_count = 1 process_min_avail = 2 vsz_limit = 1G }

I am not using dovecot and can not provide any dovecot specific support. But as said it is a common configuration error you find tons of information by just googling. Or ask for support in the dovecot forum.

You can easily check, if the configuration is correct. Connect via telnet to the manage sieve port. You should see now the server's initial message. Those capabilities should contain a "STARTTLS". And when you then type STARTTLS in telnet, you should see an OK message followed by random looking characters. This is the starttls handshake which will of course fails. If you type even more characters the server will eventually disconnect you because the handshake failed. If this sequence works you known your configuration is most likely correct.

thank you very much for your help:) you have helped me a lot.

Kind regards

thsmi / sieve