Das Notes Forum
Domino 9 und frühere Versionen => ND8: Administration & Userprobleme => Thema gestartet von: tron55 am 24.05.11 - 14:33:19
-
Hallo,
ich habe mir einmal komplett alle Threads zum leidigen Thema Umlaute in Lotus Notes durchgelesen.
Leider hat es mir nichts gebracht und es fehlt auch irgendwie der methodisch sinnvolle rote Faden in den Vorgehensweisen.
Ich versuche mal mein Problem zu beschreiben...
Ich habe aktuell das Problem das ich bei ca 100 Usern etwa 5 habe deren Umlaute nicht richtig dargestellt werden.
Wir benutzen Lotus Notes 8.5 (Client 8.5.2) und auch webnotes über einen beliebigen Browser.
Bei den ~5 Usern bei denen Probleme auftreten sind die Mailempfänger mehrere unterschiedliche Versicherungen
(also nix Wald-und-Wiesen-Server) die nichts miteinander zu tun haben.
Folgendes habe ich versucht um dem Problem auf den Grund zu gehen:
1) Ich habe in der Arbeitsumgebung überprüft das unter 'Format for messages addressed to internet addresses' auch 'MIME Format' angegeben ist.
2) Ich habe unter 'Preferences ' 'Mail' 'Internet' das 'Format Internet-Style for Reply or Forward' auf Internet mail Format: HTML and Plain Text und Multilingual Internet mail format: Use best match gestellt.
3) Ich habe mir den Mailheader genau angesehen
Die Pagesource sieht meiner Meinung nach valide aus.
Das Einzige was mir komisch vorkommt ist das hier
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"
Die Mail selbst hat nämlich keine Anhänge.
Vielleicht fällt ja jemandem noch etwas ein. Mir gehen leider die Ideen aus.
Gibt es möglicherweise irgendeine Einstellung direkt am Server die ich nicht kenne, auf die man noch achten muss?
-
Redest Du von der Darstellung des MailBody, des Usernamens, der Mail-Adresse des Empfängers oder Senders?
Was ist denn mit den Umlauten? Screenshot?
Web oder Notes-Client? Eclipse oder Basic?
So das wars was mir im 1. Wurf an Fragen so hochkam ...
Grüße David
-
Da hab ich auch noch welche:
1) Gehts um eingehende oder ausgehende Mails?
2) Wo kommt der Inhalt her? Eingetippt, von Word, ... über Copy & Paste eingefügt, eine Antwort, zu der was dazugetippt wird, .... ?
-
Das Einzige was mir komisch vorkommt ist das hier
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"
Die Mail selbst hat nämlich keine
Ja und? Das sagt ja nur, dass der Inhalt der Mail vom Typ "text/Plain" & vom Charset UTF8 ist und für die Übertragung base64 encoded wird. Das ist ganz super schön und hat nix mit Anhängen zu tun (MIME ist nicht nur für Anhänge zuständig).
-
was steht denn in den Benutzervorgaben unter Mail -> Internet -> Format für Antworten und Weiterleitungen ...?
-
Prima.
Habe mich schon gewundert warum keiner antwortet.
Dabei habe ich vergessen den Benachrichtigungshaken zu setzen :'(
Ich dachte ich hätte an alles gedacht, aber die Punkte die ihr nachfragt habe ich gar nicht berücksichtigt.
Also von oben nach unten:
@atbits
Ja es geht um den Mailbody.
Wir haben auch Absender mit Umlauten im Sendernamen; die werden aber korrekt dargestellt.
Als Client kann ich das ganze auf den 8.5.1er eingrenzen, dort sowohl Eclipse als auch Basic.
Als Ersatz für den Screenshot kann ich dir eine verfremdete Mail anbieten (copy&pasted)
Hallo Herr R䴨ner,
vielen Dank für das angenehme Telefongespr䣨...................
Der Stundensatz wird sich wie beschrieben erh ..................
Nachtr䧬ich wird folgender Zusatz erg䮺t : "......................
Den Skontoabzug kn gleich belassen,
Kn ....ob Sie das kl䲥n kn?
Grߥ und sch Wochenende aus Graz
@m3
Es geht um ausgehende Mails. Eingehende Mails werden korrekt dargestellt.
Der Inhalt ist direkt eingetippt worden.
Es handelt sich dabei immer meistens um Antworten auf eine Mail.
Ich hatte aber auch schon Mails da war das keine Antwort sondern quasi ein 'Erstkontakt'
Ok dann war ich falsch informiert.
Ich dachte ich habe mal irgendwo gelese das nur base64 Encoded wird wenn die Mail Anhänge hat.
Trotzdem seltsam, denn wenn ich mir die Header anderer Mails anschaue sind die so gut wie nie base64 .
-
@Neo
Dort steht bei uns das Gleiche wie bei dir.
Update:
Muss mich berichtigen vielleicht ist es ja wichtig.
Es steht nicht exakt das Gleiche dort.
Als Format für mehrsprachige Internetmails steht dort :Best match.
Sollte trotzdem das Selbe rauskommen oder?
@Alle
Schon mal danke für's Kopfzerbrechen.
Das ist echt ein Ätzproblem ;)
-
wir haben keine Probleme mit Umlauten. UTF-8 ist Standard. Ich würde es explizit vorgeben und nicht dem "Best match" überlassen.
siehe auch http://de.wikipedia.org/wiki/UTF-8
-
Wie gesagt - lass Dir mal von einem Empfänger eine Mail im Source schicken. Entweder erkennst Du daran selber das Problem oder poste den Code (anonymisiert) hier.
-
Hallo,
sorry ich war im Urlaub zwischendurch.
Anbei eine anonymisierte Source
Received: from gw.extern ([215.1.2.3])
by www.firma.com (Lotus Domino Release 8.5)
with ESMTP id 2011050917135-26855 ;
Mon, 9 May 2011 17:13:54 +0200
Received: from gw.extern.extern (root@gw.extern.extern [215.3.4.5])
by gw.extern (8.14.3/8.14.3) with ESMTP id p49FD3015013;
Mon, 9 May 2011 17:13:55 +0200
Received: from nospam.gwextern.net (nospam.gwextern.net [215.6.7.8])
by gw.extern.extern (8.14.3/8.14.3) with ESMTP id p49F002184;
Mon, 9 May 2011 17:13:43 +0200
Received: from mail.fremdfirma.com (mail.fremdfirma.com [212.0.0.1])
by nospam.gwextern.net (8.14.2/8.14.2) with ESMTP id p4DeRs029436;
Mon, 9 May 2011 17:13:43 +0200
Received: by mail.fremdfirma.com (Fremdfirma Mail-System, from userid 102)
id 4C68721E; Mon, 9 May 2011 17:13:40 +0200 (CEST)
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
mail9.fremdfirma.com
X-Spam-Level:
X-Spam-Status: No, score=-1.7 required=6.0 tests=AWL,BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,HTML_OBFUSCATE_05_10,T_RP_MATCHES_RCVD
autolearn=no version=3.3.1
X-Spam-Virus: No
Received: from mail.fremdfirma.com (localhost [127.0.0.1])
by mail.fremdfirma.com (Fremdfirma Mail-System) with ESMTP id 58685301BA;
Mon, 9 May 2011 17:13:36 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=fremdfirma.com; h=
mime-version:subject:date:message-id:in-reply-to:references:from
:to:cc:content-type; s=selector1; bh=h0m2ozagC8ml5cE6d2BiX2c
=; b=dD6h6pioDWMeJ3IMOeICAFotM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=fremdfirma.com; h=
mime-version:subject:date:message-id:in-reply-to:references:from
:to:cc:content-type; q=dns; s=selector1; b=OdmRvy22dMz5B59Ov
mpsdCZP
oztRVS7w5ZcqHFSJpfgHfw=
Received: from xx9.fremdfirma.com (intern.postfix.fremdfirma.com [172.16.1.1])
by mail.fremdfirma.com (Fremdfirma Mail-System) with ESMTPS id 4E3021E;
Mon, 9 May 2011 17:13:36 +0200 (CEST)
Received: by p3.fremdfirma.com (Fremdfirma Internal Mail-System, from userid 1001)
id 2D788400B3; Mon, 9 May 2011 17:13:36 +0200 (CEST)
Received: from mail35.fremdfirma2.de (s28.exchange.fremdfirma.com [172.16.3.1])
by xx9.fremdfirma.com (Fremdfirma Internal Mail-System) with ESMTPS id 1EFCD40047;
Mon, 9 May 2011 17:13:36 +0200 (CEST)
Received: from server1.hoster.dom.net (hoster.dom.net [10.1.2.3] (may be forged))
by mail35.fremdfirma2.de with ESMTP id p49FDZg22420;
Mon, 9 May 2011 15:13:35 GMT
Received: from server2.hoster.dom.net ([10.1.2.4]) by hoster.dom.net with Microsoft SMTPSVC(6.0.3790.3455);
Mon, 9 May 2011 17:13:35 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
MIME-Version: 1.0
Subject: AW: Gurkensalat
Date: Mon, 9 May 2011 17:13:34 +0200
Message-ID: <E54370E7355F.dom.net>
In-Reply-To: <OFA75F4BCEB@firma.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Gurkensalat
Thread-Index: AcwMDJ0MPUehDIfsSRCvpI+VfAxgCTPw7g
References: <OFA75F4B8F.66DD5CEB-ONC1257888.00585636-C1257888.005BC8CA@firma.com>
From: "H ,Gunther" <Guntherh@fremdfirma.com>
To: <Klaus K@firma.com>
Cc: <trudhild b@firma.com>,
"Ulf M" <Ulf@M.com>
X-OriginalArrivalTime: 09 May 2011 15:13:35.0614 (UTC) FILETIME=[AABBA9E0:01CC0E5B]
X-AntiVirus: checked by Avira MailGate (version: 3.1.2; AVE: 8.2.4.228; VDF: 7.11.7.200; host: xx9); id=3011-pRCjY5
X-Spam-Score: -0.008 HTML_MESSAGE,HTML_OBFUSCATE_05_10,T_RP_MATCHES_RCVD
X-OwnSenderRelay: nospam.gwextern.net (215.6.7.8)
X-Scanned-By: MIMEDefang 2.67 on 215.3.4.5
X-MIMETrack: Itemize by SMTP Server on Server1/firma(Release 8.5|December 05, 2008) at
09.05.2011 05:13:54 PM,
Serialize by Notes Client on Klaus K/firma(Release 8.5.2|August 10, 2010) at
24.05.2011 16:45:02,
Serialize complete at 24.05.2011 16:45:02
X-TNEFEvaluated: 1
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01CC0D63FC"
------_=_NextPart_001_5D63FC
Content-Transfer-Encoding: base64
Content-Type: text/plain;
charset="UTF-8"
SGFsbG8gS2FpLA#vielkeyumnichts#Qo=
------_=_NextPart_001_01CC0E5B.A3FC
Content-Transfer-Encoding: base64
Content-Type: text/html;
charset="UTF-8"
PGh0bWwgeG1sbnM6dj0i#vielkeyumnichts#1sPg==
------_=_NextPart_001_01CC0E5B.A63FC--
So viel zum Header.
Der Body sieht beim Sender ganz normal aus und kommt dann so zurück wie ich das euch schon gepostet habe.
Der Header sieht für mich ok aus.
Langsam gehen mir die Ideen zu dem Thema aus.
Mit wachsender Verzweiflung klammert man sich an jedem Strohhalm fest ..
Im Serverkonfigdokument gibt es einen Eintrag der bei uns so aussieht
Character Set
Use UTF-8 for output: No
Use UTF-8 for HTML forms: Yes
Macht es Sinn UFT-8 for Output mal auf "YES" zu setzen?
-
Das bezieht sich nur auf das Rendering vom http-Task.
Du mußt im Configuration-Dokument schauen unter Routing ...
-
Ein Routing Tab gibts nicht in meinem Configuration Dokument.
Kann es sein das die Mime Settings dazwischenschießen? (Siehe Screenshots)
-
Kleines Update:
Ich habe noch einen Notes Smarthost der ebenfalls zum Mailversand genutzt werden kann
(Je nach Verbindungsdokument das Benutzer ausgewählt haben)
Auf diese Möglichkeit bin ich bei der Fehlersuche bisher noch gar nicht gekommen, weil die meisten
Anwender bei uns auf dem Hauptserver arbeiten.
Auf jeden Fall fehlt auf diesem Smarthost das Häkchen im Basic Tab des Configuration Dokuments bei
"International MIME Settings for this Document"
Jetzt ist eigentlich nur noch die Frage ob ersteres Configdokuemnt oder zweiteres die richtigen Settings hat?...
PS:*schaut erwartungsvoll in die Menge* bitte bitte lass es das gewesen sein ...
-
Na...
Keiner eine Idee .. ???
-
Status Update: mein bisheriges rumspielen an den MIME Settings hat mir nichts gebracht.
Wahrscheinlich liegt es also doch an etwas anderem. :-:
-
Ok,
ich habe nun bei einem Betroffenen das Roaming deaktiviert, damit nichts in irgendwelchen personal Files geroamed wird
und anschließend habe ich den Client komplett neu aufgesetzt. Hat auch nichts geholfen.
Im HTML Teil wird aus irgendeinem Grund mit html entities ergänzt also konkret
ߥ und 䣨.
Das sieht als Ergebnis dann so aus (siehe screenshot )
Die Zeichen auf dem Screenshot waren mal äöüß usw.
So langsam nervt das gewaltig.
-
Bekanntlich stirbt die Hoffnung ja zu Letzt, daher anbei nochmal ein Screenshot von der Mail wie die bei einem unserer Zulieferer ankam
Warum tut der das mit den komischen Quotes da :(?
-
Da es den Thread nun schon einen Monat gibt habe ich die Hoffnung mal aufgegeben das noch jemand kommt der sich mit Encoding gut auskennt.
Da scheinbar die Mail selbst und das Erzeugen des HTML Krams das Problem ist, würde ich nun gerne versuchen dem Notes Client zu sagen
das er einfach Plain text schicken soll.Wie das genau funktioniert habe ich scheinbar noch nicht wirklich rausgefunden.
Wenn ich auf dem Server in den Configuration Settings unter MIME - Conversion Options - Outbound den Message Content auf from
Notes to Plain Text stelle, sollte man meinen das Notes nur noch in Plain Text umwandelt und nicht mehr HTML Mails bastelt - dem ist leider nicht so.
Ebenso bringt es nichts ,wenn ich direkt am Client unter Mail - Internet - Internet Format : nur einfacher Text einstelle.
Sobald ich Ok geklickt habe und dort wieder reingehe steht es wieder auf hmtl und plain text.
Hat jemand einen Tipp?
-
Nur um das nochmal klar zu stellen:
1) Das Problem tritt nur bei EINIGEN EMPFÄNGERN auf? Andere Empfänger - von den gleichen Absendern - haben das Problem (bei gleicher Mail) nicht?
2) Könnt Ihr das Problem mit Gmail, gmx, ... nachstellen?
3) Haben die Empfänger mit Problemen alle Exchange Outlook? Wenn ja, welche Versionen?
-
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.
-
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.
-
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 8) 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. ::)
-
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 >:D
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 ;D
LG
mike
-
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
-
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 . :P