RT4.0.6 Unknown encoding in received emails

Xavier_Reigner · October 11, 2012, 10:33am

What can I do to correct this error ?

fetchmail: MDA returned nonzero status 75

fetchmail: not flushed

RT server error.

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

said:

Unknown encoding ‘we8iso8859p1’ at /opt/rt4/sbin/…/lib/RT/I18N.pm line

Stack:

[/usr/local/share/perl/5.10.1/Carp.pm:100]

[/usr/local/lib/perl/5.10.1/Encode.pm:189]

[/opt/rt4/sbin/…/lib/RT/I18N.pm:542]

[/opt/rt4/sbin/…/lib/RT/I18N.pm:214]

[/opt/rt4/sbin/…/lib/RT/I18N.pm:210]

[/opt/rt4/sbin/…/lib/RT/EmailParser.pm:282]

[/opt/rt4/sbin/…/lib/RT/Interface/Email.pm:1407]
[/opt/rt4/share/html/REST/1.0/NoAuth/mail-gateway:61]

I already tried to add the Encode::HanExtra, restarted the VM but it seems
not to be enough and that I need to edit the I18N.pm file.
X

Ruslan_Zakirov1 · October 11, 2012, 12:42pm

What can I do to correct this error ?

fetchmail: MDA returned nonzero status 75

fetchmail: not flushed

RT server error.

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

said:

Unknown encoding ‘we8iso8859p1’ at /opt/rt4/sbin/…/lib/RT/I18N.pm line 542.

Stack:

[/usr/local/share/perl/5.10.1/Carp.pm:100]

[/usr/local/lib/perl/5.10.1/Encode.pm:189]

[/opt/rt4/sbin/…/lib/RT/I18N.pm:542]

[/opt/rt4/sbin/…/lib/RT/I18N.pm:214]

[/opt/rt4/sbin/…/lib/RT/I18N.pm:210]

[/opt/rt4/sbin/…/lib/RT/EmailParser.pm:282]

[/opt/rt4/sbin/…/lib/RT/Interface/Email.pm:1407]
[/opt/rt4/share/html/REST/1.0/NoAuth/mail-gateway:61]

I already tried to add the Encode::HanExtra, restarted the VM but it seems
not to be enough and that I need to edit the I18N.pm file.
X

Perl’s Encode doesn’t support this encoding. We have branch that
improves situation with unsupported encodings. Do you want to try a
patch?

Final RT training for 2012 in Atlanta, GA - October 23 & 24
http://bestpractical.com/training

We’re hiring! Careers — Best Practical Solutions

Best regards, Ruslan.

Xavier_Reigner · October 11, 2012, 1:55pm

What can I do to correct this error ?

fetchmail: MDA returned nonzero status 75

fetchmail: not flushed

RT server error.

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

said:

Unknown encoding ‘we8iso8859p1’ at /opt/rt4/sbin/…/lib/RT/I18N.pm line

Stack:

[/usr/local/share/perl/5.10.1/Carp.pm:100]

[/usr/local/lib/perl/5.10.1/Encode.pm:189]

[/opt/rt4/sbin/…/lib/RT/I18N.pm:542]

[/opt/rt4/sbin/…/lib/RT/I18N.pm:214]

[/opt/rt4/sbin/…/lib/RT/I18N.pm:210]

[/opt/rt4/sbin/…/lib/RT/EmailParser.pm:282]

[/opt/rt4/sbin/…/lib/RT/Interface/Email.pm:1407]
[/opt/rt4/share/html/REST/1.0/NoAuth/mail-gateway:61]

I already tried to add the Encode::HanExtra, restarted the VM but it
seems
not to be enough and that I need to edit the I18N.pm file.
X

Perl’s Encode doesn’t support this encoding. We have branch that
improves situation with unsupported encodings. Do you want to try a
patch?

Final RT training for 2012 in Atlanta, GA - October 23 & 24
http://bestpractical.com/training

We’re hiring! Careers — Best Practical Solutions

–
Best regards, Ruslan.

Hi Ruslan,

Yes, I can try a patch.
I didn’t find the branch in the git repository.
What should be changed ?

X

Ruslan_Zakirov1 · October 11, 2012, 3:29pm

What can I do to correct this error ?

fetchmail: MDA returned nonzero status 75

fetchmail: not flushed

RT server error.

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

said:

Unknown encoding ‘we8iso8859p1’ at /opt/rt4/sbin/…/lib/RT/I18N.pm line
542.

Stack:

[/usr/local/share/perl/5.10.1/Carp.pm:100]

[/usr/local/lib/perl/5.10.1/Encode.pm:189]

[/opt/rt4/sbin/…/lib/RT/I18N.pm:542]

[/opt/rt4/sbin/…/lib/RT/I18N.pm:214]

[/opt/rt4/sbin/…/lib/RT/I18N.pm:210]

[/opt/rt4/sbin/…/lib/RT/EmailParser.pm:282]

[/opt/rt4/sbin/…/lib/RT/Interface/Email.pm:1407]
[/opt/rt4/share/html/REST/1.0/NoAuth/mail-gateway:61]

I already tried to add the Encode::HanExtra, restarted the VM but it
seems
not to be enough and that I need to edit the I18N.pm file.
X

Perl’s Encode doesn’t support this encoding. We have branch that
improves situation with unsupported encodings. Do you want to try a
patch?

Final RT training for 2012 in Atlanta, GA - October 23 & 24
http://bestpractical.com/training

We’re hiring! Careers — Best Practical Solutions

–
Best regards, Ruslan.

Hi Ruslan,

Yes, I can try a patch.
I didn’t find the branch in the git repository.
What should be changed ?

https://github.com/bestpractical/rt/tree/4.0/unknown-email-charset

X

Final RT training for 2012 in Atlanta, GA - October 23 & 24
http://bestpractical.com/training

We’re hiring! Careers — Best Practical Solutions

Best regards, Ruslan.

Thomas_Sibley · October 11, 2012, 5:26pm

https://github.com/bestpractical/rt/tree/4.0/unknown-email-charset

A comparison to 4.0-trunk:

https://github.com/bestpractical/rt/compare/4.0-trunk...4.0/unknown-email-charset

Xavier_Reigner · October 12, 2012, 8:52am

Thanks for the links.
The email were accepted and new tickets are created. The content is then
not viewable into the history of the tickets in RT.
The message from RT is “Message body not shown because it is not plain
text.” and the data can be viewed in an external text editor by clicking on
“Download (untitled) application/octet-stream 766b”

Content of the file :
Blablabla,

blablabla.

blablabla.

blablabla.

blablabla,

-----------------------------------------------------------------------------------------
blablabla
-----------------------------------------------------------------------------------------

« Ce message a été envoyé blablabla. »

Result in the log :
Oct 12 10:17:18 support RT: Encoding ‘we8iso8859p1’ is not supported
(/opt/rt4/sbin/…/lib/RT/I18N.pm:217)
Oct 12 10:17:19 support RT: rt-4.0.6-28448-1350029839-119.2780-4-0@test.com
#2780/40443 - Scrip 4 On Create Notify AdminCcs
(/opt/rt4/sbin/…/lib/RT/Action/SendEmail.pm:301)
Oct 12 10:17:19 support RT: rt-4.0.6-28448-1350029839-119.2780-4-0@test.com
No recipients found. Not sending.
(/opt/rt4/sbin/…/lib/RT/Interface/Email.pm:353)
Oct 12 10:17:19 support RT: <
rt-4.0.6-28448-1350029839-221.2780-13-0@test.com> #2780/40443 - Scrip 13 On
Create Notify CCs (/opt/rt4/sbin/…/lib/RT/Action/SendEmail.pm:301)
Oct 12 10:17:19 support RT: <
rt-4.0.6-28448-1350029839-221.2780-13-0@test.com> No recipients found. Not
sending. (/opt/rt4/sbin/…/lib/RT/Interface/Email.pm:353)
Oct 12 10:17:19 support RT: Ticket 2780 created in queue ‘Test’ by
tutu@test.com (/opt/rt4/sbin/…/lib/RT/Ticket.pm:688)

It’s better as the emails are not hanging in the mail box, but it still not
the perfect solution as the content needs more time to be read.
What is missing ?

X

Alex_Vandiver · October 12, 2012, 9:09am

It’s better as the emails are not hanging in the mail box, but it
still not the perfect solution as the content needs more time to be
read.
What is missing ?

“we8iso8859p1” appears to be an Oracle-only way of saying “iso-8859-1”.
I suspect that telling RT that those are equivalent is all that is
necessary. You can do that by adding the following to your
RT_SiteConfig.pm:

require Encode::Alias;
Encode::Alias::define_alias("we8iso8859p1" => "iso-8859-1");

You may also want to look into the software that is generating the mail
in question, and see if it can be altered to provide the standard name
for the character set.

Alex

Xavier_Reigner · October 12, 2012, 9:24am

Alex your guess was correct. The messages are now correctly imported. I
prefer this to the binary file.
Thanks a lot,
XOn 12 October 2012 11:09, Alex Vandiver alexmv@bestpractical.com wrote:

On Fri, 2012-10-12 at 10:52 +0200, Xavier Reigner wrote:

It’s better as the emails are not hanging in the mail box, but it
still not the perfect solution as the content needs more time to be
read.
What is missing ?

“we8iso8859p1” appears to be an Oracle-only way of saying “iso-8859-1”.
I suspect that telling RT that those are equivalent is all that is
necessary. You can do that by adding the following to your
RT_SiteConfig.pm:
require Encode::Alias;
Encode::Alias::define_alias("we8iso8859p1" => "iso-8859-1");
You may also want to look into the software that is generating the mail
in question, and see if it can be altered to provide the standard name
for the character set.

Alex

Final RT training for 2012 in Atlanta, GA - October 23 & 24
http://bestpractical.com/training

We’re hiring! Careers — Best Practical Solutions

Ruslan_Zakirov1 · October 12, 2012, 3:09pm

Alex your guess was correct. The messages are now correctly imported. I
prefer this to the binary file.
Thanks a lot,
X

Software that sends email is incorrect and should use the following
Oracle function to
convert charset name to valid name for emails.

http://docs.oracle.com/cd/E11882_01/appdev.112/e16760/u_i18n.htm#i1001102

Information just in case you control sender.> On 12 October 2012 11:09, Alex Vandiver alexmv@bestpractical.com wrote:

On Fri, 2012-10-12 at 10:52 +0200, Xavier Reigner wrote:

It’s better as the emails are not hanging in the mail box, but it
still not the perfect solution as the content needs more time to be
read.
What is missing ?

“we8iso8859p1” appears to be an Oracle-only way of saying “iso-8859-1”.
I suspect that telling RT that those are equivalent is all that is
necessary. You can do that by adding the following to your
RT_SiteConfig.pm:
require Encode::Alias;
Encode::Alias::define_alias("we8iso8859p1" => "iso-8859-1");
You may also want to look into the software that is generating the mail
in question, and see if it can be altered to provide the standard name
for the character set.

Alex

Final RT training for 2012 in Atlanta, GA - October 23 & 24
http://bestpractical.com/training

We’re hiring! Careers — Best Practical Solutions
Final RT training for 2012 in Atlanta, GA - October 23 & 24
http://bestpractical.com/training

We’re hiring! Careers — Best Practical Solutions

Best regards, Ruslan.