Hello.
About a month ago, I have upgraded a RT system from 3.0.9 to 3.6.3. But
after that some people started to complain about broken Japaneses. So
I’ve investigated this issue and what I’ve found so far is,
If we reply the ticket which is created by email which has
"Content-Transfer-Encoding: 7bit" header, it works fine. But if we reply
the ticket which is create by email which doesn’t have
"Content-Transfer-Encoding: 7bit", the requester complains that they get
broken Japanese.
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. But, again, if
the email of requestor to RT system has " Content-Transfer-Encoding:
7bit" header in it, they don’t get broken Japanses when we reply it. And
if the email of requetor to RT system DOESN’t have
"Content-Transfer-Encoding: 7bit" header, they GET BROKEN Japanses.
It looks like 3.6.3 use 8 bit encoding. So can I change the outgoing
encoding options to make it not use 8 bit encoding? I’d like to try with
7 bit encoding. Which file should I modify to try 7 bit encoding for
outgoing email?
Or any other comment, advice, please?
Thanks,
Kihong Lee
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@rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B