Content Preview should use that Charset too

[ji...@jidanni.org]

Gentlemen, why oh why can't the Charset of the Content Preview of the
Report be set to the same as where the Report got it from? E.g.,

$ grep ^Content message
Content-Type: multipart/mixed; boundary="----------=_4A446828.7FD08E5A"
Content-Type: text/plain; charset=iso-8859-1 <===== Why can't this be big5
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Content preview: ... <======= as here you deposit a few lines of genuine big5
Content analysis details:   (3.1 points, 1.9 required)
Content-Type: message/rfc822; x-spam-type=original
Content-Description: original message before SpamAssassin
Content-Disposition: attachment
Content-Transfer-Encoding: 8bit
Content-Type: multipart/alternative; boundary=0016364c673f034480046d3a4e67
Content-Type: text/plain; charset=Big5 <======= see, you know it is big5
Content-Transfer-Encoding: base64
Content-Type: text/html; charset=Big5 <======= no denying the facts
Content-Transfer-Encoding: quoted-printable

Sure, you will say

"See
        report_charset CHARSET        (default: unset)
           Set the MIME Content-Type charset used for the text/plain
           report which is attached to spam mail messages.

Holmes. Next."

Well, I would just like to point out
1. the above "(default: unset)" is a lie:
   Content-Type: text/plain; charset=iso-8859-1
2. I don't want to hardwire it, I just want SpamAssassin (3.2.5, or
should I upgrade to 3.30 for this?) to use the same Charset from where
it got those Chars. There is no guessing involved for SpamAssassin, as
the headers where it got the chars mention the Charset.

Sure, you will now say

"See

       normalize_charset ( 0 | 1) (default: 0) Whether to detect
           character sets and normalize message content to Unicode.
           Requires the Encode::Detect module, HTML::Parser version 3.46
           or later, and Perl 5.8.5 or later.

Holmes, Next (as in Next patient waiting in line)."

But I don't want to necessarily use UTF-8 or whatever, I just want you
to use the Charset of where you got the preview. The boilerplate
"Spam detection software, running on the system ..." is all ASCII, so
should work fine with most Charsets... or perhaps the Content Preview
should be isolated into its own MIME section.

Re: Content Preview should use that Charset too

[ji...@jidanni.org]

Never mind. I'll just use report_safe 0.

Re: Content Preview should use that Charset too

[ji...@jidanni.org]

And what does
>normalize_charset ( 0 | 1) (default: 0) Whether to detect
>   character sets and normalize message content to Unicode.
Actually do? It sounds like it will convert all your mail to Unicode,
but it seems not to. Or maybe it will just convert the
Content Preview, as I mentioned in my previous message. But it turns out
that gets converted anyway, sometimes, without normalize_charset 1, nor
with Encode::Detect installed!