On Fri, Mar 18, 2011 at 03:14:17PM +0100, Lars Reimann wrote: > the following problem is very annoying: > RT Encodes Subject lines using the following concept:
Which version of RT > Original example Header > > Subject: > =?UTF-8?B?W3NlcnZpY2UubWV0YXdheXMubmV0ICM2NzAyOF0gU3BlaWNoZXJwbGF0eiBF?= > =?UTF-8?B?cmjDtmh1bmcgd2FzbWFpbjogNTAwIEdC?= > > The header is split into 2 parts: > > 1st part decoded: "[Queue Name #Ticket nubmer] First part of subject line" > 2nd part decoded: "Second part of subject line" > > Completely decoded string: "[Queue Name #Ticket nubmer] First part > of subject line"_"Second part of subject line" > > The underscore (_) marks an additional space character which is > introduced into ALL emails on decoding the two UTF parts. > > > I double checked with decoding UTF in python. Results: When using 2 > UTF parts, a decode introduces an additional space. When using only > ONE UTF-string (the above subject w/o padding and UTF header) the > decode is done correctly! > > If would be very glad the resolve this problem. If RT could use only > one UTF string, the problem would go away. > How can we do that? > And: does anyone have the same problem with email clients (we use > evolution and thunderbird, but most likely other clients are also > affected). > > p.s. It's unclear to me when UTF encoding is used. Sometimes the > Subject line is not UTF encoded and uses ASCII. Perhaps it depends > on non-ASCII characters within the subject. > > greetings, > l.r.
pgpqMrDn2wK4Q.pgp
Description: PGP signature