Using version 3.8.8 of RT with perl 5.8.8 and Oracle, I tracked down this problem:
- Reply to an existing ticket using an email agent that will encode emails in UTF8 - Put a non ascii character in the subject - The email gets recorded with crap in the subject rather than the properly encoded subject In theory, you shouldn't have pure UTF8 in the subject, but Outlook does it, so does gmail. Don't know about other emails. This only happens with existing tickets. Here's how. When receiving the mail, MIME::Parser doesn't decode the utf8, no matter what. So its all binary utf8 in the header data structure. RT adds the "RT-Ticket-ID" field. This string is properly encoded and flagged as utf8. When saving into the database, RT calls $Attachment->head->as_string, which basically does a join of all the headers. When joining strings in perl5, if any one of them is a flagged UTF8 string, then the resulting string is flagged utf8, even if it contains binary data. Don't know why, that's just what I found out. So when RT does this: utf8::decode( $head ) unless utf8::is_utf8( $head ); $head checks as being utf8, even though it's not really, so it doesn't get decoded. And that goes into the database, which is then used everywhere, and I see this in my tickets: test d'à cçênts Now, where should I fix this? - In Attachment_Overlay, force the decoding - In RT::I18N, SetMIMEHeadToEncoding. Thanks -- Mathieu Longtin 1-514-803-8977
