Email Recipient incorrectly Coded Attachments
Some email recipients on IPhones 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.
The issue is that Exchange can still encode attachments as RTF rather than MIME. There’s no need for this in a hosted SaaS email service in 2016 – it’s a legacy piece of Exchange functionality that’s probably kept around in the code-base for reasons known only to Microsoft.
You’ll undoubtedly come across various articles and suggestions that you need to indulge in a whole bunch of PowerShell commands in order to fix the problem but thankfully, there is an (apparent) fix lurking in the Office 365 Admin GUI. It goes like this:
- 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 – YMMV.
- 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”.
- For extra credit, you can change the default MIME encodings to Unicode (UTF-8) instead of Western (ISO), as in my experience it seems to transition through foreign mail servers better – but again, YMMV.
- Hit the Save button.
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” which should work 99 percent of the time.
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.