On Sat September 4 2004 20:20, Keith Moore wrote:
No, the assumption I'm making is that the message author(s) know(s)
where he wants plain replies (as opposed to reply-to-all) to go and is
capable of setting Reply-To accordingly.
Perhaps, but that's nearly useless, as there's no way to encourage
users to use "plain reply".
There's no difference if the only mailbox in To+Cc is the list mailbox
in the situation under discussion -- and that is likely to be the usual
case in that situation.
As it's implemented today, Reply-to is little more than a surrogate
From. Actually, we would probably be better off without it
I strongly disagree. It is often necessary to specify that replies should
go elsewhere than the mailbox(es) in the From field:
1. a message sent from work, responses desired at home or vice versa
2. multiple authors, responses should go to one author
3. the case in point, message sent from an individual, responses should
go to a list mailbox
4. delegation
etc.
Now you might say "forge From" instead of using Reply-To, but that
won't work with some times of authentication and spam filtering.
Now it happens to be the case that most MUAs have two types of reply
functions corresponding to the two cases.
Both of which do the wrong thing. "plain reply" should probably be
(and be labeled) "reply to author".
Nothing prevents MUA authors from implementing that -- indeed, pine
can be configured so, and Kmail provides a working "Reply to Author"
in addition to other types of responses.
The other "reply" (call it "group
reply") should probably have some way of excluding recipients that, for
whatever reason, should not receive replies.
Are you suggesting a field that modifies the interpretation of a different
field? I thought you were opposed to that.
It might be the case that
"group reply" should be the default, though this would probably be too
big a departure from existing behavior.
We probably ought not to specify such details of UA design as which type
of response is the default.
No. regardless of how Reply-To is set, anyone can easily copy-and-paste
an address, or call it up from an address book, etc.
For most of the MUAs I've seen, "easily" is a huge stretch. First, the
recipient composing the reply has to notice that reply-to is set. this
is difficult because few MUAs bother to provide any kind of alert to
this effect.
Mozilla, Kmail, Evolution show Reply-To. Probably many others as
well.
Many MUAs don't even display reply-to fields when viewing
a message.
The MUAs mentioned above, as well as several others, do. In any
event, when a response is being composed, surely the recipient(s)
is/are displayed in any sensible MUA -- advice to MUA authors
comes into play if there are any MUAs that don't display recipients when
composing a response.
Copying and pasting is not necessarily easy even if the
recipient notices - especially on systems where you have to click a
window to select it, where clicking also raises the window and buries
other windows. I've even see cases where copying an address and
pasting in another window *of the same app* didn't paste the same text
that was copied. Now maybe that's just an isolated bug, but in my
experience with windows, macosx, and X11 systems - copy and paste
basically sucks on all of them. Then there are of course systems where
copy and paste doesn't exist.
I haven't use MacOS of any flavor for sending mail, but I've had no
problems with doing so, including cutting and pasting addresses in
(and *between*) common MUAs on several flavors of MS Windows
and under the X Window System. Taht aside, we should differentiate
architectural issues from implementation issues. Architecturally, there
is nothing preventing a user from viewing or setting message header
fields. Implementation issues may well warrant advice to MUA authors.