IMAP4 mit Mac OS-Mails

Diese Seite zählt wieder zum Kuriositätenkabinett von Exchange. Ein Apple Client (MacOS oder IPhone) sendet eine Multipart/Mime-Message an eine sekundäre Adresse an ein Exchange Postfach und wenn diese per IMAP4 abgerufen wird, ändert sich die Empfängeradresse und das Mailformat, was dann eine Weiterverarbeitung anhand des eigentlichen Empfängers verhindert. Diese Seite versucht die Zusammenhänge zu erläutern.

Exchange und IMAP

Mails über das Internet werden per SMTP übertragen und bestehen aus einem "Envelope", d.h. dem Umschlag anhand dessen die Mailserver die Nachricht routen und der eigentlichen Nachricht im RFC-822 oder neueren RFC-5822-Format. Die Nachricht selbst teils sich ein einen Header und einen Body auf. Als Anwender sehen Sie auf dem Header eigentlich nur den Absender (From:) und die Empfänger (To: und CC:), den Betreff, das Datum und ggfls. eine Priorität. Der Body war früher einfach die Text-Mail, aber heute darf eine Mail auch formatiert sein und Anlagen enthalten. Daher gibt es mit MIME eine Definition wie unterschiedliche Inhalte im Body so hinterlegt werden, damit möglichst viele Anwendungen sich gleich verhalten. Für meine Tests habe ich eine etwas komplexere MIME-Mail erstellt, die zwei verschachtelte MIME-Blöcke hat. Die Quelldatei können Sie sich hier einfach herunterladen:

imap_mit_macos_mails.txt
Achtung: Diese Testdatei triggert eine IMAP4-Umschreibung. Lesen Sie vorher diese Seite.

Hier der logische Aufbau der Testmail.

Sie können diese Mail z.B. per "TELNET" an einen Mailserver einliefern.

Zuerst habe ich die Mail natürlich per SMTP an meinen Exchange Server im UCLABOR gesendet und per OWA angeschaut.

Die Anlage "ATT00001.html mit 317 Bytes hatte nur folgenden Inhalt:

Boundary2 HTML UTF8

Exchange bzw. OWA zeigt also den Text-Body gar nicht an und dann den ersten Nachrichten Text aus dem eingebetteten MIME-Container und die Anlage. Der zweite Body aus dem MIME-Container wird als Anlage angezeigt. Thunderbird macht dies anders.

Thunderbird entnimmt ebenfalls die Absender und Empfänger aus den To/From-Feldern im Header und der "text/plain"-Abschnitt ist auch hier erst einmal komplett unsichtbar. Die beiden "text/html"-Abschnitte werden aber untereinander gehängt angezeigt und die Anlage im Fußbereich angeboten.

Für die folgenden Test habe ich mir eine Text-Datei mit der Mustermail in Notepad geöffnet und per TELNET mit MAIL FROM und RCPT TO und DATA die SMTP-Kommunikation vorbereitet und dann die Mail über die Zwischenablage angehängt. Denken Sie bei solchen Tests immer, dass Sie in der Mail entweder die MessageID oder das Datum ändern, da ansonsten die Exchange Duplicate Message-ID-Erkennung zuschlägt und die Zustellung unterbleibt. Sie finden dieses Verhalten im Messagetracking:

Sie sehen hier gut, dass es hier "DUPLICATEDELIVER" gab, obwohl sich der Betreff, Sender oder Empfänger geändert haben.

Mac OS triggert Rewrite

Bei einer Analyse bei einem Kunden haben wir einen Fehler nachverfolgt, bei dem die Mail beim Abruf per IMAP "anders" aussieht als beim Lesen in OWA oder Outlook. Die Mail entspricht dem Muster von oben mit einem Unterschied:

Mime-Version: 1.0 (Mac OS)

Der Header "Mime-Version" hat einen UserAgent addiert bekommen. und das hat deutliche Auswirkungen auf den IMAP4-Anruf. Ich habe nur nur ausschnittsweise die relevanten Header nebeneinander gestellt:

IMAP-Abruf OWA-Header 
From: P2-Sender <P2sender@msxfaq.de>
To: P2-Recipient <P2-Recipient@msxfaq.de>
Subject: Betreff17 MAC OS
Thread-Topic: Betreff17 MAC OS
Thread-Index: AQHap79DyDC8jBGxbUKYD3pbVAoNlA==
Date: Mon, 1 Jan 2024 11:34:56 +0100
Message-ID: <messageid017@msxfaq.de>
Content-Language: de-DE
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: multipart/mixed; boundary="_002_messageid017msxfaqde_"
MIME-Version: 1.0

--_002_messageid017msxfaqde_
Content-Type: text/html; charset="utf-8"
Content-ID: <25D173A53BE0CF4F8024A4FE76F84882@UCLABOR.DE>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdj5IVE1MIFVT
QVNDSUkgPC9kaXY+DQo8ZGl2PkJvdW5kYXJ5MiBIVE1MIFVURjggPC9kaXY+DQo8L2JvZHk+DQo8
L2h0bWw+DQo=

--_002_messageid017msxfaqde_
Content-Type: application/pdf; name="pdfdatei.pdf"
Content-Description: pdfdatei.pdf
Content-Disposition: attachment; filename="pdfdatei.pdf"; size=294;
	creation-date="Thu, 16 May 2024 18:31:26 GMT";
	modification-date="Thu, 16 May 2024 18:31:26 GMT"
Content-ID: <ac0c22ad-53a3-4ceb-959c-203bc74748d7@UCLABOR.DE>
Content-Transfer-Encoding: base64

Dummytestnotworking=

--_002_messageid017msxfaqde_--
 
From: P2-Sender <P2sender@msxfaq.de>
To: P2-Recipient <P2-Recipient@msxfaq.de>
Subject: Betreff17 MAC OS
Date: Mon, 1 Jan 2024 12:34:56 +0200
Message-ID: <messageid017@msxfaq.de>
Content-Type: multipart/alternative; boundary="Boundary1"
MIME-Version: 1.0 (Mac OS)
Return-Path: p1sender@msxfaq.de
X-MS-Exchange-Organization-AVStamp-Enterprise: 1.0
X-MS-Exchange-Transport-EndToEndLatency: 00:00:08.7814929
X-MS-Exchange-Processed-By-BccFoldering: 15.01.2507.039






<body in OWA nicht im RAW-Format sichtbar>

Bei den Headern in OWA können Sie noch folgendes erkennen:

Content-Type: multipart/alternative; boundary="Boundary1"

Es handelt sich also um eine MIME-Message und da die Boundary nicht verändert wurde, gehe ich davon aus, dass die Mail unverändert im Postfach liegt. Wenn ich nun aber die IMAP4-Seite anschaue, dann habe ich den kompletten Quelltext und und hier hat Exchange anscheinend die Mail neu zusammengebaut. Der Content-Type ist hier.

Content-Type: multipart/mixed; boundary="_002_messageid017msxfaqde_"

Es ist als keine Multipart/alternative sondern gleich eine MultipartMixed. Der "Text Only" Body ist komplett wegrationalisiert worden und meine HTML-Nachricht aus der Boundary2 wurde BASE64.codiert. Auch fehlt der Header zum "Return-Path" mit dem P1-Absender aus dem SMTP-Envelope.

Um auszuschließen, dass Thunderbird hier etwas umgerechnet hat, habe ich den IMAP4-Abruf auch per WireShark über eine temporär unterschlüsselte Verbindung im Labor mitgeschnitten und die gleichen Header gesehen. Dann habe ich natürlich angefangen, die Original-Mail immer wieder zu verändern, bis das Verhalten aufgehört hat. Letztlich ist es der Inhalt von "Mime-Version", der das Verhalten beim IMAP4-Abruf betrifft. Folgende Header habe ich versucht

Mime-Version: 1.0                                            -> Mail wird NICHT umgeschrieben
Mime-Version: 1.0 (Mac)                                      -> Mail wird NICHT umgeschrieben
Mime-Version: 1.0 (Mac OS)                                   -> Mail wird umgeschrieben
Mime-Version: 1.0 (MAC OS)                                   -> Mail wird umgeschrieben
Mime-Version: 1.0 (Macs OS)                                  -> Mail wird NICHT umgeschrieben
Mime-Version: 1.0 (Mac OS X Mail 16.0)                       -> Mail wird umgeschrieben
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\))  -> Mail wird umgeschrieben
Mime-Version: 1.0 (Mac X OS Mail 16.0 \(3774.500.171.1.1\))  -> Mail wird NICHT umgeschrieben

Interessant: Wenn Sie eine Mail per IPhone senden, dann ist die Mime-Version auch abweichend von dem, was alle anderen Mailclients machen und in der RFC empfohlen wird.

Mime-Version: 1.0 (1.0)

Anscheinend hat Microsoft im Exchange IMAP4-Service eine Logik eingebaut, dass eine Mail beim Abruf per IMAP4 von Exchange neu zusammengestellt wird, wenn in der "Mime-Version" der String "Mac OS" enthalten ist. Der String ist nicht case-sensibel

Mac OS und TextOnly Message

Ich habe dann einmal die Gegenprobe mit einer reinen "TextOnly"-Mail gemacht, d.h. in der folgenden Form:

From: P2-Sender <P2sender@msxfaq.de>
To: P2-Recipient <P2-Recipient@msxfaq.de>
Subject: Betreff20
Date: Tue, 01 Jan 2024 12:34:56 +0200
Message-Id: <messageid020@msxfaq.de>
Mime-Version: 1.0 (Mac OS)

Nur Text

Hier hat Exchange nichts umgeschrieben. Die Sonderbehandlung könnte nur Mac OS in Verbindung mit MIME-Messages zu triggern.

Mac OS und Multipart Mixed

Daher habe ich eine einfache nicht verschachtelte MultiPart/Mixed-Nachricht per SMTP an Exchange gesendet, die aus einem "text/plain" und einer "test/html"-Baustein bestand.

From: P2-Sender <P2sender@msxfaq.de>
To: P2-Recipient <P2-Recipient@msxfaq.de>
Subject: Betreff21
Date: Tue, 01 Jan 2024 12:34:56 +0200
Message-Id: <messageid021@msxfaq.de>
Content-Type: multipart/mixed; boundary="Boundary1"
Mime-Version: 1.0 (Mac OS)

--Boundary1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;´charset=utf-8

Textbody  UTF8

--Boundary1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=utf-8

<html><body>Boundary2 HTML UTF8</body></html>

--Boundary1--
.

Aber auch diese Nachricht hat Exchange beim IMAP4-Abruf nicht unverändert gelassen und eine "HTMLOnly-Mail" daraus gemacht.

From: P2-Sender <P2sender@msxfaq.de>
To: P2-Recipient <P2-Recipient@msxfaq.de>
Subject: Betreff21
Thread-Topic: Betreff21
Thread-Index: AQHap8OzPDQfZOc6v0eost5OSg9I5w==
Date: Mon, 1 Jan 2024 11:34:56 +0100
Message-ID: 
Content-Language: de-DE
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdiBjbGFzcz0i
Qm9keUZyYWdtZW50Ij48Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwcHQ7
Ij4NCjxkaXYgY2xhc3M9IlBsYWluVGV4dCI+VGV4dGJvZHkmbmJzcDsgVVRGODxicj4NCjwvZGl2
Pg0KPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+Qm91bmRhcnkyIEhUTUwgVVRGOCA8L2Rpdj4N
CjwvYm9keT4NCjwvaHRtbD4NCg==

Alle Spuren einer MIME-Message sind verschwunden und auch der "TextOnly" Abschnitt ist weg. Auch addiert Exchange nicht mehr das Feld "Return-Path" mit der Absenderadresse aus dem SMTP-Envelope. Sobald ich in der originalen Mail wieder das "(Mac OS) aus dem "Mime-Version: 1.0 (Mac OS)" entferne, ändert Exchange nichts mehr an der Mail.

Gegenprobe (Linux)

Nun habe ich die identische Mail gesendet, aber die "Mime-Version" wie folgt gesetzt:

MIME-Version: 1.0 (Linux)

Die Mail wurde von Exchange empfangen und per OWA habe ich auch genau diese Mime-Version gesehen. Beim Abruf per IMAP4 wurde die Zeile aber wieder nur als "MIME-Version: 1.0" ausgegeben aber die Mail wurde ansonsten nicht umgeschrieben. Allein eine "()" kann es also nicht sein. In der RFC steht dazu auch:


Quelle RFC2045 Section 4 https://datatracker.ietf.org/doc/html/rfc2045#section-4

Und etwas weiter im Text folgt dann noch:


Quelle RFC2045 Section 4 https://datatracker.ietf.org/doc/html/rfc2045#section-4

Die RFC bittet darum, die Kommentare jeglicher Form zu zu ignorieren. Das macht Exchange anscheinend auch aber der IMAP4-Services sieht in "Mac OS" eine Ausnahme.

X-Mailer

Anscheinend gibt es aber noch einen zweiten Trigger, den Exchange zu diesem Fehlerbild verleitet. Auch im Feld X-Mailer, welches oft durch den Versender mit einer Versionsnummer gefüllt wird, triggert das Verhalten von Exchange:

X-Mailer: <fehlt>                       -> Mail wird NICHT umgeschrieben
X-Mailer: Outlook *                     -> Mail wird NICHT umgeschrieben
X-Mailer: Thunderbird *                 -> Mail wird NICHT umgeschrieben
X-Mailer: iPhone Mail                   -> Mail wird umgeschrieben
X-Mailer: Mac OS                        -> Mail wird umgeschrieben

Das sind dann so Moment, wo ein Zugriff auf den Sourcecode schnell für Klarheit sorgen könnte.

Wann passiert der Fehler?

Mit den ganzen verschiedenen durchgetesteten Versionen, von denen aber nicht alle hier beschrieben habe, habe ich folgendes Muster ermittelt:

WENN im Header „Mime-Version“ der String „MAC OS“ oder "Iphone" erscheint
 UND die Mail einen „Content-Type: multipart/*“ hat
 UND der Abruf der Mai per IMAP4 erfolgt

DANN schreibt der Exchange IMAP4-Services die Mail komplett um
DANN vereinfacht Exchange die MIME-Message
DANN addiert es nicht das Feld "Return-Path"

Ich werde das Gefühl nicht los, dass Microsoft einen sehr schrägen Code eingebaut hat, um einen besonderen Fall zu lösen, der in Realität nicht oft vorkommt. Exchange, Outlook, OWA, EWS und ActiveSync haben anscheinend kein Problem damit, eine Mail wir das obige Beispiel zu interpretieren. Aber irgendwo muss es vermutlich einen IMAP4-Client gegeben haben, der mit den von Apple als MIME-Mail versendeten Mails Probleme hatte und sich Microsoft dann dazu durchgerungen hat, im IMAP4-Service eine Konvertierung zu schreiben.

Vielleicht hat Microsoft damals ihre Macs mit Apple-Mail per IMAP4 an ihre Exchange Server angebunden und war damit selbst betroffen.

Ein paar Bugs kann man schon im Internet finden, wenn wir mit neuen Wissen suchen.

[MS-OXCMAIL]:PidTagMimeSkeleton

Die Problematik zeigt auf, dass irgendwo ein "Rewriting" erfolgen muss. Der Verdacht liegt daher nahe, dass Exchange auf dem Weg vom Empfang der Mail per SMTP bis zur Ablage im Postfach "etwas" damit macht. Bis Exchange 5.5 (Vor dem Jahr 2000) wurde jede eingehende Mail in eine TNEF/X400-Format gebracht und gespeichert. Laut Marketing hat Microsoft dies mit Exchange 2000 abgestellt und damals extra eine "Streaming-Datenbank" neben die EDB-Datei (Siehe auch Exchange Datenbank - ein Blick dahinter) gestellt, um eben die Konvertierung von 7-Bit-SMTP auf 8-Bit TNEF nur bei Bedarf machen zu müssen, SMTP aber auch IMAP, POP3 und OWA und MIME-Formate haben X.400 ausgestochen. Die STM-Datei ist später in der EDB-Datei aufgegangen aber im Grund hat sich die Meinung gehalten, dass die MIME-Mails nun einfach im Postfach abgelegt und durch den Client interpretiert werden. Dann könnt der IMAP4-Server ja einfach die originale Mail wieder ausliefern.

Das passiert aber nicht und ich habe den Tipp bekommen, dass ein Blick in das Feld "PidTagMimeSkeleton" für Klarheit sorgen soll. Dort würde der originale Header der Mail gespeichert, anhand dem der IMAP4-Service dann die Mail wieder rekonstruieren und mit den Anlagen anreichern würde. Ich stelle mir das dann wie folgt vor:

Meine frühere Annahme ist daher wohl falsch. Auch Exchange 2016/2019 und sogar Exchange Online nehmen eine empfangene Mail auseinander und machen ein binäres Message-Objekt darauf, welches dan in der Datenbank gespeichert wird. Im EWSEditor können Sie die meisten Felder auch schön sehen:

Allerdings habe ich bei meinem Testmails das Feld "PidTagMimeSkeleton" leider nicht gesehen. Das konnte ich dann mit Microsoft Exchange MAPI Editor (früher MFCMAPI) sehen:

Wichtig: Damit das Feld sichtbar wird, muss MFCMAPI ein "Online Profil" verwenden, d.h. es darf kein Cached Mode aktiv sein. Beim Cache-Mode sehen Sie im Baumdiagramm ein "IPM_SUBTREE" statt "Top of Informationstore", "Höchste Hierarchiestufe" oder "Oberste Ebene des Informationsspeichers"

Im Cached Mode fehlen auch viele Ordner.

Es gab normale Mails in meinem Postfach, bei denen "PidTagMimeSkeleton" gesetzt war aber bei den fraglichen Mails war das Feld nicht vorhanden. Mit so einer seltenen Bezeichnung lohnt sich dann auch wieder eine Recherche im Internet und wir erhalten z.B. Treffer wie:


Quelle: https://msopenspecs.azureedge.net/files/MS-OXCMAIL/%5bMS-OXCMAIL%5d.pdf
https://learn.microsoft.com/en-us/openspecs/exchange_server_protocols/ms-oxcmail/ff8efbb6-1178-4154-8c72-71c0e75ba390

Exchange scheint die eingehende Mail beim Parsen auch so auseinanderzunehmen, dass der originale Header im Feld "PidTagMimeSkeleton" landet und von IMAP wieder gelesen und mit den Anlagen angereichert werden soll. Wenn das Feld "PidTagMimeSkeleton" aber nicht da ist, dann muss Exchange sich die verschiedenen Felder wieder "herleiten". Und das kann Exchange dann nur anhand der MAPI/TNEF-Felder. Microsoft schreibt dazu:


Quelle: https://msopenspecs.azureedge.net/files/MS-OXCMAIL/%5bMS-OXCMAIL%5d.pdf
https://learn.microsoft.com/en-us/openspecs/exchange_server_protocols/ms-oxcmail/ff8efbb6-1178-4154-8c72-71c0e75ba390

Wenn also das Feld "PidTagMimeSkeleton" nicht vorhanden ist, und IMAP den Empfänger aus dem Feld "PidTagRecipient" gezogen wird, dann könnte das eine Ursache sein, dass die To-Adresse umgeschrieben wird. Weiter im Text steht auch noch


Auszug aus : https://msopenspecs.azureedge.net/files/MS-OXCMAIL/%5bMS-OXCMAIL%5d.pdf
oder 2.1.3.5.1 Generation Process https://learn.microsoft.com/en-us/openspecs/exchange_server_protocols/ms-oxcmail/2ec01c0b-d258-416f-9089-d4c95b60c1a6

Wenn Exchange schon den Header neu baut, dann kann es auch "MIME-Version: 1.0" setzen. Damit wäre das Fehlverhalten über IMAP4 erklärbar, wenn das Feld "PidTagMimeSkeleton" tatsächlich nicht gesetzt wäre. Also habe ich in MFCMAPI das Feld  mit der PID "0x64F00102" in die Spalten addieren und meine Testmails gesendet.

Sobald in der Mail ein "MIME-Type: 1.0 (macOS) " oder ein "X-Mailer: MacOS" oder "X-Mailer: Iphone" erscheint, wird das Feld "PidTagMimeSkeleton" nicht mehr gefüllt. Das merken Sie dann beim Abruf der Mails per IMAP4/POP3.

Da wir nun die Felder kennen, können wir diese natürlich mit einer Exchange Transport-Regel einfach umschreiben, damit beim der Ablage im Informationsspeicher die Logik nicht mehr wirksam wird.

FROM-Umschreibung

Wenn der originale Absender aber nicht mehr im Feld PidTagMimeSkeleton enthalten ist, dann muss Exchange beim Abruf per POP/IMAP die Mail aus anderen Informationen wieder herleiten. Ohne das Original wird eben das "FROM/TO-Feld aus dem MAPI-Properties genutzt. Allerdings steht in den Feldern nicht mehr die originale SMTP-Adresse der RC-822-Mail sondern die von Exchange aufgelösten Empfänger aus der globalen Adressliste. Wenn ich von extern eine Mail an eine zusätzliche Adresse (ProxyAddresses) sende, dann löst Exchange bei der Zustellung den Empfänger entsprechend auf.

Beim Abruf per POP/IMAP4 wird diese Eintrag aus der GAL gezogen aber welche der zusätzlichen Adressen damals adressiert wurde, ist nicht mehr zu ermitteln. Exchange nimmt dann einfach die primäre SMTP-Adresse. Das fällt dem Empfänger nicht auf, wenn er ein Mensch ist. Wenn Sie aber einen automatischen Prozess haben, welcher sehr wohl genau auf die SMTP-Adresse im "To:"-Header schaut, dann bricht dieses Umschreiben die Funktion. 

Fix mit Transportregeln?

Ohne Zugriff auf den Quellcode ist es kaum möglich zu ermitteln, wann Exchange genau diese Konvertierung der Mails beim IMAP4-Abruf macht. Aber die eindeutige Abhängigkeit von "Mime-Version" erlaubt mit eine Transportregel zu schreiben, die alle Nachrichten umschreibt, bei denen im Feld "MIME-Version" der String "MacOS" erscheint. Ich habe zu Testzwecken erst einmal eine Regel gebaut, die eine "MIME-Version 2.0" setzt.

Als Test habe ich dann folgende Mail per "TELNET" eingeliefert.


Testmail per SMTP eingeliefert.

Hier sehen Sie dann links das Ergebnis eines IMAP4-Abrufs per Thunderbird und Rechts den Header per OWA:

EExchange ist bei der Erkennung der Header nicht "Case"-sensibel, d.h. alle Nachrichte mit einer MIME-Version mit "Mac OS" wurden durch die Regel auch verarbeitet und im Test auf 2.0 gesetzt. Dies konnte ich in OWA auch problemlos lesen. Allerdings sehen Sie auch hier beim IMAP4-Abruf, dass Exchange die Mail verändert.

Danach habe ich die Regel natürlich wieder deaktiviert oder mit der Regel die MIME-Version auf 1.0 gesetzt./p>

Exchange addiert Header

Es ist natürlich klar, dass Exchange auf dem Weg vom SMTP-Empfang bis zum Postfach und letztlich per IMAP4 zum Client noch weitere Header addiert. An den Anfang kommen die bekannten "Received: From"-Header für jede Relais-Station hinzu.

Received: from EX01.UCLABOR.DE (192.168.13.16) by EX01.UCLABOR.DE
 (192.168.13.16) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.39 via
 Mailbox Transport; Thu, 16 May 2024 19:49:34 +0200
Received: from EX01.UCLABOR.DE (192.168.13.16) by EX01.UCLABOR.DE
 (192.168.13.16) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.39; Thu, 16
 May 2024 19:49:32 +0200
Received: from carius.DE (192.168.102.183) by EX01.UCLABOR.DE (192.168.13.16)
 with Microsoft SMTP Server id 15.1.2507.39 via Frontend Transport; Thu, 16
 May 2024 19:49:24 +0200
From: P2-Sender <p2sender@msxfaq.de>
To: P2-Recipient <P2-Recipient@msxfaq.de>
Subject: Betreff2
Date: Mon, 1 Jan 2024 12:34:56 +0200
Message-ID: <messageid002@msxfaq.de>
Content-Type: multipart/alternative; boundary="Boundary1"
MIME-Version: 1.0
Return-Path: p1sender@msxfaq.de
X-MS-Exchange-Organization-Network-Message-Id: 277ff780-1175-4ec9-9f4d-08dc75d08aad
X-MS-Exchange-Organization-AVStamp-Enterprise: 1.0
X-MS-Exchange-Organization-AuthSource: EX01.UCLABOR.DE
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Transport-EndToEndLatency: 00:00:10.6786111
X-MS-Exchange-Processed-By-BccFoldering: 15.01.2507.039

Und am Ende einige Exchange Header. Interessant ist hier, dass Exchange den Absender aus dem Envelope als "Return-Path" addiert. Diese Informationen kommen so beim IMAP4-Client auch an.

Der "Return-Path"-Header wird nicht addiert, wenn Exchange die Mail beim IMAP-Abruf aufgrund der "Mac OS"-Besonderheit neu erstellt!!

Exchange entfernt Header

Exchange entfernt allerdings auch Header aus der Mail. Das habe ich gesehen, als ich eine Mail aus der Pipeline-Trace mit "internen Headern" per SMTP anonym einliefern wollte. Diese Funktion ist aber in Exchange gut dokumentiert, so das ich mir hier einige Beispiele spare.

Zusammenfassung

Auch für mich bietet Exchange immer wieder einmal neue überraschende Erkenntnisse. Sicher nutzen nicht viele Firmen ihren Exchange Server als "IMAP4"-Backend aber dass der IMAP4-Service abhängig von einem UserAgent im Feld "Mime-Version" die Mails umformatiert, ist bemerkenswert. Anscheinend muss es eine komische Formatierung bei "Mac OS", also auch IPhones) geben, die Exchange zwar problemlos versteht aber anscheinend einige IMAP4-Client verwirrt. Das Problem muss in der Vergangenheit bei Microsoft so wichtig geworden sein, dass hier allem Anschein nach Code für genau diesen Fall eingebaut wurde und der IMAP4-Service die Mails komplett neu generiert.

In meinem Fall hat diese Umschreibung der Mails beim Abruf über IMAP4 aber zusätzlich dazu geführt das auch die "From:"-Adresse in der abgerufenen Mail auf die "P1-Sender"-Adresse gesetzt wurde. Das konnte ich auch im Testfeld nachstellen. In der Kundenumgebung hat dies natürlich die automatische Weiterverarbeitung gestört, denn per IMAP4 werden meist nur Prozesse angebunden.

Die Entfernung der Header über eine Transportregel hat Exchange wieder dazu gebracht, das Feld "PidTagMimeSkeleton" wieder zu füllen, so dass der IMAP4-Abruf wieder den korrekten Empfänger sehen konnte.

Ich hoffe einmal später auch beschreiben zu könne, warum Microsoft im Exchange Store so einen Code eingebaut hat.

Weitere Links