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): kmail-20.04.3-2.fc33.x86_64 How reproducible: always Additional info: The server I use is internal Red Hat's Zimbra.
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
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 CipherString = DEFAULT@SECLEVEL=1 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 ...)
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 ...
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)
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
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 EOF $ 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
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 33 changed to end-of-life (EOL) status on 2021-11-30. Fedora 33 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.