Organization: The American University
Newsgroups: bit.listserv.catholic
Date:         Fri, 9 Oct 1992 16:18:11 EDT
From:         Jim McIntosh <JIM@AMERICAN.EDU>
Subject:      Mail Headers

A number of people have commented on the fact that since the move of this
list from  dragon.com to american.edu,  the mail no longer  indicates the
sender of the mail. A couple of people have sent me copies of the mail as
they get it, and it appears that some uucp sites add a second "From" line
which points back to the list. When  their mail program pulls in the mail
only the  first "From" line  is displayed,  and so the  original sender's
name and e-mail address is lost. Since moving recently to Microsoft Mail,
I have found that the same thing happens there.

There are five options for mail  headers on posts coming from the mailing
list. The  first four  are similar  and concern  various options  on SMTP
headers.  The last  option (IETFHDR)  mimics the  actions of  an Internet
mailing list, and does not change  the headers except to add 'Received:',
'Message-ID:', and 'Sender:'. No other changes are made to the headers.

People who have tried  the IETFHDR option say that it  allows the mail to
show who the mail originally came from, but at a cost of no Reply-To line
pointing back to  the list. If you  would like to try  these headers send
the following command to "listserv@american.edu" (NOT "catholic"):

                          SET CATHOLIC IETFHDR

If you decide  you do not like these headers,  send the following command
to reset the mail headers back to what you are getting today:

                          SET CATHOLIC SHORTBSMTP

For the techies, a full explanation follows.

Jim McIntosh (jim@american.edu)
The American University
Washington DC 20016-8019 USA

--------------8<---------------(cut here)---------------8<---------------
**************************************
* Usability: IETF-style mail headers *
**************************************

WARNING: There are  a number of important warnings in  this section. Read
them carefully.  In particular,  IETF-style headers must  NOT be  used by
LISTSERV-to-usenet gateways.

DISCLAIMER:  All references  to  the discussions  of  the IETF  "listserv
working group" reflect  the author's personal appraisal of  the debate on
the working group's list, as of late august 1991 (shortly before the code
being described was  written). At this time, the group  did not expect to
produce a RFC (other than a  possible informational one) in the immediate
future, and the  first non-informational RFC was not  expected to address
the  topic of  mail headers.  This  topic has,  however, been  thoroughly
debated on the list, and it is this debate that the author's comments are
based upon.  The working group  archives are available via  anonymous FTP
from FTP.UTDALLAS.EDU,  should you want  to form  you own opinion  on the
matters at hand.

Up  to and  including version  1.7a,  LISTSERV provided  two flavours  of
RFC822 headers: SHORT,  with just the "essential" fields,  and FULL, with
all  fields  (including  those  usually  deemed  "superfluous",  such  as
'Received:').  For both  types of  header, two  delivery mechanisms  were
supported: "regular" delivery, with the recipient's address listed in the
RFC822 'To:' field, and "BSMTP" delivery,  with a generic 'To:' field not
pointing to the recipient. This resulted in four possible header options:
SHORTHDR, SHORTBSMTP, FULLHDR and  FULLBSMTP. The only difference between
the HDR and BSMTP  options is the contents of the  'To:' field, which for
the present discussion is immaterial: we  only need to consider the SHORT
vs FULL attribute of the header.

Due to  their different culture  and habits, Internet people  are usually
not satisfied with  either option. Most Internet users (or  at least most
of the vocal ones) read mail from workstations and use sophisticated user
interfaces which  hide "uninteresting" header fields  automatically; they
are  thus not  interested in  any removal  of "superfluous"  tags at  the
sending point (and contend that  the bandwidth saved is immaterial, given
T1-speed access).  They are furthermore  used to SMTP alias  lists, which
are basically  a feature of Internet  mail systems making it  possible to
have the mailer replace  a given mailbox with a list  of mailboxes on the
fly;  in other  words,  by  sending mail  to  'x@y.edu'  your message  is
automatically sent to a number of people as it reaches the host Y.EDU, by
causing the mail system to  internally expand the recipients list without
touching anything else.  In particular, the mail header  is unaltered and
still reads 'To: x@y.edu' - the 'To:'  field is where you should look for
the list name. The IETF's "standard listserv" RFC's will be based on this
type of headers, and disallow the LISTSERV-style ones.

In order  to allow  BITNET users to  become familiar  with Internet-style
headers and  to decrease  the rate of  incoming "suggestions"  for future
development  of  LISTSERV from  Internet  users  forced to  subscribe  to
BITNET-based mailing lists for professional reasons, a third type of mail
header is being introduced: 'IETFHDR' (which always uses BSMTP delivery).
That is,  one would  send a  'SET XYZ-L IETFHDR'  command to  LISTSERV to
switch to IETF-style headers.

For  a regular,  non-peered  list,  the IETFHDR  is  the header  LISTSERV
received from the mail system with exactly three changes:

1. A 'Received:' line is added on top of the header.

2. A  'Message-ID:' field is added,  if none was present  in the incoming
   message.

3. The  'Sender:' tag is  set to the value  of the "Sender="  list header
   keyword, if one is supplied, or to 'OWNER-listname@hostname' (in lower
   case). For instance, a posting sent to the list XYZ-L@VM.ABC.EDU would
   have a default 'Sender:' tag value of 'owner-xyz-l@vm.abc.edu'.

It is important  to understand that these headers are  not being provided
in  answer to  requirements from  non-DP-literate users.  They are  being
provided to answer requirements from  Internet specialists; it is "their"
headers, not "ours".  They are not meant to be  user-friendly and are not
open to negotiations. They will  not spawn sub-options with various bells
and whistles  added. They are here  to allow LISTSERV to  emulate an SMTP
redistribution list if desired, and nothing more.

Note that  this does not mean  that LISTSERV will be  converted to become
compliant with the upcoming "IETF  listserv" standard, nor that setting a
list to use  IETFHDR for all subscribers will make  it IETF-compliant. It
is the author's  opinion that the "IETF listserv" standard  will not make
it  possible  for  LISTSERV  to be  compliant  without  becoming  totally
incompatible  and ceasing  to address  the  needs of  some categories  of
BITNET users. In particular, the very  fact of allowing users to request,
no matter  how explicitly, that  headers be  delivered in a  format other
than IETFHDR  would be a  violation of  the future standard,  assuming no
change  in the  direction  of  the working  group  from  what the  author
experienced during his participation. Since  the "IETF listserv" is going
to  be a  fully-specified standard  and  one of  the goals  of the  "IETF
listserv" working  group (again, assuming  no change of direction)  is to
see  to it  that it  is  implemented in  a  portable way,  it seems  more
appropriate  to have  whatever new  software the  Internet comes  up with
replace  LISTSERV, rather  than striving  to  turn LISTSERV  into a  poor
emulation of the latest fashion. Indeed,  it would seem unlikely for more
than  a small  minority of  sites to  want to  run such  a service  on an
expensive mainframe if it can be provided as easily on cheaper hardware.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>> IMPORTANT WARNINGS regarding the IETFHDR option <<<<<<<<<<<<
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

A. LISTSERV does  not alter the header beyond the  three points mentioned
   above: insertion of a 'Received:'  line, generation of a 'Message-ID:'
   if  not already  present, and  generation of  a 'Sender:'  field. This
   means LISTSERV  cannot guarantee that  the header is  syntactically or
   semantically correct,  beyond the fields it  generates itself. Because
   of this, THE IETFHDR OPTION MUST  BE NOT USED FOR SUBSCRIBING PROGRAMS
   WHICH REACT ON THE CONTENTS OF THE HEADER. This means you must not use
   this option  for a usenet  gateway, but  you can subscribe  a "logger"
   program which just appends everything it receives to a disk file.

B. LISTSERV  does not (and  cannot) take control of  the "owner-listname"
   address, which is normally too long to be a valid VM userid. It is the
   responsibility of  the list  owner to  ensure that  an alias  for this
   address is set in the mailer at  the site hosting the list if he wants
   to receive delivery errors sent to that address.

C. In a peered-list environment, the IETFHDR option will operate properly
   only if ALL peers  are running release 1.7b or higher.  If this is not
   the case, some postings sent to  IETFHDR subscribers may appear with a
   FULLBSMTP-like header;  this is not  a bug,  but a consequence  of the
   simple fact  that the original  header has  not been preserved  by the
   peer to which the posting was sent.

D. If  the posting  received by  LISTSERV comes  in a  format other  than
   RFC822 (eg  PROFS), LISTSERV  will generate  a new  header out  of the
   information at hand.  Such a header may look  "suspiciously short", so
   it was felt necessary to mention this possibility.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> End of important warnings <<<<<<<<<<<<<<<<<<<<<<<
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Here  is  an  IETFHDR-style  header   example,  built  from  an  INFO-VAX
contribution using a test list (L201@SEARN) for formatting the headers:
-------------------------------------------------------------------------
Received: by SEARN (Mailer R2.05) id 0023; Fri, 18 Oct 91 15:23:22 +0100
Received: from SEARN.BITNET by SEARN.SUNET.SE (LISTSERV release 1.7a) with NJE
          id 0005 for L201@SEARN.SUNET.SE; Fri, 18 Oct 1991 15:22:52 +0100
Received: from DEARN by HEARN.BITNET (Mailer R2.07) with BSMTP id 4454; Thu,
          17 Oct 91 14:28:43 CET
Received: by DEARN (Mailer R2.08) id 4111; Thu, 17 Oct 91 14:27:44 CET
Received: from vtvm2.cc.vt.edu by DEARN (Mailer R2.08) with BSMTP id 5972; Thu,
          17 Oct 91 11:53:31 CET
Received: by VTVM2 (Mailer R2.08 R208002) id 6841; Thu, 17 Oct 91 06:54:17 EDT
Received: from VMA.CC.CMU.EDU by vtvm2.cc.vt.edu (Mailer R2.08 R208002) with
          BSMTP id 6831; Thu, 17 Oct 91 06:52:10 EDT
Received: by CMUCCVMA (Mailer R2.04) id 2335; Thu, 17 Oct 91 06:48:43 EDT
Received: from UGA.CC.UGA.EDU by VMA.CC.CMU.EDU (Mailer R2.04) with BSMTP id
          2331; Thu, 17 Oct 91 06:46:33 EDT
Received: by UGA (Mailer R2.07) id 1757; Thu, 17 Oct 91 06:49:07 EDT
Received: from CUNYVM.BITNET by UGA.CC.UGA.EDU (Mailer R2.07) with BSMTP id
          1753; Thu, 17 Oct 91 06:48:35 EDT
Received: from CUNYVM by CUNYVM.BITNET (Mailer R2.08) with BSMTP id 1159; Thu,
          17 Oct 91 06:48:35 EDT
Received: from CRVAX.SRI.COM by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with
          TCP; Thu, 17 Oct 91 06:48:33 EDT
Received: From DANPOST.UNI-C.DK by CRVAX.SRI.COM with TCP; Thu,
          17 OCT 91 03:01:39 PDT
Received: from vms2.uni-c.dk by danpost.uni-c.dk (5.65/1.34) id AA05308; Thu,
          17 Oct 91 10:01:27 GMT
X-Envelope-To: INFO-VAX@SRI.COM,
               agate!spool.mu.edu!uwm.edu!zaphod.mps.ohio-state
               .edu!wupost!micro-heart-of-gold
               .mit.edu!news.bbn.com!star-trek!cmiksis@UCBVAX.BERKELEY.EDU
X-Vms-To: UNIL63::IN
          %"agate!spool.mu.edu!uwm.edu!zaphod.mps.ohio-state.edu!wupost!micro-h
          eart-of-gold.mit.edu!news.bbn.com!star-trek!cmiksis
          @UCBVAX.BERKELEY.EDU"
X-Vms-Cc: IN::"INFO-VAX@SRI.COM"
Newsgroups: bit.listserv.info-vax
Date: Thu, 17 Oct 1991 11:01:00 +0200
Comments: Warning -- original Sender: tag was INFO-VAX@DEARN
From: <deleted for privacy reason>
Subject: Re: Would should a descriptors length be?
To: L201@SEARN

(message text removed)
-------------------------------------------------------------------------

Note that the contents of the list  archives are always kept in a special
version of the SHORT header style (without 'To:' field). This is the only
format the database driver can handle,  and with the IETFHDR format there
would be no guarantee that all  the information required by the driver is
present and  valid. If you want  public archives in IETFHDR  format, just
subscribe a "logger"  program on your local anonymous  FTP workstation to
the list with the IETFHDR option.