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 ;-)

Does it decrypt then?

This is not the first report I have gotten about mailstore problems. My suspicion here is that the mail is opened read only or somehow got the wrong properties from mailstore.

FWIW, a log of the decryption process will always show the sender's key because a message is usually also encrypted to that one (--encrypt-to).

Done in master

I think that this chnage is useful enough to be backported to 2.2. Done that.

You can test it now out using GnuPG master: Just add --include-key-block and you can then verify using an empty keyring. Currently --auto-key-retrieve is not needed but we need to think on how we can enable or disable this during verification.

This is now implemented

ftr, here is the thread I had in mind but couldn't recall above. @aheinecke is that your thinking, or a more pgp/mime bound mechanism as @dkg assumed?

@wiktor-k, "just extend the spec" doesn't necessarily work with existing clients, which might be surprised to find unexpected packets in the signature section of an e-mail. It seems more likely to me that they'd be able to handle (meaning: ignore) an unknown subpacket (as long as it's well-formed) than to handle additional packets. But all of these surmises require testing with existing clients, of course. Has anyone done any of that testing?

This is a nice idea and although it overlaps with Autocrypt it has other uses too: for example verification of signed files that can be vastly simplified (just get the file and the signature, no key fetching needed, downside: the key attached to the signature could be stale).

Ah, thanks for pointing out the subpacket option (i guess it could be hashed or unhashed). i don't think any of the subpackets currently defined in RFC4880 supports this use case -- but i guess you could mint a new one, or use a notation.

Werner said that it's possible in OpenPGP to also put the pubkey into the signature. (...) The nice advantage is that this will also work for files.

Hi @aheinecke, thanks for thinking about this, and thanks for tagging me here too. I'm definitely interested.

For the split OpenPGP / SMIME it's not intended to only work for BCC, its just the same mechanism I use internally.

I think this is a great feature to have. Thanks for working on it, @aheinecke .

The idea of the implementation is that BCC recpients will get a mail with no other recipients. Because Exchange / Outlook handles the sending we can't do it more low level. We use the "Protected-headers" scheme to transfer the original To / CC headers.

I renamed the ticket so that others don't think we generally don't support Office2019 because I use it myself and it works for me.

Thank you for the detailed report.

I remember that I tested inline content-disposition handling in Outlook without GpgOL and try to do the same handling as Outlook would handle them. But then at the very least It should be shown as an attachment and not hidden.

I've just tested this with GpgOL 2.4.6~beta3 as well, and while the i see the same issue :( (though the legacy display part is not shown, thanks to your fix of T4796).

Thanks! taking screenshots is definitely tedious. I just redid the screenshots for all the sample pgp/mime messages with GpgOL 2.4.6-beta3, and i can confirm that it looks like you've resolved the matter.

That means that the GnuPG Backend does not work. I do not think that the office update is the reason, me and others use GpgOL with the most recent versions of Office Pro Plus without issue.
Have you possibly modified you gnupg config files? If there is a bad value in there it would result in such an error.

It can force it on the outbound. https://support.symantec.com/us/en/article.tech164655.html
It also allow SIMME pass-through. https://support.symantec.com/us/en/article.tech166867.html

An updated build is available here: https://files.gpg4win.org/Beta/gpgol/2.4.6-beta3/

thanks for the fix, @aheinecke ! can you post screenshots of the changes? or do you have a nightly build i could test?

I have checked the eMail header of the eMail from Sender X in the Exchange mailbox of User A and I see Sender X is using Mozilla Thunderbird and I tested it with Thunderbird also, but it works for me.
I cannot provide all details of the eMail from Sender X because it's a customer of another customer, but I have replaced the IP addresses and other private information in the eMail header and this is the result:

thanks for the report. This is definitely a sore spot and we need to look at it again. I did some experiments a while a go trying to fix this issue but so far I was unable to get to stable results so for now this is a known issue.
I'm a bit suprised that the workaround with not having the mail open does not work for you.

Is this about any special version of Symantec? As far as I knew Symantec Endpoint Security Desktop (or whatever they call it nowadays) supports reading PGP/MIME and even sending it if forced.

This again,...
That error always occurs when the Exchange Server is unhappy with the structure of our PGP/MIME Mails. It has nothing to do with S/MIME, that is only because Exchange only knows about S/MIME, so our PGP/MIME Mails also claim to be S/MIME mails.