Gosh, LSTSRV-L is now very very near  to be as hectic as MAILBOOK! Oh well...
 
Drew:
  LISTSERV  cannot "guess"  that [log in to unmask]  is CLVM.  If you
could send a more detailed description of the problem I might be able to find a
solution.  And please  let's not  start  this "To  upcase, or  not to  upcase?"
discussion again... Thanks :-)
 
Nick:
  Actually LISTSERV has two purposes depending on why you installed it. You can
either have installed it  for local business only, ie local  lists, and in that
case you may  want to disable DISTRIBUTE  and it would be  JUST LOGICAL because
that's not why you  use the server. The file server functions  can be very very
useful for local node purpose and I  got requests from people at our node about
creating a server which  could send files only to a  certain category of people
for internal use  -- just after I had  finished 1.5d ;-) Each lab  will soon be
able to have his  own private files on the server  and they'll be automatically
maintained by  whomever. We found  it to be a  hassle to process  requests like
"please put this file on our lab's com-disk"  -- "oops, bug in the file I sent,
please put this one back" -- "you did  a typo in the filename, it's MRE2G3D not
MER2G3D" (not kidding, that's the kind of names for their programs!!!). They'll
soon PUT the stuff  themselves et voila. Of course you  might not be interested
in the file server functions for local use.
 
  If you've installed LISTSERV to interact with the network it's different. The
main goals become:
 
1) Provide efficient,  reliable, non-looping mailing list  functions (including
   non-mail file distribution to a list)
 
2) Provide easy-to-use, powerful remote-control for the above.
 
3) Provide any kind of thing that may  help cutting down on network load, be it
   related to mail items or not. This include DISTRIBUTE, file server functions
   as used in the NETSERV-cache application, etc.
 
  You can  disable the file server  functions by (1) not  creating any filelist
and (2) disallowing users to define  themselves a password. All that they'll be
able to  do is request information  files/tools which they'd be  able to obtain
via the INFO command.  If necessary I could add an option  to restrict the INFO
command  to local  users,  etc. I  perfectly understand  the  concern of  those
people who have installed  the server for local use only and  are getting a bit
worried about interaction with the network.
 
Valdis, Harold:
  No problem,  you'll have  a quiesce-distribute command  in the  next release.
 
ARPA lists:
  Go on and create  the lists, I think it could be a  good start. We can always
switch to DISTRIBUTE later.
 
Richard:
  Maybe you  could locate  the culprit  by looking into  a map  and determining
where the file was stopped, more or  less, and then looking for nearby servers.
Or maybe resend  a dummy 1-line file  to the same list with  ACK=MAIL. I myself
always use ACK=MAIL  and never had any  problem so far although  the files were
3,000+ records; however  it's very  easy to run  into a problem  if one  of the
servers gets logged off for some reason and its spool is purged, etc.
 
  Eric