Read receipts break encryption in non-verified 1:1 chats

[link2xt]

It is reported that the problem appears on nightlies and in DeltaLab, but does not affect Android release using core 1.131.9.

@gerryfrancis says that the log contains

"src/e2ee.rs:66: Peerstate for '[EMAILADDRESS, e.g. mine]' is reset."

[adbenitez]

besides breaking chat protection, this bug is also responsible for the error in sending read receipts to outside address in chatmail instances due to "message is unencrypted" that is: the MDN detection of chatmail is now failing to detect MDN as such

[link2xt]

besides breaking chat protection, this bug is also responsible for the error in sending read receipts to outside address in chatmail instances due to "message is unencrypted" that is: the MDN detection of chatmail is now failing to detect MDN as such

This seems to be a different issue. Do MDNs look different now? Otherwise detection should still work.

EDIT: I opened a separate issue #5151 to track this.

[link2xt]

Could be caused by #4826 which changed the structure of unencrypted messages to hide Message-ID from servers modifying it.

[link2xt]

Here is an example of a message sent by new core with #4826 merged:

Return-Path: <foobar@merlinux.eu>
Delivered-To: alice@testrun.org
From: a <foobar@merlinux.eu>
Subject: Message opened
To: l <alice@testrun.org>
Date: Thu, 4 Jan 2024 20:14:58 +0000
Message-ID: <Mr.aLQiBhpnouN.Ef_RckRUODR@merlinux.eu>
Auto-Submitted: auto-replied
Chat-Version: 1.0
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="pCeEhsOkOZuGARlWqL4XCIPrFuyPDs"


--pCeEhsOkOZuGARlWqL4XCIPrFuyPDs
Message-ID: <Mr.aLQiBhpnouN.Ef_RckRUODR@merlinux.eu>
Content-Type: multipart/report; report-type=disposition-notification;
        boundary="E48R9AQO1xkNWgsnsQHLjNgBUiQWOs"


--E48R9AQO1xkNWgsnsQHLjNgBUiQWOs
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=no

The "Encrypted message" message you sent was displayed on the screen of
the recipient.

This is no guarantee the content was read.


--E48R9AQO1xkNWgsnsQHLjNgBUiQWOs
Content-Type: message/disposition-notification

Original-Recipient: rfc822;foobar@merlinux.eu
Final-Recipient: rfc822;foobar@merlinux.eu
Original-Message-ID: <Mr.9EX4DvSVfPk.SHvaezjIF5n@testrun.org>
Disposition: manual-action/MDN-sent-automatically; displayed


--E48R9AQO1xkNWgsnsQHLjNgBUiQWOs--

--pCeEhsOkOZuGARlWqL4XCIPrFuyPDs--

I still don't see how this breaks verified 1:1 chat and could not reproduce it, seems we are discussing a different problem here. Autocrypt header is not added to MDNs so if MDN is not recognized as such by old DC version then this could result in reset. Need to check if we also changed MDN detection code in the core.

EDIT: I checked the code, MDNs should be detected recursively even by old DC versions and not break encryption. I also scanned faqbot@testrun.org "QR-code" from https://deltachat-bot.github.io/public-bots/ and got verified 1:1 chat that does not seem to break due to read receipts.

For chatmail servers not recognizing new MDNs I opened an issue #5151

[link2xt]

@gerryfrancis sent these steps to reproduce the bug:

Test goes like this:

1. A send message to B.
2. B reads the message, DC send read receipt to A, but no reply message.
3. A send another message to B, that message is not encrypted.

I have not been able to reproduce the issue with two non-chatmail accounts using the latest core.

[link2xt]

Update: @gerryfrancis said the chat was not verified.

[link2xt]

I can reproduce, with the latest core just created a new @testrun.org account.

Messages sent after receiving a message are encrypted, but messages sent after receiving an MDN are not.