Date: Tue, 3 Oct 95 23:08:07 -0500
From: Eric Norman <ejnorman@macc.wisc.edu>
Reply-To: drums@CS.UTK.EDU
Message-Id: <9510040408.AA14106@dogie.macc.wisc.edu>
To: drums@CS.UTK.EDU
Subject: Re: What's the sender header for?

>>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

Yes, there may indeed me more than one AGENT involved; the whole point
was really that the Sender: header should reflect whomever caused the
message to be sent (to those recipients) and that the sending AGENT
is *not* the group identified as drums@cs.utk.edu.

Assuming that a list expander may add a Sender: header, what *useful*
information do folks think it should contain?

>>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.

So what are you suggesting here?  Should it be possible to tell from
an address whether it represents a carbon-based or a silicon-based life
form?  Are you suggesting that automatic deletion via mail messages
should not be allowed?

>>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:"

I'll second this motion; however, I also want to amend it so that
the verb is "eliminate", not "deprecate"; they mean different things.

Let's not forget that RFC822 is supposed to be a protocol that only
specifies the format of messages, and, as such, does not assume the
use of any particular transport protocol.  I.e. we're going to have
to make the meaning and usage of Return-Path: clear for the folks
that don't have an envelope with a return address.

Keith says that there's no clear interface 'tween RFC822 and RFC821.
In light of the above paragraph, I'm going to lightheartedly disagree
and say that there is too.  The interface says that they're independent
and that the only thing you do after a positive reply to the DATA
command is send a bunch of RFC822 bytes; period.  [Ohmygosh; an SMTP pun.]

>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

I sure don't see how you can claim that sending bounces to Sender: is
breakage since it's specifically allowed by RFC822.  It'll be breakage
if we eliminate this, but it isn't now.

-- Eric Norman