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
Description: PGP signature
