Feature request: "Smart" email output encoding

RT Users
1

Hi,

I’m experimenting with RT 3.2.2 and character encodings.

As I understand it, incoming emails are converted to, and stored in,
UTF-8 encoding. Outgoing email are unconditionally encoded in
$EmailOutputEncoding. Characters that can’t be represented in
$EmailOutputEncoding are replaced with question marks. (This should
never happen if you stay with the default encoding, UTF-8.)

Now, this is in principle just fine. However, UTF-8 is still not
universally supported in (for example) MUAs, so it would be nice to
have the possibility to stay away from UTF-8, if possible.

I’d like to have a setting, say @EmailOutputEncodings, which is a list
of encodings to try. The first encoding that safely encodes the email
should be selected. A reasonable default value might be
qw(us-ascii iso-8859-1 utf-8).

Thoughts?

Leif Nixon Systems expert
National Supercomputer Centre Linkoping University

2

Leif Nixon wrote:

Hi,

I’m experimenting with RT 3.2.2 and character encodings.

As I understand it, incoming emails are converted to, and stored in,
UTF-8 encoding. Outgoing email are unconditionally encoded in
$EmailOutputEncoding. Characters that can’t be represented in
$EmailOutputEncoding are replaced with question marks. (This should
never happen if you stay with the default encoding, UTF-8.)

Now, this is in principle just fine. However, UTF-8 is still not
universally supported in (for example) MUAs, so it would be nice to
have the possibility to stay away from UTF-8, if possible.

I’d like to have a setting, say @EmailOutputEncodings, which is a list
of encodings to try. The first encoding that safely encodes the email
should be selected. A reasonable default value might be
qw(us-ascii iso-8859-1 utf-8).

Thoughts?

Same here with free email providers. Today I sent bug letter to
postmaster of the one :slight_smile:

IMHO such approach has big perfomance penalties.

But I agree this option is required with some additions:

  1. This option should by per queue.

  2. Logic should be fuzzy. If you try ‘xxx’ encoding and less then 1% of
    the characters were not converted then encoding is ok.

     			Best regards. Ruslan.
3

“Ruslan U. Zakirov” Ruslan.Zakirov@acronis.com writes:

Leif Nixon wrote:

I’d like to have a setting, say @EmailOutputEncodings, which is a
list
of encodings to try. The first encoding that safely encodes the email
should be selected. A reasonable default value might be
qw(us-ascii iso-8859-1 utf-8).

Same here with free email providers. Today I sent bug letter to
postmaster of the one :slight_smile:

IMHO such approach has big perfomance penalties.

Do you think so? My hunch is that the time spent trying one or two
additional encodings should be rather small compared to, say, the
scrip firing sequence that led to the mail being sent in the first
place.

But I agree this option is required with some additions:

  1. This option should by per queue.
  2. Logic should be fuzzy. If you try ‘xxx’ encoding and less then 1%
    of the characters were not converted then encoding is ok.

Well, that should certainly be configurable, if implemented. I would
much rather prefer the mail to be encoded in UTF-8 than have any
unreadable characters.

Leif Nixon Systems expert
National Supercomputer Centre Linkoping University