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