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

Re: Character set validation (with patch)



Hi,

* Alain Bench wrote:

   Sorry, I'm busy elsewhere, and can take a look here only way too
rarely. Noticed this thread only now, no time to test the patches.

No problem. As I'm no charset/localization guru, any input at any time is appreciated.

On Tuesday, November 13, 2007 at 13:48:25 +0100, Rocco Rutte wrote:

there're some bugs open where trouble could have been avoided if mutt
did validate character sets

   If I understand correctly, this would prohibit setting $*charset
variables to names that are unknown to iconv and to Mutt's internal
hardcoded list. But there are cases where one rightly wants to set such
unknown charset name.

   One such case was described in bug #1269. The user wanted to send
mails labelled "iso-8859-8-i". This -i name is unknown to iconv and
Mutt, but the "iso-8859-8" variant is known. This user can set:

| set send_charset="...:iso-8859-8-i:..."
| iconv-hook ^iso-8859-8-i$ iso-8859-8

   And today everything works as expected. But with charset validation,
the first line would be rejected.

With the current version of the patch, yes. I used mutt_iconv_open() as fallback which executes iconv-hooks, so maybe this patch should use the same trick in general? That way the example would still work as the -i variant would get mapped to 8859-8 because of the hook.

   OTOS validation would accept $send_charset=MacRoman, because it is
known to iconv. But it is not a IANA approved charset name for MIME
labels. Mutt should probably still accept it (for some specific usages),
but not seem to suggest it's approved in any way.

send_charset=MacRoman should be accepted (as far as this patch is concerned) since it's perfectly legal on macs. Making sure that charset names mutt sends are technically legal and thus (likely) understood by everybody else is a different issue (I think issues exist with //TRANSLIT mutt shouldn't send out).

The only intention of the patch is to stop accepting values the local iconv() implementation certainly does not understand (as long as mutt can correctly decide that).

If you enter something like "set charset=foobar", it can cause strange and undesired behaviour at some places in mutt. The symptoms can totally misguide you in trying to isolate the problem like 'Bad IDN' errors when the input itself is fine but only the charset is wrong.

Sure, entering a wrong charset is user error, but if there's an easy way for mutt to catch it, I think it should do it.

Rocco