Winmail.dat aus Dokorg / ein ewiges Thema

[#1]

Sachlage:

Fall a)

Kanzlei schickt Mail an Mandanten mit PDF-Anhang mittels Outlook (2013) auf  dem Wege: Outlook öffnen => neue Mail => Anhang drann => versenden => Fertig. Mail kommt beim Mandante an, alles ok, unabhängig des Mail-Clients den Mandant nutzt.

Fall b)

Kanzlei will Mail an Mandanten schicken auf dem Wege: Dokorg => Word-Datei auswählen => Per Mail senden => als PDF senden => Outlook öffnet sich => Mail ist soweit mit dem Anhang erstellt => senden => fertig. Mandant enthält bei Nicht-Nutzung von Outlook die berühmte Winmail.dat

Fall c)

In der Dokorg eine PDF-Datei mittels STRG-C kopieren und in geöffnetes Outlook einfügen (STRG-V). Auf Mandanten-Seite wieder alles ok, keine Winmail.dat.

Gibts eine Abhilfe dass Fall b) auch unabhängig vom Mail-Client der Gegenseite funktioniert?

Welches Mail-System / Mailserver im Haus nun dahinter hängt, sollte hier "egal" sein. Das Problem tritt ja "nur" auf, wenn aus der Dokorg DIREKT gemailt wird. Manuelles versenden klappt ja.

Jemand eine Idee?

[#2]

Naja, es gibt Konverter, die die Mail korrekt verarbeiten, das dürfte aber nicht das sein, was Ihnen als "Lösung" vorschwebte. "B" heile machen geht leider nicht, sie können aber B vermeiden, indem Sie die Dateien auf anderen Wegen zu den Empfängern bringen, wir nutzen z.B. eine Nextcloud Anwendung dafür. Dann muss das PDF auch nicht gesondert verschlüsselt werden... 

Da es sich um einen known bug von Microsoft handelt, kann DATEV da auch wenig dran ändern. 

[#3]

Aber Danke für C, bislang habe ich die Datei ins Dateisystem kopiert und von da aus verschickt, wenn es per Mail sein musste.

[#4]

Das passiert, wenn eine Email statt als reiner Text oder HTML im RTF-Format erstellt wird.

das sopllte bei Verwendeung eines Exchange-Servers aber nicht passieren. Versendet Outlook Emails direkt per SMTP an einen anderen Server, verwendet es eine propietäre Kodierung in dieser Form (winmal.dat als MIME-Part).

[#5]

Testen Sie mal folgende Einstellungen:

[#6]

Mir ist das persönlich "klar". E-Mail ist eh ein Medium, welches nicht zum Datentransfer "Anhang" gedacht war. Aber für "Kanzlei" ist das Mailen oft anscheinend ihr "Ein-und-Alles". Ist egal - ganze Kanzlei kann "stehen" - Hauptsache Outlook geht - so kommt es mir immer vor.

Du kannst nen DATEV-Server umziehen, die Nutzerprofile bis ins kleinste durchtickern, alles Haarklein fertig machen und dann kommt Kunde "Kanzlei" wieder mit z.B. der Autovervollständigung beim Schreiben einer Mail um die Ecke. Als ob ich noch Lust habe vorher aus 50 Outlook-Konten die NK2 zu zu verfrickeln und zu sichern um den Müll auch noch  "mitzunehmen". Oder die geliebte Mail-Langzeitablage bzw. das Outlook-DMS welches sich Papierkorb nennt, wurde nicht "mitgenommen". Um Gottes Willen - Das Geschrei ist groß. Auch immer gerne  "genommen" => Konstrukte von: Ich will aber mitlesen: Alle Konten => Eingang und Ausgang aller Mitarbeiter...

Meine Fresse!! Das nervt...

Hatte schon den Fall, dass ISO-Dateien hin und her gemailt wurden, weil man zu faul war nen Stick guste in den Nebenraum zu bringen. Und dann Mailbestände von 500-600 GB auf dem WTS mitschleppen. Die Leute wissen nicht mehr was sie tun.

[#7]

Jupp, kenn ich => Die Einstellung hatte ich schon gesetzt. Wie gesagt, Mail kommt bei "manuellem" Mailen mittels Outlook ja auch korrekt an, nur aus der DOK-Org nicht.

[#8]

Neulich hat "der Unerreichte" @metalposaunist dankenswerterweise irgendwo (sinngemäß) geschrieben, dass er anfängt Leute zu verstehen, die sagen "Ich bin NUR Steuerberater" ...

Gibt es für solche armen Seelen (wie mich) für das "winmail.dat-Malheur" im Zusammenhang mit Outlook 365 (auch) eine "einfache" Lösung?

Die Microsoft Lösung ist für mich leider NICHT einfach 😵

Und auch der ratsuchende Ulf erkundigt sich seit Mitte 2019 vergeblich nach einer solchen "einfachen" Lösung - Auszug ...

"Es kann nicht sein, dass man mit kryptischen Befehlen in der Powershell Dinge korrigieren soll, die eigentlich selbstverständlich sind, dem einfachen Versand einer PDF-Datei per Email über Outlook innerhalb von Office 365 pro."

DANKE Ulf!

[#9]

Wir haben bei uns das Problem mit dieser Lösung (https://support.microsoft.com/de-de/topic/winmail-dat-gesendet-als-e-mail-anhang-in-outlook-2007-und-2010-b72c81ac-db5e-b142-d43d-448efbc23cce) vom Hals geschafft

ggf. muss die Versionsnummer angepasst werden.

Nachdem dieser Registry-Schlüssel gesetzt wurde, klappt der Versand auch aus der DokAbl. wieder fehlerfrei.

[#10]

Hallo, wenn Exchange online oder Exchange on premise im Einsatz ist, sollte beim default sendeconnector TNEFEnabled auf $false per powershell gestellt werden. Outlook Einstellungen sind nicht zuverlässig

Set-RemoteDomain Default -TNEFEnabled $false

https://docs.microsoft.com/en-us/powershell/module/exchange/set-remotedomain?view=exchange-ps

von einem ITler für einen ITler in der Kanzlei  (oder solche welche sich DATEV Partner nennen dürfen) 😉

sowas könnte die DATEV bestimmt auch mal öffentlich publizieren bzw. bekanntmachen. 

Grüße 

AW

[#11]

... aber war weiter oben im Thread nicht davon die Rede, dass dieser Effekt beim Einsatz von Exchange 2010, 2016, 2019 nicht auftritt ?

[#12]

Tritt definitiv und teilweise unerklärlich auf. Auch bei Exchange online. einfach umsetzen (lassen) und freuen. 👍

[#13]

Den Hinweis werde ich auf jeden Fall testen!! Dafür schon mal danke!

[#14]

Moin! Hier, in meinem Fall ist überhaupt kein Exchange im Einsatz. Das verhalten zeigt sich hier bei Postfix. Wie schon 2x gesagt: Es passiert NUR bei Mail direkt aus DokAblage.

Manuelles Mailen per Outlook + Anhang geht=> keine Winmail.dat

[#15]

---

@LS4B  schrieb:

Moin! Hier, in meinem Fall ist überhaupt kein Exchange im Einsatz. Das verhalten zeigt sich hier bei Postfix. Wie schon 2x gesagt: Es passiert NUR bei Mail direkt aus DokAblage.

Manuelles Mailen per Outlook + Anhang geht=> keine Winmail.dat

---

wir haben auch keinen Exchange  im Einsatz; dennoch beschwerten sich Mandanten darüber, dass Sie WinMail.Dat-Dateien erhalten würden. Seitdem die Schlüssel gesetzt sind gibt es an dieser Stelle keine Kritik mehr.

Ich habe so meine Theorien (Missachtung der / unklare Standards beim E-Mail-Format) warum der Versand mal mit, mal ohne Winmail.dat erfolgt; letztlich interessiert es mich aber nicht mehr, nachdem ich eine Lösung gefunden habe, die das Problem umgeht.

[#16]

... habe diesen Effekt noch nie selbst erlebt, weder mit Exchange noch ohne Exchange

... evtl. wollen diverse Registry-Einträge explizit gesetzt werden, weil sie sonst undefiniert sind

... der Powershell-Befehl "Get-RemoteDomain" liefert nur sehr wenige Informationen

... werde aber mal testen, ob der Fehler und dessen Lösung reproduzierbar ist ...

[#17]

Besten Dank an  @agmü klappt mittels Ihres Links. Hier nochmals kurz der Inhalt.

• Klicken Sie auf den folgenden Registrierungsunterschlüssel:

  HKEY_CURRENT_USER\Software\Microsoft\Office\xxx\Outlook\Preferences

• Zeigen Sie im Menü Bearbeiten auf Neu, und klicken Sie anschließend auf DWORD-Wert.

• Geben Sie DisableTNEF ein, und drücken Sie dann die Eingabetaste.

• Klicken Sie mit der rechten Maustaste auf DisableTNEF, und klicken Sie dann auf Ändern.

• Geben Sie in das Datenfeld Wert den Wert 1 ein, und klicken Sie dann auf OK.

• Beenden Sie den Registrierungs-Editor.

• Starten Sie den Computer neu.

xxx => 14.0 Outlook 2010

xxx => 15.0 Outlook 2013

xxx => ...

Am Terminal-Server halt leider für jeden User "durchtickern...".

[#18]

---

@LS4B  schrieb:

...

Am Terminal-Server halt leider für jeden User "durchtickern...".

...

---

oder nach dem ersten Eintragen den Schlüssel speicher und über das Login-Script verteilen

[#19]

Ich habe so meine Theorien (Missachtung der / unklare Standards beim E-Mail-Format) warum der Versand mal mit, mal ohne Winmail.dat erfolgt;...

Der Versand erfolgt seitens des Versenders an sich immer gleich. Ob der Empfänger eine Winmal.dat bekommt, "entscheidet" der quasi Empfänger selber. Hier spielt der Mail-Client wohl die Rolle.

Beispiel bei meiner Problem-Kanzlei: (Kanzlei sendet => Mandant ist Empfänger)

Empfänger nutzt Outlook-Client => Kommt immer korrekt an

Empfänger nutzt Evolution-Client => Kommt mit Winmal.dat und zusätzlich mit korrektem Anhang, der auch zu öffnen ist

Empfänger nutzt GMX per Webinterface => Nur Winmail.dat, nicht brauchbar

... keine Ahnung was noch alles geht.

Am Ende ist halt kurios: Es kommt nur zu Problemen bei Nutzung aus der DokOrg. Versand mittels Anhang aus Windows-Ordner geht immer.

Egal - Erledigt! Besten Dank nochmals an @agmü 

[#20]

---

@LS4B  schrieb:

....
Am Ende ist halt kurios: Es kommt nur zu Problemen bei Nutzung aus der DokOrg. Versand mittels Anhang aus Windows-Ordner geht immer.

Egal - Erledigt! Besten Dank nochmals an @agmü 

---

Gerne.  

Bei unseren Mandanten waren Produkte des Herstellers mit dem angefressenen Apfel im Logo im Einsatz.

[#21]

---

@LS4B  schrieb:

Manuelles Mailen per Outlook + Anhang geht=> keine Winmail.dat

---

Bei mir - mit Outlook 365 - geht das leider nicht.

@LS4B  schrieb:

Empfänger nutzt Outlook-Client => Kommt immer korrekt an

Empfänger nutzt Evolution-Client => Kommt mit Winmal.dat und zusätzlich mit korrektem Anhang, der auch zu öffnen ist

Empfänger nutzt GMX per Webinterface => Nur Winmail.dat, nicht brauchbar

... keine Ahnung was noch alles geht.

@agmü  schrieb:

Bei unseren Mandanten waren Produkte des Herstellers mit dem angefressenen Apfel im Logo im Einsatz.

Ich habe den Eindruck, dass bei mir beide vorgenannten Problemfelder eine Rolle spielen ...

Kennt vielleicht jemand für Outlook 365 (auch) eine ("einfache") Lösung?

[#22]

---

@LS4B  schrieb:

....

Am Terminal-Server halt leider für jeden User "durchtickern...".

---

Warum auch immer:  für die "einfache" Client-Server-Lösung leider auch (zumindest bei uns).

[#23]

---

@jejo  schrieb: ....

Kennt vielleicht jemand für Outlook 365 (auch) eine ("einfache") Lösung?

---

Die im Posting 6 wiedergegebene Lösung ist auch für Outlook365 die "einfachste" Lösung.

[#24]

Am Terminal-Server halt leider für jeden User "durchtickern...".

Warum auch immer:  für die "einfache" Client-Server-Lösung leider auch (zumindest bei uns).

Für sowas gibt’s Gruppenrichtlinien.

LG, F.Lange

[#25]

... ich selbst hatte noch keinen Ärger mit "winmail.dat", weder als Sender noch als Empfänger solcher E-Mails

Offenbar kann der Empfänger einer "winmail.dat"-Anlage nichts damit anfangen, da die "winmail.dat"-Anlage nicht mehr 'repariert' werden kann, aber es wäre interessant zu wissen, ob der Absender und/oder der Empfänger durch nochmaliges Versenden/Empfangen derselben E-Mail, aber diesmal über einen anderen Weg, doch noch zum Ziel kommt (z.B. mit anderem Mail-Client, per Weiterleitung, an eine andere E-Mail-Adresse etc.)

Manche E-Mail-Absender sind ja quasi "nach Diktat verreist", also nicht mehr erreichbar und als E-Mail-Empfänger will man sich auch nicht ohne Not die Blöße geben, eine E-Mail nicht 'lesen' zu können, solange man nicht weiß, wo der Fehler steckt.

[#26]

---

@vogtsburger  schrieb:

...

Offenbar kann der Empfänger einer "winmail.dat"-Anlage nichts damit anfangen, da die "winmail.dat"-Anlage nicht mehr 'repariert' werden kann

...

---

zur Not gibt es noch den Winmail Opener

https://www.chip.de/downloads/Winmail-Opener_42439483.html

[#27]

---

@flange  schrieb:

...Für sowas gibt’s Gruppenrichtlinien.

LG, F.Lange

---

kann sein, aber selbst MS weist darauf nicht hin - oder ich kann das entsprechende Infodokument bei MS nicht finden.

Und Hand-aufs-Herz:  bei unserer Kanzleigröße - insg. 4 MA - ist der Registy-Schlüssel mindestens genauso schnell gesetzt, wie eine Gruppenrichtlinie definiert und geprüft ob die tatsächlich auf allen Rechnern greift.

[#28]

@agmü  schrieb:

Die im Posting 6 wiedergegebene Lösung ist auch für Outlook365 die "einfachste" Lösung.

---

Ich stehe vermutlich auf dem Schlauch, sorry ...

Meinen Sie mit Posting 6 diesen Beitrag?

Nachtrag: Bild

[#29]

nein.  Offensichtlich ändern sich die Nummern der Beiträge.

Ich meinte diesen Beitrag:

[#30]

... man kann den Registry-Eintrag exportieren (in eine .reg-Datei speichern) und diese reg-Datei dann per Doppelklick auf anderen PCs bzw. für andere User ausführen (in die Registry eintragen lassen)