Unknown encoding in rt-mailgate

RT Users
1

Hello,

Today we discovered, that for a few days one of the messages sent to out
RT is sitting in exim queue and not passing through to RT.
After trying passing it to rt-mailgate by hand we got “Unknown encoding”
error.

After analyzing the headers it became obvious that the fault is on the
side of our client - the encoding specified was an nonexistent one.

Since the encoding was specified, EmailInputEncoding doesn’t apply to
it. What is the proper way of accepting such emails to RT?

Regards,
Robert Wysocki
administrator systemów linuksowych
CONTIUM S.A., http://www.contium.pl

2

Hello,

Today we discovered, that for a few days one of the messages sent to out
RT is sitting in exim queue and not passing through to RT.
After trying passing it to rt-mailgate by hand we got “Unknown encoding”
error.

After analyzing the headers it became obvious that the fault is on the
side of our client - the encoding specified was an nonexistent one.

Since the encoding was specified, EmailInputEncoding doesn’t apply to
it. What is the proper way of accepting such emails to RT?

Was it a mistake in encoding or just unsupported one? Anyway, it
should be reported as a bug report with more details about what was in
headers and what is actual encoding of the mail.

Regards,

Robert Wysocki
administrator systemów linuksowych
CONTIUM S.A., http://www.contium.pl

RT Training Sessions (http://bestpractical.com/services/training.html)

  • Boston March 5 & 6, 2012

Best regards, Ruslan.

3

Dnia 2012-01-31, wto o godzinie 21:43 +0400, Ruslan Zakirov pisze:

Was it a mistake in encoding or just unsupported one? Anyway, it
should be reported as a bug report with more details about what was in
headers and what is actual encoding of the mail.

The actual encoding was iso-8859-2 and the declared one was iso-8852-2.
I think it was i typo.

Regards,
Robert Wysocki
administrator systemów linuksowych
CONTIUM S.A., http://www.contium.pl

4

Dnia 2012-01-31, wto o godzinie 21:43 +0400, Ruslan Zakirov pisze:

Was it a mistake in encoding or just unsupported one? Anyway, it
should be reported as a bug report with more details about what was in
headers and what is actual encoding of the mail.

The actual encoding was iso-8859-2 and the declared one was iso-8852-2.
I think it was i typo.

I think your options come down to:

running sed over your mail queue
temporary hack in RT::I18N::_CanonicalizeCharset
use Encode::Alias in the right place to
define_alias( “newName” => ENCODING)

-kevin

5

Dnia 2012-01-31, wto o godzinie 21:43 +0400, Ruslan Zakirov pisze:

Was it a mistake in encoding or just unsupported one? Anyway, it
should be reported as a bug report with more details about what was in
headers and what is actual encoding of the mail.

The actual encoding was iso-8859-2 and the declared one was iso-8852-2.
I think it was i typo.

I think your options come down to:

running sed over your mail queue
temporary hack in RT::I18N::_CanonicalizeCharset
use Encode::Alias in the right place to
define_alias( “newName” => ENCODING)

It’s a workaround. RT may be improved:

  • send error to owner of RT, I hope we already do this
  • we can check encoding in email with Encode and if encode doesn’t
    know it then we ignore value and guess

So this deserves a bug report and I’m Bccing ticket.

-kevin

RT Training Sessions (http://bestpractical.com/services/training.html)

  • Boston — March 5 & 6, 2012

Best regards, Ruslan.