GpgOL is an Outlook Add-In for Outlook 2010 and later. However, it won't work with the future Outlook which will come without MAPI support. We are going to replace that Add-In by the new gpgol2 .
Details
Today
I believe this was fixed with Andre's commit above.
As this ticket is old, the original reporter never answered Andres questions and the second case seemed to be POP3 related, which we do not support any more, I'll close this.
Looks like there is a rights problem modifying the body of those mails
Every time when we try to modify the HTMLBODY or BODY property we fail with MAPI_E_NO_ACCESS.
The attached mails in those tests where ms-tnef formated (winmail.dat)
omhelp.cpp:lookup_oom_dispid:160 wchar_t alloc 00000155d9abfe80:HTMLBody 07:35:08/5284/oomhelp.cpp:put_oom_string:674 wchar_t alloc 00000155ccf77710:<html><head></head><body><table border="0" width="100%" cellspacing="1" cellpadding="1" bgcolor="#0069cc"><tr><td bgcolor="#0080ff"><p><span style="font-weight:600; background-color:#0080ff;"><center>OpenPGP Nachricht</center><span></p></td></tr><tr><td bgcolor="#e0f0ff"><center><br/>Bitte warten Sie w�hrend die Nachricht entschl�sselt / gepr�ft wird...</td></tr></table></body></html> 07:35:08/5284/oomhelp.cpp:put_oom_string: Putting 'HTMLBody' failed: 0x80020009 07:35:08/5284/DBG_OOM/oomhelp.cpp:dump_excepinfo: Exception: wCode: 0x1000 wReserved: 0x0 source: Microsoft Outlook desc: Sie besitzen nicht die erforderliche Berechtigung, um diesen Vorgang auszuf�hren. help: null helpCtx: 0x0 deferredFill: 0000000000000000 scode: 0x80070005 07:35:08/5284/TRACE/oomhelp.cpp:put_oom_string:699: return 07:35:08/5284/ERROR/mail.cpp:decryptVerify_o: Failed to modify html body of item.
Yesterday
please check if this is still an issue
Tue, Sep 16
Meanwhile we notice this also with OpenPGP Mails. This needs to be further investigated.
Fri, Sep 12
Sorry, I just found out, that windows caps the filename earlier than max length, so my former tests were invalid.
All mails touched by gpgol should already have a GPGOL_UID_DASL. So to replicate:
- Send a new encrypted mail (e.g. Edward -> Ted)
- Don't open that mail, but open the context menu: Move -> Other Folder ...
- Select a subfolder of INBOX and click OK -> the mail is not moved
Thu, Sep 11
Wed, Sep 10
Tested with VS-Desktop-3.3.90.8-Beta and the test gpgol.dll from 2025-09-10 and the same test mail from the original report:
The spawning does not occur any more. (Tested with Outlook setting "show as text only" and without.)
Tue, Sep 9
Still the same behavior as described in https://dev.gnupg.org/T7240#202915 on gpg4win-5.0.0-beta369 @ win10
Mon, Sep 8
Here are the messages and logs, when trying to open them:
Andre mentioned in 10721b1dccf4 that "Closing the mail this early might also have contributed to
endless loops of read + close" which is what we see here as well
Fri, Sep 5
Thu, Sep 4
How to test this? The follwing happens for an attachment of an encrypted mail on gpg4win-5.0.0-beta357, Outlook LTSC Standard 2024 @ win10:
Moving an encrypted message on Gpg4win-5.0.0-beta357, Outlook LTSC Standard 2024 @ win10 into an inbox subfolder of Ted.Tester and back works for me, too. Does this confirm, that it's working now?
Fri, Aug 29
Thu, Aug 28
I think it is save to say that we will not implement pgp/inline encryption with attachments
Tue, Aug 26
The culprit seems to be commit rO6cb4ccf4d8db03e9922984d9c5f5bf7f8806954d but a brief inspection does not show any problematic code. Thus this might be due to an Outlook peculiarity.
Aug 13 2025
The reporter in the forum originally wrote:
Aug 8 2025
Aug 5 2025
Aug 4 2025
Jul 17 2025
We have no solution right now.
In short: A message was saved as an encrypted draft and then the user edited that draft, disabled encryption and then the message was sent out only encrypted to the draft key.
Deselect email and select again (email gets decrypted again) attachments are back.
We should not modify the HTML at all but display it as plain text. Maybe put a a notice at the top:
<!-- Below is the raw HTML encoding of this mail - ask you admin for advice -->
We won't implement that any time soon given that gpgol2 will be an easier plaform to get it right.
It is unlikely that we will fix it. The OL behaviour is just too flaky. It might be possible to do this in the no-preview mode in a more robust way.
I could not reproduce this issue with Gpg4win 4.4.1 and did not see it with Gpg4win-5.0.0-beta345, either.
I could not reproduce this issue with Gpg4win 4.4.1 (which should have it).