Ich kenne das Winmail.dat Problem nur zu gut, insbesondere von Kunden. Das Problem stammt letztlich nicht vom Mailclient der zum Senden verwendet wird und auch nicht vom Mailclient der beim Empfang einsetzt wird, sondern hängt mit der Konfiguration des empfangenden SMTP-Servers zusammen. Ich kann das sagen, da ich auf das Problem in Folge von Kundenbeschwerden mindestens schon eine volle Arbeitswoche in die Fehleranalyse und Ursachenforschung in den letzten Jahren investiert habe.

Auffällig ist, dass besonders Nutzer von GMX und Web.de Postfächern unter diesem Problem leiden. Hier tritt der Fehler immer dann auf, wenn der Absender Outlook als Mailclient verwendet und dort HTML oder RTF als Mailformat nutzt und einen Anhang anfügt, der nicht ASCII-Code enthält. Solche Mails kommen bei so gut wie allen Empfängern problemlos an und die Anhänge stimmen. Nur bei GMX und Web.de ist sowohl im Webmailclient, wie auch auf Mailprogrammen wie Thunderbird, Outlook oder halt auf einem Mobiltelefon, häufig der Anhang in Winmail.dat verwandelt.

Sendet man eine solche Mail testweise an verschiedene Empfänger als "An", "CC" oder "BCC", kommt diese Mail auch RFC konform beim jeweiligen empfangenden SMTP-Server an (habe ich geprüft). Dieser verteilt die Mails auch korrekt an die Postfächer (ebenfalls geprüft), so dass die Anhänge dem entsprechen, wie sie gesendet wurde. Ausnahme: GMX, Web.de und noch ein paar Exoten (hier kann ich das nicht prüfen, da ich keinen Zugang zu deren SMTP-Servern und deren Konfiguration habe).

Das Problem tritt hierbei auch nicht dauerhaft auf, sondern kann auch einige Zeit verschwunden sein. Dies deutet darauf hin, dass die eingesetzte Mailserverkonfiguration auf Seiten dieser E-Mail Provider fehlerhaft oder deren eingesetzte Software schlecht programmiert ist.

Was kann man als Empfänger dagegen tun: Nichts, außer sich einen anderen Mailprovider zulegen.

Was kann man als Sender dagegen tun: Mails mit Anhängen an die Deppenprovider nur als "Text" senden.

Was können alle tun: Hoffen, dass die Deppenprovider sich dem Problem irgendwann einmal annehmen und es dauerhaft lösen.

RFC-Standards für E-Mails:

Zitat von Jonicus

Währungshüter wir verwenden kostenpflichtig UnitedDomains. Sowohl das sendende Postfach, wie auch die beiden empfangenden Postfächer sind dort gehostet.

Zeitgleich kommt die Email einmal als Win.dat und einmal korrekt an.

Der Provider kann ja nicht einmal Depp sein und einmal kein Depp?

Alles dieselbe Brühe....

Die united-domains AG ist ein deutscher Internet-Provider mit Sitz in Starnberg bei München. Sie ist seit Ende 2008 eine Konzerntochter von United-Internet.

Das Unternehmen ist Teil der 1&1 Mail & Media GmbH, die auch den ehemaligen Konkurrenten Web.de einschließt. Die 1&1 Mail & Media GmbH ist eine Tochtergesellschaft des United-Internet-Konzerns. Das Akronym GMX steht ursprünglich für "Global Message eXchange".

Zitat von Jonicus

Währungshüter wir verwenden kostenpflichtig UnitedDomains. Sowohl das sendende Postfach, wie auch die beiden empfangenden Postfächer sind dort gehostet.

Zeitgleich kommt die Email einmal als Win.dat und einmal korrekt an.

Der Provider kann ja nicht einmal Depp sein und einmal kein Depp?

Doch, weil die mit sogenannten SMTP-Clustern arbeiten. Du weißt also nie genau, über welches Cluster die eingehende Mail läuft. Erwischt die eine Mail einen falsch konfigurierten Cluster, dann schepperts, sonst scheppert es nicht. Wie gesagt, habe mich damit schon sehr eingehend befasst und auch schon mehrfach den Kontakt zu United-Internet gesucht, leider kommt schlicht keine Antwort von denen, es interessiert sie offenbar nicht.

Der Witz ist halt, dass dieses Problem bei Mailservern die wir für Kunden aufsetzen nie auftritt ebenso wenig, wie es bei uns hausintern oder bei anderen Providern nicht besteht. Daher mein Fazit, dass es am SMTP-Server auf der Empfängerseite liegen muss.

Zitat von Jonicus

Ich kann Dir die Mailadresse von GF zukommen lassen?

Das nützt nichts, da die Server dort außerhalb meines Einflussbereiches stehen. Ich habe das Verhalten nur über Jahre per "Try and Error" für Kunden von uns herausgefunden und ausgeschlossen, dass es am sendenden Server bzw. dem Mailclient auf beiden Seiten liegt.

Den Kunden habe ich gesagt, dass wir da keine Handhabe haben. Hintergrund ist, dass Mails, die meine Kunden z.B. an ihre Endkunden senden, ebenfalls davon betroffen sein können, wenn deren Endkunden ein Postfach bei den betreffenden E-Mail Hostern betreiben.