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