Errors-to: owner-drums@CS.UTK.EDU
Message-Id: <199508170543.BAA26105@wilma.cs.utk.edu>
From: Keith Moore <moore@CS.UTK.EDU>
To: conklin@info.cren.net (Jim Conklin)
cc: Jacob Palme <jpalme@dsv.su.se>, ietf-drums <drums@CS.UTK.EDU>,
        moore@CS.UTK.EDU
Subject: Re: "Reply-To" 
In-reply-to: Your message of "Wed, 16 Aug 1995 16:45:43 BST."
             <199508162042.QAA27222@info.cren.net> 
Date: Thu, 17 Aug 1995 01:43:52 -0400
Sender: moore@CS.UTK.EDU


>   Please understand that mailing-list managers (as distinguished
> from list expanders) have for years been acting as surrogate senders
> for message originators who send their mail to these lists perfectly
> happy that the mailing-list manager acts as Sender for their message
> to the list and, as Sender, creates a Reply-To header as the
> participants of the list have either agreed to or accepted as
> appropriate for that list.

>   That's accepted practice for millions of e-mail discussion-list
> subscribers, and it's justified within the language of 822 by the
> fact that the list-manager is acting as the surrogate sender of the
> message, just as a secretary sending a message for a boss who, for
> example, dictated an e-mail message, would set the Reply-To header
> in accordance with the wishes of that real originator of the
> message.

While I understand that this has been happening for years, I believe
it is taking a bit too much license to declare the mailing list a
Sender.  In the DRUMS work we need to state very clearly that the
sender of a message transmitted through the list is still the sender
of the original message, that certain headers (such as To, Cc,
Reply-To, and Subject) were intended to be supplied by the sender, and
that the Sender header indicates the identity of the sender of the
message before it hit the list.

That's not to say that I want to prohibit lists from munging with
those headers; as I've already said, I think there are circumstances
when almost any kind of header munging by lists can be justified.
However, lists should have a "good reason" for mucking with these
headers (and thus obscuring the Sender's identity or intent), and
there should perhaps be some advice that a list which mungs such
headers should indicate that it has so.

Keith

p.s. While negative impact on the installed base is always a good
reason to consider not making a change to a protocol, the fact that
lots of people think "it's supposed to work this way", is not, by
itself, a good reason.

There are many instances where we need to clarify the mail standards,
and/or rule on which of several interpretations is the "right" one.
Neither of these is the same thing as bringing the standards in line
with users' expectations.  Most users don't have the depth of
expertise required to know why a particular design decision makes
sense.