Mail app 1.3.4 causes SSL-error in Dovecot - retrieving email impossible

this error occurrs on an up-to-date debian-buster with nextcloud 18.0.4 and the mail app 1.3.4. IMAP-server on the same host is dovecot; SMTPd is postfix.
after upgrade to mail app 1.3.4 existing mail-accounts are shown completely empty and it is impossible to add new accounts.
Trying to create new account via webif: “Error creating account”
nextcloud.log: ... "method":"POST","url":"/index.php/apps/mail/api/accounts","message":"Creating account failed: Could not connect to IMAP: Error connecting to mail server.", ...
dovecot.log: ... imap-login: Info: Disconnected (no auth attempts in 0 secs): user=<>, rip=SERVER-IP, lip=SERVER-IP TLS handshaking: SSL_accept() failed: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca: SSL alert number 48, ...
it does look like an ssl-error but since it works with all other programs/servers and also worked with the mail-app before the upgrade (dovecot-configs and certs were not altered in any way) i think the error is probably somewhere else.

I think I have the same problem. What looks off to me is that the connection should be established over localhost and no TLS (aka SSL) should be used at all, but I still get an SSL error in my Postfix logs. Maybe the mail app is using it, even when it should not.

I also tested account creation with the app auto_mail_accounts and it works fine, I can access e-mails. Then, if I delete it through the mail app, I can’t create it again with the same error. Therefore I suspect its the account creation dialogue that is faulty.

with this https://help.nextcloud.com/t/connection-error-to-local-imap-server/78119
(set 'app.mail.verify-tls-peer' => false, in NC-DIR/config/config.php )

i can setup the account, but it’ s (kinda) useless because retrieving mail is still impossible with the same ssl-error.

i justed found out that while the circle is spinning itself into nirvana tirelessly trying to retrieve emails i am still able to send emails with the mail-app.
(i’ll change the title of this topic if possible)

In both our setups communication should go over localhost and therefore no TLS should be used at all. This could only be a workaround for a faulty TLS configuration.