- Others get the attachment, so, it must not be on our end.
- Send a test message from a non-client account and the attachment goes through, so, it must be on our end.
- Apparently it's nobody's fault.
I'm sure that everyone that supports Outlook has at one time or another run into the winmail.dat attachment problem when Outlook sends RTF formatted email to a client that doesn't understand it. In this case, the client receiving the email partially understood RTF. It understood it enough to get the text message out, but not the attachment. The whole message was being delivered, but the client software dropped the attachment.
Outlook allows you to define on a per contact basis what formatting will be used when sending a message to a recipient. I'm yet to find a user that sets this on purpose, but in this case, it was accidentally set for RTF.
Rather than trying to fix this at the Outlook level and to ensure that it never happens again, I've disable RTF at the Exchange server level. If the client sends an RTF formatted message, Exchange will change it to HTML which is much more widely supported.
In Exchange Server, you can set how RTF format is used per domain. By default, there is a single domain in Organization Configuration > Hub Transport > Remote Domains, named Default. On the Message Format tab for this domain, under Exchange rich-text format, select Never Use. After doing this attachments were delivered correctly.
|Properties of Default Remote Domain|