feat: protect the Date header

[link2xt]

Closes #6878
Based on #6867
This depends an a fix #6669, so we may want to postpone merging this until more users have it.

We do not try to delete resent messages
anymore. Previously resent messages
were distinguised by having duplicate Message-ID,
but future Date, but now we need to download
the message before we even see the Date.
We now move the message to the destination folder
but do not fetch it.

It may not be a good idea to delete
the duplicate in multi-device setups anyway,
because the device which has a message
may delete the duplicate of a message
the other device missed.

To avoid triggering IMAP busy move loop
described in the comments
we now only move the messages
from INBOX and Spam folders.

[link2xt]

Legacy Python test tests/test_1_online.py::test_resend_message got broken by this.
Resent message is not recognized as duplicate anymore because outer timestamp of just received message is compared to the timestamp of the fetched message:

core/src/imap.rs

Lines 603 to 610 in adcc8a9

	let ts_sent = headers
	.get_header_value(HeaderDef::Date)
	.and_then(|v| mailparse::dateparse(&v).ok())
	.unwrap_or_default();
	let is_dup = is_dup_msg(is_chat_msg, ts_sent, ts_sent_old);
	if is_dup {
	info!(context, "Deleting duplicate message {message_id}.");
	}

[link2xt]

This has now broken the test added in c14f45a

[link2xt]

We will have to use something less suspicious than unix epoch, GMX is unhappy:
#6878 (comment)

[link2xt]

I have updated this PR to not send 1970 as the date. Should be good enough for review/merging now.

[link2xt]

So now the date looks like this Date: Sun, 15 Jun 2025 15:06:40 +0000.
You convert it and get:

date -d 'Sun, 15 Jun 2025 15:06:40 +0000' +%s
1750000000

[iequidoo]

This part looks unrelated because looking at encrypted timestamp_sent is fine, and does this mean that duplicates will be never deleted, even if the message is deleted by the user?

[link2xt]

When user manually deletes a message, all messages with the same rfc724_mid are deleted. See message::delete_msg_ex.

[iequidoo]

This code was deleting duplicates on IMAP, w/o it duplicates will only be deleted locally

[iequidoo]

Apparently this code removal corresponds to this part of the commit message:

It may not be a good idea to delete
the duplicate in multi-device setups anyway,
because the device which has a message
may delete the duplicate of a message
the other device missed.

But even if don't delete the duplicate, there's no guarantee the other device didn't miss both messages. Leaving the duplicate is useful though if the user detected a missed message on the other device and asked to resend it. Anyway, if we don't want to IMAP-delete duplicates anymore, i'd add a comment here explaining the motivation / scenario in which keeping the duplicate is useful.

[Hocuri]

We could add a comment, but also, it's fine as-is, because the code IMAP-deleting duplicates is removed now, and it's more important to explain why we do things than explain why we don't do things.

[iequidoo]

The code in imap is being removed, but it was just an optimization removing duplicates before decryption and parsing. A short comment won't make harm.

But i think that it's better to IMAP-delete not the duplicate, but the existing message instead, this way we don't affect receiving re-sent messages by other devices.

[link2xt]

But i think that it's better to IMAP-delete not the duplicate, but the existing message instead, this way we don't affect receiving re-sent messages by other devices.

If we change from previous behavior (removing last message) to removing the first message, then in multi-device setup with two different versions it's possible to end up with both copies deleted on the server.

[Hocuri]

Nice!

[Hocuri]

@link2xt can we merge this, or is there a specific reason why you didn't merge it yet?