I resolve this. If it is not displayed anymore it means that outlook should handle it.

Pushed to 2.2

Thanks for noticing. I've changed it and clarified that GpgOL is for Windows only and not for the Outlook Web App / Android or Mac.

In Kleopatra this should be possible through the Checksum definition config without any code changes. I'll look into it.

Multiple bugs fixed here:

The Documentation is installed. You can find it under Help -> Gpg4win Compendium in Kleopatras menu.

In T3442#105466, @tstreibl wrote:

Starting Outlook still bring up the "Fehler in der Benutzeroberfläche von XML von "GpgOL .....Unbekannte Office.Steuerelemente-ID: TabComposerTool" Message Box.

Sorry for my inpatience...but it's a little bit hard to understand why the above, very simple test procedure obviously isn't reproducible on your systems.

Thank you very much. Both the signed only and the encrypted mail are fully valid for me (checked on the IMAP server and with kmail) and don't contain any references to gpgolXXX.dat. This means they were correctly converted to valid PGP/MIME Mails.

Thanks for the report. This is indeed badly broken. I'll work on this now.
I can reproduce and also have a reproducable crash when trying to encrypt a special folder. This must be a recent regression because I tested this some months ago and it worked fine.

Indeed this was a todo that was overlooked.

Ok for me to just have it in master. It should be fixed but is not super important imo.

This might be a reason that we got multiple reports for Kleopatra since 3.0 was released that it hangs on keylisting: https://bugs.kde.org/show_bug.cgi?id=381910

Everything works correctly but the warning message is probably too cryptic. It means that the signature could not be checked because the public key that created this signature is not found. It needs to downloaded, imported and verified. (See: https://www.gpg4win.org/package-integrity.html )
We improved the warning message with gpg4win-3.0

This means that the MAPI to MIME conversion did not happen.

Jochen could you please test this on one of our test VM's again and resolve this then?

I've added a note about this in the wiki: https://wiki.gnupg.org/TroubleShooting#Passphrase_on_the_command_line

A new binary for GpgOL can be found under: http://files.gpg4win.org/Beta/gpgol/2.0.2-beta8/ or for http://files.gpg4win.org/Beta/gpgol/2.0.2-beta8_x64/

Nagi: The third suggestion (adding "--pinentry-mode loopback" to your command) should work in that case.

This is intentional with the rationale being that users either want ascii armor for some reason for all their usecases or they don't want it.
And most users won't even know what ASCII Armor means (Adding "Armor" sounds like additional protection). So we moved this setting into configuration and renamed it.

Indeed bug in Kleo, it was always 0 in kleo. (likely created during Qt5 port) fixed with: https://commits.kde.org/kleopatra/0d53416cfbe6d8fa087887c428cdfffb13514a7d

I think this is resolved here. As we now have the check in the installer to warn on Vista and disable Kleo / pinentry-qt

In T3442#104402, @JochenSaalfeld wrote:

1. Mails encrypted with S/MIME are stored with "No Data" in the sent EMail folder, but arrive properly at the recipients (you will recieve a readable copy, if you add yourself to the list of recipients). This Issue breaks the GpgOL Plugin after some time which is leading to the described Problem.

Jochen can you please confirm that this works reliable for you too?

This indeed is a mixup of the protocol detection and likely a regression from a fix for exchange support. (On Exchange emails from exchange to exchange look the same as sent mails as both don't go through the MIME conversion)

This error looks like an element might be referenced that is not available in Outlook 2010. In that case the problem should be reproducible for users that have Developer Options -> Show Add-In Errors enabled.

Fwiw I don't want to patch KDE Librarys to work with older Qt Versions and don't want to patch Qt to support older Windows Versions. I think greying out is a good solution.

Duplicated problem. Solution for the installer is described in: T3434

In T3434#103995, @werner wrote:

Indeed the notes for QT 5.9 do not anymore show Vista as supported. Stupid decision if you ask me.

In light of this I would suggest to tweak the installer to grey out QT applications for all platforms older than Windows 7. We also need to make pinentry-gtk the default in this case. Of course there should also be notes in the docs about these restrictions. And that should be done immediately.

The problem here is that libkleopatrarc did not exist. The error could be nicer but I would say this is a downstream issue that packagers have to make sure libkleopatra-data is installed when kleopatra is installed.
I've opened a debian bug for this some time ago: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869647

I suspect CRL / Root certificate fetching because it works after you once manually investigated the certificate chain through -> Properties -> Digital Signatures.

We now explicitly delete the body instead of relying on the fact that the Outlook MAPI to MIME conversion deletes the body. Somehow this worked in the past but no longer does. I could not bisect it as 1.4.0 showed the same problem but old test mails from July 2016 did not show the problem. Newer ones from August 2016 already showed it in the sent mails folder.

I think this is a duplicate of T2416 please let me know if you still see the crash with the current beta / release candidate of gpg4win-3.0

This is fixed now with ef038f2d1db15ef14c238137c1c42a99bbe25f42 initially we only took the first attachment. Now we check for the position of the created MOSS attachment. This explains why a second try worked because the MOSS was already created.

This is what you get if you "show source" in Outlook so it's only the headers.

ENABLE_NLS is not defined as it should be but we still have to define L_ in that case if simple_gettext is used to have some gettext. This was fixed by 6158811304937b592601ef30c29c5a5cdbaa88ea

So it fails after a timeout. Which probably means that the conf->sync calls timeout which probably means that some gpgme process call to gpgconf hangs. Maybe some IO Flush that does not happen correctly on MIPS. But this is pure guessing.