Nick Ing-Simmons wrote:
Bruce Lilly <ietf-822(_at_)imc(_dot_)org> writes:
Nick Ing-Simmons wrote:
One of the USENET concepts which has translated quite well to mail is
the use of the References: header to thread mails.
The References field was defined in RFC 724 (possibly earlier) which
predated Usenet by years. It was not adopted by Usenet until after
RFC 724 had been superseded by RFCs 733 and 822.
I was refering to the reliable use of message IDs in references field.
UseNet definitely had that 1st (whatever RFCs may have said).
I'm not convinced of any such reliability, due to malformed
References fields added by some UAs -- which seems to be more
prevalent in news-oriented UAs than in mainstream MUAs.
If there was a clearly defined header that said "you got this mail from
the list <whatever(_at_)somewhere>"
You mean something like
Return-Path: <owner-ietf-822(_at_)mail(_dot_)imc(_dot_)org>
or
Sender: owner-ietf-822(_at_)mail(_dot_)imc(_dot_)org
So the answer is no ;-)
Return-Path certainly provides what you asked for, viz. where
the message came from. That's not the same thing as a list
submission or subscription address in general (and obviously
isn't in this instance).
it would be trivial to add a
"Reply to list" button to a MUA.
Not necessarily. Sometimes there are multiple list expansions.
So - if the name of the _list_ was in a header "reply to list"
would go back to the machine hosting the list and be re-expanded.
The point is that you're assuming *one* and only one list,
whereas a message may be copied to multiple lists or be
expanded by one list to mailboxes which include additional
lists.
Now RFC 2369 fields -- when they're used -- might provide
some information, however:
1. they're not always used; messages on this list do not
have a List-Post field, for example.
2. the presence of those fields is due to list expansion
software, and therefore provides no indication of the
author's (or authors') preferences for responses
3. There may be multiple List-Post fields in the case of
a) submission of the original to two or more disjoint
lists
and/or
b) expansion of one list into another list
In case b, sending responses to all list submission
mailboxes will result in duplicates for at least some
recipients. There is no obvious indication which of
several mailboxes should be used or omitted to prevent
such duplication. In case a, see item #2 above (an author
might wish responses to go only to one list, or to
somewhere else entirely).
4. There is no indication of whether or not the author(s)
and/or any other original message recipients are
subscribed to any subset of lists indicated by such
fields, and therefore no reasonable way for a
respondent to be able to figure out whether or not the
author(s) or other original message recipients will
see a response sent only to one or more of the list
mailboxes, either in a timely manner or ever.
Two conclusions:
1. If an author wishes responses to go to some specific place,
he needs to indicate so or potential respondents will have
to play guessing games. The RFC 2822 Reply-To field has
the necessary semantics for indicating a recommended list
of response addresses.
2. If a respondent wishes to send a response somewhere other
than where the author(s) have recommended, he will have to
guess what the result will be; he cannot tell whether or
not an author is subscribed to any list, he may have to guess
which mailboxes in the original message address fields are
list addresses, he will be unable to readily determine if
any mailbox is expanded, or if any mailbox resulting from
any such expansion will be further expanded.
So while Return-Path, Sender, and List-* fields may be of
some use to recipients for filtering and filing, they really
provide no help for responding.