Bug 422173 - Handling missing 'date' in email headers
Summary: Handling missing 'date' in email headers
Status: REPORTED
Alias: None
Product: kmail2
Classification: Applications
Component: general (show other bugs)
Version: 5.14.1
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-05-28 12:24 UTC by Allan Sandfeld
Modified: 2023-09-13 13:37 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Allan Sandfeld 2020-05-28 12:24:50 UTC
I have one particular type of email that always get send without a date header, and always ends up being misordered by kmail.

It would be nice if kmail would fall back to a received date when an explicit date is missing or invalid (in the future).

I tried fixing it with filtering, but 
a) I couldn't match on missing headers, or match date: on being empty
b) Couldn't set the date to the current time, and only to hardcoded times.
Comment 1 Laurent Montel 2020-05-29 04:52:27 UTC
Hello,
You're idea is to use "received date" in messagelib for sorting message or replacing in message directly unknown date by "received date" ?
Regards
Comment 2 Allan Sandfeld 2020-05-29 08:52:40 UTC
I think the safest would be to used that latest received date, when date is invalid or missing. It seems to be what other mail clients do.

The notes about filtering is mostly suggestions for improvements, like a match on missing headers.
Comment 3 Allan Sandfeld 2020-05-29 08:52:43 UTC
I think the safest would be to used that latest received date, when date is invalid or missing. It seems to be what other mail clients do.

The notes about filtering is mostly suggestions for improvements, like a match on missing headers.
Comment 4 Alex Hermann 2020-06-02 20:30:14 UTC
Wouldn't the first received date be more appropriate? It is probably closer to the real originating date than the latest received dat after all intermediate hops with all their delays.
Comment 5 Allan Sandfeld 2020-06-02 21:34:48 UTC
Sure, it shouldn't matter much, as long as it has an appropriate date in the right time span.
Comment 6 Allan Sandfeld 2020-06-02 21:36:18 UTC
I guess the reason I prefer the latest received is that I trust the email-servers closer to home more. The earlier it gets the more likely it could have been spoofed.
Comment 7 Allan Sandfeld 2020-06-05 07:46:00 UTC
(In reply to Laurent Montel from comment #1)
> Hello,
> You're idea is to use "received date" in messagelib for sorting message or
> replacing in message directly unknown date by "received date" ?
> Regards

I seem to remember an option for this back in the day (perhaps in kmail1?). In any case I wouldn't change the mail these days to not break possible signatures. But use this new fallback date in the C++ and user interface when reading the date field. That way missing (or invalid) dates get a valid useful date for sorting and displaying.

Though it might be useful if dates in the future are marked as invalid early so they don't become valid later. But it could be changed in stages.
Comment 8 Matt Gibbs 2020-12-11 04:45:59 UTC
Hi - I've also come across this issue and it breaks sorting.  Occasionally I receive e-mails without a "date" header and so Kmail will give it a date of 01/01/1970 12:00AM for sorting.  I have some other e-mails that have a date header of

Date: Thu, 1 Jan 1970 00:00:00 +0000

which Kmail shows as "Unknown" for sorting.

I also suggest using one of the received dates for sorting if it finds one of the above conditions.

I'm using 5.15.3 from openSUSE.
Comment 9 Tane 2023-01-23 08:48:44 UTC
KMail 5.15.3
Debian 11 (bullseye)

Messages show up as unread but you have to scroll down to 1970 to find them. 

My Kmail settings are;
View/message list/sorting = by date/time
View/message list aggregation = current activity/threaded
View/message list/theme = smart
Comment 10 Tim Colgate 2023-09-13 13:37:15 UTC
Was there agreement on the correct approach for this? The simplest would probably be to use the "Delivery-date:" field in the header if the "Date:" field is missing. Otherwise there are dates in the "Received:" fields.

It looks like bug 425216 is basically the same issue, and 227942 may also be related.