1: We do not have an RFC822 network.
   On most systems any user can create any straem of bytes and
   transfer that to LISTSERV or any other server.
   Once people really accept that fact they will no longer complain
   about "What kind of funny header is this and that?" but rather
   try to make their systems more tolerant.
 
2: There is no good way to decide what piece of mail should be
   considered as RFC822 mail and what not.
   There are two possibilities:
   a) Take everything and try to make an incoming bytes stream
      to RFC822 without looking to other "external" indicators
      as FORMS, CLASS etc.
 
   b) Use certain indicators that say either: This is supposed
      to be RFC822 (then you simply REJECT files if they are not),
         CLASS M FORMS MAIL (FILENAME?)
      or when it says "this is not RFC822" that you don't touch
      the contents and NEVER use MAIL for delivery.
         REDIST?
 
      A NETDATA DATA SET to be distributed is NOT RFC822 at all.
 
3: There is one exception in the network which is "almost" RFC822
   IBM NOTE. This thing should be considered special and modified.
 
4: Some people at native MVS systems have a tendency to create
   these funny headers where not even a colon ends the FROM etc.
   The question is in this case: How far should the error propagate?
   When MAILER and LISTSERV continue changing the "CLASS" and
   FILENAME FILETYPE to "the defacto mail standard :-)" or whatever
   they should screen that stuff. If LISTSERV just distributes the
   data as is to recipients in the net (as with "REDIST")...
   A lot of heuristics is necessary to make garbage to something
   usable, espcially when the usable stuff looks like garbage. :-)
 
5: The implementation stategy should be that in any case a
   NEW HEADER is constructed, and as much elements from the old
   header should be copied into that new header (maybe modified).
   The remaining stuff should simply left as a beginning of the
   body (I prefer no loss of information).
 
Peter