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

Alejandro Colomar via Mutt-dev <[email protected]> Thu, 27 Aug 2026 12:49:38 +0200
Newsgroups	gmane.mail.mutt.devel
Message-ID	<apAQ3MQUa85SDV86@devuan>
Hi Kurt,

> Date: 2026-08-27 00:58:42-0400
> From: Kurt Hackenberg <[email protected]>
>
> 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.

This is allowed.  In-Reply-To can have more than one message IDs.
Quoting RFC 5322:

	The "References:" and "In-Reply-To:" fields each contain one or
	more unique message identifiers, optionally separated by CFWS.

I have personally used this one or two times, when replying to more than
one message at once.  I suspect that --since I did it manually--, I got
the References from only one of them, but I don't remember.

Out of curiosity, I've grepped for all mails that have something like
that in my maildir:

alx@devuan:~/mail$ grep -rl '^In-Reply-To: .*> <'
gmail/alx.manpages/[Gmail]/All Mail/cur/1735409718.6658_19886.devuan,U=6977:2,RS
gmail/alx.manpages/INBOX/cur/1735409207.6658_11875.devuan,U=4331:2,RS

Both are the same mail.  These are from when I was using gmail, which
duplicates mails into INBOX and All Mail.

	From: Matthew House <[email protected]>
	To: Alejandro Colomar <[email protected]>
	Cc: linux-man <[email protected]>,
		Zack Weinberg <[email protected]>,
		Lee Griffiths <[email protected]>
	Subject: Re: [PATCH] sscanf.3: Remove term 'deprecated', and expand BUGS
	Date: Wed,  6 Dec 2023 15:45:19 -0500
	Message-ID: <[email protected]>
	In-Reply-To: <ZXCjD5dP-jaUpeER@debian> <ZXDXBngCYG11NsMZ@debian>
	References: <[email protected]> <ZXCjD5dP-jaUpeER@debian> <[email protected]> <ZXDXBngCYG11NsMZ@debian>

It seems the ones I wrote have been lost.  Anyway, this one is useful,
since we can inspect it.

> 
> 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.

Interesting!

> 
> 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.

This seems in direct contradiction of a paragraph of yours I've replied
to above.  This one is more correct.

> Mutt can create a multiple In-Reply-To: like that (with tagged messages, as
> you said).

Interesting!  I had done that manually, but never expected it could
happen non-manually.

> When displaying a message that has multiple parents, Mutt
> understandably shows the message as not part of any thread.

Hmmmm, this is weird.  Most often, those two parents are subthreads of
the same thread, and it would be better to just arbitrarily one than
none.

I've checked the message I have in my maildir from above, and it is
shown as part of the tree.

mutt(1):
	4224 rsF Dec 06 To linux-man@vg (4.4K) [PATCH] sscanf.3: Remove term 'deprecated', and expand BUGS
	4225  sF Dec 06 To linux-man@vg (5.1K) ├─>
	4226 r T Dec 06 Matthew House   (1.7K) │ └─>
	4227  sF Dec 06 To Matthew Hous (5.6K) │   └─>
	4228 r T Dec 06 Matthew House   (2.1K) │     └─>
	4229   T Dec 06 Matthew House   (0.3K) │       ├─>
	4230  sF Dec 06 To Matthew Hous (3.7K) │       └─>
	4231   T Dec 06 Lee Griffiths   ( 12K) └─>
	4232 r   Dec 07 Lee Griffiths   (5.2K)   └─>Fwd: [PATCH] sscanf.3: Remove term 'deprecated', and expand BUGS
	4233  sF Dec 09 To Lee Griffith (5.2K)     └─>

neomutt(1):
	4224 rs  Dec 06 Alejandro Colom (4.4K) [PATCH] sscanf.3: Remove term 'deprecated', and expand BUGS
	4225  s  Dec 06 Alejandro Colom (5.1K) ├─>
	4226 r   Dec 06 Matthew House   (1.7K) │ └─>
	4227  s  Dec 06 Alejandro Colom (5.6K) │   └─>
	4228 r   Dec 06 Matthew House   (2.1K) │     └─>                                                                                            
	4229     Dec 06 Matthew House   (0.3K) │       ├─>
	4230  s  Dec 06 Alejandro Colom (3.7K) │       └─>
	4231     Dec 06 Lee Griffiths   ( 12K) └─>
	4232 r   Dec 07 Lee Griffiths   (5.2K)   └─>Fwd: [PATCH] sscanf.3: Remove term 'deprecated', and expand BUGS
	4233  s  Dec 09 Alejandro Colom (5.2K)     └─>

Both mutt(1) and neomutt(1) seem to agree.

The message with two In-Reply-To header fields is 4228.
I'll write an equivalence of the header fields contents using numbers,
to help see how mutt(1) is behaving:

	IRT: 4225 4227
	Ref: 4224 4225 4226 4227

Naturally, the 'References' field is used to form the path, and even
though there are two "parents", the path shown in 'References' clearly
tells which is the "closest" parent for printing the tree.

Thus, I'd keep the 'References' of one of them (I'd use the longer one)
when there are two parents, to help mutt(1) form a tree.


Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es>
signature.asc (application/pgp-signature, 833 B)