[rt-users] Email Subject Header creating fragmented strings when decoded

[Kevin Falcone]

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.reimann at 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
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20110328/bcaa81ab/attachment.sig>