* Tamotsu Takahashi [2005-02-19]: > > Full report is here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=295528 > > You said in this report you are using UTF-8 locale. > This is important. I don't know how this affects forwarded messages. > > Summary: the charset declared in the header of the forwarded email are > > changed from an original value of iso-8859-1 to utf-8 without actually > > converting the message body. I don't know why this charset conversion > > is necessary, but it does not seem to occur properly anyway. > > For me, the forwarded message was declared to be euc-jp, > because my $charset was "euc-jp". From the manual, $charset is used to set the character set of your controlling terminal. I don't see how it's relevant for the encoding of forwared messages. > Once I set both $send_charset and $file_charset to "iso-8859-1", > it was forwarded properly, though it was not 8bit but QP. > (Note: $file_charset feature is not in the CVS.) > I set only $send_charset to "iso-8859-1" and failed. > So, $file_charset should help you. Indeed, it helps. But I don't understand why it's needed in the first place. §3 of RFC3156 tells us 8bits chars should be QP- or base64-encoded when sending multipart/signed, but why change the charset too? > > I could reproduce the bug with latest CVS, but now my é letter > > is encoded in quoted-printable by the folowing sequence: "=EF=BF=BD" > > instead of "=E9" previously. > > "=EF=BF=BD" is UTF-8 character to show that it failed to be converted. > (Try "grep '.357.277.275' *.c".) So something went wrong. Thanks for the hint, I'll use that as a starting point for debugging and see what's wrong.
Attachment:
signature.asc
Description: Digital signature