Mac Outlook 2011 latest version available via Office 365 is sending all attachments encoded using Content Type: application/mac-binhex40. This has been verified by sending the email and then taking the message automatically stored in the Sent Items folder and inspecting it with a text editor. This obviously will not be readable by any non-Mac mail reader by definition, so the problem is NOT in the communications with the server, and for completeness the receiving server is a simple SMTP connection with no filtering so all explanatiions involving Exchange servers or server filtering do not apply.

The question here is very straight-forward: what would cause Mac Outlook 2011 to use mac-binhex40 encoding for attachments when that ability is not even supported?

We believe the cause is related to the fact that the User Identity was created from an Entourage installation (which converted without error) that had had a similar problem that had occurred only recently. Entourage used to have an option that let you specify using Binhex or MIME64 encoding, and we suspect that this setting may have somehow been carried over to the new Outlook installation, but Outlook does not have this option available. 

We need to know where this setting might be that would cause this encoding to occur and how to turn it back to MIME64.

I have seen dozens of similar complaints about attachment problems with Mac Outlook 2011 that are unresolved, and I believe this encoding issue is the real reason.

Any information that anyone might have about it would be appreciated.

Hi PMC99,

I noticed the question is about Outlook for Mac, please note in this forum we mainly discuss questions and feedbacks about Office for Windows, I suggest you post the question in the Office for Mac forum to get more dedicated assistance:

http://answers.microsoft.com/en-us/mac

The reason why we recommend posting appropriately is you will get the most qualified pool of respondents, and other partners who read the forums regularly can either share their knowledge or learn from your interaction with us. Thank you for your understanding.

Regards,

Melon Chen
TechNet Community Su

Sorry to hear that the Mac version is not considered a relevant IT Pro issue, and has to be relegated to consumer support.

For folks who stumble upon this thread, the repost can be found here over in the consumer community forums:

http://answers.microsoft.com/en-us/mac/forum/macofficeo365-macoutlook/mac-outlook-2011-sends-email-attachments-encoded/408b7a70-57d4-4844-b0fb-809562caef0e?tm=1434945123022

The reason I unproposed your answer is that while the Mac users are over in the Consumer forums, it's just that: an end user forum, while I am facing an IT problem where I have IT resources at my disposal to solve it. It may be true that you're all "Windows" people, but I am in search of answers about the *internals* of Outlook on the Mac, and this is the closest thing to providing that.

As I said over in the thread linked in my previous response:

We would love to not have to reverse engineer the exact bits that change in files under the conditions we're describing here, but that is hours or days of investigation that someone on the Mac Outlook team who is familiar with the code can answer in 5 minutes.

It's also obvious from searching the internet that this is actually a huge problem affecting at least hundreds of Entourage to Outlook users, and yes, someone ought to put out a patch that fixes the problem because it's really a silly issue: No one uses binhex encoding any more and the fact that Outlook blindly brings it over from Entourage installations with no way to remedy the situation is incredible.

Would greatly appreciate it if you could send someone who is familiar with the internals over this way so we can fix the situation without spending thousands of dollars in developer time to fix it on our own.

We're in a production environment, so we can't really make the users switch to a preview product, although if we have to reverse engineer, we may use it to simply find what bits get flipped.

Sorry.