taylor%hpldat@hplabs.hp.com (Dave Taylor) (11/20/86)
I think we're all missing the point here...
there are *two* different things being argued currently - one is
a low-level question of how to deal with headers, and the other is
a higher-level question of how to present the results of the header
parsing/munging to the end user.
I think that the low level questions are set out in a reasonably
straightforward manner in '822. My personal belief (and "elm" is
a result of this) is that the Reply-To: address is a sign of
mutual exclusion - if it's present, that's the *only* address you
reply to, by default. If you "Group reply" to a message that contains
a Reply-To: header, elm will build a return address based on the
address in the reply-to field and the To: and Cc: list (stripping out
the recipients address, of course). If the Reply-To: isn't present,
the program will either use the From: address or the results of its
own parsing of the "From_" lines at the top of the message (the results
of those dumb AT&T mail transport systems).
At the user level, they merely know that if they use "reply" that
it will go to the appropriate person, and if they use "group reply" it
will be sent to the "reply" address AND the list of people who received
the original message.
A wrinkle is added when we start to consider the reliability of information
in the From: and Reply-To: fields...Any mail not from a "real" internet
site has a high likelihood of having an invalid due to omission address.
So how to deal with it? I don't think we can assume that we can get
the host and login of the ultimate destination machine and route from
there (e.g. ignore the path the message took) - therein lies painful
death if we have no path, an old path, or, horrors! multiple hosts with
the same name.
Once we get domains fully implemented I anticipate a lot of this hassle
going away, since all addresses will either fully specified by the
sending machine (e.g. "To: taylor" would leave my machine as
"To: taylor@hpldat.HPL.HP.COM") or by the user (via aliases, I hope!)
as in "To: woodward@scfac" -> "To: woodward@scfac.DEC.COM" etc). This
also leads to a question of how do we deal with incorrectly specified
domains (e.g. "hpldat.HP.COM") but that's a different story entirely!!
The way the elm gets around this problem is that the default configuration
*ignores* the From: and Reply-To: addresses and simply traces back the
sending route. The system administrator, installing the program, has to
decide if the addresses contained therein are valid or not (since the
program sure can't!!).
Anyone have any comments on this user-level .vs. system-level restatement
of the problem??
[I *don't* think another header is needed! Gad! We already have
enough that it's a bloody pain to figure out the precedence of
them all (e.g. From, Sender etc). "Return-Path:" is ignored in
elm because I think it's a bogus header...]
-- Dave Taylor
taylor@hplabs.HP.COM