HTML e-mails not rendering

01-22-2008

Is there a MIME expert out there who can help me understand why some e-mail
newsletters I receive are not displaying properly in WLMail?

The newsletter's designers are clearly struggling to get it right, but I
have a feeling that the problem is at their end and not with WLMail. The
message is single-part HTML, and displays perfectly in Yahoo's web
interface. However, all I get in WLMail is garbage as shown in the
screenshot.

The relevant headers are:
....
mime-version: 1.0
from: *****
to: *****
date: 22 Jan 2008 00:55:07 -0500
subject: *****
content-type: text/html; charset=utf-8
content-transfer-encoding: base64
Message-ID: *****
X-OriginalArrivalTime: 22 Jan 2008 05:55:08.0542 (UTC)
FILETIME=[5804F9E0:01C85CBB]
Content-Length: 17958

<HTML>
<HEAD>
...

It looks like WLMail is trying to decode the characters following the
Content-Length header from base64, but because they are not encoded to start
with, the result is garbage. They also tried using QP a few weeks ago, with
bizarre results. Is there any need to encode at all, when the body is pure
HTML? Or
--
Noel

01-22-2008

What is the default encoding Tools, Options, Read, International Settings?
and Tools, Options, Send, International Settings?
--
Ronald Sommer

"Ildhund" <jnllb@xxxxxx> wrote in message
news:eeOWvHOXIHA.1168@xxxxxx

	Quote:
	> Is there a MIME expert out there who can help me understand why some > e-mail > newsletters I receive are not displaying properly in WLMail? > > The newsletter's designers are clearly struggling to get it right, but I > have a feeling that the problem is at their end and not with WLMail. The > message is single-part HTML, and displays perfectly in Yahoo's web > interface. However, all I get in WLMail is garbage as shown in the > screenshot. > > The relevant headers are: > ... > mime-version: 1.0 > from: *** > to: * > date: 22 Jan 2008 00:55:07 -0500 > subject: * > content-type: text/html; charset=utf-8 > content-transfer-encoding: base64 > Message-ID: *** > X-OriginalArrivalTime: 22 Jan 2008 05:55:08.0542 (UTC) > FILETIME=[5804F9E0:01C85CBB] > Content-Length: 17958 > > <HTML> > <HEAD> > ... > > It looks like WLMail is trying to decode the characters following the > Content-Length header from base64, but because they are not encoded to > start > with, the result is garbage. They also tried using QP a few weeks ago, > with > bizarre results. Is there any need to encode at all, when the body is pure > HTML? Or > -- > Noel > >

01-22-2008

Read: Western European (ISO). Use default... is not selected.
Send: Same

There is no significant difference whether I choose UTF-8 or ISO-8859 to
view.
--
Noel

"Ron Sommer" <rsommer@xxxxxx> wrote in message
news:OG7l8EPXIHA.5208@xxxxxx

Quote:

> What is the default encoding Tools, Options, Read, International Settings?
> and Tools, Options, Send, International Settings?
> --
> Ronald Sommer
>
> "Ildhund" <jnllb@xxxxxx> wrote in message
> news:eeOWvHOXIHA.1168@xxxxxx

	Quote:
	>> Is there a MIME expert out there who can help me understand why some >> e-mail >> newsletters I receive are not displaying properly in WLMail? >> >> The newsletter's designers are clearly struggling to get it right, but I >> have a feeling that the problem is at their end and not with WLMail. The >> message is single-part HTML, and displays perfectly in Yahoo's web >> interface. However, all I get in WLMail is garbage as shown in the >> screenshot. >> >> The relevant headers are: >> ... >> mime-version: 1.0 >> from: *** >> to: * >> date: 22 Jan 2008 00:55:07 -0500 >> subject: * >> content-type: text/html; charset=utf-8 >> content-transfer-encoding: base64 >> Message-ID: *** >> X-OriginalArrivalTime: 22 Jan 2008 05:55:08.0542 (UTC) >> FILETIME=[5804F9E0:01C85CBB] >> Content-Length: 17958 >> >> <HTML> >> <HEAD> >> ... >> >> It looks like WLMail is trying to decode the characters following the >> Content-Length header from base64, but because they are not encoded to >> start >> with, the result is garbage. They also tried using QP a few weeks ago, >> with >> bizarre results. Is there any need to encode at all, when the body is >> pure >> HTML? Or >> -- >> Noel >> >>

01-22-2008

"Ildhund" <jnllb@xxxxxx> wrote in message
news:eeOWvHOXIHA.1168@xxxxxx

	Quote:
	> Is there a MIME expert out there who can help me understand why some e-mail > newsletters I receive are not displaying properly in WLMail? > > The newsletter's designers are clearly struggling to get it right, but I > have a feeling that the problem is at their end and not with WLMail. The > message is single-part HTML, and displays perfectly in Yahoo's web > interface. However, all I get in WLMail is garbage as shown in the > screenshot. > > The relevant headers are:

	Quote:
	> content-type: text/html; charset=utf-8 > content-transfer-encoding: base64

	Quote:
	> Content-Length: 17958 > > <HTML> > <HEAD>

If you are really seeing this in the content it isn't base64. It's quoted printable.

I guess WLM could probably do a better job of interpreting incorrectly specified
data; otherwise it could be viewed as a case of GIGO.

To test this idea try saving the E-mail, make only that change and then open it.
Another thing you could do is capture all the (HTML) content
and use it in your own Forward of it which does use BASE64
to see what it should look like when using that encoding method.

Good luck

Robert Aldwinckle
---

01-22-2008

Thanks, Robert. When I opened it as quoted-printable, I got the same bizarre
rendering as when the sender was doing the same. I.e. every time a "="
appears in the HTML, WLMail takes the following two characters and converts
them as if they were QP code. So, a link like "href='http://" shows as
"ttp://" in the status bar, presumably because the " 'h " have been replaced
by whitespace because it does not decode to anything recognizable. I can
copy the HTML to a text file and open it in IE, where it looks just like
it's supposed to.

I've been corresponding with their techies via customer service and I see
that the mailbot they're using has a new version dated last week, so they
are trying. Shouldn't I suggest that they just try
content-transfer-encoding: 7-bit? Could that break anything?
--
Noel

"Robert Aldwinckle" <robald@xxxxxx> wrote in message
news:uOYtfiSXIHA.2268@xxxxxx

Quote:

> "Ildhund" <jnllb@xxxxxx> wrote in message
> news:eeOWvHOXIHA.1168@xxxxxx

	Quote:
	>> Is there a MIME expert out there who can help me understand why some >> e-mail >> newsletters I receive are not displaying properly in WLMail? >> >> The newsletter's designers are clearly struggling to get it right, but I >> have a feeling that the problem is at their end and not with WLMail. The >> message is single-part HTML, and displays perfectly in Yahoo's web >> interface. However, all I get in WLMail is garbage as shown in the >> screenshot. >> >> The relevant headers are:

>

	Quote:
	>> content-type: text/html; charset=utf-8 >> content-transfer-encoding: base64

>

	Quote:
	>> Content-Length: 17958 >> >> <HTML> >> <HEAD>

>
>
> If you are really seeing this in the content it isn't base64. It's
> quoted printable.
>
> I guess WLM could probably do a better job of interpreting incorrectly
> specified
> data; otherwise it could be viewed as a case of GIGO.
>
> To test this idea try saving the E-mail, make only that change and then
> open it.
> Another thing you could do is capture all the (HTML) content
> and use it in your own Forward of it which does use BASE64
> to see what it should look like when using that encoding method.
>
>
> Good luck
>
> Robert Aldwinckle
> ---
>

01-22-2008

"Ildhund" <jnllb@xxxxxx> wrote in message
news:OnbCwGTXIHA.3956@xxxxxx

	Quote:
	> Thanks, Robert. When I opened it as quoted-printable, I got the same bizarre > rendering as when the sender was doing the same. I.e. every time a "=" > appears in the HTML, WLMail takes the following two characters and converts > them as if they were QP code.

Oops. Perhaps you need to convert every instance of a real = into =3D
Do any of the lines end with =20 ? That instance of an = would not be
a "real" = ; )

	Quote:
	> So, a link like "href='http://" shows as > "ttp://" in the status bar, presumably because the " 'h " have been replaced > by whitespace because it does not decode to anything recognizable. I can > copy the HTML to a text file and open it in IE, where it looks just like > it's supposed to.

Another example of GIGO due to brittle design and blind unimaginative
adherence to "standards". ; ]

	Quote:
	> > I've been corresponding with their techies via customer service and I see > that the mailbot they're using has a new version dated last week, so they > are trying. Shouldn't I suggest that they just try > content-transfer-encoding: 7-bit? Could that break anything?

Originally it was UTF-8 so what would GIGO do if there was an 8-bit character
in the datastream? ; }

Did you try my second suggestion instead?
....

Quote:

	Quote:
	>> Another thing you could do is capture all the (HTML) content >> and use it in your own Forward of it which does use BASE64 >> to see what it should look like when using that encoding method.

Actually I just realized that without a Source pane WLMail makes
this suggestion harder than it would be in OE. How do you insert
custom HTML or edit it in WLMail? Perhaps you have to use
Custom Stationery as a workaround? ; }

Good luck

Robert
---

01-23-2008

Robert Aldwinckle wrote...

Quote:

> Ildhund wrote...

	Quote:
	>> Thanks, Robert. When I opened it as quoted-printable, I got the same >> bizarre >> rendering as when the sender was doing the same. I.e. every time a "=" >> appears in the HTML, WLMail takes the following two characters and >> converts >> them as if they were QP code.

	Quote:
	> Oops. Perhaps you

I? *They*

	Quote:
	> need to convert every instance of a real = into =3D > Do any of the lines end with =20 ? That instance of an = would not be > a "real" = ; )

No.

Quote:

	Quote:
	>> So, a link like "href='http://" shows as >> "ttp://" in the status bar, presumably because the " 'h " have been >> replaced >> by whitespace because it does not decode to anything recognizable. I can >> copy the HTML to a text file and open it in IE, where it looks just like >> it's supposed to.

	Quote:
	> Another example of GIGO due to brittle design and blind unimaginative > adherence to "standards". ; ]

You mean on the part of WLMail? I'm a stickler for standards

If this
client were to try and salvage every variety of malformed mail that
misguided senders could dream up, the coders would be at it till kingdom
come. Much better in my view to persuade senders to stick to the rules that
have, after all, been around for many years now and work pretty well.

Quote:

	Quote:
	>> I've been corresponding with their techies via customer service and I see >> that the mailbot they're using has a new version dated last week, so they >> are trying. Shouldn't I suggest that they just try >> content-transfer-encoding: 7-bit? Could that break anything?

	Quote:
	> Originally it was UTF-8 so what would GIGO do if there was an 8-bit > character > in the datastream? ; }

This is en-gb country! We don't do high-ascii (that's why I dropped the ë in
Noël), but even if we did, wouldn't it be much easier for the sender to
convert the odd ë to ë and send nice clean 7-bit?

	Quote:
	> Did you try my second suggestion instead?

I started, but gave up when I realized I was way out of my depth!
--
Noel

01-22-2008	#1 (permalink)
Ildhund Guest n/a posts	HTML e-mails not rendering Is there a MIME expert out there who can help me understand why some e-mail newsletters I receive are not displaying properly in WLMail? The newsletter's designers are clearly struggling to get it right, but I have a feeling that the problem is at their end and not with WLMail. The message is single-part HTML, and displays perfectly in Yahoo's web interface. However, all I get in WLMail is garbage as shown in the screenshot. The relevant headers are: .... mime-version: 1.0 from: *** to: * date: 22 Jan 2008 00:55:07 -0500 subject: * content-type: text/html; charset=utf-8 content-transfer-encoding: base64 Message-ID: *** X-OriginalArrivalTime: 22 Jan 2008 05:55:08.0542 (UTC) FILETIME=[5804F9E0:01C85CBB] Content-Length: 17958 <HTML> <HEAD> ... It looks like WLMail is trying to decode the characters following the Content-Length header from base64, but because they are not encoded to start with, the result is garbage. They also tried using QP a few weeks ago, with bizarre results. Is there any need to encode at all, when the body is pure HTML? Or -- Noel
My System Specs

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
HTML 4.01 Strict Rendering	MCM	.NET General	2	08-22-2008 04:32 AM
working on html objects using HTML DOM, VBscript	Rama	VB Script	3	08-18-2008 08:16 PM
HTML Mails being converted to an attachment	mkp	Vista mail	4	11-23-2007 12:47 PM
JE TOUS MES MAILS DES MAILS EN HEXADECIMAL, PHOTO EN BINAIRE ET BALISE HTML???	eric S.	Vista mail	1	06-27-2007 02:02 PM
Reading HTML Mails with Windows Mail	Conrad	Vista mail	9	04-09-2007 05:15 AM