Reformatted excerpts from Tero Tilus's message of 2009-12-29: > For what I know you might trigger this by replying to many messages at > once and thus having a list of ids in-reply-to header (in whatever > order of course, rfc doesn't require any particular order) instead of > one. Then when you reply to this message using MUA that is bold > enough to try to form References: with the standard in-reply-to + > my-id method even if RFC 2822 says "trying to form a References: field > for a reply that has multiple parents is discouraged and how to do so > is not defined in this document". You end up having References: which > has bunch of (thread-wise) random ids in random order instead of the > rfc-specified original, reply, replytoreply, etc. chain of ids.
It's worth reading the top bit of http://www.jwz.org/doc/threading.html for what In-reply-to: and References: look like in practice. (Basically: a mess, and the references: header in particular can be truncated in any way that any MUA feels is reasonable.) The threading used by the Ferret indexer is a pretty faithful reproduction of the algorithm described on that page. I'm not that familiar with the one used by the Xapian index, but a cursory examination suggests it's a little more fragile. -- William <wmorgan-...@masanjin.net> _______________________________________________ Sup-devel mailing list Sup-devel@rubyforge.org http://rubyforge.org/mailman/listinfo/sup-devel
