[MlMt] question about Message-ID based threading

[Chris Newman]

On 6 Sep 2018, at 0:24, Benny Kjær Nielsen wrote:
> On 3 Sep 2018, at 15:11, Peter van Dijk wrote:
>
>> when one of my coworkers makes a new calendar appointment, I get an 
>> email with headers like this:
>>
>> Message-ID: 
>> <Appointment.c26b5086-af7a-11e8-91be-b3acf41bfd87.1535975573228 at example.com>
>> In-Reply-To: 
>> <Appointment.c26b5086-af7a-11e8-91be-b3acf41bfd87 at example.com>
>> References: 
>> <Appointment.c26b5086-af7a-11e8-91be-b3acf41bfd87 at example.com>
>> Subject: New appointment: ...
>
> Ok, the `Message-ID` header is fine, but it makes little sense that it 
> refers to non-existing messages. I wonder if that serves any purpose 
> at all...
>
>> Then when somebody accepts, declines, etc., I get an email with 
>> headers like this:
>>
>> Message-ID: 
>> <Appointment.c26b5086-af7a-11e8-91be-b3acf41bfd87.1535976655967 at example.com>
>> In-Reply-To: 
>> <Appointment.c26b5086-af7a-11e8-91be-b3acf41bfd87 at example.com>
>> References: 
>> <Appointment.c26b5086-af7a-11e8-91be-b3acf41bfd87 at example.com>
>> Subject: Appointment changed: ...
>
> Again, the `Message-ID` is fine. The only requirement is that two 
> different messages should never have the same `Message-ID`.
>
>> Several mail clients tie these two messages together into a thread, 
>> but MailMate does not. Is this configurable? Is this a bug?
>
> It's not a bug. MailMate threading is based on the headers above and 
> the non-existing root messages means that MailMate cannot display 
> these messages as children of the same message.
>
> It's also not configurable, but that's something which is still not on 
> my list. Usually, other email clients would group emails based on the 
> subject, but in this case that appears to not be sufficient. In this 
> case they should be grouped because they refer to the same 
> non-existing message (which I still think is weird). I'll make a note 
> of this special case.
>
>> To be clear, there is no actual message with the ID referred to in 
>> In-Reply-To and References.
>
> I would claim that is a bug, but that's not something I can do 
> anything about (other than trying to work around it when threading is 
> more flexible).

The THREAD=REFERENCES algorithm in RFC 5256 handles this case (by using 
a dummy message in the thread tree). This scenario also happens if the 
thread's root message is expunged and there are two messages with 
In-Reply-To/References to only that root message. I think a threading 
algorithm is better if it handles this case as users expect.

Whether the mail generator has a bug depends on whether it's considered 
valid to assign a 'Message-ID' to a Calendar event and refer to that 
Message-ID in email messages related to that event. The standards don't 
explicitly permit that, but it seems like a reasonable behavior.

		- Chris