Kopfzeilen und Body zusammen
Von, an, Betreff, Datum und der Nachrichten-Body werden als eine lesbare Seite gerendert, anstatt als Rohdump, den jemand interpretieren muss.
E-Mails sind Beweismittel. Sie landen in Akten, Prüfpfaden, Discovery‑Paketen und Support‑Tickets – und dann muss jemand eine .msg auf einem Rechner lesen, auf dem Outlook nie installiert war. Doconut rendert MSG, EML und EMLX serverseitig zusammen mit jedem anderen Format im Archiv.
Das Problem
Dokumentenmanagementsysteme werden um PDF und Office herum gebaut, und dann kommt die erste echte Akte mit vierzig .msg‑Dateien. Plötzlich ist ein E‑Mail‑Client auf einem Server erforderlich, oder ein Konvertierungsschritt, den jemand ausführen muss, oder ein Support‑Ingenieur, der Beweismaterial auf einen Laptop herunterlädt.
Herunterladen ist das Schlimmste von den dreien. Sobald eine Nachricht das System verlässt, befindet sie sich außerhalb Ihrer Aufbewahrungsrichtlinie, Ihres Prüfprotokolls und Ihrer Zugriffskontrolle – und genau das Material ist später am wahrscheinlichsten von Bedeutung.
Serverseitiges Rendern hält die Korrespondenz innerhalb des Systems, das sie enthalten soll, neben den PDFs und Tabellenkalkulationen desselben Falls, die über denselben Viewer geöffnet werden.
Funktionen
Von, an, Betreff, Datum und der Nachrichten-Body werden als eine lesbare Seite gerendert, anstatt als Rohdump, den jemand interpretieren muss.
.msg für Outlook, .eml und .emlx für alles andere. Der gleiche Öffnungsaufruf verarbeitet alle drei.
HTML-Nachrichten behalten ihre Formatierung und eingebetteten Bilder bei, anstatt zu reinem Text zusammenzufallen.
Es gibt keine Outlook-Installation, kein MAPI-Profil und keine COM-Automatisierung – derselbe Grund, warum die Word‑Geschichte Interop vermeidet.
Ein Vorgang, der E-Mails, Verträge, Tabellenkalkulationen und Zeichnungen enthält, wird über eine Komponente geöffnet. Benutzer lernen eine einheitliche Oberfläche.
Prüfer lesen Seiten. Die .msg verlässt das Archiv nie, sodass Aufbewahrung und Prüfung sinnvoll bleiben.
Integration
In der Praxis liegt der Wert nicht im isolierten E-Mail-Support. Es ist, dass eine Akte nicht mehr drei verschiedene Viewer und einen Download‑Button benötigt.
Unterstützte Erweiterungen
// Outlook and MIME messages open like any other document
string token = await viewer.OpenDocumentAsync("cases/2026-114/correspondence/thread-08.msg");
// The same viewer instance handles the rest of the matter —
// contracts, spreadsheets, drawings — through identical callsDetails
Nein. Parsen und Rendern sind nativ, was dies in einem Linux‑Container oder einem abgesicherten Windows‑Server, auf dem die Installation eines E‑Mail‑Clients keine Option ist, realisierbar macht.
Die Nachricht wird als Nachricht gerendert. Wenn Sie einen Anhang anzeigen möchten, extrahieren Sie ihn in Ihrem eigenen Code und öffnen Sie ihn als eigenes Dokument – er wird eines der Formate sein, die der Viewer bereits unterstützt.
Das können Sie mit dem Converter‑Plugin. Aber die Konvertierung ist ein Batch, den jemand verwalten und erneut ausführen muss, und sie verdoppelt Ihren Speicherbedarf. On‑Demand‑Rendering hält eine Kopie des Beweismaterials und erfordert keine zu betreuende Pipeline.
Word
Natives DOC/DOCX/RTF/ODT-Rendering ohne Office-Installation, ohne COM-Interop und ohne serverseitige Automatisierung.
WordASP.NET Core
Registriert sich als gewöhnliche DI plus Middleware. Erbt die Authentifizierung, das Logging und das Hosting, die Sie bereits haben.
ASP.NET CoreEine temporäre Lizenz lässt sich in wenigen Minuten anfordern und läuft vollständig auf Ihrem eigenen Rechner. Die wichtigen Dateien sind bereits die, die Ihren aktuellen Viewer zum Absturz bringen.