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

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2021-11-30 18:22:48 UTC
Type: Bug
Embargoed:


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):
kmail-20.04.3-2.fc33.x86_64

How reproducible:
always

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

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

Comment 7 Ben Cotton 2021-11-04 14:49:29 UTC
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.

Comment 8 Ben Cotton 2021-11-04 15:47:51 UTC
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.

Comment 9 Ben Cotton 2021-11-30 18:22:48 UTC
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.


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