mailx should use "Content-Type" header to specify used charset

Bug #124944 reported by Daniel Hahler on 2007-07-09
2
Affects Status Importance Assigned to Milestone
mailx (Debian)
Won't Fix
Unknown
mailx (Ubuntu)
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.

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

Yes, it seems you're right about the merge.

Thanks,

maks attems wrote:
> 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
>
>

--
Javier Kohen <email address hidden>
ICQ: blashyrkh #2361802
Jabber: <email address hidden>

merge 282534 207724
thanks

Package: mailx
Version: 1:8.1.2-0.20050715cvs-1
Followup-For: Bug #282534

Should this really be a wishlist item? It may not exactly be a major
bug, but it does cause flawed e-mails to be produced and sent, some of
them probably unreadable by the reciever without manually finding out
and selecting the correct encoding.

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/dash
Kernel: Linux 2.6.12
Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8)

Versions of packages mailx depends on:
ii base-files 3.1.9 Debian base system miscellaneous f
ii exim4 4.60-1 metapackage to ease exim MTA (v4)
ii exim4-daemon-light [mail-tran 4.60-1 lightweight exim MTA (v4) daemon
ii libc6 2.3.5-8 GNU C Library: Shared libraries an
ii liblockfile1 1.06 NFS-safe locking library, includes

mailx recommends no packages.

-- no debconf information

# Automatically generated email from bts, devscripts version 2.9.19
severity 364809 wishlist
merge 364809 207724

Daniel Hahler (blueyed) wrote :

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
Jeff Anderson (jander99) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue for you. Can you try with the latest Ubuntu release? Thanks in advance.

Changed in mailx (Ubuntu):
status: New → Incomplete

# dropping mailx package, reassigning all its bugs to bsd-mailx
package mailx
reassign 68934 bsd-mailx
reassign 85953 bsd-mailx
reassign 148071 bsd-mailx
reassign 162333 bsd-mailx
reassign 181024 bsd-mailx
reassign 197273 bsd-mailx
reassign 197418 bsd-mailx
reassign 198167 bsd-mailx
reassign 207724 bsd-mailx
reassign 224530 bsd-mailx
reassign 286414 bsd-mailx
reassign 324981 bsd-mailx
reassign 327809 bsd-mailx
reassign 349701 bsd-mailx
thanks

reasssign 546284 debbugs
retitle 546284 ignore limits on internal requests in Debbugs::Control
severity 546284 minor
tag 546284 confirmed
limit package bsd-mailx mailx
reassign 68934 mailx
reassign 85953 mailx
reassign 148071 mailx
reassign 162333 mailx
reassign 181024 mailx
reassign 197273 mailx
reassign 197418 mailx
reassign 198167 mailx
reassign 207724 mailx
reassign 224530 mailx
reassign 286414 mailx
reassign 324981 mailx
reassign 327809 mailx
reassign 349701 mailx
reassign 68934 bsd-mailx
reassign 85953 bsd-mailx
reassign 148071 bsd-mailx
reassign 162333 bsd-mailx
reassign 181024 bsd-mailx
reassign 197273 bsd-mailx
reassign 197418 bsd-mailx
reassign 198167 bsd-mailx
reassign 207724 bsd-mailx
reassign 224530 bsd-mailx
reassign 286414 bsd-mailx
reassign 324981 bsd-mailx
reassign 327809 bsd-mailx
reassign 349701 bsd-mailx
thanks

On Fri, 11 Sep 2009, Robert Luberda wrote:
> I was reassigning all the mailx bugs to bsd-mailx, and got a response
> with a bunch of strange complains `Failed to clear fixed versions and
> reopen on XXXXX: limit failed for bugs: XXXXXX'. I have no idea what
> does it mean; it seems all of the reassign commands worked OK.

When doing a reassign, you currently need to also limit to the
packages that you're reassigning to. I'm thinking though, that this
should probably be changed to ignore the limit for internal requests
like the reopen/notfixed. Reassigned and retitled appropriately.

> > # dropping mailx package, reassigning all its bugs to bsd-mailx
> > package mailx

If you had set package mailx bsd-mailx; this would have worked properly.

> Limiting to bugs with field 'package' containing at least one of 'mailx'
> Limit currently set to 'package':'mailx'
>
> > reassign 68934 bsd-mailx
> Bug #68934 [mailx] save command and deletion of messages
> Bug reassigned from package 'mailx' to 'bsd-mailx'.

at this point, 68934 is no longer in the mailx package, but since
it's been reassigned, the fixed versions should be cleared, and the
package should be reopened.

Don Armstrong

--
Cheop's Law: Nothing ever gets built on schedule or within budget.
 -- Robert Heinlein _Time Enough For Love_ p242

http://www.donarmstrong.com http://rzlab.ucr.edu

Daniel Hahler (blueyed) wrote :

Yes, the bug is still there.

Changed in mailx (Debian):
status: New → Unknown
Changed in mailx (Ubuntu):
status: Incomplete → Triaged
Changed in mailx (Debian):
status: Unknown → New
Changed in mailx (Debian):
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.