I don't think that's true at all. The way they tend to be implemented,
these extra header fields just make things more confusing.
Well the way(s) in which Reply-To is implemented certainly have that
effect, as you and others have pointed out.
Which merely argues for a new header with a carefully written semantics
and intended method of use.
perhaps. But the semantics and intended method are a lot harder to
define and get right than the syntax of the header field.
That's not sufficient. At a minimum, the replier needs to be able to
edit the recipient fields AND see the fields of the subject message
while he's composing the reply. More realistically, the replier needs
to
a) Know (probably via an alert of some kind) when the sender of the
subject message requested that replies go to some non-default set of
recipients
I have no objection to alerts provided I don't have to give extra clicks
to turn them off, or if I can configure them off.
They should be designed so that it is rarely necessary to turn them off.
For instance, pop-up dialog boxes suck for this. Just put some text
with a yellow background at the top of the compose pane. e.g.
"Note: the author requested that replies go to xxx(_at_)yyy(_dot_)zzz"
or perhaps
"Note: the author requested that he not be copied on replies"
Then let the user click on a button to accept that request, if he so
chooses. I don't think the requests should be accepted by default.
(now if you want the alert to have a check box like:
[ ] in the future, honor similar requests from this sender without asking
that might be very useful)
b) Be able to easily select from "reply to author" "reply to all" and
"reply to where the author of the subject message recommended"
(in addition to being able to add or delete recipients from this list)
_at any time before sending the reply_
Yes, that last one is what the "Reply-to-List" button would do
maybe, maybe not. "reply to where the list recommended" might be an
additional option.
And if you design an MUA only for the "average user", you
degrade everyone's capabilities. Because even the average user
sometimes needs capabilities beyond his "average" use.
No, you provide some extra hoops for the expert user to jump through if he
wants to do something different than the "average" user.
the thing to do is to make it easy for any user to do the right thing,
not to penalize people who want to do the right thing by making them
jump through extra hoops.
Keith