mailx should use "Content-Type" header to specify used charset
Bug #124944 reported by
Daniel Hahler
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
mailx (Debian) |
Won't Fix
|
Unknown
|
|||
mailx (Ubuntu) |
Triaged
|
Undecided
|
Unassigned |
Bug Description
Binary package hint: mailx
When sending a mail through mailx, e.g. with "echo äöü | mailx -s test <email address hidden>", the mail misses any charset information and therefor is likely to get displayed wrong when the sending system's charset is different from the user's default.
Note, that this is not bug 27121, which is about header encoding especially.
Changed in mailx: | |
status: | Unknown → New |
Changed in mailx (Debian): | |
status: | Unknown → New |
Changed in mailx (Debian): | |
status: | New → Won't Fix |
To post a comment you must log in.
reassign 282534 mailx
thanks
On Mon, 22 Nov 2004, Javier Kohen wrote:
> Apparently logcheck doesn't set a charset for the mail's contents in the
> mail headers. This causes the mail software to misinterpret certain
> messages. For instance, my system is set to a Spanish UTF-8 locale,
> and gconfd's translated messages use non-ASCII characters; this causes
> funny characters to appear in the mails I receive from logcheck:
>
> Nov 22 12:54:23 localhost gconfd (jkohen-4008): Se recibió la señal
> SIGHUP, recargando todas las bases de datos
>
> If our MUAs work fine, you should see "se<A~><+->al" instead of
> the expected "señal." Where <xy> are composed characters.
>
> Assuming that all system processes and daemons run with the same locale,
> adding the following header to the mails should fix this problem:
> Content-Type: text/plain; charset="<system charset>"
>
> Where the system charset is in the form US-ASCII, UTF-8, ISO-8859-1, etc.
well logcheck is using mail(1), so your wishlist applies to mailx.
i guess this can be merged together with #207724?
> ii mailx 1:8.1.2- 0.20040524cvs- 1 A simple mail user agent
best regards.
--
maks