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.

Possible workarounds:
- 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).

For transactional mails, we sometimes want to replace the sender name only, so instead of sending with the organization's name, we show the name of the person who has sent a message to the recipient in out application.

Instead of sending from

Organization noreply@organization.com

We want to send from

{{var:name}} via Organization noreply@organization.com

I found out the hard way that although template variables can be used in the subject, they lead to an error when used in the sender name field. Internally, this creates a new sender address and an administrator will receive a mail that that (invalid) address should be verified.

In order to fulfill the requirements stated above, we now have to set the sender email address and the dynamically replaced name in the app and send both the from field in the call to the Send API.

It would be easier to do one of the following

• Allow for variable replacement in the template configuration for the "Name" field in "Email and sender details"
• Allow overriding the from.name in the Send API call and leaving the from.email empty.

Hallo, könnten sie bitte bei den Wehooks ein Feld
from: Absender der Email
hinzufügen.
Bisher gibt es nur den Empfänger:
email: email address of recipient triggering the event
und
mjcontactid: internal Mailjet contact ID
Dies ist aber nicht der wirkliche Absender, da es auch *@domain.de sein kann.
Der tatsächliche Absernder ist sehr wichtig um Mail entsprechend zu bearbeiten.
Danke.

Hello, could you please add to the wehooks a field
from: Sender of the email
to be added.
So far there is only the recipient:
email: email address of recipient triggering the event
and
mjcontactid: internal Mailjet contact ID
But this is not the real sender, because it can also be *@domain.de.
The real sender is very important to process mail accordingly.

It would be great if we could delete all of our emails in your queue via API.

We had a bug in our software and unfortunately had to watch how emails were processed again and again, which we wanted to delete in any case. Unfortunately, our hands were tied (we did not reach your support either).

Specifically, we kept running into a send limit (even after adjusting our service plan) because it was always the same emails to the same recipients. Of course, these were all blocked by you (fortunately).

This would not happen anymore with the described feature. We would then be able to stop all emails in case of an error or indications of a critical dispatch and resend them after clarifying the reason.