From: Keith Moore <moore@CS.UTK.EDU>
Date: Tue, 3 Oct 1995 15:46:44 -0400
Message-Id: <199510031946.PAA25447@wilma.cs.utk.edu>
To: drums@CS.UTK.EDU
Subject: What's the Sender header for?
Cc: moore@CS.UTK.EDU

(from the floor)

Basically, the question amounts to whether mailing lists should be 
munging the Sender field.  (At least, I don't know of any other 
controversy regarding this field.)

I personally feel that Sender should identify the original human
sender, and that mailing lists shouldn't change it.  For them to
do so removes the ability of a list recipient to see who actually
sent the message.  

I realize that this runs counter to a lot of existing practice, but 
I think this comes closer to the original intent of RFC 822.   I
interpret the intent of Sender as "the human who caused the message
to be sent"; a mailing list that automatically forwards messages
without human intervention doesn't fit this interpretation.
(One might could make a case for using sender with moderated lists;
but an Approved field might be better for this purpose.)

I also don't think it will harm the installed base for us to clarify
Sender in this way; the only result will be that users will be able
to rely on the Sender field more often.

As I see it we can fix this in either of two ways:

a) Say that lists shouldn't mung Sender, and let someone define 
   new header fields which are appropriate for lists.  (Arguably
   the latter work needs to be done anyway.)

b) Say that its okay for lists to mung Sender, and recommend a 
   different way for originators to indicate who actually sent the 
   message (say, in the first Received header)

...and the first one looks more attractive to me.

-Keith


For reference, here's the relevant section from RFC 822:


     4.4.2.  SENDER / RESENT-SENDER

        This field contains the authenticated identity  of  the  AGENT
        (person,  system  or  process)  that sends the message.  It is
        intended for use when the sender is not the author of the mes-
        sage,  or  to  indicate  who among a group of authors actually
        sent the message.  If the contents of the "Sender" field would
        be  completely  redundant  with  the  "From"  field,  then the
        "Sender" field need not be present and its use is  discouraged
        (though  still legal).  In particular, the "Sender" field MUST
        be present if it is NOT the same as the "From" Field.

        The Sender mailbox  specification  includes  a  word  sequence
        which  must correspond to a specific agent (i.e., a human user
        or a computer program) rather than a standard  address.   This
        indicates  the  expectation  that  the field will identify the
        single AGENT (person,  system,  or  process)  responsible  for
        sending  the mail and not simply include the name of a mailbox
        from which the mail was sent.  For example in the  case  of  a
        shared login name, the name, by itself, would not be adequate.
        The local-part address unit, which refers to  this  agent,  is
        expected to be a computer system term, and not (for example) a
        generalized person reference which can  be  used  outside  the
        network text message context.

        Since the critical function served by the  "Sender"  field  is
        identification  of  the agent responsible for sending mail and
        since computer programs cannot be held accountable  for  their
        behavior, it is strongly recommended that when a computer pro-
        gram generates a message, the HUMAN  who  is  responsible  for
        that program be referenced as part of the "Sender" field mail-
        box specification.