[Rt-devel] Hi, have a question about outgoing email encoding.

[der Mouse]

> For example,
> This is the part of header of requestor's email who gets broken Japanese.
> content-type: text/plain; charset="utf-8"; format="flowed"
> X-RT-Original-Encoding: iso-2022-jp

> And this is the part of header of requestor's email who gets clear Japanese.
> Content-Type: text/plain; charset="utf-8"
> Content-Transfer-Encoding: 7bit
> X-RT-Original-Encoding: iso-2022-jp

> Whatever the header is, incoming emails to RT are fine.

Perhaps, but nto as quoted above, not if they contain Japanese.  (Well,
unless it's written in roumaji, a quibble which does not appear
relevant here.)  Those two header sets are semantically the same (a
missing Content-Transfer-Encoding: is defined to be equivalent to 7bit;
see RFC 2045 section 6.1), and neither is acceptable if the message
contains any non-ASCII characters, since UTF-8 generates non-7bit octet
sequences for them.  It's possible the mail on the wire was OK, if the
X-RT-Original-Encoding: is actually the Content-Transfer-Encoding: from
the incoming message.  I don't know iso-2022-jp; provided it sticks to
the 7bit restrictions (2045 2.7) it's fine - eg, if that's the encoding
that uses X3.64ish escape sequences.  But recoding it to UTF-8 without
changing the Content-Transfer-Encoding: to match is..broken.

That said, why RT treats them differently when they are defined to be
semantically identical is an interesting question, and arguably a bug
in RT.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse at rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B