DKIM signing failing on non-UTF-8 content

get-help
1

I just stumbled on a a few mails encounter technical difficulties when trying to forward the mail from postfix to kumomta for the final sendout. The mail itself is an NDR report where the DKIM signing is failing on. The content is rather simple and slightly edited to anonymise:

[Error Message]
Mail Address : <receiver@domain.com>
Your mail is rejected by email address ("���� ����" <sender@senderdomain.com>)

And as you can guess the weird question mark thingies are the culprit.
The KumoMTA logs show this:

20250114-001516.407407936:{"type":"Rejection","id":"","sender":"","recipient":"","queue":"","site":"","size":0,"response":{"code":421,"enhanced_code":{"class":4,"subject":3,"detail":0},"content":"smtp-out2.domain.com technical difficulties","command":"Error in SmtpServer: DKIM signer: message is not ASCII or UTF-8: invalid utf-8 sequence of 1 bytes from index 719\nstack traceback:\n\t[C]: in local 'poll'\n\t[string \"?\"]:4: in method 'dkim_sign'\n\t/opt/kumomta/share/policy-extras/dkim_sign.lua:284: in upvalue 'do_dkim_sign'\n\t/opt/kumomta/share/policy-extras/dkim_sign.lua:355: in upvalue 'dkim_signer'\n\t[string \"/opt/kumomta/etc/policy/init.lua\"]:254: in function <[string \"/opt/kumomta/etc/policy/init.lua\"]:213>\n"},"peer_address":{"name":"secure-smtp.domain.com","addr":"10.30.30.201"},"timestamp":1736814163,"created":1736814163,"num_attempts":0,"bounce_classification":"Uncategorized","egress_pool":null,"egress_source":null,"source_address":null,"feedback_report":null,"meta":{},"headers":{},"delivery_protocol":null,"reception_protocol":null,"nodeid":"334e34e7-5c0d-47aa-835c-1e720bf6dfa9"}
4

I have seen amention of check_fix_conformance - KumoMTA Docs but I am not sure if this also applies to the DKIM signing.

So what could I do to let Kumomta just send the mail? This issues is limited to a few mails on a monthly volume of 2 million, so it is not a big problem.

I did capture the postfix mail and I can replay the issue probably… But a recommendation what I can test the best would be welcome. I will have a look later this weekend probably if I can make sense of this.

KumoMTA version: 2024.11.08.103708.d383b033 build on a Debian 12 host without any tweaks on the configuration, so it should be git repo build as it was meant to be :slightly_smiling_face:

5

are we having the same issue, Lol

6

i created a similar ticket 10 mins back

7

oh lol… I did have the issue for some time.. but had no time to investigate

8

ahahah

9

and you are right… I did check the get-help first to see if there was a mention like this… DOH!

10

Well I guess this is probably chinese characters butchered in a NDR report

11

well, you know what’s messed up, even my MongoDB is having issues with UTF-8 content

12

for some reason

13

it shouldn’t

14

Sounds like the incoming message is not 7-bit as is required by the baseline SMTP spec. That’s a problem independent of DKIM, because such a message is not guaranteed to be relayable throughout the SMTP network.

You can apply msg:check_fix_conformance to try to fixup messages from trusted injectors, but if the incoming message is really off the rails without using any of the appropriate MIME encoding to specify what the incoming bytes actually mean, then we won’t know how to successfully encode such a message.

15

I would agree that it looks like messed up mail, but it is the probably chinese tokens messed up in a NDR report by some system. And postfix send it just as it is. I will have a look if I can create a test queue with the check_fix_conformance to see if at least I can pass the message on. In this case it looked like a proper ndr mail.