Ein unsägliches nervtötendes Thema, das uns und - wie man hier bei der Suche in der Community feststellen kann - viele andere seit einigen Jahren begleitet.
Beim Versand von Anhängen per DATEV-E-Mail-Verschlüsselung erhält der Empfänger anstatt einer pdf-Datei eine winmail.dat.
Wir haben alle möglichen Workarounds ausprobiert. DATEV hat in 2018 unser System untersucht (damals client-server mit office 2010 und AVM KEN auf dem Kom.-Server) und kam zu dem Schluss, dass es an AVM KEN liegen muss, das damals nicht mehr supported wurde.
Nun nutzen wir seit einem Jahr WTS mit MS Server 2019 und Office 2019. Mit demselben Ergebnis, dass in der Hälfte der Fälle winmail.dat Dateien bei den Empfängern ankommen.
In Outlook habe ich wie empfohlen alle Kontakte gelöscht. Profil neu angelegt. Nur-Text-Format verwendet.
BTW: Wenn man verschlüsselt sendet, grätscht hier wahrscheinlich DATEV dazwischen, da ja der Empfänger eine Mail im html-Format bekommt.
Hat irgendwer neue Erkenntnisse zu dem Thema?
Komisch finde ich, dass ich als IT-Techniker das Problem noch nie selbst & persönlich hatte 🤔. DATEV hat mir auf meine private E-Mail Adresse eine verschlüsselte E-Mail geschickt via DATEV E-Mail Verschlüsselung und unter Windows + M365 / Outlook und MacBook MacOS + M365 / Outlook kann ich alles tun, wie es sich gehört. Keine winmail.dat ersichtlich. Meine Mails liegen bei Microsoft in der Cloud; ist eine @outlook.com Adresse inkl. Exchange-Funktionalität.
Sie nutzen dann die E-Mail Infrastruktur der DATEV? Via Direktmail + eigenen Exchange im Haus oder liegt der bei DATEV? Betrifft es auch Windows + Outlook Mandanten oder "nur" Apple MacOS Mandate?
@tobias_maass schrieb:
Beim Versand von Anhängen per DATEV-E-Mail-Verschlüsselung erhält der Empfänger anstatt einer pdf-Datei eine winmail.dat.
Wird da nicht nur eine secure.html Datei verschickt? 🤔
Aus der jahrelangen - leidvollen - Beobachtung:
keine neuen Erkenntnisse;
Allerdings funktioniert bei uns der Versand - derzeit - im Html-Format. Wir Nutzen die on premise-Programme die von MS365 bereitgestellt werden. Outlook trägt hier aktuell die Versionsnummer: 16.0.13901.20148.
Eine Zeitlang habe ich das Problem mit dem Setzen des Registry-Schlüssel "DisableTNEF" in den Griff bekommen.
.. mit dem Format TNEF, in dem die winmail.dat gespeichert ist, kommen Fremdprogramme (außerhalb der Microsoft-Welt) sowieso nicht zurecht.
... ich selbst habe nie winmail.dat-Anhänge erhalten, auch keiner der Mitarbeiter, aber bei einzelnen Mandanten trat das Problem schon auf.
Wegen fehlendem Bedarf habe ich selbst noch nicht getestet, ob das Tool "Winmail Opener" als Notlösung zu gebrauchen ist.
Wird da nicht nur eine secure.html Datei verschickt?
eigentlich ja, für MS macht das jedoch keinen Unterschied.
In der Vergangenheit konnte ich - bei unseren - Mandanten beobachten, dass sich eigentlich nur diejenigen beschwert haben, die Apple-Produkte (NEIN an dieser Stelle kein Bashing der Firma mit dem angefressenen Apfel als Logo) einsetzen.
Daher war für mich die - vielleicht nur laienhafte - Erklärung, dass die Ursache im Umfeld der Art und Weise wie MS die Mails zusammensetzt (als echten Anhang zum Mail-Body oder wie bei Apple als Einbettung in den Mail-Body) zu suchen sein könnte; wie gesagt: laienhaft und ggf. falsch. 😁
Da bei der Kombination von NUR-Text-Mails und der Einstellung in der Registry die meisten Fälle abgefangen werden konnten, habe ich mich mit den technischen Details nicht mehr vertieft beschäftigt.
@agmü schrieb: .. Da ... die meisten Fälle abgefangen werden konnten ...
... und was passierte mit den (100%-meisten%) Fällen ?
@agmü: Und dann wohl auch der integrierte Apple Mail Client von MacOS? Wenn ein Outlook installiert ist, sollte es auch da keine Probleme geben. Und Outlook gibt's im Apple Store unter MacOS kostenlos. Voraussetzung ein M365 Abo.
Soweit nach dieser Kombi die Empfänger noch immer nur Winmail.dat Mails erhalten haben, habe ich in diesen Fällen auf die klassische Post umgestellt - anachronistisch aber immer noch billiger als Stunden-/Tagelang ein scheinbar unlösbares Problem zu analysieren.
@metalposaunist schrieb:@agmü: Und dann wohl auch der integrierte Apple Mail Client von MacOS? Wenn ein Outlook installiert ist, sollte es auch da keine Probleme geben. Und Outlook gibt's im Apple Store unter MacOS kostenlos. Voraussetzung ein M365 Abo.
Ja, aber dazu müssten die Mandanten halt mehr können als nur das "Smart-"Phone zu nutzen😮.
... vielleicht würde es in solchen Fällen helfen, wenn man eine andere Mail-Software oder einen Wald-und-Wiesen-Online-Account nehmen und den Anhang dort hinzufügen und händisch versenden würde.
... ob besser und schöner, weiß ich nicht, aber wenigstens schneller als die Zustellung 'per pedes'
@agmü schrieb:
Ja, aber dazu müssten die Mandanten halt mehr können als nur das "Smart-"Phone zu nutzen.
I know what you mean 😫. Gerade erst eine E-Mail mit Fotos vom Perso erhalten, die im Apple HEIC Format waren und man im DATEVasp so nicht öffnen kann. Aber den Mandanten jetzt sagen, man solle im iPhone auf maximale Komptabilität stellen, wo HEIC im Apple Kosmos 0 Probleme macht und es "nur der StB" wieder so will?!
Lösung: PDF Dokumentenscanner als App installieren (MS Office Lens) und das ganze damit bearbeiten. PDF als Standard. #läuft Und aus 3MB HEIC werden so 1,3MB PDF, fertig zugeschnitten. 👍
Die Frage nach dem wie mal wieder.
Boah Nervfaktor Outlook und Groupware:
Nutzen Sie jetzt Outlook "einfach" direkt ohne eigenen Im-Haus Mailserver - also direkt an den Mailanbieter angeschaltet per IMAP/POP? Vorher hatten Sie ja KEN im Einsatz oder jetzt ein vielleicht anderes, eigenes Produkt (Kerio / Intra2Net / Univention etc...)? Oder einen (gehosteten) Exchange?
Haben die Problem-Empfänger selber Outlook oder dann immer einen anderen Client im Einsatz?
... Ist halt ne typische Outlook Geschichte... in allen Variationen.
Kenn das Problem in allen möglichen Zusammenhängen (unabhängig von DATEV oder Verschlüsselung). Oft beim Mailversand aus einem ERP-System oder ähnlichem. Schnellste Abhilfe hier dann, sorry: Nicht Outlook benutzen, Standardmailer Thunderbird und alle Probleme dieser Art sind verschwunden.
Leider ist mir klar, dass das keine Lösung ist, weil alle Welt mit Outlook "verheiratet" ist, gewisse Plugins halt nur für Outlook vohanden sind etc..
Dennoch bleibt festzustellen, dass Outlook der Mail-Client mit den meisten Problem überhaupt ist. Ferner "nervt" mich sowieso das ganze Zeug rund um Outlook. Du brauchst beim DATEV-Server Umzug ja das x-fache an Zeit für das Groupware-Gehampel.
Sorry, einmal "ausko...". Outlook nervt mich wirklich.
OK zum Thema, kurz rausgesucht was meistens hilft:
In Outlook gehts zu Datei/Optionen/E-Mail: Bei Nachrichten verfassen ist HTML gewählt – es ginge übrigens auch Nur-Text (es darf bloss nicht Rich-Text sein). Ausserdem: Weiter unten unter Nachrichtenformat ist für Beim Senden von Nachrichten im Rich-Text-Format an Internetempfänger auch In HTML-Format konvertieren oder In Nur-Text-Format konvertieren gewählt. Beim Verfassen der Mail an die Person, die sich über Winmail.dats beklagt, müssen Sie im Titelbalken des Verfassen-Fensters ebenfalls etwas Betreff – Nachricht (HTML) sehen.
Passt hier alles – und erhält Ihr Kontakt trotzdem immer noch Winmail.dat von Ihnen? Dann stimmt vermutlich etwas mit dem Kontakteintrag nicht. Öffnen Sie den betroffenen Kontakt aus Ihrem Outlook-Adressbuch. Klicken Sie darin mit rechts direkt auf die Mailadresse und gehen Sie zu Outlook-Eigenschaften öffnen.
Hier könnte nun für diesen Kontakt ein anderes bzw. falsches Format – zum Beispiel das Rich-Text-Format – gewählt sein. Das HTML-Format können Sie hier nicht wählen, aber das Nur-Text-Format. Verwenden Sie dieses und prüfen Sie erneut.
Soweit mir bekannt ist das Thema ein uraltes von MS Exchange in Verbindung mit MS Outlook seit annodutz.
Entweder der benutzte Kontakt (aus dem Kontakteordner oder aus vorgeschlagenen oder von anywhere importierten Kontakten) hat die Eigenschaft per Mail bevorzugt als RTF-formatiert adressiert werden zu wollen und/oder der MS Exchange Server meint formatierte Mails gern bevorzugt als RTF senden zu wollen.
Nur dann formatiert der Exchange-Server aus der Mail samt eventueller Anlagen eine winmail.dat als Anlage, die dann nur ein anderer Exchange-Server (oder ein entsprechendes Tool beim Empfänger) wieder lesbar interpretieren kann.
Gern tritt das Problem nach Abhilfe für Jahrzehnte in den Hintergrund und wird vergessen, taucht bei kürzlich installiertem Exchange oder Outlook oder Migrationen gern mal wieder auf.
Das Zauberwort heißt auf Powershell language am Exchange Server stets (so ungefähr):
SET (...)TNEFEnabled $false
Von echten Exchange-Administratoren kaum zu unterscheidende System-Admins sollten wissen, was hier nachhaltig und genau zu tun ist. Der Blogeintrag von Michael ovn ITK-Professional erklärt ungefähr das schon lange totgeglaubte Problem und die Abhilfe hier noch "relativ verständlich": WINMAIL.DAT verhindern (ITK-Professional Blog) https://www.itk-professional.de/?p=413
Theoretisch ergibt sich auch die Möglichkeit, auf der Anwenderseite einen benutzerspezifischen Registry-Key für den betreffenden (und alle künftigen) Office-Benutzer zu setzen (oder per Gruppenrichtlinie zu erzwingen), das ist aber regelmäßig nicht nachhaltig genug für eventuelle Neuinstallationen oder Office-Versionsupdates.
Ich würde bei der Hand des zu leider früh verstorbenen, argentinischen Fußballgottes schwören, dass es eigentlich keinen unmittelbaren Zusammenhang mit dem Produkt "DATEV-E-Mail-Verschlüsselung" gibt. Möchte aber da auch nicht weiter reingrätschen. Ich sage nur IF MS Exchange=TNEFEnabled $false, dann sollte das ordentlich senden.
Viel Glück!
@JoergZielke schrieb:Soweit mir bekannt ist das Thema ein uraltes von MS Exchange in Verbindung mit MS Outlook seit annodutz.
...
Sorry, aber mit Exchange allein hat das Thema nichts gemein. Wir nutzen keinen Exchange und dennoch gibt es Wochen/Monate in denen die Winmail.dat das "Maß aller Dinge" ist.
Vielleicht gibt es mittelfristig Abhilfe. Outlook soll abgelöst werden; meinten jedenfalls diverse "Fach"-Zeitschriften.