The problem: Some email recipients on Mac OS X using Apple Mail and Gmail receive winmail.dat attachments in place of correctly-encoded MIME attachments from users running Outlook 2016/Windows 10/Office 365 hosted mail. They can’t open the faulty attachments and (in my case) the result was some grumpy clients.
The cause: The real issue here is that Exchange can still encode attachments as RTF rather than MIME. In my view, there’s no need for this in a hosted SaaS email system in 2017 – it’s a legacy piece of Exchange functionality going all the way back to mid 1990’s that has been kept around in the code-base for reasons that pass understanding. It’s definitely a problem for those of us who don’t need backwards-compatibility to dinosaur-era Exchange servers; how many of those can honestly still be in use today?
The solution: If you’ve been experiencing this problem and you’ve researched it you have undoubtedly come across various articles and suggestions that you need to go through a number of PowerShell back-flips in order to correct it, however you don’t need to do that; you can fix this directly from the Office 365 Admin portal and here’s how you do it…
- Login to your Office 365 Portal (portal.office.com) using your Admin credentials.
- Click the Admin icon.
- Flip down the Admin sub-menu from the left-hand menu, and click Exchange. This will take you to your hosted Exchange admin page.
- Click Mail Flow from the left hand menu.
- Click Remote Domains from the top menu line. This will allow you to configure a specific set of rules for the offending recipient domains.
- Click the Plus icon above the name field. This brings up a separate page that allows you to start the process of configuring the rules for the recipient domain(s).
- Give the configuration a suitable name for the rule you’re adding.
- Add the fully-qualified domain name for the recipient that’s having the problem with the winmail.dat attachments. As far as I can tell, the configuration should support wildcards
- About two-thirds of the way down the page, you’ll find the “use rich text” setting – it will default to “Follow user settings”. Change this to “Never”.
- I also suggest you can change the default MIME encodings to Unicode (UTF-8) because in my experience it seems to transition through foreign mail servers better
- Hit the Save button.
Of course, you’ll need to add each domain individually if you have lots of recipients with the winmail.dat problem. The obvious fix is to use the “default” rule to set “use rich text” to “Never” – although in our case our Exchange instance already had this setting, but the problem persisted, go figure…
From my perspective, the likely cause is that the Office 365 Exchange instance isn’t respecting the encoding preferences in the Outlook 2016 client – in which case it’s a Microsoft bug and they should feel free to correct that. :-/
If you’d been experiencing this problem and you stumbled upon this post, I hope it helped you out.