A number of minor incompatibilities are being introduced in release 1.7d.
If any  of the changes described  below would cause serious  problems for
you, please contact me as soon as possible.
 
The "Formcheck= Yes" list header keyword  will no longer be honoured: all
lists will operate with the default option, "Formcheck= No" (ie NJE files
sent to  a mailing list will  be accepted if "Files=  Yes", regardless of
their NJE  form). Very few lists  seem to use "Formcheck=  Yes", and then
probably for  historical reasons.  Nowadays most  BITNET nodes  (with the
notable exception  of a number of  MVS systems) have mail  packages which
generate BITNET-compatible mail,  and the need to filter "mail  sent as a
file" is  no longer as  critical, especially given the  DISTRIBUTE change
mentioned below. On  the other hand, users complain that  they don't know
how to set the form to REDIST,  and don't understand why they should have
to anyway.
 
When a NJE file is sent to a moderated list and does not come from one of
the editors,  LISTSERV will  no longer  forward the  file to  the editor;
instead, it will  instruct the sender to send it  to the editor manually,
along with an  explanatory message. This change both  makes conversion to
PREXX easier and  avoids confusions and problems when the  editor is on a
non-BITNET system (and the file arrives as trash), when the editor is not
familiar with  the submission of  NJE files to  a list (and  wonders what
that file is and why LISTSERV sent it), or when the editor is a server.
 
When a file in Netdata, CARD or  DISK DUMP format is being DISTRIBUTEd to
a mail-only recipient, LISTSERV will  attempt to "decode" the file before
mailing it, instead of mailing the binary card images 'as is'. The result
may still  not be  usable, in  particular if  the original  file contains
object code, but text  files sent via SENDFILE to a  list will be decoded
properly. This may  be a problem if  you have mailing lists  that rely on
the fact that  the binary card images  used to be sent  as is, presumably
over a  mail channel that  can handle  arbitrary binary data:  instead of
delivering a CARD  deck via mail, LISTSERV would extract  the first file,
whose record length might exceed 80,  and deliver that instead. Note that
even mail between two VM systems using the Crosswell mailer cannot handle
arbitrary CARD  or Netdata decks,  as any line  starting with a  dot will
have the character in column 80 replaced with a blank.
 
  Eric