Mime Guru Needed! - Attachment File Names Munged from Mac->PC

[Doug]

(Using Entourage 10.1.4/SR1; OS X 10.3.6)

The problem:
=============
I send an attached file to a PC user. The mac file name is "test.xls". The
pc user gets a file named "test.xlsx-mac-creator="5843454C"

Some info:
==========
Looking at the source text of the email, it seems pretty obvious what is
happening. The mime part with the attachment says:

Content-type: application/x-msexcel; name="test.xls";
x-mac creator="5843454C";
x-mac type="5843454C"
Content-disposition: attachment
Content-transfer-encoding: base64

The PC is munging the first two lines of the mime type into a single name.
So, pretty easy to blame the pc mail reader (in this case Outlook), but I'm
not so sure. If I send multiple attachments, the 2nd through nth all work.

Even twistier:
==============
Another Entourage user at my office never has this problem. We looked at the
source of his emails. In his case, the mime type information reads:

Content-type: application/octet-stream; name="test.xls"
Content-disposition: attachment
Content-transfer-encoding: base64

It seems that this approach does not carry along the Mac creator or type,
which might be helpful on a Mac->Mac transfer, but obviously no value in
going to a pc.

When Entourage sends the attachment this way, it works on the pc end. But,
he and I compared what we think are ALL preference settings between our two
systems, and I couldn't get my output to match his.

Solutions:
==========
1) I'd be happy with a configuration solution for my machine that would
cause the attachment to be sent in the same way as on my colleagues machine
(btw, same Entourage version on both, same OS version on both). [Compose
settings: Auto check names, save copies to sent items and show html
formatting all on; Encode for Any Computer (AppleDouble); append file name
extensions off.]

2) Some other workaround or suggestion?

Thanks!!!
Doug

 

[Stephen Adams]

(Using Entourage 10.1.4/SR1; OS X 10.3.6)

The problem:
=============
I send an attached file to a PC user. The mac file name is "test.xls". The
pc user gets a file named "test.xlsx-mac-creator="5843454C"

Some info:
==========
Looking at the source text of the email, it seems pretty obvious what is
happening. The mime part with the attachment says:

Content-type: application/x-msexcel; name="test.xls";
x-mac creator="5843454C";
x-mac type="5843454C"
Content-disposition: attachment
Content-transfer-encoding: base64

The PC is munging the first two lines of the mime type into a single name.
So, pretty easy to blame the pc mail reader (in this case Outlook), but I'm
not so sure. If I send multiple attachments, the 2nd through nth all work.

Even twistier:
==============
Another Entourage user at my office never has this problem. We looked at the
source of his emails. In his case, the mime type information reads:

Content-type: application/octet-stream; name="test.xls"
Content-disposition: attachment
Content-transfer-encoding: base64

It seems that this approach does not carry along the Mac creator or type,
which might be helpful on a Mac->Mac transfer, but obviously no value in
going to a pc.

When Entourage sends the attachment this way, it works on the pc end. But,
he and I compared what we think are ALL preference settings between our two
systems, and I couldn't get my output to match his.

Solutions:
==========
1) I'd be happy with a configuration solution for my machine that would
cause the attachment to be sent in the same way as on my colleagues machine
(btw, same Entourage version on both, same OS version on both). [Compose
settings: Auto check names, save copies to sent items and show html
formatting all on; Encode for Any Computer (AppleDouble); append file name
extensions off.]

2) Some other workaround or suggestion?

Thanks!!!
Doug

A couple of years ago I had this problem. While I never did find my
ideal solution, I did find one that I could live with.

Firstly, I stopped sending HTML encoded messages. I would suggest you do
the same, unless you have a really valid reason. My co-workers' Outlook
client couldn't render the HTML messages in the same fashion as my
Entourage client did. Once I sent my messages as plain text and attached
any non-text files, things seemed to work a lot more smoothly.

Secondly, I set my attachment encoding preference to "Windows (MIME/base
64)" and left it there for all messages I sent, regardless of which
platform was to receive them. My thinking was that 97% of my recipients
would get the attachments without complaining; I could deal with the
other 3% that couldn't. That was much less stressful than the other way
around.

Thirdly, I set the "Append Windows extensions to file names" preference.
I did so because Windows knows nothing about "creator types" and all
that. It decides what to do with the attachment based upon the file name
extension only. If it gets a file without an extension, Windows and its
apps doesn't really know what to do with the file.

Give that a shot and see what happens. Like I said, it wasn't my ideal
setup because I didn't particularly care for setting up my Mac e-mail
clients to a Windows specification. But since most of my messaging went
to that platform type, it made sense to do so.

Steve

 

[Chris Ridd]

Secondly, I set my attachment encoding preference to "Windows (MIME/base
64)" and left it there for all messages I sent, regardless of which

I believe this might be the critical setting. I use this by default, and it
seems to occasionally cause a dialog to appear when I drag in a JPEG from
the Finder into the attachment panel, saying something like "There are
Mac-specific portions of this file that will be lost if you continue".

That is *probably* referring to the HFS+ creator and type codes, though
likely also refers to files bearing resource forks. (I do wish the
documentation would actually say what it was actually talking about.)

I can't remember if that dialog just allows you to continue or cancel, but
it would be worth the OP watching to see if the dialog ever came up.

Cheers,

Chris

 

[Bob Greenblatt]

I don't know about the mime encoding. However, you should set your encoding
to "Any computer ( Apple Double). I have NEVER had a problem sending files
to any version of PC using this encoding with any version of entourage.

 

[Stephen Adams]

I don't know about the mime encoding. However, you should set your encoding
to "Any computer ( Apple Double). I have NEVER had a problem sending files
to any version of PC using this encoding with any version of entourage.

Not to be contrary, but I went round and round in circles over this with
the IT folks where I used to work. They used Exchange server and Outlook
2000 for the PC clients. I used Entourage 2001 from home and sent
messages and attachments via my dial up ISP at the time. The ONLY way
they could receive the attachments I sent was by me using Windows
(MIME/base 64) encoding when sending the messages.

I know nothing about how Exchange servers operate, let alone how they're
set up. Perhaps it was a server side preference that necessitated the
use of that particular encoding scheme. It might have even been
something that my ISP's mail servers did while passing the messages and
attachments along.

All I suggested to the OP was that, perhaps, it might be something to
try out.

Steve

 

[Stephen Adams]

I believe this might be the critical setting. I use this by default, and it
seems to occasionally cause a dialog to appear when I drag in a JPEG from
the Finder into the attachment panel, saying something like "There are
Mac-specific portions of this file that will be lost if you continue".

That is *probably* referring to the HFS+ creator and type codes, though
likely also refers to files bearing resource forks. (I do wish the
documentation would actually say what it was actually talking about.)

I can't remember if that dialog just allows you to continue or cancel, but
it would be worth the OP watching to see if the dialog ever came up.

Cheers,

Chris

My understanding is that the dialog is letting the Mac sender know that
Mac-only resource forks won't be sent to the PC user. This makes sense
since PCs don't use resource forks. They use file name extensions, which
is why it's good procedure to set Entourage to include such extensions
to the file name when sending the attachments.

Steve

 

[Chris Ridd]

My understanding is that the dialog is letting the Mac sender know that
Mac-only resource forks won't be sent to the PC user. This makes sense
since PCs don't use resource forks. They use file name extensions, which
is why it's good procedure to set Entourage to include such extensions
to the file name when sending the attachments.

Resource forks aren't related to file extensions. It is quite a common
misconception, but the Mac type and creator code values are held in the file
metadata (along with the various timestamps that you can see in Finder's Get
Info.)

You can have a file with a type and creator code set, but no resource fork.

You can also have a file with a resource fork, but no type and creator code
set.

It does seem like a good idea to allow Entourage to append file extensions
to attachments being sent, to stop Windows users from getting confused.
(Though that's sometimes a fun thing to do.)

Cheers,

Chris