info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Poor HTML handling by Eudora 7.1.0.9
1,662 views
Skip to first unread message
Tom McCreadie
Jun 22, 2013, 7:58:28 AM6/22/13
to
I'm finding that emails received from a particular organization ( who - FWIW -
use Novell Groupwise 7.0.1) are consistently mangled by my Eudora 7.1.0.9 : a
veritable dog's dinner of undecoded < > stuff etc. The email content itself is
not so complex...a few links plus company logo.
The original emails display properly when received by other email clients such
as Forte Agent or Gmail. And if those messages are subsequently forwarded from
Agent or Gmail to Eudora, they then display properly.
I would appreciate any pointers. Is there something I'm overlooking in my Eudora
settings? Or is that Groupwise email sender (or Eudora) not adhering strictly to
HTML standards? Perhaps a clue can be found from inspecting the 'Blah
Blah'message header? Thanks.
Message has been deleted
Tom McCreadie
Jun 22, 2013, 5:18:35 PM6/22/13
to
Dennis Lee Bieber <wlf...@ix.netcom.com> wrote:
>On Sat, 22 Jun 2013 13:58:28 +0200, Tom McCreadie
><mccreadi...@xs4all.nl> declaimed the following:
>
> Too late by that time... Eudora has pre-parsed the raw mail. If it was
>sent with alternate renditions, Eudora has selected one to keep, and
>stripped out the other alternate.
Thanks for the prompt help.
Sorry, my description was rather imprecise so here's more info:
1. On encountering the first instance of the Eudora-botched email, I - out of
curiosity - forwarded that offending email from Eudora (my usual email app) to
myself at: (a) my same address - but then downloaded it via Forte Agent; and (b)
to my Gmail address. Both Agent and Gmail could indeed do nothing to restore the
decode-botching inflicted by Eudora.
2. I then had the organization resend the problem-causing email, plus additional
mails, but was now vigilant to screen them first on my ISP's server, before
committing to a download. The mails displayed OK on my ISP's webmail client;
displayed OK in Gmail (after being forwarded from the server to my Gmail
address); displayed OK in Agent (after downloading with 'leave mail on the
server'}; but gave the same decode issues again when finally downloaded into
Eudora.
3. When the uncorrupted Agent and Gmail arrivals from step '2' were resent to
Eudora, they still displayed OK.
>
> If you've been able to grab them in Agent, looking at a RAW (the
>carrot) message in Agent might reveal more.
I'll try that - but am a bit unsure what I should be looking out for.
> Also, are you configured for "Micro$oft Viewer" or Eudora's native
>viewer?
Microsoft viewer - with "Use separate settings from Internet Explorer" and
"Allow executables in HTML content" both unchecked.
>On Sat, 22 Jun 2013 13:58:28 +0200, Tom McCreadie
><mccreadi...@xs4all.nl> declaimed the following:
>
> Too late by that time... Eudora has pre-parsed the raw mail. If it was
>sent with alternate renditions, Eudora has selected one to keep, and
>stripped out the other alternate.
Thanks for the prompt help.
Sorry, my description was rather imprecise so here's more info:
1. On encountering the first instance of the Eudora-botched email, I - out of
curiosity - forwarded that offending email from Eudora (my usual email app) to
myself at: (a) my same address - but then downloaded it via Forte Agent; and (b)
to my Gmail address. Both Agent and Gmail could indeed do nothing to restore the
decode-botching inflicted by Eudora.
2. I then had the organization resend the problem-causing email, plus additional
mails, but was now vigilant to screen them first on my ISP's server, before
committing to a download. The mails displayed OK on my ISP's webmail client;
displayed OK in Gmail (after being forwarded from the server to my Gmail
address); displayed OK in Agent (after downloading with 'leave mail on the
server'}; but gave the same decode issues again when finally downloaded into
Eudora.
3. When the uncorrupted Agent and Gmail arrivals from step '2' were resent to
Eudora, they still displayed OK.
>
> If you've been able to grab them in Agent, looking at a RAW (the
>carrot) message in Agent might reveal more.
I'll try that - but am a bit unsure what I should be looking out for.
> Also, are you configured for "Micro$oft Viewer" or Eudora's native
>viewer?
Microsoft viewer - with "Use separate settings from Internet Explorer" and
"Allow executables in HTML content" both unchecked.
Message has been deleted
Tom McCreadie
Jun 23, 2013, 3:52:58 PM6/23/13
to
Dennis Lee Bieber wrote: If you've been able to grab them in Agent, looking at a RAW (the >>>carrot) message in Agent might reveal more. >>I'll try that - but am a bit unsure what I should be looking out for. A header that says anything like "multipart/mixed" or >"multipart/alternate" would be a good start. Since Agent might be >displaying one part while Eudora is picking the other. A header stating UTF-8 would be another flag. FWIW, the mail successfully decoded by Agent had, in the raw message: X-Mailer: Groupwise 7.0.1 Content-Type: multipart/alternative; boundary="____JWNEXLUFVRHIHGCNSCZK____" --____JWNEXLUFVRHIHGCNSCZK____ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline; modification-date="Sat, 21 Jun 2013 14:06:45 +0200" -------------------------------------------- The same mail, unsuccessfully decoded by Eudora, had the following in its 'Blah Blah' Eudora header info: X-Mailer: Groupwise 7.0.1 Content-Type: multipart/alternative; boundary="____JWNEXLUFVRHIHGCNSCZK____" Content-Type: text/html; charset=utf-8 Content-Disposition: inline; modification-date="Sat, 21 Jun 2013 14:06:45" +0200" Content-Transfer-Encoding: base64Content-Disposition: inline<HTML <META name=GENERATOR content="MSHTML 8.00.6001.23501" x 1px"> =============== (The last 5 lines are possibly irrelevant...and may well get mangled during the usenet posting) My experience so far of Eudora's non-handling of UTF-8 has mainly been restricted to the irritation of getting some strange characters turning up in the body content of certain mails...and then I could often work round that by using the UTF8-> ISO plugin. But perhaps you were surmising that this current HTML-handling issue may have arisen because Eudora was downright unlucky in that it misinterpreted a UTF8 character that just happened to be part of an HTML code-flag? It's sad to see Eudora - by miles my favourite email client - slowly slip from its top perch....like watching a Hollywood screen goddess age, fade and retreat into reclusion :-)
Tom McCreadie
Jun 23, 2013, 6:37:16 PM6/23/13
to
Dennis Lee Bieber wrote:
>>> If you've been able to grab them in Agent, looking at a RAW (the
>>>carrot) message in Agent might reveal more.
>>
>>I'll try that - but am a bit unsure what I should be looking out for.
>
>>> If you've been able to grab them in Agent, looking at a RAW (the
>>>carrot) message in Agent might reveal more.
>>
>>I'll try that - but am a bit unsure what I should be looking out for.
>
> A header that says anything like "multipart/mixed" or
>"multipart/alternate" would be a good start. Since Agent might be
>displaying one part while Eudora is picking the other.
>
The email that displayed properly in Agent contained the following lines in the
>"multipart/alternate" would be a good start. Since Agent might be
>displaying one part while Eudora is picking the other.
>
Agent raw message:
X-Mailer: Groupwise 7.0.1
Content-Type: multipart/alternative; boundary="____JWNEXLUFVRHIHGCNSCZK____"
--____JWNEXLUFVRHIHGCNSCZK____
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64
Content-Disposition: inline; modification-date="Sat, 21 Jun 2013 14:06:45
+0200"
The same mail, unsuccessfully decoded by Eudora, had the following in its 'Blah
Blah' Eudora header info:
X-Mailer: Groupwise 7.0.1
Content-Type: multipart/alternative; boundary="____JWNEXLUFVRHIHGCNSCZK____"
Content-Type: text/html; charset=utf-8
Content-Disposition: inline; modification-date="Sat, 21 Jun 2013 14:06:45"
+0200"
<META name=GENERATOR content="MSHTML 8.00.6001.23501"(String40)">
(N.B. "(String5)" and "(String40)" were actually strings of resp. 5 and 40 weird
alphanumeric characters that J had to replace, otherwise I couldn't complete
this Usenet posting :-) )
----------------------------------------
> A header stating UTF-8 would be another flag.
to the irritation of getting some weird characters in the body text content of
certain mails...but then I could sometimes work round that by using the UTF8>ISO
plugin.
But are you surmising that the cause of my current html woes may have arisen
because Eudora was unlucky in that a misinterpreted UTF-8 character just
happened to be part of an HTML code-flag?
It's sad to watch Eudora - by miles my favourite client - slipping from its top
perch...rather like watching a famous Hollywood screen beauty, age, fade away
and retreat into reclusion.
Message has been deleted
Tom McCreadie
Jun 24, 2013, 5:11:52 AM6/24/13
to
Dennis Lee Bieber wrote:
>>Content-Transfer-Encoding: base64Content-Disposition: inline<HTML PQ
>
> Something appears to have gotten trashed right there -- the
>Content-Disposition should be a separate line.
>
> And I have NO IDEA why the sender's client is first specifying the data
>is UTF-8 -- an 8-bit encoding... And then encoding UTF-8 as BASE-64 which
>uses four bytes of printable ASCII to store three bytes of binary data.
>understands <G>
I appreciate your patience and persistence in helping and educating me on this
stuff, that's outside my comfort zone.
Firstly, as a distracting annoyancet, neither of my two last posts in this
thread - the one above that you quoted and responded to, plus a repeat posting -
have actually shown up on my pc !?. [That's a unique event for my rock-solid
Agent....maybe something perhaps for the Guinness Book of Records. Possibly it
barfed on all the strange characters. But please don't get further sucked into
to troubleshooting Agent :-) ]
Yes, I rechecked the Eudora header: the 'Content-Disposition' entry was indeed
not displayed on a separate line.
Ach, though a curious mind wanted to know, it's no big deal.. I'll let it rest
here and chalk it up to an unfortunate but rare collision of Eudora with a
clunky MS Office / Novell Groupwise combo :-) Thanks again.
>>Content-Transfer-Encoding: base64Content-Disposition: inline<HTML PQ
>
> Something appears to have gotten trashed right there -- the
>Content-Disposition should be a separate line.
>
> And I have NO IDEA why the sender's client is first specifying the data
>is UTF-8 -- an 8-bit encoding... And then encoding UTF-8 as BASE-64 which
>uses four bytes of printable ASCII to store three bytes of binary data.
>
>><META name=GENERATOR content="MSHTML 8.00.6001.23501"
>
> And "MicroSoft HTML" has always tried using things that only Outlook
>><META name=GENERATOR content="MSHTML 8.00.6001.23501"
>
>understands <G>
I appreciate your patience and persistence in helping and educating me on this
stuff, that's outside my comfort zone.
Firstly, as a distracting annoyancet, neither of my two last posts in this
thread - the one above that you quoted and responded to, plus a repeat posting -
have actually shown up on my pc !?. [That's a unique event for my rock-solid
Agent....maybe something perhaps for the Guinness Book of Records. Possibly it
barfed on all the strange characters. But please don't get further sucked into
to troubleshooting Agent :-) ]
Yes, I rechecked the Eudora header: the 'Content-Disposition' entry was indeed
not displayed on a separate line.
Ach, though a curious mind wanted to know, it's no big deal.. I'll let it rest
here and chalk it up to an unfortunate but rare collision of Eudora with a
clunky MS Office / Novell Groupwise combo :-) Thanks again.
Message has been deleted
John H Meyers
Jun 25, 2013, 5:09:47 AM6/25/13
to
On 6/23/2013 2:52 PM, Tom McCreadie wrote:
> FWIW, the mail successfully decoded by Agent had, in the raw message:
>
> X-Mailer: Groupwise 7.0.1
> Content-Type: multipart/alternative; boundary="____JWNEXLUFVRHIHGCNSCZK____"
>
> --____JWNEXLUFVRHIHGCNSCZK____
> Content-Type: text/plain; charset=utf-8
> Content-Transfer-Encoding: base64
> Content-Disposition: inline; modification-date="Sat, 21 Jun 2013 14:06:45
> +0200"
>
> --------------------------------------------
"Multipart/alternative" means that the next two "MIME parts"
> FWIW, the mail successfully decoded by Agent had, in the raw message:
>
> X-Mailer: Groupwise 7.0.1
> Content-Type: multipart/alternative; boundary="____JWNEXLUFVRHIHGCNSCZK____"
>
> --____JWNEXLUFVRHIHGCNSCZK____
> Content-Type: text/plain; charset=utf-8
> Content-Transfer-Encoding: base64
> Content-Disposition: inline; modification-date="Sat, 21 Jun 2013 14:06:45
> +0200"
>
> --------------------------------------------
will generally be a text-only version of the message,
followed by an independent HTML version of the same message,
much the same as Eudora itself generates when you elect to
"send both plain and styled" in your "styled text" options.
Some email clients (e.g. Thunderbird, especially with certain add-ons)
may let you ether choose which of those to display, or display both
(as does the "Show all body parts" add-on), but it's more common for any
earlier "alternative" part to be automatically superseded by any subsequent
alternative part that the client can display. Thus, Eudora always
_discards_ the text-only version, which comes first, and then keeps and
displays _only the HTML version_ which you have prematurely _cut off_
from the above, making it a bit more difficult for us to analyze.
> The same mail, unsuccessfully decoded by Eudora, had the following
> in its 'Blah Blah' Eudora header info:
> X-Mailer: Groupwise 7.0.1
> Content-Type: multipart/alternative; boundary="____JWNEXLUFVRHIHGCNSCZK____"
>
> Content-Type: text/html; charset=utf-8
> Content-Disposition: inline; modification-date="Sat, 21 Jun 2013 14:06:45"
> +0200"
>
> <META name=GENERATOR content="MSHTML 8.00.6001.23501"
> � PQ �B? �� H � [ OH�PT��S��
>
> x 1px">
When Eudora rips apart an original message, fragments of some of the
individual headers of some MIME parts may or may not remain,
but there is NO significance to whether or not the individual MIME part
headers are even present, or "mangled," or not -- there is no intention
for what remains in Eudora's "In" mailbox to ever be parsed again, so
missing/invalid/illegal states of those headers are par for the course, and mean nothing.
In particular, the terminating "boundary string" is almost always also missing,
hence neither the message nor mailbox remains legitimately formatted.
There is enough present, however, for you to see that the HTML part
was also sent with "base64" encoding -- this is perfectly legitimate,
even common, at the sender's option, but it has something to do
with why the HTML may have become more mangled, in the end,
as does something you have done yourself, without realizing it.
> My experience so far of Eudora's non-handling of UTF-8 has mainly been
> restricted to the irritation of getting some strange characters turning up in
> the body content of certain mails...and then I could often work round that by
> using the UTF8-> ISO plugin.
well known bugs is that it tries to decode "base64" itself
but makes mistakes, and if you set the options within that plugin
("Special" > "Message Plugins Settings") to particular combinations,
this causes UTF8ISO itself to mangle your message,
if it had been sent using base64.
In this case, Eudora is innocent, but gets blamed for the combination
of your sender using base64 encoding, followed by UTF8ISO's indiscretion,
partly due to your own plugin settings,
so what I would suggest is to _disable_ UTF8ISO, by either removing
or at least renaming its file in your "plugins" directory,
e.g. to utf8iso.dlx (rather than .dll)
> But perhaps you were surmising that this current HTML-handling issue may have
> arisen because Eudora was downright unlucky in that it misinterpreted a UTF8
> character that just happened to be part of an HTML code-flag?
which means that the multi-byte strings of 8-bit bytes representing
unicode values greater than 127 remain as individual bytes, thus each
displaying as a multi-byte "nonsense string" (like those you have seen
for "curly quotes and apostrophe") in place of every such encoded character.
> It's sad to see Eudora - by miles my favourite email client - slowly slip from
> its top perch....like watching a Hollywood screen goddess age, fade and retreat
> into reclusion :-)
convincing themselves of falsehoods, much as "Chicken Little" was convinced
that "the sky is falling." The very title of this thread is an example,
since Eudora itself does not suffer from any "poor HTML handling"
when the "use Microsoft's viewer" option is enabled, because in that case,
all HTML rendering is handed off to the Internet Explorer engine,
giving results that are inevitably just as good as in Internet Explorer itself,
except that the original character set setting (e.g. UTF-8) is not passed through
to Internet Explorer. The "viewer" plugin below ameliorates that problem,
by allowing you to adjust the settings of the viewing window,
resulting in some dramatically correct rendering of a message
containing English, Chinese and Hebrew all mixed together, using UTF-8.
I have replaced my own buggy UTF8ISO with the following alternative plugin,
which differs in fundamental ways from how UTF8ISO worked:
o UTF8ISO replaced every _multi-byte_ unicode character with a _single byte_
chosen from ISO-8859-1. This _replaced_ "curly quotes" with plain
ascii quote characters ["] and ['] for example, and replaced most common
Western European "accented characters" with equivalents from ISO-8859-1,
but when it comes to Chinese ideographs, for example, there was nothing
that UTF8ISO could do with them, because you can't squeeze thousands of
different characters into a single byte each!
o The "viewer" plugin below instead copies the message into a separate file,
then displays that file in a window that "covers" Eudora's original window.
The separate "viewer window" has settings for numerous alternative encodings,
including UTF-8. When I viewed a combination of English, Chinese and Hebrew,
all sent using UTF-8 in the same message, this viewer properly displayed
every character of each language at the same time. It turned out that
results of this one test were perfect only when "use Microsoft's viewer"
was selected in Eudora, and had small flaws otherwise, FWIW.
o You must manually invoke the "viewer" plugin on messages which you want to view
using this plugin. This is easier if you add each of the plugin's tool buttons
to Eudora's main toolbar (there is one button for viewing as plain text,
and another button for viewing as HTML).
This "viewer" plugin (now called "Greek Viewer" by its author, Brana Bujenovic,
who just recently participated in a similar thread in this newsgroup),
is available from this web page:
<http://www.drivehq.com/web/brana/plugins.htm>
Are you adventurous enough to replace UTF8ISO by this plugin,
and to learn how to use it, and to withhold hasty judgement
until you have more comprehensive knowledge, practice, and experience?
I hope that this turns out to help you.
--
Tom McCreadie
Jun 26, 2013, 7:14:31 PM6/26/13
to
John H Meyers <jhme...@nomail.invalid> wrote:
<much good info benignly snipped>
thorough post. In response to this input from you (and Dennis Lee Bieber), I can
only echo the sentiments of the old Irish priest: "My dear man, for such kind
deeds, may you - when it comes your time to pass away - have a week in Heaven
before the Devil comes to claim you."
My subject title wasn't intended to be provocative or to give Eudora a bum rap.
In retrospect, though, it may have come over as a Rush to Judgment. Maybe a
neutral title was more appropriate.... "Why do certain HTML mails end up in my
Eudora 7 with strange, corrupted text?"
I checked the settings of my UTF8ISO Plug-in (via Special > Message Plug-ins
Settings > UTF8->ISO V1.60 > Settings"). There were three options:
a) Decode "=C1=A0" Encoding
b) Process HTML Messages
c) Decode MIME64 Encoding.
All three had been checked.
But I'm unsure if those three options were then operating in the background on
all incoming messages, or only kick in after I select text in an already-arrived
mail, then select: Edit > Message Plug-ins > UTF8->ISO ?
That other plug-in you mentioned looks most interesting. I'll certainly check it
out and report any findings relevant to this thread. Again, thanks for going the
extra 1.61 km* for me on this topic. I'm now mildly chastened but significantly
better-informed.
* km-to-miles plug-in required :-}
<much good info benignly snipped>
>
>Are you adventurous enough to replace UTF8ISO by this plugin,
>and to learn how to use it, and to withhold hasty judgement
>until you have more comprehensive knowledge, practice, and experience?
>
>I hope that this turns out to help you.
Thanks for the time and effort you've put in to set me straight with such a
>Are you adventurous enough to replace UTF8ISO by this plugin,
>and to learn how to use it, and to withhold hasty judgement
>until you have more comprehensive knowledge, practice, and experience?
>
>I hope that this turns out to help you.
thorough post. In response to this input from you (and Dennis Lee Bieber), I can
only echo the sentiments of the old Irish priest: "My dear man, for such kind
deeds, may you - when it comes your time to pass away - have a week in Heaven
before the Devil comes to claim you."
My subject title wasn't intended to be provocative or to give Eudora a bum rap.
In retrospect, though, it may have come over as a Rush to Judgment. Maybe a
neutral title was more appropriate.... "Why do certain HTML mails end up in my
Eudora 7 with strange, corrupted text?"
I checked the settings of my UTF8ISO Plug-in (via Special > Message Plug-ins
Settings > UTF8->ISO V1.60 > Settings"). There were three options:
a) Decode "=C1=A0" Encoding
b) Process HTML Messages
c) Decode MIME64 Encoding.
All three had been checked.
But I'm unsure if those three options were then operating in the background on
all incoming messages, or only kick in after I select text in an already-arrived
mail, then select: Edit > Message Plug-ins > UTF8->ISO ?
That other plug-in you mentioned looks most interesting. I'll certainly check it
out and report any findings relevant to this thread. Again, thanks for going the
extra 1.61 km* for me on this topic. I'm now mildly chastened but significantly
better-informed.
* km-to-miles plug-in required :-}
Message has been deleted
John H Meyers
Jun 27, 2013, 8:15:10 AM6/27/13
to
On 6/26/2013 6:14 PM, Tom McCreadie wrote:
> I checked the settings of my UTF8ISO Plug-in (via Special > Message Plug-ins
> Settings > UTF8->ISO V1.60 > Settings"). There were three options:
> a) Decode "=C1=A0" Encoding
> b) Process HTML Messages
> c) Decode MIME64 Encoding.
> All three had been checked.
The combination of b+c is not recommended,
> I checked the settings of my UTF8ISO Plug-in (via Special > Message Plug-ins
> Settings > UTF8->ISO V1.60 > Settings"). There were three options:
> a) Decode "=C1=A0" Encoding
> b) Process HTML Messages
> c) Decode MIME64 Encoding.
> All three had been checked.
as it often results in the most mangled input,
which can not be unmangled after its original scrambling,
which in that case occurs as the message is being downloaded.
> But I'm unsure if those three options were then operating in the background on
> all incoming messages, or only kick in after I select text in an already-arrived
> mail, then select: Edit > Message Plug-ins > UTF8->ISO ?
and again enclosed with the downloaded plugin)
indicates when processing is automatic,
vs. otherwise when you must invoke it manually,
right near the beginning of that page, starting with the words
"To check if a message is UTF-8 encoded..."
and the options are further discussed and explained
in the "Configuration" section of the same page:
<http://www.windharp.de/software/utf8iso.htm>
In general, however, UTF8ISO is based on the invalid premise
that whatever you receive could have been encoded with ISO-8859-1,
which is limited to a fixed set of at most 127 non-ascii characters,
whereas true UTF-8 simultaneously accommodates many thousands
of characters in all the most common languages used in email.
By the way, if what you receive is HTML, then even without
any plugin, Eudora's "send to browser," followed by adjusting
the browser's own character encoding, should generally work by itself.
Extending the same ability to non-HTML mail can be done,
if the default "text viewer" is changed to one
which has the ability to understand varying text encodings,
which should of course include UTF-8.
Brana's "viewer" plugin increases the general convenience
by having tool buttons which can automatically invoke
a browser (probably IE) for you, and overlay its display window
right over Eudora's own window. Unlike Eudora's built-in
"use Microsoft's viewer," however, Brana's viewer
retains a menu, and includes the ability
to adjust the character encoding,
which are both suppressed by Eudora's internal option.
> thanks for going the extra 1.61 km* for me on this topic
although the exercise is mighty bouncy and jarring :)
--
john...@gmail.com
Feb 23, 2016, 8:33:54 PM2/23/16
to
I found that Eudora 7 displays HTML properly if you go to Special / Message Plug-Ins Settings and make sure that under the "UTF8 -> ISO v1.60" setting, "Process HTML Messages" is NOT ticked ... Messages received prior to making that change will already be corrupted; only new messages will be OK after the setting change.
Ajo Wissink
Feb 23, 2016, 11:11:00 PM2/23/16
to
On Tue, 23 Feb 2016 17:33:52 -0800 (PST), john...@gmail.com wrote:
>I found that Eudora 7 displays HTML properly if you go to Special / Message Plug-Ins Settings and make sure that under the "UTF8 -> ISO v1.60" setting, "Process HTML Messages" is NOT ticked ... Messages received prior to making that change will already be corrupted; only new messages will be OK after the setting change.
I cannot find the message you are replying to.
>I found that Eudora 7 displays HTML properly if you go to Special / Message Plug-Ins Settings and make sure that under the "UTF8 -> ISO v1.60" setting, "Process HTML Messages" is NOT ticked ... Messages received prior to making that change will already be corrupted; only new messages will be OK after the setting change.
The old UTF8 plugin works more or less when it works correctly, but
the problem with it is that when it screws up the received message is
garbage that cannot be recovered.
Brana's message viewer is a much better choice. When invoked it opens
a new window with the corrected text, leaving the original message as
is. It is called Greek message viewer but it does a lot more than
Greek. You can find it here:
http://www.drivehq.com/web/brana/plugins.htm
Ajo Wissink
0 new messages