Since today's update on Arch Linux on two machines. Using kMail :

Version 5.7.0
KDE Frameworks 5.41.0
Qt 5.10.0 (construit sur 5.10.0)

KMail refuses to send mail through two SMTP servers, notifying like 'server can't be contacted', without any stdout message. I suspect it's because these servers use self-signed certificates, which I'm sure is the case. Both servers will forward mail if SSL is not used.

A third SMTP server continues to forward mail normally. I know that this server uses a certificate by a known 'CA'.

I could not find where KDE/KMail stores certificates accepted by the user. There are no UI tool to clear such store.

I'm ready to open a ticket if others can confirm that.

Meanwhile, can someone point me how to clear KDE's certificate store ?

Thank you.

This message appears on stdout when failing to send a message, after akonadictl stop/start :

kf5.kio.core: "The host name did not match any of the valid hosts for this certificate"

The UI notification messsge is "Connection to server lost"

I inspected the server's certificate with

openssl s_client -connect smtp.server.tld:25 -starttls smtp

and replaced the server's address in the account configuration wizard with the 'Common Name' of the certificate, and I could send mail as before. This, for one of the two failing accounts, will test the second one tomorrow.

It seems kmail is no longer friendly because it expects the Common Name to be the same as the declared SMTP server. That will be a problem for many users.

I seem to suffer a similar problem with KDE Neon.
Since a resent update, my mail won't send anymore.
I get a GUI message (plasma infocenter) saying "Failed to transport message. Connection to server lost."
Mails stay in the outbox and get marked with a tag showing this same message.

However, I don't see the message on the command line you quote after restarting akonadi.
Also, changing the the server name to the "Common Name" given by "CN=" in the output of your openssl command does not fix my problem.
Sending mail with other clients using the same SMTP account still works.

With KDE neon I received another update of the packages libkf5mailtransport-data libkf5mailtransport5 libkf5mailtransportakonadi5 ,
which looked as if it was related, but that did not fix my problem either.

Are there any other means to debug this?

Edit: it seems that this bug is already known under https://bugs.kde.org/show_bug.cgi?id=388068

I also suffer from the same problems like "highsciguy".
since the last update from the Arch repos ( to Version 5.7.0, KDE Frameworks 5.41.0, Qt 5.10.0 ), any messages via my normal SMTP server (from my internet provider) has stopped working.

Kmail simply throws "connection to server lost", or "error while sending message: 2"

Needless to say that the server settings were neither changed, nor is the server certificate pointing to a different mail server name.

I have deleted the entry for my provider and recreated it, but that did not help either.

Any suggestions to debug this further are welcome.
Thanks
Peter

The big question for me is if the patch discussed in that bug report solves the issue, and if it is sufficient to wait until it arrives.
A resent update to libkf5mailtransport5 and seemingly related KDE Neon packages lets me suspect that I have the patch already (I would be interested to learn how to know for sure), but I still see the issue.

Problem now fixed for me with latest KDE Neon User packages.
KDE Plasma Version 5.11.5
KDE Frameworks Version 5.41.0

After having this problem for a number of months, I finally found that changing the checkbox under:

Code: Select all

Settings > Accounts > Sending tab > My Fastmail SMTP label > Modify button > Server requires authentication checkbox

was not always remaining checked even after clicking it and filling in the password.

I'm not entirely sure I didn't try this months ago and it didn't work but this and changing the Advanced Settings to TLS and 587 and I'm sending emails again. Using TLS and 587 is odd as my mail provider also uses SSL and 465 but this is currently what works.