Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu> writes:
In a sense that's correct, because the header recipient addresses and
the envelope recipient addresses don't have to agree at all. But the
point is that the replier needs to be fully aware of where his replies
are going. User agents that appear to change their behavior from one
message to the next do not promote such awareness.
I agree with this.
The difference in (apparent) consistency occurs because Reply-To, MFT,
or similar fields are often not displayed to the recipient. The
recipient expects the reply to go to the sender and recipient addresses
that were displayed when he read the message, not to some other set of
addresses that were hidden from view.
Surely this is fundamentally a UA problem, though, isn't it? Assuming
that we have to add some new field or some new definition in order to
improve the existing situation, UAs are going to need at least some degree
of modification to use it or use the existing field correctly. (Even if
we go with Bruce's approach which requires no new fields, UAs are going to
need to modify their handling of Reply-To in order to make the semantics
Bruce discusses easier for people to use. Many UAs don't have a way of
setting Reply-To or only have one global setting.)
UAs clearly do need to show where replies will go, and insofar as they
don't do that with Reply-To now, I think that's a problem. But it's not
that they're incapable of doing that. In fact, if *any* routing of
replies other than simple functions of From, To, and Cc headers is
supported (and I think that we can all agree that at least some people
want this quite a bit, enough so that the need isn't going to go away),
the UA issues seem about the same to me. There has to be some way to show
the user where their replies to a particular message are going to go.
Of course, if all of the header fields were displayed, the problem would
then be one of complexity.
I think it would be better for the UA to work out the logic for the user,
at least for UAs not targetted at sophisticated users.
--
Russ Allbery (rra(_at_)stanford(_dot_)edu)
<http://www.eyrie.org/~eagle/>