Message-Id: <199510032250.SAA02966@CS.UTK.EDU>
Date:        Tue, 3 Oct 1995 23:20:30 +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 18:18:43 -0400 from moore@cs.utk.edu

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

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

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

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. There's no  support for "Joe sent the message  on behalf of Jack
and Jim, with Jane giving formal  permission". In most cases, you'll find
that these  users don't  care about this  multi-author stuff.  Their mail
program doesn't support it, and besides, when a memo has multiple authors
it's usually mentioned  in the memo itself. On the  other hand, when they
get mail from a list they like to know that.

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

>And as  long as you're  talking about the size  of user bases,  it might
>help to remember  that there's at least one other  piece of software out
>there  with   a  similar   sized  user  base,   that  has   a  different
>interpretation of Sender than does LISTSERV.

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. If  it's present  it leaves  it alone, if  it's not  present it
doesn't add it. It  only seems to be used, through  the -f option, for...
mailing lists :-)  So, while the mechanisms and details  are the same, it
seems that both LISTSERV and sendmail  have options to put something that
somehow references the list as origin of the message, using the "Sender:"
field.

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

>Actually, no. The Sender doesn't have to be in the From list,

I know.

  Eric