none
Umlaute bei der E-Mailadresse (Empfänger) (nicht Domäne) - Exchange 2016 on premise RRS feed

  • Frage

  • Hallo am Technet Forum,

    wie der Titel des sagt. Habe aktuell ein kleines Problem. 

    Ich habe folgende Exchange on premise (DAG) Umgebung:

    Windows Server 2016 Standard

    Windows Exchange 2016 Enterprise Version 15.1 (Build 1034.26)

    Domainmail, nennen wir diese mal @local-domain.de

    Die Firewalls und co. lasse ich mal weg. ;-)

    Nun zum Problem:

    E-Mail soll verschickt werden vom Konto x-beliebigen Konto (z.B. Test.User@local-domain.de) an eine externe E-Mailadresse (z.B. pseudo+töst@gmail.com).

    Leider erhalte die Rückmeldung, vom E-Mailserver, dass sich um eine ungültige Adresse handelt.

    Fehlermeldung (via Unzustellbarkeitsbericht): Remote Server returned '550 5.1.3 STOREDRV.Submit; invalid recipient address'

    Fehlermeldung (über telnet -> SMTP): 501 5.1.3 Invalid address (gleich nach dem ich "rcpt to: pseudo+töst@gmail.com" eingegeben habe)

    Die Sendeconnectoren habe ich geprüft bei "scoping" ist SMTP mit eine Wildcard (*) hinterlegt.

    Jetzt zu meine Frage:

    Wie kann ich es einstellen, dass die verantwortliche Funktion beim Exchange, Nachrichten verschicken kann an E-Mailadressen die eine (oder mehrere) Umlaute beinhalten?

    Liegt es an die Character-Codierung oder an eine bestimmte Richtlinie?

    PS: ein genaueren Auszug aus den Unzustellbarkeitsbericht

    Generierender Server: mailserver01.local-domain.local
    pseudo+töst@gmail.com
    Remote Server returned '550 5.1.3 STOREDRV.Submit; invalid recipient address'
    Ursprüngliche Nachrichtenköpfe:
    Received: from mailserver01.local-domain.local ([xxxx::xxxx:xxxx:xxxx:xxxx]) by
     mailserver01.local-domain.local ([xxxx::xxxx:xxxx:xxxx:xxxx]) with mapi id
     15.01.1034.026; XXX, XXXXXXX 09:54:27 +0200
    Content-Type: application/ms-tnef; name="winmail.dat"
    Content-Transfer-Encoding: binary
    From: "User, Test" <Test.User@local-domain.de>
    To: =?iso-8859-1?Q?=27pseudo+t=F6st=40gmail=2Ecom=27?=
    <pseudo+töst@gmail.com>
    Subject: =?iso-8859-1?Q?test_mit_t=F6st?=
    Thread-Topic: =?iso-8859-1?Q?test_mit_t=F6st?=



    • Bearbeitet Master Cyneo Montag, 20. August 2018 15:54 Highlight
    Montag, 20. August 2018 15:53

Antworten

  • Moin,

    bei Telnet-Tests gelten wie im gesamten SMTP-Verkehr nach wie vor strikt die RFCs 2821 und 2822, d.h. keine Zeichen oberhalb ASCII 127 sind hier zulässig, und diverse Sonderzeichen müssen escaped werden.

    Es ist das Client-Programm, das für die Konvertierung von EAI (pseudotöst@gmail.com) nach RFC (xn--pseudotst-67a@gmail.com) zuständig ist. Das wäre in Verbindung mit Exchange vermutlich Outlook oder halt OWA, und beide können es nach meinen Tests noch nicht, auch nicht in den aktuellen Versionen.


    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    In theory, there is no difference between theory and practice. In practice, there is.

    Montag, 20. August 2018 19:10
  • Hallo,

    Falls du die Mails über EWS versenden kannst besteht die Möglichkeit mittels IdnMapping die Adresse umzucodieren:

    # Load EWS Managed API DLL  and Connect to Exchange
    [string]$EwsApiDll = "C:\Program Files\Microsoft\Exchange\Web Services\2.2\Microsoft.Exchange.WebServices.dll"
    
    Import-Module -Name $EwsApiDll
    
    [string]$Mailbox = "vor.nach@firma.de"
    
    $EWService = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService([Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2016)
    $EWService.UseDefaultCredentials = $true    
    $EWService.AutodiscoverUrl($Mailbox, {$True}) 
    
    $Address = "müma@firma.com"
    
    [Microsoft.Exchange.WebServices.Data.EmailMessage]$message = New-Object Microsoft.Exchange.WebServices.Data.EmailMessage($EWService)
    
    $idn = New-Object System.Globalization.IdnMapping
    $Address1 = $Address -split "@"[0]
    $Local = $idn.GetAscii($Address1[0])
    $Address = $Local + "@" + $Address1[1]
    
    
    $message.Subject = "Betreff Test Umlaute im Local Part"
    $message.ToRecipients.Add($Address)
    $message.Body = "Achtung Umlaute öäü ÖÄÜ ß"
    $message.Body.BodyType = 'HTML'
    
    $message.SendAndSaveCopy() 

    Evtl. hilft das ja bei deinem Problem

    Grüße

    Dienstag, 21. August 2018 05:18

Alle Antworten

  • Moin,

    bei Telnet-Tests gelten wie im gesamten SMTP-Verkehr nach wie vor strikt die RFCs 2821 und 2822, d.h. keine Zeichen oberhalb ASCII 127 sind hier zulässig, und diverse Sonderzeichen müssen escaped werden.

    Es ist das Client-Programm, das für die Konvertierung von EAI (pseudotöst@gmail.com) nach RFC (xn--pseudotst-67a@gmail.com) zuständig ist. Das wäre in Verbindung mit Exchange vermutlich Outlook oder halt OWA, und beide können es nach meinen Tests noch nicht, auch nicht in den aktuellen Versionen.


    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    In theory, there is no difference between theory and practice. In practice, there is.

    Montag, 20. August 2018 19:10
  • Ich kann die Aussagen von Evgenij so bestätigen.

    ;)


    Gruß Norbert

    Montag, 20. August 2018 20:13
    Moderator
  • Hallo,

    Falls du die Mails über EWS versenden kannst besteht die Möglichkeit mittels IdnMapping die Adresse umzucodieren:

    # Load EWS Managed API DLL  and Connect to Exchange
    [string]$EwsApiDll = "C:\Program Files\Microsoft\Exchange\Web Services\2.2\Microsoft.Exchange.WebServices.dll"
    
    Import-Module -Name $EwsApiDll
    
    [string]$Mailbox = "vor.nach@firma.de"
    
    $EWService = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService([Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2016)
    $EWService.UseDefaultCredentials = $true    
    $EWService.AutodiscoverUrl($Mailbox, {$True}) 
    
    $Address = "müma@firma.com"
    
    [Microsoft.Exchange.WebServices.Data.EmailMessage]$message = New-Object Microsoft.Exchange.WebServices.Data.EmailMessage($EWService)
    
    $idn = New-Object System.Globalization.IdnMapping
    $Address1 = $Address -split "@"[0]
    $Local = $idn.GetAscii($Address1[0])
    $Address = $Local + "@" + $Address1[1]
    
    
    $message.Subject = "Betreff Test Umlaute im Local Part"
    $message.ToRecipients.Add($Address)
    $message.Body = "Achtung Umlaute öäü ÖÄÜ ß"
    $message.Body.BodyType = 'HTML'
    
    $message.SendAndSaveCopy() 

    Evtl. hilft das ja bei deinem Problem

    Grüße

    Dienstag, 21. August 2018 05:18
  • Guten Morgen,

    vielen Dank für die Unterstützung.

    @Evgenij: Danke für die Ausführliche Antwort.

    Ich konnte Tests ausführen über eine andere Umgebung (andere Firma), Exchange-Online. Damit funktioniert das versenden an E-Mails mit Umlauten. Ich gehe dann davon aus, dass die beiden Strukturen, als ganz verschiedene betrachten muss.

    Dienstag, 21. August 2018 06:42
  • Guten Morgen,

    @KSV43: Vielen Dank für den Workaround

    Grüße

    Dienstag, 21. August 2018 06:42
  • Hallo zusammen,

    ich klinke mich mal mit ein, da mein Problem ähnlich gelagert ist ... allerdings beim Empfang. Wir erhalten Mails, die als Absenderadresse z.B. Irgendwasmitblödenumlauten@domain.com haben.

    Wir haben einen vorgelagerten Mailserver, der als ANTI-SPAM Gateway fungiert und diese Mails anstandslos entgegennimmt. Bei der Weiterleitung (Daten der Mail werden nicht verändert) an den internen Exchange 2016 lehnt der diese Mails jedoch direkt nach dem "MAIL From" ab mit folgender Meldung:

    --> MAIL From:<Irgendwasmitblödenumlauten@domain.com> Size=12345
    <-- 501 5.1.7 Invalid address
    --> QUIT

    Die Mail wird dann auf unserem Gateway in einer Fehlerqueue gehalten. Der Mailserveradmin der Gegenseite ist bereits kontaktiert, aber meldet sich nicht.

    Kann ich auf meiner Seite irgendwas machen, um den Exchange 2016 dazu zu bewegen das doch anzunehmen?

    Danke, Michael

    Freitag, 5. April 2019 08:21
  • Kann ich auf meiner Seite irgendwas machen, um den Exchange 2016 dazu zu bewegen das doch anzunehmen?

    Danke, Michael

    Auf Exchange 2019 upgraden (ich habe aber noch nicht getestet, ob die IDN/EAI-Unterstützung am SMTP-Eingang auch implementiert wurde) oder die Appliance dazu überreden, die IDN-Übersetzung vorzunehmen.

    Fakt ist, eine RFC-konforme Mail wird keine Umlaute in den für den Transport signifikanten Feldern beinhalten.


    Evgenij Smirnov

    http://evgenij.smirnov.de

    Freitag, 5. April 2019 09:38
  • Kann ich auf meiner Seite irgendwas machen, um den Exchange 2016 dazu zu bewegen das doch anzunehmen?

    Danke, Michael

    Auf Exchange 2019 upgraden (ich habe aber noch nicht getestet, ob die IDN/EAI-Unterstützung am SMTP-Eingang auch implementiert wurde) oder die Appliance dazu überreden, die IDN-Übersetzung vorzunehmen.

    Fakt ist, eine RFC-konforme Mail wird keine Umlaute in den für den Transport signifikanten Feldern beinhalten.


    Evgenij Smirnov

    Exchange 2019 stand zur Diskussion (haben erst vor 4 Wochen von EXC2010SP3 migriert), wurde aber wegen der Hardwareanforderungen auf Eis gelegt. Die Idee mit der IDN Übersetzung am Gateway gefällt mir noch ganz gut. Ich prüfe das mal. Falls doch noch einer eine Idee für EXC2016 hat nur her damit.

    Danke, Michael

    Freitag, 5. April 2019 12:15
  • Kann ich auf meiner Seite irgendwas machen, um den Exchange 2016 dazu zu bewegen das doch anzunehmen?

    oder die Appliance dazu überreden, die IDN-Übersetzung vorzunehmen.

    Habe die Antwort vom Support des Gateway Herstellers bekommen:

    "There are no new updates regarding that wish list request for Unicode character support for account addresses and domain names. However, I have updated that wish list item to let our developers know that you are requesting this feature."

    Also da auch keine Möglichkeit.

    Weiß jemand, ob das unter Exchange 2010 SP3 ging oder ob das nur zufällig ungefähr zeitgleich mit der Exchange 2016 Migration aufgetreten ist?

    Gruß, Michael

    Montag, 8. April 2019 06:24
  • Nein, unter 2010 ging es auch nicht.

    Evgenij Smirnov

    http://evgenij.smirnov.de

    Montag, 8. April 2019 07:02