> > Now I hit reply or forward, Compose window appears and the HTML source
> > shows this:
> >
> > test �ťĞť�ĞżýŞ
> >
> > Tested in both Firefox 2.0.0.4 and IE6.
> >
> > Definitely a Squirrelmail problem.
>
> Yes. But having unsupported characters in html form does not violate RFC
> 2046.
> > Nope. It's squirrelmail which is doing that (on replies and forwards).
> > Just try this:
> >
> > 1) send yourself email in UTF-8
> > 2) try to reply/forward this email using Czech language settings
> > (iso-8859-2)
> >
> > At the moment when Compose window comes up, all the quoted text from
>
2007/7/3, Tomas Kuliavas <[EMAIL PROTECTED]>:
> > Since Squirrelmail inserts characters from other charset into a
> > message body declared as being in iso-8859-2, it definitely violates
> > the RFC and causes problems to recipients of such emails.
>
> SquirrelMail does not insert characters from o
Hello.
After yesterday's discussion and some tests it's now clear that
Squirrelmail heavily violates RFC2046 when left in default
configuration ($lossy_encoding = false).
With this default setting, replies/forwards to messages with
non-identical charset are improperly formatted like this (example
> > This problem happens also for Windows-1250 charset, which is almost
> > identical to ISO-8859-2.
>
> If you reply to cp1250 email, only non-identical characters are broken in
> default SquirrelMail configuration.
The problem here is that cp1250 and ISO-8859-2 contain the same characters, but
w
Hello.
I installed Squirrelmail 1.4.10a and selected Czech language. All
incoming mail is displayed fine, but when I try to reply to or forward
mail which is not in ISO-8859-2 codepage, the quoted text is broken.
When the message is in ISO-8859-2, replying/forwarding is OK.
Does it mean squirrelm