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?
"Robert Aldwinckle" <robald@xxxxxx> wrote in message
> "Ildhund" <jnllb@xxxxxx> wrote in message
>> Is there a MIME expert out there who can help me understand why some
>> 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
>> The relevant headers are:
>> content-type: text/html; charset=utf-8
>> content-transfer-encoding: base64
>> Content-Length: 17958
> 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
> 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