"VanguardLH" schreef in bericht
...
Ah, got it out of the web browser's TIF (temporary internet files)
although with UAC and protected mode in IE the path wasn't so straight
forward. Can see all of the .eml content now.
I see there in no Content-Type for a plain text version of the
newsletter. They probably want to ensure you see all those cutsy
images. The also probably want to ensure you see it formatted
correctly. That lack of a text version of the message is typical with
bulk mail.
I now see all the MIME parts for the embedded or inline images
(Content-Disposition: inline). There are 24 cid references but only 13
MIME parts to reference of which 1 is for the HTML formatted message.
So there are 24 CIDs inside the HTML message but only 12 MIME parts for
those CIDs to reference. Likely there is duplication. So here are the
CIDs in the HTML message, in order of appearance, and the image
(filename) in the corresponding MIME part:
72657d204c517b477133da0bb7738696@RESOURCE ---.--- background-kerst.jpg
72657d204c517b477133da0bb7738696@RESOURCE ---|
72657d204c517b477133da0bb7738696@RESOURCE ---|
72657d204c517b477133da0bb7738696@RESOURCE ---'
f123c3c8de676728340785356023b87e@RESOURCE ------- logo.png
18152c7cc40b9f7398d8eea86e6e896d@RESOURCE ---.--- arrow.jpg
18152c7cc40b9f7398d8eea86e6e896d@RESOURCE ---|
18152c7cc40b9f7398d8eea86e6e896d@RESOURCE ---|
18152c7cc40b9f7398d8eea86e6e896d@RESOURCE ---|
5573342b8a1c546a9a5d8d96284007da@RESOURCE -- | --
bellen_algemeen-newstyle.jpg
18152c7cc40b9f7398d8eea86e6e896d@RESOURCE ---|
32ce697041c6ff4bfe5f140c779a7328@RESOURCE -- | -- fritzdect200.jpg
18152c7cc40b9f7398d8eea86e6e896d@RESOURCE ---|
59ebea15b00cc0e0ace9f8fee8960de2@RESOURCE -- | -- glazenhuis.jpg
18152c7cc40b9f7398d8eea86e6e896d@RESOURCE ---|
57a521298dd0947d75c22f1699b3f5ec@RESOURCE -- | -- column.jpg
18152c7cc40b9f7398d8eea86e6e896d@RESOURCE ---|
18152c7cc40b9f7398d8eea86e6e896d@RESOURCE ---|
18152c7cc40b9f7398d8eea86e6e896d@RESOURCE ---'
40e6b8a444b9f3451391cc573c96c56e@RESOURCE ------- icon-facebook.png
4e7f1a0a0a76ace0b9f5e6d61c0f6165@RESOURCE ------- icon-twitter.png
9a0ea7b769afd462aa925fe251ed2177@RESOURCE ------- icon-blog.png
dd12ceaa05a3f1a90d1356648c15fe48@RESOURCE ------- divider-kerst.gif
8945717fc3d3f0e8cdd792bcf058b222@RESOURCE ------- mini-divider.gif
So 24 CIDs (12 duplications) point at 12 MIME parts. The Content-Type
header specifies MTQxODAzNTg2NTU0ODU4Mjk5NzE1ODA as the ID string and
each MIME part uses that ID so they all match. So it all looks good.
It's possible the MIME parts got corrupted (so they won't display due to
an error in trying to show an invalid file format). So I went to
http://www.motobit.com/util/base64-decoder-encoder.asp and inserted the
base64 string in each MIME part (other than the text/html one for the
message) to make sure the images would open okay and looked okay. I
save them at tinypic.com (some you might have to zoom in to see them,
and make sure not to confuse Tinypics other images with the one that I
uploaded):
background-kerst.jpg -- http://tinypic.com/r/rlhybr/8
logo.png -- http://tinypic.com/r/2zegq3d/8
arrow.jpg -- http://tinypic.com/r/33aweax/8
bellen_algemeen-newstyle.jpg -- http://tinypic.com/r/2cxylw9/8
fritzdect200.jpg -- http://tinypic.com/r/2zywye9/8
glazenhuis.jpg -- http://tinypic.com/r/2vnkjtd/8
column.jpg -- http://tinypic.com/r/15dnno7/8
icon-facebook.png -- http://tinypic.com/r/2ilef10/8
icon-twitter.png -- http://tinypic.com/r/53l1dg/8
icon-blog.png -- http://tinypic.com/r/j6q5wj/8
divider-kerst.gif -- http://tinypic.com/r/2cnv390/8
mini-divider.gif -- http://tinypic.com/r/20iicn9/8
(I'll have to go elsewhere to upload pics since Tinypics has made their
pages so damn "busy" that the noise confuses the visitor as to what they
should be looking at.)
They all look like good images so the MIME parts containing the encoded
strings for the images were okay. The CID references are correct. When
I load the .eml into a web browser, the headers and stuff before the
HTML tag are ignored as well as after the /HTML tag (although the
CID references are still obeyed). All the images display okay (the
mini-divider.gif is very hard to see but is between the "Algemene
voorwaarden" and "Privacyverklaring" text objects at the very bottom of
the page). So the HTML renders okay and the images show okay which
means their references are valid and the MIME parts defining those
images are not corrupted.
For:
https://dl.dropboxusercontent.com/u/...ber%202014.eml
Was this is the e-mail where you could not see some of its [image]
content or did I pick the wrong one? Seems it is all correct. There's
nothing missing or corrupted in the HTML-formatted e-mail.
Yes this is the newer edition of which html does not show up (on the Vista
PC). This goes for all newer editions of this newsletter from a certain
date. The older ones gave no problems on both computers.
I don't remember having problems with other html mail yet...
While web browsers are forgiving of syntax errors (and why IE failed the
ACID tests for so long because it measured how sloppy was a web browser
in permitting common faults), the HTML rendering in an e-mail client may
not be so forgiving. I ran the HTML MIME part's code through a
validator (http://validator.w3.org/check) and it found lots of errors,
like forgetting to close an HTML tag. I suspect all of the "missing end
tag" errors are due to the e-mail using instead of / as the closing
HTML tag. That was because the DOCTYPE tag said to use transitional
style HTML which presumes / to close a tag, not just . Then there are
attributes or their values that are not valid. The web browser will
ignore them but perhaps not the more simpler or basic HTML renderer in
an e-mail client. So while the HTML gets rendered okay in a web
browser, the same may not be true of whatever HTML renderer is used
within the e-mail client. Also, just because an e-mail client may use
the IE libraries to render HTML-formatted e-mails does not mean the
e-mail client's use of those IE libs permits web browser-like rendering.
So if this was the e-mail where you had missing images or problems
rendering it, the problem seems two-fold: the newsletter sender needs to
address their syntax errors but the rendering problem may still be
within your e-mail client of choice.
And don't forget: we're talking about the _same_ e-mail client on both
computers! Only different OS.
AND: I also tested with virus scanner and firewall disabled. And security
settings in WM to display all html.
That's why I have "mystery" in my subject :-(
Thanks for all the effort so far.
--
|\ /|
| \/ |@rk
\../
\/os