GNOME Bugzilla – Bug 393336
"Redirect" changes date on message being redirected
Last modified: 2021-05-19 12:12:35 UTC
Please describe the problem: This is a very old bug reported to Red Hat bugzilla years ago. Description from original bug report is: When using the "Redirect" command on the "Message" -> "Forward As" menu, Evolution changes the date on the redirected message to be the current date and time. Steps to reproduce: 1. Choose a messasge 2. Select "Message" -> "Forward As" -> Redirect menu item. 3. Redirect message to yourself, and check headers Actual results: You see that Date: field is changed however Date: field should left unchanged instead Resent-Date: field should be added to the message. Expected results: You should have seen Resent-Date: added to delivered message which has the recent date, and original date of the message left unchanged. Does this happen every time? Yes Other information: Downstream bug report url is: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=110893 RFC states that resent-date should be the one added for new date/time. So here's the rfc link stating that: http://www.faqs.org/rfcs/rfc822.html
Created attachment 79497 [details] [review] This patch fixes mail and composer so that resent-date is added to message This patch adds resent-date to the message, and keep original date header unchanged. It should be better to change camel_mime_message_set_date api to handle redirection but keeping this in evolution seemed better.
Question - In e_msg_composer_hdrs_set_resent_date(), are you sure you want to be overriding message->date and message->date_offset? I'm not familiar with what those fields are used for exactly, it just looks a bit suspicious to me.
Those fields are used for camel's message struct. Just setting header would not be enough for camel to recognise this e-mails date is that date. That's what I know about this fields.
Do we need to make changes to e-msg-composer-hdrs.c at all ? Why cant we add camel_mime_message_set_redirect_date function and call it from mail-ops.c on the else part of the if part that you have added.
I'll check it again. It's been a while so I don't have a clue now. Though if same functionality can be satisfied w/o changing headers, that sounds more compatible.
This bug report is getting old, while the problem is still present in evolution 2.30. Is there any chance to get this fixed?
Still present in 3.4.3, and still biting me.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines and create a new bug report ticket at https://gitlab.gnome.org/GNOME/evolution/-/issues/ Thank you for your understanding and your help.