But that's it.
With these Options set and explicitly unchecking Sign & Encrypt before sending I get the exact same behavior that you two describe. Mails are sent unencrypted.

In T3656#109394, @Mak wrote:

Ahh, and yes I use a public personal s/mime cert to sign my mails. nothing else.

Another question: Any outgoing Filters (Email Rules)?

@JHohmann Your log is similar in that I can see two Write events after the send of which there should only be one. Somehow we seem to do crypto on a copy mail object and another mail is acutally sent.

Any chance that I could get a temporary test account on your Server?

We now have update handling in the installer and this is the first thing the update handling fixes.

I understand now that README's for other languages are installed as aliases and added some missing ones.

For T3662 (PGP/Inline problem with Microsoft Exchange Online) I had to change the code used to send PGP/Inline.

I've changed the behavior now so that PGP/Inline also works with Exchange Online.

In T3656#109246, @Mak wrote:

I sent it to a user on a different Mailserver. On my setup its nothing special... Win 10 Enterprise N en, Office 365 Pro Plus en, Kaspersky Internet Security. Server Win 2012 R2 with Exchange Server 2013 and GFI Mailessentials.
I don't think there is anything special... :-(

The status is now shown and updated.

No longer blocks with that commit. Keylistjob is started in the background. As long as the keylistjob is running the validity is shown as "Updating..."

This is not with 2.0 but with 2.2.3 / current master.

The install location does not have anything to do with that. I just always have my development installations directly under C: so that I can modify them without admin rights.

@hs could you please retest with 2.0.6-beta8 http://files.gpg4win.org/Beta/gpgol/ and attach the log file again.

As this is still waiting for info for two years and I can't reproduce with current GpgOL -> Resolved.

Implemented with: https://commits.kde.org/kleopatra/9d1ebcb1e5f6b44a745c7e947f2e8eaf88fff786

This is strange, something in your setup must be different from other users. Any Idea what might be special for you? In your log it looks like only the send event for the encrypted mail is passed.
Where do you send your mails to, to another user on the same exchange server?

I believe that this was fixed in T3658 which reported more clearly what was attempted to verify and what failed.

Indeed, thanks for the note. I added the variable only later on for the check of protocol unknown and overlooked to update the setProtocol call.
I've updated the code accordingly.

I can reproduce the issue but only for PGP/Inline, encrypted only mails. PGP/MIME works finde. This allows for an easy workaround (sending PGP MIME) so Prio down to Normal.

Fixed with https://commits.kde.org/kleopatra/066c6e4ca82d064437f1902838d09fa903147e40

While trying to reproduce another bug I've set up an account with Exchange Online. With that account I had similar behavior with empty mails shown. The behavior also matched to the logging of the last mail in your log.

You might want to look at: https://wiki.gnupg.org/TroubleShooting#Passphrase_on_the_command_line

Can you please run debugview ( https://technet.microsoft.com/en-us/sysinternals/debugview.aspx ) and attach or paste any lines here that start with "org.kde.pim" when you try to encrypt the folder?

Thank you for your report. I can reproduce this problem. Kleopatra correctly looks for the signature file but then fails to set the protocol. This results in an internal error.

Prio High as this makes GpgOL unusable in such a setup.

I give this high priority as sending unencrypted is pretty much a worst case scenario. :-o

In T3714#109045, @Lloyd wrote:

I appreciate the dangers. Whilst I try and persuade the sender to deal with the issue at their end, is there anyway to include this option in GpgOL on a temporary basis?

As answered in the forum: https://wald.intevation.org/forum/forum.php?thread_id=1837&forum_id=21&group_id=11 :

Unsupported Protocol means that GpgOL can't find your GnuPG installation. Maybe something went wrong during the install of Gpg4win?

Kleopatra's debug output can be seen with DebugView https://docs.microsoft.com/en-us/sysinternals/downloads/debugview

I can't reproduce this with Kleopatra 3.0.1 from Gpg4win 3.0.2. It just works as expected. Both if I encrypt the files as an archive or if I encrypt them seperately.

You start Windows Explorer (the file manager thingy)

I could somewhat reproduce this problem when I disconnected the connection to Exchange from my Outlook and then tried to respond to an exchange mail. Although for me Outlook did not Hang and an error message (with a General Error) showed up.

Thanks for the report and the log.
I see the problem. In your case of a reply outlook does not give us the SMTP address for the recipient but an Exchange DN

Fixed with: https://commits.kde.org/kleopatra/c85bc8ebbe8594be9309e3e8a0945a5dbb90828c

Also the Name and E-Mail split in the table looks ugly. While technically they are on different UserID objects it would be prettyer to combine them.

@hs Your log is interesting but I don't yet understand it. We see a "Load" event for an encrypted mail, create our internal data modelling. But later there is a mismatch between the reference Outlook gives us and our internal reference (Failed to find mail in map).
Out of the blue there might be something I could do in that case but it's still somewhat unclear to me why this state occurs.

Debian has this with migrate-pubring-from-classic-gpg ( https://sources.debian.org/src/gnupg2/2.2.3-1/debian/migrate-pubring-from-classic-gpg/ )

Please reopen or comment if that problem still happens if you move away the gnupg home directory.

This goes to wontfix I investigated and there is no way to attach a file trough the mailto protocol with outlook. Only the parameters from https://msdn.microsoft.com/en-us/library/aa767737.aspx are supported.
Theoretically Kleopatra "could" use MAPI to achieve creating a mail with attachment but this would be overkill. Kleopatra puts up a big warning that attaching may not have worked and ok.