Ok then we can resolve this. Because I don't want to change the code there too much since it is about a plaintext leak which we cannot reliably reproduce so any change there we cannot really test if it brings up the plaintext leak again. And for users that have problems with the changing of the mail we can point them to the workaround.

The debug/workaround option works: When the option is checked, opening the msg file will not change its date.

The new "no 509 certificate" message box comes up always when restarting Outlook and then immediately composing and sending a message, even when the user has a certificate.
-> add a check if the cache is already loaded in GpgOL

For the Berta Key in the Testversion: *After* entering the Password for the signature, the new GpgOL message does show. When I choose "Retry" in spite of the warning, the mail is send out encrypted.
So I was only confused because I did expect another order of events. Something seems redundant and confusing here:
First you are shown the security confirmation dialog an click on OK (with the small warning sign and "not compliant" next to it), then you are asked for your password (if it is not in the cache) and then you get the new Warning message with the option to "Retry". Although you already in the first dialog chose to encrypt non-compliant.
Btw: The error message from gpg is for me not "end of file" instead it is: "Syntax error in URI"

If I repeat this with a totally empty keyring, I get the new message regarding the missing signing certificate.

With this certificate I do get the security confirmation dialog without "always show" on, but still no new message box.

Yes, the wording for this line should be improved, I agree.
In the current release and the releases up to now this action did not work at all when it was not used in combination with encrypt. That usually happens only if an administrator activates the "always_sign" option, prefers S/MIME and then does not issue users with S/MIME certificates. For OpenPGP we have the "Generate" option preselected in that case.

Without "always show" I get a pinentry immediately after hitting "Send". So no warning.

In T6683#176424, @ebo wrote:

I realized that I still had "always show confirmation dialog" on... When I turn that off I get the default error message, but with encoding errors:

I do not see the default error message, not even with a new, totally empty keyring.
I immediately get:

For sent mails folder there is no solution. The problem is that if the mail never leaves the exchange server it is not converted to a standard compliant PGP/MIME but left in Microsofts internal MAPI format where it looks like this. I think thunderbird has support to fixup a message if the mimetype of the first attachment application/pgp-encrypted. Which reminds me that we need to change the filename of our internal attachment, too to use .mim as an extension. Then you will at least also be able to open such messages on other clients with Kleopatra directly to view the contents of the mail. And a side effect of this might be that Enigmail might then be able to open the mails. If not we would need to talk to enigmail how to solve this.

This can be resolved I tested this myself and gave a beta to the affected customer which also worked for them

There has been another report on the Gpg4win Forum which might be related that mails now cause endless syncs and might even break further when they are saved back to the same exchange server as there is no MAPI to MIME conversion done anymore and other clients cannot read the mime structure.

that's really cool :) .. I tested now with a mail whole having the Warning message, I press "Show Mail" and it indeed open .. see the pic.
very nice feature indeed.

Meanwhile, can you please share how to use the new feature "open the mail from the Kleopatra menu" would be nice to test it.

The most difficult thing here was to actually support the case where the user then sees the keyresolver dialog and selects "yes i do not wish to sign" this never worked.

Thanks a lot Andre ... I believe it's solved.

Now when I try to encrypt to expired certificate this message comes up:

So the default error is now:

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.