Exchange 2003 und Umlaute im Realname

1. offizieller Beitrag

    Hallo,


    ich bin ganz frisch registriert, Tag allerseits...


    Und ich habe ein ordentliches Problem, bei dem ich auf Hilfe hoffe: bei (bis jetzt) zwei Exchange 2003 Servern habe ich das Phänomen, dass eingehende Nachrichten, bei denen der Realname im FROM: Feld nach dem Schema "Nachname, Vorname" <mail@domain.tld> aufgebaut ist, und die in Vorname oder Nachname einen Umlaut enthalten, NICHT zugestellt werden (es handelt sich um kein IDN-Problem, die Domain ist "ganz normal").


    Also z. B.:


    FROM: "Müller, Max" <max@mueller.com>


    wird nicht zugestellt. Die gleiche Nachricht als


    FROM: "Max Müller" <max@mueller.com>


    kann zugestellt werden.


    Die Nachrichten werden mit GFI POP2Exchange abgeholt (das geschieht auch korrekt, im Log ist alles drin) und ins Pickup-Verzeichnis gelegt. Bis dahin ist alles OK.


    In der Nachrichtenstatus-Verfolgung taucht die Nachricht nur als "M|ller" auf (anstatt "Müller, Max" - offensichtlich stolpert Exchange2003 über das in ISO codierte Komma?), mit dem Hinweis auf "Erweiterter Warteschlangenmechanismus konnte Nachricht nicht übermitteln", und in Folge, dass diese ins BadMail-Verzeichnis verschoben wird.


    Das schwerwiegende Problem: im BadMail Verzeichnis ist anschliessend keine Nachricht. Die Nachricht wird KOMPLETT verschluckt.


    Hat jemand dieses Phänomen bereits beobachtet? Ich schicke auch gerne Testnachrichten, falls es jemand überprüfen möchte.


    vielen Dank schonmal

    • Offizieller Beitrag

    Hi,


    Exchange selber sollte sich an dem Aufbau nicht stören lassen. Um das zu testen schick Deinem Exchange Server via Telnet eine Mail (Anleitung findest du in den How-To). Ich vermute eher den Fehler am GFI, dass dieser die Mail konvertiert und Exchange nichts mehr mit anfangen kann.
    Eine POP Abholung seitens Exchange kann ich nie empfehlen, da dies immer Fehlerträchtig ist. Wenn es wirklich an dem POP2Exchange liegt, so würde ich mich mal an dessen Support wenden. Sorry :-?


    Gruss
    Heinz

    Am POP2Exchange liegt es nicht, Kontakt mit dem Support hatte ich schon. Dieser holt lediglich die Nachricht und legt Sie ins Pickup-Verzeichnis, was anderes passiert dort nicht (keine Konvertierung o.ä., ist nicht die Aufgabe von dem Teil).


    Darüber hinaus hat mir der Anwender gerade mitgeteilt (ich habe seinen Account auf direkten POP3-Abruf umgestellt), dass auch Outlook 2003 ein Problem mit dieser Namensdarstellung hat: wenn er auf "Antworten" klickt, so erscheint NICHT die richtige Empfängeradresse, sondern nur der Teil für dem Komma (aus meinem obigen Beispiel also "Müller").


    Nachdem genau dieses auch im Nachrichtenstatus so auftaucht und der Fehler also so oder so ähnlich "erhalten bleibt" wenn ich den POP2Exchange gar nicht verwende, tippe ich eher mal auf ein Problem mit der Behandlung dieses (zugegegenermassen sehr beknackten) Formats der Absenderadresse.


    Der FROM Header eines Kontakts des oben erwähnten Users sieht im Header so aus:


    FROM: =?iso-8859-1?Q?Furtw=E4ngler=2C_Maria?= <xxx@xxx.xx>


    ...und da stolpert nicht nur Outlook drüber...

    Nachtrag:


    Das der Mailempfang in Exchange über POP3 problematisch ist weiss ich, aber welche Alternative habe ich bei einem kleinen Unternehmen, das mit DSL & dynamischer IP im Netz ist?


    Und: wie packe ich den ISO-codierten Namen via Telnet in die FROM: Adresse?


    Danke...

    • Offizieller Beitrag

    Ich bin jetzt was verwirrt. Wenn die von extern versendete Mail, zu Deinem Provider übermittelt wird und Du die Mail via GFI POP2Exchang oder auch mit dem POP des Outlook Clients abholst, kommt es zu diesem Problem? Dann kann es ja garnicht an Dir liegen, es sei denn eine Viruswall fasst das Mail nochmal an.


    Ist der Fehler nur bei dieser einen Domäne oder auch von anderen?


    Der hier gesehene Effekt tritt auf, wenn Realnames nach RFC-2822 kodieren (evtl. Anführungszeichen einfügen) und hinterher noch einen RFC-2047-Encoder drüber laufen lassen.


    Das ist komplett falsch kodiert. Ziel der RFC-2047-Kodierung ist es, dass RFC-822-Parser encoded-words (=?iso-8859-1?Q?...?=) als atom erkennen. So wird es aber als quoted-string erkannt und dürfte streng genommen nicht dekodiert werden.


    Falls Du keinen Einfluss auf den Server hast, wäre eine Möglichkeit, den Realname von Hand zu kodieren und ihn beim Mail-Client ins Benutzer-Feld (oder wie auch immer das heisst) einzutragen. Der Mail-Client erkennt dann, dass er den Realname nicht zu kodieren braucht (sind ja nur "legale" Zeichen enthalten) und packt ihn so ins
    "From:".


    Zu dem Nachtrag:


    Ich hatte früher meine Private Domäne bei Selfhost wo ich diese mit DynDNS betrieben habe. Nun habe ich je nach dem welches System ich in der Zeit hatte, drei Möglichkeiten, meine IP mit dem Provider zu synchronisieren.


    Windows -> DirectUpdate (Kostenpflichtig)
    Linux -> Script
    Router mit DynDNS Funktion.


    Wenn ich nicht erreichbar war, wurden die Mails bei Selfhost zwischen gelagert, bis ich mich mit meiner neuen IP gemeldet hatte. Fast jeder Anbieter gibt eine solche Möglichkeit. Das intern eingesetzte Mailsystem ist dabei egal, da die Verbindung via SMTP aufgebaut wird.


    Eine feste IP ist aber auch nicht sehr viel teurer!


    Gruss
    Heinz


    PS: Mit Telnet kannst Du es nicht so codieren.

    Zitat


    webmaster schrieb:
    Ich bin jetzt was verwirrt. Wenn die von extern versendete Mail, zu Deinem Provider übermittelt wird und Du die Mail via GFI POP2Exchang oder auch mit dem POP des Outlook Clients abholst, kommt es zu diesem Problem? Dann kann es ja garnicht an Dir liegen, es sei denn eine Viruswall fasst das Mail nochmal an.


    An "mir" liegt es insofern nicht, als dass ich bei eingehenden Nachrichten ja keinen Einfluss auf das Format habe. An "mir" (im Sinne von Exchange2003) liegt es doch, da die Mails dort im Nirvana verschwinden, während zumindest der Empfang mit einem normalen POP3-Client funktioniert (aber Outlook in Folge mit der Behandlung eines solchen Namens ein Problem hat).


    Ein Virenscanner fasst die Mail nochmal an, aber soweit kommt es gar nicht. GFI Pop2Exchange holt die Nachricht vom POP3-Server ab und legt sie ins Pickup-Verzeichnis. Ab da wird dann via "sink" (so hat mir das der GFI-Support erklärt) die Nachricht geholt, die Virenerkennung durchgeführt, und die Nachricht wiederum via "sink" zurück zu Exchange geführt. Aber wie gesagt: soweit kommt es gar nicht.


    Mit meinem privaten Mailclient (POP3, The Bat) habe ich überhaupt kein Problem, exakt diese Mails zu empfangen, zu beantworten... daher die Vermutung, dass es an Exchange selbst liegen muss - der POP-Download funktioniert und endet mit dem Log-Eintrag "message put into pickup directory".


    Zitat


    Ist der Fehler nur bei dieser einen Domäne oder auch von anderen?


    Der Fehler tritt bei zwei unterschiedlichen Domänen auf (1x SBS2003, 1x Exch2003 Standard). Bei einer dritten (wo nicht GFI POP2Exchange, sondern der SBS POP Connector eingesetzt wird) warte ich noch auf eine Rückantwort, bzw. kann erst morgen in die Logs reinschauen.


    Zitat


    Der hier gesehene Effekt tritt auf, wenn Realnames nach RFC-2822 kodieren (evtl. Anführungszeichen einfügen) und hinterher noch einen RFC-2047-Encoder drüber laufen lassen.


    Wenn ich eine Nachricht mit genau dieser Namenskonvention + Umlaut erzeuge (mit meinem normalen EMail-Client, direkt über den SMTP meines Providers), dann kann ich das Problem beliebig reproduzieren (daher mein Angebot, Testmails zu verschicken).


    Zitat


    Das ist komplett falsch kodiert. Ziel der RFC-2047-Kodierung ist es, dass RFC-822-Parser encoded-words (=?iso-8859-1?Q?...?=) als atom erkennen. So wird es aber als quoted-string erkannt und dürfte streng genommen nicht dekodiert werden.


    Daher meine Vermutung, dass das KOMMA in dem Namen eigentlich der Schuldige ist: dieses Komma wird ja zum Absetzen einzelner Mailadressen voneinander verwendet. Damit eben dies nicht geschieht, setzt ein Komma im Realname AFAIK voraus, dass der Realname in Anführungszeichen steht. Wie also sollte diese Absenderangabe "richtig" codiert werden, wenn es sowas überhaupt gibt?


    Zitat


    Falls Du keinen Einfluss auf den Server hast


    Der sendende Mailserver ist ausserhalb meines Einflussbereichs (ich könnte natürlich versuchen den Admin zu beknien, dass er das Format des Realnames ändert... hat aber glaube ich eher was von Don Quixote und den Windmühlen).

    • Offizieller Beitrag

    Allen Widersprüchen zum Trotz tippe ich auf den GFI! :-x


    Ich bin mal gespannt auf die Info des SBS mit POP Con., denn ich Würde wetten, dass es da geht.
    Ausserdem bitte ich Dich mal folgendes zu testen. Verwende mal Deinen Mailclient (POP3, The Bat) und richte diesen zu Deinem Exchange Server ein. (POP / SMTP Server = interner Exchange) Sende dann so eine Mail direkt an einen internen Benutzer. Dann wird der Empfänger nach meiner Meinung keinen Fehler sehen.
    Ausserdem solltest Du das Diagnoselog im ESM (Eigenschaften Server) hoch setzen, um Eventlog zu sehen was passiert.
    Exchange verschluckt keine Mails, es sei denn Du hast die Filter - Funktion aktiviert, dass so was in die Tonne soll. Dann kannst Du es aber auch nach Aktivierung im Log sehen.


    Gruss
    Heinz

    Ich habe das jetzt doch schon testen können. Kein Unterschied. Der MS-POPConnector holt die Mail ab (steht auch so im Eventlog). Dieses Mal taucht die Nachricht nicht als "M|ller" sondern als "Müller" (anstatt "Müller, Max" <adr@domain.bla>" in der Nachrichtenverfolgung auf. Gleiche Fehlermeldung mit der Erweiterten Warteschlange.


    Das einzige was ich noch als Möglichkeit sehe ist entweder der Spam- oder der Virenfilter von GFI. Vielleicht nimmt dieser die Mail "richtig" raus und gibt sie "falsch" zurück.


    Da dieses Produkt bei einem anderen Kunden nicht mitläuft, werde ich morgen sehen, ob es daran liegt.


    Der Tip mit dem internen Mailen via POP/SMTP ist gut. Das werde ich morgen mal versuchen.


    Danke für Deine Hilfe!

    So. GFI kann ausgeschlossen werden. Habe das grade auf einem SBS2003 mit MS-POPConnector versucht. Gleiches Ergebnis. Jedoch: wenn der Schalter "Absendername beibehalten" nicht gesetzt ist, wird die Mail zumindest zugestellt.


    Aber wie...


    aus FROM: "Müller, Max" <max@mueller.com>
    wird FROM: <Müller>, "Max" <max@mueller.com>


    ...und noch krasser:


    aus FROM: "Müller, Mäxchen" <max@mueller.com>
    wird FROM: <Müller>,
    =?ISO-Gewurstel?= <max@mueller.com>


    (und darüber mockiert sich anschliessend der Spamfilter, weil er sagt "invalid MIME FROM field", wen wunderts?).


    Das ganze ist für mich absolut reproduzierbar, jedenfalls bei POP3-Empfang. Wäre interessant ob andere POP3-Connectoren den gleichen Fehler zeigen.


    Ein interner Versand mit einer derartigen Adresse funktioniert (also mit The Bat eine Nachricht mit dieser Absenderadresse erzeugt & an den Exchange-SMTP im LAN zum Versand, kommt intern einwandfrei an).