Sch[]i? Encoding!

[tron55]

1) Das ist halt super schwer festzustellen. Man bekommt ja nicht immer eine Rückmeldung vom Kunden
"Hey deine Mail sieht scheisse aus" und nachfragen ist in den meisten Fällen auch nicht praktikabel.

Feststellen kann ich definitv
- es tritt   nicht immer auf wenn die Leute mit dem Problem mailen, manche mails kommen auch prima an
- es gibt Empfänger die die Mails normal erhalten aber ob das die gleiche Mail ist kann ich nicht sagen .


2) Wenn wir an web.de und googlemail mailen haben wir diese Probleme nicht.
Ebenso habe ich als MUA ein Outlook2010 an meinem googlemailaccount kleben. da wird auch alles prima dargestellt
wenn jemand aus der Firma eine Mail schickt.


Blöd ist halt nur das einige Kunden von uns Exchange nutzen und mit anderen Zulieferen keine Probleme haben.

Mir würde es schonmal unheimlich helfen wenn mir jemand sagen kann ob ich im Configuration Dokument unter MIME alles richtig gemacht habe.

Und das nächste was zu klären wäre  : Gibt es irgendein Setting das nur Personenbezogen gilt das diese Zeichenkonvertierung nochmal regelt und möglicherweise die Mime settings überschreibt.
Da würde erklären warum bei frisch installierten Rechnern mit frisch installiertem Notes, das Problem immernoch konsequent auftritt.

Wenns nicht an den Serversettings liegt muss es an Clientsettings liegen die irgendwo in der Mailfile  oder sonstwo des Users gesetzt sind.

[tron55]

Vergleichmal die "Optik" der Sourcen, zwischen dem, was bei den Empfängern ankommt, wo die Mail fehlerhaft ist und dem, was beispielsweise bei Gmail, ... ankommt.

Wenn die sich in der Struktur (den einzelnen MIME-Parts) unterscheiden, dürfte bei den Empfängern der Anit-Virus/Spam die Mails umschreiben => deren Problem, nicht Deines.

Die Idee ist gut aber..geht leider nicht .
Die Sourcen von Empfängern die durch das Problem betroffen sind,  sind für mich nicht erreichbar.

Grund:
Outlook 2003 kann (soweit ich das weiß) keine Mailsource anzeigen ohne etwas an der Registry zu drehen.
Ich könnte also dem User der betroffen ist gar nicht sagen "schick mir mal die Source zurück"


Somit habe ich nur die Möglichkeit mir die zerstückelte Mail zurückzuschicken zu lassen von dem Outlookuser und das bringt mir auch nichts (sieh post weil da nur massig Header zu sehen ist aber kein Mailbody.  


edit: bei outlook 2010 geht es , da klickt man einfach in die Mail. Dummes 2003. 

[tron55]

Hi,

nach langem Hin und Her habe ich das Problem gelöst.

Um den Ganzen Thread nicht zu rezitieren, mal eine kurze Zusammenfassung.

Problembeschreibung:
- Umlaute wurden bei Mails von intern nach extern nicht korrekt dargestellt .
Teilweise waren es einfach andere Schriftzeichen und teilweise wurden die Umlaute einfach komplett weggelassen.
- Alle Mails gingen UTF 8 raus, aber beim Empfänger waren dann alle Umlaute nochmal quoted-printable konvertiert und sahen dann entsprechend komisch aus.

Also versuchte ich den Fehler erstmal bei uns am Client und Server einzugrenzen.
Intern musste ich folgendes feststellen:

Analyse:

-> Server
Am Server konnte ich unter "Nachrichten" - > "Konfiguration" -> <das jeweilige Serverdokument> -> "mime" -> "Settings by Character Set Group" hin und herstellen wie ich wollte, da gab es keinen Effekt der bemerkbar gewesen wäre.
(( Mal davon abgesehen ist die Gui dort super schlecht gemacht.
Wenn man zb Unicode auswählt zeigt er nur an was er nehmen WÜRDE wenn die Mail in Unicode weggeschickt werden würde; ob er die in Unicode rausschickt, wird aber auf einer ganz anderen Baustelle entschieden ... sehr verwirrend))

Es wurde mir also irgendwann klar, das in diesem Fall der Client das letzte Wort haben muss und die Serversettings allenfalls als Template fungieren; diese werden scheinbar initial nach der Installation und vor allem einmalig am Client gesetzt.

Also schaute ich mir die Clients mal an.

->Clients

- der Fehler trat bei allen "neu" aufgesetzten Clients auf.
- Leider trat er nicht immer bei den neuen Clients (zu 90% aber halt nicht immer) auf.
Damit ist das Problem nicht 100% reproduzierbar

Alles in Allem also wirklich top Voraussetzungen den Fehler zu finden  

Trotzdem bestärkte mich das in meiner These das die Serversettings nur als Template fungieren und initial gesetzt werden. Prüfen konnte ich das nicht, weil die Settings nirgends editierbar zugreifbar sind am Client.

Lösung:

Schlussendlich habe ich
a) per Richtlinie unter  "Mail"->"Internet" -> "Mehrsprachige Internet Mail" allen Benutzern UTF-8 vorgegeben.
b) die (vermutlich!) initial einmalig festgesetzten Charsets am Client explizit übrschrieben über "Lokales Adressbuch"-> "Erweitert" -> "Intern. Mime Settings" -> "new intern. mime setting".
Dort habe ich "western" (nimmt unser Server) für den Body  als "UTF8" und Konvertierung "Keine" festgelegt.

Nun funktioniert es bei mir.
Ich hoffe das hilft dem Nächsten, das ist echt ein sehr beschissenes Problem  

LG
mike

[koehlerbv]

Danke für de Rückmeldung, Mike - von sowas lebt AtNotes ganz wesentlich!

Allerdings sind die von Dir gemachten Einstellungen m.E. das nachziehen des Standards (okay, das ist andererseits auch sehr, sehr sinnvoll - es gibt ja immer "Spielfritzen"). Genauso verhält sich nämlich der Domino und vor auch die Clients standardmässig. Aber - wie gesagt - die Spielfritzen ... Ich habe da auch schon die schrägsten Sachen gesehen, denen man mit Policies glücklicherweise meist sehr einfach Herr werden kann.

Bernhard

[tron55]

Ehrensache.
Ich hoffe der Nächste quält sich weniger.
Ich war schon kurz vorm kapitulieren.  

Das mit den Richtlinien ist eine gute Idee , da werde ich nochmal genau nachschauen, ich hatte genau die Settings für die Character Sets bisher nirgends gefunden.
Die Alternative für mich wäre nämlich das an jedem Client von Hand umzustellen und das wäre nicht so sexy .