OK, yes you are right I shorthanded OE to O which I shouldn't do.
Indeed. MS Outlook is a completely different program than MS Outlook
Express.
Its interesting that "Outlook" doesn't have this feature because it has helped
me discover that malware can be hidden this way.
I believe that MS Outlook has a different means of looking at the "raw code"
of an email message. Not sure, though, not having a copy to play with.
Thanks Hal for further clarification of how this works, however and perhaps
its my fault, the real question here is about malware. If this "pure text"
encoding represents a jpg in the body of the email, why is it that not all
richtext emails have the "printable characters" at the end of the "message
source" only those that seem to be infected? There does however seem to be
a representative scaling that perhaps those emails that contain malware pure
text are very very long and those that don't are shortened somewhat. This is
something I noticed.
SEMI CONCLUSION: so I should expect any richtext email to have this "pure
text" coding visible when I do a "message source" search of individual emails?
Not necessarily. "Rich text" email should have a "Content Type" header line,
thus:
| Content-Type: multipart/alternative;
| boundary="----=_NextPart_2168_2A20_0F386196.01C9192F"
Within the email should be "NextPart" lines, thus:
| ------=_NextPart_2168_2A20_0F386196.01C9192F
| Content-Type: text/plain; charset=ISO-8859-1
| Content-Transfer-Encoding: 7bit
Unless the body of the message contains binary data, there is no need to
encoded the data. HTML data is not binary.
"Rich text" is used to preserve special encoding characters in Word
documents, and similar. While those will be encoded, they won't,
necessarily, be .jpg file types. I've received encoded attachments of .doc,
and .pps (MS Power Point) file types.
and second, you refer to the jpg coding as "attached" which confuses me
because I consider the act of "attaching" something to an email anethema, and
I don't practice it because its a known malware vector that's why I used the
term "embedded".
The terms "attached", and "embedded" reflect the difference of how the
client displays the data. Embedded images are, generally, displayed inline,
as a background, while attached images have to be loaded in an image display
program. Malware can be embedded as easily as it can be attached.
Actuall, embedding is more likely to be dangerous than attaching.
Attachments are generally only executed by a file handler. Embedded code
will be rendered by the client, unless the client has been configured not to
render content.
I realize this comes with its own "programmers parameters" as "Object Linked
Embedded" type coding for example, I think. So maybe I need a third description
of what happens in richtext emails when the fonts are changable and pictures can
be "inserted" into the body of an email ah ha! "inserted" lol. hmmm.....
Most email clients always send email using MIME. See:
http://en.wikipedia.org/wiki/MIME
third, why is malware in jpgs that are inserted in the body of a richtext
email eluding antivirus scanning on individual PCs? I used AVG/Grisoft, even
sent them a zipped copy using notepad text editor and Winzip and they replied
with various form letters resulting in we can't help you, etc..
I've only seen malware evade AV scanning when it was too new for the
definitions of the scanner. I received a suspicious email with an attachment
which passed the AV scanners. No, I did not invoke a file handler to run it.
I zipped it, per the instructions on the Symantec site, and submitted it to
them for analysis. Within 15 minutes, Symantec responded with a link to a
new set of definitions for the AV scanner, which then detected the attached
file as malware.
While I have heard of malware piggybacking in .jpg images, it seems unlikely
that your AV would fail to find it, unless it was a zero-day virus, as the
one I received.
So for now I am deleting any emails I receive that have very long "pure
text" in them. Until I can find a way to distinguish which "pure text" is
good "pure text"and which is not. So far the only measure is the length,
like I said there are some very long ones. When I copied an example and
pasted it into a *.txt file I could then see how big the file actually was.
So there is some masking in this process with outlook express it would seem;
improper size reporting.
No. Depending in the coding used, image files are expanded beyond their
original file size; as much as 30% larger. A very short .exe file, as in a
virus, would appear to be much smaller than a 1280x1024 .jpg image file. So
you could be keeping viruses, while discarding very safe images, if you are
relying on file length. Since the goal of AV vendors is to get definitions
for new malware pushed out within twelve hours of its appearance, you are
better of holding your attachments in quarantine for two, or three days,
then scanning with the latest definition file.
Best is to discard email from unrecognized sources. If your friends sent you
a picture of the family party, and tell you that is what was in the email
you are asking about, the odds are pretty good that it is nothing more than
a picture of the family party.
In its default configuration, MS Outlook Express will not render remote
images (URLs in HTML mail fetching .gif, .jpg, etc. from remote servers),
nor will it execute attached code:
Tools | Options | Security:
"Block images and other external content in HTML" is checked.
"Do not allow attachments to be saved or opened that could potentially be a
virus" is checked.
Also, MS Outlook Express, by default, uses the Internet Explorer "Restricted
Sites zone".
All of the above can be seen on that same Security tab in the path I
outlined.
From your last article:
I am using OE 6.0 and here is an example of the "gobbledeegook" pure text I
am finding using the properties|details|message source|scroll to bottom
method to view the seemingly hidden viruses in these emails...
And I used a very nifty utility I found, called, "UUDeview 1.3" to decode
that base64 encoded file. It opened in another nifty utility, "Irfanview
4.10", as an animated image (you failed to include the filetype, so
Irfanview complained about the .001 extension I retained from the decoding).
A 36x42x8 BPP image of a rose opening up. Avast did not find an infection.
Being animated, I assume .gif, and renamed the decoded image from
'unknown.001' to 'rose.gif', and now Irfanview just opens it up.
It is well to be suspicious, and I don't wish to discourage that. So I will
reiterate: Don't be trusting of attached files from any unknown, or strange
source; just dump those right away.
And, if you don't trust your friends, quarantine their email attachments for
a couple of days, then scan with the latest AV definitions. If they confirm
that they sent the attached file, and that they have their own, current AV
(ask them which they have), and your AV doesn't find anything malicious,
then it is probably okay to view a .jpg, or .gif, or other image filetype in
an image viewer, or to open a .doc with Wordpad, or, if you have the MS
Works suite, or MS Office suite, in Word.
It is better to keep asking them, and bugging them. If they get tired of it,
who knows? They may stop sending you stuff like that!
