Keith Moore wrote:
If the only thing anyone wants to do with it is
suppress duplicates that are caused by mailing lists, it more-or-less
works. But that's not the only reason people want to redirect replies.
And when the header gets overloaded for multiple purposes, the recipient
has no way to sort this out. Why does this header contain what it does?
Is it because the sender wants to eliminate duplicates, or because
the sender thinks that discussion should naturally take place on a
particular list (and the recipient might disagree).
Regardless of the original message author's motivations, if he
indicates that default responses are recommended to go to some
set of mailboxes (which the recipient can of course override),
a responding recipient can choose to comply with that recommendation
or override it (for whatever reasons).
Also, it seems like overloading is at the heart of the problems
with Reply-To, so I'd like us to not go down that path again.
Which problems, specifically?
I think we are in agreement that user agents should uniformly
implement two reply functions (along with being able to edit the
reply address list);
- reply to author
- wide reply (more or less "reply to everyone")
The first should go to From,
OK...
though for the sake of a clean transition
it might be acceptable for recipient MUAs to honor Reply-To. But use
of Reply-to in new messages should be discouraged.
The second should default to From+To+Cc.
But Keith, that won't work for the specific case of eliminating
duplicates...
But if we really want to have recipients' MUAs suppress duplicates when
composing replies, we should do it differently than with the
Wide-Reply-To or Mail-Followup-To field. For instance, we could have a
field of the form
Suppress-Duplicate: address1, [address2, address3, ... ]
which says that if a reply is being sent to _any_ of address1, address1,
etc., don't send a separate copy to the From address.
That has the same lack of traction that affects Wide-Reply-To and
Mail-Followup-To -- every UA has to be modified for it to work.
Though MTAs shouldn't munge address fields, it also requires MTAs
that do so to be aware of the field and its syntax and semantics
and to modify it in a manner consistent with any modifications to
other address fields (and envelope addresses).