Re: [PATCH] wip: Add forward-message-refs function.

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.