Re: References in forwarded messages

Alejandro Colomar via Mutt-dev <[email protected]> Sun, 23 Aug 2026 18:39:55 +0200
Newsgroups	gmane.mail.mutt.devel
Message-ID	<aosdpTjiIglZ5lwb@devuan>
Hi John,

> Date: 2026-08-23 11:13:29-0400
> From: John Hawkinson <[email protected]>
>
> I am confused at the baseline request, and it seems like the thread is
> discussing *how* this should be implemented and not *whether* it should be.
> Huh?
> 
> On Fri, Aug 21, 2026 at 10:57 AM Alejandro Colomar via Mutt-dev <
> [email protected]> wrote:
> 
> > When I forward a message, I want to have it threaded under the original
> > mail.
> 
> 
> To be overly cute, "It's nice to want things."
> 
> What is the justification for this change?

Technically, the quote above is not the change, but the justification
itself.  It's weird to ask for a justification of the justification.

The proposed change was:

	What do you think of adding a 'References' header field to forwarded
	mails?

As to why do I want it threaded...  I want them together, to make it
easier to find all of the related mails.  I thought this would be
obvious, but just in case, I say it now.

> Is it for your personal benefit as the sender, or is for the perceived
> benefit of the recipients of your forwarded messages? Or something else?

I think the justification seems clear about this.  It's for my personal
benefit as a sender.  I don't see any particular benefit in the receiver
(unless I also bounce the original mail, but that's unusual to do if I
 also send a forwarded mail).

> Is there any standards-based support for it?

There's no support nor restriction from standards.

> Is there any non-standards based real-world practice implemented by others
> that do this?

Yes, there is.  thunderbird(1) adds both 'References' and 'In-Reply-To'.
I didn't check any other clients.

> It's not great for email clients to innovate in how they manage their
> interactions with the rest of the email ecosystem because many email users
> and clients have expectations in what they receive, and breaking those
> expectations can lead to pain and suffering.

As you can see, we wouldn't be innovating.  At least one client (but
that's all I tested, so there could be many more) already does this.

> > I know some people are against this (especially the In-Reply-To one, since
> > it's not a reply, technically).
> 
> (I am troubled when we use the word "technically" in a discussion without
> specifying the technical basis being referred to, because I find it clouds
> the discussion and makes it vague what people's positions are. Do we mean
> "technically" in the RFC5322 sense?

Yes, we mean "technically" in the RFC5322 sense.  In that sense,
a forwarded mail is not a "reply message".

> Do we agree that RFC5322 should govern
> what we do here?)

Yes.

RFC5322 says that reply messages SHOULD have "In-Reply-To:" and
"References:" fields as appropriate.

However, it doesn't anywhere say that other messages shouldn't have
them.  Thus, my proposed extension would be conforming (not required,
not even suggested, but technically conforming).

> But indeed, a forwarded email is absolutely not a reply, and that is
> arguably the whole point. Not a reply, should not be treated like a reply.

That's precisely why I suggested using only 'References' but not
'In-Reply-To'.  That's because the message _refers_ to the original
message, even though it doesn't _reply_ to it.

> It seems to me that this is the kind of feature that you can locally add to
> a programmatically controlled email client that can be configured with a
> scripting language like Lua or Elisp or Guile (or python), and then you
> could, I guess, publish that configuration/script so it would be available
> to others who share your preference. Except that, absent some justification
> not articulated, it seems like a *bad* feature — a *misfeature* — that more
> people should not be encouraged to do, because then people will start to
> misunderstand what a reply is and what a forwarded message is, and the
> blurring of that distinction seems like it leads to problems and broken
> privacy boundaries and the like.
> 
> And of course, when we talk about a scriptable email client, that is not
> mutt. I hear neomutt supports Lua, which makes me wonder why that's not
> what you're pursuing. (Of course, you can bolt on your own features to mutt
> by scripting your editor or by changing mutt's C codebase or using wrapper
> scripts around sendmail/whatever and whatnot.)

This is easy to solve in mutt(1)'s source code, but not so easy
scripting.  Thanks, but no.

> As for whether this should be always-on versus an option, it seems clear to
> me that it is wholly inappropriate as a mandatory behavior change (as Kevin
> says, "heresy")

Okay, let's do an option then.

> and arguably does not even belong as an optional feature.
> Or if it does, we haven't heard any explanation as to why…or I missed it
> entirely!

It was in the exact line you quoted, plus a few that you didn't quote.


Have a lovely day!
Alex

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