Hi Mark,

--On Friday, January 10, 2003 8:38 PM -0800 Mark Crispin <[EMAIL PROTECTED]> wrote:

|> Are you saying that there are mailboxes that will not be correctly
|> threaded in this case?
|>
|> Or do you not want to get rid of THREAD=REFERENCES because of widespread
|> deployment?
|
| Yes to both of the above.

I think what we need here is a compromise between the two extremes that we have: grouping by subject and only use 2822 headers. The current algorithm breaks when you have two distinct threads that have the same subject. I often get messages from colleagues that just say 'Update' in the subject, or online order confirmations that just say 'Your Order Confirmation' (no order number). These currently all get grouped together and this is the root of my real annoyance, because a message I got yesterday could be incorrectly grouped with one sent a year ago. I've had complaints from users about this in the sixteen months we've had thread support deployed.

Having said that, the current algorithm does work reasonably well when there is a thread with a unique subject that is broken (2822-wise) because there are still many deployed clients that don't do 2822 references headers properly, and it would be nice to preserve the subject grouping in those cases.

What I propose is to tweak the current algorithm to fix the first case whilst still allowing the second case to work. This could be a simple matter of spotting the fact that there are two distinct 'root' messages (i.e. messages that have the same 'original' as opposed to 'extracted' subject that does not contain any Re/fwd/[...] etc artifacts). Those root messages should not be grouped together. Then it is a matter of deciding how to group replies that do not have proper 2822 references headers to those roots in such a way that the proper replies go with the appropriate root. The simplest solution is to apply a grouping of replies based on date sent. i.e. all replies sent before the second root message are grouped with the first, and all replies sent after the second root message, are grouped with the second root. This could mean that legitimate replies to the first root end up under the second one, but I don't believe this is any worse than the current position where the roots and all replies get grouped together. Note that replies that have the proper 2822 headers will always appear under the correct root.

This change would require significant reworking of step (5) in the current algorithm and would lead to more complexity there, but I think it is worth it to provide a reasonable compromise. This should probably be done as a separate THREAD=XXX option.

--
Cyrus Daboo

Reply via email to