Email output encoding and "RT Essentials"

RT Users
1

Browsing through my copy of the excellent “RT Essentials”, I was
overjoyed to find this sentence at the bottom of page 119:

When sending messages back out, RT looks at a site’s list of
preferred encodings, picks the most apropriate[sic] one, and re-encodes
the message.

This is exactly what I need! I’d really, really like outgoing e-mails
to be encoded in the simplest applicable encoding in the list
(us-ascii, iso-8859-1, utf-8).

However, this doesn’t seem to be implemented as of the RT 3.5.5
snapshot, or am I mistaken?

Leif Nixon - Systems expert
National Supercomputer Centre - Linkoping University

2

Browsing through my copy of the excellent “RT Essentials”, I was
overjoyed to find this sentence at the bottom of page 119:

When sending messages back out, RT looks at a site’s list of
preferred encodings, picks the most apropriate[sic] one, and re-encodes
the message.

This is exactly what I need! I’d really, really like outgoing e-mails
to be encoded in the simplest applicable encoding in the list
(us-ascii, iso-8859-1, utf-8).

However, this doesn’t seem to be implemented as of the RT 3.5.5
snapshot, or am I mistaken?

It should encoding in the first valid option in that list.
What behaviour are you seeing?

Jesse

3

Jesse Vincent jesse@bestpractical.com writes:> On Fri, Oct 21, 2005 at 04:03:41PM +0200, Leif Nixon wrote:

This is exactly what I need! I’d really, really like outgoing e-mails
to be encoded in the simplest applicable encoding in the list
(us-ascii, iso-8859-1, utf-8).

However, this doesn’t seem to be implemented as of the RT 3.5.5
snapshot, or am I mistaken?

It should encoding in the first valid option in that list.
What behaviour are you seeing?

OK, now I have had another look at the code, and it seems I was
confused. Still am, for that matter. 8^)

What I was longing for was to be able to say something like

@EmailOutputEncodings = qw(us-ascii iso-8859-1 utf-8);

in RT_SiteConfig.pm, and that functionality doesn’t seem to be there.

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?

Leif Nixon - Systems expert
National Supercomputer Centre - Linkoping University

4

Leif Nixon nixon@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

5

Leif Nixon wrote:

Leif Nixon nixon@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.

And based on your description, I agree that it’s probably just…wrong.
I’ve opened a ticket. We have three or four issues in that chunk of code
that need looking at. We’ll try to take care of them together, unless
some kind user beats us to it.

Jesse

signature.asc (189 Bytes)

6

Jesse Vincent jesse@bestpractical.com writes:

Leif Nixon wrote:

Leif Nixon nixon@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.

And based on your description, I agree that it’s probably just…wrong.
I’ve opened a ticket. We have three or four issues in that chunk of code
that need looking at. We’ll try to take care of them together, unless
some kind user beats us to it.

I have sent a patch to rt-bugs@fsck.com, that sort of addresses this
issue. (Should I have sent it to rt-devel instead?) Hopefully it can
be of some use.

Leif Nixon - Systems expert
National Supercomputer Centre - Linkoping University