nordicmike
Goto Top

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:

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

Content-ID: 2482226746

Url: https://administrator.de/contentid/2482226746

Printed on: October 9, 2024 at 13:10 o'clock

1915348599
1915348599 Apr 12, 2022 updated at 09:48:43 (UTC)
Goto Top
  • 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.
NordicMike
NordicMike Apr 12, 2022 at 10:15:53 (UTC)
Goto Top
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
1915348599
1915348599 Apr 12, 2022 updated at 10:57:01 (UTC)
Goto Top
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.

screenshot

Kannst du die andere Frage noch beantworten?
NordicMike
NordicMike Apr 12, 2022 at 11:11:00 (UTC)
Goto Top
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:

--==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/wAARCBPsGcgDASIA

Da 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
1915348599
1915348599 Apr 12, 2022 updated at 11:21:15 (UTC)
Goto Top
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.
1915348599
1915348599 Apr 12, 2022 updated at 11:24:52 (UTC)
Goto Top
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?="

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.
NordicMike
NordicMike Apr 12, 2022 at 11:39:16 (UTC)
Goto Top
Ich mag das MFCMAPI jetzt schon, das wird mein Lieblingswerkzeug :c)

So sieht ein Attachment aus. Der Dateiname wird mit PT_UNICODE dargestellt.

[[imag
screenshot 2022-04-12 133614
e b6eb9def4deaa526a9ad666747febb1a]]
1915348599
1915348599 Apr 12, 2022 updated at 12:13:22 (UTC)
Goto Top
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.
NordicMike
NordicMike Apr 12, 2022 at 12:18:12 (UTC)
Goto Top
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:
screenshot 2022-04-12 141540
NordicMike
NordicMike Apr 12, 2022 at 12:22:22 (UTC)
Goto Top
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?
1915348599
1915348599 Apr 12, 2022 updated at 13:08:29 (UTC)
Goto Top
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
mbehrens
mbehrens Apr 12, 2022 at 18:52:07 (UTC)
Goto Top
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 values

Besser wäre sicherlich die Anwendung von RFC 2231/2047.
NordicMike
NordicMike Apr 13, 2022 updated at 06:55:33 (UTC)
Goto Top
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.

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?="

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: base64

Also 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.
1915348599
1915348599 Apr 13, 2022 updated at 08:16:52 (UTC)
Goto Top
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 ...
NordicMike
NordicMike Apr 13, 2022 at 09:23:27 (UTC)
Goto Top
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.
1915348599
1915348599 Apr 13, 2022 updated at 09:31:13 (UTC)
Goto Top
OWA ist auch nur ein Client face-smile.
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 face-smile. 🖖
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.
NordicMike
NordicMike Apr 13, 2022 at 09:31:05 (UTC)
Goto Top
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.
1915348599
1915348599 Apr 13, 2022 updated at 09:32:21 (UTC)
Goto Top
Zitat von @NordicMike:

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, außer man sagt das dem Exchange explizit.
NordicMike
NordicMike Apr 13, 2022 at 09:38:50 (UTC)
Goto Top
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.
1915348599
1915348599 Apr 13, 2022 updated at 09:47:02 (UTC)
Goto Top
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,
NordicMike
NordicMike Apr 13, 2022 at 11:03:56 (UTC)
Goto Top
Ist dann der Multipart Teil
--==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
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.