RT Bug?

We recently had a request submitted to our RT system (version 4.0.4 on
a Linux Mint 13 box) that caused a crash. I have narrowed this down to
the fact the e-mail had a header that read “Content-Type: TEXT/PLAIN;
charset=X-UNKNOWN; format=flowed” and this caused RT to crash:

cse-rt ~ # cat emailmessage | /usr/bin/rt-mailgate --debug --queue
general --action correspond --url https://cse-rt.unl.edu/
/usr/bin/rt-mailgate: temp file is ‘/tmp/E0FHMLj0Le/l_8jE5Tohr’
/usr/bin/rt-mailgate: connecting to
https://cse-rt.unl.edu//REST/1.0/NoAuth/mail-gateway
Unknown encoding ‘x-unknown’ at
/usr/share/request-tracker4/lib/RT/I18N.pm line 540

Stack:
[/usr/share/perl/5.14/Carp.pm:79]
[/usr/lib/perl/5.14/Encode.pm:187]
[/usr/share/request-tracker4/lib/RT/I18N.pm:540]
[/usr/share/request-tracker4/lib/RT/I18N.pm:214]
[/usr/share/request-tracker4/lib/RT/I18N.pm:210]
[/usr/share/request-tracker4/lib/RT/EmailParser.pm:282]
[/usr/share/request-tracker4/lib/RT/Interface/Email.pm:1405]
[/usr/share/request-tracker4/html/REST/1.0/NoAuth/mail-gateway:61]

RT server error.

The RT server which handled your email did not behave as expected. It
said:

Unknown encoding ‘x-unknown’ at
/usr/share/request-tracker4/lib/RT/I18N.pm line 540

Stack:
[/usr/share/perl/5.14/Carp.pm:79]
[/usr/lib/perl/5.14/Encode.pm:187]
[/usr/share/request-tracker4/lib/RT/I18N.pm:540]
[/usr/share/request-tracker4/lib/RT/I18N.pm:214]
[/usr/share/request-tracker4/lib/RT/I18N.pm:210]
[/usr/share/request-tracker4/lib/RT/EmailParser.pm:282]
[/usr/share/request-tracker4/lib/RT/Interface/Email.pm:1405]
[/usr/share/request-tracker4/html/REST/1.0/NoAuth/mail-gateway:61]

As far as I’ve been able to determine, any message with the header in
question causes a crash. I have not been able to determine how the
“X-UNKNOWN” header was added, but the original mail client was a recent
version of Alpine.

Hi,

We have a branch that improves sitatuation with unknow encodings. It
will be part of future 4.0.x releases.On Mon, Nov 12, 2012 at 8:16 PM, sac sac@cse.unl.edu wrote:

We recently had a request submitted to our RT system (version 4.0.4 on a
Linux Mint 13 box) that caused a crash. I have narrowed this down to the
fact the e-mail had a header that read “Content-Type: TEXT/PLAIN;
charset=X-UNKNOWN; format=flowed” and this caused RT to crash:

cse-rt ~ # cat emailmessage | /usr/bin/rt-mailgate --debug --queue general
–action correspond --url https://cse-rt.unl.edu/
/usr/bin/rt-mailgate: temp file is ‘/tmp/E0FHMLj0Le/l_8jE5Tohr’
/usr/bin/rt-mailgate: connecting to
https://cse-rt.unl.edu//REST/1.0/NoAuth/mail-gateway
Unknown encoding ‘x-unknown’ at /usr/share/request-tracker4/lib/RT/I18N.pm
line 540

Stack:
[/usr/share/perl/5.14/Carp.pm:79]
[/usr/lib/perl/5.14/Encode.pm:187]
[/usr/share/request-tracker4/lib/RT/I18N.pm:540]
[/usr/share/request-tracker4/lib/RT/I18N.pm:214]
[/usr/share/request-tracker4/lib/RT/I18N.pm:210]
[/usr/share/request-tracker4/lib/RT/EmailParser.pm:282]
[/usr/share/request-tracker4/lib/RT/Interface/Email.pm:1405]
[/usr/share/request-tracker4/html/REST/1.0/NoAuth/mail-gateway:61]

RT server error.

The RT server which handled your email did not behave as expected. It
said:

Unknown encoding ‘x-unknown’ at /usr/share/request-tracker4/lib/RT/I18N.pm
line 540

Stack:
[/usr/share/perl/5.14/Carp.pm:79]
[/usr/lib/perl/5.14/Encode.pm:187]
[/usr/share/request-tracker4/lib/RT/I18N.pm:540]
[/usr/share/request-tracker4/lib/RT/I18N.pm:214]
[/usr/share/request-tracker4/lib/RT/I18N.pm:210]
[/usr/share/request-tracker4/lib/RT/EmailParser.pm:282]
[/usr/share/request-tracker4/lib/RT/Interface/Email.pm:1405]
[/usr/share/request-tracker4/html/REST/1.0/NoAuth/mail-gateway:61]

As far as I’ve been able to determine, any message with the header in
question causes a crash. I have not been able to determine how the
“X-UNKNOWN” header was added, but the original mail client was a recent
version of Alpine.


We’re hiring! http://bestpractical.com/jobs

Best regards, Ruslan.

Hi there,

Chiming in to say that we’re also having this issue on RT version 3.8.15.
This other thread also references the issue:

Should we expect a fix on the 3.8.x branch as well ? It’s a rather
inconvenient bug considering it wasn’t present before our upgrade from
3.8.8.

Thanks,

David Moreau Simard/
IT Specialist/On 12-11-12 11:20 AM, Ruslan Zakirov wrote:

Hi,

We have a branch that improves sitatuation with unknow encodings. It
will be part of future 4.0.x releases.

On Mon, Nov 12, 2012 at 8:16 PM, sac sac@cse.unl.edu wrote:

We recently had a request submitted to our RT system (version 4.0.4 on a
Linux Mint 13 box) that caused a crash. I have narrowed this down to the
fact the e-mail had a header that read “Content-Type: TEXT/PLAIN;
charset=X-UNKNOWN; format=flowed” and this caused RT to crash:

cse-rt ~ # cat emailmessage | /usr/bin/rt-mailgate --debug --queue general
–action correspond --url https://cse-rt.unl.edu/
/usr/bin/rt-mailgate: temp file is ‘/tmp/E0FHMLj0Le/l_8jE5Tohr’
/usr/bin/rt-mailgate: connecting to
https://cse-rt.unl.edu//REST/1.0/NoAuth/mail-gateway
Unknown encoding ‘x-unknown’ at /usr/share/request-tracker4/lib/RT/I18N.pm
line 540

Stack:
[/usr/share/perl/5.14/Carp.pm:79]
[/usr/lib/perl/5.14/Encode.pm:187]
[/usr/share/request-tracker4/lib/RT/I18N.pm:540]
[/usr/share/request-tracker4/lib/RT/I18N.pm:214]
[/usr/share/request-tracker4/lib/RT/I18N.pm:210]
[/usr/share/request-tracker4/lib/RT/EmailParser.pm:282]
[/usr/share/request-tracker4/lib/RT/Interface/Email.pm:1405]
[/usr/share/request-tracker4/html/REST/1.0/NoAuth/mail-gateway:61]

RT server error.

The RT server which handled your email did not behave as expected. It
said:

Unknown encoding ‘x-unknown’ at /usr/share/request-tracker4/lib/RT/I18N.pm
line 540

Stack:
[/usr/share/perl/5.14/Carp.pm:79]
[/usr/lib/perl/5.14/Encode.pm:187]
[/usr/share/request-tracker4/lib/RT/I18N.pm:540]
[/usr/share/request-tracker4/lib/RT/I18N.pm:214]
[/usr/share/request-tracker4/lib/RT/I18N.pm:210]
[/usr/share/request-tracker4/lib/RT/EmailParser.pm:282]
[/usr/share/request-tracker4/lib/RT/Interface/Email.pm:1405]
[/usr/share/request-tracker4/html/REST/1.0/NoAuth/mail-gateway:61]

As far as I’ve been able to determine, any message with the header in
question causes a crash. I have not been able to determine how the
“X-UNKNOWN” header was added, but the original mail client was a recent
version of Alpine.


We’re hiring! http://bestpractical.com/jobs

Chiming in to say that we’re also having this issue on RT version 3.8.15.
This other thread also references the issue:
Carbon60: Cloud Consulting - Services and Solutions

Should we expect a fix on the 3.8.x branch as well ? It’s a rather
inconvenient bug considering it wasn’t present before our upgrade
from 3.8.8.

RT 3.8 is only getting critical and security fixes (see paragraph 3 of
this)

If this is really a regression from 3.8.8 then it’s possible we’ll
make a 3.8.16 release, but you’re the first person to claim a
regression.

-kevin

What kind of information would you need to further confirm the issue on
the 3.8.x branch ?

I’d gladly pass along the information.

Thanks !

David Moreau Simard/
IT Specialist/On 12-11-14 9:49 AM, Kevin Falcone wrote:

On Wed, Nov 14, 2012 at 08:51:06AM -0500, David Moreau Simard wrote:

Chiming in to say that we’re also having this issue on RT version 3.8.15.
This other thread also references the issue:
Carbon60: Cloud Consulting - Services and Solutions

Should we expect a fix on the 3.8.x branch as well ? It’s a rather
inconvenient bug considering it wasn’t present before our upgrade
from 3.8.8.
RT 3.8 is only getting critical and security fixes (see paragraph 3 of
this)

Release Scheduling — Best Practical Solutions

If this is really a regression from 3.8.8 then it’s possible we’ll
make a 3.8.16 release, but you’re the first person to claim a
regression.

-kevin


We’re hiring! http://bestpractical.com/jobs

Hey there,

Just wanted to confirm that it does seem to be a regression.
https://github.com/bestpractical/rt/commits/3.8-trunk/lib/RT/I18N.pm

That eval seems to be necessary to have a “Fallback” encoding if an
e-mail is received with an encoding that doesn’t exist/isn’t recognized.
We’ve tested the eval inside the 3.8.15 I18N.pm and were able to receive
e-mails if they’re a non-standard encoding again.

For the time being, and I know this is not ideal, we’ve reverted only
I18N.pm to our previous version from 3.8.8 and everything works well again.

Feel free to let me know if you have any questions !

David Moreau Simard
/ IT Specialist/On 12-11-14 9:49 AM, Kevin Falcone wrote:

On Wed, Nov 14, 2012 at 08:51:06AM -0500, David Moreau Simard wrote:

Chiming in to say that we’re also having this issue on RT version 3.8.15.
This other thread also references the issue:
Carbon60: Cloud Consulting - Services and Solutions

Should we expect a fix on the 3.8.x branch as well ? It’s a rather
inconvenient bug considering it wasn’t present before our upgrade
from 3.8.8.
RT 3.8 is only getting critical and security fixes (see paragraph 3 of
this)

Release Scheduling — Best Practical Solutions

If this is really a regression from 3.8.8 then it’s possible we’ll
make a 3.8.16 release, but you’re the first person to claim a
regression.

-kevin


We’re hiring! http://bestpractical.com/jobs

Hey there,

Just wanted to confirm that it does seem to be a regression.
https://github.com/bestpractical/rt/commits/3.8-trunk/lib/RT/I18N.pm
removed the eval and the unreachable if ($@) code. · bestpractical/rt@ccafbd2 · GitHub

That eval seems to be necessary to have a “Fallback” encoding if an
e-mail is received with an encoding that doesn’t exist/isn’t recognized.
We’ve tested the eval inside the 3.8.15 I18N.pm and were able to receive
e-mails if they’re a non-standard encoding again.

This behaviour is fixed and improved in 4.0. Upgrading when you can is
your best bet. I don’t believe 3.8 will see more work in this code, as
our energy is going into 4.0 and the next major release series, 4.2.

For the time being, and I know this is not ideal, we’ve reverted only
I18N.pm to our previous version from 3.8.8 and everything works well again.

I understand your motivation, but I’m leery of the compatibility of
this. Please mention how your I18N.pm is special if you’re debugging
encoding issues on the list in the future.