SMTP-Forwarded read receipts should not turn into new chats

[link2xt]

An issue is reported on the forum that read receipts with a To: field not corresponding to self address create a group: https://support.delta.chat/t/troubles-with-system-messages-and-alias/2888

This should be reproducible with a simple Rust test. Read receipts should be trashed as usual and mark messages as read regardless of the To: field.

[Septias]

I'm having troubles recreating this. I used set_override_sender_name but bob only creates MDNs with a to field alice@example.org.

[link2xt]

I think original poster just used forwarding on provider level. So to reproduce you can create Alice user and receive_imf an unencrypted read receipt from Bob. This will currently likely create a group with Alice, Bob and original sender.

[Septias]

How do you know he did that? I don't really read that from the forum post...

[Septias]

I think original poster just used forwarding on provider level. So to reproduce you can create Alice user and receive_imf an unencrypted read receipt from Bob. This will currently likely create a group with Alice, Bob and original sender.

What will this scenario look like? Maybe this:

To: <alice@axample.org>
From: <bob@example.net> <fiona@example.net>

[link2xt]

There is a single From when message is SMTP-forwarded. Just the To: field is not corresponding to our self-address.

[Septias]

So to address would be fiona@example.net for alice?

[link2xt]

It is two accounts configured on the same mailbox, e.g. <alice@example.org> and <alicechat@example.org>. Two Delta Chat accounts are configured using the same login and password, but different From: address. E.g. <alicechat@example.org> sends a mail to <bob@example.net>. Bob repiles with a read receipt from <bob@example.net> to <alicechat@example.org>. Alice's account <alice@example.org> receives it and creates a group with <alice@example.org> (self), <alicechat@example.org> (from the To: field) and <bob@example.net>.

For normal messages adding self into ad-hoc group makes sense, but for read receipts this should not happen, we should unconditionally just process them as read receipts.