Bug 180145

Bugzilla seems to have encoding problems, too. :-(
I could not send the bugreport with my sample outputs in it. I always received:
500 Internal Server Error from your apache.

2nd attempt:

Actual Results:  e.g. some VACUUM VERBOSE output from psql:


psql:<stdin>:50: INFO:  vacuume ûinformation_schema.sql_featuresë
psql:<stdin>:50: INFO:  ûsql_featuresë: 0 entfernbare, 360 nicht entfernbare
Zeilenversionen in 5 Seiten gefunden
psql:<stdin>:50: INFO:  vacuume ûpg_toast.pg_toast_17070ë
psql:<stdin>:50: INFO:  Index ûpg_toast_17070_indexë enthält 0
Zeilenversionen in 1 Seiten
psql:<stdin>:50: INFO:  ûpg_toast_17070ë: 0 entfernbare, 0 nicht entfernbare
Zeilenversionen in 0 Seiten gefunden
psql:<stdin>:50: INFO:  analysiere ûinformation_schema.sql_featuresë
psql:<stdin>:50: INFO:  "sql_features": 5 Seiten, 360 Zeilen ausgewählt, 360
geschätzte Zeilen insgesamt
psql:<stdin>:50: INFO:  vacuume ûinformation_schema.sql_implementation_infoë
psql:<stdin>:50: INFO:  ûsql_implementation_infoë: 0 entfernbare, 12 nicht
entfernbare Zeilenversionen in 1 Seiten gefunden
psql:<stdin>:50: INFO:  vacuume ûpg_toast.pg_toast_17075ë

2nd attempt:

Expected Results:  should look like
psql:<stdin>:50: INFO:  vacuume »information_schema.sql_features«
psql:<stdin>:50: INFO:  »sql_features«: 0 entfernbare, 360 nicht entfernbare
Zeilenversionen in 5 Seiten gefunden
psql:<stdin>:50: INFO:  vacuume »pg_toast.pg_toast_17070«
psql:<stdin>:50: INFO:  Index »pg_toast_17070_index« enthält 0 Zeilenversionen
in 1 Seiten
psql:<stdin>:50: INFO:  »pg_toast_17070«: 0 entfernbare, 0 nicht entfernbare
Zeilenversionen in 0 Seiten gefunden
psql:<stdin>:50: INFO:  analysiere »information_schema.sql_features«
psql:<stdin>:50: INFO:  "sql_features": 5 Seiten, 360 Zeilen ausgewählt, 360
geschätzte Zeilen insgesamt
psql:<stdin>:50: INFO:  vacuume »information_schema.sql_implementation_info«
psql:<stdin>:50: INFO:  »sql_implementation_info«: 0 entfernbare, 12 nicht
entfernbare Zeilenversionen in 1 Seiten gefunden
psql:<stdin>:50: INFO:  vacuume »pg_toast.pg_toast_17075«

*** Bug 180140 has been marked as a duplicate of this bug. ***

*** Bug 180141 has been marked as a duplicate of this bug. ***

*** Bug 180142 has been marked as a duplicate of this bug. ***

*** Bug 180144 has been marked as a duplicate of this bug. ***

Yes, good point. The next version of vixie-cron for RHEL-4, 4.1-40.EL4, will
set the character encoding for emails properly. 

This bug is now fixed with vixie-cron-4.1-40.EL4, which should be in a future
RHEL-4 update release - meanwhile, it can be downloaded from:
  http://people.redhat.com/~jvdias/vixie-cron/RHEL-4 
Please try out this version and let me know of any issues - thank you !

crond will now by default use the system default locale codeset/charmap 
for the mail 'Content-Type' header 'charset=' parameter
(which is usually 'UTF-8' by default) - so the default content-type header
for cron job output mail would be:
    'Content-Type: text/plain; charset=UTF-8'

It is now also possible to set the Content-Type and Content-Transfer-Encoding
headers explicitly in crontab files, with crontab variables of that name, as
documented in 'man 5 crontab' -  eg. one could run a cron job that produces
base64 encoded video output with a crontab entry something like:
---
CONTENT_TYPE="application/x-mpeg-3"
CONTENT_TRANSFER_ENCODING="base64"
* * * * * video_output_cron_job
---

hello,
I am trying to reproduce this bug; 

WITH LATEST PACKAGE:
there is new line in message-source:
"Content-Type: text/plain; charset=UTF-8"
But subject of message is encoding wrongly (czech signs=? or germans 'SS' = ? etc).
Message-body was correct even with old version or new version

-----
versions:
vixie-cron-4.1-54.el4
sendmail-8.13.1-3.3.el4

# cat /etc/sysconfig/i18n
LANG="de_DE.UTF-8"
SUPPORTED="en_GB.UTF-8:en_GB:en:en_US.UTF-8:en_US:en:de_DE.UTF-8:de_DE:de"
SYSFONT="latarcyrheb-sun16"


I tried thunderbird and mutt.

message source:
 
From root.brq.redhat.com  Wed Jan 23 04:48:01 2008
Date: Wed, 23 Jan 2008 04:48:01 -0500
From: root.brq.redhat.com (Cron Daemon)
To: root.brq.redhat.com
Subject: Cron <root@xen24> /bin/echo �š��žýýáíů  � ä ü
Content-Type: text/plain; charset=UTF-8
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <HOME=/root>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=root>
X-Cron-Env: <USER=root>

ěščřžýýáíů ß ä ü

===============
Subject of message was not fixed.

It's quite hard to reproduce it. I started with creating cron job for vixie-cron-4.1-50 with locales in cs_CZ.UTF-8. 

1/ install old cron
2/ set locales to cs_CZ.UTF-8 (or your favourite language)
3/ create cron job f.e. echo "* * * * * root echo ěščřžýáíé" > /etc/cron.d/job
4/ change locales to cs_CZ.ISO-8859-2
5/ check email with mutt. You can see something like>
Date: Mon, 26 Jan 2009 16:22:01 +0100
From: root.redhat.com (Cron Daemon)
To: root.redhat.com
Subject: Cron <root@ppc04> echo ěščřžýáíé
X-Cron-Env: <CHARSET=ISO-8859-2>
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <HOME=/root>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=root>
X-Cron-Env: <USER=root>

?????????

6/ update to f.e. vixie-cron-4.1-53 and you should see something like
Date: Mon, 26 Jan 2009 16:43:01 +0100
From: root.redhat.com (Cron Daemon)
To: root.redhat.com
Subject: Cron <root@ppc04> echo ÄĹĄÄĹŞýåí
X-Cron-Env: <CHARSET=ISO-8859-2>
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <HOME=/root>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=root>
X-Cron-Env: <USER=root>

ěščřžýáí

I believe this bug should be reproduced when you have one machine with non-utf8 locales and sent the results to other machine with utf8. In my case also depend on my terminal settings. 

The subject of emails is other thing. This problem is also in rawhide because encoding for subject is set elsewhere. I'd like to fix in this bug only the body encoding, which has been tested in other branches.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-0025.html