Recently the great support folks at FastMail helped me to debug a rather irritating issue where emails that had languished in my inbox for too long, and were then processed by me to end up in the Archive folder, would get the date of archival assigned as the main email date, instead of the date of arrival.

For example, an email with a date in November of 2020 would get a new date of say February 21, 2021, if that’s the date that I finally got around to it and moved it to the Archive folder.

This played havoc with email retrieval efforts, where I can usually remember the month in which something transpired, and then use that to narrow down my search.

After some debugging and a great deal of web searches, it turns out the culprit was in fact a bad default in the mbsync mail synchronization tool which is an important part of my Emacs and mu4e mail-processing setup.

Based on this, please do take my advice when I say:

Always set mbsync CopyArrivalDate to yes!

In the mbsync documentation we read the following about CopyArrivalDate:

Selects whether their arrival time should be propagated together with the messages. Enabling this makes sense in order to keep the time stamp based message sorting intact. Note that IMAP does not guarantee that the time stamp (termed internal date) is actually the arrival time, but it is usually close enough. (Default: no)

So far, I have not been able to think of any situations where CopyArrivalDate no would be desirable.

I would appreciate being enlightened.

Until then, I do believe the default should be yes.

In any case, I now have right at the top of my ~/.mbsyncrc, so that it applies to everything in the rest of the file, the following lines:

# by default (CopyArrivalDate no), if you copy an old email from inbox to
# Archive (e.g.) it will get the date of the copy assigned, instead of just
# keeping its original date of arrival! That doesn't sound like a very good
# default to me. Also see:
CopyArrivalDate yes