This has been fixed meanwhile. (I can confirm the fix with kmail2 6.2.1 (24.08.1))

I tested it and updated the community wiki documentation to refer to it.

Ah, that was what daniel and me actually talked about. So I was a bit dissapointed when I only found the documentation. :)

Daniel wrote a migration tool which was merged in January (https://invent.kde.org/pim/akonadi/-/merge_requests/154), i.e. a few weeks after he wrote the documentation. He foresaw that the documentation "will go out-of-date quickly". ;-)

Well, so the documentation is that there is no way to migrate and you have to delete everything and then set it up manually again? In that case it is still missing the deletion of the KMail settings etc.

This is a KDE bug and not really appropriate for this tracker.

This is a KDE bug and not really appropriate for this tracker.

Also noticed this and created an upstream report as well: https://bugs.kde.org/show_bug.cgi?id=485308

Thanks. I wonder if we should inform distros about this?

Fixed in 24.02.2

We're waiting for a RNP v0.17.1 release which intends to tolerate this mode.
https://github.com/rnpgp/rnp/issues/2198
https://github.com/rnpgp/rnp/pull/2190

This is fixed on RNPs side: https://github.com/rnpgp/rnp/issues/2198

Btw we should probably add TB in our QA environment to check for such things. Esp. with future changes in GnuPG we should try to use TB and maybe a bounycastle MUA (Greernshield?) to avoid creating accidental incompatibilities.

To reproduce:

• Send a mail to yourself
• add an attachment
• select encrypt

I can test this. For Ebo I want to try using the flatpack so that she can benefit from Dans work on debian stable, too.

I encouraged Eva to create this ticket. While the specific case described here might be fixed in current master, the attachment handling still has issues.

With KMail 5.23.1 the attachment icon is shown as icon. It's also show in the header (I don't see a way to disable this).

This has most likely been fixed already with https://invent.kde.org/pim/messagelib/-/commit/70f39256784280d2034aa7bf1c4765f606c22d56. Please retest with KMail 5.23.1 or later.

In T6891#180473, @aheinecke wrote:

@ebo told me that she can reproduce the problem by just moving around e.g. 1000 unread mails to a different folder and then e.g. marking them all as read while they are syncing. At least if I understood her correctly. @ebo could you please describe your test case?

In T6891#180474, @ikloecker wrote:

I'm also wondering why syncing a handful of new messages takes so long. Or, actually, why syncing takes so long even if nothing at all changed on the server (the new messages were already shown by KMail). Maybe it's just the bad IMAP implementation of Exchange. Or maybe Akonadi has marked the folder as bad, so that it always syncs the entire folder.

My hypothesis about what happens:

• I enter a folder with some new messages. KMail starts a sync.
• I read some of the new messages. They are marked as read in KMail and (hypothesis) Akonadi records the status changes for later because a sync is running.
• The sync finishes. KMail shows the new messages again as unread which (hypothesis) is what the sync reports.
• In the background Akonadi syncs the deferred status changes to the server. (hypothesis)

@ebo told me that she can reproduce the problem by just moving around e.g. 1000 unread mails to a different folder and then e.g. marking them all as read while they are syncing. At least if I understood her correctly. @ebo could you please describe your test case?

Both the company and me are running debian dovecot.

It seems I'm using Exchange (account at my old university and o2mail.de).

Could you share what IMAP server software do you run personally and in the office (probably Dovecot or Cyrus IMAP?).

Your comment on speed might also be why I do not see this issue. Nearly all of my mails and all my large folders go through my private mail server that stands at a dedicated hoster. While our company mail server is located in the office and only reachable through the office internet connection with VPN afaik. I had a tool / command to deliberately slow down connections on some port maybe you can use something like that? I don't think that we can give you access to the company mail server / VPN since you are not a regular employee.

But I guess syncing a second client should do the trick to get the server state. At least ebo has afaik both claws and kmail configured with the same server.

No, our webinterface is telnet :)

Is there also a web interface for the @gnupg.com mail server? It would be useful to be able to check what's the read/unread status on the server.

I saw this recently on a imap subfolder with between 4- and 5000 mails. I have marked a few hundred new ones as read in one go. The folder does not even have mail threads in it and I've never used that function anyway.
This was on my work account @gnupg.com (the only account where I use KMail). Should we ask Werner for details of the server?

I'm seeing this on an inbox with about 4,000 messages. It may depend on the server (speed) because I'm not seeing this on larger folders on another server. But it does happen for more than one server. I'm not using "Ignore thread". Just the plain old mailing-list style message list. I'll keep an eye on when it happens for which folders.

Also, are you using the "Ignore thread" function?

Can you be more specific how much is "many messages"? Is it tens, hundreds, thousands, tens of thousands? :)

It is okay for you to start with option so "akonadictl --migrate" but I would suggest deleting the old DB only as an option. Especially if error handling is not 100% perfect there should be also an easy way to restore your old config.

Requests to be able to migrate to SQLite without losing data/configuration has been requested multiple times since we blogged about the improvements in SQLite support.

Since 23.08.2 the crash is gone again as expected. Thanks. Btw. do you know which was the first version that had this crash? I am a bit worried that our fellow debian stable users in the office might be affected with the next debian upgrade. Since we use signed / encrypted mails a lot. :)

OK, so after debugging the issue and finally digging into the code I realized that I don't see the fix I did the first time....it turned out I committed the fix to release/23.04 branch but forgot to merge it into master and as such the change did not make it to 23.08 - which is probably why it seemingly "came back" after you upgraded. I've cherry-picked the fix to release/23.08 branch and merged it to master.

Hi Dan,

PR that removes the "Show key details" link from the response email: https://invent.kde.org/pim/kdepim-addons/-/merge_requests/37

It took a bit of time to set things up, but I was able to manually perform the WKS dance and open each email in KMail to check how it works.

All the patch related to this are now merged

This is now done with https://lists.gnupg.org/pipermail/gnupg-devel/2023-July/035401.html and https://invent.kde.org/pim/messagelib/-/merge_requests/138

in our study we've found that personal users often did not know that their software is capable of sending encrypted email. I blieve that most of them want a protected communication by default. (I may have seen surveys about this at some time as well.) If the recipient has published their public key, they are indicating that they can receive encrypted email.

I am not really a fan of this. I can respect this as a wish but it is currently not my vision. What you are really asking is basically that we lead the private users into sending encrypted mails without knowing that they are doing it. This will lead to frustrated users who then blame KMail for their bad user experience.

Linked from https://wiki.gnupg.org/EMailClients/KMail

Fix merged to release/23.04 branch.

Absolutely, I'll prioritize looking at this.

I will re-test it with KDE neon.

@dvratil I think the message has changed a bit with recent versions of the WKS server. Or is this maybe in a plugin that might not be installed on some distributions? At least when alexk tried it it was not processed on a fairly recent ArchLinux but he had such issues like plugin for crypto settings in KAdressbook not installed etc. so it might just be that. I can test this again but its probably best if we get you a test mail address with a forward for gnupg.org (which has WKS)

From https://phabricator.kde.org/D3140 the "Confirm your key registration" (see last screenshot) button seems to be what this is about, right?

I have yet to test this, but just by looking at the code in kdepim-addons this seems to already be implemented since the beginning. When we were implementing this back in 2016, we were using some testing WKD server that @aheinecke operated (the presence of testuser10@test.gnug.org and key-submissions@test.gnupg.org keys in my Kleopatra is most likely from that time and instance).