PS. Next time you copy an account into another, begin with OLDEST mail to the NEWEST (first come in server, first copied to new account)
I've migrated several accounts via IMAP.
Most recently, just a few months ago, I was migrating an account that was about 9 years old, had about 13GB worth of messages, and went through being handled by different server-side software combined with the direct access by clients. That history yielded some glitches in the way messages were indexed. As a result, migration software was choking on some messages, and I've tried various ways, and had to do some manual intervention to assure all (or rather most) messages were migrated.
Unfortunately, with some methods, when you do the migration, you have no explicit way of controlling the sequence in which messages are moved. E.g. one of the relatively easy ways is to copy folders from one account to another one in Thunderbird. Then you are hoping that Thunderbird would copy the messages in their sequence of appearance, which, in principle, is not guaranteed. (But surprisingly, it seems to do that, at least most of the time.)
And unfortunately, I don't know any mail system or email app that would consider this "little detail" when "migrating" or "uploading".
@Kostya: Actually, <i>offlineimap</i> copies messages according to their sequence provided by the IMAP server, -- as long as there are no problems/glitches. If it chokes on the specific folder, then, during the subsequent re-run, you might get some artifacts in the sequence. That's my personal observation.
Long click on your account name, in main view -> Options and folders -> Account options -> Messages to sync -> By time period -> 30 days
I actually wonder if that
always produces the result that you are thinking about.
Each message accessible via IMAP server has several dates associated with it:
1. Date in the "Date:" header set by the mail client, or by the first MSA (mail submission agent) server if it was missing.
2. "Internal date", set in the database (index) of messages by the SMTP or IMAP server. Typically it is set to the date when the message arrived.
3. I am not 100% certain, but I suspect that some mail clients might also be able to used the last "Received" header to derive the date when the message arrived. Maybe none of the modern mail programs is using that.
I suspect that there could be situations when the Internal Date (#2) is not copied over when the messages are migrated from one server to another (even though according to RFCs it should be). I wouldn't be surprised that at least in some scenarios of migrating messages, this date can be lost. In that case the "new" IMAP server needs to set that date to some value. I see two possibilities: it could be set as the date when the message was migrated ("first seen by the IMAP server"), or, in some implementations, it could be set to one of the dates #1 or #3 above, if the IMAP server is smart.
RFC 3501 has this
description::
In the case of messages delivered via [SMTP], this SHOULD be the
date and time of final delivery of the message as defined by
[SMTP]. In the case of messages delivered by the IMAP4rev1 COPY
command, this SHOULD be the internal date and time of the source
message. In the case of messages delivered by the IMAP4rev1
APPEND command, this SHOULD be the date and time as specified in
the APPEND command description. All other cases are
implementation defined.
Furthermore, in case of
APPEND:
If a date-time is specified, the internal date SHOULD be set in
the resulting message; otherwise, the internal date of the
resulting message is set to the current date and time by default.
@Kostya, your response implicitly suggests that choosing "30 days" always works...
But it sounds that there are situations (most likely rare) that the internal date could be lost during some migration. This is not a criticism. Aquamail does what it can do.
I am just saying that this recipe also has limitations.
