Bug 1880942 - kmail unable to work with IMAP server
Summary: kmail unable to work with IMAP server
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: kmail
Version: 33
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Rex Dieter
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2020-09-21 08:11 UTC by Karel Volný
Modified: 2021-03-29 19:19 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed:
Type: Bug

Attachments (Terms of Use)

Description Karel Volný 2020-09-21 08:11:52 UTC
Description of problem:
After upgrading to F33, my email account (IMAP) stopped working. Going to incoming email settings and clicking to autodetect, I'm getting an error message:

"Nelze se spojit se serverem, prosím zkontrolujte adresu serveru."

which translates as

"Cannot connect to server, please check the server address."

However, I didn't change anything from before the upgrade, so this should work.
Trying to resolve the name manually, there's no problem in getting the server IP by the name copy&pasted from the kmail configuration.
And in addition, trying to catch some traffic with Wireshark, it looks that kmail successfully handshakes (SSL) with the server so the error message about possibly wrong address is utter nonsense.

Version-Release number of selected component (if applicable):

How reproducible:

Additional info:
The server I use is internal Red Hat's Zimbra.

Comment 1 Dario 2020-10-14 12:58:21 UTC
Dear Karel,

this may be related to https://bugs.kde.org/show_bug.cgi?id=419782 , which is marked as resolved for kmail version 5.13.3 , while on my fedora33 machine kmail is stuck at version 5.13.2

Comment 2 Karel Volný 2020-11-09 08:51:46 UTC
nope, it still doesn't work with kmail 5.15.1 (kmail-20.08.1-1.fc33.x86_64)

and there is no /etc/ssl/openssl.cnf ... trying to look around a bit, it seems that the appropriate config section gets included from /etc/crypto-policies/back-ends/openssl.config which is a symlink to /usr/share/crypto-policies/DEFAULT/openssl.txt

trying to replace the symlink with a file containing the recommended settings:

MinProtocol = TLSv1.2

did not help

(also, if this is some ssl misconfiguration problem, kmail should report it as such and not lie that the server cannot be reached because of wrong address ...)

Comment 3 Karel Volný 2020-11-09 10:17:06 UTC
oops, wrong file, it should be /etc/crypto-policies/back-ends/opensslcnf.config which is a symlink to /usr/share/crypto-policies/DEFAULT/opensslcnf.txt

copying that file and modifying it - adding ":!DH" at the end of CipherString immediately fixed connecting with openssl like `openssl s_client -connect my.server.address:993` (see https://bugs.kde.org/show_bug.cgi?id=400221#c7 ) but it doesn't seem to have any effect on kmail, still the same ...

Comment 4 Karel Volný 2020-11-18 17:58:36 UTC
it magically started working for me ... not sure if after some update, or if the change from comment #3 got propagated into kmail settings somehow (simple restart, including akonadi, wasn't enough)

Comment 5 Karel Volný 2021-01-20 10:48:54 UTC
okay, now I can confirm that comment #3 works around the problem ... something (I do not know what as there was no crypto-policies update???) has replaced /etc/crypto-policies/back-ends/opensslcnf.config with the symlink and kmail stopped working; modifying the file again and rebooting has made kmail working again

Comment 6 Tomas Dolezal 2021-03-29 19:19:16 UTC
Hello Karle,
I've tried to resolve problem against same server but using different client and solution.

I see two easy possibilities:
1) # update-crypto-policies --set LEGACY
Setting system policy to LEGACY
Note: System-wide crypto policies are applied on application start-up.
It is recommended to restart the system for the change of policies
to fully take place.

as the command output says, you may need to reboot the system.

2) tune the configuration only for your application, not the whole system and keep the fedora configs used
   LEGACY config that is shipped would be cleanly used. I use this solution and prefer it over global LEGACY setting.

cat > $HOME/.local/openssl-legacy.cnf <<EOF
.include /etc/pki/tls/openssl.cnf

[ crypto_policy ]
.include = /usr/share/crypto-policies/LEGACY/opensslcnf.txt

$ export OPENSSL_CONF=$HOME/.local/openssl-legacy.cnf
$ ./your-program

of course you can reuse this in your etc or wherever else and use your xdg paths to change .desktop file of your client.
mind that the variable *won't* work on suid/sgid binaries, ref man:config(5) ENVIRONMENT

Note You need to log in before you can comment on or make changes to this bug.