21
Exchange Anhänge mit Umlautproblem
Moin zusammen,
Exchange 2016 on premisses, letztes CU
Wenn ich eine Email von einem uralten Linux Server erhalte, sind die Umlaute im Nachrichtentext zwar in Ordnung, jedoch nicht in den Dateianhängen.
Wenn ich diese Nachricht vom Linux Server aus zu einem anderen Konto schicke, das sich z.B. auf M365 befindet, passen die Umlaute.
Die Umlaute sind defekt im Outlook, auf OWA und auf dem iPhone, also ist es ein Transportproblem vom 2016er Exchange und kein Problem, dass der Client nicht richtig dekodieren würde.
Der Body der Email zeigt UTF-8 an, der Text wird ja auch danach richtig dekodiert, eben nur der Anhang nicht:
Wo könnte ich ansetzen?
Danke euch and keep rockin'
Der Mike
Exchange 2016 on premisses, letztes CU
Wenn ich eine Email von einem uralten Linux Server erhalte, sind die Umlaute im Nachrichtentext zwar in Ordnung, jedoch nicht in den Dateianhängen.
Wenn ich diese Nachricht vom Linux Server aus zu einem anderen Konto schicke, das sich z.B. auf M365 befindet, passen die Umlaute.
Die Umlaute sind defekt im Outlook, auf OWA und auf dem iPhone, also ist es ein Transportproblem vom 2016er Exchange und kein Problem, dass der Client nicht richtig dekodieren würde.
Der Body der Email zeigt UTF-8 an, der Text wird ja auch danach richtig dekodiert, eben nur der Anhang nicht:
Subject: =?UTF-8?B?XXXXXXXXXXXXXXXXXXX=?=
From: =?UTF-8?B?XXXXXXXXXXXXX=?= S <linuxserver@meinedomain.de>
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="==Multipart_Boundary_x30901ebexd5381x1dc6x2bd26x1b6x4dx" Wo könnte ich ansetzen?
Danke euch and keep rockin'
Der Mike
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 2482226746
Url: https://administrator.de/forum/exchange-anhaenge-mit-umlautproblem-2482226746.html
Ausgedruckt am: 21.12.2024 um 13:12 Uhr
21 Kommentare
Neuester Kommentar
- Um welche Art Attachments handelt es sich?
- Welcher Mimetype wird als Content-Type im Multipart-Abschnitt für das Attachment aufgeführt? Leider bei deiner Angabe oben nicht ersichtlich.
Das zeigt mir Outlook scheinbar nicht mehr an. Ich mach mich mal an die Recherche, ob man irgendwo den kompletten Inhalt als Protokoll sieht. Oder weisst du wo ich das sehen würde?
Grüße
Grüße
Zitat von @NordicMike:
Das zeigt mir Outlook scheinbar nicht mehr an. Ich mach mich mal an die Recherche, ob man irgendwo den kompletten Inhalt als Protokoll sieht. Oder weisst du wo ich das sehen würde?
Nimm MFCMAPI und öffne die Attachment-Table der Nachricht.Das zeigt mir Outlook scheinbar nicht mehr an. Ich mach mich mal an die Recherche, ob man irgendwo den kompletten Inhalt als Protokoll sieht. Oder weisst du wo ich das sehen würde?
Kannst du die andere Frage noch beantworten?
Es handelt sich um .jpg Bilder. Sie haben ein Umlaut im Dateinamen.
Ich probiere das gleich mal mit MFCMAPI aus.
In der Zwischenzeit habe ich mir auf dem Linux Server die Email angesehen. Die Attachments beginnen mit:
Da oben Fehlt doch die Angabe des Charsets, währen der Text Part ein Charset sehr wohl anzeigt:
Ich probiere das gleich mal mit MFCMAPI aus.
In der Zwischenzeit habe ich mir auf dem Linux Server die Email angesehen. Die Attachments beginnen mit:
--==Multipart_Boundary_x1923d45007d26f427d18cd027037dc46x
Content-Type: application/octet-stream; name="große-welle.jpg"
Content-Description: große-welle.jpg
Content-Disposition: attachment;
filename="große-welle.jpg"; size=11775226;
Content-Transfer-Encoding: base64
/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a
HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy
MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCBPsGcgDASIADa oben Fehlt doch die Angabe des Charsets, währen der Text Part ein Charset sehr wohl anzeigt:
--==Multipart_Boundary_x1923d45007d26f427d18cd027037dc46x
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit Sie haben ein Umlaut im Dateinamen.
Ach so, ich dachte im Inhalt.Eine Charset-Angabe benötigt es bei octet-stream files nicht, ist ja kein lesbarer Klartext sondern pure bytes.
Wenn die Dateinamen Umlaute enthalten aber nicht richtig dargestellt werden dann wurde der Dateiname wohl nicht richtig im Header des Attachments kodiert
z.B. so
Ein vernünftiger Mailer macht das, ältere Implementierungen oder verbuggte machen das nicht. Genauso gibt es Clients die meist ein anderes Default Encoding als UTF-8 eingestellt haben. Google & Co. in Webmailern benutzen meist per Default UTF-8 dort erscheinen dann die Namen auch korrekt.
z.B. so
Content-Type: application/octet-stream; name="=?utf-8?Q?Sch=C3=B6ne_PDF.pdf?="Ein vernünftiger Mailer macht das, ältere Implementierungen oder verbuggte machen das nicht. Genauso gibt es Clients die meist ein anderes Default Encoding als UTF-8 eingestellt haben. Google & Co. in Webmailern benutzen meist per Default UTF-8 dort erscheinen dann die Namen auch korrekt.
Ich mag das MFCMAPI jetzt schon, das wird mein Lieblingswerkzeug :c)
So sieht ein Attachment aus. Der Dateiname wird mit PT_UNICODE dargestellt.
[[imag
e b6eb9def4deaa526a9ad666747febb1a]]
So sieht ein Attachment aus. Der Dateiname wird mit PT_UNICODE dargestellt.
[[imag
Das ist normal weil der Datentyp hier immer Unicode ist.
Entscheidend ist wie Outlook den nicht enkodierten Namen interpretiert. Outlook ist hier strikt wenn der Header nicht als UTF-8 ausgewertet wird kommt es dazu, stell mal explizit auf UTF-8 in den Einstellungen von Outlook.
Ansonsten den alten Linux-Server fixen und den Namen korrekt kodiert in den Header schreiben lassen.
Es gibt Mailserver, die lehnen solche Mails schon im Vornherein ab weil die Umlaute nicht korrekt kodiert sind, denn das ist eine Sicherheitslücke und potentiell vulnerabel.
Entscheidend ist wie Outlook den nicht enkodierten Namen interpretiert. Outlook ist hier strikt wenn der Header nicht als UTF-8 ausgewertet wird kommt es dazu, stell mal explizit auf UTF-8 in den Einstellungen von Outlook.
Ansonsten den alten Linux-Server fixen und den Namen korrekt kodiert in den Header schreiben lassen.
Es gibt Mailserver, die lehnen solche Mails schon im Vornherein ab weil die Umlaute nicht korrekt kodiert sind, denn das ist eine Sicherheitslücke und potentiell vulnerabel.
Ich habe ja oben geschrieben, dass es auch im OWA und auf dem iPhone so aussieht. Ich würde jetzt ungern alle Clients ändern müssen. Das muss am Exchange Transport liegen.
Ich habe nun dem selben Outlook, der am Exchange hängt, noch ein Linux IMAP Konto hinzugefügt und ihm die selbe Email geschickt. Dort zeigt es Outlook und MFCMAPI richtig an:
Ich habe nun dem selben Outlook, der am Exchange hängt, noch ein Linux IMAP Konto hinzugefügt und ihm die selbe Email geschickt. Dort zeigt es Outlook und MFCMAPI richtig an:
Ansonsten den alten Linux-Server fixen
Der Linux Server wird von jemanden anderen administriert. Ich würde ihm gerne sagen was er zu fixen hätte, fehlt irgendwas in einem Header?Zitat von @NordicMike:
Ansonsten den alten Linux-Server fixen
Der Linux Server wird von jemanden anderen administriert. Ich würde ihm gerne sagen was er zu fixen hätte, fehlt irgendwas in einem Header?Hast du meinen Kommentar dazu überlesen?
Das muss am Exchange Transport liegen.
Nein, der jung soll das "Name" Feld des Attachments mit quoted printable richtig kodieren
Zitat von @NordicMike:
Es handelt sich um .jpg Bilder. Sie haben ein Umlaut im Dateinamen.
Content-Type: application/octet-stream; name="große-welle.jpg" Das ist nach 2045 nicht vorgesehen:
token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
or tspecials>
tspecials := "(" / ")" / "<" / ">" / "@" /
"," / ";" / ":" / "\" / <">
"/" / "[" / "]" / "?" / "="
; Must be in quoted-string,
; to use within parameter valuesBesser wäre sicherlich die Anwendung von RFC 2231/2047.
Ich glaube so langsam blicke ich durch, danke an Pretty zur Erinnerung an den Kommentar und mbehrens für die RFC Beschreibung. Lauf RFC muss da also ein utf-8 dazu.
In meinem Fall ist es ja so:
Also fehlt im name="große-welle.jpg" die UTF-8 Codierung. Das kann ich dem Linux Admin auch beibringen, dass das rein muss.
Hier ist der Client der Exchange 2016 z.B. über OWA (und auch Outlook und iPhone mit diesem Exchange Konto).
Outlook und iPhone über M365 und Outlook über das Linux IMAP Konto zeigen es richtig an. Also würde ich dieses gerne auf der Exchange 2016 Seite gerne lösen, damit ich zumindest kompatibel zu M365 und IMAP bin, nach diesen Linux Server die Sinnflut :c)
Kann man dem Exchange 2016 auch beibringen per Default mit UTF-8 zu dekodieren? Alle Google Ergebnise beschreiben nur die Senderichtung, nicht die Empfangsrichtung.
Wenn die Dateinamen Umlaute enthalten aber nicht richtig dargestellt werden dann wurde der Dateiname wohl nicht richtig im Header des Attachments kodiert
z.B. so
Content-Type: application/octet-stream; name="=?utf-8?Q?Sch=C3=B6ne_PDF.pdf?="
z.B. so
Content-Type: application/octet-stream; name="=?utf-8?Q?Sch=C3=B6ne_PDF.pdf?="
In meinem Fall ist es ja so:
--==Multipart_Boundary_x1923d45007d26f427d18cd027037dc46x
Content-Type: application/octet-stream; name="große-welle.jpg"
Content-Description: große-welle.jpg
Content-Disposition: attachment;
filename="große-welle.jpg"; size=11775226;
Content-Transfer-Encoding: base64Also fehlt im name="große-welle.jpg" die UTF-8 Codierung. Das kann ich dem Linux Admin auch beibringen, dass das rein muss.
Genauso gibt es Clients die meist ein anderes Default Encoding als UTF-8 eingestellt haben. Google & Co. in Webmailern benutzen meist per Default UTF-8 dort erscheinen dann die Namen auch korrekt.
Hier ist der Client der Exchange 2016 z.B. über OWA (und auch Outlook und iPhone mit diesem Exchange Konto).
Outlook und iPhone über M365 und Outlook über das Linux IMAP Konto zeigen es richtig an. Also würde ich dieses gerne auf der Exchange 2016 Seite gerne lösen, damit ich zumindest kompatibel zu M365 und IMAP bin, nach diesen Linux Server die Sinnflut :c)
Kann man dem Exchange 2016 auch beibringen per Default mit UTF-8 zu dekodieren? Alle Google Ergebnise beschreiben nur die Senderichtung, nicht die Empfangsrichtung.
Zitat von @NordicMike:
Kann man dem Exchange 2016 auch beibringen per Default mit UTF-8 zu dekodieren?
Das hat nichts mit dem Exchange zu tun, das ist Client-Sache. Optionen => Erweitert => Internationale Optionen => UTF-8 Unterstützung ...Kann man dem Exchange 2016 auch beibringen per Default mit UTF-8 zu dekodieren?
Das hat nichts mit dem Exchange zu tun, das ist Client-Sache
Der Client ist doch auch OWA, also doch Exchange Sache.Ausserdem reagiert Outlook als Client auch richtig, wenn er es von einem Linux IMAP Server abholt statt vom Exchange 2016.
Egal, ich bin jetzt mit der Info, dass der Multipart Teil des Headers nicht UTF-8 kodiert ist an den Linux Admin ran gegangen und warte auf seine Reaktion. Gleichzeitig wäre es schön gewesen, wenn mein Exchange 2016 OWA genau so reagieren würde/könnte als M365 OWA.
OWA ist auch nur ein Client 
.
. 🖖
.wäre es schön gewesen, wenn mein Exchange 2016 OWA genau so reagieren würde/könnte als M365 OWA.
Wäre schön wenn ich mein Auto nicht tanken müsste . 🖖an den Linux Admin ran gegangen
Definitiv besser, solche Mails sind halt non standard. Mein Mailserver nimmt solche fehlerhaften Mails die schon nicht den RFCs entsprechen gar nicht erst an denn die sind teilweise auch potentiell vulnerabel.OWA ist auch nur ein Client
Jedoch im Exchange integriert. Exchange verändert auch den Stream, sodass der selbe Outlook oder iPhone Client, der es über IMAP von einem Linux Server oder von M365 noch richtig empfangen hat, auf einmal über Exchange 2016 nicht mehr richtig empfängt. Der Knoten, in dem die Veränderung stattfindet ist immer der Exchange 2016, also keine Clientsache.Zitat von @NordicMike:
Mailinhalt wird nicht verändert, außer man sagt das dem Exchange explizit.OWA ist auch nur ein Client
Jedoch im Exchange integriert. Exchange verändert auch den Stream, sodass der selbe Outlook oder iPhone Client, der es über IMAP von einem Linux Server oder von M365 noch richtig empfangen hat, auf einmal über Exchange 2016 nicht mehr richtig empfängt. Der Knoten, in dem die Veränderung stattfindet ist immer der Exchange 2016, also keine Clientsache.Mailinhalt wird nicht verändert
Das dachte ich mir auch, nur, ich kann mir nicht erklären warum es der selbe Client von einem anderen Postfach anders ließt?Er hängt ja auch seine Header Zeilen mit seinem Fingerabdruck dazu, also muss etwas stattfinden.
Zitat von @NordicMike:
Er hängt ja auch seine Header Zeilen mit seinem Fingerabdruck dazu, also muss etwas stattfinden.
Das ist nicht der eigentliche Inhalt der Mail sondern nur die Header/Umschlag,Er hängt ja auch seine Header Zeilen mit seinem Fingerabdruck dazu, also muss etwas stattfinden.
Ist dann der Multipart Teil
Teil des Headers oder der Mail, weil RFC 2045/2047 beschreibt nur die Header codierung. Von der Position her hätte ich jetzt gesagt es ist mitten in der Email.
--==Multipart_Boundary_x1923d45007d26f427d18cd027037dc46x
Content-Type: application/octet-stream; name="große-welle.jpg"
Content-Description: große-welle.jpg
Content-Disposition: attachment;
filename="große-welle.jpg"; size=11775226;
Content-Transfer-Encoding: base64
