Upgrading a 1:1 conversation to e2ee using a second email client does not work as expected

[seifferth]

Delta Chat version on Bob's side: 2.43.0 (Android app from F-Droid)
Delta Chat version on Alice's side: 2.43.0 (Android app from F-Droid)

Settings:

• Both Alice and Bob have "Multi Device Mode" enabled
• Bob has "Show Classic Emails" set to "All"
• Alice has "Show Classic Emails" set to "No, chats only"

Observed behaviour:

• Alice and Bob exchange keys via SecureJoin, which creates a key-contact chat on both sides
• Alice and Bob exchange multiple messages back and forth via Delta Chat
• At some point, Alice uses a different email client to send a message (M) without e2ee
  • On Alice's side, this message does not appear in Delta Chat at all (as expected)
  • On Bob's side, this message appears in an address-contact chat with Alice (as expected)
• Bob uses a different email client to send a reply (R) with e2ee enabled using the key known from the previous key exchange
  • On Alice's side, R does not appear in Delta Chat at all (unexpected)
  • On Bob's side, R appears in a new address-contact group chat that has Alice as its only member (unexpected); interestingly, there is no envelope symbol on the message itself

Expected behaviour:

• Alice and Bob exchange keys via SecureJoin, which creates a key-contact chat on both sides
• Alice and Bob exchange multiple messages back and forth via Delta Chat
• At some point, Alice uses a different email client to send a message (M) without e2ee
  • On Alice's side, this message does not appear in Delta Chat at all
  • On Bob's side, this message appears in an address-contact chat with Alice
• Bob uses a different email client to send a reply (R) with e2ee enabled using the key known from the previous key exchange
  • R appears in the existing key-contact chat between Alice and Bob on both sides

Thoughts about why this might happen

I guess there might be an issue with assigning R to an existing chat. Note that R does not reference (via In-Reply-To or References) any previous message from the key-contact chat between Alice and Bob. If Bob sends a reply R' that references an existing message from the key-contact chat (via both In-Reply-To and References; everything else being equal to the case described above), R' does indeed appear in the key-contact chat between Alice and Bob on both sides.

I do realize that assigning the message to an existing chat might be tricky in the case described above. However, the following methods should be possible:

• R is signed by Bob -- so at least Alice should be able to attribute that message to Bob.
• R is encrypted to both Alice's and Bob's encryption subkey. Both Alice and Bob know both encryption subkeys.

Other things that may be relevant

• R uses protected headers (RFC 9788), where the outer header looks like this:

Date: [[real message Date]]
Message-ID: [[real Message-ID]]
From: bob@example.com
To: hidden-recipients:;
Subject: [...]
In-Reply-To: [[real In-Reply-To value]]
References: [[real References value]]

• R contains an Autocrypt header with Bob's keydata, but no Autocrypt-Gossip header with Alice's keydata.

• R does reference M (via In-Reply-To and References) but it does not reference any message found in the key-contact chat between Alice and Bob

• Encryption was performed with gpg, so the PGP MESSAGE uses the old packet format for some things. The output of sq packet dump looks like this:

Public-Key Encrypted Session Key Packet, old CTB, 94 bytes
    Version: 3
    Recipient: [[KeyID for Bob's encryption subkey]]
    Pk algo: ECDH

Public-Key Encrypted Session Key Packet, old CTB, 94 bytes
    Version: 3
    Recipient: [[KeyID for Alice's encryption subkey]]
    Pk algo: ECDH

Sym. Encrypted and Integrity Protected Data Packet, new CTB, partial length, 1024 bytes in first chunk

    Version: 1
    No session key supplied

[link2xt]

#7786 is supposed to fix this case, but only when intended recipient fingerprint subpacket is on the signature.

Can you decrypt the message R while keeping the signature using --unwrap option of gpg and show how the signature looks like with sq packet dump? If Alice's key fingerprint is there, Bob's Delta Chat should recognize that the message is intended for Alice's key. Otherwise Bob's Delta Chat cannot really tell if the message is for Alice's key, or just for Alice's address but for a different key, this is why encrypted message gets assigned to the chat with Alice's address rather than Alice's key.

[link2xt]

On Alice's side, R does not appear in Delta Chat at all (unexpected)

Why do you expect Alice's Delta Chat to show a non-chat message with "No, chats only" setting?

[seifferth]

> On Alice's side, R does not appear in Delta Chat at all (unexpected) Why do you expect Alice's Delta Chat to show a non-chat message with "No, chats only" setting?

I assumed that if R' is treated as a "chat message", R would be treated as a "chat message" as well -- as the main difference between those two messages are the In-Reply-To and References headers, which I did not expect to affect the "chat message" vs. "classic email" distinction. Of course, I could have misunderstood what "chat message" means. I.e. I understood "chat message" to mean "a message that is end-to-end encrypted and signed" -- as opposed to a "classic email" which I took to mean "not end-to-end encrypted; and therefore marked with an envelope icon". Neither R' nor R contain a Chat-Version header. If I am mistaken about the meaning of "chat message", I would appreciate any pointers to further clarification of its meaning.

Can you decrypt the message `R` while keeping the signature using `--unwrap` option of `gpg` and show how the signature looks like with `sq packet dump`? If Alice's key fingerprint is there, Bob's Delta Chat should recognize that the message is intended for Alice's key. Otherwise Bob's Delta Chat cannot really tell if the message is for Alice's key, or just for Alice's address but for a different key, this is why encrypted message gets assigned to the chat with Alice's address rather than Alice's key.

Thanks for pointing me to the Intended Recipient subpacket. I had not been aware of that before; and I'll see if I can get my setup to create this packet going forward. For completeness, I include the packet dumps you requested below. I can see that Bob's Delta Chat cannot verify that the message was intended for Alice. However, Alice's Delta Chat should be able to verify that the message was indeed sent by Bob. So I guess this leads us back to the meaning of "chat message" mentioned above. Also: In Bob's Delta Chat, message R did not get assigned to the existing chat with Alice's address. It got assigned to a new email-style group chat instead; and this new group chat does not have Bob in the member list, even though Bob's address is mentioned in the From field of message R. # Packet dump for message R $ cat R | gpg --decrypt --unwrap | sq packet dump gpg: encrypted with 255-bit ECDH key, ID [...], created [...] ***@***.***>" gpg: encrypted with 255-bit ECDH key, ID [...], created [...] ***@***.***>" Compressed Data Packet, old CTB, indeterminate length │ Algorithm: ZLIB │ ├── One-Pass Signature Packet, old CTB, 13 bytes │ Version: 3 │ Type: Binary │ Pk algo: EdDSA │ Hash algo: SHA256 │ Issuer: [...] │ Last: true │ ├── Literal Data Packet, new CTB, partial length, 2048 bytes in first chunk │ Format: Binary data │ Timestamp: 2026-03-03 09:27:38 UTC │ Content: "Content-Type: text/plain; charset=\"utf-8"... │ └── Signature Packet, old CTB, 117 bytes Version: 4 Type: Binary Pk algo: EdDSA Hash algo: SHA256 Hashed area: Issuer Fingerprint: [...] Signature creation time: 2026-03-03 09:27:38 UTC Unhashed area: Issuer: [...] Digest prefix: [...] Level: 0 (signature over data) # Packet dump for message R' $ cat R_ | gpg --decrypt --unwrap | sq packet dump gpg: encrypted with 255-bit ECDH key, ID [...], created [...] ***@***.***>" gpg: encrypted with 255-bit ECDH key, ID [...], created [...] ***@***.***>" Compressed Data Packet, old CTB, indeterminate length │ Algorithm: ZLIB │ ├── One-Pass Signature Packet, old CTB, 13 bytes │ Version: 3 │ Type: Binary │ Pk algo: EdDSA │ Hash algo: SHA256 │ Issuer: [...] │ Last: true │ ├── Literal Data Packet, new CTB, partial length, 1024 bytes in first chunk │ Format: Binary data │ Timestamp: 2026-03-03 11:38:30 UTC │ Content: "Content-Type: text/plain; charset=\"utf-8"... │ └── Signature Packet, old CTB, 117 bytes Version: 4 Type: Binary Pk algo: EdDSA Hash algo: SHA256 Hashed area: Issuer Fingerprint: [...] Signature creation time: 2026-03-03 11:38:30 UTC Unhashed area: Issuer: [...] Digest prefix: [...] Level: 0 (signature over data)

[iequidoo]

If I am mistaken about the meaning of "chat message", I would appreciate any pointers to further clarification of its meaning.

A chat message is a message containing the "Chat-Version" header in its signed and encrypted payload. Not sure it's documented somewhere though except for the code comments.

So, Signature Packet in R and R' doesn't contain the "Intended Recipient Fingerprint" subpacket (it should be in Hashed area), so for the record, this is expected:

• On Bob's side, R appears in a new address-contact group chat that has Alice as its only member (unexpected); interestingly, there is no envelope symbol on the message itself

There's no envelope symbol on the message itself because it's correctly encrypted and signed.

• On Alice's side, R does not appear in Delta Chat at all (unexpected)

Could you try to set "Show Classic Emails" for Alice to "For accepted contacts"? Then such a message should appear in Alice's Delta Chat and be assigned to the correct 1:1 chat (and we could close this issue AFAIU).

[seifferth]

So, `Signature Packet` in R and R' doesn't contain the "Intended Recipient Fingerprint" subpacket (it should be in `Hashed area`), so for the record, this is expected: > * On Bob's side, R appears in a new address-contact group chat that has Alice as its only member (unexpected); interestingly, there is no envelope symbol on the message itself

I am afraid that I don't fully understand this point yet. I can see why the message has no envelope symbol. I can also see why it appears in an address-contact chat. I do not yet understand why it should appear in an address-contact group chat. It's simply a message "From: Bob" and "To: Alice" (although some headers are protected as per RFC 9788). My intuition would be that (on Bob's side) the message should at least appear in the existing address-contact 1:1 chat with Alice's address. Could you elaborate why this intuition is wrong?

> * On Alice's side, R does not appear in Delta Chat at all (unexpected) Could you try to set "Show Classic Emails" for Alice to "For accepted contacts"? Then such a message should appear in Alice's Delta Chat (and we could close this issue AFAIU).

I'll try to confirm this soon(tm). It might take a couple of days until I get a chance to do it, though. I'll get back to you on this.

[iequidoo]

• On Bob's side, R appears in a new address-contact group chat that has Alice as its only member (unexpected); interestingly, there is no envelope symbol on the message itself

I do not yet understand why it should appear in an address-contact group chat. It's simply a message "From: Bob" and "To: Alice" (although some headers are protected as per RFC 9788). My intuition would be that (on Bob's side) the message should at least appear in the existing address-contact 1:1 chat with Alice's address. Could you elaborate why this intuition is wrong?

The message assigned to a group chat with only Alice is on purpose for Bob to avoid continuing conversation unencrypted, Bob can't send messages if he isn't a group member. https://www.rfc-editor.org/rfc/rfc9787.html#name-composing-a-reply-message tells that a MUA should avoid unencrypted replies to encrypted messages, but even if a message isn't a reply technically, i think that not suggesting to send unencrypted messages to Alice makes sense.

[seifferth]

The message assigned to a group chat with only Alice is on purpose for Bob to avoid continuing conversation unencrypted, Bob can't send messages if he isn't a group member. https://www.rfc-editor.org/rfc/rfc9787.html#name-composing-a-reply-message tells that a MUA should avoid unencrypted replies to encrypted messages, but even if a message isn't a reply technically, i think that not suggesting to send unencrypted messages to Alice makes sense.

Thanks for pointing me to RFC 9787. This does sound reasonable. For the record: I posted some follow-up thoughts about this issue on the forum at https://support.delta.chat/t/4852 and https://support.delta.chat/t/4853. I also learned that simplifying the "Show Classic Email" setting is already planned with #7494 -- and I suppose that this change will fix the misunderstanding about what "chat message" actually means. As already mentioned, I will get back to you to once I can confirm that setting Alice's "Show Classic Emails" to "For accepted contacts only" solves the issue.