.msg attachments do not keep right extension - can't open

hi there,

Just installed my wife's new windows 7 professional pc. no outlook installed
here.
the old win xp with outlook 2003 still runs beside it.

my wife receives email message from a friend. those messages have other
messages as attachments. on outlook 2003 (win xp) I can open those messages.
on windows live desktop, I see that there are attachments, but I can't open.
before you start to mention the extensions and the standard applications,
please read on.

for example the following:

on outlook 2003 (on XP), the attachment name shows as "for you... (813
Byte)(3KB)". if I save the attachment on the desktop, I get a file with the
name "for you...(813 Byte).msg. obviously, I can open that file with no
problems.

the same message on Live Mail Desktop on Win 7. the attachment name shows as
"for you.__ (813 Bytes)". if saved to the desktop, I get a file with the name
"for you.__". note that there is no .msg or .eml extension.

obviously, if doubleclicked in live mail, there is no application assigned
to that extension.

in another case, the attachment name is "Weihnachtsrätsel......". again, on
win xp with outlook, all is fine. on windows 7 with live mail, I get a file
name like this for that attachment: "Weihnachtsrätsel._._". again a weird
"extension".

I guess that Windows Live Mail Desktop can't handle attachment file names
that are ending with a few dots?

or is there somewhere a setting that will solve this issue?

thanks

dan

Chances are, that sender is using Outlook when sending.
The explanation for that problem is here:

http://email.about.com/od/outlooktips/qt/et121705.htm

The basic problem is that Outlook, by default, uses a proprietary
form of encoding for attachments, which is not readable by
non-Outlook mail clients.
Ask the sender to resend the attachment using either plain text (preferred) or
standard HTML format.

Alternatively, your Outlook 2003 may be licensed to run on two or three
computers, so you may be able to install it on your Windows 7 PC.

--
Gary VanderMolen, Microsoft MVP (Mail)
http://mvp.support.microsoft.com/def...le/vandermolen


"dan" <> wrote in message news:9D8B1167-A5C3-4EF7-AF2A-...
> hi there,
>
> Just installed my wife's new windows 7 professional pc. no outlook installed
> here.
> the old win xp with outlook 2003 still runs beside it.
>
> my wife receives email message from a friend. those messages have other
> messages as attachments. on outlook 2003 (win xp) I can open those messages.
> on windows live desktop, I see that there are attachments, but I can't open.
> before you start to mention the extensions and the standard applications,
> please read on.
>
> for example the following:
>
> on outlook 2003 (on XP), the attachment name shows as "for you... (813
> Byte)(3KB)". if I save the attachment on the desktop, I get a file with the
> name "for you...(813 Byte).msg. obviously, I can open that file with no
> problems.
>
> the same message on Live Mail Desktop on Win 7. the attachment name shows as
> "for you.__ (813 Bytes)". if saved to the desktop, I get a file with the name
> "for you.__". note that there is no .msg or .eml extension.
>
> obviously, if doubleclicked in live mail, there is no application assigned
> to that extension.
>
> in another case, the attachment name is "Weihnachtsrätsel......". again, on
> win xp with outlook, all is fine. on windows 7 with live mail, I get a file
> name like this for that attachment: "Weihnachtsrätsel._._". again a weird
> "extension".
>
> I guess that Windows Live Mail Desktop can't handle attachment file names
> that are ending with a few dots?
>
> or is there somewhere a setting that will solve this issue?
>
> thanks
>
> dan
>

hello gary,

that is an interesting thought. I've read the mentioned article about
winmail.dat.
however, i can't find the same conclusions.
the attachements are actually plain text emails forwarded.
that is, there is no formatting in there.

in addition, I've checked on the mail provider webmail frontend and did
not find a winmail.dat.

I still think it's only an issue with the attachment name containing
dots at the end...

I will test further..

dan


On 28.12.2009 20:00, Gary VanderMolen (MVP) wrote:
> Chances are, that sender is using Outlook when sending.
> The explanation for that problem is here:
>
> http://email.about.com/od/outlooktips/qt/et121705.htm
>
> The basic problem is that Outlook, by default, uses a proprietary
> form of encoding for attachments, which is not readable by
> non-Outlook mail clients.
> Ask the sender to resend the attachment using either plain text (preferred) or
> standard HTML format.
>
> Alternatively, your Outlook 2003 may be licensed to run on two or three
> computers, so you may be able to install it on your Windows 7 PC.
>

You have two issues, neither of which is the Winmail.dat problem.

Attachments that end in two of more dots get saved without any
extension. This commonly shows up when someone forwards a message where
the subject ends in ... The subject becomes the attachment file name.
The workaround for this is save the attachment and then rename it adding
the appropriate extension.

This is a design feature of Outlook Express, Windows Mail and Windows
Live Mail. Priority is given to the file extension over the MIME
Content-type. If there is no file extension, then the content-type will
be used to make up the file extension. Most other mail programs don't
provide an extension for forwarded messages. This normally is OK except
when the subject ends in the multiple dots. In that case instead of
treating it as an attachment with a missing extension, it is taken as an
attachment that is not to have any extension.

The second and bigger issue, is that the .MSG file type is unique to the
Office Outlook program. The actual file contents is different than an
EML file and WLM can't make sense of a MSG file. Lacking Outlook, you'd
need a 3rd party MSG viewer in order to read the file.

--

Mike - http://TechHelp.Santovec.us



"Dan" <> wrote in message
news:e8$4w7$...
> hello gary,
>
> that is an interesting thought. I've read the mentioned article about
> winmail.dat.
> however, i can't find the same conclusions.
> the attachements are actually plain text emails forwarded.
> that is, there is no formatting in there.
>
> in addition, I've checked on the mail provider webmail frontend and
> did not find a winmail.dat.
>
> I still think it's only an issue with the attachment name containing
> dots at the end...
>
> I will test further..
>
> dan
>
>
> On 28.12.2009 20:00, Gary VanderMolen (MVP) wrote:
>> Chances are, that sender is using Outlook when sending.
>> The explanation for that problem is here:
>>
>> http://email.about.com/od/outlooktips/qt/et121705.htm
>>
>> The basic problem is that Outlook, by default, uses a proprietary
>> form of encoding for attachments, which is not readable by
>> non-Outlook mail clients.
>> Ask the sender to resend the attachment using either plain text
>> (preferred) or
>> standard HTML format.
>>
>> Alternatively, your Outlook 2003 may be licensed to run on two or
>> three
>> computers, so you may be able to install it on your Windows 7 PC.
>>
>

hello michael,

yeah, I thought something like this. thanks for explaining.
I find it strange (well, not so strange as the MS programmers are
probably not the same for Outlook/Office products and things like WLM?),
that an RFC (i.e. rfc2183) can be interpreted in such different ways.

you call it a design feature, while I would call it a hidden feature
(a.k.a. bug ;-)

looking at the message parts defining the MIME body part in my test message:

================================================== =============

[...email RFC headers...]

------=_Part_1953_6850373.1261664468474
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

[...some text from the email message comes here...]

------=_Part_1953_6850373.1261664468474
Content-Type: message/rfc822; name="for you..."
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="for you..."

[...other text (including rfc822 mail header) that is in the attached
message comes here...]

================================================== =============

I would have assumed that Content-Type would have preference and thus
the email client would know that this second part is a valid RFC822
message. and would treat it as such..

(see rfc1341:
7.3.1 The Message/rfc822 (primary) subtype
A Content-Type of "message/rfc822" indicates that the body contains an
encapsulated message, with the syntax of an RFC 822 message.)


reading through rfc2183, I would have interpreted the follwing
paragraphs as a direction to use the proper .msg or.eml extension (on
windows) when writing the attachment:


-----from frc2183---------------

[...]
2.2 The Attachment Disposition Type

Bodyparts can be designated `attachment' to indicate that they are
separate from the main body of the mail message, and that their
display should not be automatic, but contingent upon some further
action of the user. The MUA might instead present the user of a
bitmap terminal with an iconic representation of the attachments, or,
on character terminals, with a list of attachments from which the
user could select for viewing or storage.

2.3 The Filename Parameter

The sender may want to suggest a filename to be used if the entity is
detached and stored in a separate file. If the receiving MUA writes
the entity to a file, the suggested filename should be used as a
basis for the actual filename, where possible.

It is important that the receiving MUA not blindly use the suggested
filename. The suggested filename SHOULD be checked (and possibly
changed) to see that it conforms to local filesystem conventions,
does not overwrite an existing file, and does not present a security
problem (see Security Considerations below).

[...]

-----------------------------------

apparently, in WLM, "Content-Disposition" has preference and is not
considering "Content-Type" as input for it's decision to use the right
extensions. probably the same logic applies when I click on the
attachment to open in within WLM?

anyway, for me this looks more like a flaky implementation of that rfc,
rather than a feature..

the second issue you describe is IMHO less a problem. at least when I
look at it from a user perspective. as long as WLM knows what to do with
a valid MIME encoded rfc822 attachment when I doubleclick on it (means
display it) or save it (means using a proper system recognizeable
extension), I am totally happy. well.. it seems I am unhappy?

on my Win 7 system, the .msg handler is something called "Microsoft
Office Client Virtualization Handler" (I only have Office 2010 click to
run installed for testing). so, my system *would* know what to do with a
..msg file. if only WLM would tell it that it is a .msg file...
by the way, the .eml file is having the same standard application
defined...


way cool. thanks for the hints. was fun to dig again into RFC's.. ;-)


dan









On 28.12.2009 22:38, Michael Santovec wrote:
> You have two issues, neither of which is the Winmail.dat problem.
>
> Attachments that end in two of more dots get saved without any
> extension. This commonly shows up when someone forwards a message where
> the subject ends in ... The subject becomes the attachment file name.
> The workaround for this is save the attachment and then rename it adding
> the appropriate extension.
>
> This is a design feature of Outlook Express, Windows Mail and Windows
> Live Mail. Priority is given to the file extension over the MIME
> Content-type. If there is no file extension, then the content-type will
> be used to make up the file extension. Most other mail programs don't
> provide an extension for forwarded messages. This normally is OK except
> when the subject ends in the multiple dots. In that case instead of
> treating it as an attachment with a missing extension, it is taken as an
> attachment that is not to have any extension.
>
> The second and bigger issue, is that the .MSG file type is unique to the
> Office Outlook program. The actual file contents is different than an
> EML file and WLM can't make sense of a MSG file. Lacking Outlook, you'd
> need a 3rd party MSG viewer in order to read the file.
>

Rich Text composition is not the default in Outlook.
The user would have had to modify the default to send in Rich Text.


The following is applicable to Outlook 2007 as the sending client:
Sending a message in Html or plain text format in Outlook with an Outlook message(*.msg) attached and upon arrival in WLM will
permit the attachment received in WLM to be dragged to a folder(or desktop) and/or saved as an *.eml message.

Send a message in Rich Text will include the attachment in the body of the composed Outlook message. Upon arrival in WLM the
attachment will follow the same as above(dragged or saved as an *.eml message)
- if Outlook is left in Default mode(I.e. the default for sending to the Internet is not changed and left as 'Convert Rich Text to
Html')

Thus it doesn't matter if Outlook is operating in the default mode or composing in Rich Text with Outlook's default...it does
matter if composing in Rich Text and the option when sending Rich Text messages to Internet recipients is changed from its default
'convert to Html' to not convert and 'send in Rich Text'...in this case...the attachment in the body of the Rich Text message will
be stripped upon arrival in WLM(no attachment at all)



--
...winston
ms-mvp mail

"Gary VanderMolen (MVP)" <> wrote in message news:eVs5KA$...
> Chances are, that sender is using Outlook when sending.
> The explanation for that problem is here:
>
> http://email.about.com/od/outlooktips/qt/et121705.htm
>
> The basic problem is that Outlook, by default, uses a proprietary
> form of encoding for attachments, which is not readable by
> non-Outlook mail clients.
> Ask the sender to resend the attachment using either plain text (preferred) or
> standard HTML format.
>
> Alternatively, your Outlook 2003 may be licensed to run on two or three
> computers, so you may be able to install it on your Windows 7 PC.
>
> --
> Gary VanderMolen, Microsoft MVP (Mail)
> http://mvp.support.microsoft.com/def...le/vandermolen
>
>
> "dan" <> wrote in message news:9D8B1167-A5C3-4EF7-AF2A-...
>> hi there,
>>
>> Just installed my wife's new windows 7 professional pc. no outlook installed
>> here.
>> the old win xp with outlook 2003 still runs beside it.
>>
>> my wife receives email message from a friend. those messages have other
>> messages as attachments. on outlook 2003 (win xp) I can open those messages.
>> on windows live desktop, I see that there are attachments, but I can't open.
>> before you start to mention the extensions and the standard applications,
>> please read on.
>>
>> for example the following:
>>
>> on outlook 2003 (on XP), the attachment name shows as "for you... (813
>> Byte)(3KB)". if I save the attachment on the desktop, I get a file with the
>> name "for you...(813 Byte).msg. obviously, I can open that file with no
>> problems.
>>
>> the same message on Live Mail Desktop on Win 7. the attachment name shows as
>> "for you.__ (813 Bytes)". if saved to the desktop, I get a file with the name
>> "for you.__". note that there is no .msg or .eml extension.
>>
>> obviously, if doubleclicked in live mail, there is no application assigned
>> to that extension.
>>
>> in another case, the attachment name is "Weihnachtsrätsel......". again, on
>> win xp with outlook, all is fine. on windows 7 with live mail, I get a file
>> name like this for that attachment: "Weihnachtsrätsel._._". again a weird
>> "extension".
>>
>> I guess that Windows Live Mail Desktop can't handle attachment file names
>> that are ending with a few dots?
>>
>> or is there somewhere a setting that will solve this issue?
>>
>> thanks
>>
>> dan
>>

Giving priority to the file extension over the content-type has long
been a Microsoft policy, including in IE. Other software companies have
generally gone the other way.

Depending on the circumstances sometimes one way works better than
others. With many web servers, they look at the file extension and
compare it to a server table to determine the content-type to tell the
browser. If the server didn't recognize the extension, it would use the
generic "application/octet-stream". For a browser giving priority to
the content-type, it wouldn't know what to do with the file. In the
case of IE, as long as the Windows File Associations recognized the file
extension, the recipient could open the file in the expected
application. In the early Internet days, this was a bonus since most
web servers had tables recognizing only a few common file types. Today,
that's less of an issue since most web servers recognize more file
types.

In your specific example

Content-Type: message/rfc822; name="for you..."
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="for you..."

the ... is interpreted by WLM that the file is not to have any extension
and so the file name is to be "for you", and having no extension is
unknown to Windows.

If the coding had been

Content-Type: message/rfc822; name="for you"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="for you"

WLM would have said that the sending program failed to provide an
extension and would have looked at the content-type and would have
interpreted the intended file name to be "for you.EML" and would have
handled the attachment correctly.

--

Mike - http://TechHelp.Santovec.us



"Dan" <> wrote in message
news:...
> hello michael,
>
> yeah, I thought something like this. thanks for explaining.
> I find it strange (well, not so strange as the MS programmers are
> probably not the same for Outlook/Office products and things like
> WLM?), that an RFC (i.e. rfc2183) can be interpreted in such different
> ways.
>
> you call it a design feature, while I would call it a hidden feature
> (a.k.a. bug ;-)
>
> looking at the message parts defining the MIME body part in my test
> message:
>
> ================================================== =============
>
> [...email RFC headers...]
>
> ------=_Part_1953_6850373.1261664468474
> Content-Type: text/plain; charset=utf-8
> Content-Transfer-Encoding: quoted-printable
>
> [...some text from the email message comes here...]
>
> ------=_Part_1953_6850373.1261664468474
> Content-Type: message/rfc822; name="for you..."
> Content-Transfer-Encoding: 7bit
> Content-Disposition: attachment; filename="for you..."
>
> [...other text (including rfc822 mail header) that is in the attached
> message comes here...]
>
> ================================================== =============
>
> I would have assumed that Content-Type would have preference and thus
> the email client would know that this second part is a valid RFC822
> message. and would treat it as such..
>
> (see rfc1341:
> 7.3.1 The Message/rfc822 (primary) subtype
> A Content-Type of "message/rfc822" indicates that the body contains an
> encapsulated message, with the syntax of an RFC 822 message.)
>
>
> reading through rfc2183, I would have interpreted the follwing
> paragraphs as a direction to use the proper .msg or.eml extension (on
> windows) when writing the attachment:
>
>
> -----from frc2183---------------
>
> [...]
> 2.2 The Attachment Disposition Type
>
> Bodyparts can be designated `attachment' to indicate that they are
> separate from the main body of the mail message, and that their
> display should not be automatic, but contingent upon some further
> action of the user. The MUA might instead present the user of a
> bitmap terminal with an iconic representation of the attachments,
> or,
> on character terminals, with a list of attachments from which the
> user could select for viewing or storage.
>
> 2.3 The Filename Parameter
>
> The sender may want to suggest a filename to be used if the entity
> is
> detached and stored in a separate file. If the receiving MUA writes
> the entity to a file, the suggested filename should be used as a
> basis for the actual filename, where possible.
>
> It is important that the receiving MUA not blindly use the
> suggested
> filename. The suggested filename SHOULD be checked (and possibly
> changed) to see that it conforms to local filesystem conventions,
> does not overwrite an existing file, and does not present a
> security
> problem (see Security Considerations below).
>
> [...]
>
> -----------------------------------
>
> apparently, in WLM, "Content-Disposition" has preference and is not
> considering "Content-Type" as input for it's decision to use the right
> extensions. probably the same logic applies when I click on the
> attachment to open in within WLM?
>
> anyway, for me this looks more like a flaky implementation of that
> rfc, rather than a feature..
>
> the second issue you describe is IMHO less a problem. at least when I
> look at it from a user perspective. as long as WLM knows what to do
> with a valid MIME encoded rfc822 attachment when I doubleclick on it
> (means display it) or save it (means using a proper system
> recognizeable extension), I am totally happy. well.. it seems I am
> unhappy?
>
> on my Win 7 system, the .msg handler is something called "Microsoft
> Office Client Virtualization Handler" (I only have Office 2010 click
> to run installed for testing). so, my system *would* know what to do
> with a .msg file. if only WLM would tell it that it is a .msg file...
> by the way, the .eml file is having the same standard application
> defined...
>
>
> way cool. thanks for the hints. was fun to dig again into RFC's.. ;-)
>
>
> dan
>
>
>
>
>
>
>
>
>
> On 28.12.2009 22:38, Michael Santovec wrote:
>> You have two issues, neither of which is the Winmail.dat problem.
>>
>> Attachments that end in two of more dots get saved without any
>> extension. This commonly shows up when someone forwards a message
>> where
>> the subject ends in ... The subject becomes the attachment file
>> name.
>> The workaround for this is save the attachment and then rename it
>> adding
>> the appropriate extension.
>>
>> This is a design feature of Outlook Express, Windows Mail and Windows
>> Live Mail. Priority is given to the file extension over the MIME
>> Content-type. If there is no file extension, then the content-type
>> will
>> be used to make up the file extension. Most other mail programs
>> don't
>> provide an extension for forwarded messages. This normally is OK
>> except
>> when the subject ends in the multiple dots. In that case instead of
>> treating it as an attachment with a missing extension, it is taken as
>> an
>> attachment that is not to have any extension.
>>
>> The second and bigger issue, is that the .MSG file type is unique to
>> the
>> Office Outlook program. The actual file contents is different than
>> an
>> EML file and WLM can't make sense of a MSG file. Lacking Outlook,
>> you'd
>> need a 3rd party MSG viewer in order to read the file.
>>
>

thanks for the explanation, mike.
very detailed and understandable.

i just don't understand why the case you described in your last
parapgraph below (missing extension), could not also be applied to the
"..." case. there is no rule without exception. and this exception is
probably well known. a simple "case" or "if" statement would do the job
I guess..

anyway. let's close that for now. it was great information from you,
mike. i really appreciate it!

dan




On 29.12.2009 22:48, Michael Santovec wrote:
> Giving priority to the file extension over the content-type has long
> been a Microsoft policy, including in IE. Other software companies have
> generally gone the other way.
>
> Depending on the circumstances sometimes one way works better than
> others. With many web servers, they look at the file extension and
> compare it to a server table to determine the content-type to tell the
> browser. If the server didn't recognize the extension, it would use the
> generic "application/octet-stream". For a browser giving priority to
> the content-type, it wouldn't know what to do with the file. In the
> case of IE, as long as the Windows File Associations recognized the file
> extension, the recipient could open the file in the expected
> application. In the early Internet days, this was a bonus since most
> web servers had tables recognizing only a few common file types. Today,
> that's less of an issue since most web servers recognize more file
> types.
>
> In your specific example
>
> Content-Type: message/rfc822; name="for you..."
> Content-Transfer-Encoding: 7bit
> Content-Disposition: attachment; filename="for you..."
>
> the ... is interpreted by WLM that the file is not to have any extension
> and so the file name is to be "for you", and having no extension is
> unknown to Windows.
>
> If the coding had been
>
> Content-Type: message/rfc822; name="for you"
> Content-Transfer-Encoding: 7bit
> Content-Disposition: attachment; filename="for you"
>
> WLM would have said that the sending program failed to provide an
> extension and would have looked at the content-type and would have
> interpreted the intended file name to be "for you.EML" and would have
> handled the attachment correctly.
>