No, this is simply not possible.

well it might be.

i forgot the headers are all created/stored before the summary is created (which
is really the important bit here).  so the summarising function could just do
it  itself with some awful hack.

and then do similarly for the message opening function, but i'm not sure this
will even be what epople want

I've modified the header_decode_string/header_decode_text functions to
take a default_charset argument.

I also made each function that calls header_decode_string() pass in
the locale charset as the default, although if we can make it pass in
the Content-Type charset, that would probably be better.

But I think the locale is at least a start...even if it's not ideal.

*** bug 206422 has been marked as a duplicate of this bug. ***

Yes, passing the charset from Content-Type as default_charset
would be a solution for 99.999% of cases with chars with 8th bit set
in headers.
So please, please fix this by peeking Content-Type's charset and passing
it as default_charset parameter.

I've changed it thus:

 - it'll try the content-type charset if supplied
 - it'll try the locale charset if supplied
 - it'll give up, and just append anyway

It'll try with any data, so there's cases it will produce the wrong
thing.  e.g. 7 bit ascii that is 7 bit ascii might get converted to
japanese (assuming 7 bit decoding doesn't overlap, which it does afaik
for most 'western' encodings).

The same changes have been propagated to searching/filtering as well.

Should it only try this conversion for 8 bit data?