I want at least five reply options:
"Reply" (uses Reply-To header, falls back to From
header)
"Reply to author" (uses From header)
"Reply to sender" (used Sender header, falls back to From
header)
"Reply to all" (uses all possible addresses, lets me
edit the list)
"Followup" (somehow figures out how to send to mailing
list)
I'm curious - when would you use "Reply" or "Reply to sender"? or
to ask the question another way, what assumptions are you making
about how "Reply-to" and "Sender" fields are used that would cause
you to want those functions?
The Reply-To header says where the author suggests that ordinary
replies should go. "Ordinary" replies are whatever the author thinks
will be the most common type of reply to this particular message.
I think this illustrates the "wrong split" I was talking about in an
earlier message when I wrote:
I think the current typical user interface has the wrong split
between what the author of a message specifies and what the
recipient specifies when he's composing a reply.
The recipient typically doesn't have a button that implements "ordinary
reply" - he has two buttons which implement
"To+Cc+(Reply-to?Reply-to:From)"
(typically labeled "reply all") and
"Reply-to?Reply-to:From"
(typically labeled "reply"). Neither function does what is needed, and
both functions are mislabeled in that they don't always do what the user
thinks they will do. And because reply-to affects both of them "reply
all" the way it does, its applicability is greatly reduced.
My list would be similar to yours but I would want
a) "reply to author(s)"
This would go to the From address(es).
b) "reply to originator"
This would probably go to the Return-Path - though strictly speaking,
that's the address where errors should go. We don't really have an
address for the originator. Sender is effectively deprecated - it's
far more widely misused (by lists) than used correctly. We probably
need some kind of address for the originator to be added by the MSP -
though getting the right balance between tracability and anonymity
is hard.
c) "reply"
This would be like your "ordinary reply", I think - it would do the
right thing in the vast majority of cases. If defined in terms of
today's email header fields it would be something like
Reply-to?Reply-to:(To+Cc+From)
But it might be the case that some new fields should be defined
to make this work better.
Basically, ordinary reply should be "reply to all" with the following
exceptions:
- (maybe) the author should be able to specify alternate addresses
I say "maybe" because while useful for delegation, experience seems
to suggest that this is a rare case. I wonder if it's worth
the additional complexity it requires, especially if (as I am
starting to believe) overloading Reply-to to do both that _and_
excluding unwanted recipients is a bad idea.
- it should exclude certain recipients who should not get replies.
One kind of recipient who should not get replies is an author who has
said "don't reply to me if you're also replying to any of these
addresses".
Another kind of recipient who should not get replies is a recipient who
the author has said "don't send replies to this recipient".
Another kind of recipient who should not get replies is a list that has
said "don't reply to this list". Though I don't see any way to
implement that in the recipients' user agents for recipients who don't
get the message from the list.
Even if "reply" is defined as
Reply-to?Reply-to:(To+Cc+From)
it doesn't suffice for all cases. For instance, say a message is sent
to recipients A, B, X, and Y where X and Y are mailing lists, A is a
member of list X, and B is a member of list Y. Let's further say that A
doesn't wish to be copied on messages to list X and B doesn't wish to be
copied on messages to list Y.
Perhaps the author of the message is aware of A and B's preferences so
he sets reply-to to X and Y only. But if the person sending the reply
decides that his reply is not appropriate for list Y, he has no way of
knowing whether he should copy B. The reply-to field doesn't tell the
recipient whether B wants copies of messages sent to Y, it only says
what to do under "ordinary" circumstances.
Now maybe that's an exceptional case which isn't worth worrying about,
but it illustrates that "wrong split". Reply-to doesn't tell the
recipient or the recipient's UA _why_ certain addresses should or
should not see replies - it only tells what to do in the ordinary
case. In any case except the one the author deems "ordinary", the
UA will often do the wrong thing by default, and the recipient is
left to guess.
--
In all cases I think the person composing the reply should be able
to (a) see the original addresses and (b) override the default
reply recipient list - no matter which kind of reply is chosen.
--
Another thing I'd want a UA to do is to be able to change "reply modes"
during and after message composition, rather than having to choose
the reply mode before message composition. There are two reasons for
this. First, I'm often finding after composing a message that I
want to make it public (if I originally hit "reply") or private
(if I originally hit "reply all"). Second, I think that if UAs had
buttons or a menu at the top of a compose window that let the user
select which kind of reply to send (and provided immediate feedback
about how this changed the recipient list) it would help the recipient
make appropriate choices about who should and should not receive replies.
I also think that such an interface would make it easier for UAs to
be more flexible about replies. Right now for the typical GUI there's
a limit on screen real estate - five reply buttons is just too many,
and if some of the least frequently used functions are placed elsewhere
they just won't be used. Putting the functionality in a compose window
(again with immediate feedback) would make it reasonable to give the
user more choices. Also, it puts the functionality where it belongs -
since choosing a recipient list is very much part of composing a message.
Keith