A large part of the problem is that some people think that
(a) Reply-To specifies the complete list of recipients that the
author thinks should receive replies while other people think
that>
(b) Reply-To specifies a list of recipients to be used instead of
the From address when directing replies.
I'd argue that the proper function is (a) but the reality is (b).
My understanding is the opposite. RFC 2822 seems to me to imply that
the Reply-To address is a substitute for the From address - i.e.(b).
I would argue that RFC 2822 propagated the error in RFC 822. But it's
pretty much irrelevant now, because (b) is the widespread behavior.
Mail-Followup-To seems to fit the bill.
One of my concerns with MFT is that it's being promoted and used as a
way to suppress some kinds of duplicate copies of replies. There's a
conflict between using a field like this to suppress duplicate copies
and using the same field to indicate whether the author thinks
replies should go to somewhere besides "everyone who received this
message":
MFT tells where replies are to be sent in the case of a Reply-to-All
(or maybe a Reply-to-List if avaiable). Its chief merit is that it has
the flexibility to fulfil both the roles you mention
As far as I can tell, that's not a feature, it's a bug.
- The recipient's user interface needs to act differently in these
two cases - in the first case it's just a normal "reply all" since
everybody is getting a copy of the message. In the second case the
replier needs to be aware that the reply is going to a different set
of recipients than is normal, and it seems appropriate for the MUA to
provide some kind of alert to that effect.
No problem with an alert, provided I have the option to configure it
off.
One of the problems with having alerts is that if they happen too often,
they'll annoy the user but to no useful effect. i.e. they'll still
annoy one part of his brain but he'll just accept the default action
without thinking about it. Which is worse than not having alerts.
That's part of why using MFT for both duplicate suppression and reply
delegation seems like a problem to me - you don't want the alerts for
duplicate suppression (since the message is still going to everyone the
replier thought it should go to) but you might want them for reply
delegation (when the message is going to some other set of recipients).
But there's another wrinkle in that the ability to redirect replies is
arguably a security risk.[*] Say an attacker forges a message from
someone's boss that tells its recipient to do something costly and
irreversible. If the recipient replies to confirm the message, the boss
will see the reply and may have a chance to stop the action. But if the
attacker also sets reply-to to point to somewhere else, and the
recipient doesn't notice, then the boss won't see the reply. From that
point-of-view you might like to have an alert any time replies are
redirected from the default, or you might like to insist that such
replies require explicit confirmation by the replier. And again, that
set of conditions might happen so often that the alerts will be worse
than useless.
So I'm trying to understand whether there is a set of conditions in
which the alerts would actually be helpful.
Keith
[*] and yes, it's a risk we've accepted for ~23 years, but that doesn't
mean it's not worth considering if we're going to change how replies
work.