You should have received mail with additional log levels now

This has loong been resolved.

That says "Interface not supported" when GpgOL is trying to obtain some data from Outlook. AFAIK this can only happen if the server is either not a Microsoft MAPI server like OpenExchange or KOPANO or so. But even these two are known to work.

Thanks for the report. Some time ago I wrote the code in a way that when setting the HTML body failed it would fallback to the plain body, regardless of the preferences:
So even though there is an error that error is handled. https://dev.gnupg.org/source/gpgol/browse/master/src/mail.cpp;4d57033a095aecf8529606428efef6af466f1196$1488

Argh! I had added the translation to GpgOL but forgot to list the file in our installer. So it will only be part of the next version.

Maybe it helps:
Here is another log from a user with a similar looking problem, same symptoms:

Thanks for the feedback

Ok, I found the message and tried some opening and clicking around w/o any crashes. But back then I also couldn't reproduce it. Please close the issue. I'll ask for reopening if I ever come across it once more. Thanks for your good work!

That would mean I could remember the exact problem. Can you extract the mail name from my logs? I should still have it...

Reopening this as I have seen such hangs multiple times during testing. When importing multiple keys with Kleopatra at once this can be reproduced sometimes.

This works with the message class changing. We still need to do it for OpenPGP, too.

This has been resolved with rOb05416e7bc41

This works now with 0c1bd9076958e584820fadf997ca7d8a248b6888 but needs more testing before this can be relased. It will probably be part of a Gpg4win-4 beta.

I'd suggest to first try the current version to see whether the bug has been solved.

Please try using the current version (3.1.14) and if the problem persists re-open this bug. In this case we will also need a more detailed report.

Please try gpg4win 3.1.14 and check whether your problem has gone.

We should see that we can implement an auto-key-locate feature also in gpgsm. This would allow us to fetch the key as needed from the AD or another LDAP server.

It worked again, attaching the screenshot. Unfortunately had disabled the logging and hence no log info.

No plans to work on this.

Long since resolved.

For linking the MSI installer we already need a windows host and a windows sign host. The binaries inside that package we also sign usign the signhost / signkey which can be included in an optional / custom sign.mk during the build process. By default the path to the included sign.mk is gnupg-vsd/sign.mk in the src repo. But that can be changed of course.

Ah no, this is about the sending part, where we only encrypt to online validated keys, that is not mitigated at all. Disregard my last comment.

This is resolved with the preview feature in GpgOL-2.4.6 Gpg4win-3.1.12

I could find no issue with the error handling for verify errors.

Released with GpgOL 2.4.6 ang gpg4win 3.1.12

Hi Zetrick,

Hi Zetrick,

Further analysis shows that this only happens when async crypt is enabled.

To be honest I have not tried that but it should work because then it has another 50 tries to find a name like "attachment_51.txt" because we stay in the loop.

I'm not sure what to do with the issue. For further analysis we would need to figure out what third party software breaks the MIME structure of the mail. That is more something for a support contract and not for the general issue tracker. This issue is very specific to your setup and so I'm not surprised that Microsoft says it can't help.

3.1.12 was released with this.

Still an issue, just noticed that with the 3.1.12 release announcement, it really looks ugly.

Dear gnupg developers.
I have contacted the Microsoft to get their analysis as well.
A Case #:20812681 has been registered. Where Microsoft stated that third party developers of plugins like GpgOL have their channels and should contact Microsoft directly in cases like this. Further analysis has been denied to me.

Thank you very much for working on this issue.
I think there might be a problem with your fix, if there is a mail arriving with
more than 1 attachment with invalid filenames. I expect all but the last
processed attachment with invalid filename will be overriden by this fix. I
think this will happen very rarely but maybe it is worth consider this also.
Of course I may be totally wrong with my thoughts as I'm not a programmer and
don't know how gpgol is handling attachments in mails.
kind regards
Helmut Häfner

I can reproduce the issue. GpgOL creates a temporary file using the original filename and that fails because the pipe is one of the invalid filename characters on Windows / NTFS.

Thanks,
I edited the task and now you can edit it too.

Hi,
could you please change the edit policy back to all users so that I can change the status of this task?

MAPI Namespace has a pickFolder method which can be used here.

The problem is with the code for T3656

Thanks for the report. I can reproduce this by replying to S/MIME enc & sign mails.

This was implemented 0d2db8b81ab24e2ab02d7ba6832cabd07b72f852 in Gpg4win-3.1.11 but does not work reliably.

Closing with Info Needed.

I'm moving this from testing to open again. Especially the deletion is an issue. I had a report that even for a sent mail Outlook.com also stores an unencrypted variant in the "Trash Bin".

Thought of a way to at least mitigate it. When a mail is closed we know it's not printing.

After looking at this for 4h I could not see a way to detect it better when a print job is done. So we now treat every ItemLoad of a mail after we have seen the BeforePrint event as a print.

Outlook is a bit nasty here:

I'm not sure what to do here. The problem is that all users in clients without PGP/MIME Support will see the attachment names. That is why we use the names as they are.

hello
thanks for the feedback
it s indeed exchange 2007 (migration planned on long term)
we will try the imap workaround

There was a similar Problem in the past reported on our mailing list:

From the commit message:

Thanks, I can reproduce the problem. I'll look into it, printing mails is important for some ;-)