"Date" used to be the default, and it's bad because Date is:
- Set by the sending app
- Can be wrong, on the sending side
- Cannot be changed on the receiving side
The same 3 arguments are applicable to "From:" field, but you are not rewriting that?
What this means in practice -- I'd get support email like "why is there a message from January 1, 1970 (or July 15, 2017...) in my mailbox, and how do I fix it".
And often, I hear people saying:
"Why does this mail (spam) tell me that it was sent by me? I didn't send it!..."
There is bad (or malicious) software on the sending side. I know that you are doing a lot in various areas to compensate for some shortcomings of other programs, servers, etc.
But I think this is not correct here.
As I wrote above, Date: is one of the very few headers shown by default by all e-mail programs that allows to identify the message (from a particular sender) almost uniquely.
And it frequently used in the business world: "In your message of November 17, 10:15am (EST), ..."
INTERNALDATE is assigned by the server, and is less likely to be grossly wrong like that.
Most messages are delivered within seconds to minutes (with some rare exceptions), so I really don't think there anything lost here.
There are many exceptions.
Let me name a few:
1. When greylisting is enabled on the receiving servers (as an anti-spam measure), messages can be arriving half an hour later.
(I am not a proponent of this solution, but I've had it enabled by my previous employer.)
2. When the messages are sent by the sender's device at a later point (e.g. a person writes messages in the absence of connectivity, and then they are queued for sending). This happens all the time: when people are working during flights, or even during a ground trip with the device that does not have mobile connectivity (laptop, tablet, ..).
The discrepancy can be several hours.
3. There could be some maintenance window (scheduled or emergency) when the mail could be queued for hours at an MX server.
4. Mail quarantine at the dedicated spam-scanning servers at a large organization periphery. After you release a message from the quarantine, it will have essentially the date of when you released it. Since in some cases you can only do that from the internal network, if you are traveling, you don't get to look through the quarantined messages until you are back. (Yes, there is a VPN, but that's a different issue. And sometimes you cannot use VPN, especially from some public (NATted) networks or during international travel.)
...
All those things happen on a regular basis.
I think it is great that you enabled sorting based on INTERNALDATE! That makes perfect sense, at least for any folder with the
incoming messages. (Sorting incoming messages based on "Date:" header can result in missed messages. I had had that struggle with other mail clients until I fixed the settings for sorting.)
What I am talking about is what
date to display.
And I think that it should be the "Date:" header even when the sorting is done by INTERNALDATE.
Sorting and displaying date should be decoupled.
Sorting: optional (Sent Date, INTERNALDATE (received))
Display: Sent Date (as defined in RFC5256
https://tools.ietf.org/html/rfc5256#section-2.2 )
I had had some problems with Aquamail earlier, while I was trying to find a message from a sequence of several messages. In one case there were some 10 messages or so. The sender was referring to a particular message by the Date, and I couldn't understand why it was not there. I had not had time to investigate, and a few other cases it was somewhat easier to locate the message. So, I hadn't figured it out until this week, when I was looking at the messages that we discussed via e-mail.
In this, most recent case the Date: and INTERNALDATE were different by 1-2 days, and it became apparent what date is displayed.
Additional, in many (most?) cases INTERNALDATE does not exist in the message headers. This makes matching the date displayed to the "raw" message very difficult.