Page MenuHome GnuPG

Windows registry option to prevent modifications to signed/encrypted messages after validation by GpgOL
Open, WishlistPublic



After verifying a message or decrypting it, gpgol wants to update the message, for example to save a green category,
as visible on the given screenshot

This category and other changes on the message performed by gpgol will trigger an update of the original message. Exchange can deal with this update easily, but we are developing an alternate mapi-http implementation using an IMAP server as its backing store. Emulation the mutability of exchange messages over an imap server is complicated tasks and we would like to know if a "read only" registry option in gpgol already exist or was feasible.

I can easily understand that improving gpg4win compatibility with bluemind and its mapi endpoint is not a priority. If you could point us in the right direction in your addon code we could provide a PR for a read-only option when opening messages.


gpg4win 4.0.0

Event Timeline

The problem is that we replace the encrypted text and attachments with the decrypted / verified parts. This would already be a modification even without such changes like the category.

I wonder though if it is only some changes that are problematic? We do most just in the outlook object model and try to avoid sync back to MAPI as we do not want to have the plain text synced to the exchange server. But we do some changes to MAPI, like changing the message class and setting some flags for us. If only these would be the problem we might be able to avoid them. Although the message class change is very hard to avoid. The code for the modification is mostly in the parsingDone function$1876

But replacing the mail contents itself is very deep in GpgOL, reworking it to work on something like temporary copies would be a major refactoring.

aheinecke triaged this task as Wishlist priority.Feb 23 2022, 6:09 PM

we replace the encrypted text and attachments with the decrypted / verified parts

That's what I feared, but it seemed like a security issue to do that as the mailboxes could be shared to others.

I guess most users of this addin are using IMAP accounts and it's fine there : only the cached copy inside the mapi profile is updated but as messages are immutable in the IMAP store, the "save" function is a noop there.