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

I'm using gnupg 2.2.4 and this problem repros for me, and it impacts downstream things like pacman-key (Arch Linux) quite insidiously, which fails with an misleading error message that would not point a regular user to this line of investigation.

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.

gnupg 2.0 reached EOL - there won't be any fixes.

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.

ok,
well I run "it" on Power Shell ( Debuggable Package Manager ) and I got ..

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... :-(

Do you mean that GnuPG installed to c:/gnupg/bin/ crashed if that mentioned --homedir is given but it does work if it is installed at the standard place? Please run "gpgconf --version" in both ways.

@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?

my <output> was the following...

FWIW, I ran the same test with three card versions:

I can confirm that PGP/MIME works ok for me.

What is the output of

gpg-connect-agent --dirmngr 'getinfo dnsinfo' /bye

and what is the content of your /etc/nsswitch.conf and /etc/resolv.conf ? Is there anything special in your /etc/hosts? Are you using any kind of non mainstream DNS resolver on your system or network?

I forwarded the bug report to the OpenPGP card author.
I think that 2.0 card is OK, 2.1, 2.2, and 3.3 card have this bug.

I disabled all my add-ins and tested it again. Still the same. Mails are sent unencrypted.
Tried also to send a plain text message

That is likely "host not found" or "domain not found". Maybe a problem with your resolver. Please add

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.

All e-mails I tried to open with 2.0.6-beta7 gpgol.dll were readable and showed the correct content in my environment, now. Great!

@aheinecke thanks for the fix. But I have a suggestion for the code(I only looked at the diff):

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.

In the folder %APPDATA%\gnupg create a file named gpg.conf (or edit it if it exists) and put the line "ignore-mdc-error" in there. This should globally set this option and gpgol will also respect this.

Fixed for 2.2.5. Thanks for the report.

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?

I have attached a small patch to show this two additional key flags with "--list-keys":