Using version 3.8.8 of RT with perl 5.8.8 and Oracle, I tracked down this problem:<br><br>- Reply to an existing ticket using an email agent that will encode emails in UTF8<br>- Put a non ascii character in the subject<br>

- The email gets recorded with crap in the subject rather than the properly encoded subject<br><br>In theory, you shouldn't have pure UTF8 in the subject, but Outlook does it, so does gmail. Don't know about other emails.<br>

<br>This only happens with existing tickets. Here's how.<br><br>When receiving the mail, MIME::Parser doesn't decode the utf8, no matter what. So its all binary utf8 in the header data structure.<br><br>RT adds the "RT-Ticket-ID" field. This string is properly encoded and flagged as utf8.<br>

<br>When saving into the database, RT calls $Attachment->head->as_string, which basically does a join of all the headers.<br><br>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.<br>

<br>So when RT does this:<br><div style="margin-left: 40px;">utf8::decode( $head ) unless utf8::is_utf8( $head );<br></div><br>$head checks as being utf8, even though it's not really, so it doesn't get decoded.<br>

<br>And that goes into the database, which is then used everywhere, and I see this in my tickets:<br><div style="margin-left: 40px;">test d'àcçênts<br></div><br>Now, where should I fix this?<br>- In Attachment_Overlay, force the decoding<br>

- In RT::I18N, SetMIMEHeadToEncoding.<br><br>Thanks<br><br clear="all">--<br>Mathieu Longtin<br>1-514-803-8977<br>