Mail replies missing the "In-Reply-to" header since a few versions.

[toni-patroni]

Hi!

Since a few weeks mail replies send over the OX webmail client are missing the "In-Reply-to" header, thus breaking threading in MUAs like Thunderbird.

We work with quite some mailing lists and have a patch review workflow there, so this effectively breaks reviews from people using the webmail to answer.

Current versions in use:
UI version: 7.10.5 Rev5
Server version: 7.10.5-Rev5

But as said, this is broken since a bit, FWICT at least since 25.03.2021 here, I can only report it now because I waited weeks for an activation link from the forum and then another ~ten days to be actually approved - nuts!

[Wolfgang Rosenauer]

I actually cannot reproduce this but I'm on 7.10.5-rev9 already.

Testcase was just:
- send a mail
- reply from App Suite
- recipient got the mail and it contains a In-Reply-To and References header set to the original message.

[toni-patroni]

Thanks for replying!
You got my hope up with the newer version, but after our OX admin updated, and I retested I sadly saw no remedy yet


Testcase was also just:
* send mail from some mail-address
* reply from OX App Suite
* recipient got the mail but no In-Reply-To or References header set

The mail on the recipient looked like (I omitted the first few lines of the header with the Received, Arc-... entries, as that really should not be relevant here):

Date: Sun, 25 Apr 2021 18:00:20 +0200 (CEST)
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Thomas Lamprecht <thomas@lamprecht.org>
Message-ID: <532504187.29.1619366420453@webmail.proxmox.com>
Subject: Re: Testing in-reply-to
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Priority: 3
Importance: Normal
X-Mailer: Open-Xchange Mailer v7.10.5-Rev9
X-Originating-Client: open-xchange-appsuite

> Il 25/04/2021 17:37 Thomas Lamprecht <thomas@lamprecht.org> ha scritto:
>
>  
> Test, please reply to see if headers are OK now.


Test reply from the OX App Suite v7.10.5-Rev9 web-interface

[toni-patroni]

FWIW, replied to the exact same mail with Thunderbird, reply looks OK here:

Message-ID: <bc24f5ef-086d-5781-3958-32d3dc1f4c31@proxmox.com>
Date: Sun, 25 Apr 2021 18:10:14 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:89.0) Gecko/20100101
 Thunderbird/89.0
Subject: Re: Testing in-reply-to
Content-Language: en-US
To: Thomas Lamprecht <thomas@lamprecht.org>
References: <2a686c2a-bf69-b5da-3fc0-05b5b1af2ca1@lamprecht.org>
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
In-Reply-To: <2a686c2a-bf69-b5da-3fc0-05b5b1af2ca1@lamprecht.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 25.04.21 17:37, Thomas Lamprecht wrote:
> Test, please reply to see if headers are OK now.
>

Test reply from Thunderbird

Both, the References and In-Reply-To are there and correct.

So, as the same SMTP server is used by both and the receive path looks exactly the same, I'd rule some scrambling in-between which would drop just those two header out, seems really related to using the OX App Suite MUA (not sure if there's any setting related to this?)

[Wolfgang Rosenauer]

So to my knowledge there is no configuration which should be able to change that behavior.
Tested again and it still works as expected for me.

I'm wondering what could be special for you then. I'm wondering if we could do some cross checking.
E.g. you send such a testmail to me, I reply ... and the other way round. If you are interested please use my firstname@lastname.org to get in contact.

[toni-patroni]

Ok, I sent the test message, much thanks for the offer.


FYI, we had the old OX6 GUI still available, so I tested with that one. There it also worked OK, both References and In-Reply-To are included and correct.

So working tuple:

GUI Version: 6.22.13 Rev5
Server Version: 7.10.5-Rev9

[toni-patroni]

So I could test this on a test instance which is managed the same way as the other, both with UCS (univention) and same version, there it works OK.

The only difference between those versions is, that the problematic one was setup a bit earlier - but both are existing since years.

So, what can cause this to start failing on only one instance since the update to v7.10.5-Rev5? At least I'm a bit flabbergasted from that behavior here.