This is the log output for sending a GPG message to myself:

Trying to reproduce this / staring down the log, I think I might have found the problem.

I think now that the problem is similar to T3523 in that there are too many invalidations of the "Sigstatus" GUI and Outlook somehow does not like that and this causes mail to be unloaded which are still visible.

We use a custom window and a Windowmessage to trigger the update of the "Sigstatus" icon when an unencrypted mail is selected. (Otherwise we update it after encryption)

In your log I don't see that this Windowmessage is ever sent. (It would be logged as "Non crypto mail %p opened. Updating sigstatus." but I see it received 18 times ! (windowmessages.cpp:gpgol_window_proc: Recieved user msg: 1)
The problem might be that we just use "WM_USER + 1" and wmsg_type "1" (So the lowest possible values).

Something on your system is sending GpgOL "WM_USER + 1" window messages with a type of "1". This causes GpgOL to "invalidate the sigstatus UI Element" way too often and brings us into a behavior like we had in T3523 Outlook going crazy about this. This can be any faulty software / addon which sends WM_USER + 1 to all windows instead of it's own.

But in T3789 I also noticed that we could trigger such a behavior on a test system of mine when using a slow server and two Explorer Windows to trigger invalidations while the decryption was running.

My solution here will be:

• Put the parser under the invalidation lock.
• Always use delayed invalidation to avoid too many invalidations in a short time.
  • -> This will make it slower to update the sig / encrypt status icon when reading but I think that is acceptable.
• Use a different offset for WM_USER ( + 42 ) and a different offset for the window message types (1100) to avoid a situation like this.

I'll upload a version with these changes soon.

The changes are made as described. Could you please try:

Version 2.0.7-beta6
from:
http://files.gpg4win.org/Beta/gpgol/

and attach a log again if it does not work.

Thanks!

Version 2.0.7-beta6
Test 1 (without S/MIME support):
encrypted e-mail shown as plain text (-----BEGIN PGP MESSAGE----- ...), can be decrypted via clipboard and GPA.
Sent message shows same plain text as received one.
No encryption icon in Outlook Inbox.

Test 2 (S/MIME + PGP/Inline):
sent and received message appear empty.
No encryption icon, but attachment icon added.

Test 3 (S/MIME + no PGP/inline):
same result as test 2, but encryption icon shown

Thank you for the test :-/
So back to the drawing board.

A big difference to the problem I could reproduce in T3789 is that for you decryption is not even attempted. So it's not the update code thats wrong here. Somehow we don't see the "Read Event" from Outlook. :-/

In T3769#110496, @aheinecke wrote:

Something on your system is sending GpgOL "WM_USER + 1" window messages with a type of "1". This causes GpgOL to "invalidate the sigstatus UI Element" way too often and brings us into a behavior like we had in T3523 Outlook going crazy about this. This can be any faulty software / addon which sends WM_USER + 1 to all windows instead of it's own.

This analysis was wrong. Such messages are still happening, so I further looked into it and the invalidations come from the selection change event which does not print debug output before asking for invalidiation. But I doubt that too many invalidations are an issue here as the decryption is not even attempted.

We confirmed in a remote session that the Titus Data Classification plugin ( https://www.titus.com/data-classification-product-collection.php#tmc ) interfered with GpgOL.

I think that if an addon does not return S_OK in an event handler the event handling stops there and events will not be forwarded to other addons and that is why we don't see the read event here. Probably a bug that should be fixed in that addon.... :-/

A possible workaround would be to add the option to enable the no-mime UI again.

Alternatively maybe we can somehow jump the line and get in the messaging queue before the Titus addon. Or document how a user could configure GpgOL to come first in the Addon order. This might work and make us more robust when combined with other addons.

According to this thread on stackoverflow: https://stackoverflow.com/questions/32712399/c-sharp-vsto-outlook-itemsend-event-execution-order

The Event's in Outlook are handled in reverse alphabetical order of the Prog ID. So Titus came before GpgOL.

With rOa6bf8ef284d9 our ProgId is now "Z.GNU.GpgOL" ;-) This string is not user visible anywhere.

Hope that helps. I'll let you know when there is a beta with that change.

Behavior is the same as 3.0.3 /3.1.0beta32.
It reads encrypted e-mails if Titus plugin is disables (GpgOL as the only plugin).
Strange: Both beta32 and beta38 show the recipients box after pressing the send button, but
the messages are sent unencrypted. After downgrading to 3.0.3 messages are sent encryted,
again.

In T3769#111899, @hs wrote:

Behavior is the same as 3.0.3 /3.1.0beta32.
It reads encrypted e-mails if Titus plugin is disables (GpgOL as the only plugin).

:-( Well, it was probably worth a try.

Strange: Both beta32 and beta38 show the recipients box after pressing the send button, but
the messages are sent unencrypted. After downgrading to 3.0.3 messages are sent encryted,
again.

Ok, I would very much like to know more about this. This would be a Release blocking issue. Could you please provide a log of such an unencrypted send?

Even with other Addons interfering we have safeguards in place to prevent this from happening. I would like to understand how they are bypassed.

Thank you for your Time,
Andre

I've upgraded to 3.1.0 beta 38 and sent an encrypted, non-signed e-mail to myself.
The received e-mail was shown unencrypted in inbox. See log-file below.

Thanks a lot!
The log shows pretty much whats going wrong. I've opened T3863 for this to have a clear issue for the problem.