Well, that is a detailed bug report. Thanks.

Ok. If you can confirm that then it means that my analysis is right. Still unexpected to get an error there. I have to do some more tests with Exchange Online but that would be another issue. If this issue is fixed by turning of debugging then it will also be fixed by my patches.

You are right that Outlook behaves normally if debugging is deactivated.
I had major problems with 3.1.4 and never used it until 3.1.5 came
along, so I guess it might be an existing problem.

While I can't reproduce it myself (because I probably don't have the right mails in my exchange) looking at your log I think that I see the problem there might be an issue with the error handling in openProperty. So for old mails the openProperty probably fails because we have exchange online for that and the property is not yet available in Outlook and then the error is not correctly handled and it crashes.

This should be fixed in commit fd34415bdd57332424bd5a98d279e2331678a2fb

Was released with 3.1.5

Was released with 3.1.5

hm, adding: --with-tar=tar to my invocation of ./configure appears to leave gpg-zip with:

My problem isn´t linked to forwarding encrypted e-mails and / or attachments. It occurs by ordinary PGP mails WITH attachments which are not ASCII format. Encrypted e-mails without attachmoments or in ASCII format will be delivered.

oh! i suppose i underestimated the severity of it. apologies!

Form my understanding this needs to be fixed urgently.

So for me, sending encrypted attachments by selecting them from disk works fine for attachments. up to ~200k (I haven't tried larger ones).

Pretty obvious. Thanks.

I have a warning already in my working copy.

I fixed the gpgrelay link.

"Miranda ICQ [Unix] CHAT" also doesn't work. Maybe it would be a good idea to check all of them via script or something like that...

i don't see any active use of it in all of debian: https://codesearch.debian.net/search?q=gpg-zip

Thank you very much for the quick response and try-out in detail!

Bug or user error?

It is useful if you often log out and in, for example using remote remote ssh session. If you don't like it, you should "gpgconf --kill gpg-agent" in your .bash_logout. ~/.xsession or whatever your system uses. Instead of --kill you can also use --reload so that the passphrase cache is flushed immediately and not only at the end of the TTL.

Thanks. Just pushed the change to master.

Let me also note that gpg-zip was not installed since 2006 due a conflict with gpg1.

gpg-zip is deprecated because we have replaced it by gpgtar. Given that you have a workaround for Debian I tend to close this bug as WONTFIX.

Thanks for reporting your problem. We are highly interested in any crash. But please note that our minimum supported Exchange Version is 2010 because 2007 has reached end of life in april 2017. So I cannot test with that Server.

The corresponding fix can be found here: https://github.com/smuellerDD/jitterentropy-library/commit/9048af7f06fc1488904f54852e0a2f8da45a4745

Please note that this issue in Jitterentropy has been already fixed by upstream: http://www.chronox.de/jent.html

Default settings in Outlook are as following: (i) S/MIME encryption disabled, (ii) S/MIME signature enabled.

I'm lowering the priority as this does not appear to be a general problem. Otherwise more people would have reported it and I can't reproduce it yet.

Strange, even if I take that codepath it just works for me. Just to clarify you are also saying that if you enable "Block Outlook during encryption" it works for you? Which would be doubly strange because in your log I can see that the attachment is detected and due to T4131 we currently still always block Outlook when we detect an attachment.

I'll look into it.

Ok, I will reload the mail item then!

I can reproduce it if I enter your or an unknown IP address.

Thanks for reply.

Strange, I don't know of an issue that is related to that. There were a lot of changes to the DNS code but if you are using an IP. I've tested that using an IP works for me. I used https://192.146.137.99:443 for testing.

Indeed, I use a S/MIME certificate in Outlook for signing by default all e-mails. However, if I intend to send a PGP mail, I manually disable this feature and I manually opt for PGP signature & encryption. I am sure, that this standard procedure applied in this case. Therefore, I am surprised, that the message appears.

It worked as I expected. I've tested it with the run-messenger test and I can close and later "re-decrypt" again. The only surprising thing might be for your users that they have to unlock their secret key again if it is not already unlocked.

Right. While switching the Mail works for me if there are no other references to the mail open (e.g. If I have the mail opened in Outlook Spy switching does not work as the mail is not unloaded). It is better to make it explicit. The code is all there I just have to add a window message handler for it. I'll do that.

Thank you! The beta38 is working for me. Guess the mail->setPassWrite (true); line from the last commit did the trick. I did not need to reload the mail object again.

The problem is probably that you are also holding a reference to the mail in question. For me the close triggers an unload so that GpgOL completely detaches from the mail in question.
I've now added a more explicit tracking of when it should be allowed to write namely after our close with discard changes.

I tested these window messages with the provided beta build. Both messages gets processed and the e-mail is encrypted again but I still receive the 0x80004004 (E_ABORT) error when trying to save the message via the outlook api.

Marking this as resolved as it was forgotten in the testing state.

I think this is resolved by kleopatra's watchdog. There is a bug that the agent becomes unresponsive somehow then the loading also hangs but this is unrelated to kleopatra.

I've added two message handling routines and a small program to test it (run-messenger.cpp) You can use run-messenger.cpp for reference.

To reproduce it the key is to close Outlook through the file -> close option.

In the log I can see where it uses a non default codepath:

I don't think this answered my question -- i'm asking how adding --no-keyring affects gpgme_op_decrypt_verify -- it seems like verification would fail if no keyring is used, no?

gpgme_op_decrypt_verify can always be used instead of gpgme_op_decrypt. This is an obvious requirement because the signature and the fact that there is a signature is only known after the decryption step. The newer GPGME_DECRYPT_VERIFY of the gpgme_op_decrypt_ext function is basically an alias for gpgme_op_decrypt_verify.
For both functions gpgme employs "gpg --decrypt".

I'm fine with this change, but i do note that some people expect --decrypt to mean "decrypt and verify, if possible". In particular, gpg(1) says about --decrypt:

Hi sorry, here it is. I don't see a recommended way for providing a ton of text, so just pasting it here.

Ok. Thank you for sharing informations!

Yep, I can access this property.

Please provide a complete build log or at least the output of the configure run.

So maybe closing the inspector, too is necessary here so that the real close / unload on the mail is triggered. But it might just be that Outlook immediately reopens the mail in your case. Then it won't help but I think you should try that, too because any Interprocess communication will be more effort.

It happens with 3.1.4, too.

Works nicely now. I added a "yellow" warning to indicate that the message is a crypto message that can't be handled by GpgOL in the Junk folder. I see no way to actually decrypt in the Junk folder as we are not allowed to access attachments.

In T4241#119944, @msc wrote:

I wonder if it would be possible for you to close the mail / inspector of the mail with DiscardChanges before doing a save as?

Discarding changes with the Close(OlDiscard) method has no effect on the issue.

or, more accurately so it matches the C api, perhaps gpg.constants.import_status

Yes that is expected, we block the save event as long as we have replaced the Body / Attachments of the mail with decrypted contents are shown. In our debug log you would see the message "Canceling write event".

Yes, I can confirm that log entry.

Yes I see the problem and have a fix for it. I'm just trying to make it nice now :-)

Yes, I also can't decrypt the files there. As Outlook warns about
restricting access to attachments and active contents, the reason is
clear. The mail must be moved elsewhere.

I can reproduce that it won't be moved.

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.

A wait, we have T4203 for the continuing problems. So let's close this.

This was likely one form of T4111

There is still at least one report claiming that this still happens for large attachments. I could not reproduce it.

This was fixed with the Gpg4win-3.1.4 release. Apologies that I forgot to mention a pre release version / installer in this issue.

I've tried to reproduce it but failed. Even If I open the message in a new window or a new explorer the message is correctly caught.