but I do like list-specific fields better than having lists rewrite
originator-supplied fields.
every now and again, Keith and I agree on something. This is one of them.
(but of course, it did not last for even one entire message...)
:)
And many/most humans can't be bothered, with
the result that replies often wind up going to *everyone* the MUA will
allow them to be sent to.
interesting that in the days of paper memos, people could be bothered
to think about such things.
the human factors issues are a tad different.
absolutely.
paper did not automatically fill out the reply fields...
and thus, paper never filled out the reply field incorrectly :)
Getting the defaults "right" is a dilemma and, therefore, requires choosing
the kind of error that is least undesireable.
I think of it as a user interface issue. sometimes user interfaces that
try to guess what the human wants are more annoying (and/or error-prone)
than those that expect the human to explicitly specify what he/she wants.
our understanding of desirable characteristics of user interfaces has
increased a lot in the past 20+ years. similarly, I don't think the
subtleties of communication between humans and automatic responders
over email were well understood at the time the data model for email
headers was defined.
part of the problem is probably (as you said) that the subtle
differences between return-path, from, reply-to, and sender
aren't clear to most email users
The intent was that users should only need to know about From/Reply-to,
with Sender serving as a kind of accountability fall back.
actually this works most of the time - human users don't generally fool with
either sender or return-path.
Return-path
(and Sender) are intended for the mail handling system, not really for the
recipient user.
sender seems to have been intended for humans, if only as a diagnostic tool,
because 822 doesn't require it to be a valid email address.
Keith