Response from different mailing address is shown in contact request

[Jas2Ma]

• Operating System (Linux/Mac/Windows/iOS/Android): Linux
• Delta Chat Version: 1.20.2
• Expected behavior: Emails answered by different mailing address show up in private chat (having multiple mailing addresses going to the same inbox is common, with non dc-clients a different mailing address might be preselected for answering). The dissent mailing address should be shown with a leading ~.
• Actual behavior: Emails answered by different mailing address show up as contact request. This way one can not be safe to read all corresponding messages. The Android-Client shows the expected behavior.
• Steps to reproduce the problem: Answer private chat message with different mailing address

[Jikstra]

Seems like a core problem to me. Will move responseability :P

[Hocuri]

I think that this has been fixed by #2297.

The Android-Client shows the expected behavior.

This sounds to me as if you were using a Delta-Chat-Desktop version with an old core. DC-Desktop is not always that fast with updating to the newest core, so it is possible that #2297 has not been released on DC-Desktop yet. Or maybe it has by now, but when this issue was opened in June.

[Jas2Ma]

I tested it today, same result, with Version 1.22.2 (git: flathub) using ubuntu 20.04.3.

The message is still shown as contact request. In Android it is now, too. Did I miss something? Here is what I test:

1. send a message from A to B
2. answer message at B by C (Ubuntu evolution)
3. Message should appear at A as ~C in chat with B. Actually it appears as contact request from C at A.

[Jas2Ma]

Here I give you the masquerade code of the second/answering mail given to me by evolution:

Message-ID: [email protected] Subject: Re: Zotero file managment From: My Name [email protected] To: My Name [email protected] Date: Wed, 10 Nov 2021 11:06:56 +0100 In-Reply-To: [email protected] References: [email protected] [email protected] [email protected] Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5-0ubuntu1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Evolution-Identity: 35fdb496912f804f3c0a7736c227bfc6f526a767 X-Evolution-Fcc: folder://3a4c6d2ad060bdad778610ef9d7b1003eae65889/INBOX X-Evolution-Transport: cb00ff0629c901c0c6064006464c59f6b6e25bc3 X-Evolution-Source-Folder: folder://54fac303aa012faf59dbd16519f80c66fee9eee5/INBOX X-Evolution-Source-Message: 683 X-Evolution-Source-Flags: ANSWERED SEEN X-Evolution-Source:

Can you see this?

Am Mittwoch, dem 10.11.2021 um 09:55 +0000 schrieb My Name:

Test -> For return with different Email-Adress

I do not understand how that works for you. Did Evolution miss something in the reply, that prohibits you to detect it as answer from B?

[Hocuri]

I looked into the code, and:

We don't assign private messages to the parent chat, but to the 1:1 chat with the sender. A message is "private" if it was sent only to self and to no one else. We do this by checking is_probably_private_reply() in lookup_chat_by_reply().

What we could do is, restrict this to groups because the concept of a "private reply" doesn't make sense in a 1:1 chat. Or, better, to change as little as possible, restrict this to all non-1:1 chats:

diff --git a/src/dc_receive_imf.rs b/src/dc_receive_imf.rs
index c0ab3ef2..c7f05885 100644
--- a/src/dc_receive_imf.rs
+++ b/src/dc_receive_imf.rs
@@ -1335,7 +1335,10 @@ async fn lookup_chat_by_reply(
             return Ok(None);
         }
 
-        if is_probably_private_reply(context, to_ids, mime_parser, parent_chat.id, from_id).await? {
+        if parent_chat.get_type() != Chattype::Single
+            && is_probably_private_reply(context, to_ids, mime_parser, parent_chat.id, from_id)
+                .await?
+        {
             return Ok(None);
         }

At least none of the tests fails with this diff.

Disadvantage: Makes the whole chat-id-assignment logic a little bit more complicated.

[link2xt]

So the proposal is that if we receive a message which does not have our address anywhere, because it is a message sent by our alias or because we are in Bcc, and the message has only a single recipient, we assign the message to the 1:1 chat with the recipient but the from_id of the contact listed in the From?

I do not think using ~ (i.e. setting an "override sendr name") applies here if we do not know that From is our alias.

Maybe as a start, add a testcase for when From is an address listed in SecondaryAddr config. In this case we can indeed set from_id to self, but set override name to match the name actually used in the From field. But there is currently no way for the user to add alias addresses to SecondaryAddr manually.