1799112 - Fails to thread message with UTF-8 encoded id in `References`

Status: RESOLVED INVALID

(Thunderbird :: Untriaged, defect)

Description

[Paul Menzel]

Steps to reproduce:

Using Debian sid/unstable with thunderbird 1:102.4.1-1, receive a message, which is a reply to another message in my inbox.

Actual results:

The message is incorrectly threaded.

Mikulas’ message has:

Message-ID: <[e-mail]>

The reply contains:

In-reply-to: =?utf-8?q?=3Calpine=2ELRH=2E2=2E21=2E2211031121070=2E18305=40fi?=

=?utf-8?q?le01=2Eintranet=2Eprod=2Eint=2Erdu2=2Eredhat=2Ecom=3E?=
References: =?utf-8?q?=3Calpine=2ELRH=2E2=2E21=2E2211031121070=2E18305=40fil?=
=?utf-8?q?e01=2Eintranet=2Eprod=2Eint=2Erdu2=2Eredhat=2Ecom=3E?=

Expected results:

The message should be threaded correctly.

Comment 1

[Thomas D. (:thomas8)]

Attachment: Set1.Test threading - John Doe - 2022-11-18 1632.001.eml

.

Comment 2

[Thomas D. (:thomas8)]

Attachment: Set1.Re Test threading - John Doe - 2022-11-18 1632.002.eml (with ASCII ids in `References` and `In-reply-to` - correct threading)

.

Comment 3

[Thomas D. (:thomas8)]

Attachment: Set2.Test threading - John Doe - 2022-11-18 1632.001.eml

.

Comment 4

[Thomas D. (:thomas8)]

Attachment: Set2.Re Test threading - John Doe - 2022-11-18 1632.002.eml (UTF-8 encoded id in `References` and `In-reply-to`)

.

Comment 5

[Thomas D. (:thomas8)]

Comment on attachment 9304134 [details]
Set2.Re Test threading - John Doe - 2022-11-18 1632.002.eml (UTF-8 encoded id in References and In-reply-to)

This is the reply message of reporter's case, having UTF-8 encoded id in References and In-reply-to.

Comment 6

[Thomas D. (:thomas8)]

Thanks Paul! Confirming on 102.5.0 (64-bit), Win10 - see my contrastive testcases attached.
Messages with UTF-8 encoded id in References and In-reply-to are not correctly threaded (not recognized as belonging to the original message with ASCII message id).

And then, it's already on record - bug 1596377.

Comment 7

[Magnus Melin [:mkmelin]]

When UTF-8 is used in References (which seems like a bad pointless idea), the value shouldn't be qencoded, but actually real UTF-8.