Properly handle headers encoding when the target MTA lacks SMTPUTF8 and the client app uses UTF8 when sending to mailjet
When enabling UTF8 support between the client app and mailjet SMTP API, the client library generally encodes SMTP headers like the Subject using UTF8 rather than quoted-printable + US-ASCII. So when using any UTF8-ready SMTP client library (in our case the SmtpClient from .NET 6), a Subject like "Caractères accentués" will be sent to mailjet as "Subject: Caractères accentués" when UTF8 is enabled (SmtpDeliveryFormat.International in .NET), and "Subject: =?UTF-8?Q?=Caract=C3=A8res_accentu=C3=A9s?=" when it is not (SmtpDeliveryFormat.SevenBit in .NET).
This is correct behavior from the client library, but there is an issue with mailjet when the recipient MTA does not support SMTPUTF8 itself: mailjet just forwards the headers as it received them in the first place, including the Subject encoding (i.e. mailjet sends a UTF8 Subject header value to a MTA that does not support UTF8). This results in broken subject messages in the recipient's mailbox (non-ASCII characters are replaced with "???", so in this example the recipient sees "Caract???res accentu???s"). This happens with the few email providers that do not support SMTPUTF8 (iCloud, yopmail, or any MTA using Postfix < 3.0).
One odd thing to note is that mailjet DOES reencode the Subject header using quoted-printable + US-ASCII when it contains the "[" character, meaning "[test] Caractères accentués" will be correctly displayed in thoses mailboxes whereas "Caractères accentués" will not. The correct behavior would be to reencode the Subject header if the recipient does not list SMTPUTF8 as a supported extension, instead of reencoding it using the current logic.
- ignore the issue - most mailboxes support SMTPUTF8 (iCloud and some self-managed mailboxes being notable exceptions) ;
- always include the character "[" in your email subjects (e.g. use "[xxx]" prefixes) ;
- disable UTF8 encoding in the client app (use SmtpDeliveryFormat.SevenBit in .NET) - however this means UTF8 email addresses will not be supported ;
- keep UTF8, but force the Subject header to be encoded using quoted-printable + US-ASCII - this might not be possible depending on the level of control your SMTP library offers (e.g. this is not possible using the SmtpClient from .NET).