Message-Id: <199510040041.UAA26292@wilma.cs.utk.edu>
From: Keith Moore <moore@CS.UTK.EDU>
To: Eric Thomas <ERIC@SEARN.SUNET.SE>
cc: Keith Moore <moore@CS.UTK.EDU>, drums@CS.UTK.EDU
Subject: Re: What's the Sender header for? 
In-reply-to: Your message of "Tue, 03 Oct 1995 23:20:30 BST."
             <199510032250.SAA02966@CS.UTK.EDU> 
Date: Tue, 03 Oct 1995 20:41:35 -0400
Sender: moore@CS.UTK.EDU

> >        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.
> 
> I read this as saying "Don't put a machine mailbox address in the Sender:
> field unless  you're sure this won't  result in loops". 

Hmmm.  This is the first time I've ever run across this
interpretation.  It seems a bit of a stretch to me.  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.

> It doesn't say a program can't be referred to by "Sender:", it just
> "strongly recommends" that the address of the *maintainer* of that
> program (which is not the same person as the guy who sent the
> message) should be used rather than the address of the program
> itself.

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

> And  the reason for this  is that, at
> the time, the  "Sender:" field was were delivery errors  were to be sent.
> This was to avoid loops. 

I'm aware of the language in 822 (section 4.4.4) that says that
delivery errors should go to the Sender.  I've always attributed this
to a lack of a well defined interface between SMTP and 822, or a bit
of muddiness in how the layers were separated.  (not surprising, since
as far as I can tell this was one of the earliest attempts to separate
the MTA and UA layers, maybe even anticpating the IFIP WG 6.5 work.)

And it wouldn't surprise me at all if the Sender field were once used
as the destination address for bounced mail in environments that
lacked a mail transport protocol, especially since the purpose of the
Return-Path field wasn't stated very clearly until RFC 1123.

> Nowadays we  seem to have a clear agreement that
> "Sender:" should  not be used for  this purpose, which is  served by MAIL
> FROM:<>, so  this delivery error loop  risk should no longer  be an issue
> (although of course you still have a whole bunch of ill-behaved MTAs that
> you just have to live with).

I hope there are few MTAs left which send bounces to the Sender
address.  AFAIK, there are more of them using Errors-To for this
purpose, and those seem to be declining.
 
> >But the real question is: is  it more important to identify the "person,
> >system, or process" / "agent" / (preferably HUMAN) who *originally* sent
> >the message, or  to identify the "person, system, or  process" / "agent"
> >(presumably a list) that *last* sent the message?
> 
> It's not a question  to which there is a universal  answer. It depends on
> what  the list  is used  for. There  are  lists that  you want  to be  as
> transparent as  possible, a simple  expansion list without any  change in
> headers. And then  there are lists where  you want to make  it clear that
> the message went through the list, change the reply address, etc.

I've said many times that it's difficult to make generalizations about
mailing lists, and for precisely this reason.  A digest, for example,
clearly has no original "Sender" other than the list maintainer.
Other lists wish to preserve the anonymity of their contributors.

But in the usual case it seems very useful to preserve the name of the
person who originally sent the message.  In section A.2 of RFC 822,
all of the examples given for uses of Sender are for the source of a
message, and the examples are clearly intended to point out the
distinction between Sender and From (or Reply-To).

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.

> Most of today's Internet users read  mail from systems that don't support
> all the subtleties  of RFC822. There's the origin address,  the TO and CC
> addresses, and if you're  lucky there may be support for  BCC and a reply
> address. 

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

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.

Again, if people think we should deprecate things like the "original
person who sent the message" meaning of Sender, in favor of overall
simplicity and ease of interfacing with other mail systems, they
should speak up.  I haven't seen much support for this view so far,
but if that ends up being the concensus of the group, that's what
we'll do.


> >In this case  it won't hurt them  to pull the rug. Right  now the Sender
> >field is so ambiguous that you can't tell what it means.
> 
> It may be ambiguous, but it's used  in a certain way that people are used
> to. They  know what it  does for them. What  you're proposing is  to take
> away the facility by  which users can opt to have mail  that comes from a
> list show up  as coming from that list (rather  than the original sender)
> in their mail directory. Judging from historical data when a minor change
> in LISTSERV caused people running old versions of a mail program to see a
> truncated origin  address, I can  guarantee a whole bunch  of complaints.
> Some people deinstalled  the LISTSERV update because this  change was not
> acceptable to their users and they could not update the mail program in a
> quick enough  time frame. I  wouldn't dream  of taking the  facility away
> completely.

I don't doubt that people will complain.   ANY change, no matter how
trivial or insignificant or how much it improves things in the long
run, will inconvenience users and cause them to generate complaints.

I also sympathize with the need to provide some way for a user to know
that the message came from a list (and which list it came from).  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.)

While I'd like to get rid of the conflict between the different
meanings of Sender, I would also like to preserve people's ability to
presort mail and to know which list a message came from.  Unless we
can agree to get rid of one function or the other, this probably means
having different headers for each purpose.

 
> As far as I know, sendmail doesn't "use" the "Sender:" field. It's one of
> the fields  whose contents are  processed through the rewrite  rules, and
> obviously  you can  write  your  own munging  rules  doing  all sorts  of
> creative things,  but at  least sendmail  V8 doesn't seem  to use  it for
> anything. 

You're right; I was mistaken about sendmail's behavior.
 
> >Just because the  feature is not used very often  doesn't mean that it's
> >not very useful. And  yes, it breaks a lot of mail  software, but if the
> >feature is useful  enough to keep then  the solution is to  fix the mail
> >software and to make it very clear in the specs that mail software needs
> >to be able to deal with multiple From addresses.
> 
> And do what with it? In my MUA,  where I have a "From:" column with space
> for  one typical  address, what  am I  supposed to  do with  the multiple
> address?

It's in the protocol, but your user agent doesn't have to support it.

Keith