Version: 3.5.1-0.3-fc4 (using KDE KDE 3.5.1) Installed from: Fedora RPMs OS: Linux While browsing a mailing list archive with konquereror, i wanted to reply to one mail => i click the "reply to the author": mailto:smith@example.com?In-Reply-To=200504170053.12345.smith%40example.com&Subject=%5Bexample-devel%5D%20multi-board%20branch (i can give you the real adress, i changed the name and id of the mail) => kmail is open with a correct "To" field, _BUT_ it does not contain the "in-reply-to" => the mail-thread is broken which is very sad :( I think there is a bug, i can't believe this feature lacks to so nice KDE ;-) RH FC4 konqueror 3.5.1-0.3.fc4 kmail 1.9.1 kde-i18n-French-3.5.1-0.1.fc4 LANG=fr_FR.UTF-8 Best Regards Alain
I don't think KMail accepts In-Reply-To.
Kmail does understand 'in-reply-to' field, and use it to sort mail by thread. I googled and triple checked this, before thinking to just read all the headers ;-)
I meant: I don't think KMail accepts In-Reply-To in the mailto: URI. I know it understands them to sort messages by thread.
KMail doesn't have an option to set In-Reply-To from the command-line. Even if it did, KToolInvocation::invokeMailer does not support passing in arbitrary headers. Even if it did, kmailservice will not decode arbitrary headers from the URI.
This feature is VERY important and is part of the RFC. It is impossible to teach a correct use of mail-archive and maill_thread without this feature, so i must use thunderbird instead for my teachings (and this causes other problems...)
I think that full implementation of mail protocol is much more important than anything else.
http://www.faqs.org/rfcs/rfc2368.html does indeed explicitely contain the following example: An interesting use of your mailto URL is when browsing archives of messages. Each browsed message might contain a mailto URL like: <mailto:foobar@example.com?In-Reply-To=%3c3469A91.D10AF4C@example.com> I guess we should extend invokeMailer and kmailservice and kmail to support arbitrary headers or at least some more useful headers. I'm wondering where we should decide which headers to use and which to ignore. In invokeMailer? Or should we delegate this to the invoked mail client? Should we probably (optionally) pass the complete mailto: link to the mail client and let the mail client decide what to make out of it?
People should learn to use mail thread correctly too ;) Indeed incredible that RFC is not fully implemented. / John
Is there a workaround for this to allow manually setting In-Reply-To?
1/ This still does not work with Konqueror 4.3.2 (KDE 4.3.2) + Kmail 1.12.2 2/ clicking on url given in #7 make kmail crypting the message. something need to be done.
SVN commit 1041880 by tnyblom: Change parseMailtoUrl() to return a QMap containing all fields. This way we can support arbitrary fields in mailto urls. This support needs further work as this commit only fixes this function, the use of this new functionality is left for later. CCBUG: 122684 M +8 -9 kmcommands.cpp M +9 -9 kmkernel.cpp M +5 -6 stringutil.cpp M +3 -3 stringutil.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1041880
SVN commit 1042416 by tnyblom: Add ability to enterpret "In-Reply-To" header in mailto urls. BUG: 122684 M +2 -1 kmkernel.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1042416
Please accept my honest thanks for this feature. Looking forward to KDE 4.4.
SVN commit 1045765 by tnyblom: Backport r1041880,1042416 by tnyblom from trunk to the 4.3 branch: Change parseMailtoUrl() to return a QMap containing all fields. This way we can support arbitrary fields in mailto urls. This support needs further work as this commit only fixes this function, the use of this new functionality is left for later. CCBUG: 122684 ------------------------------------------------------------------------ r1042416 | tnyblom | 2009-10-29 20:09:26 +0100 (tor, 29 okt 2009) | 4 lines Add ability to enterpret "In-Reply-To" header in mailto urls. CCBUG: 122684 M +8 -9 kmcommands.cpp M +11 -10 kmkernel.cpp M +5 -6 stringutil.cpp M +3 -3 stringutil.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1045765