Message-Id: <199510040155.VAA18225@CS.UTK.EDU>
Date:        Wed, 4 Oct 1995 02:43:43 +0100
From: Eric Thomas <ERIC@SEARN.SUNET.SE>
Subject:     Re: What's the Sender header for?
To: drums@CS.UTK.EDU, Eric Norman <ejnorman@macc.wisc.edu>
In-Reply-To: Message of Tue, 3 Oct 95 20:31:09 -0500 from Eric Norman
             <ejnorman@macc.wisc.edu>

On  Tue, 3  Oct 95  20:31:09 -0500  Eric Norman  <ejnorman@macc.wisc.edu>
said:

>For example, we have this list that's known as drums@cs.utk.edu. Suppose
>someone is  going to insert a  Sender: header that identifies  the AGENT
>(person, system, or process) that caused  the message to be sent. Who or
>what causes the message to be sent  to all those folks? The right answer
>is drums-request@cs.utk.edu;  that's the agent  that put my name  on the
>mailing list; that's the agent that caused the message to be sent to me;
>that's the agent that I talk to if I don't want any more such messages.

Well, if the list in question were, say, WIN95-L, the AGENT that put your
name on the list, that caused the message to be sent to you, and that you
would   talk  to   if   you   wanted  to   leave   the   list  would   be
LISTSERV@PEACH.EASE.LSOFT.COM.  That's  a  technical fact.  The  -request
address would  go to a  human being  in charge of  the list, but  that is
(usually) not the agent who added  you to the list, that's definitely not
the  agent that  sent you  the  message, and  while you  can usually  get
removed from the  list by writing to  that person, that isn't  the way he
would like you to proceed :-)

>There's no implication that drums-request@cs.utk.edu is a human being;

Which incidentally many people think  it should be. It's very frustrating
to write to what  you think will be a person and be  told that because in
your language the third line of  the message sounded like you were asking
to leave the  list, you have been automatically deleted,  even though you
were just making a suggestion about the list charter.

>Furthermore,  RFC822 specifically  says (4.4.4)  that the  Sender: field
>should  be sent  notices of  non-delivery, etc.  It's not  clear, but  I
>suppose this would only apply in a non-SMTP environment without envelope
>return addresses (yes,  I know Return-Path: would be better  too in such
>an environment). However, that fact  remains that RFC822 *does* say that
>error notices  may (should) be  sent to  the Sender: address,  so aiming
>this back at the whole list would be asking for big trouble.

Actually, I'd  like to put in  a motion that we  deprecate this. Nowadays
there seems to be a pretty clear agreement that in a SMTP environment you
MUST use MAIL FROM:<>, and  that in a non-SMTP environment "Return-Path:"
is your best bet. At the very  least we should clarify that for SMTP, you
MUST NOT  use the  "Sender:" (or "Errors-To:")  field, because  there are
still people who  get confused by this. And if  there's anyone relying on
the fact that  errors go to "Sender:" rather than  MAIL FROM:, well, he's
probably having a serious operational problem today :-)

As for asking for big trouble, well, it's a non issue because only broken
MTAs will send  bounces to that address, and the  category of broken MTAs
includes MTAs that send bounces to the "Reply-To:" address, which you may
want to set to the list, so you  simply have got to be prepared to handle
bounces  to  the list  or  you  will risk  loops.  In  my experience  the
"Reply-To:"  breakage is  more common  than the  "Sender:" breakage.  The
former is mainly  due to "one origin address" mail  software, whereas the
latter is mostly ancient software that nobody cared to update.

  Eric