On Thu, Aug 27, 2026 at 10:58 +0800, Kevin J. McCarthy wrote:
This reuses the existing Mutt functions to set references, which means
they are like reply references: the full list. It clears out the
In-Reply-To header afterwards, because I personally feel like that
header is a step too far for a "forward".
RFC 5322 says both headers are for replies. Treating In-Reply-To: as
for replies, and References: as for something else, goes against that RFC.
<https://www.rfc-editor.org/info/rfc5322/#section-3.6.4>
The "In-Reply-To:" and "References:" fields are used when
creating a reply to a message. They hold the message
identifier of the original message and the message
identifiers of other messages (for example, in the case of a
reply to a message that was itself a reply). The
"In-Reply-To:" field may be used to identify the message (or
messages) to which the new message is a reply, while the
"References:" field may be used to identify a "thread" of
conversation.
There is code to support taggged messages, however the Mutt
code (at least in the index and pager) on purpose removes References
that are combined from two different "parents".
Because that would be invalid. A mail thread is a tree; References:
describes a path through a tree, like a pathname of a file. In a tree,
a node can only have one parent. Message threads, being trees, do not
allow multiple parents.
A message with two parents would need two paths, and References: cannot
express that. References: can only express one path.
RFC 5322:
Note: Some implementations parse the "References:" field to
display the "thread of the discussion". These
implementations assume that each new message is a reply to a
single parent and hence that they can walk backwards through
the "References:" field to find the parent of each message
listed there. Therefore, trying to form a "References:"
field for a reply that has multiple parents is discouraged;
how to do so is not defined in this document.
I guess that says "some implementations" because some don't interpret
References: at all, just ignore it. Far as I know, nothing interprets
References: as anything other than a path through a thread.
If the attachment menu creates References: for multiple parents, that
sounds like a bug. What does it create, exactly? How can it work?
In-Reply-To: can say that a message has multiple parents, because it is
a list of just parents, not paths.
Mutt can create a multiple In-Reply-To: like that (with tagged
messages, as you said). When displaying a message that has multiple
parents, Mutt understandably shows the message as not part of any thread.
