winmail.dat on a Jira or JSM request: why it is there and how to get the real attachment

What winmail.dat is

Outlook and Exchange have their own way of sending a message with formatting: Rich Text Format, carried in a container called TNEF (Transport Neutral Encapsulation Format). Inside that container sit the formatting, any attachments and some Outlook-only fields. Other Microsoft systems unpack it without you noticing. Anything that is not Exchange, including Jira's mail handler, sees one opaque file named winmail.dat and treats it as the attachment.

So the screenshot is not lost. It is inside the file, together with whatever else the sender attached.

What Jira does with it

Jira Cloud and Jira Service Management Cloud attach winmail.dat to the request as-is. They do not open the container or pull out the real files. That has been an open suggestion on Atlassian's tracker since 2016 (JSDCLOUD-4383). Atlassian's own knowledge base describes the worst case: when the whole message body is sent as TNEF, the mail handler cannot read it and creates the work item with an empty description (Jira created issue from e-mail has no description). Their advice is the same as ours: change the format on the sending side.

You will usually see it on requests created from email. If an agent forwards a message as an attachment, the forwarded email itself can carry a winmail.dat inside it.

Opening the winmail.dat you already have

Two ways, depending on where the file is.

Ask the sender to resend. Fastest when the customer is reachable: ask them to send the attachment again as a plain HTML email (the setting is in the next section). Everything they attach arrives as normal files.

Open the file yourself. There are winmail.dat openers for Windows, macOS and as websites. The websites upload the file to someone else's server; for customer data that is a bad habit, so prefer a tool that runs on your own machine. Once unpacked, attach the real files to the request so the next agent does not have to repeat this.

Stopping it at the source

The file is created by the sender's Outlook or Exchange, so the fix lives there. Pass this section on to the customer or their IT team.

In Outlook (per person). In new Outlook for Windows: Settings, then Mail, then Compose and reply, and set Message format to HTML. Rich Text is the setting that produces TNEF. Outlook also remembers a rich-text preference for individual addresses it has autocompleted before; removing the address from the autocomplete list (the small X next to the suggestion) and typing it again clears that memory.

In Exchange Online (for everyone in the organisation). An admin can tell Exchange never to send TNEF to outside domains. In the Exchange admin center: Mail flow, then Remote domains, open the remote domain that covers the service desk's email address, choose Edit text and character set, and set "Use rich-text format" to Never. The same thing in PowerShell, from Microsoft's own article, for that remote domain:

Set-RemoteDomain -Identity <remote domain> -TNEFEnabled $false

For a single external address instead of a whole domain:

Set-MailContact <address> -UseMapiRichTextFormat Never

Microsoft's reference for both: How to specify the email message format that's used for external recipients to prevent Winmail.dat attachments.

Your own JSM email address counts as an outside domain for the customer's Exchange, which is exactly why their colleagues never see the problem and you do.

Keeping emails readable on the request

winmail.dat is one of several ways an email loses something on the way into Jira. Forwarded emails arrive as a file without an extension, dragged-in .msg and .eml files show as code or raw text, and inline forwards drop the headers. The guides on forwarding emails into JSM and missing email attachments cover those.

Full disclosure: Dortus makes MailView, which shows .eml and .msg attachments on a work item as the email itself. Support for winmail.dat is being built; this page will say so when it is live.

Short answers

Is winmail.dat dangerous? Not by itself. It is a container. Treat the files inside it the way you would treat any attachment from that sender.

Why does it only happen with some customers? Because it depends on the sender's Outlook or Exchange settings, not on yours. One organisation with Rich Text turned on will send it every time; everyone else never will.

Can Jira be set to unpack it? No. There is no setting for it in Jira Cloud or JSM Cloud. Atlassian's knowledge base points to a third-party mail handler app (JEMH) for this; we have not tested it.

Will renaming the file help? No. It is not a zip and not an email; it needs a tool that understands TNEF.

Questions

Spotted something wrong on this page, or a case we missed? Email support@dortus.com.