This was now added as disableAutoPreview (the option was renamed after 26c2fc196bb73d9bd96c91ea7cc12679d925b376 )

Since codesigning for all dlls was added this is fully resolved.

There won't be improvements to PGP/Inline

The status of HTML Mails is noted in T6333 everything else here does no longer apply afaik. Although mailstore has since been known as an incompatible addin.

Forgotten to resolve the issue when fixing it.

I have fixed this as a7349189f3af05822eba4bd17b62482fa2b0747f so I am closing this as a duplicate of T5982 because it is clear to me now that the problem was sending and no receiving such mails and was broken by 9f81ed6561c5f41e50d1a51333c9586a33ed2ef6

I mostly receive HTML only mails from automated mail systems.

Sorry, what I meant by this was just 9316d458d509dd0237a6bb82109c0f48549c3e59 which I added to T6582 instead of this ticket

This was fixed by c0ca4f1b254f6879d719d1a5ed43a51ca9015b93 since the embedded message was not handled it was not extracted / parsed into an Attachment C++ Object which caused this error. I don't want to change the status of tasks which are not assigned to me but i saw it while looking over my open assigned tickets.

I misunderstood the problem. On the receiving side this was already fixed by me in 2019 9a9fe4e7fcad92bfba49ade9a6c44373f170ccd2

Closing since the cause for this was identified.

Maybe its overthinking the problem of attachments with content-id but no reference in the HTML (btw. if mails are shown as plain text all attachments are listed regardless of their content id. ) I guess code like: if filename.endsWith(.png) || filename.endsWith(.jpg) || filename.endsWith(.jpeg) then ignore_cid=false; else ignore_cid = true. Would do the right thing 99% of the time. Core reference: rOd87848059727587be1f660283e0aeb3be16cc382

I assume the problem has been resolved because we never got feedback that the problem persists.

Please ask on the forum or a mailing list for help.

Gpg4win-Beta-70: This works now, the issue can not be reproduced any more like described

This is no longer possible. The sign/encrypt button is disabled and an info box is displayed.

When I last talked about this ticket I had not thought of the fact that we need to have this in some kleowrap wrapper and that currently stdout and stderr are not printed in a process which forwards its call to an already running kleopatra.

I thought about this and any change here has a regression risk and the release is already overdue. If we change this now as a band aid before a release with keyboxd we really need this only for one release.

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.

This works now.

I am observing strange beavior on WIndows 10 22h2 and OL 16.0.17830.200056 even if no mail is displayed in the reading pane and the selection returns no selected mails, Outlook loads mails which are e.g. right clicked. I think a way which could prevent some problems and allow it again to change flags and categories for unselected mails would be for us to check in the Read event if the mail has some inspector and abort in that case. This could also increase compatibility with other addins. I will do some experiments with it.

I understand the problem now. The difference between my test yesterday and today was that I had disabled S/MIME support in my GpgOL. Since T7243: GpgOL: multipart/signed OpenPGP SMTP transfered mails are displayed as S/MIME is an issue that makes GpgOL think that it is looking at an S/MIME mail but S/MIME is disabled, it tries to write back the mail to the server in a way so that Outlooks internal S/MIME support can parse it on the next run. In the log you see:

Today this was reproducible for me, too. Not sure what the difference is yet to yesterday I could see in my logs that this time the mails were never completely unloaded so that might be a reason. But we cannot rely on that. So reopening mails must work of course even if the mail stays open. (Good to simulate by keeping outlook spy active on the mail when loading and unloading).

I cannot reproduce the duplication, there are probably errors in your log regarding that close / discard changes failed or something like that in this case as we leave the original message intact and only add the extracted mime parts as attachments and replace the body with the text mimepart. It would duplicate that when it would "reverrify" a mail that already went thorugh all this. But it is meant that while the mail exists in outlooks memory that GpgOL tracks that, too and so does not decrypt the same mail twice. What I can see is that multipart/signed without encryption is somehow parsed as S/MIME initially. This looks like some new behavior in Office 365 or recent versions of Outlook when the message class is changed to an S/MIME Message class. Which we do to get unmodified access to the MAPI structure. From the data objects looking at the mail in outlook spy:

As I could not reproduce the issue with different builds I realized that I was compiling and linking GpgOL for development using a very different version of winpthread.
When I switch to a consistent build and runtime library the crash no longer happens. I wonder if we can maybe statically link winpthread, too. But I think that is coming from Gpgme++ since GpgOL only uses windows threads.

I added some comments to the commit. But

Markus this ticket I find important as it has much user visible impact. While VS-NfD secops say you "should" not use H TML mail, most users and basically all non - VS-NfD users use the default of outlook anyway and use HTML.

We have solved this now by showing a configurable error message in that case instead of hard failure with a cryptic error in T6683: GpgOL: Configurable error if sign is selected and prefer_smime

A better solution might be to use categories to have that element "this message will be signed / this message will be encrypted" above the edit window. But what I find more important and so much more a high priority is that in cases we have a failure saving the draft info flags an error message should come up. This happened for a customer and in the logs I could see that MAPI returned an error. the button was not toggled in this case but the mail also was not marked for encryption. T7144 is the task for that so I'd suggest to start with that one.

In gpgoladdin:

Changing the icon is unusual and does not match a native look and feel in Outlook where toggle icons are there for a reason, to be toggled or not. This is also the way how Outlooks native encrypt & sign works and Microsoft will probably have thought about this a bit.