To summarize and re-phrase more clearly what has been said previously:
 
There are four categories of RFC822 tags within LISTSERV:
 
(E)  Tags which  are EXAMINED  by LISTSERV  but left  unchanged (and  possibly
    generated if not found in the mail header): DATE, SUBJECT, FROM, etc.
 
(R) Tags which are examined by LISTSERV and REMOVED from the mail header. They
    may  cause COMMENTS  tags  to  be generated  but  that's another  problem.
    Examples are: TO, CC, SENDER, RESENT-FROM, etc.
 
(G) Tags which  are GENERATED by LISTSERV regardless of  whether they appeared
    in the original  mail header or not:  TO, SENDER, etc. Note  that (G) tags
    are usually also (R) tags.
 
(O)  Other  tags,   which  are  neither  examined   nor  generated:  RECEIVED,
    MESSAGE-ID, TODAYSLUNCHTIME, RLYEH, etc.
 
Obviously (E) tags are  no problem. We're only dealing with  "what do with the
other tags". The present mail headers are the result of the following process:
 
- Discard (R) and (O) tags
 
- Insert (G) tags
 
I suggested three possible implementations of  a "full header" concept. In all
three cases, LISTSERV may:
 
1) Fold tags differently than they were originally folded.
 
2) Change the relative position of a few tags within the mail header.
 
3) Behave  incoherently if more than  one occurence of  a tag such as  FROM or
   SENDER is found in the original header.
 
4) Add COMMENTS tags as it sees fit.
 
Items (3)  and (4) are no  problem as they  are in accordance with  the RFC822
norm. Items  (1) and (2)  are VERY difficult to  circumvent and I  don't think
it's worth the trouble.
 
In all 3 implementations, (O) tags would be kept unchanged (possibly reordered
or folded differently), and a 'Received:'  tag would be generated by LISTSERV.
(E) tags would be kept as they are presently, but the fate of (G) and (R) tags
would differ as follows:
 
- Case 1:
 
   o Discard (R) tags
 
   o Insert (G) tags
 
  That's what  is being done  with the present  headers, except that  (O) tags
  would be kept instead  of being discarded. The big problem  is that (R) tags
  are lost. Remember, the (R) tags are: TO, CC, SENDER, etc.
 
- Case 2:
 
   o Keep (R) tags
 
   o Discard (G) tags
 
  LISTSERV is acting (more or less)  as a MAILER. It generates nothing, except
  a 'Received:' tag and possibly a  few 'Comments:'. However, the (G) tags are
  lost.
 
- Case 3:
 
   o Keep (R) tags
 
   o Insert (G) tags as the DATA portion of a new tag, X-LSVTAG (or suchlike).
 
  In this  case a  program could  access the (G)  tags if  it needed  them, or
  ignore them if  not needed. However, a  human reader might not  like the new
  tags at all, especially as they are likely to span more than 1 line each.
 
 
The general consensus was:
 
  o 50% voted (1)
 
  o 40% voted (2)
 
  o 10% voted (3)
 
There were very little votes so this is not very meaningful. I personally vote
(1) because it makes  it possible to send the mail item  without having to use
BSMTP, whilst  cases (2)  and (3) would  force me  to use BSMTP  -- not  a big
problem  if Crosswell's  BSMTP routines  were not  buggy... Otherwise  my vote
would have  been (2). I'm particularly  interested in the votes  of people who
will  have to  USE the  feature to  interface LISTSERV  to some  other mailing
system.
 
  Eric