MSO File Documentation

---

Technical details

Feature	Value
Full name	Microsoft Office HTML/OLE data stream (oledata.mso)
File extension	.mso
Typical names	oledata.mso, editdata.mso
MIME type	application/x-mso
Format type	ActiveMime-wrapped OLE2 compound file (binary)
Developer	Microsoft
Introduced	c. 1999–2000 (Office 2000 HTML mail / web export)
Origin	Outlook packaging embedded objects in Word/RTF-format mail
Outer signature	41 63 74 69 76 65 4D 69 6D 65 (“ActiveMime”), offset 0
Payload	zlib/DEFLATE stream, commonly starting near offset 0x32
Inner container	OLE2 compound file (D0 CF 11 E0 A1 B1 1A E1)
Inner contents	Embedded OLE objects and/or a VBA macro project
Open standard	No — Microsoft proprietary
Security note	Can carry VBA macros; flagged by antivirus engines
Related extensions	.dat (winmail.dat/TNEF), .eml, .doc, .emz

What is an oledata.mso file?

An .mso file — almost always named oledata.mso or editdata.mso — is not a document anyone creates on purpose. It is an artifact of how Microsoft Outlook renders e-mail. When a message is composed in Word’s Rich-Text or Word-as-HTML editing mode and contains an embedded Office object (an inserted Excel chart, a Word drawing, an OLE object), Outlook packages that object’s data into an attachment. If the recipient’s mail client is not a matching version of Outlook, it cannot merge that data back into the message body, so the stream surfaces as a mysterious .mso attachment. The feature dates to Office 2000’s HTML-mail and web-page export, around 1999–2000.

The practical point for a recipient is that oledata.mso carries no information the sender meant to send as a file. It is formatting plumbing left over from an embedded object, and the content you actually want is elsewhere in the message. This is the same problem as winmail.dat: both are caused by Outlook using a proprietary mail representation that non-Outlook clients cannot decode. The rest of this article covers what is technically inside the file, because the wrapper is a real, documented structure — and one with security relevance, since the same container can carry macros.

The ActiveMime wrapper

The file is an ActiveMime stream. It begins at offset 0 with the literal ASCII string ActiveMime (hex 41 63 74 69 76 65 4D 69 6D 65), followed by a fixed header of version and length fields. After that header comes a zlib/DEFLATE-compressed payload. On the common case the compressed stream begins near offset 0x32 — roughly 50 bytes in — but the exact offset is not a fixed constant; it varies with the Office version that produced the file, so a robust parser scans for the zlib header (78 followed by a valid flag byte) rather than assuming a hard-coded position.

offset 0x00   "ActiveMime"           10-byte ASCII signature
offset 0x0A   header fields          version / reserved / length
offset ~0x32  zlib stream            78 9C ...  (DEFLATE-compressed)
              |
              v  (inflate)
              OLE2 compound file: D0 CF 11 E0 A1 B1 1A E1

The wrapper does nothing but compress and label the real payload. Inflating the zlib stream is the only way to see what the object actually is, which is why oledata.mso shows as opaque binary in a text editor and why a generic archiver does not open it directly: the compression is a bare DEFLATE stream inside a Microsoft-specific header, not a ZIP or gzip container an archiver recognises.

The inner OLE2 compound file

Decompressed, the payload is a standard OLE2 Compound File — Microsoft’s Compound File Binary format, the same container that legacy .doc and .xls files use. It starts with the compound-file signature D0 CF 11 E0 A1 B1 1A E1 and is organised internally like a small filesystem: a header, a FAT that chains 512-byte sectors, a directory of named storages (folders) and streams (files), and the stream data itself. This mini-filesystem is what lets one .mso hold several embedded objects side by side.

Inside that compound file are the embedded OLE objects Outlook stripped out of the message — and, if the source object was macro-enabled, a VBA project. The VBA project lives in its own storage (conventionally named Macros or VBA) containing a dir stream and per-module streams whose code is stored in a compressed form. That is the piece with security consequences, covered below.

MSO versus winmail.dat, and why both appear

Two different Outlook artifacts confuse recipients, and they are not the same format. winmail.dat is TNEF (Transport Neutral Encapsulation Format), signature 78 9F 3E 22, and it can hide your real attachments inside a proprietary envelope when Outlook sends in Rich-Text format. oledata.mso is an ActiveMime wrapper around embedded objects, signature ActiveMime, and it holds formatting data rather than your files. Both share one root cause: an outgoing message composed in Word/RTF mode instead of plain HTML or plain text. The cure is on the sender’s side — set the outgoing format to HTML or Plain Text and avoid embedding OLE objects in the body — not on the recipient’s. For the recipient, the safe response is almost always to ignore the .mso and read the message body.

Security: why .mso is a macro carrier

The .mso structure is security-relevant because of what the inner OLE2 file can contain. A genuine oledata.mso from a known contact is harmless leftover formatting. But the ActiveMime→OLE2 chain is a recognised macro-malware delivery path, and understanding the mechanics explains why antivirus engines flag standalone .mso files.

The attack works by abusing the layering. An attacker crafts a document whose embedded object is a macro-enabled OLE object; Outlook (or a weaponised Office file) serialises it into an ActiveMime .mso. The outer ActiveMime label plus the zlib compression obscures the payload from simple content scanners that only look for the D0 CF 11 E0 compound-file signature at offset 0 — because here that signature only appears after inflation, not in the raw file. Inside the decompressed OLE2 is a VBA project. If a user extracts the object and opens it in an Office application, the VBA AutoOpen / Document_Open entry points can execute macro code automatically. This ActiveMime-embedded-object technique is the same class used in the older CVE-2018-0802-era Office attacks. The takeaways are concrete: never extract-and-open an .mso from an unknown or unexpected sender, trust an antivirus engine that flags one, and remember that no legitimate workflow requires you to open oledata.mso as a document — the real content is in the message body.

Frequently asked questions

What is oledata.mso and do I need it?

It is a formatting attachment Outlook adds when a sender embeds an Office object in HTML/Word-format e-mail. You do not need it: it holds object and formatting data, not the content you want, which is in the message body. From a trusted sender you can ignore or delete it.

Is an MSO file a virus?

Usually not — it is normally harmless leftover formatting. But the inner OLE2 container can hold a VBA macro project, and crafted .mso files have been used to deliver Office macro malware, which is why security products flag them. Never extract and open one from an unknown sender, and trust your antivirus if it quarantines it.

How do I stop sending oledata.mso to people?

The problem is the sending Outlook’s message format. Set outgoing mail to HTML or Plain Text (not Rich Text / Word) under Outlook’s mail options, and avoid embedding OLE objects directly in the message body. Sending a real file as a normal attachment instead of an embedded object also avoids it.

References

• File Format Docs — MSO (ActiveMime / OLE reference)
• SANS Internet Storm Center — ActiveMime .mso as a macro-malware vector
• Microsoft — recipients receive winmail.dat / TNEF attachments (related Outlook issue)

Feedback

Was this page helpful?

Yes No

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.