I found the rfc https://datatracker.ietf.org/doc/html/rfc2231.html the code to decode this is not fun and can be found here: https://invent.kde.org/frameworks/kcodecs/-/blob/master/src/kcodecsqp.cpp

@ikloecker I think your logs contain only false positives, I do not know that we use any defines created by config.h. Maybe for gpgme_off_t but even so when I moved gpgme++ and qgpgme from kdepimlibs into the GPGME repo I did not add any defines to configure for that.

Fixed with c6e16e403744ca39a24a38f38264865019c0cb93

Hi Carl,
yes I saw that test case. Btw. I don't really think that this comes from Outlook itself otherwise I would have seen this much earlier, the current MIME Parser in our Outlook Plugin is about 8 years old. Currently this comes through some kind of AppleMail (server?) application to the customer.

Applied to master.

Applied to 2.4.

Applied to master.

To be honest I have never seen such a way to transfer parameters but KMime and our new MIMETreeparser in T6199 can probably handle them but our old and trusty RFC822parse code in GpgOL needs to be adjusted.

This works, there is only one gpgsm process at a time while importing a dozen S/MIME certificates at once.

yes, one down, two to go...

signing works, too

follow up of T6517

works (I did only check the first 2 criteria)

I have built it according to the method described here.
(https://wiki.documentfoundation.org/Development/BuildingOnWindows)

Meanwhile the AppImage (same binaries as the current Gpg4win version) can be found here among the binary releases: https://gnupg.org/download/index.html

I can't find a missing forward port; need to debug this issue with gpg4win 4.2.0

I wonder why you mention Visual Studio and Cygwin? Either it is Cygwin or a native Windows build.

I realized again how bad the current implementation is last week when Alexander managed to send a mail to me encrypted with a completely unrelated key.
a) It was not clear to him that he encrypted to a totally different key because it only displays the keyid
b) He somehow managed to store that key for me in the addressbook
c) He again selected something like "always encrypt to this user" in the dialog without realizing the consequences. This created a contact for me in his personal address book (invisible to him because he said he does not use the addressbook and in there all sources were unselcted) which had the wrong keyid (again only the fingerprint there) and the setting "always encrypt to this user"