Bug 407611 - emails generated by cron have improperly formatted Date: headers
emails generated by cron have improperly formatted Date: headers
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: vixie-cron (Show other bugs)
8
All Linux
low Severity medium
: ---
: ---
Assigned To: Marcela Mašláňová
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-01 21:42 EST by Daryl Tester
Modified: 2007-12-20 15:11 EST (History)
0 users

See Also:
Fixed In Version: 4.2-6.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-12-20 15:11:30 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Daryl Tester 2007-12-01 21:42:33 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.10) Gecko/20061201 Firefox/2.0.0.10 (Ubuntu-feisty)

Description of problem:
First bug post, please be gentle.

Vixie cron has a feature where if any program that produces stdout or stderr (without redirection) is emailed to the user of the crontab (or MAILTO if defined).  I've just freshly installed Core 8, and the cron-generated emails from it are getting appearing with the wrong date in my inbox, but are sent at the correct time.  The box time is set to UTC, and the timezone is Australia/Adelaide.

Examining further, the date header generated by the FC8 cron is

Date: Sun,  2 Dec 2007 00:01:01 1030 (CST)

The same report coming from an FC6 box has:

Date: Sun, 2 Dec 2007 04:02:02 +1030

(Note that the CST string is commented, so that shouldn't be a concern).

It appears that between FC6 (running vixie-cron-4.1-64.fc6) and FC8 the cron program now generates its own Date: header (at least, as identified by strings) instead of relying on the underlying MSA to do it.  According to RFC822, the timezone offset should be prefaced with +/-, so this is probably what's causing the mail reader (Thunderbird 1.5) to improperly decode and display the date.


Version-Release number of selected component (if applicable):
vixie-cron-4.2-5.fc8

How reproducible:
Always


Steps to Reproduce:
1.  Server clock set to UTC, and a definite timezone offset (e.g. Australia/Adelaide)
2.  Add a crontab entry: echo "hi there"
3.  Wait for cronjob to run

Actual Results:
View result in mail reader; note time that email arrived vs time displayed.  Examine email source for "pre-rendered" Date string.

e.g. received email with "Date: Sun,  2 Dec 2007 00:01:01 1030 (CST)", email client shows email received at 16:31



Expected Results:
Email from FC6 cron server with "Date: Sun,  1 Dec 2007 00:00:01 +1030", email client shows email received at 00:00


Additional info:
Nothing special about this configuration.
Comment 1 Daryl Tester 2007-12-01 23:15:48 EST
I grabbed the source rpm to vixie-cron and poked into this further.  It looks
like the MAIL_DATE macro is now defined which causes the use of the
misc.c/arpadate() function.  Looking at the sprintf() format string used in the
function to print the timezone offset it appears that this would work correctly
for negative offsets, but not positive ones (as is the case here).
Comment 2 Marcela Mašláňová 2007-12-03 02:37:47 EST
It will be fixed in the next update vixie-cron-4.2-6.fc8
Comment 3 Fedora Update System 2007-12-06 15:43:24 EST
vixie-cron-4.2-6.fc8 has been pushed to the Fedora 8 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update vixie-cron'
Comment 4 Daryl Tester 2007-12-10 02:30:08 EST
Tested update, appears good.  Thanks!
Comment 5 Fedora Update System 2007-12-20 15:11:29 EST
vixie-cron-4.2-6.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.