Bug 56553 - Support for threading with Microsofts Outlook/Exchange "Thread-Topic" and "Thread-Index" headers
Summary: Support for threading with Microsofts Outlook/Exchange "Thread-Topic" and "Th...
Status: REOPENED
Alias: None
Product: kmail2
Classification: Applications
Component: message list (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR wishlist
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-03-28 18:06 UTC by Nick Brown
Modified: 2012-08-24 11:42 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Brown 2003-03-28 18:06:34 UTC
Version:            (using KDE Devel)
Installed from:    Compiled sources

Outlook and exchange do not use the rfc optional headers, but instead use the proprietary headers "Thread-Topic:" and "Thread-Index:". Just about every mailer on earth uses the optional rfc headers as outlined at http://www.dsv.su.se/jpalme/ietf/message-threading.html including kmail. Kmail has recently gone one step further and added support for threading by subject which helps with such broken messages.
It truely would great if kmail where to add support for threading using these Microsoft headers, as they are increasingly common in mails. The  "Thread-Topic:" header is straight forward, but some kind of reverse engineering is probably needed with the "Thread-Index:" header as its probably undocumented.

I can provide examples of messages containing these headers if required.
Comment 1 Tom Emerson 2003-03-28 18:35:26 UTC
You say "they are increasingly common in mails" -- is this because other e-mail clients are falling 
for the "embrace, extend, exterminate" trap, or is the relative percentage of microsoft-based 
clients increasing? 
 
I can't help but think that "supporting" this non-rfc header is playing right into microsoft's hand -- 
they may be prepared to "drop" this overnight thus making everyone else's "client" look like it's 
broken [consider the possibility that they have some other header already defined -- outlook and 
exchange may already have the code in place to use the "new, as yet undocumented header" and 
simply have it "triggered" by receiving a message with that header.  Result: at the drop of a hat, 
Microsoft can force everyone that "complies" with their way of thinking into a re-write...] 
 
If it is the second case, (that the relative number of outlook/exchange clients & servers is 
increasing,) well, dunno what to say to that... 
 
Comment 2 Nick Brown 2003-03-28 23:58:15 UTC
I think its very much the second case. Outlook/exchange is the only client that I 
know uses these headers. I don't think anyone has of yet reverse engineered the 
"Thread-Index" header and thus been able to use them. 
Certainly no linux client I can find uses them (i've raised wishlist bug reports with 
several to add support, as I'm doing with kmail). I've after asking around, to other 
windows client seem to use them either. (But then "most" windows users use 
outlook/exchange) 
 
It is rather annoying that outlook/exchange does not use the rfc optional headers for 
threading as just about every other client in exsistance does, but given its 
pervasivness, supporting these prioprity headers seem like the only option. (given 
the unlikelyness of microsoft falling into line and using the rfc optional headers.)  
Comment 3 Myriam Schweingruber 2012-08-18 08:28:32 UTC
Thank you for your feature request. Kmail1 is currently unmaintained so we are closing all wishes. Please feel free to reopen a feature request for Kmail2 if it has not already been implemented.
Thank you for your understanding.
Comment 4 Luigi Toscano 2012-08-19 01:04:18 UTC
Instead of creating a new feature request, please confirm here if the wishlist is still valid for kmail2.
Comment 5 Bernd Oliver Sünderhauf 2012-08-24 11:08:35 UTC
Still applies to kmail2, component: message list.
Comment 6 Christoph Feck 2012-08-24 11:42:21 UTC
Thanks for the update.