Re: [rt-users] Email Subject Header creating fragmented strings when decoded
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
Re: [rt-users] Email Subject Header creating fragmented strings when decoded
Sorry, forgot that... :( It is v3.8.8 (clean install) greetings, l.r. On 03/18/2011 03:28 PM, Kevin Falcone wrote: 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. -- Lars Reimann System Engineer Metaways Infosystems GmbH Pickhuben 2, 20457 Hamburg Tel: +49 (0)40 31 70 31 - 527 Fax: +49 (0)40 31 70 31 - 927 l.reim...@metaways.de www.metaways.de Metaways Infosystems GmbH - Sitz: D-22967 Tremsbüttel Handelsregister: Amtsgericht Lübeck, HRB 4508 AH Geschäftsführung: Hermann Thaele, Lüder-H. Thaele
Re: [rt-users] Email Subject Header creating fragmented strings when decoded
On 18 Mar 2011 10:14, Lars Reimann wrote: > Hi all, > > the following problem is very annoying: > > RT Encodes Subject lines using the following concept: > > 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 think this is actually a bug in Encode::MIME::Header's parsing/generation of the encoded header lines. I tracked it down when it broke a test in other code. I believe it was introduced with the fix for https://rt.cpan.org/Public/Bug/Display.html?id=40027. I've copied this mail to the bug tracker for Encode. > 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? If you're really, really annoyed by it, I believe you can downgrade to an older Encode. But you'll regain other bugs that have been fixed as well, and I can't suggest it. > 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. It's used when there are characters other than ascii in a mail header. Thomas
Re: [rt-users] Email Subject Header creating fragmented strings when decoded
Hi all., it seems to me like this problem is becoming more serious, as I recently recognized: - If a ticket queue name has the appropriate length (e.g. [longqueuename.longexampledomain.com #67894] Email Subject ) it happens, that the split occurs right in the middle of the ticket number, thus fragmenting it. This makes the RT unable to assign an fragmented answer to the correct ticket queue. Please consider fixing it and consider the problem serious. References https://rt.cpan.org/Public/Bug/Display.html?id=66713 https://rt.cpan.org/Public/Bug/Display.html?id=40027 greetings, l.r. On 03/18/2011 03:32 PM, Lars Reimann wrote: Sorry, forgot that... :( It is v3.8.8 (clean install) greetings, l.r. On 03/18/2011 03:28 PM, Kevin Falcone wrote: 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. -- Lars Reimann System Engineer Metaways Infosystems GmbH Pickhuben 2, 20457 Hamburg Tel: +49 (0)40 31 70 31 - 527 Fax: +49 (0)40 31 70 31 - 927 l.reim...@metaways.de www.metaways.de Metaways Infosystems GmbH - Sitz: D-22967 Tremsbüttel Handelsregister: Amtsgericht Lübeck, HRB 4508 AH Geschäftsführung: Hermann Thaele, Lüder-H. Thaele
Re: [rt-users] Email Subject Header creating fragmented strings when decoded
On Mon, Mar 28, 2011 at 06:42:27PM +0200, Lars Reimann wrote: > Hi all., > > it seems to me like this problem is becoming more serious, as I > recently recognized: > > - If a ticket queue name has the appropriate length > (e.g. [longqueuename.longexampledomain.com #67894] Email Subject ) > it happens, that the split occurs right in the middle of the ticket > number, thus fragmenting it. This makes the RT unable to assign an > fragmented answer to the correct ticket queue. > > Please consider fixing it and consider the problem serious. As Tom mentioned in the ticket you link and in earlier mail, the problem appears to be in Encode, not in our code, so we're waiting on the bug to be resolved upstream. As Tom also mentioned, you can downgrade Encode, but you may have other bugs. -kevin > References > https://rt.cpan.org/Public/Bug/Display.html?id=66713 > https://rt.cpan.org/Public/Bug/Display.html?id=40027 > > greetings, > l.r. > > On 03/18/2011 03:32 PM, Lars Reimann wrote: > >Sorry, > > > >forgot that... :( > > > >It is v3.8.8 (clean install) > > > >greetings, > >l.r. > > > >On 03/18/2011 03:28 PM, Kevin Falcone wrote: > >>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. > > > > -- > Lars Reimann > System Engineer > > Metaways Infosystems GmbH > Pickhuben 2, 20457 Hamburg > > Tel: +49 (0)40 31 70 31 - 527 > Fax: +49 (0)40 31 70 31 - 927 > > l.reim...@metaways.de > www.metaways.de > > Metaways Infosystems GmbH - Sitz: D-22967 Tremsbüttel > Handelsregister: Amtsgericht Lübeck, HRB 4508 AH > Geschäftsführung: Hermann Thaele, Lüder-H. Thaele > > pgpFVQw4BgXWI.pgp Description: PGP signature
