<<< Date Index >>>     <<< Thread Index >>>

Re: Curiose encoding...



[ I'm taking this mutt-dev. Someone got a mail with ANSI_X3.4-1968 in a RfC2047-encoded word in a mail's subject and mutt fails to detect and hence decode it since it contains MIME-special characters (the dot) though it elsewhere in charset.c has a mapping for it to its MIME name. ]

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!