From Bugzilla Helper: User-Agent: Mozilla/5.0 Galeon/1.2.0 (X11; Linux i686; U;) Gecko/20020408 Description of problem: Pan looks for the environment variable LC_ALL to determine what charset to use for Content-Type. When it is unset, it seems to fall back on iso885915 which is invalid. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Red Hat Linux 7.3 GNOME-based installation with en_GB (United Kingdom) i18n. In /etc/sysconfig/i18n LANG="en_GB.iso885915" # LANG="en_GB" produces identical results SUPPORTED="en_GB.iso885915:en_GB:en" SYSFONT="lat0-sun16" SYSFONTACM="iso15 Actual Results: Pan posts invalid header: Content-Type: text/plain; charset=iso885915 Expected Results: Pan should post valid header: Content-Type: text/plain; charset=iso-8859-15 Additional info: Easily fixed by placing LC_ALL="ISO-8859-15" ...or similar in /etc/sysconfig/i18n
Xlib seems to like either LANG=en_GB.ISO8859-15 or LANG=en_GB.iso885915. Perhaps you can get away with former? Not the pan side I am not really sure what can be done, but gmime could be made to handle the issue more gracefully? You could try bringing up the issue on one of the pan mailing lists.
gmime seems to assume the form "iso-%d-%d", which gives an Xlib warning. :-\
Btw LC_ALL is not a normal environment variable (see the glibc manual for more details), but a macro: try "printenv LC_ALL". FWIW essentially no current glibc locales (the only exception being one Norwegen locale) have a hyphen in them...
Hmm, with 0.13.2 I seem to get: | Content-Type: text/plain; charset=ISO-8859-1 when sending from "LANG=en_GB.iso885915 pan".
In fact AFAICT it seems to ignore the encoding part of the locale entirely. At least the charset in the Content-Type field seems to be based now only on the xx_YY part apartly. Need to look at the code though to see what's going on.
Things should be better with utf-8 now, I imagine.