issue with utf8 chars in recipient domain

get-help
1

we’re facing issues on sending emails to recipient domains that contains valid chars (none ascii). Kumomta reports STARTTLS: xxx is not a valid DNS name

examples:

/opt/kumomta/sbin/tls-probe probe mail.hausmeister-dülmen.de:25
Error: failed to connect to mail.hausmeister-dülmen.de:25

Caused by:
    failed to lookup address information: Name or service not known

dig +short mail.hausmeister-dülmen.de 
178.254.4.101

dig +short mail.stüßer.de
80.237.138.5

/opt/kumomta/sbin/tls-probe probe mail.stüßer.de:25
Error: failed to connect to mail.stüßer.de:25

Caused by:
    failed to lookup address information: Name or service not known

I’m running kumomta 2024.12.13-1037b1a1
resolv.conf is pointing to a local installed dns server, which is used by dig.
kumomta is using the default dns settings.

4

SMTP domains must be 7-bit names. Using UTF-8 names is an SMTP extension that we do not support

5

Is there any plan to support it in the near future?

6

How common is it that you have non 7-bit domains?

7

You should be able to use IDNA in these cases to convert the UTF-8 domain to ASCII

8

UTF-8 in email is complicated and painful. There is a separate spec for the envelope during SMTP and a separate spec for the email headers.

RFC 6531 - SMTP Extension for Internationalized Email is the former and it requires that the sender explicitly indicate that they are using the SMTPUTF8 extension when issugin MAIL FROM / RCPT TO.

It is not valid for an SMTP client to use UTF-8 without properly implementing this RFC and explicitly indicating that they have UTF-8 content.

This particular RFC is especially burdensome because it requires that 8BITMIME also be implemented. That’s a PITA because that RFC requires that the message be re-written (invalidating DKIM and other signatures) if the downstream system does not also implement both SMTPUTF8 and 8BITMIME.

There’s a decent amount of work involved in supporting this sort of just-in-time message re-writing, and that’s ignoring how it would invalidate signatures, which is highly undesirable.

9

its not very common, but might be an issue if we want to replace powermta

10

we had around 1500 messages in the last month, so not really a big deal, but I was kinda expecting that kumo it can :slightly_smiling_face:

11

i mean i dont know what has to be done.

12

i only can say some customers are asking me we this is not supported

13

It is not impossible, but it is difficult, rare, and none of our supported customers have asked for it. KumoMTA has delivered over 100Billion messages without needing it yet.
I can write up a feature request under “Needs Funding” and see if we can work up an estimated development cost.

14

I suspect that you won’t be happy to see the cost to fund a complete implementation of 8BITMIME and SMTPUTF8 because the surface area of the two features combined is fairly large… and I suspect that your specific use case may not need its full extent.

It would be helpful if you could expand on what your scenario and use case actually are, because the original report doesn’t cover many details about the actual message flow and addressing.

15

I wrote up some more technical details around what would be needed to claim support for SMTPUTF8 over in Support for SMTPUTF8 · Issue #327 · KumoCorp/kumomta · GitHub

16

thank you for writing up.

17

as of smtp_server: allow 8bit envelopes · KumoCorp/kumomta@49eb103 · GitHub if you add this to your policy:

kumo.on('smtp_server_ehlo', function(domain, conn_meta, extensions)
  table.insert(extensions, 'SMTPUTF8')
  table.insert(extensions, '8BITMIME')
  return extensions
end)

you’ll have a partial SMTPUTF8 implementation that won’t try to downconvert either the envelope or the data during send, but that will try to use those extensions if it realizes that you have 8bit data.

I’d suggest coupling that with check_fix_conformance - KumoMTA Docs with at least NEEDS_TRANSFER_ENCODING set to fix.

I suspect that that is probably enough to unblock most use cases.

18

I will test it this week :smiling_face: