Bug#726600: otrs2: Internal server error when replying to email ticket

[Patrick Matthäi]

Am 03.11.2013 15:04, schrieb Niko Tyni:
> tag 726600 - moreinfo unreproducible
> reassign 726600 libmime-tools-perl 5.504-1
> thanks
>
> On Fri, Nov 01, 2013 at 08:17:03AM +1100, John Seymour wrote:
>> I have worked out how to reliably trigger the bug.
>>
>> If you enter a Unicode character in the the "system standard
>> signature"  and reply to a ticket that uses that signature the bug
>> will be triggered.
>
> Thanks. It doesn't need a signature in my tests, just replying to a bug
> and copy-pasting non-latin1 chararacter to the text field triggers it.
>
> It can be reduced to this:
>
>    % perl -w -MMIME::Entity -e 'print MIME::Entity->build(Data => "\x{2660}")->body_as_string'
>    Strings with code points over 0xFF may not be mapped into in-memory file handles
>    open body: Invalid argument at /usr/share/perl5/MIME/Entity.pm line 1878.
>
> or just
>
>    % perl -w -MMIME::Body -e 'MIME::Body::InCore->new("\x{2660}")->open("r") or die "open failed: $!"'
>    Strings with code points over 0xFF may not be mapped into in-memory file handles
>    open failed: Invalid argument at -e line 1.
>
> I'm reassigning this against libmime-tools-perl again - if this is an
> intentional limitation there, it should at least be documented better.
> Preferrably, I suppose MIME::Body::InCore should transparently encode
> Unicode data before making an in-memory file out of it. (This needs to
> be discussed upstream, of course.)
>
> In this case, OTRS hits it in Kernel::System::Email::Send() when it gets
> a body containing HTML elements that map onto non-latin characters,
> for instance ♠ . The $Self->{HTMLUtilsObject}->ToAscii() call
> around line 288 of Kernel/System/Email.pm then converts the elements into
> Unicode characters, which are later passed to MIME::Entity->build() as-is.
>
> If necessary, OTRS could work around the problem by encoding the string
> first. It already does for some cases, around line 316 or so:
>
>      # body encode if utf8 and base64 is used
>      if ( $Header{Encoding} =~ /utf(8|-8)/i && $Header{Encoding} =~ /base64/i ) {
>          $Self->{EncodeObject}->EncodeOutput( \$Param{Body} );
>      }
>
> Making this EncodeOutput() call unconditional fixes the crash for me,
> probably at the cost of some double encoding later. (I don't use OTRS
> myself so I didn't really test that any further, but it seems too simple
> minded to be a proper fix.)
>

Much thanks for working this out, I have also sent the information to 
OTRS upstream, so that they also could workaround this problem.


-- 
/*
Mit freundlichem Gruß / With kind regards,
  Patrick Matthäi
  GNU/Linux Debian Developer

   Blog: http://www.linux-dev.org/
E-Mail: pmatthaei at debian.org
         patrick at linux-dev.org
*/