[Tickets #10148] Re: Incorrect message charset in replies with reply_headers
bugs at horde.org
bugs at horde.org
Thu Sep 1 19:21:50 UTC 2011
DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.
Ticket URL: http://bugs.horde.org/ticket/10148
------------------------------------------------------------------------------
Ticket | 10148
Updated By | je at ktf.rtu.lv
Summary | Incorrect message charset in replies with reply_headers
Queue | IMP
Version | Git master
Type | Bug
State | Resolved
Priority | 2. Medium
Milestone |
Patch |
Owners | Michael Slusarz
------------------------------------------------------------------------------
je at ktf.rtu.lv (2011-09-01 19:21) wrote:
>> it is clear the only a half of the problem is solved - It is very
>> likely that headers can contain US-ASCII only (and - as the results -
>> relpy in 8859-1) characters only, while the the reply message BODY
>> requires UTF8.
>
> And this is completely expected. And this has already been
> discussed (not sure if it was this thread). Again: for replies, we
> send the message in the charset that the original sender sent (as
> long as the original sender sent in non-ASCII). That is because
> this is the only charset we know for sure the sender can handle.
yes, you are right but just for some part of the problem.
Today the recurrent round of encoding war among Latvian IT specialists
ended which began as usual - one sent UTF8 encoded message on which
reply was made using client which for some damned legacy reasons
analyses the message and decides what encoding to use and due to the
fact that neither Subject no reply body text contained chars with
vowels, the client demoted encoding to ISO8859-1 ("the best one
everyone can read" ). On that message I replayed using chars with
vowels. The result was ordinary unreadable email in iso8859-1 with a
lot of question marks (as horde keeps encodind from original) with
following investigation on "who is ass among us". Therefore I made the
correction in Compose.php to have UTF8 ALLWAYS ON assuming that the
time of UTF8 incapable clients is long time gone and such should not
be honoured.
On the care for mental health of those who do not know what the
encoding means - I suggest one step further - remove prom preferences
any mention of encoding to make no confusion at all.
By the way, even my mom (71) knows what the encoding is; at least -
what effect is has on e-mails. So the problem lies within basic
computer literacy and not the encodings. Even browsers have a lot of
available encodings and users - at least in Baltic countries - know
how to use them to get the problematic page readable.
> Conversely, whether or not I know about charsets is important because
> I, as a user, **must proactively make a decision** using this
> information at compose time. And if I use my non-existent/incorrect
> knowledge, there is a good chance I could break the outgoing e-mail
> since the chosen charset may not support the characters I have
> placed in the body.
IMP4 had such option and i do not remeber protests from horde
deplyoers in horde/imp mailin list about users going insane seeing the
encoding option. Yes, using that control it was possible to break
outgoing email, but without it you do not give the possibility for
the user to make a correction to it if it is desperately necessary.
What solution do you offer for such cases? Start to write a new letter
and copy/paste the text on which one is replying after reception of
the letter having "What that means?!!!" as the main text of the body?
Janis
More information about the bugs
mailing list