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

[Lars Reimann]

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.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