TB & "winmail,dat" attachments
rebro
mail-client?
So far I've tried in vain. Using e. g. an editor I get a full page of
weird metadata; using a program called *Winmail Reader* at the most I
come up with the result: This attachment is a MAPI 1.0 embedded message
and is not supported by this mail system.
Totally confused I'd be grateful for some support.
-rebro
Ralph Fox
Use one of the following programs to launch the winmail.dat file.
Then you can extract the attachments which are encoded inside
the winmail.dat file.
• Fentun -- http://www.fentun.com/
• WMDecode -- http://www.biblet.freeserve.co.uk/
• Winmail Opener -- http://www.eolsoft.com/freeware/winmail_opener/
Notes:
With Fentun, you cannot first open Fentun and then open the
winmail.dat file from within Fentun. You have to launch the
winmail.dat file using fentun.exe.
--
Kind regards
Ralph
Beauregard T. Shagnasty
This advice may or not be satisfactory to you. As I don't use Windows,
when I receive mail like you describe, and if it from someone I know, I
reply and ask them to resend whatever it was in a non-proprietary
format. Then, I'll possibly get a reply stating "it was some joke
forwarded to me." Ok, trash.
If *not* from someone I know .. straight to trash.
--
-bts
-Four wheels carry the body; two wheels move the soul
rebro
lead to a satisfactory result. In the case of Fentun and WMDecode the
result is again "This attachment is a MAPI 1.0 embedded message
and is not supported by this mail system". In the case of Winmail Opener
the text of the mail is reopened out of this "winmail.dat"-file and the
attachment is shown without a file-ending this time.
-rebro
Peter Taylor
The person who is sending you this mail is using Microsoft Outlook in
RTF format. Tell them to use HTML or plain text instead. There's nothing
interesting in that file.
--
Peter Taylor
rebro
according to your suggestion.
-rebro
rebro
-rebro
Peter Taylor
When I first got Outlook, I tested some form emails to Yahoo, Hotmail,
AOL, etc. to see how they would look and found that all my emails had a
winmail.dat attachment. I asked her and switched to HTML and the
attachment no longer went with the email.
--
Peter Taylor
Greywolf
> Thank you very much for your suggestions! But unfortunately they didn't
> lead to a satisfactory result. In the case of Fentun and WMDecode the
> result is again "This attachment is a MAPI 1.0 embedded message
> and is not supported by this mail system". In the case of Winmail Opener
> the text of the mail is reopened out of this "winmail.dat"-file and the
> attachment is shown without a file-ending this time.
> -rebro
This would make me suspicious of the mail. Trash it.
Wolf K.
Ken Whiton
*-* In Article <XcadnU2os8AAF-bQ...@mozilla.org>,
*-* rebro wrote
*-* About TB & "winmail,dat" attachments
> How do I open a "winmail.dat" attachment when exclusively using TB
> as my mail-client?
Try the LookOut extension
(<https://addons.mozilla.org/en-US/thunderbird/addon/lookout/>).
> So far I've tried in vain. Using e. g. an editor I get a full page
> of weird metadata; using a program called *Winmail Reader* at the
> most I come up with the result: This attachment is a MAPI 1.0
> embedded message and is not supported by this mail system.
> Totally confused I'd be grateful for some support.
<http://kb.mozillazine.org/Winmail.dat_attachments> has some
information about winmail.dat attachments, as well as links to the
LookOut extension, two of the programs suggested by Ralph Fox, and
other programs for Windows, Linux, Mac, and iPhone.
Ken Whiton
--
FIDO: 1:132/152
InterNet: kenw...@surfglobal.net.INVAL (remove the obvious to reply)
rebro
> *-* On Sat, 12 Mar 2011, at 16:00:41 +0100,
> *-* In Article<XcadnU2os8AAF-bQ...@mozilla.org>,
> *-* rebro wrote
>
>> How do I open a "winmail.dat" attachment when exclusively using TB
>> as my mail-client?
>
> Try the LookOut extension
> (<https://addons.mozilla.org/en-US/thunderbird/addon/lookout/>).
>
>> So far I've tried in vain. Using e. g. an editor I get a full page
>> of weird metadata; using a program called *Winmail Reader* at the
>> most I come up with the result: This attachment is a MAPI 1.0
>> embedded message and is not supported by this mail system.
>> Totally confused I'd be grateful for some support.
>
> <http://kb.mozillazine.org/Winmail.dat_attachments> has some
> information about winmail.dat attachments, as well as links to the
> LookOut extension, two of the programs suggested by Ralph Fox, and
> other programs for Windows, Linux, Mac, and iPhone.
>
> Ken Whiton
make sure that I had to cope with a TNEF attachment. In the meantime
I've received the message in question in plain text at my request: So
trashing "winmail.dat"-files seems to be the most reasonable solution as
far as I have seen. I say so because the LookOut extension didn't offer
any satisfactory result either: It simply split up the original
winmail.dat-file into a "body_part_0.rtf" (offering the text body of the
mail again) and an "Untitled Attachment" without a file-ending (which
offers the complete set of metadata again when opened in an editor).
-rebro
Gord McFee
rebro
It was useful in telling me how to identify a TNEF attachment. But the
LookOut extension turned out to be as unsatisfactory as the other tools.
-rebro
Mike Easter
> How do I open a "winmail.dat" attachment when exclusively using TB as my
> mail-client?
I think you need to determine if the .dat attachment is actually a TNEF
attachment.
http://kb.mozillazine.org/Winmail.dat_attachments While almost all
attachments named "winmail.dat" are TNEF, you could receive non-TNEF
attachments with names ending ".dat" ... To verify whether or not you've
received a TNEF attachment, highlight the message and click "View" ->
"Message Source". Look for where the attachment begins; ... If you see
"Content-Type: application/ms-tnef" then it's a TNEF attachment. If you
see another "Content-Type", then it's likely something else. ... The
sender can avoid sending TNEF attachments by by turning off TNEF in
Outlook. When Outlook is configured to send e-mail in "Outlook Rich Text
Format", it may use TNEF. When it sends in "HTML" or "Plain Text", it
uses standard, compatible formats. There are two options for disbling TNEF:
--
Mike Easter
Mike Easter
> make sure that I had to cope with a TNEF attachment.
OK
> In the meantime I've received the message in question in plain text
> at my request:
So you know what the body actually contained and how it corresponded
with the .rtf which Lookout gave you.
> So trashing "winmail.dat"-files seems to be the most reasonable
> solution as far as I have seen.
Your handling all winmail.dat files satisfactorily on your end is not a
reasonable target. You should be seeking to get the people who are
errantly sending winmail.dat files to stop doing that. That is not a
proper mailing etiquette.
> I say so because the LookOut extension didn't offer any satisfactory
> result either: It simply split up the original winmail.dat-file into
> a "body_part_0.rtf" (offering the text body of the mail again) and an
> "Untitled Attachment" without a file-ending (which offers the
> complete set of metadata again when opened in an editor).
Presumably the bodypart0.rtf has the 'genuine' content of the email
(Yes?No?).
According to the wikipedia article on TNEF, there can be all kinds of
'inappropriate' material included in there.
http://en.wikipedia.org/wiki/TNEF TNEF attachments can contain
security-sensitive information such as user login name and file
paths,[3][4] from which access controls could possibly be inferred.
If you like, you can peruse some of the Lookout mailing list archives
here http://www.mozdev.org/pipermail/lookout/ The Lookout Archives or
subscribe here https://www.mozdev.org/mailman/listinfo/lookout
<from another post>
> But the LookOut extension turned out to be as unsatisfactory as the
> other tools.
Why do you say that? Wasn't the body.rtf the content of the plaintext
received later?
--
Mike Easter
rebro
"body_part_0.rtf")and simply hinted at the attachment; the attachment
was supposed to transport the proper message. Knowing the message later
on I've seen that it was actually broken down into fragments and somehow
scattered over this "set of metadata", as I called it. So it was
definitely there when I used the LookOut extension.
-rebro
Mike Easter
> Mike Easter:
>>> I say so because the LookOut extension didn't offer any satisfactory
>>> result either: It simply split up the original winmail.dat-file into
>>> a "body_part_0.rtf" (offering the text body of the mail again) and an
>>> "Untitled Attachment" without a file-ending (which offers the
>>> complete set of metadata again when opened in an editor).
I still don't understand what this paragraph is saying, or down below.
>> Presumably the bodypart0.rtf has the 'genuine' content of the email
>> (Yes?No?).
That would have been a good place for you to say Yes or No.
My understanding is that an OL Outlook user may send something as an
.rtf. When they do that, it is likely that it - that content - will be
sent as a TNEF attachment, which is improper sending outside of the
Exchange server's network.
It is also typical for OL and OE Outlook Express mailers to mail both
plaintext and html content (which would be a better choice as it avoids
TNEF) or plaintext and .rtf content (which gets sent as TNEF).
>> Why do you say that? Wasn't the body.rtf the content of the plaintext
>> received later?
> No,
If you say 'No' here right underneath those words, you are saying that
the bodypart0.rtf wasn't the same content as the plaintext. I don't
believe that is what you mean.
> the text-body was readable from the beginning on (= identical with
> "body_part_0.rtf")
Then the answer to the above is Yes instead of No.
> and simply hinted at the attachment;
Hinted? What does that mean?
So (are you saying) your correspondent who sent you a plaintext (only)
version of the mail subsequently sent you some other 'information' (in
addition to the plaintext body) in the second follow up mail? What are
you saying?
That is, are you saying that the (2nd) plaintext mail had an attachment
with some other content than text?
> the attachment
> was supposed to transport the proper message.
What means 'the proper message' in this context? (What does 'the proper
message' mean in your sentence above.)
> Knowing the message later
> on I've seen that it was actually broken down into fragments and somehow
> scattered over this "set of metadata", as I called it.
I don't really want to talk about metadata. I only want to talk about a
rough description of what the correspondent wanted to send you which you
received in the 2nd mail. Plaintext plus something else or plaintext
plus nothing else?
> So it was definitely there when I used the LookOut extension.
I don't know what that sentence means either.
--
Mike Easter
rebro
> rebro wrote:
>> Mike Easter:
>
>>>> I say so because the LookOut extension didn't offer any satisfactory
>>>> result either: It simply split up the original winmail.dat-file into
>>>> a "body_part_0.rtf" (offering the text body of the mail again) and an
>>>> "Untitled Attachment" without a file-ending (which offers the
>>>> complete set of metadata again when opened in an editor).
>
> I still don't understand what this paragraph is saying, or down below.
>
>>> Presumably the bodypart0.rtf has the 'genuine' content of the email
>>> (Yes?No?).
>
> That would have been a good place for you to say Yes or No.
>
> My understanding is that an OL Outlook user may send something as an
> .rtf. When they do that, it is likely that it - that content - will be
> sent as a TNEF attachment, which is improper sending outside of the
> Exchange server's network.
>
> It is also typical for OL and OE Outlook Express mailers to mail both
> plaintext and html content (which would be a better choice as it avoids
> TNEF) or plaintext and .rtf content (which gets sent as TNEF).
>
>>> Why do you say that? Wasn't the body.rtf the content of the plaintext
>>> received later?
body.rtf simply "hinted" (s. below) at this fact.
>
>> No,
>
> If you say 'No' here right underneath those words, you are saying that
> the bodypart0.rtf wasn't the same content as the plaintext. I don't
> believe that is what you mean.
to me and that the essential message (in the attachment) was still
invisible.
>
>> the text-body was readable from the beginning on (= identical with
>> "body_part_0.rtf")
>
> Then the answer to the above is Yes instead of No.
>
> > and simply hinted at the attachment;
>
> Hinted? What does that mean?
>
> So (are you saying) your correspondent who sent you a plaintext (only)
> version of the mail subsequently sent you some other 'information' (in
> addition to the plaintext body) in the second follow up mail? What are
> you saying?
>
> That is, are you saying that the (2nd) plaintext mail had an attachment
> with some other content than text?
without any attachment.
>
>> the attachment was supposed to transport the proper message.
>
> What means 'the proper message' in this context? (What does 'the proper
> message' mean in your sentence above.)
>
>> Knowing the message later on I've seen that it was actually broken
>> down into fragments and somehow scattered over this "set of metadata",
>> as I called it.
>
> I don't really want to talk about metadata. I only want to talk about a
> rough description of what the correspondent wanted to send you which you
> received in the 2nd mail. Plaintext plus something else or plaintext
> plus nothing else?
preconfigurated list.
>
>> So it was definitely there when I used the LookOut extension.
>
> I don't know what that sentence means either.
you could find the information in the pursuit of some hide and seek game
spread in fragments over a page of code (maybe this is a suitable term)
within this "Untitled Attachment" without file-ending that now
accompanied "body_part_0.rtf"
>
I do hope that this is both understandable and helpful.
-rebro
rebro
>> Mike Easter:
>
>>>> I say so because the LookOut extension didn't offer any satisfactory
>>>> result either: It simply split up the original winmail.dat-file into
>>>> a "body_part_0.rtf" (offering the text body of the mail again) and an
>>>> "Untitled Attachment" without a file-ending (which offers the
>>>> complete set of metadata again when opened in an editor).
>
> I still don't understand what this paragraph is saying, or down below.
>
>>> Presumably the bodypart0.rtf has the 'genuine' content of the email
>>> (Yes?No?).
>
>
> My understanding is that an OL Outlook user may send something as an
> .rtf. When they do that, it is likely that it - that content - will be
> sent as a TNEF attachment, which is improper sending outside of the
> Exchange server's network.
>
> It is also typical for OL and OE Outlook Express mailers to mail both
> plaintext and html content (which would be a better choice as it avoids
> TNEF) or plaintext and .rtf content (which gets sent as TNEF).
>
>>> Why do you say that? Wasn't the body.rtf the content of the plaintext
>>> received later?
>
>
> If you say 'No' here right underneath those words, you are saying that
> the bodypart0.rtf wasn't the same content as the plaintext. I don't
> believe that is what you mean.
to me and that the essential message (in the attachment) was still
invisible.
>
>> "body_part_0.rtf")
>
> Then the answer to the above is Yes instead of No.
>
> > and simply hinted at the attachment;
>
> Hinted? What does that mean?
>
> version of the mail subsequently sent you some other 'information' (in
> addition to the plaintext body) in the second follow up mail? What are
> you saying?
>
> That is, are you saying that the (2nd) plaintext mail had an attachment
> with some other content than text?
without any attachment.
>
>
> What means 'the proper message' in this context? (What does 'the proper
> message' mean in your sentence above.)
>
>> down into fragments and somehow scattered over this "set of metadata",
>> as I called it.
>
> I don't really want to talk about metadata. I only want to talk about a
> rough description of what the correspondent wanted to send you which you
> received in the 2nd mail. Plaintext plus something else or plaintext
> plus nothing else?
preconfigurated list.
>
>
> I don't know what that sentence means either.
rebro
your advice as a result of the discussion hitherto.
-rebro