header is incorrected when it's quoted printable unicode

[schmitch]

Describe the bug
hello we have a vsto plugin where we convert our mail via a Mapi conversion directly in outlook and than we feed the message to MimeKit, however the message than contains a header like: Subject: =?unicode?Q?Test?= however the subject is now completly incorrect and it will print chinese letters, if I change it to =?utf-8?Q?Test?= it will work.
I'm still not sure if we are using it wrong, however there is just no way to get the correct charset

Platform (please complete the following information):

• OS: Windows, Linux, MacOS
• .NET Runtime: [e.g. CoreCLR, Mono] CoreCLR
• .NET Framework: .net4.8 / dotnet 6-7
• MimeKit Version: 3.1-4.0

Expected behavior
correctly parse the header as valid characters.

we basically only do the following:

var mimeMessage = await MimeMessage.LoadAsync( stream, false);
Console.WriteLine($"Subject: {mimeMessage.Subject}");

Test E-Mail:

MIME-Version: 1.0
Date: Mon, 5 Jun 2023 16:50:30 +0200
From: example@example.com
To: example@example.com
Subject: =?unicode?Q?Test?=
Content-Type: text/plain; charset="utf-8"

Test

it's probably a outlook bug, that it encodes that not in a correct rfc style, but maybe I'm overseeing some things which would make this work

[jstedfast]

The reason you are having problems is because the charset name unicode maps to UTF-16, not UTF-8.

The problem is that unicode as a charset name is ambiguous. It could mean UTF-16LE, UTF-16BE, UTF-32, or (as in your case), UTF-8 (it could arguably even mean UTF-7).

.NET maps unicode to UTF-16LE (as it probably should).

[schmitch]

is there a way to change the behavior? since at the moment we only use it with outlook which will somehow return these as a header?

Edit: I already tought that something like this was the case, because in Outlook for Windows it's correct, but in most other clients it prints chinese characters... sadly there is no way to have a way to convert the msg to a correct eml.

[jstedfast]

Just forced the alias mapping. Hopefully I'm not breaking anyone but I suspect that UTF-16* is rare in email (I've never seen it personally) and so that "unicode" is more likely to map to UTF-8 than UTF-16.

[schmitch]

maybe if it breaks stuff, there could be a flag, because https://learn.microsoft.com/de-de/office/client-developer/outlook/mapi/iconvertersession-mapitomimestm will always use unicode, besides that the original header is =?utf-8?Q?Test?=. parserDefaults.UnicodeCompat = true or something