Protect the `Date` header

[link2xt]

We want to protect the sender date (the Date header) to reduce the metadata available to the server.

There is some preparation work done in #6669 to make the client read the Date header from the protected part and using it to set the last_seen property of the Autocrypt peerstate.

However, initial attempt to replace the Date header with Thu, 01 Jan 1970 00:00:00 +0000 broke the legacy Python test tests/test_1_online.py::test_resend_message which tests that resent message gets deleted by the receiver. Currently resent messages are resent with the same Message-ID (#3238), but a different Date. We then use this fact to detect resent messages:

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}.");
	}

We cannot unconditionally delete all messages that have known Message-ID. We did it in the past and it caused problems for users manually moving the messages between folders: #3138
We also cannot unconditionally move duplicates to the target folder and fetch them, because this previously caused infinite move loops on servers that have multiple aliases for mvbox:
#4544

One way to resolve this would be to move all messages unconditionally, including the duplicates, but only move from INBOX to mvbox and never from other folders. The only case when we might want to move the message out of non-INBOX folder is when it was incorrectly moved into the Spam folder by the spam filter. So maybe move out of INBOX and Spam only, but not out of all folders. This way we don't need to look at the Date, but avoid infinite loops.

[link2xt]

I am running #6877 as an experiment, setting the date to Thu, 01 Jan 1970 00:00:00 +0000.

GMX is unhappy, it returns an error:

host mx00.emig.gmx.net[212.227.15.9] said:
554-Transaction failed
554-Reject due to policy restrictions.
554 For explanation visit https://postmaster.gmx.net/en/case?...
(in reply to end of DATA command)

The URL leads to a web page that shows this:

[hpk42]

Maybe using 1970 is a bit extreme :) How about always setting the outer Date header to current year's first day or so? It is leaking more information than a static string but let's not overdo it. Did you try not sending an outer Date header at all? I guess GMX would also complain.

…

On Fri, May 30, 2025 at 12:10 -0700, l wrote: link2xt left a comment (chatmail/core#6878) I am running #6877 as an experiment. GMX is unhappy, it returns an error: ``` host mx00.emig.gmx.net[212.227.15.9] said: 554-Transaction failed 554-Reject due to policy restrictions. 554 For explanation visit https://postmaster.gmx.net/en/case?... (in reply to end of DATA command) ``` The URL leads to a web page that shows this:  -- Reply to this email directly or view it on GitHub: #6878 (comment) You are receiving this because you are subscribed to this thread. Message ID: ***@***.***>