MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

SMTPUTF8Enabled, EAI Support

SMTP ist ein sehr altes Protokoll und damals waren 7-bit, US-ASCII und Text der Standard. Für die Übertragung von Dateien wurden diese dann mittels UUENCODE oder BASE64 in solche Zeichen konvertiert und Umlaute in den From und To wurden auch konvertiert. Mit der Erweiterung SMTPUTF8 ist es nun erstmalig möglich, auch Email Address Internationalization (EAI) schon im Protokoll zu verwenden. Das führt manchmal zu Problemen.

SMTP mit UTF8

Auf der Seite SMTP-Telnet habe ich beschrieben, wie sie eine Mail per TELNET an einen SMTP-Server senden können. Wenn ich z.B. den Mailserver für die Domain msxfaqlab.onmicrosoft.com anspreche und mit einem EHLO begrüße, dann sehne Sie zwei Angebote für UTF8.

Beide erweitern die Möglichkeiten einer Übertragung von Mails an den anderen Server.

  • 8BITMIME
    Diese Erweiterung erlaubt meinem Server beim Senden auch 8bit-Zeichen im BODY-Parte zu übertragen und muss ich nicht auf 7-Bit beschränken.
  • SMTPUTF8
    Damit steuer ich , dass ich auch im SMTP-Handshake, d.h. bei der Übermittlung von "MAIL FROM" und "RCPT TO" nun mit Umlaut Domains oder IDN arbeiten kann. Es kann ja auch Mailadressen mit Umlauten (UTF8) im Userpart oder Domainpart haben.

Ob man das wirklich braucht, lasse ich mal dahin gestellt sein. zum Testen kann ich einfach eine Mail im entsprechenden Format senden, z.B. indem ich nach dem EHLO dann die Absenderzeile anpasse.

# Beispiel einer Mail mit encodierten Umlauten 
MAIL FROM:=?utf-8?Q?Rechnungsb=C3=BCro_MSXFAQ?= <erechnung@msxfaq.de>

# Beispiel eines SMTP-Handshake mit SMTPUTF8-Absender
MAIL FROM: "Rechnungsbüro MSXFAQ" <erechnung@msxfaq.de>

Soweit ist das Prinzip einfach zu verstehen. Kniffliger wird es aber, wenn wir diese Funktion dann auch in einer echten Umgebung nutzen.

Testmail mit SMTPUTF8

Dazu sende ich eine entsprechende Mail. Per "Send-MailMessage" geht das aber nicht:

Send-MailMessage `
 -SmtpServer msxfaqlab.mail.protection.outlook.com `
 -From "Fränk Carius <fränk@carius.de>" `
 -To fcadmin@msxfaqlab.onmicrosoft.com `
 -Subject "Test SMTPUTF8"

Der Fehler "Send-MailMessage : The client or server is only configured for E-mail addresses with ASCII local-parts" ist deutlich. Ich habe parallel die SMTP-Verbindung mit Wireshark mitgeschnitten und Send-MailMessage bricht schon direkt nach dem EHLO ab.

Das passt auch zur anderen Meldungen, die ich gefunden habe:

the DeliveryFormat property of your SmtpClient instance is set to SmtpDeliveryFormat.SevenBit (the default) then you need to make sure your SMTP gateway is replying with SMTPUTF8 when sent EHLO by .NET while it's trying to send the email. SmtpClient uses this to work out if the gateway is able to support UTF8.
c# - SmtpException: The client or server is only configured for e-mail addresses with ASCII local-parts - Stack Overflow
https://stackoverflow.com/questions/13260772/smtpexception-the-client-or-server-is-only-configured-for-e-mail-addresses-with

Auch der Versuch mit dem Parameter "-Encoding UTF8" o.ä. zu arbeiten, hat keine Änderung gebracht. Der Versand ohne Umlaut in der Mailadresse funktionierte natürlich wie erwartet:

Hier wurde der Umlaut im Displayname dann als Teil des Headers "UTF-8" codiert aber im Header war nichts zu sehen. Also war mal wieder PowerShell gefragt und eine kurze Frage an VSCode-KI:

GPT 4.1: "Write a PowerShell Script to send an SMTP message with SMTPUTF8 characters to Exchange Online without authentication"

Das Ergebnis war folgender Code, den ich nachträglich nur noch gering anpassen musste. Ich habe SSL zur Analyse mit Wireshark abgeschaltet und den SMTP-Server auf den MX-Record meines Tenant geändert.

$smtpServer = "msxfaqlab.mail.protection.outlook.com"
$smtpPort = 25
$from = "fränk@carius.de"
$to = "fcadmin@msxfaqlab.onmicrosoft.com"
$subject = "Test - UTF8 ✓"
$body = "Hello, this is a test with UTF8 😀"

# Create the SMTP message
$message = New-Object System.Net.Mail.MailMessage $from, $to, $subject, $body
$message.BodyEncoding = [System.Text.Encoding]::UTF8
$message.SubjectEncoding = [System.Text.Encoding]::UTF8
# Create the SMTP client
$smtp = New-Object System.Net.Mail.SmtpClient $smtpServer, $smtpPort
$smtp.DeliveryFormat=[System.Net.Mail.Smtpdeliveryformat]::International
$smtp.EnableSsl = $false
# Send the message (no authentication)
$smtp.Send($message) 

Der Versand hat funktioniert und sie sehen auch mein MAIL FROM die zwei "Punkte", welche das Unicode-Zeichen enthalten und von Wireshark nicht angezeigt werden.

In der Detailansicht gibt Wireshark sehr wohl die 8-Bit-UNICODE-Ausgabe sauber aus und auch der "Haken" im Betreff wird angezeigt.

Die vom Server angebotene SMTPUTF8-Option wurde hier erfolgreich genutzt. In meinem Posteingang waren die Mails mit allen Sonderzeichen zu sehen:

Wenn ich die gleiche Mail an einen Server ohne SMTPUTF8-Support senden möchte, dann wird diese direkte nach dem EHLO abgelehnt.

Probleme bei der Zustellung

Wenn doch alles so nett aussieht, dann kann es doch nicht so schlimm sein? Das stimmt so leider nicht, denn es gibt zwei Problemfälle, die auftreten können.

  • Client und Server inkompatibel
    Das erste Problem haben Sie bei meinen Testmails schon gesehen, wenn ein Server SMTPUTF8 nicht anbietet aber der Client eine Mail mit UTF-Sonderzeichen absenden will, dann kann er sie ggfls. nicht zusenden.
  • Relay mit und Upstream ohne SMTPUFT8
    Der zweite Fall ist, wenn Sie eine Mail mit SMTPUTF8 an einen Server einliefern, der diese annimmt aber dann seinerseits als Relay an einen Server senden will, der dies nicht kann. Er bekommt die Mail nicht los und erstellt einen NDR. Natürlich könnte der Relayserver die Mail vor der übertragung konvertieren. Das machen die SMTP-Server aber in der Regel nicht, weil eine Änderung z.B. eine DKIM oder SMIME-Signatur verändern würde. Zudem kostet es einfach Rechenleistung.

Um dies nachzustellen, habe ich auf meinem Exchange Online Tenant die IP-Adresse über einen Inbound Organization Connector für meine genutzte IP-Adresse als Relay konfiguriert und eine Mail per SMTPUTF8 über Exchange Online an einen Server ohne SMTPUTF8 gesendet.

$smtpServer = "msxfaqlab.mail.protection.outlook.com"
$smtpPort = 25
$from = "fränk@msxfaqlab.de"
$to = "frank@carius.de"
$subject = "Test - UTF8 ✓"
$body = "Hello, this is a test with UTF8 😀"

# Create the SMTP message
$message = New-Object System.Net.Mail.MailMessage $from, $to, $subject, $body
$message.BodyEncoding = [System.Text.Encoding]::UTF8
$message.SubjectEncoding = [System.Text.Encoding]::UTF8
# Create the SMTP client
$smtp = New-Object System.Net.Mail.SmtpClient $smtpServer, $smtpPort
$smtp.DeliveryFormat=[System.Net.Mail.Smtpdeliveryformat]::International
$smtp.EnableSsl = $false
# Send the message (no authentication)
$smtp.Send($message) 

Die Mail wurde von Exchange Online angenommen und sollte dann zu IONOS, dem Mailserver für die Zieldomain weitergeroutet werden. Das hat nicht funktioniert und Exchange Online hat diesen Fehler als NDR an den Absender zurückgesendet. Aus dem Messagetracking in Exchange Online habe ich mir die Fehlermeldung extrahiert:

Es ist gut zu sehen, dass die Gegenseite bei IONOS die Annahme der Mail mit folgendem Fehlercode abgelehnt hat:

550 5.1.9 SMTPSEND.Utf8SenderAddress; UTF-8 sender address not supported

Wenn Sie einen "TELNET mx01.ionos.de 25" mit nachfolgendem EHLO zu der Zeit ausgeführt haben, konnten sie das Fehlen von SMTPUTF8 gut sehen.

Das bedeutet im Umkehrschluss aber auch, dass Exchange Online zwar SMTPUTF8 annimmt aber bei der Weiterleitung zu nachfolgenden Mailservern keine Konvertierung vornimmt. Ich kann aber die Option SMTPUTF8 nicht pro Tenant oder Connector abschalten, denn Exchange Online bietet diese Option schon direkt nach dem EHLO an und weiß zu der Zeit noch gar nicht, an welchen Tenant und über welchen Inbound Connector die Mail verarbeitet wird.

Ich habe mich gefragt, wie andere Mailserver damit umgehen und bin auf eine Beschreibung bei POSTFIX gestoßen.


https://www.postfix.org/SMTPUTF8_README.html#using

Auch Postfix macht keine Konvertierung von per SMTPUTF8 empfangenen Mails, wenn der nächste Hop diese Funktion nicht unterstützt aber die Mail UTF-8-Inhalte im Header enthält.

Bei Exchange OnPremises können Sie die Unterstützung für SMTPUTF8 allerdings abschalten. Dazu gibt es pro Receive Connector einen passenden Parameter:


Quelle: Set-ReceiveConnector
https://learn.microsoft.com/en-us/powershell/module/exchangepowershell/set-receiveconnector?view=exchange-ps#-smtputf8enabled

Allerdings ist der Parameter als "for internal Microsoft use" klassifiziert. Allerdings hat Microsoft den Support für "Email Address Internationalization (EAI)" in Exchange Online schon Anfang 2018 aktiviert. Der Support für Exchange 2019 kam etwas später.

SMTPUTF8-Support im Internet

Das hat mich aber nicht gehindert, mittels EHLO verschiedene Gegenstellen abzuprüfen.

System Receive Connector/Telnet-Ergebnis SMTPUTF8Enabled

Exchange 2019

Default internal receive connector edge01

[PS] C:\>Get-ReceiveConnector | ft name,SmtpUtf8Enabled

Name                           SmtpUtf8Enabled
----                           ---------------
Default EX2019                            True
Client Proxy EX2019                       True
Default Frontend EX2019                   True
Outbound Proxy Frontend EX2019            True
Client Frontend EX2019                    True
RelayAnonymous                            True

Die Einstellung ist vorhanden und änderbar.

Ja, abschaltbar
Edge 2019
Exchange Edge Default Settings		 Default internal receive connector edge01
Die Einstellung ist vorhanden und änderbar.

Ja, abschaltbar

Exchange 2016

Default internal receive connector edge01

[PS] C:\>Get-ReceiveConnector | ft name,SmtpUtf8Enabled

Name                           SmtpUtf8Enabled
----                           ---------------
Default EX2016                            True
Client Proxy EX2016                       True
Default Frontend EX2016                   True
Outbound Proxy Frontend EX2016            True
Client Frontend EX2016                    True
RelayAnonymous                            True

Die Einstellung ist vorhanden und per Default auf "True" aber wirkungslos.

Wird nicht angeboten

Exchange 2013

EX2013\Default Frontend EX2013

Wird nicht angeboten
Exchange 2007/2010 Receiveconnector

Nicht getestet

Wird nicht angeboten
Exchange Online
Office 365 Mail Connector

Globale Einstellung durch Microsoft

Ja, nicht abschaltbar
Postfix
https://www.postfix.org/SMTPUTF8_README.html

Nicht getestet

Ja

Outlook.com

 
220 DS1PEPF0001708F.mail.protection.outlook.com Microsoft ESMTP 
     MAIL Service ready at Tue, 30 Sep 2025 13:35:59 +0000 [08DDFD83593CC665]
ehlo test
250-DS1PEPF0001708F.mail.protection.outlook.com Hello [217.91.247.140]
250-SIZE 49283072
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-STARTTLS
250-8BITMIME
250-BINARYMIME
250-CHUNKING
250 SMTPUTF8

Ja

GMail

 
250-mx.google.com at your service, [217.91.247.140]
250-SIZE 157286400
250-8BITMIME
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-CHUNKING
250 SMTPUTF8

Ja

Yahoo

 
220 mtaproxy407.free.mail.ne1.yahoo.com ESMTP ready
ehlo tet
250-mtaproxy407.free.mail.ne1.yahoo.com
250-PIPELINING
250-SIZE 41943040
250-8BITMIME
250 STARTTLS

Ja

IONOS

 
220 kundenserver.de (mxeue101) Nemesis ESMTP Service ready
ehlo test
250-kundenserver.de Hello test [217.91.247.140]
250-8BITMIME
250-SIZE 157286400
250 STARTTLS

Nein

GMX

 
220 gmx.net (mxgmx107) Nemesis ESMTP Service ready
ehlo test
250-gmx.net Hello test [217.91.247.140]
250-8BITMIME
250-SIZE 157286400
250 STARTTLS

Nein
bmw.de
Cisco Secure Mail (Cloud)		 
220 esa13.hc324-48.eu.iphmx.com ESMTP
ehlo test
250-esa13.hc324-48.eu.iphmx.com
250-8BITMIME
250-SIZE 26214400
250 STARTTLS

Nein

rwe.com

 
220 secmail.rwe.com ESMTP
ehlo test
250-secmail.rwe.com
250-PIPELINING
250-SIZE 78643200
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250 CHUNKING

Nein

NoSpamProxy

 
220 de-s111-gw1.mail.cloud.nospamproxy.com - NoSpamProxy ready
ehlo test
250-de-s111-gw1.mail.cloud.nospamproxy.com welcome
250-DSN
250-ENHANCEDSTATUSCODES
250-X-ANONYMOUSTLS
250-STARTTLS
250-8BITMIME
250 SIZE

Ja

Proofpoint

 
220 mx0b-00148501.pphosted.com ESMTP mfa-m0337698
ehlo test
250-mx0b-00148501.pphosted.com Hello pd95bf78c.dip0.t-ipconnect.de [217.91.247.140], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE 157286400
250 STARTTLS

Ja

Hornet Security

 
220 mx-gate85-hz1.antispameurope.com antispameurope Mailsecurity
ehlo test
250-mx-gate85-hz1.antispameurope.com
250-PIPELINING
250-SIZE 157286400
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

Nein

Sie können gerne eigene Untersuchungen anstellen. Sie ermitteln den für eine Domain zuständigen Mailserver über die DNS-Abfrage auf den MX-Record um dann eine TELNET <servername> 25 zu starten und danach einen "EHLO <beliebigername>" einzugeben. Allerdings könnten einige Server die TCP-Verbindung direkt ablehnen, wenn ihre IP-Adresse eine schlechte Reputation hat oder eine dynamische Adresse ist.

Einschätzung

Ich habe bei der Tabelle absichtlich ein "Nein" nicht rot markiert, denn auf der einen Seite erscheint die EAI/SMTPUTF8-Unterstützung als wünschenswert aber Sie kann auch zu Problemen führen, wenn Sie wirklich in Anspruch genommen wird. Ich selbst meidet Umlaute in Mailadressen, weil es sich einfach falsch anfühlt und es immer noch Server geben könnte, die damit ein Problem haben. Dazu zählen nicht die großen Provider wie Gmail, Hotmail, Yahoo etc. und auch Exchange Online und einige Hosted Spamfilter unterstützen diese Funktion. Sie dürfte aber nur sehr selten genutzt werden, denn Umlaute bei Absender und Empfänger sind selten. Etwas anders sieht es aus, wenn Sie UTF8-Sonderzeichen etc. im Betreff verwenden wollen.

Probleme gibt es immer dann, wenn ihr SMTP-Client auf UTF8 besteht und der Server dies nicht kann. Sie können ihre Mail gar nicht absenden und hoffentlich haben Sie in ihrem Versandprozess eine Fehlerbehandlung implementiert und erkennen das Problem. Kniffliger wird es, wenn der nächste Hop die Funktion SMTPUTF8 unterstützt aber seinerseits die Mail an andere Systeme weiterleitet, die SMTPUTF8 nicht unterstützen. Dann kann er die Mail nicht zustellen und generiert eine NDR-Meldung an den Absender. Normaler Anwender werden diese kaum verstehen und nicht wissen, wie Sie damit umgehen. Auch erfahrene Administrator werden erst einmal recherchieren um dann zu erkennen, dass allein die Software des Absenders der UTF8-Mail sich überlegen muss, ob er eine Mail mit UTF8 senden und einige Unzustellbarkeiten riskiert oder auf die UTF8-Sonderzeichen verzichtet und mit 7-Bit unterwegs sein kann. Ich hoffe, dass die Hintergrundinformationen ihnen bei der Analyse und und Behebung ihrer Fehler helfen konnte.

Weitere Links