On Tue, 15 Dec 2009 16:54:20 +0100, Marten Veldthuis <mar...@veldthuis.com> 
> On Thu, 10 Dec 2009 13:30:13 -0800, Carl Worth <cwo...@cworth.org> wrote:
> > But I still have a hard time justifying user operations to manipulate
> > threading. The whole point of threading is to make it faster to process
> > and read messages. But manual operations like joining and splitting
> > threads seem like the user just doing more work, and that *after* having
> > read the messages. So that seems mostly backwards to me.
> By the way, Outlook & Exchange suck (or at least some versions do), and
> don't seem to generate In-Reply-To and References: headers. Just got a
> mail which prompted me to write this mail. I'd really like to be able to
> join messages in a case like this.

It's actually worse than that.  I was looking into why some of my
threads weren't coalescing.  Some of it seems to be a very difficult bug
DB that doesn't use identical Message-ID's to refer to the parent bug
mail.  I don't know how that works at all.  Sometimes it uses the same
Message-ID, but sometimes it changes a number in the ID.

However, this isn't the worst news, because I work with a lot of
Exchange users, and I noticed that their mail was also refusing to

I was looking at the message bodies, and they led me to these links
about mail processing.

The problem identified:

How to read it, or how Exchange goes its own way:

With a fairly loose understanding of how notmuch detects threads, and
how much information it places in the Xapian database (only the
msg-id?), I can't suggest much of the how.

But I would like to propose that we consider handling the Exchange
non-standard threading method as well as the RFC822 threading in the



notmuch mailing list

Reply via email to