Page MenuHome GnuPG

GPG messages with empty content / not decrypted in Outlook 2010
Closed, ResolvedPublic

Description

I've tried to send GPG encrypted messages in Outlook 2010 with GpgOL 2.0.6.
Cases:
OpenPGP w/o attachments not encrypted as PGP/inline option

  • empty content displayed both in Inbox and Sent folder (with GpgOL enabled)
  • empty content and "gpgolXXX.dat" as attachment (with GpgOL disabled)

It is possible to decrypt gpgolXXX.dat via GPA outside of Outlook (save attachment and open in GPA)
(see gpgolXXX.dat.txt

)

OpenPGP with attachments encrypted as PGP/inline option

PGP message is shown literally (-----BEGIN PGP MESSAGE----- .... -----END PGP MESSAGE-----), but no decryption (GpgOL icon flags "unsafe" message). Message marked as encrypted (lock icon) in Inbox folder. Message can be decrypted via GPA outside of Outlook (clipboard used to copy text).
See complete message "GPG 3 0 3 Inline HTML.msg"

(all Name references are anonymized by "X").

This behavior is independent of GPG options for S/MIME support and Outlook options to convert RTF to plain text or HTML. But obviously, some Virus scanner and classification tools change e-mail content on exchange server.

Details

Version
Gpg4Win 3.0.3, GpgOL 2.0.6

Revisions and Commits

Event Timeline

hs renamed this task from GPG messages with empty cotent / not decrypted in Outlook 2010 to GPG messages with empty content / not decrypted in Outlook 2010.Feb 2 2018, 3:24 PM
hs created this task.
hs updated the task description. (Show Details)

Does this happen to you for all mails or just some? From the GpgOLXXX.dat I can't see anything wrong.
My expectation is that something goes wrong when updating the plain text into the message viewer. Again, could you please attach the GpgOL Debug output? That might help.

For the second part I can't import the "GPG 3 0 3 Inline HTML.msg"

My Outlook 2016 only says "No"

That is also with GpgOL disabled :-/

Thanks!
Andre

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


I had overwritten all name characters in the message above. Here is an original message:

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

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.

aheinecke changed the task status from Open to Testing.Mar 22 2018, 8:48 AM

Could you please test again with the beta38 (or later) from https://www.gpg4win.org/version3.1-de.html It contains the change now.

Its a bit of a moonshot but might just work. :-)

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.

aheinecke claimed this task.

This issue is pretty old and I think anything here was fixed in recent releases. So let's close this to avoid artifacts in the tracker.