Mail an einen einzelnen Empfänger wird zu winmail.dat

[lukas]

Hallo zusammen.

Ich habe im Mailing ein Problem, für das ich keine Lösung finde. Deswegen werfe ich das mal in die Runde und hoffe, dass jemand die zündende Idee oder einen Zaunpfahl zum Winken hat. Ich habe echt keinen Ansatz, ob und wo ich im Outlook, EXO oder NSP suchen muss.

Unsere Umgebung:
Microsoft 365
Outlook Full-Client
Mailversand über NSP über den Connector
NSP 14.0.5

Das Problem betrifft eine bestimmte Kollegin mit einem bestimmten Empfänger (Quasi eine 1:1-Beziehung). Sie sendet eine Mail an mehrere Empfänger aus derselben Firma (gleiche Domain, gleicher Ziel-Mailserver). Die Mail kommt bei dieser einen Person als winmail.dat an und das Verhalten bis zum Versand ist auch bereits ungewöhnlich:

• Die E-Mail kommt wie gesagt bei einem konkreten Empfänger als winmail.dat an, die anderen Empfänger im Unternehmen bekommen sie korrekt.
• In der Nachverfolgung des NSP taucht die Mail nur 1x auf, was ein korrektes Verhalten ist.
• Auf dem Gateway taucht sie (Logging aktiviert) im Ordner „Received“ (also noch nicht in Processed) bereits in 2 varianten auf, siehe Screenshot.



• Darauf sieht man, dass die E-Mail ein abweichendes Format hat und die HTML-Signatur nicht korrekt dargestellt wird.
• Links: ganz normale HTML-Mail, Rechts: defekte Mail
• Im Mailheader sind nur 3 Unterschiede zu sehen. Die Mails unterschieden sich in 3 Zeilen (außerdem noch in Signaturen, Keys usw aber das ist ja korrekt)

2x (oben und unten als Grenze)
Content-Type: multipart/mixed; boundary="_XXX_FRYP281MB25XXXXX0DEUP_"

Und mitten drin (in der Korrekten mail ist das Tag vorhanden aber leer)
X-MS-TNEF-Correlator: <XXXXXX@XXXXXX.XXXXX.PROD.OUTLOOK.COM>


Das Verhalten tritt auch auf, wenn man eine „Nur Text“ mail versendet.
Ob es ohne Anhang durchgeht, weiß ich leider nicht, der „defekte“ Empfänger ist extern und leider nicht allzu kooperativ bzw. das Verständnis für IT-Themen ist nicht vorhanden. Aus diesem Grund lässt sich das auch nicht groß Testen.

Interessanterweise sehe ich gerade beim Schreiben dieses Beitrags, dass sich die Größe der Anhänge beider Mails angeblich unterscheidet. In der NSP-Nachrichtenverfolgung ist die Größe der linken, korrekten Mail angegeben. Ziehe ich beide Files aus der Mail raus, dann haben sie beide die korrekten 180kb sowie dieselbe MD5-Cheksumme.

(Anm: Exakt dasselbe Problem hatte ich vor knapp 1 Jahr schon einmal bei wem anderen (ebenfalls eine 1:1 Beziehung), jedoch hat der Ansprechpartner auf der anderen Seite das Unternehmen verlassen, deswegen hat es sich dadurch von allein erübrigt)

Ich bin wie anfangs erwähnt überfragt….. hat jemand hier einen Ansatz für mich?

Besten Dank und Grüße

 

[Sören]

im Ordner „Received“

wenn das da schon so ist, dann kam die Mail auch bei uns so an...das was wir das machen in dem Ordner ist nichts anderes als TCP Dump

Ergo scheint euer Problem im M365 zu sein...ins blaue geraten: ich bringt Disclaimer oder Signaturen bereits im EXO auf und die zerschiessen euch das encoding der Mail

Du könntest mal deinen User bitten einen Test zu machen und der User soll selbst das encoding der Mail wählen, in dem Fall HTML:

 

[EricZ]

Moin.
Kurze Anmerkung.
Das liegt teilweise aber auch am Empfänger Postfach. Da hat Outlook eine Macke.

Muss nicht zwangsläufig am Sender liegen. Vorallem, wenn ich den Text so sehe.

VG

 

[Sören]

Moin.
Kurze Anmerkung.
Das liegt teilweise aber auch am Empfänger Postfach. Da hat Outlook eine Macke.

Muss nicht zwangsläufig am Sender liegen. Vorallem, wenn ich den Text so sehe.

VG

nicht zwangsläufig, aber wenn er schreibt:

Auf dem Gateway taucht sie (Logging aktiviert) im Ordner „Received“ (also noch nicht in Processed) bereits in 2 varianten auf, siehe Screenshot.

dann bedeutet das, dass die Mail schon bevor sie raus gegangen ist oder durch NSP verarbeitet wurde, unterschiedlich aussah...ergo, es kann nicht am Empfänger liegen

 

[EricZ]

Ah. Okay.
Das habe ich überlesen. Sry.

Dann einmal html versuchen und so doof das klingt. Einmal den defekten Empfänger aus dem Outlook Cache löschen und die Email neu eintragen.
Wenn der Empfänger als Kontakt gespeichert ist, den Kontakt einmal löschen.

Auch damit hatte ich leider meinen Spaß.

VG

 

[Sören]

@lukas : du könntest mir mal das die Dumps aus dem recieved folder an PN schicken wenn du magst, dann schau ich da mal drauf

 

[lukas]

Hallo die Herren
vielen Dank für die Kommentare. Ich befürchte auch, dass es irgendwas im Outlook/EXO ist. Als wir vor 10 Jahren noch einen lokalen Exchange hatten war die radikale Lösung Windows (und damit Office) platt zu machen, jetzt geht's leider nicht so einfach . Ich bin mir nicht sicher aber ich glaube als ich das Problem letztes Jahr mit dem Kollegen hatte trat es auch bei OWA auf.

Regeln führen wir im EXO nur 2 aus:
"Is sent to 'Outside the organization'" -> "An NSP übergeben"
"Sender ist NSP" -> "Set the spam confidence level (SCL) to '-1'"

Das Encoding explizit auf Text zu setzen hatte leider ebenfalls nicht geholfen.

Mein Problem ist hier halt, dass ich nicht groß Testen kann, da der Empfänger IT-Resistent ist.

Beim selben Problem letztes Jahr hatte ich hingegen 2 IT-Affine Menschen und kam trotzdem zu keiner Lösung. Ich hab im Hinterkopf, dass es evtl. bei Mails ohne Anhang durch ging aber bin mir hier leider nicht mehr sicher. Was auch interessant war: als der Absender exakt dieselbe Mail mit einem anderen Absender (Shared Mailbox, gleiches Outlook, gleicher Account) versendet hat, dann ging sie korrekt durch.

Wenn es da jetzt keine spontane Lösung gibt, dann ist es halt so.. Einzelschicksal. Notfalls habe ich Workarounds. Aber ich hatte gehofft, dass wer die zündende Idee hat.

@Sören ich schick dir die Mails gleich rüber.

Grüße

 

[Sören]

Also ich hab die Daten bekommen und dir auch schon geantwortet

Mein Problem ist hier halt, dass ich nicht groß Testen kann, da der Empfänger IT-Resistent ist.

Der Empfänger kann dafür auch nichts ihr schickt ihm bereits die Mails so.

Für alle anderen mitlesenden: Im Dump ist zu sehen, dass die Mails die wir vom EXO bekommen, eine Mail gar kein Content/Type im Header hat und die andere Mail bereits die winmail.dat enthält. Somit kann ich den NSP ausschließen, es muss vom Client kommen oder von der Lösung, die den Disclaimer anhängt.

Ich hab dazu auch zwei Screenshots, anonymisiert natürlich

Hier fehlt der Content Type in der kompletten Mail:



und in der Mail wo der Content Type enthalten ist, ist auch die winmail.dat enthalten



Wir ändern halt am Encoding der Mail nichts, sondern verarbeiten die Stumpf so wie wir diese bekommen haben.

Wenn MS jemals ne richtig doofe Idee hatte, also zum Beispiel Python in Excel zu implementieren dann ist der TNEF Container, also winmail.dat die Krönung der Dummheit.

 

[EricZ]

Was auch interessant war: als der Absender exakt dieselbe Mail mit einem anderen Absender (Shared Mailbox, gleiches Outlook, gleicher Account) versendet hat, dann ging sie korrekt durch.

Kill mal den Cache für die Auto Vervollständigung im Outlook.
Der ist an den Absender gekoppelt.

Wie Sören schon schreibt, das ist ein Client Problem.

Den Cache kannst du über die Einstellungen platt machen. Ist nicht toll, aber kann in dem Moment helfen. Damit ist dann aber der komplette Cache weg. Das muss einem bewusst sein.

Datei > Optionen > E-Mail > AutoVervollständigungs-Liste leeren

Oder du schreibst den Cache neu.

Dazu eine neue Mail schreiben.
Den Empfänger durch den Cache suchen, dort hinten auf das x, damit löscht du den.
Danach die Emailadresse einmal manuell eingeben und die Mail abschicken.

Wichtig. Die Mail muss abgeschickt werden, sonst schreibt der den Cache nicht neu.

Ist nur eine Idee, wo es herkommen kann.

Zu empfehlen ist natürlich erst Schritt 2, das hat den kleinsten Eingriff zu Folge.

Vg

 

[lukas]

Danke fürs Analysieren. Die Stelle mit der winmail.dat im Mail-Quelltext hatte ich nicht auf dem Schirm, hab immer nur in den Header geschaut und nicht die EM per Texteditor aufgemacht. Mit dieser Info werde ich mal in die Recherche gehen und den Empfänger mal zusammen lassen. Vielleicht kann ich ja eine Regel bauen, dass Mails vom internen Absender an den defekten Empfänger gar nicht zugestellt werden... so kann ich auch Testen ohne den Empfänger zu belästigen. Danke euch für die Tipps und Recherchen.

Grüße

 

[Sören]

Danke fürs Analysieren. Die Stelle mit der winmail.dat im Mail-Quelltext hatte ich nicht auf dem Schirm, hab immer nur in den Header geschaut und nicht die EM per Texteditor aufgemacht. Mit dieser Info werde ich mal in die Recherche gehen und den Empfänger mal zusammen lassen. Vielleicht kann ich ja eine Regel bauen, dass Mails vom internen Absender an den defekten Empfänger gar nicht zugestellt werden... so kann ich auch Testen ohne den Empfänger zu belästigen. Danke euch für die Tipps und Recherchen.

Grüße

Du könntest per Inhaltsfilter -> ausgehend -> winmail.dat verbieten ....dann bekommst du recht schnell mit, welche deiner User solche Mails versenden

 

[Jordan]

evtl. hilfreich, ist eine neuere Info:

So wird's gemacht: Angeben des E-Mail-Nachrichtenformats, das für externe Empfänger verwendet wird, um Winmail.dat-Anlagen zu verhindern - Exchange

Beschreibt, wie Microsoft 365-Administratoren das Nachrichtenformat ändern können, sodass Nachrichten, die von Microsoft 365-Benutzern an externe Empfänger gesendet werden, nicht die Winmail.dat-Anlage enthalten.

learn.microsoft.com