Instead of using KDE for MIME parsing, and as I would also only do simple parsing we could use the mimeparser from gpgol. This also has the advantage that we do not open new attack surfaces as we already have that code in use. The mimedataprovider can already be compiled on Linux and used with a FILE, I did this to allow fuzzing for it. And the API implements the GpgME::DataProvider interface https://dev.gnupg.org/source/gpgol/browse/master/src/mimedataprovider.h and then just offers simple functions to access the parsed content.

So maybe this is something for me to work on :)

Wouldn't it make more sense to pass the decrypted text back (wrapped into a minimal rfc2822 message) to a MUA if it turns out to be another MIME tree with attachments and what not? After all, parsing and showing MIME trees is what MUAs are really good at and many MUAs should be able to open an .eml file.

That would make sense on a Linux desktop. But my main use case for this is Windows. I have the feeling that more Linux users have a decent MUA.
If we had a MUA with good MIME Support then we would not need this feature at all. If a user has Outlook for example that could be used with GpgOL but not everyone has that. I know that some users decrypt such messages already with Kleopatra and then open the Output in Thunderbird. But again, if they had Thunderbird, they could use that with included PGP/MIME support.
Windows 10 has a default Mail app, but if you open a file with that it does not show it but asks you to configure an account.

My last idea with this ask was that we should reuse the Handler from GpgOL. Because that one is very simple and the difficulty is not the mime parsing, which KMIME could do but the whole complexity the objecttreeparser does.

GpgOL handles only a "top-level" crypo mime part and collects text / html and attachments from this. No recursion, except that a signed mail is parsed again after decryption.

A starting point for this could be:

https://dev.gnupg.org/source/gpgol/browse/master/tests/t-parser.cpp

which then uses: https://dev.gnupg.org/source/gpgol/browse/master/src/parsecontroller.cpp

And for MIME handling this:
https://dev.gnupg.org/source/gpgol/browse/master/src/mimedataprovider.cpp

I started working on it. Current progress, I managed to move the mimetreeparser/partmodel from kalendar to libkleo and removed the few akonadi bits.

This will still more work to bring back the massive amount of unit tests. I'm also seriously considering to instead of moving this code to libkleo to instead create a new library with this and then have Kleopatra, kalendar, kube use it (and kmail too in the future but that would require a lot more work).

For the UI, I suppose the idea was in kleopatra "Decrypt/Verify" feature to display the email content when it detect an email or should this be a new menu entry "Decrypt Email" where the user is prompted to choose a pgp-encrypted/pgp_encrypted_message.asc/mbox file which they want to display?

In T6199#172571, @CarlSchwan wrote:

This will still more work to bring back the massive amount of unit tests. I'm also seriously considering to instead of moving this code to libkleo to instead create a new library with this and then have Kleopatra, kalendar, kube use it (and kmail too in the future but that would require a lot more work).

Yes, please. libkleo should stay focussed on crypto and not become the next dumping ground for "stuff more than one PIM app needs".

Kleopatra should autodetect email messages if passed on the command line or opened via the file dialog. I think Kleopatra should accept any email even if not encrypted. I'm not so sure whether Kleopatra should become an application that offers its service for any email messages if there are proper MIME types for MIME-encrypted or MIME-signed emails.

Yes, this might make sense to have a library for the core parsing / reparsing part and then maybe some widgets in Libkleo that could be used to show the information. So that we could in theory create a small executable that just instantiates a libkleo widget to show a MIME mail and Kleopatra could use that then, too. But for clients like Kalendar which don't necessarily use QWidgets it is porbably better to have this split out.

Seperate library it is :) https://invent.kde.org/carlschwan/mimetreeparser

I added in the examples folder a small app that visualize the mails (see the readme for a screenshot). It's basically Kalendar email viewer, so it's currently written in QML.

Something I wonder is if we can use QML in Kleopatra with QQuickWidget or if it is better to write a QWidget implementation. The core logic is in C++ with a QAbstractListModel, but using a QML implementation would still reduce quite a bit the amount of Kleopatra-specific code that would need to be maintained, but on the other hand the QML dependency might be an issue.

Regarding MIME Structures in general. I wonder if this might not even be a job for Okular as a universal Document Viewer, it can already handle attached documents within Documents and another optional plugin there to display MIME messages might not be too far fetched. But for now I would go with Kleopatra as we have it much more under our control and can more easily change things there.

I love the idea :) Definitively not something for the near future, but I'll keep the idea in mind

I see little value in viewing emails in Okular. People often want to reply to emails so they need an email client anyway. Or shall Okular get a composer and save the composed email (of course with signing and encryption) to disk so that people can give their reply to their correspondents on a USB stick because that's more secure than using an email server? I suppose it makes sense for spies. ;-)

P.S.: I'm not actually opposed to a standalone email viewer and a standalone email composer. I just don't see the value to cram that into Okular. I guess Carl wrote Arianna, a dedicated epub reader, for a reason despite Okular already supporting epub.

Current progress left being the qml version for Kalendar and right the QtWidget version for Kleopatra. This still require some work in the QtWidget viewer to display that the message is signed and encrypted

I also made some progress on the kleopatra integration

I hope this is where the "show email" button was expected to show up ;)

Current progress, the viewer now support viewing embedded calendar events, embedded emails and embedded calendar events in an embedded email

I have added an observer repository for mimetreeparser here. So you can now use the keywords like "GnuPG-Bug-Id:" and your commits will be visible here on the platform. We can later switch the "upstream" URL to something else of course. https://dev.gnupg.org/source/mimetreeparser/

BTW. The icon is breeze "view-sidetree" which I found fitting to split a larger opaque MIME structure (e.g. an encrypted mail) into different parts.

Small summary onf the recent progress, I made:

• I moved the repo to KDE Review: https://marc.info/?l=kde-core-devel&m=169030704105197&w=2
• The mime tree viewer now displays error message correctly (e.g. unable to decrypt a subpart)
• I fixed the unit tests and we now have 56% test coverage!
• Progress was also made on https://invent.kde.org/pim/kleopatra/-/merge_requests/50 and the ugly temporary hacks were removed
  • This require the following patch in gpgme https://lists.gnupg.org/pipermail/gnupg-devel/2023-July/035399.html but we could probably ifdef it