RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1462286 - yum-cron date/time on email
Summary: yum-cron date/time on email
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: yum
Version: 7.3
Hardware: All
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: Packaging Maintenance Team
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks: 1630909
TreeView+ depends on / blocked
 
Reported: 2017-06-16 15:23 UTC by Lloyd Brown
Modified: 2019-09-02 12:09 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-09-02 12:09:25 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
adds the current date/time to the emails generated (720 bytes, patch)
2017-06-16 15:23 UTC, Lloyd Brown
no flags Details | Diff

Description Lloyd Brown 2017-06-16 15:23:54 UTC
Created attachment 1288391 [details]
adds the current date/time to the emails generated

Description of problem:
The email emitter built into yum-cron, does not add a "Date" header.  While some MTAs (eg. Postfix or Exim) can be configured to add the header if it is missing, this is not always done.

With most clients (certainly with Mozilla Thunderbird, which I use), if the Date header is missing, the client will assume and show the date/time when it first saw the email.

Since the body of the email doesn't seem to include any date/time information, if the email client happens to be off or disconnected when the email is sent, it isn't clear when the yum-cron actually did anything.

Version-Release number of selected component (if applicable):
I see this using yum-cron-3.4.3-150.el7.noarch on RHEL 7.3, but I suspect it affects all versions.

How reproducible:

- Using a host with upgrades available (yum downgrade something if needed), make sure that the "emit_via" in /etc/yum/yum-cron.conf includes email, and that the "[email]" section is set up appropriately to send emails to a specific destination, etc.
- Have two separate email clients available to access the email account receiving from the yum-cron.  Leave one of the two email clients running and connected, and the other non-running/disconnected.
- Manually run "yum-cron" and let it update the packages
- Using the currently-up email client, see the email, view the headers, and notice the lack of a "Date" header
- Wait an appreciable amount of time (eg. 2-3 minutes), and launch/connect your second email client.  The message will probably be shown with the date/time when your second email client was launched/connected, which will be a few minutes different than the first email client shows.

If you repeat the process after applying my attached patch, the email notification should have a "Date" header, and both clients will show the same date, despite the delay in the second one seeing the message.

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 2 Lloyd Brown 2017-06-16 15:26:01 UTC
Just realized that I filled out the description poorly.  It's easily reproducible, and those steps should've been listed below in the "Steps to Reproduce".  Hopefully the rest should be clear.

I really should read the instructions better.

Comment 5 Marcel Kolaja 2019-01-03 15:25:10 UTC
Given that messages without a Date header are not compliant with RFC 5322, this is a defect, not an RFE:

https://tools.ietf.org/html/rfc5322#section-3.6

Comment 6 Michal Domonkos 2019-01-03 15:29:51 UTC
Nice find, thanks, Marcel.

Comment 7 Michal Domonkos 2019-09-02 12:09:25 UTC
Since the RHEL 7.7 release is now in Maintenance Support 1 Phase, we are only focusing on high priority customer issues at this time.  That said, I'm closing this BZ as WONTFIX.  If you wish to have this reconsidered, please open a ticket with the RH support.


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