[rt-users] RE: Smart Encoding

[Richard Ellis]

We have been seeing very similar issues, with MTA's in Asia that only support their local encoding. RT does it's best to send them a UTF-8 message back, but thy are unable to read it.

Some smarter way to modify this transmission end of th process would be very helpful

> Message: 8
> Date: Thu, 09 Dec 2004 13:41:35 +0100
> From: Leif Nixon <nixon at nsc.liu.se>
> Subject: [rt-users] Feature request: "Smart" email output encoding
> To: rt-users at lists.bestpractical.com
> Message-ID: <87mzwntzi8.fsf at nsc.liu.se>
> Content-Type: text/plain; charset=us-ascii
> 
> 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
> ------------------------------------------------------------
>