[rt-users] Email output encoding and "RT Essentials"

Leif Nixon nixon at nsc.liu.se
Fri Oct 21 11:22:57 EDT 2005

Leif Nixon <nixon at nsc.liu.se> writes:

> On the other hand, I now discovered that I18N.pm has a *hardcoded*
> fallback from $EmailOutputEncoding to iso-8859-1 to utf-8, so if I
> change $EmailOutputEncoding from its default value utf-8 to us-ascii,
> I should get my dream behaviour already in RT 3.4.4, right?

No, actually I don't understand SetMIMEEntityToEncoding in
I18N.pm at all.

First it does "$charset = _FindOrGuessCharset($entity)" to guess the
current encoding, then it does

Encode::from_to( $lines[$_], $charset => $enc ) for ( 0 .. $#lines );

where $enc is $EmailOutputEncoding. Now, this will not fail even if
the body can't be encoded into $enc, since the optional CHECK argument
to from_to is missing.

However, if the from_to call still manages to fail, the function tries

Encode::from_to( $lines[$_], 'iso-8859-1' => $enc ) for ( 0 .. $#lines );

instead. Perhaps the reasoning here is that _FindOrGuessCharset might
guess incorrectly, and that the encoding might work if we interpret
the body as iso-8859-1 instead?

Anyway, the result of all this is that the mail will be forcibly
encoded into $EmailOutputEncoding, whether it's possible or not.

Leif Nixon                       -            Systems expert
National Supercomputer Centre    -      Linkoping University

More information about the rt-users mailing list