It's an RFC822 header and lots of MUAs use it. Some, like Pine, use it exclusively when replying to a message. Since Mozilla doesn't support it, any reply to a message from a Pine user prevents Mozilla from properly threading. I think failing to support this header is a bug.

Actually, it's an enhancement request, but we track those in bugzilla too. Reassigning to bienvenu since he's The Man for threading. David, there's a thread on In-Reply-To usage conventions here: news://news.mozilla.org/375D0CEC.43C710C3%40cybernex.net

Well, we'll see what we can do.

There's an even earlier thread starting at news://news.mozilla.org/6A228B1.1A9E7390@cybernex.net . If you saw the mess it made of the linux-kernel mailing list, you'd agree it's a bug.

correcting platform to All since if addressed, this will affect all platforms.

I don't think we can do this for news, since the in-reply-to header is not part of xover data, but we can try to do it for POP3 and IMAP.

It's an RFC822 header so it's only for mail. It's also optional. I'm not suggesting emitting one only reading and using it if it's there.

moving to m16

adding feature to summary. We hae to do this.

fix checked in. you will need to delete the .msf file if you want existing messages with in-reply-to headers to get rethreaded.

I'm fairly sure that In-Reply-To and References are not mutually exclusive in email so using one or the other but not both may not work. I'll gather some data later. Also, you are prepared to handle garbage in either header, right?

It's fine if an email uses both; I'll just use the REFERENCES header. If an email generates an incorrect REFERENCES header (i.e., w/o the message-id of the replied-to message) that seems like a bug in the original email client. I'm neither more or less able to handle garbage in either header than I was before. We don't crash if we can't find the message id, if that's what you mean. But neither do I fall back on the in-reply-to header if the references header is invalid. In the messages I looked at (probably from Pine), there was an In-Reply-To header and no references header. Which is what caused all the problems in the first place, if I understand correctly.

RFC822 allows non-message-id text in both the In-Reply-To and References headers. It actually happens in practice. For best results, it is necessary in email (not news, of course) to extract message ids from the headers. If you are already doing that, then there should be no problem. Pine turns out to be rather well-behaved in the sense that it only includes message ids in its i-r-t header. Other MUAs aren't. I have some data from my mailing lists which shows all sorts of variety. It's available if you want it.

tenthumbs - fixed for you?

I still get weird threading with with In-Reply-To headers, which is related to giving |References| the preference, IIRC. Will investigate.

yes, we've discussed that on the newsgroup. I doubt I'm going to have any time to do more than what I've done. If anyone wants, they can open a different bug for giving the references header preference and not throwing out invalid references.

Certainly greatly improved but I see weird threading also. I found at least one mailer that does this: X-Mailer: exmh version 2.1.1 (devel) In-Reply-To: <20000531145430.B32749@lug-owl.de> References: <20000531145430.B32749@lug-owl.de> <20000530211154.A1909@yahoo.com> <Pine.GSO.4.21.0005310346520.12622-100000@khan.acc.umu.se> The message content indicates that the message should thread against the In-Reply-To header but Mozilla threads against the last id in References. Has another bug been filed on this?

no, that was a choice I made to prefer the references header. I've got to choose one to prefer, and if I chose to prefer the in-reply-to-header, I'm sure someone would come up with a case where I should have prefered the references header.

You're absolutely right that there's no way to win. The only question is how many people will complain. Maybe this should be a pref.

the problem with making it a pref is that you could get mail from clients that are broken in either way, so the pref would just be saying which brokeness you want to favor, which seems of limited value.

Sure, but at least you could find the setting that works best for you. Empower the user and all that stuff.

This bug was fixed for original scenario in April of 2000. The reporter commented in June of 2000 that this works better. There was some discussion as to what else should be fixed and was suggested new bugs be logged for specific outstanding issues. Continued discussion about what is and what should be ended June 8 2000 without any resolve. I will verify this as fixed per the 1st fix. If the reporter or any others commenting logged new bugs for specific outstanding issues, please note them in this bug.