Maybe its not a com addin but one of the New JavaScript webapi addins? They have a different menu to disable. Definetly not an outlook feature its this protectit thingy. But have you now Trierdto open the mail from the Kleopatra menu? That is the cool New feature we are currently working on.

I disable all Addons (see screenshots) and restarted the Outlook, but still getting the same warning when trying to open the email.

Ah wait, in the first of your screenshots it is obvious which addin is modifying your mail so that we don't see it as an encrypted mail anymore. It is that warning text from the protection Addin that you should report that mail if you are unsure where it came from. That would cause such problems because when it inserts this text the type of the mail is changed and it is no longer detected as an encrypted mail.

There in the last screenshot on the right. Btw. since the mail you sent me with the ZIP archive looked also fine to me, there might be another problem here. Could you try disabling your other Addons in Outlook temporarily and check if that might solve the issue? Other addons are also often a cause for some unusual client behavior. You can do that if you go to File -> Options -> Add-Ins -> Manage COM Addins, and then unselect others just for a test.

this is what I'm getting when trying to open the mail then the attachment. Am i missing something?

strange, your test mail in the attachment decrypted for me, too. What happens if you now use the "Show EMail" button?

Tested on the command line with

• a previously valid certificate after setting its root certificate to untrusted
• a expired certificate without the root certificate in the certificate list

I've installed the Beta version, but issue still exist !!
My encrypted mails are readable by the other party, while I can't read his mail giving the same error msg "Decryption succeeded ......... Note: you cannot be sure who encrypted this message as it is not signed" , while I can read my sent encrypted mails.
see attached.
Any suggestions?

Thanks .. will try it now

Please try: https://files.gpg4win.org/Beta/gpg4win-4.2.1-beta55/gpg4win-4.2.1-beta55.exe This should solve your problem. And if not you can now open the encrypted attachments with Kleopatra and it will show your mail.

Working on both. Beta will come later today, I had one on friday but did not upload it yet and need to recompile it first.

Hi Andre,

Thanks Andre for your response..

I am pretty sure that we can fix that issue and have a beta for you maybe even today or tomorrow. But afterwards we should talk about your company actually using a product with professional support (which you are getting right now from me) like GnuPG Desktop. Gpg4win is basically only "goodwill" support.

I tested once more with another person, issue confirmed, he can read my encrypted mail (as you did), however, I can NOT read his emails (with the same error: you cannot be sure who encrypted this message as it is not signed)

Yes, I can decrypt my sent mails, in my Sent folder

To say this differently, the problem fixed recently which Relaxed detection of encrypted mails might still fix your problem. But the "corruption" of the mail which makes it harder to detect as a crypto mail for GpgOL does not happen when you send a mail, it appears to happen when you receive a mail.

Received, but it is not the same problem at least on your side. Your mail looks perfect. It would have been handled by any version of GpgOL on my side. So I think it is the receiving side meaning your incoming crypto mails are modfied by some middleware in a way that GpgOL does not detect them as crypto mails anymore. But before we debug more here with logs for you, let me finish up some other work on GpgOL and I can probably give you and some others in the tracker here a beta this week where we can then confirm if its already fixed. I'm currently actively working on GpgOL.

I sent the test encrypted email

Thanks once more... and appreciate your swift response.

Yes the resolution in that issue is "I have fixed this, you need to wait for the next update." The comments above explain the problem, the mail is modified in transit, if you change something there then you can maybe workaround in the meantime. The exact comment I linked gave the instructions on how to assist with analyizing this issue. If you would follow them I could also tell you for sure weather or not this is your problem. https://dev.gnupg.org/T6686#174856

Thank you for your reply.

Ok. Let me unpack this for you. I think your problem is that now since you switched to your new domain the mails in Outlook are no longer directly decrypted, then you open the attachment and get this message.

I am closing this, for now as this issue lacks actionable details, we would need an example mail or debug data. So my intent is just to close it and reopen if the issue still occurs with Gpg4win-4.2.1

Noticed this issue while searching for a different one.
I think this could be fixed with T6686 if it has not already been fixed by a previous change that relaxed the detection of the encrypted message part better.

For another user this change caused endless syncs. Since I do not yet see a way to fix this without risking again that the plaintext leaks to the server under some circumstances, because the problem is that I still do not know how to reproduce these circumstances, my plan is to at least add an option in the debug tab of Kleopatra to disable this "save back" feature.

Another customer case with "always show security-dialog" on (-> external resolver):

I have analyzed this. In the ribbon we get a mailitem OOM object as reference, but that can be a different pointer then the one we used for decryption / verification. Our trick for this was to assign mailitems a custom uuid property and then look for that from the riboon pointer so that we can update accoringly with our internal Mail object representation.

Changed the task description to easier find it

Ok. Thanks for testing. That confirms my suspicion. rOdd3ff8397aaf62e58fa9405ddc5397cb6bcfdc29 is to blame here with the setReadFlag line as the specific cause. Because it is intended to trigger a save back. The problem was that we had circumstances where other addins changed the mail and really wanted it to be saved back to the server. So we call "save" before decrypting the mail to ensure that these changes are saved and then we decrypt, put in our temporary plaintext and ensure that the plaintext never is saved.

I testet it with 4.10 and GggOL 2.5.6. The file isn't changed if I open it. So it seems the change happend in 4.2.0.

Do you know if this is something new that started to happen with 4.2.0 for the first time or did it happen with 4.1.0, too?

Not really, the GnuPG System configuration settings are generated from gpgconf output and there is no tooltip mechanism for that.

we could include the "better explanation" part, though. The options in "GnuPG system (technical)" do not have a tooltip, we could add one there, at least.

This won't go into the next release it is too invasive and needs to be very thought through and announced to users. This also needs to be deployed in a Gpg4win first to get user feedback. GpgOL is pretty much done for the summer release of GnuPG VS-Desktop.

I am reopening this at least for testing as we have reports that another client is facing the issue with recent versions and also with verified mails .

This fix was pretty minimal and I could test:

This works now for me and all the examples I have for the customer. With https://dev.gnupg.org/rO0fc4b87a946dd634d4b61d4e8cb0ad6164faa83c it looks to me in KMail like KMime might handle the transition between different encodings / languages not correctly in continued parameters.

I won't go so far to try to fully implement RFC2231 in the rfc822parse. But I have an idea how to implement this in a secure and robust manner in rfc822parse without touching the parser or the token stuff. My idea is to treat them as seperate TOKEN and then combine them in query parameter just for name and filename values.

I found the rfc https://datatracker.ietf.org/doc/html/rfc2231.html the code to decode this is not fun and can be found here: https://invent.kde.org/frameworks/kcodecs/-/blob/master/src/kcodecsqp.cpp

Hi Carl,
yes I saw that test case. Btw. I don't really think that this comes from Outlook itself otherwise I would have seen this much earlier, the current MIME Parser in our Outlook Plugin is about 8 years old. Currently this comes through some kind of AppleMail (server?) application to the customer.

To be honest I have never seen such a way to transfer parameters but KMime and our new MIMETreeparser in T6199 can probably handle them but our old and trusty RFC822parse code in GpgOL needs to be adjusted.

Fix pushed to the 23/07 branch and master.

I am raising this up from the wishlist. Error messages from CRL errors can be so obscure, like we just had in a support call.

I noticed this recently, too. Should be fixed. Especially if we want to use this in KMail, too.

No, it doesn't do even that. Sorry, I only tested that with 3.1.26 which is older than your fix.
No encrypt-only key is offered or selectable for signing any more in Gpg4win-4.2.0-beta360

I don't think that Kleopatra allows to select an encrypt-only key for signing because I have fixed exactly this issue a couple of months: T6456: Kleopatra: Offers encryption-only OpenPGP keys as signing key.

This works, when sign is selected and no standard OpenPGP key for the mail address exists.

This will not translate into the new addon and is too large a change for the current one.

This no longer happens. It was a case of such inline signature images. Maybe if they are added through the clipboard they dont get a filename or something like that.

Works good enough for me

Fixed with: 8e258f77114ce0474a2bb6aa1314385e2fb68e15