Brian,
You are correct about the recipient having the ability to rename the file on
saving. However, someone has to remember to provide these instructions and
the user has to actually read/follow them. I was hoping we could find a way
to eliminate these steps of user involvement.
This is a problem some of our software guys are having in sending updated
software files to customers. In this one particular case, adding the .dat
extension caused some noticeably bad things to happen to the customer's
system as when they installed the update file, they were actually
overwriting another legitimate file (same filename but with an actual .dat
extension).
In doing a bit more testing today, it turns out that part of what I had said
in my earlier email was not quite right. That's what I get for assuming that
something that someone tells me is actually correct. Outlook does not add
the extension to the attachment in sending. As you suggested, it is added
after the email is received (even with Outlook). So the "rich-text option"
possibility turns out to be somewhat of a red herring. On reception, Outlook
itself adds the .dat extension (rich-text option or not).
For other typical email clients such as web based client software, you end
up with either the dreaded winmail.dat attachment (with rich-text option on)
or the filename with an extension added such as .txt if the rich-text option
is turned off.
This is the attachment portion of the raw mail file that is sent/received.
You can see that the filename is still intact at this point.
------=_NextPart_000_0008_01C63DD5.CDCD4CB0
Content-Type: application/octet-stream;
name="master"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="master"
I was hoping that someone might know how to make this work. Perhaps, some
way to convince Outlook to use some other encoding that doesn't cause the
filename to be mangled or ???