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
go elsewhere than the mailbox(es) in the From field:
1. a message sent from work, responses desired at home or vice versa
users should be able to set the From field on a per-message basis.
(it's not forgery if the address belongs to you)
2. multiple authors, responses should go to one author
potentially useful, but rarely used
3. the case in point, message sent from an individual, responses should
go to a list mailbox
fair enough. though presumably the list is one of the recipients of
the message, and if there were a way to say "don't reply to the author"
that would also work.
there are indeed cases where it would be useful if the author could
redirect replies (say, to a secretary) but the way Reply tends to be
implemented by user agents, this isn't likely to work well anyway.
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.
Now you might say "forge From" instead of using Reply-To, but that
won't work with some times of authentication and spam filtering.
most forms of spam filtering are too broken to use anyway. and any
authentication mechanism that restricts the setting of From is broken.
From is clearly not intended to be used for that purpose.
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.
maybe other MUA authors need encouragement?
The other "reply" (call it "group
reply") should probably have some way of excluding recipients that,
whatever reason, should not receive replies.
Are you suggesting a field that modifies the interpretation of a
field? I thought you were opposed to that.
everything else being equal, I would prefer something like To-NoReply.
but I am trying to keep an open mind about other possibilities.
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
of response is the default.
not clear. lack of uniformity in UA behavior causes problems. I don't
think we should specify details like what the interface should look
like, where the buttons should be, whether it's a command-line or GUI
interface, etc. I do think it might be useful to encourage some degree
of uniformity as to which functions are provided, and I do think it
might be useful to say "please provide ways of doing these things".
Many MUAs don't even display reply-to fields when viewing
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
composing a response.
often there's no easy way to tell how the recipients of a reply relate
to the sender and recipients of the original message. that is why
reply behavior can be surprising.
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,
is nothing preventing a user from viewing or setting message header
fields. Implementation issues may well warrant advice to MUA authors.
I agree that these are implementation issues.