Hi, * Thomas Roessler [06-06-09 15:12:24 +0200] wrote:
On 2006-06-09 13:05:17 +0000, Rocco Rutte wrote:
Hmm. But what's the point behind having ANSI_X3.4-1968 in our compatbility recognition in charset.c if rfc2047.c will never extract it so that there's no chance of it being looked up?
That table is, among other things, used to map locale charsets to MIME charsets. It's not at all unnecessary.
Okay.
Well, it's not a real bug, just confusing that mutt can't handle it though it already knows what ANSI_X3.4-1968 is and has code to find that out...
What mutt can't handle are malformed RFC 2047 encodings. Some character set identifiers that mutt knows about for locale purposes can't show up in RFC 2047 encoded strings legitimately.
That's all.
I agree that mutt must not send out something like this. However, mutt already has quite a number of features to be more robust against standard-violating input like RfC2047-encoded parameters. And if it's not too expensive, I vote for catching such errors.
So it's a feature request to make mutt use the same alias mapping table for RfC2047-encoded words if it doesn't find a valid MIME character set name as a last chance.
I can implement that if there are chances of getting into CVS and people want it...
bye, Rocco -- :wq!