Backported for VSD 3.3

Fixed.

FWIW, a related task is T7308

Alright, we should do that in any case because two key caches are never a good idea and in particualr not if one of them needs too be reloaded too often. Thus re-using the one in Kleopatra is the proper solution. I recall that we looked at this at a time when we already started to design gpgol2 which would solve the problem anyway. However, at least for vsd we need to keep on using the classic gpgol for quite some more time. Thus the effort to improve the key resolving in gpgol is really justified.

The problem is that this is a just a band aid at best. The underlying problem that shows up in other places is not fixed. We should apply the band aid only if we say we don't fix the underlying problem.

Something which has high priority but has not been touch can't have a super high priority.

Either this has super high priority or we fix S/MIME keylistings in GnuPG. I will write a mail with details as that involves customer information.

I see only links to our own pages and to the emailselfdefense - which is a good resource.

Hmm, two years old - I doubt that it makes sense to continue here.

Priority lowered in the light of the the forthcoming gpgol.js

Should definitely work with gpg4win if it works with vsd.

A bit more verbose description would be helpful ...

Closing because POP3 is rarely used and has never been supported.

More than a year old - we can reduce the priority.

Note: The code for this is in the work/mmontkowski branch but has not yet been merged with master. Before we take this bug up again, we need to look closer at the ribbon UI events as remarked by Andre on July 29.

That was resolved with vsd 3.2.0

Fixed together with T6864

Works fine.
For special DOS names only COM/LPT1-9 are supported names like COM12 are not handled.
But that is not really an issue as these names are always prepended with the temp-pathname and c:\tmp\COM12 are valid names.

Getestet, beim normalen wechseln taucht dieses Verhalten so nicht mehr auf. Aber einmalig nach Klick auf weiterleitung dafür neues Ticket T7276

For an additional quick test I forwarded a signed+encrypted mail from KMail as attachment, the mail containing the attachment was a) signed only, b) signed+encrypted.

My recommendation would be to include this change together with the other changes from today even in a minor release since any changes are behind:

I tested all scenarios I could think of with multiple embedded mails and mails which had themself embedded mails. signed, unsigned, s/mime and openpgp.

This is caused by "Mail::removeOurAttachments_o()" to avoid that when you forward an encrypted mail, that the decrypted attachments are also attached as well as the original mail. Same goes for send again.

The whole problem that we now had to take care of marking mails as Read was a misunderstanding of the code. As I assumed since we saved the mail. The property change of "UnRead" would then not be synced to the server, but more testing and user feedback after the last release has shown that the even FC99 which we observed in the "Uncancellable write event" cases was sent to us in conjunction with the property change of UnRead.

This is another side effect of: dd3ff8397aaf62e58fa9405ddc5397cb6bcfdc29 and 1f9c757872b033e1be8199c4d488ac84bf8f07bd before that revision the code that changed IPM.Note.GpgOL.MultipartSigned to IPM.Note.SMIME.MultipartSigned was only executed for S/MIME mails. I do now understand that the code in question at the beginning of decryptVerify_o was meant for other Addins, Outlook Web Interface etc. to ensure that the message class on the server was always IPM.Note.SMIME and not some GpgOL specific class so that outlook or other tools like securePIM would still treat the mail as S/MIME.

This is not a distinct issue from T7242 but the same.

My suspiction with this is that here the exchange server / outlook parses the mail attachment into MAPI and somehow handles mails differently then other attachments. This automatic conversion regarding attached mails is why we always ask users in Support to send us a problematic mail as a file in a zip archive. Otherwise Exchange will convert an attached Outlook MAPI mail to MIME and on the receiving side we can no longer see the original strucutre. Similar things are probably happening on the receiving side where the MIME eml "file" is converted into a MAPIOBJECT holding the forwarded mail which then confuses our internal knowledge about the attachments causing this error.