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.

Can confirm KMime handle this correctly :)

There is a test case for this in KMime https://invent.kde.org/pim/kmime/-/blob/master/autotests/data/mails/outlook-attachment.mbox which render correctly in the new mime tree parser ;) The test case is 9 years old but this syntax seems to be only used when the filename is using utf8 characters which might explain why this issue only appear now.

I can try to take a look at GpgOL and fix it, unless the short term plan is to use the new mimetreeparser anyway

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.

While I find the

name*=....

Irritating and would like to know how this is called and where the RFC for this is, I find the second case more difficult to implement:

name*0="Some long filename without any special characters but just a very";
long filename that is continued here";
	name*1=and then in a second parameter.pdf;

And for that I don't think KMIME has support currently.

I have the example mails from the customer in the binary outlook format. I will try to extract the MIME structure for testing and then create my own test mail which we can then add to KMIME / MTP, I would like to have them signed though. So I will probably hack my GpgOL version to produce such mails. When I have the examples I will attach them here.

For the c++ GpgOL the mimetreeparser is not an option. Its plain C++/C without Qt. We are currently basically using GnuPGs own https://dev.gnupg.org/source/gnupg/browse/master/tools/rfc822parse.c so a fix needs to go there. And TBH. I currently I have no idea how I can fit the second case in the architecture 🤔

name*0="foo"
name*1="bar.pdf"

In a way that I can later just rfc822parse_query_parameter("name") there.

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

I won't go so far to try to fully implement RFC2231 in the rfc822parse. But I have an idea how to implement this in a secure and robust manner in rfc822parse without touching the parser or the token stuff. My idea is to treat them as seperate TOKEN and then combine them in query parameter just for name and filename values.

Something like pseudocode:

if (param == name || param == filename)
  result = check(param);

if (result.empty())
  result = check(param + '*');

if (result.empty())
{
int i = 0;
do {
   foo = check(param + '*' + i);
   result += foo;
} while (!foo.empty() && i < 10)

Assuming that "check" already does the rfc2047 parse for the different parameter encodings.