After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 756842 - [Maildir] Do not overwrite received date on the message info
[Maildir] Do not overwrite received date on the message info
Status: RESOLVED FIXED
Product: evolution-data-server
Classification: Platform
Component: Mailer
3.16.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2015-10-20 07:03 UTC by joakim.tjernlund
Modified: 2015-10-21 09:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
partial patch (625 bytes, patch)
2015-10-20 17:37 UTC, Milan Crha
needs-work Details | Review

Description joakim.tjernlund 2015-10-20 07:03:46 UTC
Copying folders using Copy Folder To does not preserve Received date.
Instead the date is reset to time of copy operation.
This may be tied to EWS backend which is what I am using.
Comment 1 Milan Crha 2015-10-20 07:31:59 UTC
Thanks for a bug report. Let's set Received date from the message ID only if the message itself doesn't contain Received header, otherwise use the value from the header, as the other providers do.

Created commit 0d1cf50 in eds master (3.19.1+)
Created commit f1044d6 in eds gnome-3-18 (3.18.2+)
Comment 2 joakim.tjernlund 2015-10-20 10:44:03 UTC
I backported the bug fix to data-server 3.16.5 and redid the copy: It worked
for about half the mails, the other half had the time of copy operation.
Comment 3 Milan Crha 2015-10-20 11:48:04 UTC
(In reply to joakim.tjernlund from comment #2)
> I backported the bug fix to data-server 3.16.5 and redid the copy: It worked
> for about half the mails, the other half had the time of copy operation.

Right. As I wrote above, it's for cases when the Received header is available. Otherwise (when there is no good guess), the value of the "current time" is used. Check the message source (Ctrl+U) and you might see no Received header in those emails.
Comment 4 joakim.tjernlund 2015-10-20 13:40:19 UTC
(In reply to Milan Crha from comment #3)
> (In reply to joakim.tjernlund from comment #2)
> > I backported the bug fix to data-server 3.16.5 and redid the copy: It worked
> > for about half the mails, the other half had the time of copy operation.
> 
> Right. As I wrote above, it's for cases when the Received header is
> available. Otherwise (when there is no good guess), the value of the
> "current time" is used. Check the message source (Ctrl+U) and you might see
> no Received header in those emails.

It does not make sense, Received is present and OK in the src folder
but is lost after copying. You are correct that the Received: header is
missing, why I do not known, but the src Folders still present Received
which is different from Date: by 1-2 minutes or so.
Comment 5 Milan Crha 2015-10-20 17:37:30 UTC
Created attachment 313768 [details] [review]
partial patch

for evolution-data-server;

This will do it, but only if the caller set the right message info with the filled received date. That worked for me in case of the evolution-ews message (which didn't have the received header, like those messages in the Sent folder), but not for an IMAPx account, thus this needs more work than just in the maildir code, but also in the other providers' code.

Feel free to test this partial fix, I'll return to this shortly (tomorrow or so).
Comment 6 joakim.tjernlund 2015-10-20 17:57:06 UTC
Did a quick test and it worked :)

I understand this is a quick fix but just in case:

1) I think you should prefer Received iff it exists and then fallback to other
   means.

2) I case of Copy operation, always write a real Received: header so one does
   not need to rely on magic code to construct one.
Comment 7 Milan Crha 2015-10-21 05:32:21 UTC
The patch from comment #5 relies on accuracy of the received date value provided by the caller. It also affects the result only in the case where the caller sets the received date.

Both your points are covered by the previous commit (comment #1), but I will extend it to this new part too.
Comment 8 Milan Crha 2015-10-21 06:30:16 UTC
I realized, after further investigation, that in the case of the IMAPx it's correct. It fully relies on the Received header, it doesn't ensure it by creating an artificial value, thus the messages without that header doesn't have the received value filled at all. That means that the patch from comment #5 is basically it, I only slightly extended it.

Created commit 4c74c15 in eds master (3.19.1+)
Created commit c6ecd77 in eds gnome-3-18 (3.18.2+)
Comment 9 joakim.tjernlund 2015-10-21 07:04:33 UTC
(In reply to Milan Crha from comment #8)
> I realized, after further investigation, that in the case of the IMAPx it's
> correct. It fully relies on the Received header, it doesn't ensure it by
> creating an artificial value, thus the messages without that header doesn't
> have the received value filled at all. That means that the patch from
> comment #5 is basically it, I only slightly extended it.
> 
> Created commit 4c74c15 in eds master (3.19.1+)
> Created commit c6ecd77 in eds gnome-3-18 (3.18.2+)

I see, thanks.

I see that you have committed fixes to >= 3.18, does this mean that
3.16.x is not supported anymore?
Comment 10 Milan Crha 2015-10-21 09:57:46 UTC
(In reply to joakim.tjernlund from comment #9)
> I see that you have committed fixes to >= 3.18, does this mean that
> 3.16.x is not supported anymore?

Correct, 3.16 is dead for upstream, due to limited man power. You can always ask your distribution maintainer(s) to backport the changes. Then it's up to them whether they'll do it or not.