[Tickets #14456] Certain emails gets encoded wrong and cannot be replied to
noreply at bugs.horde.org
noreply at bugs.horde.org
Sun Sep 4 13:38:54 UTC 2016
DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.
Ticket URL: https://bugs.horde.org/ticket/14456
------------------------------------------------------------------------------
Ticket | 14456
Created By | alexh at boxed.no
Summary | Certain emails gets encoded wrong and cannot be
| replied to
Queue | Horde Groupware
Version | 5.2.15
Type | Bug
State | Unconfirmed
Priority | 2. Medium
Milestone |
Patch |
Owners |
------------------------------------------------------------------------------
alexh at boxed.no (2016-09-04 13:38) wrote:
I communicate extesively with people in the Nordic countries, and they
have some funny characters [ÅØÖÆåøæö], and Horde seem to get these
wrong in some circumstances, and making email replies that are not
valid.
My setup is I have postfix/dovecot on a server, and two iPhones. One
iPhone accesses the mail as IMAP (via dovecot) and one as ActiveSync
(using Horde on same server).
I have one particular user that seems to be more prone to a problem
that makes horde submit replies with an attempt to encode the
recipient as QP:
Sep 4 02:39:25 popper postfix/smtpd[11134]: NOQUEUE: reject: RCPT
from localhost[127.0.0.1]: 550 5.1.1 <=?utf-8?Q?"Hylen>: Recipient
address rejected: User unknown in local recipient table;
from=<alexh at acme.com> to=<=?utf-8?Q?"Hylen> proto=ESMTP
helo=<mail.foo.com>
The person's email is "Håvar Hyle <Havar.Hyle at acme.no>", and the
iPhone using IMAP/MSA has no prolbem reading, displaying and replying
to this person's messages, the phone using Horde usually displays the
email subjects wrongly coded (it should be e.g. displayed as "Våken?"
but gets displayed as "VÃ¥ken?", which makes it look like the "å"
encoded in some multibyte format somewhere got misrepresented as two
single byte chars.
Viewing the email raw, the subject looks like this:
Subject: =?iso-8859-1?Q?RE:_v=E5ken_=3F?=
Which looks like there is latin1 in there also.
All of this runs alone on a CentOS 7 machine with all default
installation with English language support, and nothing especially
done to pick at PHP or other components for character set changes.
Anyone have any clue what goes wrong?
More information about the bugs
mailing list