`Chat-Version:` header seems to do more harm than good meanwhile

[r10s]

the Chat-Version: header may do more harm than good nowadays.

e.g. mailcow seems to move messages by default with this header unconditionally to the DeltaChat folder, resulting in messages just being missed on the recent Delta Chat updates. maybe there are more such automations.

if we do not use the DeltaChat folder any longer internally, and the main purpose of external usage of this header was to move messages server-side around, it seems logical to drop the header as well.

only reason to maintain it, is if we still need it internally, i do not have deep knowledge over that, but reading #7932 it does not look like it, the PR even suggests to "moving Chat-Version must happen at least one release after the PR here is released"

for existing filters, well, the server obviously anyways need adaption and can then be adapted for filtering eg. by "message encrypted" or "subject = [...]". both a bit hands on, but good enough regarding the fact that we do no longer support "shared usecase" at all

[link2xt]

The reason for keeping Chat-Version was to avoid users on pre-2.50.0 from missing the messages if they have show_emails setting configured to not fetch non-chat messages. #7632 removed show_emails in 2.50.0. Also related, with #8566 we don't even remember anymore which messages are chat messages.

We don't need to remove Chat-Version, maybe it is still useful to be able to distinguish if the message is generated by us on the client, but we can protect the header. See also comment at #8016 (comment), we already document Chat-Version as encrypted, but still copy it into unencrypted part.

[link2xt]

I opened #8596 to protect the Chat-Version. We may still want to remove Chat-Version from unencrypted messages so Chat-Version never appears unencrypted and nobody can use it for any sort of server-side filtering then. We can also try to remove Chat-Version completely, but it is used at least here and will break chat bot detection:

core/src/receive_imf.rs

Lines 1015 to 1021 in 0119db8

	if let Some(is_bot) = mime_parser.is_bot {
	// If the message is auto-generated and was generated by Delta Chat,
	// mark the contact as a bot.
	if mime_parser.get_header(HeaderDef::ChatVersion).is_some() {
	from_id.mark_bot(context, is_bot).await?;
	}
	}

Also this logic will break, it is only about group messages without Chat-Group-Member-Timestamps so we may want to clean it up anyway, but this is a reason not to remove Chat-Version now:

core/src/receive_imf.rs

Lines 3162 to 3167 in 0119db8

	// Allow non-Delta Chat MUAs to add members.
	if mime_parser.get_header(HeaderDef::ChatVersion).is_none() {
	// Don't delete any members locally, but instead add absent ones to provide group
	// membership consistency for all members:
	new_members.extend(to_ids_flat.iter());
	}

Overall i think cleaning up Chat-Version dependencies is good, but i'd rather not stop sending it in encrypted messages now, it does not gain us much but then we need to think about how old versions will behave when they receive a message without Chat-Version.

[link2xt]

We may still want to remove Chat-Version from unencrypted messages so Chat-Version never appears unencrypted and nobody can use it for any sort of server-side filtering then

I tried to do it, but this results in unencrypted messages arriving with Subject prepended to the message body for unencrypted chat messages.

[giocomai]

For reference, quick update on the MailCow side of things: a PR dropping legacy DeltaChat auto-filing sieve rule has just been committed to staging:

[Dovecot] Remove legacy DeltaChat auto-filing sieve rule