[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


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  

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[]: 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  

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