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

Discussion in 'Windows Live Mail' started by dan, Dec 28, 2009.

  1. dan

    dan Guest

    hi there,

    Just installed my wife's new windows 7 professional pc. no outlook installed
    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

    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

    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?


    dan, Dec 28, 2009
    1. Advertisements

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


    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 \(MVP\), Dec 28, 2009
    1. Advertisements

  3. dan

    Dan Guest

    hello gary,

    that is an interesting thought. I've read the mentioned article about
    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, Dec 28, 2009
  4. 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.
    Michael Santovec, Dec 28, 2009
  5. dan

    Dan Guest

    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...]

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

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

    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

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

    Dan, Dec 28, 2009
  6. dan

    ...winston Guest

    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

    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, Dec 29, 2009
  7. 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

    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

    Michael Santovec, Dec 29, 2009
  8. dan

    Dan Guest

    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, Dec 29, 2009
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.