Exchange 2003 und Umlaute im Realname

    Schwacher Trost. :) Eigentlich sollten die POP-Connectoren die Mails so ablegen, dass Exchange die auch richtig bearbeiten kann. *grummel*


    Ich habe die Problematik auch an GFI gemeldet, seit dieser Mail Stille :-? von Seiten des Supports. Der GFI POP2Exchange Connector macht aus dem "Müller" nämlich zu allem Überfluss auch noch "M|ller".

    Ich finde es relativ erschreckend, dass auch der MS-eigenen POP3-Connector den gleichen Murks macht, und irgendwie leuchtet mir das "warum" auch überhaupt nicht ein.


    Ich mein... das FROM Feld wurde in meinem Test von TheBat ISO-codiert, und nicht erst vom Exchange. Die Mail ging direkt so an den Exchange-SMTP, und alles ist OK.


    Wenn das also einmal so codiert ist, dann verstehe ich nicht, wieso der POP3-Connector (die Abkürzung "POPCon" benutze ich absichtlich nicht, weil damit ja das Produkt von Christensen gemeint sein könnte *g*) irgendwas vermurkst.


    Denn was geht den POP3-Connector die FROM Zeile an? Eigentlich gar nichts, oder? Der POP3-C. soll in den allermeisten Fällen Mail von einem bestimmten EMail-Account in ein bestimmtes Postfach packen - ganz egal, was in FROM oder TO steht... (jaja, u. U. wird das TO Feld gebraucht, ist meistens aber problematisch, spätestens bei BCC)...


    *grübel*

    Hallo,
    ich habe exakt das gleiche Problem,
    GFI Pop2Exchange und Exch2003. Die Mails verschwinden einfach, wenn ein Umlaut im Realname und ein Komma.
    Lösung 1 war, das SP1 den Badmail-Ordner abschaltete.
    Nach Reaktivierung waren die Mails in Badmail zu finden.
    Dort sah man dann auch, das die From und X-sender Felder kaputt-gequoted wurden.


    Habt Ihr mittlerweile eine Lösung gefunden ????
    Gruss,
    Kanne

    Mir hat das Thema keine Ruhe gelassen und ich habe mich damit inzwischen noch ein bisschen weiter beschäftigt. Nachfolgend meine weiteren Erkenntnisse, vielleicht hilft es jemandem bei der Findung einer anderen Lösung als meiner (siehe unten).


    Der Fehler an sich kann einfach überprüft werden (sowohl mit ME als auch mit dem MS-POP-Connector vom SBS2003): einfach mal den SMTP-Service anhalten. Dann Mails runterladen. Ins Pickup-Verzeichnis schauen - zerbröselte FROM Header (im Falle von ME wird auch noch ein X-SENDER Header eingefügt, der ist gleichfalls kaputt). Zum Vergleich kann man (im Falle von ME) dann mal das Log unter %PROGRAMFILES% \ GFI \ MailEssentials \ DebugLogs \ pop-log-des-jew.-nutzers.log anschauen - in der Mailsession steht die Mail genau so drin wie sie runtergeladen wurde.


    Der Fehler dieser Programme ist, dass sie den Realname-Teil des FROM Headers, wenn dieser ISO-codiert ist, nicht (gemäss RFC) als sog. "atom" behandeln, also eine Einheit (alle verwendeten Buchstaben gehören zu dieser Einheit, es ist Sache des MTA zur weiteren Verarbeitung/Anzeige ggf. nach der Decodierung wieder Anführungszeichen zu ergänzen).


    Ich habe testweise eine Mail mit 8bit-Headern erzeugt, diese wurden dann von einem Gateway "auf dem Wege" ISO-codiert (kommt aufs Gateway an), und scheinbar sind einige Gateways so schlau, dann einfach zusätzliche Anführungszeichen zu ergänzen - mit derart codierten Namen (also die Anführungszeichen auch im ISO-codierten Teil enthalten) haben die beiden POP-Connectoren keine Probleme mehr. Darauf kann man sich aber nicht verlassen, und die Möglichkeit der Einflussname auf die Header des Absenders dürften ja allgemein gering sein... :-?


    ABER! Das Problem tritt (jedenfalls bei den von mir untersuchten Systemen, das sind nur drei) immer dann auf, wenn auf dem Exchange-Server (aus welchem Grund auch immer) ein Outlook installiert ist (oder mal war). Die Deinstallation von Outlook von der Exchange-Maschine (hat ja eigentlich auch nix da drauf verloren) verändert das Verhalten unter Umständen - z. B. derart, dass die Mails mit verkrüppeltem FROM Namen doch zugestellt werden - oder aber, wenn sie vorher mit den kaputten Namen zugestellt wurden, dann nicht mehr zugestellt werden. Ob das irgendwas mit den jeweiligen MAPI-DLLs zu tun hat konnte ich nicht nachvollziehen, nach dem Entfernen von Outlook sind dessen DLLs jedenfalls nicht mehr vorhanden.


    Abhilfe habe ich mittlerweile für den einen Kunden durch einen anderen POP-Connector geschaffen. Ohne Werbung machen zu wollen... "POPCon" von Christensen Software hat mit diesen Mails kein Problem. Der augenscheinlichste Unterschied ist (ich hoffe ich rede jetzt keinen Mist), dass POPCon die Mails nicht ins Pickup-Verzeichnis ablegt, sondern per SMTP an den Exchange übergibt (anonymer Zugriff muss dazu ermöglicht sein, was bei einem Exchange der über POP3 Mails empfängt kein Problem sein dürfte, da Port25 eingehend an der Firewall ja nicht geöffnet ist... oder sein sollte). So nebenbei beherrscht POPCon auch eine sog. "komplexe Zeitplanung" mit der man z. B. nur innerhalb der Arbeitszeiten POP3-Abrufe macht. Ausserdem kann man einzelne POP3-Konten schnell Ein-/Ausschalten, ohne das Konto zu löschen - gefällt mir in Summe sehr gut, das Produkt.


    Noch nicht getestet habe ich was passiert, wenn ME nicht auf der Exchange-Maschine läuft.

    Hi,
    schönen Dank für die Antworten.
    Natürlich versuchen wir möglichst viele Kunden auf feste IP und auf SMTP-Zustellung umzustellen.
    Deshalb fehlt mir ja auch ein bischen die Experimentierbasis. Werde mal auf Basis des Pickup-Dirs noch mal testen.
    Outlook ist auf den Servern definitiv nicht draufgewesen.
    Ich habe ein bischen den verdacht, dass der Fehler erst seit dem SP1 von Exchange 2003 vorhanden ist. Exchange 2000 ist nicht betroffen.
    Wenn es im Pickup schon defekt ist muesste es ja GFI sein. Da MS-POP das gleiche Problem hat könnte es eine reingezogene MS-dll sein, die mit SP1 kam.
    Vielleicht werde ich mal GFI kontaktieren...


    Bis später,
    kanne

    Ergänzung: der Hotfix behebt einen Fehler von Exchange - ich denke also nicht, dass die Probleme der POP-Connectoren von GFI & MS damit gleichfalls behoben werden...

    Hi,
    ich hab den Hotfix heut erhalten und bei einem Kunden getestet. :(
    Leider keine Änderung.
    Es hört sich aber absolut nach dieser Sache an.
    Evtl. gleicher Fehler in anderer .dll.


    Bis später