You are correct that Reply-To is not the solution to this problem,
but the fact that Reply-To is better reserved for use by authors is
NOT "exactly why" Reply-To is not the solution to the problem. The
reason that Reply-To is not the solution to the problem is that the
decision about where a reply goes needs to be made by the person
composing the reply, and NO set of header fields, no matter how you
define them, can make this decision for that person.
But nobody has ever suggested that the person composing the reply should
not have the final say.
Actually, that's not true either. But I don't think this view is widely held,
and to name names would be to invite digression into a pointless discussion
about who said what and what he meant by that. Let's not go there.
But if you want to provide hoops and popups to ask the user
"The original sender wants you to send your reply to X, but you should
should be aware that you have a God given right to to send it somewhere
else, and you are advised to consider your options carefully before
just hitting 'send'."
then the 95% of people who are happy to just hit 'send' will be mightily
pissed off.
Well, duh. If you _try_ to make an annoying UI, of course it's going to
piss people off. It's certainly possible to botch this UI so that it's
annoying
to the user, but it's not at all difficult to do well. Which is why I provided
(if you cared to read it) an example of how it could be done _without_ hoops
or popups and without excessive or condescending dialogue.
Currently, we have the Reply-To header, and the usual behaviour of MUAs is
to reply to that address when you hit 'send'.
Which - without a clear indication to the user that the result will be
surprising,
and without an easy way for the user to override that behavior - is thoroughly
broken.
All that is suggested is that there should be some further header(s) with
the same property, namely MUAs will reply to that address when you hit
'reply-to-list'.
Which is even more broken (i.e. more complex, harder to use correctly)
than the current behavior.
(well, actually it's not "all that is suggested" - it may be all _you_ are
suggesting at the moment but the number of harebrained ideas for fixing
reply is rather large.)
Both Reply-To and MFT/whatever are headers provided by the original sender
and/or the mailing list manager with the intent of influencing where
replies should be sent. The first is existing practice and the second is a
proposed future practice.
But experience indicates that existing practice is broken, so it's reasonable
to assume that further extensions along those lines will also be broken.
Also, there's a difference of opinion about whether MFT should be used
by lists. Not surprisingly, the same kind of brokenness that's been
been observed with the use of Reply-To by lists seems to occur when MFT
is used by lists.
But in both cases, it is reasonable to suppose that 95% of repliers will
just hit the proper key and accept the default behaviour.
Your characterization is overly simplistic and contradicted by experience.
- When faced with multiple reply buttons, people often fail to use the right
one even when they are aware of it. Since 9X% of the time people
hit one button, they tend to hit that button without thinking even for the
cases when it's not appropriate.
- People often end up wanting to change the recipient list of a reply
after they have started composing the text of a message, indicating that the
"push the right reply button before you compose" model is broken.
- Even when people hit the right button, (i.e. "reply to author" or
"reply all") the behavior of an MUA in the presence of reply-to or
other header fields is often surprising to the user, because these
fields are either difficult to notice or not displayed at all.
- Often this surprising behavior isn't noticed until after the message is
sent, when it's too late to change it.
- It's not as if 95% of repliers want to do the same thing in every case.
You need to look at a spectrum of repliers and what they want to do
with a spectrum of mail messages. It also should not be assumed that
the remaining 5% of cases (or however many cases) are insigifnicant.
Small mistakes in communications can have large consequences.
If you are complaining that you do not like such behaviour for MFT, then
logically wou must admit that you do not like it for Reply-To either. In
that case, your quarrel is with implementors of existing MUAs, and if you
want to start a campaign to have chem change their user interfaces, then
go ahead.
I have two goals:
1. to change the behavior of existing MUAs
2. to discourage further brain-damage in MUA and header field design
They're not mutually exclusive, and they're related.
But no way is your argument a valid objection to having another header, in
addition to Reply-To, whose behaviour is broadly similar to Reply-To.
Just in case it isn't clear, I have no objection to defining a new header field
which is set by lists (and only by lists), and which says in effect, "if you
want to reply to the list, use this address." However, without substantial
changes to the UIs of MUAs, such a field won't be terribly useful, and may
even be harmful if it produces less consistent behavior than at present.
Note that such a field is NOT the same as Mail-Followup-To, which was
intended to be set by message originators. Trying to equate the two
doesn't lend credibility to your arguments.
Keith