Message-Id: <199510040141.VAA17522@CS.UTK.EDU>
Date:        Wed, 4 Oct 1995 02:21:24 +0100
From: Eric Thomas <ERIC@SEARN.SUNET.SE>
Subject:     Re: What's the Sender header for?
To: Keith Moore <moore@CS.UTK.EDU>
cc: drums@CS.UTK.EDU
In-Reply-To: Message of Tue, 03 Oct 1995 20:41:35 -0400 from moore@cs.utk.edu

On Tue, 03 Oct 1995 20:41:35 -0400 Keith Moore <moore@cs.utk.edu> said:

>Hmmm. This is  the first time I've ever run  across this interpretation.
>It seems a bit of a stretch to me.

Well, I'll just say it used to actually generate mailing loops many years
ago  when there  was a  lot of  software using  the "Sender:"  address to
deliver bounces.

>In particular, I  don't see how the desirability of  avoiding loops fits
>with  the  "computer  programs  cannot be  held  accountable  for  their
>behavior" language.

Quite to  the contrary,  it just means  that if you  deliver a  bounce to
"Sender:" and "Sender:" points to a program, the program may not identify
it as a bounce and may instead reply, possibly resulting in a new bounce,
etc.

>Except  that the  other interpretation  of  Sender is  "the person  that
>initiated the message transfer" (822, section 4.4.4)

You just said it, the *other* interpretation of "Sender:". There were two
of  them in  the original  RFC, both  are widely  used, I  don't see  any
premise for removing one of them.

>But in the usual  case it seems very useful to preserve  the name of the
>person who originally sent the message.

Sorry Keith,  but in the  "usual" case there is  just a "From:"  field to
start with, and no "Sender:" (not counting mailing lists).

>If one of  these messages was sent  to a mailing list  that replaced the
>Sender  field, the  carefully  engineered distinction  between From  and
>Sender at the source would be lost. So I have a hard time believing that
>doing so is consistent with the intent of 822.

In reality  what happens is  that you get  another level of  "Sender:" vs
"From:" on top of  the existing one. If RFC822 had  supported a method to
indicate multiple  levels of  authoring/transmission, this  wouldn't have
been  an  issue, but  it  doesn't.  And we  have  the  same problem  with
forwarding. In general, RFC822 just isn't recursive.

>I  don't know  whether  this is  "most"  or "many",  and  no offense  is
>intended, but I  suspect you don't either. (If you  have real statistics
>over a randomly sampled set of  Internet users, please give a reference;
>I'm sure the WG members would benefit from such knowledge.)

Add AOL and CompuServe and Prodigy  for starters. That's a big, big chunk
of users with the kind of interface I described. Then take a walk through
your university  and count  the number  of PC users  vs unix  users. Then
factor in  the fact  that universities are  much more  unix-oriented than
corporations, and  that the  growth will  come from  corporations, simply
because the  universities are just  about as  connected as they  can ever
get.

>Also,  for those  users the  Sender  issue is  largely irrelevant;  they
>discard the Sender field regardless of whether it refers to the original
>sender or to a mailing list.

No, they don't. It usually replaces the "From:" field when present, which
is why  the message looks  like it came from  the list, not  the original
author.

>I am certain, for instance, that  some people find this field useful for
>automatically sorting  incoming messages  into folders. (I'll  also note
>they can't use this field for  every list because some lists *don't* set
>the Sender field.)

That's true, but in my experience  very few lists don't set the "Sender:"
field. These  are usually manually  maintained sendmail aliases  to which
Joe Users seldom subscribe.

  Eric